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

JeroenTogt · September 22, 2026, 7:27pm

No Issue, just waiting for the HGI, was shipped very quick. But the postal system is a bit slow :-).

ivovangastel · September 25, 2026, 12:07pm

Hi all,
i am using the Ramses RF for a few years for my heating. recently we got a new ventilation system, a Itho HRU ECO 350. i can read the sensor information from the HVAC in my HA. but i can’t control the unit (yet). my mind cannot “wrap around” the information in the WIKI. so i have a few questions:

i have a HGI80, am i able to control the HVAC with this transmitter?
do i need to fake a remote? if so, do i define it’s own device ID with a random number?
do i need to do command learning? if so, i see 2 possible remotes. how do i know which remote has which device id? where is the learned command stored? (i tried, but see no learned commands in my schema).

EgbertB · September 26, 2026, 6:11pm

@ivovangastel

Yes, the HGI80 allows for control.
If you already have a physical remote bound to the HRU, you can use the same id for a faked REM. If you are using 0.60.7 and you turned on Discovery, your remote will be discovered. Accept it and add _faked: true in the schema. Add its id to the _remotes: list under your fan.
Add _scheme: itho to your FAN to tell Ramses RF what built-in command set to use.

EgbertB · September 26, 2026, 7:17pm

The next pre-release of the Ramses RF integration, 0.60.8, is now available in HACS. Fixes, improved stability for multi-HGI pools, a new complete Diagnostics report and lots more.

Please try it out and report bugs, before we create the next stable release.

tomasz-dominiak · September 27, 2026, 12:44pm

Setup: Alnor HRU-PremAIR-450, control board VMD-02RPS66-2 (Airios, OEM code 0x6A, confirmed by decoding the 10E0 identity payload myself against the ramses_rf parser source). Gateway is a plain ESP32 with a CC1101, running a fork of wlcrs/esphome-ramses over TCP, connected to ramses_cc.

I originally had a TX bug: my fork’s UART framing to the CC1101 was wrong, so nothing I transmitted ever actually left the radio correctly, even though RX always worked. I fixed the TX path to go through the ESP32’s hardware UART driving GDO0 properly, and confirmed that TX is now correct at the RF level: sending an RQ from the gateway reliably gets a real RP back from the fan (313F, 1470, 0001, 31DA all work fine both ways).

So communication is solid in both directions. The problem is specifically with getting the fan to act on commands from a device it hasn’t bound.

I created a brand new REM address (37:112233, never used before, not the same as my physical remote 37:220902) and sent it a 22F1 fan-speed command directly over TCP into the gateway. The fan heard it and replied:

RP --- 32:148895 37:112233 --:------ 22F1 003 000407

So it clearly received and processed the frame enough to answer with an RP (which matches the CODES_SCHEMA entry for FAN: 22F1 is RP-only on that device type). But the payload it reported (000407) was just its current actual speed, not an acknowledgement of the new command I sent (000607, boost) — and the fan did not physically react at all. So it seems willing to report state to literally anyone, but won’t execute a command from an unbound source.

I also tried a manual 1FC9 offer for that same new REM, byte-identical in structure to the real offer I captured from my physical remote pairing, just with the new address substituted in. I tried it with three different OEM domain bytes in the 10E0 slot: 6A (the real one for this board), 66 (Vasco) and 67 (Orcon), all sent within the 10-minute pairing window that opens after a power cycle (confirmed from Alnor’s own manual, no other pairing trigger exists on the unit). None got an Accept, same failure mode as #1218.

I noticed ramses_rf 0.60.7/0.60.8 added a Vendor.BROFER entry with oem_code 6A to the SCHEME_LOOKUP table in binding_fsm.py, which is exactly this board’s OEM. But as far as I can tell from reading the source, that table isn’t actually consumed anywhere in the current binding logic yet, so it doesn’t change behavior.

Has anyone gotten an Airios OEM 0x6A device (Siber/Alnor/Brofer family) to actually execute a command from a REM that wasn’t bound through the real Airios pairing procedure, or is BRDG-02R13 currently the only working path for this specific OEM? I’m so close from the goal yet so far…

18:000730:
  _class: HGI
32:148895:
  _bound: 37:220902
  _class: FAN
  _commands:
    _comment: Commands on FAN (Phase 3b) — target entity for automations
    high:
      code: 22F1
      payload: '000407'
      verb: I
    low:
      code: 22F1
      payload: '000207'
      verb: I
    medium:
      code: 22F1
      payload: '000307'
      verb: I
    party:
      code: 22F1
      payload: '000507'
      verb: I
    probe:
      code: 313F
      payload: '00'
      verb: RQ
    standby:
      code: 22F1
      payload: '000107'
      verb: I
  _owner: me
  remotes:
    - 37:220902
