Updated version seems to be working well with evohome, thanks for your efforts.
One question on discovery/passive scan. Once the main trvs are discovered, will the unknown status resolve itself without the passive scan being enabled?
TRV states should update status with or without the Passive scan turned on, provided you keep that schema in Config.
If they don’t, we will look into it again.
Thanks to the code contributions, folks.
0.58.4 is just out, and it should do better on fetching the zone names from the CTL.
Faking a UFH zone sensor: transmit works after binding, but the UFC never accepts it — looks like a wrong zone idx (packet-log evidence)
Hi all,
I’ve spent a lot of time trying to control an evohome underfloor-heating (UFH) zone from Home Assistant by faking its room thermostat, and I’ve hit a very specific wall that I believe is a zone-idx issue. I have packet-log evidence and would really appreciate any guidance (or confirmation that it’s a limitation/bug).
Setup
- ramses_cc 0.58.3, HA Core 2026.6.2 (HA OS)
- Gateway: RAMSES-ESP (evofw3-based), connected via USB/serial
- System: evohome controller 01:010153, UFH controller (UFC/HCE80) 02:009007, 5× HCW82 room stats (03:2388xx)
- Goal: fake room stat 03:238899 so HA can drive that zone’s demand.
What works
- Normal HGI-sourced send_packet transmits fine (green TX LED on the dongle blinks; controller replies).
- After: 03:238899 set to {class: THM, faked: true}, enforce_known_list on, and binding it (put the evohome controller in “add room sensor” mode for the zone, then ramses_cc.bind_device with offer: {30C9: null}), put_room_temp now transmits (green TX LED) and the controller displays the faked temperature (e.g. Principal shows 15 °C). So binding unblocked the transmit path.
What does NOT work
- The UFC/HCE80 keeps the zone in comms-lost (red LED), heat_demand stays unknown, no actuator movement — even with sustained injection every 1 min for 15+ min, and even in Heat mode with current < setpoint.
- send_packet with a non-HGI from_id (impersonation) still fails, even after binding:
- Failed to send packet: <ProtocolContext state=IsInIdle cmd_=30C9| I, tx_count=0/0>: Expired global timer after 20.0 sec
The smoking gun — packet log shows the fake uses the wrong zone idx
Real thermostat 03:238899 (RX, RSSI 080):
2026-07-21T00:33:32 080 I 166 03:238899 --:------ 03:238899 30C9 003 0109EC
→ payload 01 09EC = idx 01, 25.40 °C. (It also periodically emits 2389 and 0002.)
Faked 03:238899 (TX, RSSI 000, my injection every 2 min):
2026-07-21T00:00:00 000 I — 03:238899 --:------ 03:238899 30C9 003 000708
→ payload 00 0708 = idx 00, 18.00 °C.
So the faking emits 30C9 with idx 00, but this device (a UFH zone sensor) uses idx 01. The UFC expects idx 01, so it ignores the idx-00 fake and the zone stays in comms-lost. This is consistent with a RX warning I also get: Packet idx is 01, but expecting no idx (00) — it seems ramses_rf models these THMs as idx-00 devices and therefore fakes them with idx 00.
Questions
- Can faking be made to emit 30C9 with the correct zone idx (01) for a THM that is a UFH zone sensor? (Packet log proves the fake uses idx 00 while the real device uses idx 01.)
- Why does send_packet (non-HGI from_id) still fail with tx_count=0/0 after binding, while put_room_temp transmits? That’s the only route I can see to send idx 01 manually.
- The real device also emits 2389 and 0002 that the fake doesn’t — are any of these required for the UFC to treat the zone as “live”?
Thanks so much for this great integration — happy to provide full logs or test anything.
thanks, i’ll try to create a fix
I can’t tell.
try to run the update_fan_params action from developer tools.
If it persists then please create an issue on github with logfiles and your schema attached .
The information in those entities is not officially defined for ventilation equipment (HVAC).
- Fan Info: Current fan info displayed on the Climate controller entity in Home Assistant, for example “speed 1, low”. Looks like a combo of the next mode, rate:
- Fan mode: one value from a list of “modes”, “auto”, “manual”, “boost”, “paused”. Some manufacturers don’t let their fan send this, or use it for the fan speed (“low”) or always send the same strange value “Unknown_0x1F”. Not translated in the UI
- Fan rate: fan speed step “name”, for example: “low”, “III”. Again, the fan just sends a number and we pick an item from a fixed list. But some manufacturers put a % in here. Not translated in the UI
- (Exhaust) Fan speed: a number from 0-100% (not sent by every fan). It is in the same byte as Fan rate, you might see 0.1%. In that case, just ignore…
Ramses RF sticks to the English manufacturer’s words.
If you want to display localised (“translated”) words, you can create a template helper.
Quick question. Since my last struggle with faked temperature sensors and HVAC remote and going back to the back up, I’ve skipped all releases. Are these things already on the up and up and working with this latest true release or should I still stay with my current version where it’s working fine? Thanks again BTW for all the hard work you have and pouring into this. So please don’t see the above as a complaint but rather as curiosity.
Personally ive just kept updating, i never bothered rolling back, the latest releases IMHO, seem pretty perfect. Im on Evohome.
Hi, I’ve been testing several options but still not successful Absolute Humidity. If I use internal sensor, it seems the selection is not saved (every time I try to change a parameter, all internal sensor selection are blank). I have created an absolute humidity helper for internal and external (they are working) but I’m unable to make them work in the dashboard. If I use external sensor, parameter are saved correctly but absolute humidity is not showed. If I check “sensor sources” it says indoor and outdoor abs are calculated, but no value is shown. I can anyhow show un the same screen absolute humidity in blue color. Not sure what I’m doing wrong.
Ramses RF pre-release 0.59.2 is now available in HACS.
Many great optimisations and fixes, so backup before giving it a spin.
Hint: The good ol’ known_list is now fully integrated into the config schema.
I’ve now moved to the new release thank you. I have an evofw3 dongle and it is mostly working. I am seeing two issues
- My underfloor heating has two zones and I am only getting one reported
- I am receiving repeated notifications of the same two new devices having been discovered:
Found 2 new device(s):
10:093149 (OTB, medium)
13:142019 (BDR, medium)
Review discovered devices — open Configure → Review discovered devices to accept, decline, or skip for now.
Or call ramses_cc.accept_discovered_device / ramses_cc.discard_discovered_device services.
I have tried individual and bulk acceptance of these but they just keep repeating.
Is this a general issue or something I can clear?
Thank you
Donald
@dwp please supply a 24h packet log so we can check. Best if you create an issue on ramses_cc GitHub and drop it there as an attachment
I’ve created an issue on issue by Vedovatod on HA: absolute humidity not saved · Issue #126 · wimpie70/ramses_extras · GitHub
Thanks for reporting.
I’ve ‘moved’ it to the ramses_cc repo.
Yeah, I get that, but since I’m dependent on faked remotes and sensors, I really need those confirmed working/supported before I can move over/on.
ramses-esp dongles have moved to https://indalotech.co.uk/