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

So is the ramses_esp Wiki what you are looking for?

Fixes and enhancements, including for MQTT, in RAMSES RF 0.51.7, just released.

2 Likes

Thanks Egbert for all your work on this integration! :grinning:

I added the schema myself based on what I extracted {{ state_attr(ā€œbinary_sensor.18_140805_statusā€, ā€œknown_listā€) }}
)…although I did try and use the template again recently but didn’t get a response.
I’m also seeing a lot of warning messages in the log, they were always there but the number seems to have increased recently…they aren’t specifically for that zone.

2025-09-26 17:16:01.958 WARNING (MainThread) [ramses_tx.protocol_fsm] <ProtocolContext state=WantRply echo=0418|RQ|01:068717|00, tx_count=1/4>: Invalid state to receive an echo (expecting reply)
2025-09-26 17:16:02.043 WARNING (MainThread) [ramses_tx.protocol_fsm] <ProtocolContext state=WantRply echo=1F41|RQ|01:068717|00, tx_count=1/4>: Invalid state to receive an echo (expecting reply)
2025-09-26 17:16:04.107 WARNING (MainThread) [ramses_tx.protocol_fsm] <ProtocolContext state=WantRply echo=3EF1|RQ|13:094634, tx_count=1/4>: Invalid state to receive an echo (expecting reply)
2025-09-26 17:16:05.129 WARNING (MainThread) [ramses_tx.protocol_fsm] <ProtocolContext state=WantRply echo=2E04|RQ|01:068717, tx_count=1/4>: Invalid state to receive an echo (expecting reply)
2025-09-26 17:16:15.367 WARNING (MainThread) [ramses_tx.protocol_fsm] <ProtocolContext state=WantRply echo=2349|RQ|01:068717|07, tx_count=1/4>: Invalid state to receive an echo (expecting reply)
2025-09-26 17:16:15.525 WARNING (MainThread) [ramses_tx.protocol_fsm] <ProtocolContext state=WantRply echo=2349|RQ|01:068717|05, tx_count=1/4>: Invalid state to receive an echo (expecting reply)
2025-09-26 17:16:32.388 WARNING (MainThread) [ramses_tx.protocol_fsm] <ProtocolContext state=WantRply echo=2349|RQ|01:068717|00, tx_count=1/4>: Invalid state to receive an echo (expecting reply)
2025-09-26 17:16:33.241 WARNING (MainThread) [ramses_tx.protocol_fsm] <ProtocolContext state=WantRply echo=2349|RQ|01:068717|0A, tx_count=1/4>: Invalid state to receive an echo (expecting reply)
2025-09-26 17:16:38.100 WARNING (MainThread) [ramses_tx.protocol_fsm] <ProtocolContext state=WantRply echo=3EF1|RQ|13:112203, tx_count=1/4>: Invalid state to receive an echo (expecting reply)
2025-09-26 17:16:49.893 WARNING (MainThread) [ramses_tx.protocol_fsm] <ProtocolContext state=WantRply echo=3EF1|RQ|13:094634, tx_count=1/4>: Invalid state to receive an echo (expecting reply)
2025-09-26 17:16:49.931 WARNING (MainThread) [ramses_tx.protocol_fsm] <ProtocolContext state=WantEcho cmd_=3EF1|RQ|13:094634, tx_count=1/4>: Invalid state to receive a reply (expecting echo)
2025-09-26 17:16:50.409 WARNING (MainThread) [ramses_tx.protocol_fsm] <ProtocolContext state=WantRply echo=2349|RQ|01:068717|09, tx_count=1/4>: Invalid state to receive an echo (expecting reply)
2025-09-26 17:16:50.490 WARNING (MainThread) [ramses_tx.protocol_fsm] <ProtocolContext state=WantRply echo=0008|RQ|13:112203, tx_count=1/4>: Invalid state to receive an echo (expecting reply)
2025-09-26 17:17:23.669 WARNING (MainThread) [ramses_tx.protocol_fsm] <ProtocolContext state=WantRply echo=0008|RQ|13:094634, tx_count=1/4>: Invalid state to receive an echo (expecting reply)
2025-09-26 17:17:50.088 WARNING (MainThread) [ramses_tx.protocol_fsm] <ProtocolContext state=WantRply echo=3EF1|RQ|13:094634, tx_count=1/4>: Invalid state to receive an echo (expecting reply)
2025-09-26 17:18:49.788 WARNING (MainThread) [ramses_tx.protocol_fsm] <ProtocolContext state=WantRply echo=1260|RQ|01:068717|00, tx_count=1/4>: Invalid state to receive an echo (expecting reply)
2025-09-26 17:18:50.407 WARNING (MainThread) [ramses_tx.protocol_fsm] <ProtocolContext state=WantRply echo=3EF1|RQ|13:094634, tx_count=1/4>: Invalid state to receive an echo (expecting reply)
2025-09-26 17:18:57.980 WARNING (MainThread) [ramses_tx.protocol_fsm] <ProtocolContext state=WantRply echo=3EF1|RQ|13:079345, tx_count=1/4>: Invalid state to receive an echo (expecting reply)
2025-09-26 17:19:09.448 WARNING (MainThread) [ramses_tx.protocol_fsm] <ProtocolContext state=WantRply echo=1100|RQ|01:068717|FC, tx_count=1/4>: Invalid state to receive an echo (expecting reply)

I couldn’t find any documentation that explained why they might occur.

I see those warnings too (sporadically though).

When you say ā€˜template’ and ā€˜no response’, you mean a template_sensor and a reply from your system? Or something else entirely?

When you go to HA > Integrations > Ramses RF, click on the HGI > Gateway Status sensor and expand Attributes at the bottom, there is your active system config. Anything special to report?

I run HA on a synology/docker as well, and for some versions you cannot directly use USB without some tricks. But there are some videos on how to do this.
But i understand you are using wifi. So do I.
To setup the esp, first connect it to your compu with USB.
Make sure you get the timezones in your esp right.
I use eclipse-mosquitto as my MQTT broker (also on the nas, in docker)
I also run cturra/ntp server in docker.

mqtt broker mqtt://NAS:1883
sntp server pool.ntp.org
timezone CET

And follow the steps closely as described in the wiki Egbert mentioned.

I managed to get it working with some help from chatgpt. Thanks all… now learning to use it

When you say ā€˜template’ and ā€˜no response’, you mean a template_sensor and a reply from your system? : Yes
When you go to HA > Integrations > Ramses RF, …there is your active system config. Anything special to report? No, the offending zone is defined the same as the others
I see those warnings too (sporadically though).I’m seeing about 250 per hour, so would be good to try and track down the issue.

Still wondering where your unique (to me) class name is coming from. Instead of:
class: TRV
yours are:
class: radiator_valve

Does anyone else recognize that class name?