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

zxdavb · November 25, 2021, 3:38pm

As you infer, the second evofw3 should really be in listen-only mode:

python client.py listen /dev/ttyUSB0

Yes, my hardware guys have said as much to me - I don’t get involved in that stuff too much.

The same chaps are working on this, too - more like an 802.1D ethernet bridge; you just ask the hardware guys what they’re doing - you can reach out to them via the evofw3 repo, or there is a slack group somewhere.

The way I might do it is to replace client.py (which leverages the ramses_rf library) with a bridge.py (I’d be interested to write one, but don’t have time). It would be a nice little project, no too hard, if you knew some Python.

Yes, and no - there is an option to ‘inject’ well-structured commands (i.e. below the API layer), but for your purposes you’d need impersonation - this is doable (ramses_rf does it all the time, e.g. Faking), but not yet exposed via HA.

For the basic sending, enable the evohome_cc.send_packet service call in HA:

evohome_cc:
  send_packet: true

The second thing evohome_cc needs is a way to trigger an event when a certain packet is received.

Huppeldeflut · November 25, 2021, 4:38pm

The second evofw3 is already in listenmode

I was thinking of doing it outside of Home Assistant and some how injecting the received data directly into the tty of the evofw3 connected to Home Assistant.
That way it could also be used by Domoticz (I know the enemy ) users.

But below the API layer would also work I think. The commands should be well-structured as they are sniffed close by and filtered for a specific source.

I don’t want to resend the traffic, as the controller is receiving the commands (at least it is updating the temperature for that zone) and it would then receive the data twice.
That’s why I said “simple repeater”, it would be more of a remote receiver to pickup the missing data.

I’ll check with the evofw3 repo guys, maybe they have some form of beta version I could work with.

As you said it should not be to hard, but time is the issue.
For me the biggest time consumer will be to improve my Python skills. I’m more of a VB.net/Java/Bash/Powershell guy, but should be doable.
The other stick will probably arrive faster

Lloyd · November 25, 2021, 4:55pm

No idea on your level of expertise, but are you sure what you have is a 868MHz pigtail? My receiver seems to work well with one of these:

zxdavb · November 25, 2021, 5:07pm

Version 0.16.18 just released - is much less likely to trip RF duty cycle limit on a Honeywell HGI80 with back-to-back HA restarts.

ALso @Lloyd - code specifically for our bag chase - please use this logging:

logs:
    homeassistant.core: debug 

    ramses_rf.devices: debug
    ramses_rf.entity: debug
    ramses_rf.message: info  
    ramses_rf.protocol.message: info

    custom_components.evohome_cc: debug
    custom_components.evohome_cc.sensor: debug

Send me the logs minimum 2.5 hours after a restart.

bluediamond84 · November 25, 2021, 7:39pm

Could you clarify for me if I would add my 18:009231 sensor to the know_list.
After getting these messages in the log

2021-11-25 19:10:17 WARNING (MainThread) [ramses_rf.protocol.transport] Allowing packets with device_id: 18:009231 (is gateway), configure the known_list/block_list as required

I added 18:009231 to the know_list and restarted. Then I got these AssertionError

