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

Share your Projects!
1910

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
1911

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.

1912

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

1913

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

1914

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:

image

1915

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

1916

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.

image
image1125×214 62.5 KB

1917

Missing packets for that long should result in unavailable…

1918

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

1919

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.

1920

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.

1921

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

1922

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

1923

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
1924

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>>```
1925

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
1926

Hmmm… It shouldn’t be doing that - the packet at 09:33 should still be valid at 09:59…

So is ramses_rf getting an invalid packet after 09:33? Or is it invalidating the one from 09:33?

Full set of please - let it run for a while first.

1927

This is easy to fix - just let me know the answer to my questions, and a packet log for QA:

|| CTL:024170 | HGI:009231 | RP | system_zones     | 0008 || {'_device_class': '08', 'zone_mask': [0, 0, 0, 0, 0, 0, 0, 0], 'zone_type': 'radiator_valve'}
1928

I have/had a spare TRV in my spares box, so I used this.

10:51 - rebound both existing, at the same time, successfully.
10:54 - restarted HA, with restore false
11:00 - schema still showing null for zone 00
11:08 - bound 3rd on its own to zone 00, ID seems to be 04:055488, controller shows 3 actuators bound for the zone
11:12 - restarted HA again, restore false
11:18 - devices became available in HA, packet log copied at this point

Config below:

evohome_cc:
  restore_state: false
  serial_port: 
    port_name: /dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0
    baudrate: 57600
  packet_log: 
    file_name: /config/packet.log
    rotate_backups: 3
  ramses_rf:
   enforce_known_list: true
   max_zones: 8
  schema:
    controller: 01:050858
  known_list:
    - 01:050858
    - 04:055594
    - 04:055596
    - 04:055510
    - 04:055514
    - 04:055480
    - 04:055506
    - 04:055486
    - 04:055482
    - 04:055600
    - 07:014869
    - 13:215029
    - 13:246213
    - 22:245508
    - 22:245512
    - 22:245517

Schema shows:

schema:
  system:
    heating_control: null
  orphans: []
  stored_hotwater:
    hotwater_sensor: '07:014869'
    hotwater_valve: '13:215029'
    heating_valve: '13:246213'
  underfloor_heating: {}
  zones:
    '00':
      _name: Living Room
      heating_type: radiator_valve
      sensor: '22:245508'
      devices:
        - '22:245508'
      _sensor: '22:245508'
      _actuators: null

Packet log:

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?

P.S. Should heating_valve be under stored_hotwater?

1929

There are no DHW packets in the logs between those two. Logs are on their way.

Though it is interesting that the two packets have different styles of output. What is the bit after the #, and there is also a missing number after the timestamp.

2021-11-24T09:33:14.918106 ...  I --- 07:046786 --:------ 07:046786 1260 003 000709 # 1260| I|07:046786
2021-11-24T09:59:05.478563 059  I --- 07:046786 --:------ 07:046786 1260 003 000709