Using more than 1 HGI

[wimpie70]

I actually want to start a discussion about this...what are your thoughts @silverailscolo ?

I'm doing some research before starting this new project to allow more than 1 HGI's to be used. I fixed my second Ramses ESP (lets call it HGI2) and wanted to check it with this integration, so I added it to the known list. I also removed the other one (HGI1) from the list and enforced only known devices only.

But...only the old HGI1 is set as the HGI to work with. HGI2 is ignored.

Why:
A. Transport Layer vs Application Layer
The issue occurs because there are two separate layers of HGI selection:

• Transport Layer (ramses_tx/transport.py): This is the low-level serial communication layer that automatically discovers and selects the first available HGI device during initialization
• Application Layer (ramses_rf/gateway.py): This is where the known_list filtering should be applied

B. Initialization Order Problem
The problem is in this sequence:

1. The transport layer initializes and automatically selects HGI1 it finds (18:149488)
2. The transport layer sets this as the "active HGI" in its internal state
3. The application layer (Gateway.hgi property) then returns this transport-selected HGI
4. The known_list filtering happens too late in the process

So, what is the desired approach here. Do we want to fix this ? And how do you think about allowing more than 1 HGI in ramses anyways ?

[silverailscolo]

@wimpie70 happy to discuss.

For starters, what would the role of 2 HGI devices be, exactly? A sort of master/slave, or 2 fully independent "nets"?
I remember you had an issue with reception at the outhouse.
Comparing this to Wifi mesh, when a TRV is somewhere in between your 2 dongles, should it select the strongest signal or would you configure all the items related to the shed in system B?

Do you need one full Ramses system, e.g. in order to control one central heat device, or could you approach this as if it was your neighbours' independent Ramses RF setup? In that case the current limitation is rooted in not allowing to add that 2nd Entry in HA.

Otherwise, the fundamental architecture of Ramses RF, with the Engine/Gateway designed as the 'brains' of the system, will need a serious rewrite.

Your question is not just theoretical, I wish to emphasize. I recently plugged in an independent RF Bridge, without adding it to HA/Ramses RF. But it does show up in Ramses RF as an HGI, and one FAN now broadcasts and responds (RQ-RP) to 2 HGI's.
And what surprised me: this FAN has a second address that showed up after pairing to the RF Bridge. That address also shows up in Ramses RF, so I enforce the known list to prevent me from mixing them up. These double addresses seem important to consider in your concept. Edit: this was not happening, as I just noticed the fan speed and HUM were way off. Looking closely, it reported as a CVE-RF, so must be new at the neighbours...

For now, just some thoughts...

[silverailscolo]

If the issue is just RF reception, Airios makes this BRDG-02M11 repeater. Available OEM from Itho, Orcon.

[wimpie70]

Interesting, I do have an extra HGI 18:000001 and also an unknown HVC:37:154519 listed in RF, but never paid much attention to it.
I also need to do some more testing to see what's going on with the 2nd HGI. I didn't see any messages logged to or from the 2nd HGI so far.
Creating a WiFi like mesh sounds pretty tricky.

Here's a possible strategy:

1. Let the config_flow overrule the HGI found by _rf

2. config_flow: optional 'default' trait to the HGI class. This HGI will be used if none other is specified for a device. If not specified, _rf will use the found HGI it is using now as default.

3. Config_flow: optional 'HGI' trait for all other devices. This will route sending msgs for this device to this gateway. It may not be needed for all devices, but if there are conflicts (device between 2 ESP's) this will block other HGI's from handling msgs for this device.

4. Reading msgs, - listen to all HGI's- accept a msg if it passes CRC & parsing

• Deduplicate and process the first ? Or only process the specified (or default).

5. _rf adaption: big change

• each msg gets tagged with "origin HGI"

6. msgs -> SQLite: I'll need to have a better look at what you did so far and how to prep for this. And where to query for updates and status.

7. Builder pattern: I'll also need to have a better look at this to avoid a lot of work later on.Considerations:

• Later adding/removing or failing an HGI may cause problems

---

I noticed your post about the repeater while typing this :D Yes, this could work, I searched for them, but didnt find any that would really do the job, this one might do it...Deduplicating the same msgs might be a problem, but I think there is already some code handling this. I'll investigate further.

[wimpie70]

I doubt Airios sells these to consumers, but only B2B. Seems Like eg. Orcon rebrand/adapt their products. The Itho Daalderop RF Repeater seems to be the same (+/-150 euro). And there is a limitation of 6 devices...
So, back to the drawing table ...

[wimpie70]

I found I had to manually send a packet from the 2nd ESP with a response from the FAN. Now a 2nd HGI device is created. These msgs also get parsed and redirected to the handler (in this case hvac).
So, indeed. as you described, it can be used as an extra HGI. This may be less complicated than I expected at first.

[ghoti57]

My view on how multiple gateway devices (HGI) should be used is that ramses_rf should be able to use more than one gateway device.

The benefit of multiple gateways is that they do not have to be co-located with the HA host system. Often this is in a less than ideal location compared to the 868Mhz radio devices. Since ramses_esp has introduced MQTT over wifi connections to ramses_rf the colocation restrictiion of the original USB evofw2/evofw3 devices is no longer a restriction.

every gateway should report all received messages to ramses_cc, I don't believe this should cause problems, it's effectively the same as devices sending multiple copies of the same message.

On transmit, it's important that only one gateway is used to transmit any message. Sending via multiple gateways will result in high numbers of TX collisions and crowded radio space.

It's easy to decide which gateway should be used to transmit any message.

As messages are received from any device via multiple gateways the RSSI value for messages received from each HVAC device is recorded. The gateway that sees the best RSSI value should be used to transmit messages to that device.

[wimpie70]

Yes, I agree,
I think this could be implemented with the builder pattern design.
For sending I still suggest to bind a HGI to devices, or, the other way around: let HGI's have a list of devices if it overrules a default one.

[ghoti57]

I don't think there should be any configuration of which devices should be associated with each gateway. There's no need and if one of the gateways should fail some of the HVAC devices will be isolated. ⁣Get BlueMail for Android ​

…

On Jan 26, 2026, 19:21, at 19:21, Willem ***@***.***> wrote: wimpie70 left a comment (ramses-rf/ramses_rf#289) Yes, I agree, I think this could be implemented with the builder pattern design. For sending I still suggest to bind a HGI to devices, or, the other way around: let HGI's have a list of devices if it overrules a default one. -- Reply to this email directly or view it on GitHub: #289 (comment) You are receiving this because you commented. Message ID: ***@***.***>

[wimpie70]

Ah I get it. I missed the part about recording the RSSI values per device. They can even be updated automatically when something changes.
Great.

[ghoti57]

I'm not sure how you are selecting the available HGIs. Don't consider only multiple MQTT devices. It should be possible to use any combination of direct USB connected and MQTT connected devices (although I don't know why you would want to directly connect 2 USB devices)

Allowing USB devices means it works for somebody having an older evofw3 device and a ramses_esp device.

Auto recognition of the available devices might be tricky - much better to allow multiple instances in the configuration.

[ghoti57]

No need to tag the messages with HGI. ramses_cc doesn't care where they've come from. The RSSI data should just be stored in ramses_rf. It doesn't need to go into any non-volatile mechanism. ramses_cc should just request ramses_rf to TX a message. It doesn't care how it's sent. Which HGI to use is a transport issue.