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

Hi David,

Thank you for your advise, altough I also think the wifi reception is fine I relocated the RAMSES_ESP to be sure.

Also when I try to change the temperature from within HA I get the error message below, do you have an suggestion how to solve this?

Logger: homeassistant.components.websocket_api.http.connection
Bron: components/websocket_api/commands.py:287
integratie: Home Assistant WebSocket API (documentatie, problemen)
Eerst voorgekomen: 10:11:01 (5 gebeurtenissen)
Laatst gelogd: 20:30:10

[139694164675600] Preset mode is not valid. Valid preset modes are: none, temporary, permanent
[139694369833744] Preset mode is not valid. Valid preset modes are: none, temporary, permanent
[139694165112096] Preset mode is not valid. Valid preset modes are: none, temporary, permanent
[139694164676032] Preset mode is not valid. Valid preset modes are: none, temporary, permanent
[139694164676032] Preset mode is not valid. Valid preset modes are: none, away, custom, home, eco

Dear users,
The setup is now working very well since 1 month.
I have a good visibility of total gas consumption and individually heat demand.
Does anybody have an idea to know the gas consumption by room ?
For example :
Gas = 0.1 mÂł
Demand Room 1 = 100%
Demand Room 2 = 50 %
For each minutes/second I need to calculate : 150% = 0.1 mÂł
Room 1 = 0.1 / 150 x 100 = 0.0666
Room 2 = 0.1 / 150 x 50 = 0.0333
Is it possible in HA to do such computing each seconds/minutes ?
Thank A lot for your advises.

Or with more precision :

Maybe you can create a helper or helpers, based on combined formulas?

Hi David,

A different spot more in the neigbourhood of the WiFi AP for the RAMSES_ESP didn’t solve the offline/ online messages in my log. But more annoying is the situation that when I try to change the setpoint, the setpoint goes back to the previous setpoint or I get the message that the preset mode is not valid.

Is this a known issue for the Honeywell Evohome system?

Hi David, hsluis,

For me things are going 2 steps forward, 1 step back.
I disabled the RAMSES_RF integration for a few days, because of the issues and hte flood of mqtt messages. But now I tried to restart it, I get
This error originated from a custom integration.

Logger: custom_components.ramses_cc
Source: custom_components/ramses_cc/__init__.py:100
integration: RAMSES RF (documentation, issues)
First occurred: October 14, 2024 at 11:46:27 AM (15 occurrences)
Last logged: 7:48:40 PM

Failed to set up entry 01J9M0G3D3R1M1GBGG7DNKPJKE (will retry): There is a problem with the serial port: Transport did not bind to Protocol within 9 secs (check config)

So somehow RAMSES_RF is now refusing to connect to my mosquitto mqtt server. I didn’t do anything else than disable the integration and re-enable it again.

For reference: y serial string is:
mqtt://Myusername:Mypassword%[email protected]:1883
(changed the username password obviously, but I left the hash sign in the password)

I do see some messages coming in over MQTT in from RAMSES_ESP in Node-Red:

18/10/2024, 19:46:29[node: debug 13]
RAMSES/GATEWAY/18:017268 : msg.payload : string[7]
"offline"

18/10/2024, 19:46:29[node: debug 13]
RAMSES/GATEWAY/18:017268/info/firmware : msg.payload : string[10]
"ramses_esp"

18/10/2024, 19:46:29[node: debug 13]
RAMSES/GATEWAY/18:017268/info/version : msg.payload : string[5]
"0.4.9"

I also checked the mosquitto logs. They show

2024-10-18 20:11:07: New connection from 192.168.71.10:52761 on port 1883.
2024-10-18 20:11:07: New client connected from 192.168.71.10:52761 as auto-09471882-DF03-4E75-1FF5-816E7FC98D3B (p2, c1, k60, u'Mqtt').

This message pops up every time when I try to restart the RAMSESS_RF. So there seems there is no error on that side of the connection.
Any idea why RAMSES_RF is complaining and refusing to start? I hope we can get this figured out. Any help is welcome. Time for a step forward again :slight_smile:

Regards, Bert

