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

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.

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

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.

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.

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?

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

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.

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).

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

I will add this fix.

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.

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.

@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!

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?

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.

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

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

Is it an actual Honeywell HGI80 or an evofw3 device?

I’m currently running only one instance with HGI80

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.

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.

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

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.

Version 0.16.16 just released.

@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.

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

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

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

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 :frowning:

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 :frowning:
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 :innocent:

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?