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

iMiMx · November 23, 2021, 2:17pm

Did you try rebinding these? I was seeing the same, only 1 actuator listed but both devices listed.

Tried rebinding both TRVs to the zone, then ended up with … no TRVS listed

    '00':
      _name: Living Room
      heating_type: radiator_valve
      sensor: '22:245508'
      devices:
        - '22:245508'
      _sensor: '22:245508'
      _actuators: null

TRV binding was a success, repeated it multiple times - both individually and both at once. They both ‘work’ …not sure if this is a code bug, or some other oddity. Ran out of time to play for logs etc, the Australian gets annoyed when I mess with the heating at this time of year.

… and, yup, I set restore_state: false

… do device IDs change when rebinding? :-/ Edit: Nope.

… tried deleting and recreating the zone, re-binding both TRVs and the DT92E, still the same. Most odd.

zxdavb · November 23, 2021, 4:45pm

I would have to see the packet log…

For various reasons, I don’t run a zone “00” here - I wonder if that has something to do with it…

Lloyd · November 23, 2021, 5:00pm

Yes. I unbound the TRVs, deleted the zones, and recreated them. Schema now looks ok. (And I do have a zone 0.)

iMiMx · November 23, 2021, 5:57pm

I’m not sure I had a choice - I just deleted the zone, then added another one and it recreated (presumably) on the first free contiguous zone number.

Attached below packet log is from midnight, i.e today, so should contain the before-deleting-the-zone, with only 1 actuator listed on zone 0, then a few attempts at rebinding and ending up with ‘null’

Hopefully I might get some time to play again tomorrow. From an evohome point of view, the TRVs are operating, the DT92E is the sensor, all seems ok from that point of view.

Lloyd · November 23, 2021, 6:31pm

I’ve just rebooted (17:51), and intially I had a DHW temperature value (from sensor.07_046786_temperature). When I next looked, probably around 18:10, the sensor was unavailable, and the last change was recorded at 18:06. If I look in the packet.log, filtered for what I think are the packets from the DHW sensor reporting temperature, I see the following. So it looks like temperature readings were being received.

2021-11-23T17:51:23.846399 ...  I --- 07:046786 --:------ 07:046786 1060 003 00FF01 # 1060| I|07:046786
2021-11-23T17:51:23.881375 ...  I --- 07:046786 --:------ 07:046786 1260 003 0016FF # 1260| I|07:046786
2021-11-23T18:02:44.326070 062  I --- 07:046786 --:------ 07:046786 1260 003 001684
2021-11-23T18:06:29.353990 062  I --- 07:046786 --:------ 07:046786 1260 003 00161C
2021-11-23T18:11:29.391768 069  I --- 07:046786 --:------ 07:046786 1260 003 0015A5
2021-11-23T18:14:44.415609 061  I --- 07:046786 --:------ 07:046786 1260 003 00153D
2021-11-23T18:20:29.458360 061  I --- 07:046786 --:------ 07:046786 1260 003 0014D5

Are you interested in seeing the packet and HA logs for this? I have these log settings:

  logs:
    homeassistant.core: debug  
    ramses_rf.message: info   
    ramses_rf.protocol.message: info
    evohome_rf.packet_log: info

zxdavb · November 23, 2021, 6:57pm

So, the relevant packet should be 6, 12, 18, 24 bytes long… Every TRV will add another 6 bytes.

For your system - the only time I’ve ever seen it before now - it goes from 6 to 11 bytes when you add the second TRV!

But now I’ve looked - there are (only) 3 systems doing this (I’ve got logs from many, many systems):

1970-01-01T01:00:00.000000 053 RP --- 01:051477 18:013109 --:------ 000C 011 02000028909F00001186E7
2021-11-18T11:41:06.666720 057 RP --- 01:069616 18:205592 --:------ 000C 011 010800121B540800121B52
2021-11-18T11:41:06.738780 049 RP --- 01:050858 18:141846 --:------ 000C 011 00000010D92A000010D8DA

So at one TRV, this packet would be valid, but add a second TRV and its payload becomes invalid.

