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

[iMiMx (iMx)]

Running the latest 0.17.x release noticed the ‘active fault’ was showing as Unavailable this morning and saw the below in the logs:

Logger: ramses_rf.protocol.transport
Source: /usr/local/lib/python3.9/site-packages/ramses_rf/protocol/transport.py:447 
First occurred: 22 January 2022, 00:20:55 (6 occurrences) 
Last logged: 05:58:19

000 I --- --:------ 36:000268 --:------ F1FF 023 0011017E80B5478233304339204930333A303535353036 < Cant create packet (ignoring): Corrupt addresses: Invalid addr set: --:------ 36:000268 --:------
000 RQ --- --:------ 10:050588 --:------ 30C9 001 01 < Cant create packet (ignoring): Corrupt addresses: Invalid addr set: --:------ 10:050588 --:------
000 RQ --- --:------ 10:050588 --:------ 00C9 001 03 < Cant create packet (ignoring): Corrupt addresses: Invalid addr set: --:------ 10:050588 --:------
000 RQ --- --:------ 10:050588 --:------ 0006 001 00 < Cant create packet (ignoring): Corrupt addresses: Invalid addr set: --:------ 10:050588 --:------
000 I --- 03:005559 --:------ 03:055596 30C9 003 000708 < Cant create packet (ignoring): Corrupt addresses: Invalid src/dst addr pair: 03:005559 --:------ 03:055596



Logger: ramses_rf.protocol.message
Source: /usr/local/lib/python3.9/site-packages/ramses_rf/protocol/message.py:391 
First occurred: 05:30:05 (149 occurrences) 
Last logged: 07:56:43

