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

[zxdavb (David Bonnes)]

@Lloyd

Though it is interesting that the two packets have different styles of output.

The first is a restored packet - it was annotated by the parser when it was saved before shutting down (& subsequently restarting) HA. Everything after the # is a comment & is ignored. The RSSI number is replaced with ... becuase it wasn’r ‘received’ via RF.

I’d say that’s why its timing out - although it is ‘loaded’ at 09:33, it is timestamped as something well before that. These packets normally ‘expire’ after an hour.

[bluediamond84 (bluediamond)]

@zxdavb

The 03:xxxxxx devices are anachronistic - I don’t have the ability to test them - they may behave differently to every other thermostat.

Is it only these devices causing an issue?

Sadly no. The controller also doesn’t update anymore.

@zxdavb

To be clear - did it work perfectly before? If so, what build was working for you? I need to know, so I can take the changes into account.

Yes, it works perfectly on version 0.9.3. After every test I downgrade to this one and then all my sensors getting there information. The Payload error shows also in this version, but it functions without problems.

@zxdavb

Is this an evohome controller? What make / model is it?

Honeywell evotouch. It doesn’t show a model version, but this one matches: ATC928G1000
https://products.ecc.emea.honeywell.com/europe-historic/2010_1/docs/pdf_evohome_atc928g1000.html

I will send you my packetlog from 0.16.14. Do you still need the one from the old version? It is no problem, just have to restart the system for a clean build.

[zxdavb (David Bonnes)]

@iMiMx

I did not add 04:055488 to my known_list, perhaps I should have? Although I assume as it’s present in the packet log, this is what you needed to see?

Yes, I got what I wanted. You can restore your zone to the two TRVs.

This is the relevant packet (I have added - and = for readability):

RP --- 01:050858 18:141846 --:------ 000C 016 00=00-0010D8DA-00-0010D92A-00-0010D8C0

It is 6 + 5 + 5 bytes instead of 6 + 6 + 6… This presents a small challenge (1x6B + 6x5B, 36 bytes for 7 TRVs) == (6x6B, 36 bytes for 6 TRVs) - how do I tell the difference?

What make/model controller do you have?

@iMiMx

P.S. Should heating_valve be under stored_hotwater?

Yes. It functions as the heating_control, but is definitely configured as a heating_valve.

[zxdavb (David Bonnes)]

@bluediamond84

Yes, it works perfectly on version 0.9.3.

Generally speaking, ramses_rf becomes more exacting as I learn more about the protocol over time… I wonder if this has a part to play.

There will be no plans to ‘weaken’ these tests of validity, only to ‘tune’ them as required.

@bluediamond84

Do you still need the one from the old version? It is no problem, just have to restart the system for a clean build.

No - the packet log format is unchanged since nearly 2y ago - it contains every packet seen by the HGI, regardless of filter lists, and regardless if valid (or not).

@bluediamond84

Honeywell evotouch. It doesn’t show a model version, but this one matches: ATC928G1000

So the 1st generation monochrome mode - it only supports 8 zones.

I will add this fix.

[iMiMx (iMx)]

@zxdavb

What make/model controller do you have?

Was part of ATP921G2080 base pack, which says:

The ATP921G2080 Honeywell evohome Base Pack (2014 MK2 Version)

Non-wifi version, there was previously a separate internet gateway that was used with it.

[Lloyd (Lloyd Adams)]

@zxdavb

I’d say that’s why its timing out - although it is ‘loaded’ at 09:33, it is timestamped as something well before that. These packets normally ‘expire’ after an hour.

That’s good to know.

So why doesn’t the packet at 09:49 set the value in the sensor?

Also I think the next DHW temperature packet is at 10:59:05, but there is no corresponding core debug entry associated with it.

[zxdavb (David Bonnes)]

@bluediamond84

I have updated the parsers for your evohome mono - you should get a lot less error logging - let me know, after you start using the next release.

There may still be issues!

[zxdavb (David Bonnes)]

OK, I’ve got 2 issues on the go:

• @Lloyd - chasing DHW sensor not available - awaiting a 24h set of logs
• @iMiMx - different format for 000C packet - I’m thinking about it… May be a short-term fix, then will be relying on an upcoming feature - ‘Profiles’

