Ramses II 868MHz communicatie via evofw3 en ramses_rf

[Wimpie70]

Meer info over 2411 support in de doc. De action calls staan ergens onderaan.
Even voor de duidelijkheid: dit zijn configuratie instellingen voor je FAN, voorzichtig hiermee. Het lijkt me niet handig om de aanvoer op 10% en de afvoer op 100% te zetten...
Ik heb het zelf getest op een Orcon fan. Het heeft vergelijkbare mogelijkheden als een RF15 display.
Op dit moment worden 15 parameters ondersteund, maar er zijn er meer (info graag delen). Zo kun je nu o.a. de comfort temperatuur instellen en percentages voor low, mid en high.

Om waardes te kunnen veranderen heb je een 'bound' REM nodig. Dit is een extra optie die je in je configuratie plaatst bij je fan. Deze REM kun je zelf aanmaken als 'faked', die je natuurlijk nog wel even moet binden op de gebruikelijke manier.

code:

"32:153289":
  bound: "37:168270"
  class: FAN
"37:168270":
  class: REM
  faked: true

Veel plezier ermee, ben benieuwd hoe jullie het kunnen gebruiken

[ebroerse]

Ramses RF release 0.52.3 is uit. Het is weer een “echte” versie, die in HACS verschijnt.

Er zit een optie in Config Flow waarmee je de MQTT-berichten kan tonen. Staat standaard uit omdat met Known Devices Only anders heel veel verkeer (van de buren) in de system log verscheen waardoor het onoverzichtelijk werd.
Verder verbeteringen in 2411 params etc.
Bekijk ook even de release notes.

[Keesnotals]

Dag allen,

Vraagje, is er een bongle/ apparaat waarmee je de communicatie kan bewerkstelligen die je niet zelf in elkaar moet zitten?

Ik weet dat deze mogelijkheid er is: https://indalo-tech.onlin...s/cat7844708_4841997.aspx
Maar zijn er ook ander mogelijkheden?

Bedankt voor jullie hulp.

[asaki]

Maar dat is toch precies wat je vraagt, een module die je niet zelf in elkaar moet zetten? Hij is nu even niet op voorraad, maar vorige week kon die nog gewoon besteld worden.

[Kriseh]

Keesnotals schreef op maandag 24 november 2025 @ 22:34:
Dag allen,

Vraagje, is er een bongle/ apparaat waarmee je de communicatie kan bewerkstelligen die je niet zelf in elkaar moet zitten?

Ik weet dat deze mogelijkheid er is: https://indalo-tech.onlin...s/cat7844708_4841997.aspx
Maar zijn er ook ander mogelijkheden?

Bedankt voor jullie hulp.

Er staat er momenteel ook 1 op Vraag en Aanbod: v&a aangeboden: 868MHz naar Wifi interface gebaseerd op ESP32-C6 en CC1101

[asaki]

Ik heb deze, ook van tweaker immrmkw gekocht. Werkt als een speer

[ Voor 9% gewijzigd door asaki op 28-11-2025 00:16 ]

[ebroerse]

Ramses RF 0.52.4 is uit.
Bevat bugfixes en ontwikkeltools (coverage report), plus een mooi configuratiepaneel voor je MQTT-instellingen.

[rwijnhov]

Heb het allemaal werkend maar nu heb ik een probleem waar ik niet uit komt. Ramses pakt in de autodetect van het shema de verkeerde otb controller. Nu heb ik via know devices schema de juist otb toegevoegd aan de controller. Hoe verwijder ik nu de foutief gedetecteerd otb uit het controller overzicht? Zelf als hem disable blijft die in het overzicht staan. Heb beide cache al verwijderd, etc.

[ebroerse]

rwijnhov schreef op woensdag 10 december 2025 @ 18:39:
Hoe verwijder ik nu de foutief gedetecteerd otb uit het controller overzicht?

Mijn advies: lekker in het overzicht laten staan, en negeren. Maak een eigen dashboard met de items, grafieken etc. die jij gebruikt. Dan kom je zelden op het overzicht van de integratie.
Over een tijdje mss deze instructie volgen, al begint die ook met “I don’t advise doing this at all but…” 😙

[ebroerse]

Ramses RF 0.52.5 (m.n. bugfixes) is uit.
Dank voor al jullie bijdragen en feedback in 2025!

[asaki]

Bedankt voor het maintainen!

[GroeneBoom456]

Iemand ervaring met Ramses RF voor een Vasco RF 3 standenschakelaar? (type: 90.01.06.76.A)

[ Voor 3% gewijzigd door GroeneBoom456 op 22-12-2025 10:09 ]

[vliegnerd]

GroeneBoom456 schreef op maandag 22 december 2025 @ 10:09:
Iemand ervaring met Ramses RF voor een Vasco RF 3 standenschakelaar? (type: 90.01.06.76.A)

Niet direct, maar waar ben je naar opzoek?

De standenschakelaar ziet eruit als een "gewone" OEM-versie van een 3-standenschakelaar gemaakt door Airios uit Veldhoven. Die zal dus vrijwel zeker 868MHz ramses gebruiken.

Wil je het dingen uitlezen/besturen via Home-Assistant? Wil je weten of je een ramses-bordje hiervoor zou kunnen gebruiken? (vrijwel zeker wel) Of heb je al een bordje? Enz.

Vertel meer!

[ebroerse]

GroeneBoom456 schreef op maandag 22 december 2025 @ 10:09:
ervaring met Ramses RF voor een Vasco RF 3 standenschakelaar? (type: 90.01.06.76.A)

Ja, die draait hier thuis happy met Ramses RF. Het is de Airios VMN-17LMP01 (zie sticker aan de binnenkant).

Plak de volgende code in de HA Ramses RF configuratie > Known Devices (adressen wel aanpassen voor jouw setup):

code:

"29:091138":
  alias: Vasco remote
  class: REM
  commands:
    auto: " I --- 29:091138 32:022222 --:------ 22F1 003 000506"
    boost: " I --- 29:091138 32:022222 --:------ 22F3 007 00021E04060000"
    hoog: " I --- 29:091138 32:022222 --:------ 22F1 003 000406"
    laag: " I --- 29:091138 32:022222 --:------ 22F1 003 000206"
    llaaag: " I --- 29:091138 32:022222 --:------ 22F1 003 000106"
    midden: " I --- 29:091138 32:022222 --:------ 22F1 003 000306"
    uit: " I --- 29:091138 32:022222 --:------ 22F1 003 000006"
  faked: true

Meer info in de Ramses RF wiki

[ Voor 55% gewijzigd door ebroerse op 24-12-2025 10:47 ]

[golfdiesel]

Residio/Honeywell hebben nieuwe modules en radiatorkranen uitgebracht met een "nieuw" protocol volgens de verpakking. Heeft iemand de R3 modules al getest om te zien of ze nog steeds uit te lezen zijn via Ramses RF? De physical layer van de communicatie blijft wel hetzelfde maar heb zo'n vermoeden dat residio er nu encryptie aan toegevoegd heeft gezien het logo.

[ebroerse]

golfdiesel schreef op maandag 29 december 2025 @ 16:16:
Heeft iemand de R3 modules al getest om te zien of ze nog steeds uit te lezen zijn via Ramses RF?

Is door meerdere gebruikers gezien toen ze een nieuw device ontvingen of toen Resideo support hun evohome ging upgraden.

Het nieuwe Ramses-III protocol gebruikt idd encryptie en werkt nu (nog) niet met de Ramses RF integratie/lib

Zie dit issue voor de laatste stand.

Als het (ooit) gaat werken dan zal ik dat hier zeker melden.

PS Je schijnt een downgrade aan te kunnen vragen als je bijv. 1 nieuwe TRV krijgt en de rest werkt gewoon nog op Ramses-II

[Hippe Lip]

ebroerse schreef op donderdag 1 januari 2026 @ 14:35:
[...]
Is door meerdere gebruikers gezien toen ze een nieuw device ontvingen of toen Resideo support hun evohome ging upgraden.

Eh, watte? Gaat dat upgraden alleen op verzoek, of krijgt ‘iedereen’ op termijn die upgrade?

En die upgrade naar Ramses III betekent dan een versleutelde verbinding? Dan neem ik aan dat dit dan niet zomaar kan communiceren met de ‘oude’, reeds bestaande onderdelen?

[asaki]

Ik verwacht dat de upgrade alleen maar nodig is als je een device toevoegt dat het Ramses-III protocol gebruikt.

[HH91]