37:112233:
  _commands:
    high: ' I --- 37:112233 32:148895 --:------ 22F1 003 000407'
    low: ' I --- 37:112233 32:148895 --:------ 22F1 003 000207'
    medium: ' I --- 37:112233 32:148895 --:------ 22F1 003 000307'
    party: ' I --- 37:112233 32:148895 --:------ 22F1 003 000507'
    probe: RQ --- 37:112233 32:148895 --:------ 313F 001 00
    standby: ' I --- 37:112233 32:148895 --:------ 22F1 003 000107'
37:200000:
  _commands:
    test_high: ' I --- 37:200000 32:148895 --:------ 22F1 003 000407'
37:220902:
  _class: REM
  _commands:
    _comment: >-
      Commands were moved to FAN — consider removing from REM, or keep as
      downgrade backup
    high: ' I --- 37:220902 32:148895 --:------ 22F1 003 000407'
    low: ' I --- 37:220902 32:148895 --:------ 22F1 003 000207'
    medium: ' I --- 37:220902 32:148895 --:------ 22F1 003 000307'
    party: ' I --- 37:220902 32:148895 --:------ 22F1 003 000507'
    probe: RQ --- 37:220902 32:148895 --:------ 313F 001 00
    standby: ' I --- 37:220902 32:148895 --:------ 22F1 003 000107'
  _faked: true
  _owner: me
_owner: me
device_comments:
  32:148895: >-
    Likely FAN. may also be DIS (31DA is sent by both). codes: 0001, 042F, 10D0,
    10E0, 12A0. RSSI -101. (auto-generated — do not edit)
  37:220902: >-
    Likely REM. belongs to 32:148895. codes: 0001, 042F, 1060, 10D0, 10E0. RSSI
    -91. (auto-generated — do not edit)

098  I --- 32:148895 --:------ 32:148895 313F 009 007CB21ACD1B0907EA
my HA remote, faked, spoofing
---  I --- 37:220902 32:148895 --:------ 22F1 003 000307
response, ingoring my command
102 RP --- 32:148895 37:220902 --:------ 22F1 003 000407
original remote
105  I --- 37:220902 32:148895 --:------ 22F1 003 000307
102  I --- 32:148895 --:------ 32:148895 31DA 030 00EF007FFF2DEF08CC097B09840839F000000254540000EFEF24DE24DC00
102  I --- 32:148895 --:------ 32:148895 31DA 030 00EF007FFF2DEF08CC097B09890838F000000254540000EFEF2311225D00
102  I --- 32:148895 --:------ 32:148895 31DA 030 00EF007FFF2DEF08C3097409810839F000000254540000EFEF153615AB00

type or paste code here

type or paste code here

JeroenTogt · September 27, 2026, 6:38pm

I didn’t post this on the ramses cc github, but just wanted your guys opinion.

The below is for now only a cosmetic issue but it might not help with multiple HGI’s

See Below made with llm

Possible RSSI reporting anomaly with RAMSES_ESP 0.6.6d

Environment

Home Assistant OS
ramses_cc: 0.60.8
ramses_rf: 0.60.8
Gateway: RAMSES_ESP 18:172464
RAMSES_ESP firmware: 0.6.6d
Controller: 01:007149
OpenTherm Bridge (OTB): 10:057706
Transport: PooledTransport

The OTB 10:057706 is configured as the appliance controller for 01:007149.

Problem

I am investigating unusually large RSSI variations for packets received from the same OTB (10:057706).

Many correctly decoded responses from the OTB are received at approximately:

-39 to -43 dBm

However, other correctly decoded packets from exactly the same device are intermittently reported at:

-97 to -105 dBm

This means the reported RSSI can change by more than 60 dB.

The large changes can occur within a fraction of a second, while the same devices are communicating and the packets are still decoded successfully.

Example

One particularly interesting sequence occurs during a 3220 exchange between controller 01:007149 and OTB 10:057706.

The OTB responses are reported approximately as:

-43
-43
-40
-43
-39
-40
-98
-101 dBm

The transition from approximately -40 dBm to approximately -100 dBm happens within the same short exchange.

An extract from the log:

RQ 01:007149 -> 10:057706  3220   RSSI -72
RP 10:057706 -> 01:007149  3220   RSSI -43

RQ 01:007149 -> 10:057706  3220   RSSI -72
RP 10:057706 -> 01:007149  3220   RSSI -43

RQ 01:007149 -> 10:057706  3220   RSSI -72
RP 10:057706 -> 01:007149  3220   RSSI -40

RQ 01:007149 -> 10:057706  3220   RSSI -70
RP 10:057706 -> 01:007149  3220   RSSI -43