zxdavb · November 23, 2021, 8:08pm

@iMiMx Is there any chance you could capture the creation of a zone with 3 TRVs, so I can see exactly what’s going on? Specifically, restart HA after creating such a zone, and have restore_state: false.

zxdavb · November 23, 2021, 8:10pm

@Lloyd is your issue with the DHW sensor reliably reproducible / recurrent?

Lloyd · November 23, 2021, 8:32pm

Probably not reproducible in the true sense (I don’t know when it will have a value, and then become unavailable), but it is unavailable more often than it is. And whenever I look, the packets are being received. Graph for last 48 hrs:

zxdavb · November 23, 2021, 8:41pm

No, I think we can work with that. Is it the same for something that would send pkts more often, like a relay?

Lloyd · November 23, 2021, 9:17pm

I certainly think I am missing relay packets. If you look at the plot below, the pink line is a crude temperature sensor on the boiler bypass (ignore the sharp drops where there is a data point lost and the filtering does not quite work). There should be a correlation between it, and the green heating relay line, but as you can see, there are periods when the green peaks are missing. What I can’t tell you at the moment is if the relay sensor goes unavailable, or whether it just does not record the changes. I’ll try and keep an eye on it tomorrow.

zxdavb · November 23, 2021, 10:01pm

Missing packets for that long should result in unavailable…

zxdavb · November 23, 2021, 11:26pm

@Lloyd Please run version ~~0.16.13~~ 0.16.14 - it has some DHW sensor-specific tricks.

Please report any changes you notice, and keep an eye on your logs via the HA web UI.

Lloyd · November 24, 2021, 8:23am

Anything specific you are after from the logs? And can you confirm that the log settings I used previously are the ones you need for this.

zxdavb · November 24, 2021, 8:59am