I’m trying to set up the HVAC for my father in law through this. I have it all connected in HA but it I have two main issues:

  1. . It only shows up as devices and not as entities / data or controls. I turned on logging and it does parse quite a lot. However it does throw a parsing error every 20-25 lines.
2024-10-19 11:42:33.448 ERROR (MainThread) [ramses_tx.message]  W --- 29:238228 29:238219 --:------ 4E04 003 00007F < AssertionError()
Traceback (most recent call last):
  File "/usr/local/lib/python3.12/site-packages/ramses_tx/message.py", line 255, in _validate
    result = parse_payload(self)
             ^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/ramses_tx/parsers.py", line 2938, in parse_payload
    result = _PAYLOAD_PARSERS.get(msg.code, parser_unknown)(msg._pkt.payload, msg)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/ramses_tx/parsers.py", line 2766, in parser_4e04
    assert int(payload[4:], 16) < 0x40 or payload[4:] in (
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError
2024-10-19 11:42:33.524 ERROR (MainThread) [ramses_tx.message]  I --- 29:238219 29:238228 --:------ 4E04 003 00007F < AssertionError()
Traceback (most recent call last):
  File "/usr/local/lib/python3.12/site-packages/ramses_tx/message.py", line 255, in _validate
    result = parse_payload(self)
             ^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/ramses_tx/parsers.py", line 2938, in parse_payload
    result = _PAYLOAD_PARSERS.get(msg.code, parser_unknown)(msg._pkt.payload, msg)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/ramses_tx/parsers.py", line 2766, in parser_4e04
    assert int(payload[4:], 16) < 0x40 or payload[4:] in (
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError
2024-10-19 11:42:49.276 INFO (MainThread) [ramses_rf.dispatcher] ||  29:238228 |            |  I | ufc_demand       |      || {'mode': 'heating', 'demand': 0.0}
2024-10-19 11:42:59.307 INFO (MainThread) [ramses_rf.dispatcher] ||            |  29:238219 |  I | opentherm_sync   |      || {'ticker': 20348}
2024-10-19 11:43:05.091 INFO (MainThread) [ramses_rf.dispatcher] ||            |  29:238228 |  I | opentherm_sync   |      || {'ticker': 26576}
2024-10-19 11:43:06.332 INFO (MainThread) [ramses_rf.dispatcher] ||  37:066933 |  37:097904 | RQ | unknown_4401     | (10) || {'last_update_dst': '00', 'time_dst': '1970-09-06 03:56:57', '_unknown_12': '00', 'time_src': None, 'offset': '00', '_unknown_24': '00', 'last_update_src': '00', 'time_dst_receive_src': None, '_unknown_36': '00', 'hops_dst_src': '63'}
2024-10-19 11:43:09.084 WARNING (MainThread) [ramses_tx.message]  W --- 21:033261 29:238228 --:------ 22D0 008 0304001E14030020 < Packet idx is 03, but expecting no idx (00) (0xAB)
2024-10-19 11:43:09.147 WARNING (MainThread) [ramses_tx.message]  I --- 29:238228 21:033261 --:------ 22D0 004 03010000 < Packet idx is 03, but expecting no idx (00) (0xAB)
2024-10-19 11:43:09.258 INFO (MainThread) [ramses_rf.dispatcher] ||  21:033261 |            |  I | actuator_state   | (02) || {'modulation_level': 0.0, '_flags_2': '00', '_flags_3': [0, 0, 0, 0, 0, 0, 0, 0], 'ch_active': False, 'dhw_active': False, 'cool_active': False, 'flame_on': False, '_unknown_4': '02', '_unknown_5': '00'}
2024-10-19 11:43:09.259 INFO (MainThread) [ramses_rf.dispatcher] ||  21:033261 |            |  I | ufc_demand       |      || {'mode': 'heating', 'demand': 0.0}
2024-10-19 11:43:10.031 INFO (MainThread) [ramses_rf.dispatcher] ||  29:238228 |            |  I | message_22d0     |  00  || {'idx': '00', '_flags': [0, 0, 0, 0, 0, 0, 0, 1], 'cool_mode': False, 'heat_mode': False, 'is_active': False, '_unknown': '0000'}
2024-10-19 11:43:12.009 INFO (MainThread) [ramses_rf.dispatcher] ||  29:238228 |            |  I | message_22d0     |  00  || {'idx': '00', '_flags': [0, 0, 0, 0, 0, 0, 0, 1], 'cool_mode': False, 'heat_mode': False, 'is_active': False, '_unknown': '0000'}
2024-10-19 11:43:18.798 INFO (MainThread) [ramses_rf.dispatcher] ||  21:033261 |            |  I | temperature      |      || {'temperature': 21.91}
2024-10-19 11:43:18.953 WARNING (MainThread) [ramses_tx.message]  W --- 21:033261 29:238228 --:------ 22C9 006 03086608CA01 < Packet idx is 03, but expecting no idx (00) (0xAB)
2024-10-19 11:43:18.956 INFO (MainThread) [ramses_rf.dispatcher] ||  21:033261 |            |  I | setpoint_bounds  |      || {'mode': 'heat', 'setpoint_bounds': (21.5, 22.5)}
2024-10-19 11:43:19.011 WARNING (MainThread) [ramses_tx.message]  I --- 29:238228 21:033261 --:------ 22C9 008 0308667FFF010103 < Packet idx is 03, but expecting no idx (00) (0xAB)
2024-10-19 11:43:30.282 INFO (MainThread) [ramses_rf.dispatcher] ||            |  37:066933 |  I | unknown_10e2     |      || {'counter': 47576}
2024-10-19 11:44:16.065 INFO (MainThread) [ramses_rf.dispatcher] ||            |  37:078035 |  I | unknown_10e2     |      || {'counter': 48476}
2024-10-19 11:44:24.593 INFO (MainThread) [ramses_rf.dispatcher] ||  21:063313 |            |  I | temperature      |      || {'temperature': 21.55}
2024-10-19 11:44:24.821 WARNING (MainThread) [ramses_tx.message]  I --- 29:238219 21:063313 --:------ 22C9 008 04076C7FFF010103 < Packet idx is 04, but expecting no idx (00) (0xAB)
2024-10-19 11:44:24.993 INFO (MainThread) [ramses_rf.dispatcher] ||  29:238219 |  29:238228 |  I | hvac_4e01        |      || {'temperatures': [None, 21.55, None, None, None, None, None, None]}
2024-10-19 11:44:25.990 INFO (MainThread) [ramses_rf.dispatcher] ||  29:238219 |  29:238228 |  I | hvac_4e01        |      || {'temperatures': [None, 21.55, None, None, None, None, None, None]}
2024-10-19 11:44:27.001 INFO (MainThread) [ramses_rf.dispatcher] ||  29:238219 |  29:238228 |  I | hvac_4e01        |      || {'temperatures': [None, 21.55, None, None, None, None, None, None]}
2024-10-19 11:44:28.003 INFO (MainThread) [ramses_rf.dispatcher] ||  29:238219 |  29:238228 |  I | hvac_4e02        |      || {'mode': 'heat', 'setpoint_bounds': [None, (19.0, 20.0), None, None, None, None, None, None]}
2024-10-19 11:44:28.996 INFO (MainThread) [ramses_rf.dispatcher] ||  29:238219 |  29:238228 |  I | hvac_4e02        |      || {'mode': 'heat', 'setpoint_bounds': [None, (19.0, 20.0), None, None, None, None, None, None]}
2024-10-19 11:44:29.984 INFO (MainThread) [ramses_rf.dispatcher] ||  29:238219 |  29:238228 |  I | hvac_4e02        |      || {'mode': 'heat', 'setpoint_bounds': [None, (19.0, 20.0), None, None, None, None, None, None]}
2024-10-19 11:45:07.799 INFO (MainThread) [ramses_rf.dispatcher] ||            |  29:238228 |  I | opentherm_sync   |      || {'ticker': 26577}
2024-10-19 11:45:09.806 INFO (MainThread) [ramses_rf.dispatcher] ||            |  29:238219 |  I | opentherm_sync   |      || {'ticker': 20349}
2024-10-19 11:45:16.684 INFO (MainThread) [ramses_rf.dispatcher] ||  21:037015 |            |  I | temperature      |      || {'temperature': 21.25}
2024-10-19 11:45:18.076 WARNING (MainThread) [ramses_tx.message]  I --- 29:238219 21:037005 --:------ 22C9 008 05079E7FFF010103 < Packet idx is 05, but expecting no idx (00) (0xAB)
2024-10-19 11:45:18.785 INFO (MainThread) [ramses_rf.dispatcher] ||  29:238219 |  29:238228 |  I | hvac_4e01        |      || {'temperatures': [None, None, 21.4, None, None, None, None, None]}
2024-10-19 11:45:19.796 INFO (MainThread) [ramses_rf.dispatcher] ||  29:238219 |  29:238228 |  I | hvac_4e01        |      || {'temperatures': [None, None, 21.4, None, None, None, None, None]}
2024-10-19 11:45:20.778 INFO (MainThread) [ramses_rf.dispatcher] ||  29:238219 |  29:238228 |  I | hvac_4e01        |      || {'temperatures': [None, None, 21.4, None, None, None, None, None]}
2024-10-19 11:45:21.786 INFO (MainThread) [ramses_rf.dispatcher] ||  29:238219 |  29:238228 |  I | hvac_4e02        |      || {'mode': 'heat', 'setpoint_bounds': [None, None, (19.5, 20.5), None, None, None, None, None]}
2024-10-19 11:45:22.780 INFO (MainThread) [ramses_rf.dispatcher] ||  29:238219 |  29:238228 |  I | hvac_4e02        |      || {'mode': 'heat', 'setpoint_bounds': [None, None, (19.5, 20.5), None, None, None, None, None]}
2024-10-19 11:45:23.782 INFO (MainThread) [ramses_rf.dispatcher] ||  29:238219 |  29:238228 |  I | hvac_4e02        |      || {'mode': 'heat', 'setpoint_bounds': [None, None, (19.5, 20.5), None, None, None, None, None]}
2024-10-19 11:45:28.168 INFO (MainThread) [ramses_rf.dispatcher] ||  37:078035 |  37:104186 | RQ | unknown_4401     | (10) || {'last_update_dst': '00', 'time_dst': '1970-08-28 03:28:31', '_unknown_12': '00', 'time_src': None, 'offset': '00', '_unknown_24': '00', 'last_update_src': '00', 'time_dst_receive_src': None, '_unknown_36': '00', 'hops_dst_src': '63'}
2024-10-19 11:45:30.278 INFO (MainThread) [ramses_rf.dispatcher] ||            |  37:066933 |  I | unknown_10e2     |      || {'counter': 47577}

I tried adding them as hvac_orphans but I found it hard to distill the devices as I would have guessed to see the CO2 sensor more clearly.

  1. Also adding a faked remote does not make it show up in the devices. Is it required to bind it first or should it show up already before binding?
ramses_cc:
  serial_port: /dev/serial/by-id/usb-Espressif_USB_JTAG_serial_debug_unit_48:27:E2:FF:76:54-if00

  packet_log:
    file_name: packet.log
    rotate_backups: 28
  advanced_features:
    send_packet: true
  ramses_rf:
    enable_eavesdrop: true
    enforce_known_list: false

  restore_cache: true
  orphans_hvac:
    [
      18:226900,
      29:123456,
      29:170931,
      21:033261,
      29:238228,
      37:123456,
      32:082155,
    ]
  known_list:
    18:226900: { class: HGI }
    29:170931: { class: REM }
    29:123456:
      class: REM
      faked: true
      commands:
        away: " I --- 37:123456 32:082155 --:------ 22F1 003 000004"
        low: " I --- 37:123456 32:082155 --:------ 22F1 003 000104"
        medium: " I --- 37:123456 32:082155 --:------ 22F1 003 000204"
        high: " I --- 37:123456 32:082155 --:------ 22F1 003 000304"
        auto: " I --- 37:123456 32:082155 --:------ 22F1 003 000404"
        timer_15mins: " I --- 37:123456 32:082155 --:------ 22F3 007 00020F03040000"
        timer_30mins: " I --- 37:123456 32:082155 --:------ 22F3 007 00021E03040000"
        timer_60mins: " I --- 37:123456 32:082155 --:------ 22F3 007 00023C03040000"

Hi Bert,

In the wiki I see serial_port: “mqtt://mqtt_user:mqtt_p%[email protected]”, maybe you can try if it works?

Best regards,

Patrick

Hoi Patrick,

I thought a bit to late of the obvious: a good reboot… :slight_smile:
I hadn’t changed anything in the serial port settings, so the format ‘should’ be OK.
I have no idea why the integration refused to start.
But fortunately, after the reboot the integration came up OK. So I’m back on the same page as you, with intermittently disappearing devices.

And I am back on the search for this behavior. I changed the USB charger to the RAMSES_ESP from a 0.5A to 1.0A charger, in the hopes that that makes a difference. Unfortunately, it didn’t.

Did you make any progress? I spent some time monitoring the log messages and mqtt messages in Home assistant and Node-Red.

In Home assistant the log is ~99% filled with a steady stream of this kind of warnings.

2024-10-20 17:45:42.344 WARNING (MainThread) [ramses_tx.transport] MqttTransport(QosProtocol(WantEcho, len(queue)=0)): Discarding write (tokens=-0.83)
2024-10-20 17:45:42.846 WARNING (MainThread) [ramses_tx.protocol_fsm] TOUT.. = <ProtocolContext state=WantEcho cmd_=0008|RQ|13:144633, tx_count=1/4>: echo_timeout=0.5
2024-10-20 17:45:44.347 WARNING (MainThread) [ramses_tx.protocol_fsm] TOUT.. = <ProtocolContext state=WantEcho cmd_=3EF1|RQ|13:144633, tx_count=1/4>: echo_timeout=0.5
2024-10-20 17:45:44.664 WARNING (MainThread) [ramses_tx.transport] MqttTransport(QosProtocol(WantEcho, len(queue)=0)): Discarding write (tokens=-0.73)
2024-10-20 17:45:45.166 WARNING (MainThread) [ramses_tx.protocol_fsm] TOUT.. = <ProtocolContext state=WantEcho cmd_=2349|RQ|01:205429|00, tx_count=1/4>: echo_timeout=0.5
2024-10-20 17:45:45.730 WARNING (MainThread) [ramses_tx.protocol_fsm] <ProtocolContext state=WantEcho cmd_=2349|RQ|01:205429|00, tx_count=2/4>: Invalid state to receive a reply (expecting echo)

In Node-Red I set a debug on the mqtt messages from RAMSES/#.
There is a continuous flow of this kind of messages:

{"msg":"RQ --- 18:000730 01:205429 --:------ 30C9 001 00"}
{"msg":"RQ --- 18:000730 01:205429 --:------ 30C9 001 00"}
{"msg":"051 RP --- 01:205429 18:017268 --:------ 2349 007 00070800FFFFFF","ts":"1970-01-01T05:20:32.000897+00:00"}
{"msg":"000 RQ --- 18:017268 01:205429 --:------ 30C9 001 00","ts":"1970-01-01T05:20:32.063977+00:00"}
{"msg":"RQ --- 18:000730 01:205429 --:------ 12B0 001 00"}
{"msg":"000 RQ --- 18:017268 01:205429 --:------ 30C9 001 00","ts":"1970-01-01T05:20:32.126080+00:00"}
{"msg":"000 RQ --- 18:017268 01:205429 --:------ 12B0 001 00","ts":"1970-01-01T05:20:32.188924+00:00"}
{"msg":"RQ --- 18:000730 01:205429 --:------ 0418 003 000000"}
{"msg":"000 RQ --- 18:017268 01:205429 --:------ 0418 003 000000","ts":"1970-01-01T05:20:33.670942+00:00"}
{"msg":"051 RP --- 01:205429 18:017268 --:------ 2349 007 00070800FFFFFF","ts":"1970-01-01T05:20:33.801196+00:00"}
{"msg":"051 RP --- 01:205429 18:017268 --:------ 313F 009 00FC852DD3140A07E8","ts":"1970-01-01T05:20:33.816624+00:00"}

i don’t think this is the place for a full log. But it is available if someone wants it.

Regards,

Bert

Hi Bert,

Glad the reboot did solve the integration start problem, in my logbook I see these errors:

Logger: homeassistant
Bron: /usr/src/homeassistant/homeassistant/runner.py:147
Eerst voorgekomen: 20:02:00 (20 gebeurtenissen)
Laatst gelogd: 20:12:33

Error doing job: Exception in callback Controller._handle_msg(RP — 01:133…AE00080013AC65) (None)
Traceback (most recent call last):
File “/usr/local/lib/python3.12/asyncio/events.py”, line 88, in _run
self._context.run(self._callback, *self._args)
File “/usr/local/lib/python3.12/site-packages/ramses_rf/device/heat.py”, line 336, in _handle_msg
self.tcs._handle_msg(msg)
File “/usr/local/lib/python3.12/site-packages/ramses_rf/system/heat.py”, line 588, in _handle_msg
super()._handle_msg(msg)
File “/usr/local/lib/python3.12/site-packages/ramses_rf/system/heat.py”, line 482, in _handle_msg
self.get_htg_zone(msg.payload[SZ_ZONE_IDX], msg=msg)
File “/usr/local/lib/python3.12/site-packages/ramses_rf/system/heat.py”, line 544, in get_htg_zone
zon._handle_msg(msg)
File “/usr/local/lib/python3.12/site-packages/ramses_rf/system/zones.py”, line 664, in _handle_msg
self._gwy.get_device(dev_id, parent=self)
File “/usr/local/lib/python3.12/site-packages/ramses_rf/gateway.py”, line 417, in get_device
dev.set_parent(parent, child_id=child_id, is_sensor=is_sensor)
File “/usr/local/lib/python3.12/site-packages/ramses_rf/entity_base.py”, line 1072, in set_parent
parent, child_id = self._get_parent(
^^^^^^^^^^^^^^^^^
File “/usr/local/lib/python3.12/site-packages/ramses_rf/entity_base.py”, line 973, in _get_parent
raise exc.SystemSchemaInconsistent(
ramses_rf.exceptions.SystemSchemaInconsistent: 04:160928 (TRV): None cant change parent (01:133689_01 (RAD)_01 to 01:133689_00 (RAD)_00) (hint: try restarting the client library)

And

Logger: ramses_tx.transport
Bron: runner.py:189
Eerst voorgekomen: 20:01:56 (281 gebeurtenissen)
Laatst gelogd: 20:12:45

MqttTransport(QosProtocol(WantEcho, len(queue)=3)): Discarding write (tokens=-0.90)
MqttTransport(QosProtocol(WantEcho, len(queue)=3)): Discarding write (tokens=-0.81)
MqttTransport(QosProtocol(WantEcho, len(queue)=2)): Discarding write (tokens=-0.88)
MqttTransport(QosProtocol(WantEcho, len(queue)=1)): Discarding write (tokens=-0.81)
MqttTransport(QosProtocol(WantEcho, len(queue)=2)): Discarding write (tokens=-0.81)

And

Logger: ramses_tx.protocol_fsm
Bron: runner.py:189
Eerst voorgekomen: 20:01:56 (571 gebeurtenissen)
Laatst gelogd: 20:12:45

TOUT… = : echo_timeout=0.5
TOUT… = : echo_timeout=0.5
TOUT… = : echo_timeout=0.5
TOUT… = : echo_timeout=0.5
TOUT… = : echo_timeout=0.5

Hi David, Patrick,

The errors look very much the same, between mine and Patricks… I now also see a whole bunch of “buffer overrun” errors. That looks like a problem on the intergration side. Maybe this can shed a light on the issue?

Logger: ramses_rf.entity_base
Source: runner.py:189
First occurred: October 20, 2024 at 7:31:53 PM (5350 occurrences)
Last logged: 7:40:17 AM

01:205429_00 (VAL): Failed to send discovery cmd: 2349|RP|01:205429|00: <ProtocolContext state=WantEcho>: Send buffer overflow
01:205429_00 (VAL): Failed to send discovery cmd: 30C9|RP|01:205429|00: <ProtocolContext state=WantEcho>: Send buffer overflow
01:205429 (evohome): Failed to send discovery cmd: 2E04|RP|01:205429: <ProtocolContext state=WantEcho>: Send buffer overflow
13:144633 (BDR): None: Failed to send discovery cmd: 3EF1|RP|13:144633: <ProtocolContext state=WantEcho>: Send buffer overflow
01:205429 (evohome): Failed to send discovery cmd: 0006|RP|01:205429: <ProtocolContext state=WantEcho>: Send buffer overflow

Hello

I use a Honeywell EvoHome controller with THR0924HRT and 2 HCW82 thermostats.
After some confusion with the new configuration via config flow I was able to setup my system.

I have some trouble with the thermostats. They are found and defined in the well known list:

"01:085976":
  class: CTL
"04:240427":
  class: TRV
"03:040558":
  class: HCW
"04:240503":
  class: TRV
"04:240509":
  class: TRV
"03:040559":
  class: HCW
"04:240425":
  class: TRV
"04:240507":
  class: TRV
"04:240423":
  class: TRV
"30:143911":
  class: RFG
"18:018100":
  class: HGI

I read the documentation in the wiki. I’m not sure if I have to configure them in class HCW or THM. The name of the devices starts with THM. Anyway, both classes cause the same problem.
The devices are found but all of their entities are unavailable. The system log shows errors:

Logger: ramses_rf.dispatcher
Source: runner.py:189
First occurred: October 26, 2024 at 13:47:39 (96 occurrences)
Last logged: 12:51:49

I 245 03:040558 --:------ 03:040558 2389 003 02001E < PacketInvalid( I 245 03:040558 --:------ 03:040558 2389 003 02001E < Unexpected code for src (THM) to Tx)
I 000 03:040559 --:------ 03:040559 0002 004 03020105 < PacketInvalid( I 000 03:040559 --:------ 03:040559 0002 004 03020105 < Unexpected code for src (THM) to Tx)
I 000 03:040558 --:------ 03:040558 0002 004 03020105 < PacketInvalid( I 000 03:040558 --:------ 03:040558 0002 004 03020105 < Unexpected code for src (THM) to Tx)
I 246 03:040558 --:------ 03:040558 2389 003 02001B < PacketInvalid( I 246 03:040558 --:------ 03:040558 2389 003 02001B < Unexpected code for src (THM) to Tx)
I 247 03:040558 --:------ 03:040558 2389 003 020191 < PacketInvalid( I 247 03:040558 --:------ 03:040558 2389 003 020191 < Unexpected code for src (THM) to Tx)

I enabled the log output:

2024-10-27T12:40:50.195410 029 RQ --- 30:143911 01:085976 --:------ 0006 001 00
2024-10-27T12:40:50.221788 055 RP --- 01:085976 30:143911 --:------ 0006 004 00050000
2024-10-27T12:41:33.795111 070  I 247 03:040558 --:------ 03:040558 2389 003 020191
2024-10-27T12:41:36.116561 081  I --- 04:240503 --:------ 01:085976 3150 002 0100
2024-10-27T12:41:39.247171 071  I 247 03:040558 --:------ 03:040558 2389 003 020191
2024-10-27T12:41:41.665215 000 RQ --- 18:018100 01:085976 --:------ 0418 003 000000
2024-10-27T12:41:41.687802 056 RP --- 01:085976 18:018100 --:------ 0418 022 004000B0040201000000A618494EFFFFFF700013AB7D

I assume the problem is the value 247. For all other devices, this part of the log is set to “—” but everytime one of the thermostats communicates, this field is set.

How can I fix this and make the thermostats work?

Thank you very much

Unfortunately, HCW thermostats are not fully supported. However, read further…

Define them as THM.

No, it (the sequence number) isn’t.

The errors you are receiving apply only to those packets. All other packets should be processed normally.

Do you have any entities show up OK? Most of them come via packets Tx by the controller.

You don’t generally have any value from the thermostats, other than it is nice to know if their battery is going flat.

@hsluis & @brjhaverkamp

Your issues appear to be due to something going badly at the radio-layer (either 868 MHz, or Wifi/MQTT).

Because ramses_rf is Tx packets without getting the Rx it expects (first an echo (if MQTT), then a reply) in good time, it is re-Tx:

  • echo_timeout=0.5

It will keep re-Tx, but eventually it gives up and moves onto the next queued Tx.

  • QosProtocol(WantEcho, len(queue)=3)

In the meantime, the Tx queue is filling up faster than it is emptying (either via successful Tx, or those timed out), and eventually you get: Send buffer overflow.

For example:

{"msg":"RQ --- 18:000730 01:205429 --:------ 30C9 001 00"}
{"msg":"RQ --- 18:000730 01:205429 --:------ 30C9 001 00"}
{"msg":"051 RP --- 01:205429 18:017268 --:------ 2349 007 00070800FFFFFF","ts":"1970-01-01T05:20:32.000897+00:00"}
{"msg":"000 RQ --- 18:017268 01:205429 --:------ 30C9 001 00","ts":"1970-01-01T05:20:32.063977+00:00"}
{"msg":"RQ --- 18:000730 01:205429 --:------ 12B0 001 00"}
{"msg":"000 RQ --- 18:017268 01:205429 --:------ 30C9 001 00","ts":"1970-01-01T05:20:32.126080+00:00"}

It appears RQ|01:205429|30C9 was Tx twice. Once should have been enough:

{"msg":"RQ --- 18:000730 01:205429 --:------ 30C9 001 00"}
{"msg":"RQ --- 18:000730 01:205429 --:------ 30C9 001 00"}```

… then you get the echo, followed by a second:

{"msg":"000 RQ --- 18:017268 01:205429 --:------ 30C9 001 00","ts":"1970-01-01T05:20:32.063977+00:00"}
{"msg":"000 RQ --- 18:017268 01:205429 --:------ 30C9 001 00","ts":"1970-01-01T05:20:32.126080+00:00"}

… I don’t know if you later get an RQ|01:205429|30C9, as the logs are unsatisfactory for that.

But it is clear the controller is being swamped by the re-Tx.

I would suggest you take MQTT out of the picture, and see about getting it working with the dongle plugged into a USB port on the device running HA.

Your schema does not match reality. This is saying that the ramses_rf believes 04:160928 is in zone 01, but it has just received information that it is in zone 00.

The information appears to have come from a 000C packet, which contains schema data what the controller believes to be true.

Either your schema is wrong, or your system is mis-configured.

Perhaps you could post you configured schema, and a packet log full of your 000C packets for people to comment upon?

Hi David,
Thank you for responding.
Below screenshot of the schema.

No schema then (do you have an OTB?).

This increases the chances your system is misconfigured…

Please provide a packet log, that includes a startup of HA, but with the cached schema/cached packets disabled.

Hi David,

I am using a OpenTherm Central Heating system.

I have a packet log, including the startup of HA with cached schema, but how can I share this?

I hope it is OK for mw to share a few packets here:

> cat 2024-10-27.log | grep -E 'RP.* 000C ... 0108'

… gives (inter alia):

...
2024-10-27T10:04:48.140700 050 RP --- 01:133689 18:227312 --:------ 000C 006 0108001274A0
2024-10-27T16:21:22.667594 052 RP --- 01:133689 18:227312 --:------ 000C 006 010800299C98
...

So, I am confused - the payload changed from 0108001274A0 to 010800299C98 !!!

Did you recently change your system configuration?

To me, it appears you have managed to bind your OTB to zone 01 (zone is named ‘P…k’)! If you process the latter packet, you get this error:

TypeError: for Parent 01:133689_01 (RAD): Actuator 10:105624 (OTB) must be BDR, TRV, UFC

And you have made other changes too?

2024-10-27T10:53:06.767004 051 RP --- 01:133689 18:227312 --:------ 000C 018 0008001274A00008001274AE00080013AC65
2024-10-27T16:20:13.153277 052 RP --- 01:133689 18:227312 --:------ 000C 006 0008001274AE

Hi David,
I’m sorry, I forgot to say that I reset my Evohome system hoping that it would solve the issues.

I’m sorry - all evidence is you’ve made it worse!