RQ 01:007149 -> 10:057706  3220   RSSI -72
RP 10:057706 -> 01:007149  3220   RSSI -39

RQ 01:007149 -> 10:057706  3220   RSSI -72
RP 10:057706 -> 01:007149  3220   RSSI -40

RP 10:057706 -> 01:007149  3220   RSSI -98
RQ 01:007149 -> 10:057706  3220   RSSI -99
RP 10:057706 -> 01:007149  3220   RSSI -101

The behaviour is not limited to message code 3220.

Unusually low RSSI values have also been observed with messages including:

3EF0
1FD4
22D9
3220

So this does not appear to be associated with only one RAMSES message type.

Gateway relocation test

To check whether this could simply be caused by RF propagation, multipath, interference or gateway placement, I physically moved the RAMSES_ESP gateway to another position and collected another packet log.

The same behaviour remained.

In the available log there are 195 received packets where 10:057706 is the sender.

The RSSI distribution is approximately:

RSSI range:      -105 .. -39 dBm
Median:          ~-56 dBm

>= -50 dBm:       93 / 195
<= -90 dBm:       36 / 195

Therefore changing the physical position of the gateway did not eliminate the large RSSI jumps.

This does not prove that the cause is in RAMSES_ESP, but it makes a simple gateway-placement explanation less convincing.

Another example

The same behaviour can also be seen with 3EF0.

For example, normal OTB responses are repeatedly reported around:

-39 / -40 dBm

but an otherwise normal 3EF0 response can suddenly be reported around:

-103 dBm

and subsequent packets can return to approximately -40 dBm.

Again, the packet itself is successfully decoded.

Additional RSSI observation

The automatically generated device comments contain some RSSI values without a minus sign.

Examples:

10:057706 (OTB): RSSI 38
01:007149 (CTL): RSSI 63

34:094165 (THM): RSSI 60
34:094171 (THM): RSSI 47
34:195026 (THM): RSSI 55

Other devices in the same diagnostics have expected negative-looking values such as:

-55
-73
-89

I do not know whether these positive-looking values are related to the packet-log RSSI anomaly, so I am mentioning this only as an additional observation.

Current hypothesis

The packet logs alone do not prove that RAMSES_ESP is calculating RSSI incorrectly.

However, several observations make the RSSI measurement/reporting path worth investigating:

RSSI changes by more than 60 dB for the same transmitter.
These changes can occur within a fraction of a second.
The packets with very low reported RSSI are still successfully decoded.
The behaviour occurs with multiple RAMSES message codes.
Physically relocating the gateway did not eliminate the behaviour.
Subsequent packets can immediately return to approximately -40 dBm.

Possible areas worth checking could therefore include:

raw CC1101 RSSI register value;
signed/unsigned handling of the RSSI value;
CC1101 RSSI-to-dBm conversion;
timing of reading the CC1101 RSSI/status registers;
stale RSSI/status data;
association of an RSSI value with the wrong packet;
processing of RSSI between RAMSES_ESP and ramses_rf.

These are only possible explanations, not confirmed causes.

Question regarding multi-gateway operation

I also intend to use multiple RAMSES_ESP gateways with PooledTransport.

Could this RSSI anomaly affect gateway selection when multiple gateways are connected?

I understand that RSSI-based per-device gateway routing has been discussed/planned for multi-gateway operation, but I am not sure to what extent this is currently implemented in ramses_rf 0.60.8.

For example, consider two gateways receiving the same device:

                 actual RF      reported RSSI

Gateway A        ~-40 dBm       -101 dBm   <- anomalous sample
Gateway B        ~-70 dBm        -70 dBm

If gateway selection uses the anomalous RSSI measurement, it could potentially make Gateway B appear to have the better RF path even though Gateway A actually receives the device much more strongly.

I therefore have a few questions regarding PooledTransport / multi-gateway operation:

Does PooledTransport in ramses_rf 0.60.8 currently use RSSI when selecting a gateway for TX?
If so, is the selection based on the latest RSSI value, an average/filter, history, or another metric?
Can a single anomalous RSSI sample influence the selected gateway?
Is RSSI currently only informational, with RSSI-based routing intended for a later implementation?
Would collecting the same packet simultaneously on two RAMSES_ESP gateways be useful for diagnosing this?

Summary

The main observation is:

Same OTB
Same gateway
Same short RF exchange
Valid decoded packets

RSSI approximately -40 dBm
          ↓
RSSI approximately -100 dBm
          ↓
RSSI returns to approximately -40 dBm

Moving the RAMSES_ESP gateway to another physical position did not eliminate this behaviour.