The logging I want to see will be an `logger.ERROR``-level entry: you want miss it.

Other than that, see this post, and - if you like - you can add:

    ramses_rf.devices: info

The changes I made are only for the DHW sensor.

zxdavb · November 24, 2021, 9:12am

Oh, and you should make the config change that I PM’d to you, to.

phdelodder · November 24, 2021, 9:41am

@zxdavb moving the HGI80 closer to the controller, would that increase the reliability?

bluediamond84 · November 24, 2021, 10:09am

Running 0.16.14 getting these AssertionError. I noticed my climate sensors don’t get the attribute zone_idx anymore.

2021-11-24 10:17:51 WARNING (MainThread) [ramses_rf.protocol.frame]  I 007 03:201565 --:------ 03:201565 30C9 003 01073A # Expecting payload index to be 00
2021-11-24 10:17:51 ERROR (MainThread) [ramses_rf.protocol.transport] Exception in callback to message layer
Traceback (most recent call last):
  File "/srv/homeassistant/lib/python3.9/site-packages/ramses_rf/protocol/transport.py", line 393, in _pkt_received
    self._callback(pkt)  # only wanted PKTs to the MSG transport's handler
  File "/srv/homeassistant/lib/python3.9/site-packages/ramses_rf/protocol/protocol.py", line 181, in _pkt_receiver
    msg = Message(self._gwy, pkt)  # trap/logs all invalid msgs appropriately
  File "/srv/homeassistant/lib/python3.9/site-packages/ramses_rf/protocol/message.py", line 128, in __init__
    self._payload = self._validate(self._pkt.payload)  # ? raise InvalidPacketError
  File "/srv/homeassistant/lib/python3.9/site-packages/ramses_rf/protocol/message.py", line 388, in _validate
    return result if isinstance(result, list) else {**self._idx, **result}
  File "/srv/homeassistant/lib/python3.9/site-packages/ramses_rf/protocol/message.py", line 240, in _idx
    assert self._pkt._idx == "00", "What!! (00)"
AssertionError: What!! (00)

After running the system for a hour, I noticed that the almost every sensor isn’t updated anymore with new information. Only the heat_demand of my HCE80, the schema en config sensor are updated.

Also getting a warning on corrupt payload. Followed up by a Coding error

2021-11-24 09:30:56 WARNING (MainThread) [ramses_rf.protocol.message] RP --- 01:024170 18:009231 --:------ 0005 003 000800 < Corrupt payload: Payload doesn't match '^00[01][0-9A-F]{5}$': 000800 (will be ignored)
2021-11-24 09:30:56 ERROR (MainThread) [ramses_rf.protocol.message] RP --- 01:024170 18:009231 --:------ 0005 003 000800 << Coding error: IndexError(index out of range)
Traceback (most recent call last):
  File "/srv/homeassistant/lib/python3.9/site-packages/ramses_rf/protocol/message.py", line 358, 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 237, in parser_0005
    return _parser(payload)
  File "/srv/homeassistant/lib/python3.9/site-packages/ramses_rf/protocol/parsers.py", line 218, in _parser
    zone_mask = flag8(seqx[4:6], lsb=True) + flag8(seqx[6:8], lsb=True)
  File "/srv/homeassistant/lib/python3.9/site-packages/ramses_rf/protocol/helpers.py", line 124, in flag8
    return [(bytes.fromhex(byte)[0] & (1 << x)) >> x for x in range(8)]
  File "/srv/homeassistant/lib/python3.9/site-packages/ramses_rf/protocol/helpers.py", line 124, in <listcomp>
    return [(bytes.fromhex(byte)[0] & (1 << x)) >> x for x in range(8)]
IndexError: index out of range

Lloyd · November 24, 2021, 10:45am

Not really seeing any change (concentrating just on DHW). HA restart at 09:33. Noticed sensor was unavailable at 10:22, and last change was recorded at 9:59. Nothing obvious in the logs at ERROR level.

I did think this was interesting:

9:33 data packet. → core debug shows old_state=<state sensor.07_046786_temperature=unavailable, new_state=<state sensor.07_046786_temperature=18.01

9:59 data packet. → core debug shows old_state=<state sensor.07_046786_temperature=18.01, new_state=<state sensor.07_046786_temperature=unavailable

2021-11-24 09:33:14 INFO (MainThread) [ramses_rf.message] || DHW:046786 |            |  I | dhw_temp         |      || {'temperature': 18.01}
2021-11-24 09:33:25 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=sensor.07_046786_temperature, old_state=<state sensor.07_046786_temperature=unavailable; restored=True, state_class=measurement, supported_features=0, device_class=temperature, unit_of_measurement=°C, friendly_name=07:046786 (temperature) @ 2021-11-24T09:33:16.786371+00:00>, new_state=<state sensor.07_046786_temperature=18.01; state_class=measurement, controller_id=01:185426, device_id=07:046786, domain_id=FA, domain_name=Stored HW, unit_of_measurement=°C, friendly_name=DHW Temperature, device_class=temperature @ 2021-11-24T09:33:25.669336+00:00>>

2021-11-24 09:59:05 INFO (MainThread) [ramses_rf.message] || DHW:046786 |            |  I | dhw_temp         |      || {'temperature': 18.01}
2021-11-24 09:59:06 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=sensor.07_046786_temperature, old_state=<state sensor.07_046786_temperature=18.01; state_class=measurement, controller_id=01:185426, device_id=07:046786, domain_id=FA, domain_name=Stored HW, unit_of_measurement=°C, friendly_name=DHW Temperature, device_class=temperature @ 2021-11-24T09:33:25.669336+00:00>, new_state=<state sensor.07_046786_temperature=unavailable; state_class=measurement, unit_of_measurement=°C, friendly_name=DHW Temperature, device_class=temperature @ 2021-11-24T09:59:06.666966+00:00>>```

zxdavb · November 24, 2021, 10:49am

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?

In any case, please send me a packet lot that includes a start up of HA - I don’t need anything else for now.

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.

Every other 0005 packet I’ve seen from an evohome controller is of this form, below - the payload is 1 byte longer:

RP --- 01:054173 18:006402 --:------ 0005 004 00080100

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

I think I can justify changing the code so this packet is parseable, but:

are you saying it worked before, but doesn’t now (this parser hasn’t changed for years, so your controller must have changed its behaviour?)
I will need a packet log also