Honeywell CH/DHW via RF - evohome, sundial, hometronics, chronotherm

[bishop]

updated to 0.17.10 and all is fine. My ventilation is reporting fan speed and indoor humidity now and the values seems valid. This is an improvement over 0.17.7a
The rest seems to work as before.

Thanks a lot for the hard work

[iMiMx (iMx)]

@zxdavb

I have just pushed a new release, 0.17.10.

Generally seems good for me - although the below appears to still be broken:

@iMiMx

Not that I use it very often, but I don’t seem to be able to set a Permanent nor Temporary override? Does this work for others?

https://dl.dropboxusercontent.com/s/5xdyaeef3j481ug/Screen%20Recording%202022-01-12%20at%2013.09.02.mov?dl=0

Seems not just for me:

@bluediamond84

I tried it and it doesn’t work for me either

According to the log it looks like the value of setpoint/active is missing

set_zone_mode('01:024170', 0, 'temporary_override', None, None, {}): Invalid args: For temporary_override, setpoint/active cant be None
Traceback (most recent call last):
  File "/srv/homeassistant/lib/python3.9/site-packages/ramses_rf/protocol/command.py", line 148, in _wrapper
    return fcn(cls, *args, **kwargs)
  File "/srv/homeassistant/lib/python3.9/site-packages/ramses_rf/protocol/command.py", line 736, in set_zone_mode
    mode = _normalise_mode(mode, setpoint, until, duration)
  File "/srv/homeassistant/lib/python3.9/site-packages/ramses_rf/protocol/command.py", line 221, in _normalise_mode
    raise ValueError(
ValueError: Invalid args: For temporary_override, setpoint/active cant be None

This is the latest I get, when I try:

2022-01-16 08:04:46 ERROR (SyncWorker_2) [ramses_rf.protocol.command] set_zone_mode('01:050858', 0, 'temporary_override', None, None, {}): Invalid args: For temporary_override, setpoint/active cant be None
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/command.py", line 174, in _wrapper
    return fcn(cls, *args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/command.py", line 762, in set_zone_mode
    mode = _normalise_mode(mode, setpoint, until, duration)
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/command.py", line 247, in _normalise_mode
    raise ValueError(
ValueError: Invalid args: For temporary_override, setpoint/active cant be None
2022-01-16 08:04:46 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection] [139629013814912] 'NoneType' object has no attribute '_source_entity'
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 185, in handle_call_service
    await hass.services.async_call(
  File "/usr/src/homeassistant/homeassistant/core.py", line 1495, in async_call
    task.result()
  File "/usr/src/homeassistant/homeassistant/core.py", line 1530, in _execute_service
    await handler.job.target(service_call)
  File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 209, in handle_service
    await self.hass.helpers.service.entity_service_call(
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 663, in entity_service_call
    future.result()  # pop exception if have
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 896, in async_request_call
    await coro
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 700, in _handle_entity_call
    await result
  File "/usr/src/homeassistant/homeassistant/components/climate/__init__.py", line 486, in async_set_preset_mode
    await self.hass.async_add_executor_job(self.set_preset_mode, preset_mode)
  File "/usr/local/lib/python3.9/concurrent/futures/thread.py", line 52, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/config/custom_components/evohome_cc/climate.py", line 258, in set_preset_mode
    self.svc_set_zone_mode(mode=ZoneMode.TEMPORARY)
  File "/config/custom_components/evohome_cc/climate.py", line 287, in svc_set_zone_mode
    self._call_client_api(
  File "/config/custom_components/evohome_cc/__init__.py", line 396, in _call_client_api
    func(*args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/zones.py", line 844, in set_mode
    return self._send_cmd(cmd)
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/entities.py", line 225, in _send_cmd
    cmd._source_entity = self
AttributeError: 'NoneType' object has no attribute '_source_entity'

Sensor binary_sensor.18_141846_config seems to be unavailable, not sure if I need to try restore_cache: false, whether it’s supposed to be like this on my system, etc.

@dev_el_ops

The only thing I note is a number of sensors that are marked as “unavailable” (which is correct, I wouldn’t think the BDR91 is reporting back e.g. DHW status. It would be nice to have those sensors at all in that case, to avoid clutter and confusion.

I manually disable these in the UI, it then hides them easily enough - I don’t seem to have ‘flame_active’ I assume that’s for OpenTherm etc which I don’t have.

[zxdavb (David Bonnes)]

@iMiMx

[0.17.10] Generally seems good for me - although the below appears to still [ed.: my emphasis] be broken

ValueError: Invalid args: For temporary_override, setpoint/active cant be None

Yes, this bug has been around for years. It is because I have been focussed upon sensors, and not Climate - there are other bugs too - I will look at Climate presently (when I also hope to add HVAC).

Until then, simply use the official evohome TCC integration.

@dev_el_ops

The only thing I note is a number of sensors that are marked as “unavailable” (which is correct, I wouldn’t think the BDR91 is reporting back e.g. DHW status. It would be nice to [not?] have those sensors at all in that case, to avoid clutter and confusion.

dev_el_ops is a special case - his system is not evohome (so perhaps he could PM me with these conscerns, so to not excite others too much).

@iMiMx

I manually disable these in the UI, it then hide them easily enough - I don’t seem to have ‘flame_active’ I assume that’s for OpenTherm etc which I don’t have.

Correct: OpenTherm is very variable - it depends upon the specifics of the make/model of your boiler - I cannot get too involved in this (is too much work) - just disable the entities.

I will warn OpenTherm users - you have two of many sensors… in future it will be only one of everything.

[zxdavb (David Bonnes)]

@iMiMx

Sensor binary_sensor.18_141846_config seems to be unavailable…

It will be permanently unavailable. Delete/remove it from HA.

It has been replaced by a new binary sensor, in your case: binary_sensor.18_141846_status, which contains the same extra state attributes , and is much more useful…

When that binary sensor is true, it will be because there is a problem with your HGI80 compatible (evofw3) dongle.

[hamba]

Hi,

Anyone here running on a raspberry pi? I seem to have a problem where it keeps restarting and just want to see if there are any other people out there who is on the latest version.

[stevieb12345]

Your Pi keeps restarting?

[hamba]

yup, supervisor keeps restarting
an example from last nights logs

22-01-15 17:43:23 ERROR (MainThread) [supervisor.homeassistant.api] Error on call http://172.30.32.1:8123/api/config: 
22-01-15 17:43:28 ERROR (MainThread) [supervisor.homeassistant.api] Error on call http://172.30.32.1:8123/api/config: 
22-01-15 17:43:28 WARNING (MainThread) [supervisor.misc.tasks] Watchdog miss API response from Home Assistant
22-01-15 17:45:04 ERROR (MainThread) [supervisor.homeassistant.api] Error on call http://172.30.32.1:8123/api/config: 
22-01-15 17:45:59 ERROR (MainThread) [supervisor.homeassistant.api] Error on call http://172.30.32.1:8123/api/config: 
22-01-15 17:45:59 ERROR (MainThread) [supervisor.misc.tasks] Watchdog found a problem with Home Assistant API!
22-01-15 17:45:59 INFO (SyncWorker_4) [supervisor.docker.interface] Restarting ghcr.io/home-assistant/raspberrypi4-64-homeassistant
22-01-15 17:47:45 ERROR (MainThread) [supervisor.homeassistant.api] Error on call http://172.30.32.1:8123/api/config: 
22-01-15 17:48:30 ERROR (MainThread) [supervisor.homeassistant.api] Error on call http://172.30.32.1:8123/api/config: 
22-01-15 17:49:39 WARNING (MainThread) [supervisor.homeassistant.websocket] Connection is closed

Its happening to both my Pis that are running evohome_cc, as soon as I upgrade past v0.17.6 it starts going into this restart cycle.
I’ve now disabled everything apart from evohome_cc on one of them, lets see how that goes

[stevieb12345]

I’ve got the same problem on my Nuc. Rolling back to 17.6 solves the issue. I’ve messaged David about it and he’s going to look in to it.

22-01-16 11:03:39 ERROR (MainThread) [supervisor.homeassistant.api] Error on call http://172.30.32.1:8123/api/config: 
22-01-16 11:03:39 WARNING (MainThread) [supervisor.misc.tasks] Watchdog miss API response from Home Assistant
22-01-16 11:04:24 ERROR (MainThread) [supervisor.homeassistant.api] Error on call http://172.30.32.1:8123/api/config: 
22-01-16 11:06:10 ERROR (MainThread) [supervisor.homeassistant.api] Error on call http://172.30.32.1:8123/api/config: 
22-01-16 11:06:10 ERROR (MainThread) [supervisor.misc.tasks] Watchdog found a problem with Home Assistant API!

[hamba]

ah, nice to know that I’m not going mad.
Do you have any other integrations and plugins running?

[stevieb12345]

I have a few running, it’s took me over a week to narrow it down to when I updated evohome.

Anything above 17.6 and the problems start within 15 minutes.

[hamba]

same symptoms here. Can’t get it stable on anything after that. Thanks

[dev_el_ops (David Schmitt)]

have you replaced restore_state: true with restore_cache: true as explained in the release notes?

[hamba]

Yes, it won’t start otherwise, the problem is that it starts fine but then supervisor starts restarting itself

[zxdavb (David Bonnes)]

So, I am back from the kids’ soccer…

I understand two people are having issues running anything >0.17.6 on a Pi. I understand issues occur fairly reliably after about 15 minutes.

Can anyone running 0.17.10 without any issue let us know - let us know if it is on a Pi.

For those with issues, please run 0.17.7 with with this logging:

logger:
  default: warn
  logs:
    homeassistant.core: debug
    homeassistant.helpers.entity: info

    ramses_rf.message: info

Restart HA, wait for it to crash, and send me the HA log, home-assistant.log

If that fails, we’ll try:

logger:
  default: info

In the meantime, I will do a code review between 0.17.6 and 0.17.7.

[zxdavb (David Bonnes)]

@stevieb12345 @hamba Is it this? HassOS partially hangs since 7.1 - UAS uas_eh_abort_handler

[Spaco]

Running HA core on a pi, no issue here with 0.17.10 and HA 2021.12.9. I guess it’s only occurring on supervised instances?

[zxdavb (David Bonnes)]

There are a lot of changes between 0.16.6 and 0.17.10, but relatively few between it at 0.17.7 - I have just had a look at them all… I can’t see where there would be an issue…

Even with a memory leak, 15 mins isn’t enough for it to take an effect?

[hamba]

Hi,

Thanks for looking into this, I’ve enabled those logs and will get them over to you soon.
The bug looks related to ssd drives connected via usb, I’m using a sd card.

It does seem to be a supervisor problem and not the core.

[zxdavb (David Bonnes)]

@hamba

The bug looks related to … usb

My point is as above.

[hamba]

stupid question here, does the sd card use usb?