This is awaiting further testing by the edge-case user:

• @bluediamond84 - support for Mk1 evo & improved support for HCW82s – awaiting new release to test

@phdelodder I asked you some questions - you have not answered.

Is there anything else?

[Lloyd (Lloyd Adams)]

I have a TRV that never creates a temperature sensor. It creates the ones for the battery and the window status, but never one for the temperature.

The latest version, or the config changed you sent by PM appears to have resolved by heating relay status not reporting consistently. Probably need to run a bit longer to confirm that.

Had not realised you wanted full 24hr set of logs, but will send these through tomorrow.

[phdelodder (Philippe Delodder)]

I have responded this: Honeywell CH/DHW via RF - evohome, sundial, hometronics, chronotherm - #1904 by phdelodder

Maybe I missed it?

For now I’m looking into buying an RPI4 to be able to place the HGI80 closer to the controller for the stable connection

[zxdavb (David Bonnes)]

@phdelodder

Maybe I missed it?

@zxdavb

Last I heard, you were running two HGI80s at the same time, and one of them was in a VM - is that still the case?

The above was the question I was seeking an answer to.

Is it an actual Honeywell HGI80 or an evofw3 device?

[phdelodder (Philippe Delodder)]

I’m currently running only one instance with HGI80

[zxdavb (David Bonnes)]

@Lloyd

I have a TRV that never creates a temperature sensor. It creates the ones for the battery and the window status, but never one for the temperature.

We can look at this if it is still an issue after fixing the DHW issue - just let me know if it is still an issue.

@Lloyd

The latest version, or the config changed you sent by PM appears to have resolved by heating relay status not reporting consistently. Probably need to run a bit longer to confirm that.

I’d say it is the config change - nothing else relevant was changed.

Long-term, I’ll be using callbacks - that is: event-driven, instead of polled.

[zxdavb (David Bonnes)]

Someone has PM’d me & I think I should post my response for the benefit of all:

[I] restarted with the latest version updated at 16:13:06, and by 16:13:37 I had my first QoS message

2021-11-24 16:13:37 WARNING (MainThread) [ramses_rf.protocol.transport] PktProtocolQos.send_data(sent=3220|RQ|10:123456|7F): boff=0, want=3220|RP|10:123456|7F, tout=2021-11-24T16:13:37.119: QoS: IS_EXPIRED (giving up) (1/1)

I’ve had a further 117 of them in the next 50 minutes.

For reference I was receiving full info for the 10:123456 device before the big refactor you did…

The reality is this:

• these errors were previously logged as INFO, and you wouldn’t have seen them by default
• I’ve just switched them to a WARNING & you’ll now see them by default
• in all likelihood, these errors were always there, you just didn’t have visibility on it (a detailed look in your packet logs will support/refute this - you’ll see RQs without corresponding RPs)

The change in logging is there to make you aware why things may not be behaving as you might expect.

In the specific a case of an OTB, it may not matter as much because it is polled every 60 seconds.

[zxdavb (David Bonnes)]

Version 0.16.16 just released.

[zxdavb (David Bonnes)]

@Lloyd

Please run 0.16.16, and with the following to your configuration.yaml:

logger:
  logs:
    ramses_rf.devices: debug
    ramses_rf.message: debug

Don’t forget to use the other changes I sent you just now, via PM.

[Lloyd (Lloyd Adams)]

OK. I’ll leave that running overnight. I’ll send the logs in the morning, but this sequence may be of interest:

