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

EgbertB · September 25, 2025, 4:33pm

So is the ramses_esp Wiki what you are looking for?

EgbertB · September 25, 2025, 9:12pm

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

galaxy_explorer · September 26, 2025, 8:29am

Thanks Egbert for all your work on this integration!

PaulHo · September 26, 2025, 4:18pm

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.

EgbertB · September 26, 2025, 4:29pm

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?

Willem70 · September 27, 2025, 7:11am

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.

Tim_Br · September 27, 2025, 2:25pm

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

PaulHo · September 28, 2025, 3:42pm

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.

EgbertB · September 28, 2025, 8:09pm

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?

galaxy_explorer · September 30, 2025, 9:16pm

Hey Egbert, I am running the latest release and I have noticed the default behaviour on the temperature setpoint has changed from “temporary” mode/preset to “permanent” mode. I believe this change was introduced during the recent fix Cannot create a temporary temperature override via the UI climate control (Evohome) · Issue #297 · ramses-rf/ramses_cc · GitHub

The old behaviour was that when you changed the temperature without selecting the preset/mode it would use the “temporary” mode be default.

However, since this change, it now defaults to “permanent”. I believe the old behaviour of “temporary” should be used.

EgbertB · October 1, 2025, 6:44am

Yes, that is the issue/change. Peter’s evohome didn’t pick up the next scheduled change, hence the request.
What Controller do you have that responds as you describe? Please enter that in the issue, which I reopened.

Tchirana · October 3, 2025, 6:06pm

@galaxy_explorer can you share the yaml file for that dashboard? it looks extremly good.

galaxy_explorer · October 3, 2025, 6:49pm

The images above are from the stock thermostat card that comes with HA. However, I have created a separate zone card which you can find here HA Custom Cards by @Galaxy Explorer · ramses-rf/ramses_cc Wiki · GitHub

Tchirana · October 4, 2025, 6:52am

@galaxy_explorer Hello. So the card on the left side is the stock ha and one on the right is your own, correct ?. But both are using ramses rf not honeywell integration. I tried the one on wiki but my devices in ramses were totally screwed so it will take some time until I retest dincevI just ordered a new ESP adaptor to work with ranses rf. I’ll keep you postedcas I test. Thaks a lot.

Tim_Br · October 4, 2025, 4:37pm

Does anyone know if it is possible to see the individual position of the actuators of an hcc100?

EgbertB · October 5, 2025, 8:59pm

Just released Ramses RF 0.51.8.
Thanks for the PRs.

Note: the ramses_cc custom integration requires HA 2025.10.0 or later. Please check the release notes for details.

EgbertB · October 7, 2025, 8:18pm

Fixed in ramses_cc 0.51.8

galaxy_explorer · October 7, 2025, 9:03pm

Not implemented. Reply from the previous code owner below.

SealineF43 · October 10, 2025, 12:02pm

I am trying to set the Hot Water to on for 30 minutes but I am getting error messages when I put the duration in saying that duration is not allowed.
Here is the code that works and sets the HW to Boost for the default time of one hour:


alias: Hot Water Boost
description: Hot Water Boost
triggers: []
conditions: []
actions:
  - action: ramses_cc.set_dhw_boost
    target:
      device_id: fd84d231040f8fa6d0ec9814025ca1f5
mode: single

Where am I going wrong?

galaxy_explorer · October 10, 2025, 5:05pm

I don’t believe it’s supported. It uses the HA water heater entity documentation here. You can test the service options in the Developer Tools ./developer-tools/action

The solution is to create a simple automation with a time delay which turns it off after 30 minutes.

actions:
  - data:
      entity_id: water_heater.dhw_controller
      operation_mode: on
    action: water_heater.set_operation_mode
  - delay:
      hours: 0
      minutes: 30
      seconds: 0
      milliseconds: 0
  - data:
      entity_id: water_heater.dhw_controller
      operation_mode: auto
    action: water_heater.set_operation_mode