2021-11-25 19:21:03 WARNING (MainThread) [ramses_rf.protocol.message] RP --- 01:024170 18:009231 --:------ 0418 022 004000B0060402000000BC95717AFFFFFF70020F131A < Corrupt payload: Payload doesn't match '^00(00|40|C0)[0-3][0-9A-F]B0[0-9A-F]{6}0000[0-9A-F]{12}FFFF700[01][0-9A-F]{6}$': 004000B0060402000000BC95717AFFFFFF70020F131A (will be ignored)
2021-11-25 19:21:03 ERROR (MainThread) [ramses_rf.protocol.message] RP --- 01:024170 18:009231 --:------ 0418 022 004000B0060402000000BC95717AFFFFFF70020F131A < AssertionError(02)
Traceback (most recent call last):
  File "/srv/homeassistant/lib/python3.9/site-packages/ramses_rf/protocol/message.py", line 364, in _validate
    result = PAYLOAD_PARSERS.get(self.code, parser_unknown)(
  File "/srv/homeassistant/lib/python3.9/site-packages/ramses_rf/protocol/parsers.py", line 131, in wrapper
    return func(*args, **kwargs)
  File "/srv/homeassistant/lib/python3.9/site-packages/ramses_rf/protocol/parsers.py", line 531, in parser_0418
    assert payload[12:14] in _0418_DEVICE_CLASS, payload[12:14]
AssertionError: 02

I also noticed these entities are created, but doesn’t get any state information:

HCW82 sensor heat_demand; there where none before (0.9.3)
HCW82 sensor battery_low. There where before but also didn’t get any information in the past. It doesn’t bother me, just want you to know.
HCE80 sensor heat_demand; did work before.
BDR91 actuator; did work before

Scanning the logs finding these warnings Expecting Payload for HCW82

2021-11-25 19:17:25 WARNING (MainThread) [ramses_rf.protocol.frame]  I 078 03:201498 --:------ 03:201498 30C9 003 0106A4 # Expecting payload index to be 00
2021-11-25 19:17:25 WARNING (MainThread) [ramses_rf.protocol.frame]  I 023 03:201565 --:------ 03:201565 30C9 003 0106FE # Expecting payload index to be 00
2021-11-25 19:17:25 WARNING (MainThread) [ramses_rf.protocol.frame]  I 136 03:052382 --:------ 03:052382 30C9 003 010762 # Expecting payload index to be 00
2021-11-25 19:17:25 WARNING (MainThread) [ramses_rf.protocol.frame]  I 238 03:196221 --:------ 03:196221 30C9 003 0106CC # Expecting payload index to be 00
2021-11-25 19:17:25 WARNING (MainThread) [ramses_rf.protocol.frame]  I 221 03:196196 --:------ 03:196196 30C9 003 010758 # Expecting payload index to be 00

Scanning the logs finding these warnings IS_EXPIRED for HCE80

2021-11-25 19:17:35 WARNING (MainThread) [ramses_rf.protocol.transport] PktProtocolQos.send_data(sent=0005|RQ|02:016894|0009): boff=3, want=0005|RP|02:016894|0009, tout=2021-11-25T19:17:35.212: QoS: IS_EXPIRED (giving up) (2/2)
2021-11-25 19:18:35 WARNING (MainThread) [ramses_rf.protocol.transport] PktProtocolQos.send_data(sent=0005|RQ|02:017825|0009): boff=3, want=0005|RP|02:017825|0009, tout=2021-11-25T19:18:35.327: QoS: IS_EXPIRED (giving up) (2/2)
2021-11-25 19:19:35 WARNING (MainThread) [ramses_rf.protocol.transport] PktProtocolQos.send_data(sent=0005|RQ|02:017729|0009): boff=3, want=0005|RP|02:017729|0009, tout=2021-11-25T19:19:35.417: QoS: IS_EXPIRED (giving up) (2/2)

Scanning the logs finding this warning IS_EXPIRED for BDR91

2021-11-25 20:06:41 WARNING (MainThread) [ramses_rf.protocol.transport] PktProtocolQos.send_data(sent=3EF1|RQ|13:140780): boff=3, want=3EF1|RP|13:140780, tout=2021-11-25T20:06:41.710: QoS: IS_EXPIRED (giving up) (2/2)

I will send you my packetlog

zxdavb · November 25, 2021, 8:49pm

Yes, you should. You all should use a known_list, and add all your devices to it, including the HGI-compatible gateway.

This is merely a co-incidence, it is just the case that I’ve never seen this particular feature in an 0418 packet before.

Please provide me with a screenshot (or the full text, if you can’t handle that) of your system log, specifically this one & the one before that:

{'log_idx': '00', 'log_entry': ['21-11-25T14:11:53', 'restore', 'comms_fault', '02', '04', '03:201498', 'B0', '0000', 'FFFF7002']}

… and I can/will fix it.

The HCW82 is being treated as any other thermostat, such as a DTS92, or a TR87RF - this is not optimal, but it is such a rare device, I haven’t needed to address this issue - I will see what I can do.

For the rest, I will look at your log.

iMiMx · November 26, 2021, 7:21am

Did a quick upgrade to 0.6.19 started seeing the below:

2021-11-26 07:16:09 ERROR (MainThread) [ramses_rf.protocol.command] validate_command(): get_dhw_mode() takes 2 positional arguments but 3 were given
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/command.py", line 143, in _wrapper
    return fcn(*args, **kwargs)
TypeError: get_dhw_mode() takes 2 positional arguments but 3 were given
2021-11-26 07:16:09 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/helpers.py", line 17, in execute_func
    return func(*args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/entities.py", line 98, in wrapper
    return func(self, discover_flag=discover_flag)
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/zones.py", line 326, in _discover
    [send_code(code) for code in (_1260, _1F41)]
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/zones.py", line 326, in <listcomp>
    [send_code(code) for code in (_1260, _1F41)]
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/zones.py", line 306, in send_code
    self._send_cmd(CODE_API_MAP[f"{RQ}/{code}"](self._ctl.id, self.idx))
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/entities.py", line 195, in _send_cmd
    cmd._source_entity = self
AttributeError: 'NoneType' object has no attribute '_source_entity'

zxdavb · November 26, 2021, 9:23am

I believe I have fixed this bug, offending code should be:

self._send_cmd(CODE_API_MAP[f"{RQ}/{code}"](self._ctl.id))

… fix is coming.

iMiMx · November 26, 2021, 9:25am

Whether it helps, or not, but just an observation - I downgraded to 0.14.24, hot water sensor is then consistently available again.

zxdavb · November 26, 2021, 9:46am

Thanks, I think I got it - a change introduced in 0.16.17 - a very useful change for zones, and reducing unneeded transmits (esp. with back-to-back restarts of HA), but a bug for the DHW side (DHW is a special type of zone).

I have no DHW in a test bed presently - I don’t have time to set one up at the moment, so we’ll see how it goes, I think it will be OK… but I’ve said that before.

You can help by testing 0.16.20!

The good new is, you might have helped me identify another bug that I’ve been struggling with!

@Lloyd Please switch to 0.16.20 as soon as you can.

iMiMx · November 26, 2021, 9:48am

Latest on GitHub seems to still be 0.16.19 - is it cached?

zxdavb · November 26, 2021, 9:54am

Try it now - just released.

iMiMx · November 26, 2021, 10:35am

Looks promising.

Lloyd · November 26, 2021, 12:03pm

Definite improvement. Both DHW packets have made it into the database. I will keep an eye on it for a bit longer.

iMiMx · November 26, 2021, 12:06pm

Now… I don’t know if this is recent code related, or… but… I’m seeing significantly less ‘Expired’ messages in my logs.

Something else that changed my end, that might be worthwhile for consideration for others seeing the same, is that one of my Z-Wave sensors (also using 868Mhz) began acting erratically. Even though it still said it had 100% battery, I changed the battery anyway and it resolved the problem.

I’ve previous been bitten by failing-but-not-showing-as-failing batteries with LightwaveRF (different frequency) so I now change all batteries once a year, regardless of whether or not they need it. I’ve seen that when batteries are on their way out, they perhaps ‘spam’ the radio frequency or cause interference (certainly some of the LightwaveRF Mood switches).

… am wondering if the failing battery in my Z-wave sensor, was causing problems for Evohome. Am going to change all the rest (Black Friday battery deal) over the next few days, as it happens this was just 11 months since they were changed previously (usually change them all first week of Jan).

… I also have Texecom Ricochet, which also uses 868Mhz - so am going to change those as well.

zxdavb · November 26, 2021, 12:08pm

Woot!

I have been hunting for this bug for so long…

iMiMx · November 26, 2021, 12:10pm

Still looks good for me - I updated at 10:25 - to the left, prior to this, was 0.14.24

iMiMx · November 26, 2021, 1:46pm

Has to be one or the other, or perhaps both… Unfortunately I swapped the z-wave battery and upgraded to 0.16.20 at about the same time - ~10:25

2021-11-26 10:14:05 WARNING (MainThread) [ramses_rf.protocol.transport] PktProtocolQos.send_data(sent=3EF1|RQ|13:215029): boff=3, want=3EF1|RP|13:215029, tout=2021-11-26T10:14:05.296: QoS: IS_EXPIRED (giving up) (2/2)
2021-11-26 10:15:58 WARNING (MainThread) [ramses_rf.protocol.transport] PktProtocolQos.send_data(sent=0008|RQ|13:215029): boff=3, want=0008|RP|13:215029, tout=2021-11-26T10:15:58.126: QoS: IS_EXPIRED (giving up) (2/2)
2021-11-26 10:16:04 WARNING (MainThread) [ramses_rf.protocol.transport] PktProtocolQos.send_data(sent=3EF1|RQ|13:215029): boff=3, want=3EF1|RQ|13:215029, tout=2021-11-26T10:16:04.137: QoS: IS_EXPIRED (giving up) (2/2)
2021-11-26 10:16:10 WARNING (MainThread) [ramses_rf.protocol.transport] PktProtocolQos.send_data(sent=0008|RQ|13:246213): boff=3, want=0008|RQ|13:246213, tout=2021-11-26T10:16:10.150: QoS: IS_EXPIRED (giving up) (2/2)
2021-11-26 10:16:16 WARNING (MainThread) [ramses_rf.protocol.transport] PktProtocolQos.send_data(sent=3EF1|RQ|13:246213): boff=3, want=3EF1|RQ|13:246213, tout=2021-11-26T10:16:16.159: QoS: IS_EXPIRED (giving up) (2/2)
2021-11-26 10:16:58 WARNING (MainThread) [ramses_rf.protocol.transport] PktProtocolQos.send_data(sent=0008|RQ|13:215029): boff=3, want=0008|RP|13:215029, tout=2021-11-26T10:16:58.119: QoS: IS_EXPIRED (giving up) (2/2)
2021-11-26 10:17:04 WARNING (MainThread) [ramses_rf.protocol.transport] PktProtocolQos.send_data(sent=3EF1|RQ|13:215029): boff=3, want=3EF1|RQ|13:215029, tout=2021-11-26T10:17:04.127: QoS: IS_EXPIRED (giving up) (2/2)
2021-11-26 10:17:10 WARNING (MainThread) [ramses_rf.protocol.transport] PktProtocolQos.send_data(sent=0008|RQ|13:246213): boff=3, want=0008|RQ|13:246213, tout=2021-11-26T10:17:10.140: QoS: IS_EXPIRED (giving up) (2/2)
2021-11-26 10:17:16 WARNING (MainThread) [ramses_rf.protocol.transport] PktProtocolQos.send_data(sent=3EF1|RQ|13:246213): boff=3, want=3EF1|RQ|13:246213, tout=2021-11-26T10:17:16.148: QoS: IS_EXPIRED (giving up) (2/2)
2021-11-26 10:18:58 WARNING (MainThread) [ramses_rf.protocol.transport] PktProtocolQos.send_data(sent=3EF1|RQ|13:215029): boff=3, want=3EF1|RP|13:215029, tout=2021-11-26T10:18:58.212: QoS: IS_EXPIRED (giving up) (2/2)
2021-11-26 10:19:09 WARNING (MainThread) [ramses_rf.protocol.transport] PktProtocolQos.send_data(sent=0008|RQ|13:246213): boff=3, want=0008|RP|13:246213, tout=2021-11-26T10:19:09.155: QoS: IS_EXPIRED (giving up) (2/2)
2021-11-26 10:20:58 WARNING (MainThread) [ramses_rf.protocol.transport] PktProtocolQos.send_data(sent=0008|RQ|13:215029): boff=3, want=0008|RP|13:215029, tout=2021-11-26T10:20:58.153: QoS: IS_EXPIRED (giving up) (2/2)

Since the upgrade/battery swap, to now, 13:46… only 1:

2021-11-26 10:49:39 WARNING (MainThread) [ramses_rf.protocol.transport] PktProtocolQos.send_data(sent=2E04|RQ|01:050858): boff=3, want=2E04|RQ|01:050858, tout=2021-11-26T10:49:39.657: QoS: IS_EXPIRED (giving up) (2/2)```

zxdavb · November 26, 2021, 2:11pm

These should work - the very occasional one is OK.

This may well be normal - I just need to think about turning off these particular RQs.

Could you send me up a packet log that includes a restart of HA, and is running 0.16.20 - I won’t need anything else except possibly your schema.

iMiMx · November 26, 2021, 2:42pm

Have messaged this.