2021-11-24 20:51:30 INFO (MainThread) [ramses_rf.devices] DHW msg = None
2021-11-24 20:51:35 INFO (MainThread) [ramses_rf.message] || BDR:197705 | HGI:136212 | RP | relay_demand     |      || {'relay_demand': 0.22}
2021-11-24 20:51:35 INFO (MainThread) [ramses_rf.message] || BDR:197705 | HGI:136212 | RP | actuator_cycle   |      || {'modulation_level': 0.0, 'actuator_countdown': 104, 'cycle_countdown': 236, '_unknown_0': 'FF'}
2021-11-24 20:51:39 INFO (MainThread) [ramses_rf.devices] DHW msg = None
2021-11-24 20:51:39 INFO (MainThread) [ramses_rf.message] || BDR:164839 | HGI:136212 | RP | relay_demand     |      || {'relay_demand': 0.0}
2021-11-24 20:51:39 INFO (MainThread) [ramses_rf.message] || BDR:164839 | HGI:136212 | RP | actuator_cycle   |      || {'modulation_level': 0.0, 'actuator_countdown': 232, 'cycle_countdown': 232, '_unknown_0': 'FF'}
2021-11-24 20:51:40 INFO (MainThread) [ramses_rf.devices] DHW msg = None
2021-11-24 20:51:40 INFO (MainThread) [ramses_rf.devices] DHW msg = None
2021-11-24 20:51:41 INFO (MainThread) [ramses_rf.message] || DHW:046786 |            |  I | dhw_temp         |      || {'temperature': 40.01}
2021-11-24 20:51:41 DEBUG (MainThread) [ramses_rf.devices]  I --- 07:046786 --:------ 07:046786 1260 003 000FA1 < handling (00)
2021-11-24 20:51:41 INFO (MainThread) [ramses_rf.message] || CTL:185426 | HGI:136212 | RP | dhw_temp         |      || {'temperature': 40.01}
2021-11-24 20:51:44 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=sensor.wind_update_time, old_state=<state sensor.wind_update_time=1637787077; friendly_name=Wind Update Time @ 2021-11-24T20:51:16.849216+00:00>, new_state=<state sensor.wind_update_time=1637787105; friendly_name=Wind Update Time @ 2021-11-24T20:51:44.852169+00:00>>
2021-11-24 20:51:44 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=sensor.wind_last_updated, old_state=<state sensor.wind_last_updated=2021-11-24 20:51:17; friendly_name=wind_last_updated, device_class=timestamp @ 2021-11-24T20:51:16.850862+00:00>, new_state=<state sensor.wind_last_updated=2021-11-24 20:51:45; friendly_name=wind_last_updated, device_class=timestamp @ 2021-11-24T20:51:44.854101+00:00>>
2021-11-24 20:51:47 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=sensor.cave_update_time, old_state=<state sensor.cave_update_time=1637787074; friendly_name=Cave Update Time @ 2021-11-24T20:51:14.223782+00:00>, new_state=<state sensor.cave_update_time=1637787107; friendly_name=Cave Update Time @ 2021-11-24T20:51:47.224046+00:00>>
2021-11-24 20:51:47 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=sensor.cave_last_updated, old_state=<state sensor.cave_last_updated=2021-11-24 20:51:14; friendly_name=cave_last_updated, device_class=timestamp @ 2021-11-24T20:51:14.225480+00:00>, new_state=<state sensor.cave_last_updated=2021-11-24 20:51:47; friendly_name=cave_last_updated, device_class=timestamp @ 2021-11-24T20:51:47.225743+00:00>>
2021-11-24 20:51:49 INFO (MainThread) [ramses_rf.devices] DHW msg = None

[bluediamond84 (bluediamond)]

@zxdavb

support for Mk1 evo & improved support for HCW82s – awaiting new release to test

Version 0.16.16 is working. I see temperature states in the climate sensors now

[zxdavb (David Bonnes)]

@bluediamond84

Version 0.16.16 is working

Please send me another packet log to confirm things are as expected.

[Huppeldeflut (Kees)]

David,

I’m monitoring the packets with a second evofw3 as a sniffer and see that the evofw3 that I’m using as HGI is missing almost all packets from coming from my HR92 that is in the attic.
The controller it self can receive the packets, but the evofw3 (even when directly next to the controller) is missing all packet coming from the HR92 in the attic

I already tried moving the evofw3 around the house and the only spot I can find with reception for all EvoHome devices is somewhere in a spot where you don’t want a rpi
I also tuned both evofw3 sticks and they are receiving the same packets when they are close to each other.

Clearly the pigtail antenna is not the best recipient

While I’m waiting for a stick with a SMA connector and a external antenna, I was thinking of building a simple repeater that filters only the packets coming from the problematic HR92 and injecting these some how in to the Ramses_rf module.

Is there a option to inject packets to ramses_rf with a command?