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

So to be clear, I dont “believe” I can now go backwards due to python incompatiblity, according to AI chat. So my option is best to wait it out. Are you suggesting that v56 may work for Evohome, or thats its an unknown at this stage? Also AI chat pointed out that I have a zone 00 which apparently could be throwing it off, is that likely? Thanks again.

1 Like

Egbert, are you advising NOT to update to Release 0.56.0. I only run it for EvoHome.

v0.55.2 in stable for me as an Evohome user. However, the responsiveness of set point changes are incredibly slow.

First impressions of Ramses RF 0.56.0, just out in HACS, are looking good for both HVAC and evohome/CH.

Still, do create a backup before the update as any system (configuration) is slightly different.
We’ll post a 24h evaluation next Monday.

I’ve updated to 0.56. unfortunately despite it all looking good and lots of relevant data flowing as before, climates have not returned. Seems like it just isn’t rebuilding the library. Perhaps its a quirk of my setup. If packet log of interest its here 2026-04-04T16:06:13.324664 # ramses_tx 0.56.02026-04-04T16:06:13.366329 000 I - Pastebin.com
Thanks

Hi, has anything changed with regards to how the ramses_cc_meesage events work in recent versions? I have my system confugred to raise events matching RP.* 13:.*3EF1 (configured via the UI) but these events haven’t been firing in any version since 0.55.3, so after trying each new version I’ve been reinstalling 0.55.3 because I have a few template entities based on the payload of these messages.

Also my ‘active faults’ entity linked to the Evohome controller is still showing as unavilable for me under version 0.56.0 (and as far as I recall, other recent versions), but it again it is working correctly in version 0.55.3.

Indeed they have, in line with how HA advises to publish events also to the UI. It was mentioned in the 0.55.6 release notes:

  • Use Platform.EVENT to init one Regex_Match and one Remote_Learn event
  • These published events can be selected from the Entities list in the Automations UI (search for regex)
  • in REM.learn_cmd, replace bus listener by async_track_state_change_event helper
  • Updates to the Regex in the Config UI are immediately applied to the callback filter
  • Move async_register_domain_events() and the message callback from init.py to event.py

New Regex event

You no longer directly listen to the even bus, but watch for change events on the event.ramses_cc_regex_event object.

Example how to use it from the UI:

Fill in the Ramses RF > Config > Advanced > Regex as e.g. PR.* 29

Create/paste this Automation:

alias: Regex Match alert
description: Saw a msg matching the regex
triggers:
  - entity_id:
      - event.ramses_cc_regex_event
    trigger: state
conditions: []
actions:
  - action: notify.mobile_app_myphone
    metadata: {}
    data:
      message: >-
        Regex 29 RP:  "{{ state_attr( 'event.ramses_cc_regex_event',
        'extra_data')['code'] | default('N/A') }}"
      title: A Regex Match
mode: single

It will send you an alert every time a 29: fan sends a (changed) RP Message. Handy if it is rare. You can also add a Code to the Regex.

Thanks very much, I’ve successfully recreated all my template entities and automations based on this.

I’m getting the active faults entity reporting as ‘unknown’, although this seems to be a known issue mentioned on https://github.com/ramses-rf/ramses_cc/issues/583.

Ramses RF 0.56.1 contains some Heat fixes and a new logger.
To complete the 0.56.1 setup after restart, open HA > Integration > Ramses RF > PacketLog tab and click Submit.

Everything should load instantly.

Same issue for me, when updating from 55.3 to 56.1 fake sensors do not update the evohome thermostat anymore and thus the temperature of the climate entities freezes. On the physical thermostate itself they are not available.

for my simple setup and automations version 0.56.1 is working perfectly

@davidtja Thanks for your logs.
I created issue 588 to track this on GitHub. Some fixes in 0.56.2

Ok great, ill update each new fix and report back if I get the climate entity. Many thanks.

0.56.2 has the same issue. I guess there is progress because I don’t get any more template errors or errors using the put_room_temperature action. Also the faked temperature sensor in Ramses itself does update to the temperature you put there, but the zone temperature on the display or in HA does not change.

On the image: Ramses zone showing 21.5
Ramses faked sensor shwoing 9.5 after performing the put temperature action, also in the image.

1 Like

Word of warning: 0.56.2 did NOT allow me to downgrade to 0.55.3 or 0.55.2. It completely shat the bed. Lucky for me I had a back-up from 2 hours ago, but be warned!

Ramses RF 0.56.3 uses a new config v2 format and fixes more evohome crashes.

Here are some hints to go back. Glad you had a backup.

1 Like

Tnx, missed that :sweat_smile:

Hey, I’m not sure if this is a known issue but since I’ve upgraded to 0.56.3 my thermostats periodically show as “off” when they should be heating, I’ve seen this on earlier 0.56.x versions as well but I thought it had gone away. Is this a known issue? I checked GitHub but I can’t see this mentioned specifically like this. I reload of Ramses cc brings everything back to life but I breaks my automations until the reload happens.

Happy to input if there’s an exiting issue or I can raise a new issue if I’m the only one seeing this.

Thanks

@spencerwebb189 If you are now running 0.56.3, can you try Ramses RF 0.56.5 - with Debug logging turned On?
Please copy your system log from startup to a new ramses_cc issue.

A lot of structural plumbing has been rebuilt in the ramses_rf library over the weekend to prevent silent crashes, especially for Heat/evohome.

For HVAC systems I recommend updating to 0.56.5 anyway, as the Clear Cache issue has been fixed in ramses_cc.

Ok great I’ve upgraded. I’ll enable debug logging, do I need to leave it on until the issue happens again (if it does) or just collect a sample. The issue was previously occuring once every 24 hours or so.