Hebben jullie aanbevelingen voor hardware?
Degene die op github wordt aangeraden (https://indalo-tech.onlineweb.shop/) is niet meer verkrijgbaar.

Zou het leuk vinden om hier ook mee aan de slag te gaan!

[asaki]

HH91 schreef op vrijdag 2 januari 2026 @ 23:53:
Hebben jullie aanbevelingen voor hardware?
Degene die op github wordt aangeraden (https://indalo-tech.onlineweb.shop/) is niet meer verkrijgbaar.

Zou het leuk vinden om hier ook mee aan de slag te gaan!

Ik heb deze ooit gekocht, tik hem eens aan, wellicht heeft hij er meer liggen

[Kriseh]

HH91 schreef op vrijdag 2 januari 2026 @ 23:53:
Hebben jullie aanbevelingen voor hardware?
Degene die op github wordt aangeraden (https://indalo-tech.onlineweb.shop/) is niet meer verkrijgbaar.

Zou het leuk vinden om hier ook mee aan de slag te gaan!

Er staat nog steeds een bordje op vraag & aanbod: v&a aangeboden: 868MHz naar Wifi interface gebaseerd op ESP32-C6 en CC1101 zelfde is al in gebruik door iemand binnen dit topic en werkte als een trein.

[correcto]

HH91 schreef op vrijdag 2 januari 2026 @ 23:53:
Hebben jullie aanbevelingen voor hardware?
Degene die op github wordt aangeraden (https://indalo-tech.onlineweb.shop/) is niet meer verkrijgbaar.

Zou het leuk vinden om hier ook mee aan de slag te gaan!

Volgens mij houden ze niet echt voorraad aan. Was destijds ook zo toen ik de voorloper van deze dongle bestelde. Je kunt je aanmelden voor een notificatie als ze weer leverbaar zijn.

[maleadt]

Kriseh schreef op zaterdag 3 januari 2026 @ 08:59:
[...]


Er staat nog steeds een bordje op vraag & aanbod: v&a aangeboden: 868MHz naar Wifi interface gebaseerd op ESP32-C6 en CC1101 zelfde is al in gebruik door iemand binnen dit topic en werkte als een trein.

Ik heb deze ook net in gebruik genomen, en werkt inderdaad perfect.

Daarom heb ik wel een ongebruikte nanoCUL met de evofw3 firmware (werkt perfect maar ik wou iets stand-alone), dus moest je willen kan ik die wel op v&a zetten.

[Wimpie70]

Hij wordt bij indalo waarschijnlijk wel weer beschikbaar, je kan een notify invullen. Anders even een berichtje sturen ?

---
ah, ik zie dat die andere wordt aangeboden door @immrmkw , lijkt me een prima optie

[ Voor 27% gewijzigd door Wimpie70 op 03-01-2026 09:56 ]

[XElD]

Ik draai hier nog de boel op de oude Idalotech SSM-D2 wat destijds eigenlijk de enige optie was die goed werkte. Maar verzendkosten vanuit de UK, invoerrechten en nog een keer extra BTW betalen dankzij de Brexit daar wordt je niet vrolijk van. Dus ik zou nu gewoon voor de optie van immrmkw gaan.

[asaki]

Ik heb de module van immrmkw nu een maand of iets draaien. Werkt als een speer met mijn Evohome systeem. Vooral het gevoel dat dingen direct reageren ipv het wachten op een cloud call is bijna magisch

[golfdiesel]

Hippe Lip schreef op donderdag 1 januari 2026 @ 22:50:
[...]

Eh, watte? Gaat dat upgraden alleen op verzoek, of krijgt ‘iedereen’ op termijn die upgrade?

En die upgrade naar Ramses III betekent dan een versleutelde verbinding? Dan neem ik aan dat dit dan niet zomaar kan communiceren met de ‘oude’, reeds bestaande onderdelen?

Voor zover ik weet gaan alleen nieuwe apparaten via R3 commmuniceren dus dat zijn de HR93 knoppen en de nieuwe vloerverwarming regelaar. Dus langzaam aan zal alles overgaan op Ramses-III.
Erg jammmer dat Residio deze weg ingeslagen is.

[LdvM]

Hallo allen,

Ik ben geintereseerd geraakt in deze thread en wil nu ook proberen een setje in elkaar te zetten voor het monitoren en aansturen van mijn Evohome. Ik heb mij op de notificatielijst laten zetten voor de Indalo oplossing, maar kijk intussen ook naar de oplossing met het prinbordje van @vliegnerd (vliegnerd in "Ramses II 868MHz communicatie via evofw3 en ramses_rf"). Nu blijkt de (juiste) CC1101 lastig verkrijgbaar via de aanbevolen AliExpress winkel, maar goed, dat komt vast nog wel.

Dank!

Zijn er anderen die deze route genomen hebben en aanbevelingen hebben tot het laten maken van dit bordje? JLPCB, heb ik gelezen, meen ik...?

[Wimpie70]

zie 6 posts hierboven

[LdvM]

Ik sta al op de Indalolijst om geïnformeerd te worden. En wat betreft de advertentie van @immrmkw, ik meende net een kwartiertje geleden te hebben gezien dat de advertentie de status "vervallen" had. Nu niet (meer), blijkbaar. Kan dat ook eens proberen...

[immrmkw]

@LdvM, de advertentie is nog actief als het goed is. Ik heb er nog een paar.

Laat het me weten als je er 1 wil proberen. Die van mij heb ik nu iets minder dan een jaar en doet het goed. Ik zet de Ramses ESP software er al op en ik test het bordje even voor ik hem verstuur. Mocht je het niet wat vinden mag je hem altijd terugsturen

[ebroerse]

HH91 schreef op vrijdag 2 januari 2026 @ 23:53:
Hebben jullie aanbevelingen voor hardware?

3e optie, staat ook op Ramses_rf github wiki:

Om eerst te proberen hoe/of het werkt heb ik zelf een ESP32-S3-WROOM1 N16R8 verbonden met een CC1100 transceiver (in NL besteld bij een van de bekende shops) en daar ramses_esp op geflashed.
Werkte zo goed dat ik meteen klaar was, voor €30.

Ik zal er eens een post over schrijven. DM voor de onderdelen.

[Gerritjuh]

LdvM schreef op zaterdag 3 januari 2026 @ 15:37:
Hallo allen,

Ik ben geintereseerd geraakt in deze thread en wil nu ook proberen een setje in elkaar te zetten voor het monitoren en aansturen van mijn Evohome. Ik heb mij op de notificatielijst laten zetten voor de Indalo oplossing, maar kijk intussen ook naar de oplossing met het prinbordje van @vliegnerd (vliegnerd in "Ramses II 868MHz communicatie via evofw3 en ramses_rf"). Nu blijkt de (juiste) CC1101 lastig verkrijgbaar via de aanbevolen AliExpress winkel, maar goed, dat komt vast nog wel.

Dank!

Zijn er anderen die deze route genomen hebben en aanbevelingen hebben tot het laten maken van dit bordje? JLPCB, heb ik gelezen, meen ik...?

Ik heb deze destijds besteld: https://nl.aliexpress.com/item/1005003256614835.html. Bordjes heb ik laten maken bij JLCPCB, ik heb er nog 4 over die weg mogen.

[asaki]

Heeft iemand wel eens bij een HR92 gehad dat de heat demand sensor van de climate entity niet werkt? Ik heb 12 HR92's hangen in het huis en 1 daarvan rapporteert een "unavailable" bij deze sensor. Zie screenshot.

[Hippe Lip]

@asaki Ik heb diverse dingen die unavailable zijn. Bij de ene thermostaat krijg ik een heat demand, terwijl een andere thermostaat unavailable geeft bij de heat demand. En alle thermostaten zijn van hetzelfde merk en type en zijn allemaal tegelijk geleverd.
Dus waar dat aan ligt? Ja, zeg het maar…

[asaki]

Heel raar! Extra vreemd is dat de rad controller wel een heat demand geeft, maar die wijkt dus af van wat de climate entitiy heat demand aangeeft.

Voorbeeld is dat de thermostaat in de kinderkamer op een gegeven moment een heat demand van 7% heeft en de radiator knop (en dit is dus hetzelfde device!) 39%. Geen pijl op te trekken

[Kriseh]

asaki schreef op dinsdag 13 januari 2026 @ 23:32:
Heel raar! Extra vreemd is dat de rad controller wel een heat demand geeft, maar die wijkt dus af van wat de climate entitiy heat demand aangeeft.[Afbeelding]

Voorbeeld is dat de thermostaat in de kinderkamer op een gegeven moment een heat demand van 7% heeft en de radiator knop (en dit is dus hetzelfde device!) 39%. Geen pijl op te trekken

Ga ik voor je uitleggen !

De heat-demand van de zone zelf, dus climate entity (bijv. kinderkamer), is dezelfde waarde die je in de Evohome controller terugvindt onder 'Systeem overzicht'. Het is een indicatie van de mate waarin een zone warmte vraagt aan de ketel of warmtepomp. D.w.z. 0% = geen warmtevraag, 100% = maximale warmtevraag vanuit die zone.

De heat-demand van de draadloze radiator thermostaat (HR92), is feitelijk de klepstand. D.w.z. 0% = volledig dicht, 100% = volledig open .

[Kriseh]

asaki schreef op dinsdag 13 januari 2026 @ 22:46:
Heeft iemand wel eens bij een HR92 gehad dat de heat demand sensor van de climate entity niet werkt? Ik heb 12 HR92's hangen in het huis en 1 daarvan rapporteert een "unavailable" bij deze sensor. Zie screenshot.
[Afbeelding]

Probeer de batterij er is even uit te halen en opnieuw erin en kijk of dit helpt. Als dat niet werkt, pas lokaal (draaiknop) de temperatuur van de zone even aan en controleer ook even of de instellingen van de HR92 identiek zijn aan degene die wel alles netjes doorstuurt.

[asaki]

Hey @Kriseh , bedankt voor de heldere uitleg!

Ik heb de batterijen er even uitgehaald en ook maar meteen vervangen. Instellingen zijn gelijk met andere knoppen en manueel de temperatuur aanpassen werkt ook prima.

De zone werkt ook goed en je ziet de heat demand ook terug in het systeemoverzicht op de evohome controller. Het is dus alleen de waarde die niet doorkomt.

De homeassistant logs lopen vol met dit soort meldingen:

code:

2026-01-14 09:36:08.695 WARNING (MainThread) [ramses_tx.transport] Echo: RQ --- 18:156972 01:013373 --:------ 2349 001 08 < PacketInvalid(Bad frame: invalid structure: >>>: RQ --- 18:156972 01:013373 --:------ 2349 001 08<<<)
2026-01-14 09:36:09.545 WARNING (MainThread) [ramses_tx.transport] Echo: RQ --- 18:156972 01:013373 --:------ 2349 001 07 < PacketInvalid(Bad frame: invalid structure: >>>: RQ --- 18:156972 01:013373 --:------ 2349 001 07<<<)
2026-01-14 09:36:09.855 WARNING (MainThread) [ramses_tx.transport] Echo: RQ --- 18:156972 01:013373 --:------ 2349 001 03 < PacketInvalid(Bad frame: invalid structure: >>>: RQ --- 18:156972 01:013373 --:------ 2349 001 03<<<)
2026-01-14 09:36:09.935 WARNING (MainThread) [ramses_tx.transport] Echo: RQ --- 18:156972 01:013373 --:------ 2349 001 06 < PacketInvalid(Bad frame: invalid structure: >>>: RQ --- 18:156972 01:013373 --:------ 2349 001 06<<<)
2026-01-14 09:36:12.005 WARNING (MainThread) [ramses_tx.transport] Echo: RQ --- 18:156972 01:013373 --:------ 2349 001 01 < PacketInvalid(Bad frame: invalid structure: >>>: RQ --- 18:156972 01:013373 --:------ 2349 001 01<<<)
2026-01-14 09:36:19.845 WARNING (MainThread) [ramses_tx.transport] Echo: RQ --- 18:156972 01:013373 --:------ 2349 001 00 < PacketInvalid(Bad frame: invalid structure: >>>: RQ --- 18:156972 01:013373 --:------ 2349 001 00<<<)
2026-01-14 09:36:25.615 WARNING (MainThread) [ramses_tx.transport] Echo: RQ --- 18:156972 01:013373 --:------ 0418 003 000000 < PacketInvalid(Bad frame: invalid structure: >>>: RQ --- 18:156972 01:013373 --:------ 0418 003 000000<<<)

Zou dat er iets mee te maken kunnen hebben? Het lijkt er op alsof de data blokjes mist en daarom niet verwerkt kan worden.

[Kriseh]

asaki schreef op woensdag 14 januari 2026 @ 09:39:
Hey @Kriseh , bedankt voor de heldere uitleg!

Ik heb de batterijen er even uitgehaald en ook maar meteen vervangen. Instellingen zijn gelijk met andere knoppen en manueel de temperatuur aanpassen werkt ook prima.

De zone werkt ook goed en je ziet de heat demand ook terug in het systeemoverzicht op de evohome controller. Het is dus alleen de waarde die niet doorkomt.

De homeassistant logs lopen vol met dit soort meldingen:

code:

2026-01-14 09:36:08.695 WARNING (MainThread) [ramses_tx.transport] Echo: RQ --- 18:156972 01:013373 --:------ 2349 001 08 < PacketInvalid(Bad frame: invalid structure: >>>: RQ --- 18:156972 01:013373 --:------ 2349 001 08<<<)
2026-01-14 09:36:09.545 WARNING (MainThread) [ramses_tx.transport] Echo: RQ --- 18:156972 01:013373 --:------ 2349 001 07 < PacketInvalid(Bad frame: invalid structure: >>>: RQ --- 18:156972 01:013373 --:------ 2349 001 07<<<)
2026-01-14 09:36:09.855 WARNING (MainThread) [ramses_tx.transport] Echo: RQ --- 18:156972 01:013373 --:------ 2349 001 03 < PacketInvalid(Bad frame: invalid structure: >>>: RQ --- 18:156972 01:013373 --:------ 2349 001 03<<<)
2026-01-14 09:36:09.935 WARNING (MainThread) [ramses_tx.transport] Echo: RQ --- 18:156972 01:013373 --:------ 2349 001 06 < PacketInvalid(Bad frame: invalid structure: >>>: RQ --- 18:156972 01:013373 --:------ 2349 001 06<<<)
2026-01-14 09:36:12.005 WARNING (MainThread) [ramses_tx.transport] Echo: RQ --- 18:156972 01:013373 --:------ 2349 001 01 < PacketInvalid(Bad frame: invalid structure: >>>: RQ --- 18:156972 01:013373 --:------ 2349 001 01<<<)
2026-01-14 09:36:19.845 WARNING (MainThread) [ramses_tx.transport] Echo: RQ --- 18:156972 01:013373 --:------ 2349 001 00 < PacketInvalid(Bad frame: invalid structure: >>>: RQ --- 18:156972 01:013373 --:------ 2349 001 00<<<)
2026-01-14 09:36:25.615 WARNING (MainThread) [ramses_tx.transport] Echo: RQ --- 18:156972 01:013373 --:------ 0418 003 000000 < PacketInvalid(Bad frame: invalid structure: >>>: RQ --- 18:156972 01:013373 --:------ 0418 003 000000<<<)

Zou dat er iets mee te maken kunnen hebben? Het lijkt er op alsof de data blokjes mist en daarom niet verwerkt kan worden.

Ik denk dat je hiervoor het beste even een issue op de ramses cc/rf GitHub kunt aanmaken (wellicht is er al eens eerder een issue aangemaakt dus eerst even zoeken voordat je een nieuwe issue aanmaakt).

[Kriseh]

Kriseh schreef op woensdag 14 januari 2026 @ 18:33:
[...]


Ik denk dat je hiervoor het beste even een issue op de ramses cc/rf GitHub kunt aanmaken (wellicht is er al eens eerder een issue aangemaakt omtrent dit probleem dus eerst even zoeken voordat je een nieuwe issue aanmaakt).

[asaki]

Thanks. Kon niet echt een issue vinden, dus heb een nieuwe aangemaakt.

https://github.com/ramses-rf/ramses_cc/issues/423

[ebroerse]

Ramses RF release 0.53.2. is uit, met een fix voor het issue van de verdwenen Services in 0.53.1 plus verbeterde stabiliteit. Updaten via HACS wordt sterk aangeraden.

In de ramses_rf wiki heb ik een pagina over de ramses_tx.parsers toegevoegd.
Wie op zoek is naar meer details: lees de Ramses_rf developer's resource.

[fRiEtJeSaTe]

werkmane schreef op vrijdag 1 november 2024 @ 20:23:
[Afbeelding]

Het is mij ook gelukt! En hij werkt perfect. SMD solderen was wel een uitdaging, maar is gelukt. 1k weerstanden voor de ledjes is te veel, ze zijn een beetje zwak (maar is niet erg, hoef geen disco op zonder waar ik hem hem neergezet). Moet nog wel op zoek naar een doosje.

Ik heb een een mechanische ventilator van Orcon, de MVS-15HB, met een tweetal RF15 (eentje met CO2 sensor en eentje zonder).

De CO2 sensor heb ik aan de praat in ramses_cc in HA, maar uit de ventilatie unit krijg ik geen data. Het is natuurlijk geen WTW, maar had gehoopt dat ie in iedergeval wel de ventilatiestand zou kunnen weergeven en de luchtvochtigheid. Blijkbaar mist daar nog wat support voor in ramses_cc.

Ik heb trouwens nog 4 pcb's over (zonder onderdelen), dus als iemand nog interesse heeft, stuur maar een PB.

Heeft iemand nog een pcb liggen? En past de ESP32-C6 hier ook op?

[werkmane]

Ik heb al mijn extra pcbs al een tijd verkocht, maar zelf bestellen in China is niet zo moeilijk hoor.

[oshiro]

Hallo allen,

Ik heb Ramses RF versie 53.2 (soort van) draaiend via een bordje van @immrmkw (waarvoor mijn dank!).
Alles werkt eigenlijk naar verwachting, zolang ik de known_list niet invul (dus ik kan mooi meegenieten met de installatie van alle buren om me heen). Ik zie mijn volledige installatie, kan temperaturen aanpassen, klepstanden bekijken, OpenTherm-data uitlezen van de OTB, etcetera.
Nu wil ik ook mijn mechanische ventilatie toevoegen, en moet ik dus werken met het schema en de known_list.
Schema invullen heeft geen negatief effect, maar ook maar één regel toevoegen aan de known_list zorgt voor de onderstaande fout in de logs:

code:

2026-01-19 21:10:51.454 ERROR (MainThread) [homeassistant.config_entries] Error setting up entry RAMSES RF for ramses_cc
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/config_entries.py", line 762, in __async_setup_with_context
    result = await component.async_setup_entry(hass, self)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/ramses_cc/__init__.py", line 168, in async_setup_entry
    await broker.async_setup()
  File "/config/custom_components/ramses_cc/broker.py", line 147, in async_setup
    if v.get(CONF_COMMANDS)
       ^^^^^
AttributeError: 'NoneType' object has no attribute 'get'

Wat ik ook invul aan devices in de known_list, ik blijf bovenstaande fout houden. Inmiddels weet ik zo goed en zo kwaad niet meer waar ik het moet zoeken...
Ik heb de integratie al gewist, opnieuw gedownload, cache gewist, opnieuw herladen na het wissen van cache, maar de boel werkt niet totdat ik de known_list leeghaal.
Is dit nu iets wat ik zelf fout doe, of is dit een bug?

[ Voor 5% gewijzigd door oshiro op 19-01-2026 21:25 ]

[ebroerse]

oshiro schreef op maandag 19 januari 2026 @ 21:21:
Is dit nu iets wat ik zelf fout doe, of is dit een bug?

In (maintainer van Ramses RF) heb n.a.v. je post een nieuw issue 444 op GitHub geopend.
Heb wel meer info van je nodig.
Voeg daar dus zo veel mogelijk info toe, dan zal ik er naar kijken.

[oshiro]

ebroerse schreef op maandag 19 januari 2026 @ 23:25:
[...]


In (maintainer van Ramses RF) heb n.a.v. je post een nieuw issue 444 op GitHub geopend.
Heb wel meer info van je nodig.
Voeg daar dus zo veel mogelijk info toe, dan zal ik er naar kijken.

Ik heb de data aan het issue toegevoegd, mocht je nog meer nodig hebben hoor ik het graag!

[oshiro]

ebroerse schreef op maandag 19 januari 2026 @ 23:25:
[...]


In (maintainer van Ramses RF) heb n.a.v. je post een nieuw issue 444 op GitHub geopend.
Heb wel meer info van je nodig.
Voeg daar dus zo veel mogelijk info toe, dan zal ik er naar kijken.

Zoals je al had gezien lijkt het issue nu verholpen te zijn door iedere entry in de known_list een alias mee te geven. Alles draait nu!

Wel iets wat me opvalt: nu de known_list ingevuld is krijg ik voor de zones niet meer de "verbonden apparaten" te zien. Dat was voorheen wel zo, voordat ik de lijst had ingevuld.
Is dat simpelweg een kwestie van wachten tot het schema automatisch is opgebouwd?
Ik vind het wel fijn om per zone ook te zien welke TRV (hr92) en THM (honeywel round wireless) eraan hangen.
Die apparaten staan individueel wel in de lijst met apparaten, maar niet volgens het juiste schema (dus gekoppeld aan de zone).

Edit: dit is nu allemaal in orde, onder de zones hangen nu keurig de juiste apparaten.
Nu moet ik enkel nog de details invullen zoals beschreven in de wiki: op de juiste manier de OTB in het schema hangen, en voor de woonkamer de controller als sensor configureren (ik gebruik daar een BDR91 om een wasventiel te schakelen op een regelafsluiter die alle 6 de convectors/radiators van de benedenverdieping schakelt, dat was wat voordeliger dan 6x een HR92 met 6 nieuwe ventielen op de convectors en radiators).

[ Voor 20% gewijzigd door oshiro op 20-01-2026 14:09 ]

[ebroerse]

Net uit in HACS: Ramses RF 0.53.3, een pre-release die niet vanzelf verschijnt. Selecteer hem in HACS > Ramses RF > Download > Need a different version menu.

Bevat stevige veranderingen aan de broker>coordinator code, service acties en asynchrone koppeling met de ramses_rf library. Dit lost waarschuwingen over ‘blocking calls’ op.

Heb het hier al prima draaien, maar het leek me beter dat meer mensen even 24h testen of het ook bij hen thuis werkt. Zo niet, dan kan je met HACS terug naar 0.53.2 🥶

Succes!

[Kriseh]

ebroerse schreef op dinsdag 20 januari 2026 @ 15:54:
Net uit in HACS: Ramses RF 0.53.3, een pre-release die niet vanzelf verschijnt. Selecteer hem in HACS > Ramses RF > Download > Need a different version menu.

Bevat stevige veranderingen aan de broker>coordinator code, service acties en asynchrone koppeling met de ramses_rf library. Dit lost waarschuwingen over ‘blocking calls’ op.

Heb het hier al prima draaien, maar het leek me beter dat meer mensen even 24h testen of het ook bij hen thuis werkt. Zo niet, dan kan je met HACS terug naar 0.53.2 🥶

Succes!

Heb hem voor je geïnstalleerd, wil je dat ik nog specifiek ergens op let? of iets test?

[Wimpie70]

@ebroerse yeah, ik kreeg een

code:

RuntimeError: Detected that custom integration 'ramses_cc' calls hass.async_create_task from a thread other than the event loop, which may cause Home Assistant to crash or data to corrupt. For more information, see https://developers.home-assistant.io/docs/asyncio_thread_safety/#hassasync_create_task at custom_components/ramses_cc/services.py, line 114: lambda _: self.hass.async_create_task(. Please create a bug report at https://github.com/ramses-rf/ramses_cc/issues

Fix is onderweg

[ebroerse]

Kriseh schreef op dinsdag 20 januari 2026 @ 16:37:
[...]
Heb hem voor je geïnstalleerd, wil je dat ik nog specifiek ergens op let? of iets test?

Zonder en mét de SQLite optie verwacht ik minder foutmeldingen over ‘blocking calls’ bij (her)start en als ‘s nachts het ramses packetlog een nieuwe file opent (“rollover”).

Wie evohome heeft, ziet hopelijk sneller updates van sensors.
Verder is het vooral achter de schermen beter in modules/files opgedeeld.
We hebben nu veel meer testen, bijna 100%, maar de praktijk is de echte test.
Klein dingetje: de parser is aangepast voor betichten van een nieuwe (?) versie van de Siber Evo2 WTW.

[asaki]

Klinkt goed! Ik zal hem vanavond eens installeren.

[oshiro]

ebroerse schreef op dinsdag 20 januari 2026 @ 17:54:
[...]


Zonder en mét de SQLite optie verwacht ik minder foutmeldingen over ‘blocking calls’ bij (her)start en als ‘s nachts het ramses packetlog een nieuwe file opent (“rollover”).

Wie evohome heeft, ziet hopelijk sneller updates van sensors.
Verder is het vooral achter de schermen beter in modules/files opgedeeld.
We hebben nu veel meer testen, bijna 100%, maar de praktijk is de echte test.
Klein dingetje: de parser is aangepast voor betichten van een nieuwe (?) versie van de Siber Evo2 WTW.

Ik heb hem ook geïnstalleerd, ik zie op dit moment weinig slechts voorbij komen in de logs.

Nu heb ik een vergelijkbaar issue als hier: https://github.com/ramses-rf/ramses_cc/issues/424

1. Ook ik krijg een unknown error bij het wijzigen van de settings vanuit de fan-tegel
2. De aangemaakte entities kloppen niet: exhaust fan speed wordt voor zover ik weet niet gemeten, maar de gerapporteerde waarde zweeft continu tussen 1, 1,5 en 2%. Wat dit zou moeten voorstellen weet ik niet (misschien luchtvochtigheid verkeerd omgerekend?)
3. De settings zoals teruggemeld door de ventilator kloppen niet ("off" of "away" wordt trickle, "high" wordt medium, "automatisch" wordt boost, etcetera)

Wanneer ik een setting wijzig vanuit de fan-tegel krijg ik de volgende fout in de logs:

code:

2026-01-21 12:39:16.747 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection] [547496400736] Unexpected exception
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 278, in handle_call_service
    response = await hass.services.async_call(
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    ...<7 lines>...
    )
    ^
  File "/usr/src/homeassistant/homeassistant/core.py", line 2819, in async_call
    response_data = await coro
                    ^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/core.py", line 2862, in _execute_service
    return await target(service_call)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 832, in entity_service_call
    single_response = await _handle_entity_call(
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^
        hass, entity, func, data, call.context
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 904, in _handle_entity_call
    result = await task
             ^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/climate/__init__.py", line 577, in async_handle_set_hvac_mode_service
    await self.async_set_hvac_mode(hvac_mode)
  File "/usr/src/homeassistant/homeassistant/components/climate/__init__.py", line 585, in async_set_hvac_mode
    await self.hass.async_add_executor_job(self.set_hvac_mode, hvac_mode)
  File "/usr/local/lib/python3.13/concurrent/futures/thread.py", line 59, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/usr/src/homeassistant/homeassistant/components/climate/__init__.py", line 581, in set_hvac_mode
    raise NotImplementedError
NotImplementedError

Het gaat om een Orcon MVS-15. Service calls werken exact zoals de bedoeling zou moeten zijn, met fake remote.

Ik heb in de known list ook al dit gezet, helpt nog niet (id van de afstandbediening bij bound):

code:

"32:231021":
  alias: Orcon MVS-15 mechanische ventilatie
  bound: "29:172615"
  class: FAN

Nu las ik al dat dit niet eenvoudig te voorspellen is vanwege gebrek aan standaardisatie, en dat jullie werken aan een manier om hier beter mee om te gaan.
Zijn er dingen die ik kan doen om dit te verbeteren in mijn setup?
En zijn er dingen waarmee ik kan helpen of die ik kan analyseren om de entities beter te laten matchen?

[ Voor 33% gewijzigd door oshiro op 21-01-2026 12:59 ]

[werkmane]

oshiro schreef op woensdag 21 januari 2026 @ 12:54:
[...]

Ik heb hem ook geïnstalleerd, ik zie op dit moment weinig slechts voorbij komen in de logs.

Nu heb ik een vergelijkbaar issue als hier: https://github.com/ramses-rf/ramses_cc/issues/424

1. Ook ik krijg een unknown error bij het wijzigen van de settings vanuit de fan-tegel
2. De aangemaakte entities kloppen niet: exhaust fan speed wordt voor zover ik weet niet gemeten, maar de gerapporteerde waarde zweeft continu tussen 1, 1,5 en 2%. Wat dit zou moeten voorstellen weet ik niet (misschien luchtvochtigheid verkeerd omgerekend?)
3. De settings zoals teruggemeld door de ventilator kloppen niet ("off" of "away" wordt trickle, "high" wordt medium, "automatisch" wordt boost, etcetera)

Hier is nog beter integratie nodig voor de Orcon unit denk ik (ik heb hetzelfde, maar heb een eigen dashboard gemaakt)
T.a.v. punt 2: dit is de fan state bij de Orcon MV unit: dus 2=auto, 0=away, 0.5=low,1=medium, 1.5=high.
Dit lijkt in de huidige implementatie nog niet goed gemapt naar de beschrijvingen die je onder 3 vermeld.

[oshiro]

werkmane schreef op woensdag 21 januari 2026 @ 13:24:
[...]

Hier is nog beter integratie nodig voor de Orcon unit denk ik (ik heb hetzelfde, maar heb een eigen dashboard gemaakt)
T.a.v. punt 2: dit is de fan state bij de Orcon MV unit: dus 2=auto, 0=away, 0.5=low,1=medium, 1.5=high.
Dit lijkt in de huidige implementatie nog niet goed gemapt naar de beschrijvingen die je onder 3 vermeld.

Klopt het dat dit onder het 31D9 bericht valt, wat wordt geparset in ramses.py? Het lijkt erop dat de berichten die de fan uitstuurt vrij kort zijn. Zie bijvoorbeeld (29:172615 is de fake remote):


Fan naar standje 3 (high):

code:

2026-01-21T07:27:20.621078 000  I --- 29:172615 32:231021 --:------ 22F1 003 000304
2026-01-21T07:27:20.662552 054  I --- 32:231021 --:------ 32:231021 31D9 003 000003
2026-01-21T07:27:21.340759 054  I --- 32:231021 --:------ 32:231021 31D9 003 000003

Fan naar standje 1 (low):

code:

2026-01-21T07:27:32.792946 000  I --- 29:172615 32:231021 --:------ 22F1 003 000104
2026-01-21T07:27:32.834574 054  I --- 32:231021 --:------ 32:231021 31D9 003 000001
2026-01-21T07:27:33.351378 054  I --- 32:231021 --:------ 32:231021 31D9 003 000001

Fan naar standje Auto:

code:

2026-01-21T07:27:41.812106 000  I --- 29:172615 32:231021 --:------ 22F1 003 000404
2026-01-21T07:27:41.854719 054  I --- 32:231021 --:------ 32:231021 31D9 003 000004

En hier nog iets dat ik opving:

code:

2026-01-21T07:29:29.512315 ...  I --- 29:172615 32:231021 --:------ 10E0 038 000001C894030167FFFFFFFFFFFF1B0807E4564D492D313557534A3533000000000000000000 # 10E0| I|29:172615
<knip>
2026-01-21T07:29:29.542172 ...  I --- 32:231021 --:------ 32:231021 31D9 003 000004 # 31D9| I|32:231021|00 (00)

[ Voor 10% gewijzigd door oshiro op 21-01-2026 15:28 ]

[ebroerse]

werkmane schreef op woensdag 21 januari 2026 @ 13:24:
[...]
Hier is nog betere integratie nodig voor de Orcon unit denk ik (ik heb hetzelfde, maar heb een eigen dashboard gemaakt)

Ik raad sowieso iedereen aan om eigen dashboards te maken, want het valt niet te mappen. De ene fan stuurt een 'mode' in het veld waar het andere merk een 'speed' doorgeeft. En in HA kan je niet 1:1 zien met welk merk je te maken hebt, althans niet in de bestaande Ramses RF code. Wel een beetje, maar hoe meer fans en wtw's we willen ondersteunen hoe vaker je ontdekt dat er geen unieke kenmerken in hun berichtjes zitten.
En het kan zelfs na een firmware update veranderen!

Voor de korte termijn kunnen we in de wiki wel dashboard yaml per merk delen.

[Wimpie70]

Voor Orcon kan je ook even kijken naar Ramses Extras. Daar zit een HVAC FAN CARD in die nog steeds prima werkt met de laatste versie van Ramses RF (ORCON 300 WTW).
De commando's die verstuurd worden zijn niet afhankelijk van je in je 'Known Device ID's' hebt ingevuld in Ramses RF. Wel is het handig om bij je FAN een bound: "12:345678" in te vullen (zie de wiki). Deze wordt gebruikt om de commando's mee te versturen.
Ook kan je er de 2411 configuratie entities mee bekijken en veranderen.
Op dit moment ben ik bezig met een debug feature, Deze zal beschikbaar zijn in de komende versie.
Ramses Extras is nu ook te installeren via HACS.

[oshiro]

ebroerse schreef op woensdag 21 januari 2026 @ 20:47:
[...]


Ik raad sowieso iedereen aan om eigen dashboards te maken, want het valt niet te mappen. De ene fan stuurt een 'mode' in het veld waar het andere merk een 'speed' doorgeeft. En in HA kan je niet 1:1 zien met welk merk je te maken hebt, althans niet in de bestaande Ramses RF code. Wel een beetje, maar hoe meer fans en wtw's we willen ondersteunen hoe vaker je ontdekt dat er geen unieke kenmerken in hun berichtjes zitten.
En het kan zelfs na een firmware update veranderen!

Voor de korte termijn kunnen we in de wiki wel dashboard yaml per merk delen.

Hooguit dat de gebruiker per apparaat een merk/model/type kan invullen in bijvoorbeeld de known_list of het schema, en dat op die manier de juiste mapping geselecteerd kan worden, maar ik kan me voorstellen dat dat nogal wat werk is...

In de tussentijd heb ik een template sensor gemaakt om de mapping in orde te krijgen. Vanuit de GUI in dit geval:

code:

{% set t = states('sensor.32_231021_fan_info') %}
{% if t == '1 (trickle)' %} 1 (Low)
{% elif t == '2 (low)' %} 2 (Medium)
{% elif t == '3 (medium)' %} 3 (High)
{% elif t == '4 (boost)' %} Auto
{% elif t == 'off' %} off
{% else %} unavailable
{% endif %}

Code uiteraard naar smaak aan te passen, maar laat de "off" staan.
Minimalistisch dashboard op basis van bubble card:


YAML (de sensor fan_info is de bovengenoemde sensor template):

code:

type: custom:bubble-card
card_type: sub-buttons
sub_button:
  main: []
  bottom:
    - tap_action:
        action: perform-action
        perform_action: remote.send_command
        data:
          command: low
        target:
          entity_id: remote.29_172615
      content_layout: icon-left
      icon: mdi:fan-speed-1
    - tap_action:
        action: perform-action
        perform_action: remote.send_command
        data:
          command: medium
        target:
          entity_id: remote.29_172615
      content_layout: icon-left
      icon: mdi:fan-speed-2
    - tap_action:
        action: perform-action
        perform_action: remote.send_command
        data:
          command: high
        target:
          entity_id: remote.29_172615
      content_layout: icon-left
      icon: mdi:fan-speed-3
    - tap_action:
        action: perform-action
        perform_action: remote.send_command
        data:
          command: auto
        target:
          entity_id: remote.29_172615
      content_layout: icon-left
      icon: mdi:fan-auto
    - tap_action:
        action: perform-action
        perform_action: remote.send_command
        data:
          command: away
        target:
          entity_id: remote.29_172615
      content_layout: icon-left
      icon: mdi:fan-off
    - entity: sensor.fan_info
      show_last_changed: false
      show_last_updated: false
      show_state: true
      show_attribute: false
      tap_action:
        action: none
      content_layout: icon-left
      show_icon: false
rows: 0.938

Wimpie70 schreef op woensdag 21 januari 2026 @ 21:16:
Voor Orcon kan je ook even kijken naar Ramses Extras. Daar zit een HVAC FAN CARD in die nog steeds prima werkt met de laatste versie van Ramses RF (ORCON 300 WTW).

Dit ga ik even bekijken!

Wel is het handig om bij je FAN een bound: "12:345678" in te vullen (zie de wiki). Deze wordt gebruikt om de commando's mee te versturen.

Ik ben aan het zoeken, maar ik kan deze in geen van beide wiki's vinden!

[ Voor 27% gewijzigd door oshiro op 21-01-2026 22:40 ]

[Wimpie70]

@oshiro Je hebt gelijk, het is uit de wiki verdwenen, ik zal het toevoegen.

Zet zoiets als dit in je Known devices:

code:

"37:168270":
  class: REM
"32:153289":
  bound: "37:168270"
  class: FAN

De 'bound' trait is ook te gebruiken met een aantal service calls in Ramses RF zelf.
Ramses Extras zoekt deze bound REM op en gebruikt hem om berichten mee te verzenden.

Als je Rames Extras installeerd kan je in de configuratie aan aantal 'features' aanzetten. In dit geval de 'hvac fan card'. Hierna moet je HA herstarten en ook je browser verversen (met een harde clear cache nadat HA volledig is opgestart). Dit is nodig voor registratie van de nieuwe kaart, welke daarna in de dashboards beschikbaar zou moeten komen.
Bij het toevoegen van de kaart geef je het id van je FAN op, en is dan klaar voor gebruik. De benodigde commando's maakt ie zelf.
Ramses Extras is een framework, features kunnen worden toegevoegd (er zitten er al een paar in) waarbij het basiswerk (entities creeren, registratie cards, websockets en meer) door het framework wordt gedaan.

[ Voor 77% gewijzigd door Wimpie70 op 22-01-2026 08:53 ]

[ebroerse]

Er is weer een volgende pre-release uit met fixes van Ramses RF, versie 0.53.4.
Willen mensen die nu testen met 0.53.3 in HACS alvast updaten naar 0.53.4? Dan kijken we allemaal naar dezelfde (test) versie…

[akatar]

Nooit geweten dat hier een draadje loopt over de ramsesrf.

Ik heb sinds de laatste paar updates het probleem dat het na ongeveer een halve dag niet meer werkt, geen updates meer naar en van mijn evohome.

de log laat het volgende zien:
Logger: ramses_tx.protocol
Bron: runner.py:289
Eerst voorgekomen: 12:17:46 (1969 gebeurtenissen)
Laatst gelogd: 16:59:03

QosProtocol(WantEcho, len(queue)=0): Impersonating device: HGI:000730, for pkt: 2401|RQ|10:032338, NB: non-evofw3 gateways can't impersonate!
QosProtocol(IsInIdle, len(queue)=0): Impersonating device: HGI:000730, for pkt: 3220|RQ|10:032338|00, NB: non-evofw3 gateways can't impersonate!
QosProtocol(WantEcho, len(queue)=0): Impersonating device: HGI:000730, for pkt: 3EF0|RQ|10:032338, NB: non-evofw3 gateways can't impersonate!
QosProtocol(WantEcho, len(queue)=0): Impersonating device: HGI:000730, for pkt: 2349| W|01:205485|00, NB: non-evofw3 gateways can't impersonate!
QosProtocol(WantEcho, len(queue)=1): Impersonating device: HGI:000730, for pkt: 2349| W|01:205485|00, NB: non-evofw3 gateways can't impersonate!

ik heb een hgi80 in gebruik en heb zelf geen idee wat hier het probleem is?
een herstart van home assistent lost het op voor ongeveer een halve dag.

[ebroerse]

akatar schreef op zondag 25 januari 2026 @ 17:02:

Ik heb sinds de laatste paar updates het probleem dat het na ongeveer een halve dag niet meer werkt, geen updates meer naar en van mijn evohome.

Welkom. Vergelijkbare problemen met evohome zijn ook door anderen gemeld, zie de Issues in de GitHub repo.
Heb wat meer context nodig om je te helpen:
Welke versie van Ramses RF (HA integratie) draai je?
Met of zonder SQLite MessageIndex optie ingeschakeld?

[asaki]

Ik ben vooral benieuwd hoe je aan die hgi80 bent gekomen

[akatar]

ebroerse schreef op maandag 26 januari 2026 @ 15:53:
[...]


Welkom. Vergelijkbare problemen met evohome zijn ook door anderen gemeld, zie de Issues in de GitHub repo.
Heb wat meer context nodig om je te helpen:
Welke versie van Ramses RF (HA integratie) draai je?
Met of zonder SQLite MessageIndex optie ingeschakeld?

Ik moet nu eerlijk zeggen dat ik uit pure ergernis de stekker er uit heb gehaald (x64 mini pc) en dan na het opstarten werkt nu alles na een dag nog steeds.
de problemen die ik had kwamen altijd na een paar uur, en een herstart loste het weer even voor een paar uur op.

deze meldingen zijn er trouwens nog steeds:
Logger: ramses_tx.protocol
Bron: runner.py:289
Eerst voorgekomen: 25 januari 2026 om 18:17:34 (11382 gebeurtenissen)
Laatst gelogd: 18:20:36

QosProtocol(IsInIdle, len(queue)=0): Impersonating device: HGI:000730, for pkt: 2401|RQ|10:032338, NB: non-evofw3 gateways can't impersonate!
QosProtocol(IsInIdle, len(queue)=0): Impersonating device: HGI:000730, for pkt: 0008|RQ|13:081029, NB: non-evofw3 gateways can't impersonate!
QosProtocol(IsInIdle, len(queue)=0): Impersonating device: HGI:000730, for pkt: 3EF1|RQ|13:081029, NB: non-evofw3 gateways can't impersonate!
QosProtocol(IsInIdle, len(queue)=0): Impersonating device: HGI:000730, for pkt: 3EF0|RQ|10:032338, NB: non-evofw3 gateways can't impersonate!
QosProtocol(IsInIdle, len(queue)=0): Impersonating device: HGI:000730, for pkt: 3EF1|RQ|13:182285, NB: non-evofw3 gateways can't impersonate

de sqlite staat uit

Dus om het af te ronden, het werkt nu ineens allemaal weer maar de fout meldingen blijven wel komen,

[akatar]

asaki schreef op maandag 26 januari 2026 @ 17:03:
Ik ben vooral benieuwd hoe je aan die hgi80 bent gekomen

eeh jaren geleden besteld en betaald

[Kriseh]

Vraagje voor de experts of ervaringsdeskundigen: Ik kan mijn Orcon MVS-15R heel gemakkelijk via known list & actions aansturen (door device-id van fysieke remote mee te geven). Kan dit ook voor Evohome BDR-91 schakelmodules? of moet ik dan die omslachtige werkwijze gebruiken zoals in de Ramses Wiki (ESP32 binden met BDR91 en keep-alive packets blijven sturen)? Idealiter wil ik gewoon doen alsof ik de evohome confroller ben zegmaar

[RVerheijden]

vliegnerd schreef op woensdag 20 november 2024 @ 11:49:
Uit de serie "experimenten met cc1101 bordjes":

Ik heb geprobeerd om een hele minimale HGI-80 ramses naar serial gateway te maken (ramses_esp/evofw3 kloon).

Op een PCB dat ik gemaakt heb voor een arduino pro micro om evofw3 te draaien had ik al plek gemaakt voor een ESP32 C3 supermini. Zo'n bordje heeft ook gewoon Wifi, maar slechts één RISC-V core in plaats van de 2 lx6 cores van de ESP32 S3. Omdat ramses ESP één core gebruikt voor cc1101 RF communicatie en de andere core voor Wifi/MQTT verwachtte ik eigenlijk dat deze single core oplossing niet zou werken met Wifi. Maar het werkt toch, zie verderop. Bedraad aansluiten is hier wel echt de bedoeling.

Ik heb ook deze zelfde unit met ESP S3 heb alleen nog niet uitgevoeld hoe ik die wifi aan de praat krijg. Wil heb het liefst via het netwerk aansturen.


Voordeel is dat een ESP32 C3 supermini ongeveer 3 euro kost. Dus veel goedkoper en makkelijker verkrijgbaar dan een Arduino pro micro. Vandaar mijn idee om zo'n ding te bouwen als nog goedkoper alternatief voor een evofw3 bordje.

Het bordje ziet er dan zo uit:
[Afbeelding]

Dit draait ramses ESP met slechts minimale aanpassingen: https://github.com/tomkooij/ramses_esp_c3/
Verrassend genoeg werkt Wifi/MQTT eigenlijk prima. Ook in mijn "drukke" RF omgeving. Er zijn 100 apparaten met ongeveer 1 bericht per seconde in mijn nieuwbouwblok.
Maar dat is eigenlijk niet mijn "bedoelde" gebruik: Dit is in ieder geval een hele goedkope zelfbouw oplossing voor een ontvanger die je bedraadt (USB C) aansluit.

PCB: https://github.com/tomkooij/promicro-cc1101

[ebroerse]

Er staat weer een volgende Ramses RF pre-release in HACS: versie 0.53.5.
Wie al een pre-release draait, raad ik aan om deze te installeren via het uitklapmenu.

[asaki]

Ik heb hier nog een draadloze Honeywell gong liggen met een Honeywell DCP917S die volgens de sticker ook op 868MHz werkt. Ik zie alleen in de logs nergens iets langskomen als ik de gong activeer.



Is dit stiekem een ander protocol dan de thermostaat zaken?

[vliegnerd]

asaki schreef op maandag 2 februari 2026 @ 10:29:
Ik heb hier nog een draadloze Honeywell gong liggen met een Honeywell DCP917S die volgens de sticker ook op 868MHz werkt. Ik zie alleen in de logs nergens iets langskomen als ik de gong activeer.


[Afbeelding]
Is dit stiekem een ander protocol dan de thermostaat zaken?

Het zou kunnen dat dit (nieuwe?) device RAMSES III ipv II gebruikt. Zelfde frequentie, beetje ander protocol met encryptie.
Experimentele versies van ramses_esp kunnen het ontvangen, maar door de encryptie is het nog niet bruikbaar: https://github.com/IndaloTech/ramses_esp/issues/31

[asaki]

Volgens mij is dit gebaseerd op Honeywell Activelink, dat was toch Ramses II?

Nu zit ik gewoon naar de Home Assistant logs te kijken, is dat de goede plek of moet ik verder nog iets doen?

[ebroerse]

asaki schreef op maandag 2 februari 2026 @ 13:00:
Volgens mij is dit gebaseerd op Honeywell Activelink, dat was toch Ramses II?

Nu zit ik gewoon naar de Home Assistant logs te kijken, is dat de goede plek of moet ik verder nog iets doen?

Als je nog geen gong-device in je Ramses system schema hebt staan, maar wel het schuifje "Accepteer alleen berichten van erkende device-IDs" aan staat in config, dan wordt hij niet getoond.
Je kunt het schuifje "Log alle MQTT topics" inschakelen. Misschien dat je dan het nieuwe device (adres) ziet langskomen.

[Burn_and_Fire]

akatar schreef op maandag 26 januari 2026 @ 18:23:
[...]


Ik moet nu eerlijk zeggen dat ik uit pure ergernis de stekker er uit heb gehaald (x64 mini pc) en dan na het opstarten werkt nu alles na een dag nog steeds.
de problemen die ik had kwamen altijd na een paar uur, en een herstart loste het weer even voor een paar uur op.

deze meldingen zijn er trouwens nog steeds:
Logger: ramses_tx.protocol
Bron: runner.py:289
Eerst voorgekomen: 25 januari 2026 om 18:17:34 (11382 gebeurtenissen)
Laatst gelogd: 18:20:36

QosProtocol(IsInIdle, len(queue)=0): Impersonating device: HGI:000730, for pkt: 2401|RQ|10:032338, NB: non-evofw3 gateways can't impersonate!
QosProtocol(IsInIdle, len(queue)=0): Impersonating device: HGI:000730, for pkt: 0008|RQ|13:081029, NB: non-evofw3 gateways can't impersonate!
QosProtocol(IsInIdle, len(queue)=0): Impersonating device: HGI:000730, for pkt: 3EF1|RQ|13:081029, NB: non-evofw3 gateways can't impersonate!
QosProtocol(IsInIdle, len(queue)=0): Impersonating device: HGI:000730, for pkt: 3EF0|RQ|10:032338, NB: non-evofw3 gateways can't impersonate!
QosProtocol(IsInIdle, len(queue)=0): Impersonating device: HGI:000730, for pkt: 3EF1|RQ|13:182285, NB: non-evofw3 gateways can't impersonate

de sqlite staat uit

Dus om het af te ronden, het werkt nu ineens allemaal weer maar de fout meldingen blijven wel komen,

Sinds vandaag heb ik ook ineens die impersonating device fouten. Mijn Evohome entities vallen na een tijdje uit op status "niet beschikbaar". Reboot lijkt tijdelijk te helpen. Beschik ook over een HGI80. Werkte al maanden rotsvast. De start van het gedoe is ontstaan bij update van HA 2026.1.3 of de update naar de nieuwste HAOS (17.0). Ik zat nog op Ramses 0.53.2 en ben net overgestapt op de 0.54.0 versie die net vanmiddag uitgebracht is. Hopelijk biedt dat de oplossing.

[akatar]

@Burn_and_Fire Tot op heden werkt het hier nog steeds, ondanks deze foutmeldingen.

[ebroerse]

Voordat je HA Core bijwerkt naar 2026.2.0, update dan eerst in HACS naar Ramses RF 0.54.0, de nieuwste release.

[Burn_and_Fire]

akatar schreef op woensdag 4 februari 2026 @ 20:08:
@Burn_and_Fire Tot op heden werkt het hier nog steeds, ondanks deze foutmeldingen.

Bij mij werkt het inmiddels ook weer. Ik ben even helemaal opnieuw begonnen met de Ramses RF setup. Gelijk ook even even even het schema en erkende device's vastgezet. Dat stond toch nog op mijn actieijstje. Eerst alleen even die device id's zichtbaar. Vanochtend ook weer de namen. Tot dusverre weer 24 uur stabiel.

[ebroerse]

In HACS staat weer een update van Ramses RF 0.54.1.

[ebroerse]

Ramses RF 0.54.2, net uit in HACS, bevat een fix voor een bug in 0.54.1 die CH Zones liet vastlopen.

[aj_prof]

ebroerse schreef op donderdag 5 februari 2026 @ 08:18:
Voordat je HA Core bijwerkt naar 2026.2.0, update dan eerst in HACS naar Ramses RF 0.54.0, de nieuwste release.

Heeft iemand enig idee wat ik moet doen als ik per "ongeluk" HA heb geüpdatet naar 2026.2.2 voordat ik Ramses naar 0.54.2 gegaan? Geen signal meer en alles staat op unavailable.

[JoepW]

aj_prof schreef op maandag 16 februari 2026 @ 21:47:
[...]

Heeft iemand enig idee wat ik moet doen als ik per "ongeluk" HA heb geüpdatet naar 2026.2.2 voordat ik Ramses naar 0.54.2 gegaan? Geen signal meer en alles staat op unavailable.

Is het niet op te lossen met een reload van ramses?

[JoepW]

@ebroerse Ik gebruik nu al enige tijd RAMSES RF met een Nanocul v3 (USB Serial - /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0, s/n: n/a - 1A86:7523) tbv mijn EvoHome installatie met 12 Zones, waarvan 3 vloerzones via de HCC100.
In principe draait het probleemloos, maar ik krijg de devices en entities die spookjes zijn of van een ander device buiten de knownlist maar niet weg. Deleten gaat niet dus heb ik ze maar op disabled gezet. Maar dat lijkt mij niet de juiste weg,

System Options van Ramses RF staan als volgt:


Ik heb de Known List als volgt gevuld:

code:

"01:094566":
  alias: Evohome Controller
  class: CTL
"02:074869":
  alias: HCC100
  class: UFC
"04:007750":
  alias: Badkamer 2 radiator klep
  class: TRV
"04:019489":
  alias: Zolder radiator klep
  class: TRV
"04:019491":
  alias: Handdoeken radiator klep
  class: TRV
"04:025691":
  alias: Toilet radiator klep
  class: TRV
"04:025733":
  alias: Dorien radiator klep
  class: TRV
"04:025739":
  alias: Joep radiator klep
  class: TRV
"04:157354":
  alias: Hal radiator klep
  class: TRV
"04:157356":
  alias: Slaapkamer radiator klep
  class: TRV
"04:157358":
  alias: Gang radiator klep
  class: TRV
"13:215304":
  alias: Evohome Remeha Relais
  class: BDR
"18:262143":
  alias: Ramses Bridge
  class: HGI
"34:041481":
  alias: Gang round wireless
  class: THM
"34:052245":
  alias: Badkamer round wireless
  class: THM
"34:227157":
  alias: Keuken round wireless
  class: THM
"34:227159":
  alias: Woonkamer round wireless
  class: THM
"34:232285":
  alias: Joep round wireless
  class: THM
"34:238783":
  alias: Dorien round wireless
  class: THM
"34:238785":
  alias: Hal round wireless
  class: THM
"34:238787":
  alias: Slaapkamer round wireless
  class: THM

en


Alleen blijf ik geconfronteerd worden met een stuk of 20-30 ghosts die ik met geen mogelijkheid verwijderd krijg. Sommige hebben ook entities en sommige niet.

Ik heb natuurlijk de cache geleegd en reload gedaan. En zelfs het cache file in config/.storage verwijderd, maar het helpt allemaal niks.

Ik had me er bij neergelegd, maar nu jij zo ontzettend goed bezig bent met het opwaarderen van de software (waarvoor grote dank) begint het me toch weer te irriteren.

Kan jij mij helpen?

----
Toevoeging: Op mijn testsysteem draai ik Ramses RF met een ESP dongle (niet MQTT) en daar lukte het met wel om alle spookzaken te verwijderen.

[oshiro]

JoepW schreef op dinsdag 17 februari 2026 @ 11:24:
@ebroerse Ik gebruik nu al enige tijd RAMSES RF met een Nanocul v3 (USB Serial - /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0, s/n: n/a - 1A86:7523) tbv mijn EvoHome installatie met 12 Zones, waarvan 3 vloerzones via de HCC100.
In principe draait het probleemloos, maar ik krijg de devices en entities die spookjes zijn of van een ander device buiten de knownlist maar niet weg. Deleten gaat niet dus heb ik ze maar op disabled gezet. Maar dat lijkt mij niet de juiste weg,

System Options van Ramses RF staan als volgt:
[Afbeelding]

Ik heb de Known List als volgt gevuld:

code:

"01:094566":
  alias: Evohome Controller
  class: CTL
"02:074869":
  alias: HCC100
  class: UFC
"04:007750":
  alias: Badkamer 2 radiator klep
  class: TRV
"04:019489":
  alias: Zolder radiator klep
  class: TRV
"04:019491":
  alias: Handdoeken radiator klep
  class: TRV
"04:025691":
  alias: Toilet radiator klep
  class: TRV
"04:025733":
  alias: Dorien radiator klep
  class: TRV
"04:025739":
  alias: Joep radiator klep
  class: TRV
"04:157354":
  alias: Hal radiator klep
  class: TRV
"04:157356":
  alias: Slaapkamer radiator klep
  class: TRV
"04:157358":
  alias: Gang radiator klep
  class: TRV
"13:215304":
  alias: Evohome Remeha Relais
  class: BDR
"18:262143":
  alias: Ramses Bridge
  class: HGI
"34:041481":
  alias: Gang round wireless
  class: THM
"34:052245":
  alias: Badkamer round wireless
  class: THM
"34:227157":
  alias: Keuken round wireless
  class: THM
"34:227159":
  alias: Woonkamer round wireless
  class: THM
"34:232285":
  alias: Joep round wireless
  class: THM
"34:238783":
  alias: Dorien round wireless
  class: THM
"34:238785":
  alias: Hal round wireless
  class: THM
"34:238787":
  alias: Slaapkamer round wireless
  class: THM

en
[Afbeelding]

Alleen blijf ik geconfronteerd worden met een stuk of 20-30 ghosts die ik met geen mogelijkheid verwijderd krijg. Sommige hebben ook entities en sommige niet.

Ik heb natuurlijk de cache geleegd en reload gedaan. En zelfs het cache file in config/.storage verwijderd, maar het helpt allemaal niks.

Ik had me er bij neergelegd, maar nu jij zo ontzettend goed bezig bent met het opwaarderen van de software (waarvoor grote dank) begint het me toch weer te irriteren.

Kan jij mij helpen?

----
Toevoeging: Op mijn testsysteem draai ik Ramses RF met een ESP dongle (niet MQTT) en daar lukte het met wel om alle spookzaken te verwijderen.

Ik had hier ook last van, uiteindelijk mijn gehele configuratie gebackupt (in notepad), de integratie verwijderd, de integratie opnieuw geïnstalleerd en toen waren alle ghosts weg.
Historie bleek gewoon behouden te blijven omdat de nieuwe entities exact dezelfde naam/nummering hebben als de oorspronkelijke.
Your mileage may vary, echter.

[oshiro]

Nu sta ik hier op het punt om mijn volledige Resideo Honeywell Total Connect Comfort (Europe) integratie te verwijderen omdat Ramses BIJNA alles kan wat Honeywell kan, en andere dingen uiteraard meer en beter.

Er is echter één ding wat ik mis: individuele zones uitzetten via de Climate tegels.
Plaatje 1: Honeywell climate tegel:

Plaatje 2: Ramses tegel:


De Honeywell tegels kan ik dus "uit" zetten (wat ik deze dagen veel gebruik).
Is er een manier om "uit" ook in de Ramses tegel te krijgen? Anders dan simpelweg "zet op 5 graden"?
En... Wat betekent "automatisch"?

[JoepW]

oshiro schreef op dinsdag 17 februari 2026 @ 11:50:
[...]

Ik had hier ook last van, uiteindelijk mijn gehele configuratie gebackupt (in notepad), de integratie verwijderd, de integratie opnieuw geïnstalleerd en toen waren alle ghosts weg.
Historie bleek gewoon behouden te blijven omdat de nieuwe entities exact dezelfde naam/nummering hebben als de oorspronkelijke.
Your mileage may vary, echter.

Wat bedoel je met "hele configuratie gebackupt" Dat is toch enkel de known-list. De rest is redelijk vanzelfsprekend..... Maar het vervelende is dat je de known-list enkel kan toevoegen als Ramses RF al draait en dan wordt al die "bagger" weer opgepakt is mijn ervaring...

[oshiro]

JoepW schreef op dinsdag 17 februari 2026 @ 12:20:
[...]

Wat bedoel je met "hele configuratie gebackupt" Dat is toch enkel de known-list. De rest is redelijk vanzelfsprekend..... Maar het vervelende is dat je de known-list enkel kan toevoegen als Ramses RF al draait en dan wordt al die "bagger" weer opgepakt is mijn ervaring...

Inderdaad, klopt helemaal. Bij de eerste configuratie inderdaad de known-list erin plakken. Ramses draait nog niet voordat je de wizard volledig hebt afgerond en dus pikt hij dan geen vreemde apparaten op.
Dat is precies hoe ik het heb gedaan.

Laatst heb ik een BDR met thermische motor vervangen voor een HR92. Die BDR zwerft nog steeds in mijn configuratie rond, omdat ik de boel nog niet opnieuw heb ingeladen. Als ik hem weg wil hebben, doe ik dat op bovenstaande manier.

[ebroerse]

oshiro schreef op dinsdag 17 februari 2026 @ 11:56:
...
Er is echter één ding wat ik mis: individuele zones uitzetten via de Climate tegels.

En... Wat betekent "automatisch"?

Dit is al een wat langer bestaand issue: https://github.com/ramses-rf/ramses_cc/issues/227

Zit nog geen voortgang in. Kun je jouw volledige foutlog (van dat moment) onder dat issue plakken?

Automatisch is vlg. mij (heb zelf geen CH in Ramses RF) dat de (?) thermostaat de ketel regelt (dus zonder (temporary) overrides).

[ebroerse]

JoepW schreef op dinsdag 17 februari 2026 @ 11:24:
Nanocul v3 (USB Serial)
...
dus heb ik ze maar op disabled gezet. Maar dat lijkt mij niet de juiste weg,
...

Toch precies wat ik adviseer, ook eerder op dit forum.
Je kunt in de .storage editen, en bij de een gaat dat goed maar bij de ander niet
Is vlg. mij ook een HA dingetje, dat onthouden van verdwenen entities.

Toevoeging: Op mijn testsysteem draai ik Ramses RF met een ramses_esp dongle (via USB) en daar lukte het met wel om alle spookzaken te verwijderen.

Interessant om te horen!

[ Voor 18% gewijzigd door ebroerse op 17-02-2026 20:05 ]

[oshiro]

ebroerse schreef op dinsdag 17 februari 2026 @ 15:01:
[...]


Dit is al een wat langer bestaand issue: https://github.com/ramses-rf/ramses_cc/issues/227

Zit nog geen voortgang in. Kun je jouw volledige foutlog (van dat moment) onder dat issue plakken?

Automatisch is vlg. mij (heb zelf geen CH in Ramses RF) dat de (?) thermostaat de ketel regelt (dus zonder (temporary) overrides).

In de Evohome integratie bestaat "automatisch" helemaal niet, enkel "verwarmen" en "uit".
Verwarmen betekent "schema volgen". Dus dat had wat mij betreft beter "automatisch" kunnen heten, maar goed.
Wanneer je een override doet van de temperatuur springt de voorinstelling vanzelf naar "temporary". Die kun je op "permanent" zetten zodat hij altijd zo blijft (totdat je de thermostaat weer op "afwezig" of "eco/boost" zet).

Ramses heeft enkel "verwarmen" en "automatisch". Wat je daarmee kan is me eigenlijk geheel niet duidelijk (zoals ook in het ticket staat waarnaar je linkt). Functionaliteit van de voorinstelling is identiek aan de Honeywell Home integratie. Maar ik kan de zone niet uitzetten...
Uitzetten houdt hier in feite gewoon in dat hij permanent op 5 graden setpoint wordt gezet. Ik kwam erachter dat sommige zones midden in de nacht ineens gingen verwarmen omdat het schema op 13 graden stond... En ik wil ze gewoon uit kunnen zetten.
Dat kan uiteraard ook via het schema, maar het lijkt me mooi als de functionaliteit van de Honeywell Home integratie gelijk is aan die van Ramses.

Dit is op dit moment gewoon "by design", voor zover ik weet zitten er ook helemaal geen fouten in de logs.

[asaki]

Ik ben hier ook tegen aan gelopen in Home Assistant. HVAC Mode "Off" bestaat niet. Je kan het wel via YAML inregelen maar je krijgt uiteindelijk in de logs te zien dat die mode niet wordt ondersteund. Het fijne van de Evohome Off setting is dat de een schema niet opeens een ruimte gaat verwarmen. Om dit met Ramses op te lossen zal je een automation moeten maken die bij een aanpassing van de HVAC mode (doorgaans naar Heat) moet controleren of de zone nog uit moet staan of niet. Dit zou je kunnen doen met een helper entity.

Dit is mijn automation die de temperatuur naar 5 graden zet als het raam open gaat. Als de Evohome controller dan een schema update doorvoert om te verwarmen controleert de automation of het raam nog open staat en zet de temperatuur weer naar beneden. Ik weet dat de HVAC Off mode er nog in wordt ingesteld, dit voor het geval het wel wordt ondersteund

code:

alias: Raam Open
description: Schakelt de HVAC uit als de verwarming op verwarmen staat terwijl het raam open staat OF als het raam open wordt gedaan.
triggers:
  - entity_id: climate.01_013373_04
    to: heat
    trigger: state
  - entity_id:
      - binary_sensor.raamsensor_contact
    from:
      - "off"
    to:
      - "on"
    trigger: state
    for:
      hours: 0
      minutes: 0
      seconds: 10
conditions:
  - condition: state
    entity_id: binary_sensor.raamsensor_contact
    state: "on"
  - condition: state
    entity_id: climate.01_013373_04
    state: heat
actions:
  - target:
      entity_id: climate.01_013373_04
    data:
      temperature: 5
    action: climate.set_temperature
  - target:
      entity_id: climate.01_013373_04
    data:
      hvac_mode: "off"
    action: climate.set_hvac_mode
mode: single

[ Voor 3% gewijzigd door asaki op 17-02-2026 16:39 ]

[oshiro]

asaki schreef op dinsdag 17 februari 2026 @ 16:38:
Ik ben hier ook tegen aan gelopen in Home Assistant. HVAC Mode "Off" bestaat niet. Je kan het wel via YAML inregelen maar je krijgt uiteindelijk in de logs te zien dat die mode niet wordt ondersteund. Het fijne van de Evohome Off setting is dat de een schema niet opeens een ruimte gaat verwarmen. Om dit met Ramses op te lossen zal je een automation moeten maken die bij een aanpassing van de HVAC mode (doorgaans naar Heat) moet controleren of de zone nog uit moet staan of niet. Dit zou je kunnen doen met een helper entity.

Dit is mijn automation die de temperatuur naar 5 graden zet als het raam open gaat. Als de Evohome controller dan een schema update doorvoert om te verwarmen controleert de automation of het raam nog open staat en zet de temperatuur weer naar beneden. Ik weet dat de HVAC Off mode er nog in wordt ingesteld, dit voor het geval het wel wordt ondersteund

code:

alias: Raam Open
description: Schakelt de HVAC uit als de verwarming op verwarmen staat terwijl het raam open staat OF als het raam open wordt gedaan.
triggers:
  - entity_id: climate.01_013373_04
    to: heat
    trigger: state
  - entity_id:
      - binary_sensor.raamsensor_contact
    from:
      - "off"
    to:
      - "on"
    trigger: state
    for:
      hours: 0
      minutes: 0
      seconds: 10
conditions:
  - condition: state
    entity_id: binary_sensor.raamsensor_contact
    state: "on"
  - condition: state
    entity_id: climate.01_013373_04
    state: heat
actions:
  - target:
      entity_id: climate.01_013373_04
    data:
      temperature: 5
    action: climate.set_temperature
  - target:
      entity_id: climate.01_013373_04
    data:
      hvac_mode: "off"
    action: climate.set_hvac_mode
mode: single

HVAC mode Off bestaat niet in Ramses bedoel je?
In Home Assistant zelf wordt het wel ondersteund: https://developers.home-a...docs/core/entity/climate/

Ik ben ook aan het knutselen met climate_template om de mechanische ventilatie in een climate tegel te krijgen en daar werkt "off" ook gewoon. Het is verder een bende maar daar heb ik het maar even niet over

[asaki]

Ja precies, in Ramses wordt het niet ondersteund, maar uiteraard wel in Home Assistant.

Dit is de log als je de off mode probeert in te stellen via Ramses:

code:

2026-02-17 18:02:25.289 ERROR (MainThread) [homeassistant.components.automation.raam_open_check] Error while executing automation automation.raam_open_check: HVAC mode off is not valid. Valid HVAC modes are: heat, auto

[JoepW]

oshiro schreef op dinsdag 17 februari 2026 @ 11:50:
[...]

Ik had hier ook last van, uiteindelijk mijn gehele configuratie gebackupt (in notepad), de integratie verwijderd, de integratie opnieuw geïnstalleerd en toen waren alle ghosts weg.
Historie bleek gewoon behouden te blijven omdat de nieuwe entities exact dezelfde naam/nummering hebben als de oorspronkelijke.
Your mileage may vary, echter.

Gedaan en het werkt.... Ben enkel nu om onverklaarbare reden de warmtevraag gegevens van de HCC100 kwijt. ff zoeken of ik een device te weinig heb...
Maar bedankt voor de tip..

Update: Ik had per ongeluk de HCC100 niet in de known list gezet. Dus opgelost.

[ Voor 6% gewijzigd door JoepW op 18-02-2026 16:41 ]

[aj_prof]

JoepW schreef op maandag 16 februari 2026 @ 21:59:
[...]

Is het niet op te lossen met een reload van ramses?

Bedankt! Na twee keer herladen en het volledig verwijderen van Ramses_cc werkt nu alles weer zoals het hoort.

Nog een vraag: ik heb een Orcon met 2-zone-sturing. Communiceert het 2-zone-klep ook via hetzelfde protocol? En hoe kan ik die klep toevoegen als een bekend apparaat op Ramses RF? Is het een HGI, FAN, of iets anders?

[oshiro]

Voor wat betreft het "off" zetten van een zone, vanaf regel 91 van climate.py staat het volgende:

code:

MODE_ZONE_TO_HA: Final[dict[str, str]] = {
    ZoneMode.ADVANCED: HVACMode.HEAT,
    ZoneMode.SCHEDULE: HVACMode.AUTO,
    ZoneMode.PERMANENT: HVACMode.HEAT,
    ZoneMode.TEMPORARY: HVACMode.HEAT,
}
MODE_HA_TO_ZONE: Final[dict[str, str]] = {
    HVACMode.HEAT: ZoneMode.PERMANENT,
    HVACMode.AUTO: ZoneMode.SCHEDULE,
}

PRESET_ZONE_TO_HA: Final[dict[str, str]] = {
    ZoneMode.SCHEDULE: PRESET_NONE,
    ZoneMode.TEMPORARY: PRESET_TEMPORARY,
    ZoneMode.PERMANENT: PRESET_PERMANENT,
}

Dus daarom staat "off" er niet in, er is geen "HVACMode.OFF" gedefinieerd.
Dit betekent ook dat:

• Bij override: status = Verwarmen
• Bij schema volgen: status = Automatisch

Nu zie ik verder vanaf regel 564 het volgende:

code:

async def async_set_hvac_mode(self, hvac_mode: HVACMode) -> None:
        """Set a Zone to one of its native operating modes.

        :param hvac_mode: The HVAC mode to set.
        :raises ServiceValidationError: If the mode is invalid.
        """
        try:
            if hvac_mode == HVACMode.AUTO:  # FollowSchedule
                await self.async_reset_zone_mode()
            elif hvac_mode == HVACMode.HEAT:  # TemporaryOverride
                await self.async_set_zone_mode(mode=ZoneMode.PERMANENT, setpoint=25)
            else:  # HVACMode.OFF, PermanentOverride, temp = min
                await self._device.set_frost_mode()
                self.async_write_ha_state()

Dat houdt in dat als de mode niet AUTO of HEAT is, hij dan naar set_frost_mode() moet gaan, maar kan hij überhaupt wel wat anders zijn dan AUTO of HEAT, kijkend naar bovenstaand?
Ik ben helaas te slecht in programmeren, heb weinig kaas gegeten van python en git, om zelf iets te kunnen fiksen...

Edit:
Nu heb ik dus een zone op Uit staan vanuit de Evohome integratie. En dat ziet er dan zo uit:

Dus, hier staat wel degelijk "Uit - permanent". Dat is wat je zou verwachten.
Maar in de dropdown in de tile staat dan helemaal niets:

(zelfde screenshot als eerder).
Normaliter laat de knop zelf de huidige mode zien. Maar nu niet, hij geeft enkel "Mode" weer, met als opties "Automatisch" en "Verwarmen".

[ Voor 21% gewijzigd door oshiro op 19-02-2026 17:56 ]

[ebroerse]

Er is een nieuwe Ramses RF (pre)release, met remote.send_packet fix; selecteer 0.54.3 uit de HACS Download dropdown.

[Seroendeng]

Ik probeer mijn Evohome systeem hier lokaal aan te sturen nadat de cloud dienst er meermaals uit heeft gelegen. Ik had een HGI80 gekocht en aan mijn home assistant systeem gehangen. In combinatie met mijn hybride warmtepomp (quatt systeem) ontstond er vreemd gedrag. Na wat checken met Co-Pilot lijkt het erop dat mijn HGI80 zich als een 2e controller opstelt en gaat 'vechten' met de oorspronkelijke OpenTherm controller van mijn Evohome systeem. Ik kreeg daarbij elke 10 minuten een 'CH Active turned on/off' fout.

In de HGI80 kon ik niets instellen om zich anders te gedragen dus heb ik een tweede poging gedaan met een zelfbouw bordje (ESP32 plus CC1101). Dat bordje werkt, alleen resulteert dat in hetzelfde gedrag.

Kent iemand dit probleem en is daar een oplossing voor gevonden? Op een of andere manier moet ik mijn Ramses_ESP bord anders instellen maar hoe dat moet kan ik niet vinden. Hopelijk weet iemand hier iets meer en geeft dit ook genoeg info over het probleem, anders licht nog meer toe natuurlijk.

Ik heb trouwens nu ramses_esp 0.4.8 erop staan. In de terminal probeer ik 'ota start' te doen om naar een nieuwere versie te komen maar mijn terminal lijkt niet te luisteren. Ik kan wel 'ota' typen en krijg dan de uitleg. Echter, als ik ota start type gebeurt er niets. Er staat ook geen normaal prompt waarbij ik mijn toetsenbord invoer zie. als ik het typ en op enter drukt komt het wel tevoorschijn maar wordt er niets mee gedaan. Klinkt dat ook bekend bij iemand?

[ Voor 18% gewijzigd door Seroendeng op 25-02-2026 22:11 ]

[ebroerse]

oshiro schreef op donderdag 19 februari 2026 @ 17:44:
...
Voor wat betreft het "off" zetten van een zone,
...

Dit is al eens besproken: https://github.com/ramses-rf/ramses_cc/issues/129 Er staat ook wat het probleem is.

@oshiro Kun je daar als nieuwe Comment de foutmelding en jouw antwoord op de openstaande vraag invullen?

[oshiro]

ebroerse schreef op donderdag 26 februari 2026 @ 11:54:
[...]

Dit is al eens besproken: https://github.com/ramses-rf/ramses_cc/issues/129 Er staat ook wat het probleem is.

@oshiro Kun je daar als nieuwe Comment de foutmelding en jouw antwoord op de openstaande vraag invullen?

Ah, wat goed, dat is inderdaad wat er aan de hand is!
Zoals ik zei heb ik zelf geen foutmeldingen (code werkt zoals de bedoeling is). Er ontbreekt echter functionaliteit die dus wel in de Evohome integratie zit, exact zoals het issue beschrijft.

Dat een zone niet volledig "off" kan staan klopt: hij stuurt het setpoint naar 5 graden.
Emuleren van dit gedrag is echter niet zo eenvoudig als "setpoint op 5 graden zetten", want bij "off" is het setpoint ook niet aan te passen (geloof ik, ga ik testen).

Er zijn meerdere manieren waarop het setpoint door de controller naar 5 graden wordt gepusht en wordt vastgezet. Zie ook screenshot uit handleiding :

• Vanuit Evohome integratie op Off zetten (geeft speciaal telefoon-icoon op Evohome controller display, "bediening via app")
• Raam-open-stand (geeft speciaal icoon op Evohome controller display)
• Optimale stop actief (geeft speciaal icoon op Evohome controller display)
• Warmweer regeling actief (geeft speciaal icoon op Evohome controller display)

Ik zal testen of ik via de service calls in de Ramses-integratie deze data ook tevoorschijn kan toveren. Het is interessant om te zien hoe de "off" stand vanuit de Evohome-integratie precies werkt.
Ik heb ook naar de code gekeken van de Evohome integratie maar daar kom ik niet helemaal uit...
https://github.com/home-a...onents/evohome/climate.py

Edit: nog even naar de code gekeken, en het is me wat duidelijker hoe de Evohome integratie dit aanpakt:

• Wanneer setpoint == minimum zone temp, dan HVAC_mode == off
• Wanneer HVAC_mode op Off wordt gezet, dan zone temp naar minimum
• Wanneer mode wordt geforceerd door controller (bijvoorbeeld window open) worden de min- en max temperatuur op 5 graden gezet, zodat deze ook niet omhoog kan worden gezet vanuit de integratie

Ik experimenteer hier nog wat verder mee, om te kijken of deze data via een service call naar boven komt. Zeker de warmweerregeling en optimale stop zijn interessant, de raam-openregeling is in principe af te leiden van de "window open" entity.
Dat werkt ook wanneer een controller wordt gebruikt als zone-temperatuuropnemer, ookal heeft die geen aansluiting voor een raamsensor.

[ Voor 17% gewijzigd door oshiro op 26-02-2026 15:42 ]