I --- 01:050858 --:------ 01:050858 0418 022 000000B00704010000001C162BD27FFFFF7000000002 < AssertionError(07)
RP --- 01:050858 18:141846 --:------ 0418 022 000000B00704010000001C162BD27FFFFF7000000002 < AssertionError(07)
I --- 01:050858 --:------ 01:050858 0418 022 004000B00704010000001C162BF27FFFFF7000000002 < AssertionError(07)
RP --- 01:050858 18:141846 --:------ 0418 022 004000B00704010000001C162BF27FFFFF7000000002 < AssertionError(07)
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/message.py", line 382, in _validate
    result = PAYLOAD_PARSERS.get(self.code, parser_unknown)(
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/parsers.py", line 152, in wrapper
    result = fnc(payload, msg, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/parsers.py", line 596, in parser_0418
    assert payload[8:10] in _0418_FAULT_TYPE, payload[8:10]
AssertionError: 07

Time (first occurrence) lines up with a ‘bogus’ 250C value for a faked sensor.03_xxxxxx device

Spike is not present on the Xiaomi BLE sensor being used as a faked device:

After a restart of HA, the ‘binary_sensor.01_050858_active_fault’ is still showing as unavailable - even though the rest of the zones are showing data correctly. I haven’t tried ‘restore_cache: false’, will have to try that later. Controller shows the sensor error:

I don’t have the ability to clear the fault log on the controller, no button…. And no accessible batteries to remove (per the Evohome documentation) on my ancient controller.

This is the first oddity I’ve seen in a new weeks, since I got rid of the DT92E (horrendous looking things) and replaced them all with the Xiaomi faked sensors.

Rooms that didn’t have external temperature readings previously, relying on the TRVs, now heat more consistently and pretty much never over or under-run…after a week or so for Evohome to adjust/relearn.

[zxdavb (David Bonnes)]

@iMiMx

noticed the ‘active fault’ was showing as Unavailable

That shouldn’t happen - it should be OK, or Problem.

@iMiMx

Cant create packet (ignoring): Corrupt addresses: Invalid src/dst addr pair: 03:005559 --:------ 03:055596

Except for this specific packet, the rest are truly corrupt.

@iMiMx

I --- 01:050858 --:------ 01:050858 0418 022 000000B00704010000001C162BD27FFFFF7000000002 < AssertionError(07)

Vey interesting - sorry, the error message should be better.

@iMiMx

Time (first occurrence) lines up with a ‘bogus’ 250C value for a faked sensor.03_xxxxxx device

The is the cause of the 07.

@iMiMx

Controller shows the sensor error:

You have captured a error I have never seen before. Remarkable, given the number of packet logs I have. You very rightly sent me a screen shot - thanks!

There is a way to remove the 250C value from the HA database, if you are desperate. I may look at a means of rejecting such in evohhome_cc, before it passes them onto the controller.

@iMiMx

Spike is not present on the Xiaomi BLE sensor being used as a faked device:

OK, It was corrupted during transmission.

[zxdavb (David Bonnes)]

@Robvde

What I noticed is that 02_013748_relay_demand is as percentage. I think this is the control of the pump of the UFH (HCE80) and only can be on or off. In the log the value is 0% or 100%.

For an UFC, the values seen are either 0x00, or 0xC8 (200 decimal) - this is converted to a percentage by dividing by 200 (or 2, if you prefer).

However, for some devices it can be 0% to 100%, and all values in between.

Similar example: for boiler control (heat_demand, not relay_demand), a BDR91 will be on/off (with TPI)< but an R8810A (OTB), it will go any value from 0% up to 100%.

(venv) dbonnes@vm-builder ~/c/ramses_rf (master)> cat .secret*/*/*.log | grep -E ' (RP|I).* 0008 ' | grep -vE ' 002 ..(00|C8)' | head -2 | python client.py -ns -rrr parse
2021-10-17T00:14:24.891434 088  I --- --:------ --:------ 12:106131 0008 002 000C
2021-10-17T00:14:25.886963 084  I --- 22:054901 --:------ 22:054901 0008 002 00C6

I could change it for UFC, though…

Question: do all implementations of a UFC (HCE80) have a pump attached to them?

[zxdavb (David Bonnes)]

@stevieb12345

I’ve just noticed this error, which I think is new.

Sorry, you need to tell me what version you’re using: 0.17.13 or 0.18.2?

IN any case, the one you’ve shown me is due to a corrupt packet - the payload is 8400, which gives a value of >33,000 - normal values for CO2 in the home are 400-800 ppm (and maybe as high at 1,500).

The 31DA` packets are corrupt, only because they’re reflecting what the sensor is saying.

I mean it could be 33,000… Is there a reason for that?

[llevering (Leonard Levering)]

All HCE80 have a relais for a pump. However one doesn’t need to have it connected. It depends on the type underfloor heating unit you have (and the heating system in general). I have no pump connected to either of them, one of to most annoying things is you cannot disable the relay for the pump you always here it clicking which at night can be quite audible.

For my UFC I see all values ranging from 0% to 100% and it seems very accurate as it is implemented now (in my case at least).

[zxdavb (David Bonnes)]

@MDIGIT1971

In the previous version I was running it was not seeing the correct number of actuators for that room. It declared one of the actuators as an orphan. This is why I check this evohome_cc file.

If required, you should be sending me the schema from the device state attributes of the 01:xxxxxx schema entity instead.

One way is to use the Developer tools, Template:

{{ state_attr("binary_sensor.01_145038_schema", "schema") }}

[zxdavb (David Bonnes)]

@llevering

For my UFC I see all values ranging from 0% to 100% and it seems very accurate as it is implemented now (in my case at least).

For relay demand, or heat demand?

[zxdavb (David Bonnes)]

@MDIGIT1971 Please send me a packet log & I’ll have a look.

[llevering (Leonard Levering)]

Sorry heat_demand, forgot about relay_demand as a separate entity as I have no use for it. It is indeed all or nothing.

[iMiMx (iMx)]

@zxdavb

There is a way to remove the 250C value from the HA database, if you are desperate. I may look at a means of rejecting such in evohhome_cc, before it passes them onto the controller.

MariaDB backend, so easy enough. For anyone else, I’m running a supervised install on Ubuntu:

• On the main host, get the MariaDB container ID:

docker ps|grep maria
c78d9004edfc   homeassistant/amd64-addon-mariadb:2.4.0                      "/init"                  3 hours ago    Up 3 hours

• Enter the MariaDB container:

docker exec -it c78d9004edfc bash
bash-5.0#

• Connect to mysql/MariaDB:

bash-5.0# mysql
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 32
Server version: 10.4.19-MariaDB MariaDB Server

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]>

• ‘use’ the homeassistant DB:

MariaDB [(none)]> use homeassistant;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
MariaDB [homeassistant]>

• List the states for the impacted sensor, greater than 30:

MariaDB [homeassistant]> select * from states where entity_id="sensor.03_055506_temperature" and state > 30;
+----------+--------+------------------------------+--------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------+----------------------------+----------------------------+----------------------------+--------------+
| state_id | domain | entity_id                    | state  | attributes                                                                                                                                                                                                                                                       | event_id | last_changed               | last_updated               | created                    | old_state_id |
+----------+--------+------------------------------+--------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------+----------------------------+----------------------------+----------------------------+--------------+
| 65422595 | sensor | sensor.03_055506_temperature | 246.79 | {"state_class":"measurement","controller_id":"01:050858","device_id":"03:055506","domain_id":"04","domain_name":"Master Bed","setpoint":null,"unit_of_measurement":"\u00b0C","device_class":"temperature","friendly_name":"Master Bedroom - Thermostat (Faked)"} | 72324385 | 2022-01-24 05:30:05.664632 | 2022-01-24 05:30:05.664632 | 2022-01-24 05:30:05.664632 |     65421878 |
+----------+--------+------------------------------+--------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------+----------------------------+----------------------------+----------------------------+--------------+
1 row in set, 13 warnings (0.012 sec)

• Looks good, modify to delete:

MariaDB [homeassistant]> delete from states where entity_id="sensor.03_055506_temperature" and state > 30;
Query OK, 1 row affected, 13 warnings (0.030 sec)

• Graph back to normal

[MDIGIT1971 (MarcovD1971)]

Just sent you a logfile message… Over here I decided to take everything away (since it was stalling all the time)

• In previous version after a prety long wait (a week al least) it seemed to have stalled. Unavailable all over. Which I did not see the time before. I am thinking whether there was somethign that might have triggered this, cant think of it right now.
• The thing was to see if it really could discover the right actuators for my first zone, that it did correctly.
• Still dont understand why below config item gives me an error message and prevents me from restarting the core. I need to restart the host to get below config running:

configuration.yaml

evohome_cc: !include evohomevh.yaml

which will call the seperate config file (easier when I need to disable instead of # ing all these lines) but I gives me an error when it checks the file. While after a restart there seems to be no problem.

• Also it stops functioning and later I discovered that I stopped recording packlogs as well

But then I noticed that after a short time it stalled. The homeassistant.log file kept on reporting so the process was still running. But the items were no longer updated…
This morning after a restart, fresh install (removed all packetlogs) only kept evohome_cc file in the storage folder I noticed these lines:

2022-01-24 11:52:53 ERROR (MainThread) [homeassistant] Error doing job: Exception in callback SerialTransport._read_ready()
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/asyncio/events.py", line 80, in _run
    self._context.run(self._callback, *self._args)
  File "/usr/local/lib/python3.9/site-packages/serial_asyncio/__init__.py", line 119, in _read_ready
    self._protocol.data_received(data)
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/transport.py", line 477, in data_received
    self._line_received(dtm, _normalise(_str(raw_line)), raw_line)
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/transport.py", line 460, in _line_received
    self._pkt_received(pkt)
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/transport.py", line 704, in _pkt_received
    self._qos_received(pkt)
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/transport.py", line 762, in _qos_received
    logger_rcvd(msg, wanted=wanted)
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/transport.py", line 723, in logger_rcvd
    pkt._hdr or str(pkt),
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/frame.py", line 353, in _hdr
    self._hdr_ = pkt_header(self)
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/frame.py", line 480, in pkt_header
    return f"{header}|{pkt._ctx}" if isinstance(pkt._ctx, str) else header
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/frame.py", line 342, in _ctx
    self._ctx_ = self._idx
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/frame.py", line 364, in _idx
    self._idx_ = _pkt_idx(self) or False
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/frame.py", line 439, in _pkt_idx
    raise InvalidPayloadError(
ramses_rf.protocol.exceptions.InvalidPayloadError: Corrupt payload: Packet idx is FF, but expecting no idx (00)

And not very much later this was my thermostat screen:

When I inspect the packlog (where it stopped) then I notice this in the homeassistant.log

2022-01-24 12:06:24 INFO (MainThread) [ramses_rf.message] || CTL:059885 | HGI:010642 | RP | system_fault     |  00  || {'log_idx': '00', 'log_entry': ['21-12-31T23:14:08', 'restore', 'comms_fault', 'sensor', '03', '04:126366', 'B0', '0000', 'FFFF7000']}
2022-01-24 12:06:25 INFO (MainThread) [ramses_rf.message] || CTL:059885 | HGI:010642 | RP | system_mode      |      || {'system_mode': 'auto', 'until': None}
2022-01-24 12:06:39 INFO (MainThread) [ramses_rf.message] || STA:176627 |            |  I | temperature      |      || {'temperature': 18.78}
2022-01-24 12:06:40 INFO (MainThread) [ramses_rf.message] || STA:155573 |            |  I | message_3120     |      || {'unknown_0': '70B00000', 'unknown_5': '00', 'unknown_2': 'FF'}
2022-01-24 12:06:52 INFO (MainThread) [ramses_rf.message] || CTL:059885 |            |  I | relay_demand     |  FC  || {'domain_id': 'FC', 'relay_demand': 0.0}
2022-01-24 12:06:52 INFO (MainThread) [ramses_rf.message] || OTB:030670 | CTL:059885 |  I | heat_demand      |  FC  || {'domain_id': 'FC', 'heat_demand': 0.0}

Was having the idea to go back to the original version I came from but HACS wouldnt let me…

[zxdavb (David Bonnes)]

@Lloyd

I have a small issue with occasional lockouts, which occur when … and occasionally this causes a boiler lockout, even with ABV etc. in place and working.

The fact is, you need your system not to do this.

@Lloyd

Is it possible with this integration to send a heat demand (of zero) directly to the BDR91?

Yes - although I’d have to enable the feature (there are two ways this can be achieved). However, see above.

I’m curious, what controller do you have - if it’s the latest Wifi/Colour (gen 3), is it running the latest firmware?

[zxdavb (David Bonnes)]

@MDIGIT1971

2022-01-22 15:52:52 INFO (MainThread) [ramses_rf.message] || CTL:059885 | RFG:051821 | RP | zone_mode | 01 || {'zone_idx': '01', 'mode': 'follow_schedule', 'setpoint': 12.0}

I think the above is due to a recent change I made - it is a bit of an edge case (in that I don’t regularly test it) - you have a RFG100.

No: it works for me:

(venv) dbonnes@vm-builder ~/c/ramses_rf (master)> cat .secret*/*/*.log | grep -E ' RP.* 01:.* 30:.* 2349 01' | head -4 | python client.py -ns parse

22:16:21.759 || CTL:076010 | RFG:042165 | RP | zone_mode | 08 || {'zone_idx': '08', 'mode': 'temporary_override', 'setpoint': 17.5, 'until': '2021-10-26T23:30:00'}
22:16:31.558 || CTL:076010 | RFG:042165 | RP | zone_mode | 09 || {'zone_idx': '09', 'mode': 'temporary_override', 'setpoint': 18.5, 'until': '2021-10-26T22:30:00'}
22:16:41.659 || CTL:076010 | RFG:042165 | RP | zone_mode | 0A || {'zone_idx': '0A', 'mode': 'temporary_override', 'setpoint': 17.5, 'until': '2021-10-26T22:30:00'}
06:54:52.196 || CTL:059885 | RFG:051821 | RP | zone_mode | 02 || {'zone_idx': '02', 'mode': 'temporary_override', 'setpoint': 12.0, 'until': '2022-01-03T07:40:00'}

[Lloyd (Lloyd Adams)]

@zxdavb

@Lloyd

I have a small issue with occasional lockouts, which occur when … and occasionally this causes a boiler lockout, even with ABV etc. in place and working.

The fact is, you need your system not to do this.

@Lloyd

Is it possible with this integration to send a heat demand (of zero) directly to the BDR91?

Yes - although I’d have to enable the feature (there are two ways this can be achieved). However, see above.

I’m curious, what controller do you have - if it’s the latest Wifi/Colour (gen 3), is it running the latest firmware?

I know I should really sort the issue at source, but the boiler will be replaced this summer, so I’m loath to make any physical changes for something that is very occasional.

Running the latest controller, with the latest firmware.

[zxdavb (David Bonnes)]

@Lloyd

I know I should really sort the issue at source, but the boiler will be replaced this summer, so I’m loath to make any physical changes for something that is very occasional.

I have plans to implement changes to support this (in fact, my version can do so, already), but I can’t justify pushing that feature in front of others.

[Lloyd (Lloyd Adams)]

That’s fine. I presume that the changes would be in ramses_rf.

[zxdavb (David Bonnes)]

No, it would be a change in evohome_cc - an extension of the send_packet service.

[Cinamon]

I try to connect a fake sensor to my UFH. I use now the evohome touch as sensor but i want to you another (zigbee) sensor. When i want to pair a fake sensor id (03:123001) to the system it doesn’t work.
The evohome doesn’t detect anything when i select pair sensor at the evohome screen.
I use this service:

service: evohome_cc.fake_device
data:
  device_id: '03:123001'

[iMiMx (iMx)]

Click ‘All available parameters’ (In YAML mode) on Developer Tools → Service page - you need to create_device, then start_binding once done

service: evohome_cc.fake_device
data:
  device_id: '03:123001'
  create_device: true

Then edit your evohome_cc configuration, to add the new device with a faked hint, restart HA… then…:

service: evohome_cc.fake_device
data:
  device_id: '03:123001'
  start_binding: true

[zxdavb (David Bonnes)]

@iMiMx

edit your evohome_cc configuration, to add the new device with a faked hint, restart HA… then…:

service: evohome_cc.fake_device
data:
  device_id: '03:123001'
  start_binding: true

Just doing the above should be enough, or:

service: evohome_cc.fake_device
data:
  device_id: '03:123001'
  create_device: true
  start_binding: true

Doing the above will get it into the schema (and start binding), but if you ever restart the system without using the cache, then it must be in your configuration file.