At this point I am not claiming that this is a RAMSES_ESP firmware bug. I would like to determine whether the large RSSI changes are genuine RF measurements or originate somewhere in the RSSI acquisition/conversion/reporting path.

Willem70 · September 27, 2026, 7:41pm

@JeroenTogt I’ve had an LLM analyze your post to get a fast, but detailed response:

Thanks for the well-documented report — the log excerpt is actually quite informative.

On the anomaly itself

A few observations that point away from genuine RF propagation and toward the RSSI acquisition path in the gateway firmware:

~-100 dBm is the textbook CC1101 noise floor. The classic cause of exactly this signature is the RSSI register being sampled when no carrier is present — e.g., read before sync lock, after the packet has already ended, or a stale/cleared latch.
The last block in your excerpt is the strongest evidence: RP -98, RQ -99, RP -101. Two different transmitters — the OTB (~-40) and the controller (~-70) — both “dropped” to the noise floor in the same short window. One gateway, one window, all sources at floor. That’s a receiver-side measurement artifact; two coincidental 40–60 dB fades happening simultaneously and recovering together is not plausible propagation.
The burst pattern matters: three consecutive floor reads rather than randomly scattered outliers suggests a state/timing issue (e.g., RSSI sampling relative to TX/RX turnaround, calibration, or a latched register being cleared) rather than per-packet misassociation.
It can’t originate in ramses_rf. The RSSI field is embedded in each frame line and parsed per-line; there’s no code path where one packet’s RSSI could be attached to another packet, and ramses_rf never measures RSSI itself — it just normalises what the firmware reports (unsigned 098/101 → -98/-101). So whatever is in the packet log is literally what RAMSES_ESP emitted.

My suggestion would be to raise this with the RAMSES_ESP firmware maintainer — the questions about when the CC1101 RSSI/status registers are read relative to packet reception are the right ones.

On PooledTransport / multi-gateway

To answer your numbered questions for ramses_rf 0.60.8:

Yes, RSSI-based TX routing is implemented. PooledTransport keeps a per-child RSSI tracker and selects the sendable child with the best evidence for that specific target device.
It’s not the latest sample and not an average. Each child keeps the last 5 samples per device with a 5-minute TTL, and selection uses the best (max) of that window. Fallback order: per-device RSSI → best RSSI across all devices that child has heard → no data → first sendable child in config order (deterministic cold-start).
A single anomalous low sample cannot flip routing. max() ignores it as long as any good sample remains in the window — it would take ~5 consecutive anomalous samples within 5 minutes, and it self-heals. A single anomalously high sample could briefly over-prefer a child, but your anomaly is downward, which is the benign direction for this policy. Echoes and loopback frames from other pool HGIs are excluded from the trackers.
It’s live routing today, not informational-only.
Yes, dual-gateway capture would be useful. If the ~-100 windows are uncorrelated between the two gateways, that confirms a per-receiver artifact. Practically, each child keeps an independent tracker, so anomalies on one gateway can’t contaminate the other’s evidence anyway — the design is fairly resilient to exactly this failure mode.

On the positive-looking comment RSSI values

Almost certainly unrelated to the anomaly: those are remnants from before a recent fix (ramses_rf 0.60.1) that normalised the firmware’s unsigned RSSI representation (038 → -38). Comments generated earlier were persisted with the sign dropped — the magnitudes you quote (38, 63, 60, 47, 55) are all plausible real RSSI values. They should refresh correctly over time; cosmetic only.

JeroenTogt · September 28, 2026, 7:38am

Thanks. So it looks like the 2 HGI setup should be robust enough to handle these anomlys. One’s I have my second HGI we can see further

Thanks

Willem70 · September 28, 2026, 7:44am

Hehe, seems some people will have some extra work on their hands

EgbertB · October 3, 2026, 8:48am

Ramses RF pre-release 0.60.9 is out in HACS.

DiscoveryScan improvements (only “your” devices)
New Buttons on HGI and Fan to run Reset actions on themselves
Translatable Port selection dialogs (en, nl provided)
last_message_sent sensors on every device (turn on in Config > Advanced options)

Includes an essential fix to run the integration on HA Core 2026.10.0+

EgbertB · October 8, 2026, 6:29am

The next Ramses RF pre-release, 0.60.10 is out in HACS.
Per-device polling interval setting, fixes & tweaks.

The ramses_cc wiki has been updated to match the options and formats used in the current release.

And once again a reminder to update to this pre-release to run the integration on Hone Assistant Core 2026.10.0. Quite stable, and at least it loads

EgbertB · October 14, 2026, 11:58am

Ramses RF pre-release 0.60.11 is out in HACS.

Many fixes in the ramses_rf library (last CLI version to run on python 3.12). Integration requires HA 2026.9.0 or later.