Mede oprichter van GoT iRacen & druk met Home Assistant
Hoe check ik dit? er is hier niet veel verkeer, mijn Evohome setje en een paar Orcon boxen (één van mijzelf, en een aantal van de buren om mijn huis heen).Wimpie70 schreef op zaterdag 2 augustus 2025 @ 13:44:
De 63:xxxxxx zie ik ook wel, maar wordt zover ik kan zien gebruikt door de ESP HGI bij druk verkeer, als doorgeefluik of intern gebruik. Kan dit bij jou ook zo zijn ?
De master in github is een development versie met de laatste wijzigingen voor een nieuwe release, Deze heeft o.a. al wel de clear cache fix, maar is nog in ontwikkeling. Er kunnen dus nog wijzigingen komen voordat deze gereleased wordt.
Ramses mapped zelf eigenlijk al vrijwel mijn hele Evohome systeem, als ik onder de controller kijk, zie ik dit:
:strip_exif()/f/image/KEKymJVge1st7G1N2xElIQo8.png?f=user_large)
Als ik vervolgens op bijv. Kantoor klik, zie ik rechts onderin, bij 'Connected Devices' de TRV staan.
/f/image/jK8U0ojM23wV3D2O2KGDnmj0.png?f=fotoalbum_large)
Dit werkt voor alle zones waar ik een TRV heb, behalve de Hobby Kamer. Als ik bij de Hobby kamer kijk, dan zie ik geen 'Connected Devices' en TRV.
/f/image/QEobwYM32UGJE6leiSFQ0nd7.png?f=fotoalbum_large)
Ik ben dus in de lijst van Ramses 'Devices' gaan kijken en kwam erachter dat er een 63:xxxx device was, aangeduid als HVC i.p.v. TRV, die dezelfde temperatuur doorgeeft als de zone temperatuur (afkomstig van de controller). Ook als ik de batterij er even uithaal zie ik hierover zaken in het logbook onder het 63:xxx device waardoor ik zeker weet dat deze TRV bij de hobby kamer hoort. Fysiek zien de TRV's er identiek uit.
Ik heb in mijn known list de class op TRV gezet:
:strip_exif()/f/image/i65q5Xm9SD6YGVKmO6vXUZzh.png?f=user_large)
Nu wordt hij ook goed weergegeven als ik naar het device ga:
/f/image/zUO8aUgY6ffNeWCV1bDfpya5.png?f=fotoalbum_large)
Echter, is hij nu nog niet 'als 'Connected Device' onder de Zone te zien en vice-versa. Ik dacht, misschien moet ik heel simpel in het system_schema duidelijk maken dat die 63:xxxx bij zone 4 hoort, maar dan krijg ik een error 'not a valid value', zie hieronder. Als ik als proef, de waarde hieronder van 63 naar 04 aanpas, verder niks anders wijzig, dan accepteert hij het gek genoeg wel en kan ik de configuratie opslaan. Het lijkt wel of hij een validatie doet en een 63:xxx hier niet accepteert.
:strip_exif()/f/image/3sWns9sEg08lX840bFugPQ0g.png?f=user_large)
Dus heel kort mijn vraag: Hoe krijg ik nu de link tussen de Hobby Kamer en de TRV? Ik dacht via System Schema maar die slikt een 63:xxx als sensor niet om de één of andere reden.
PS. ik zit op de laatste versie (0.51.5)
Schijnt vaker voor te komen, zie het engelstalige HA forum. Alles wat Ramses RF oppikt, komt uit je instellingen in de Evohome? Centrale. Namen van kamers, koppeling met ‘parent’ radiatoren. Ik lees dat je daar ook deze fout moet fixen: zie bijv. deze discussieKriseh schreef op zaterdag 13 september 2025 @ 16:37:
[...]
mijn vraag: Hoe krijg ik nu de link tussen de Hobby Kamer en de TRV? Ik dacht via System Schema maar die slikt een 63:xxx als sensor niet.
Heb de zone meermaals verwijderd uit de Evohome controller, de toewijzing uit de HR92 gewist, HR92 vervolgens naar fabrieksinstellingen en alles opnieuw. Helaas werkt het nog steeds niet. Ik ga vandaag op vakantie dus ga er mee verder zodra ik terugkom. Ik heb ook nog een reserve HR92 liggen waar ik ook eens mee kan troubleshooten. Ik kom hier op een later moment op terug!ebroerse schreef op zaterdag 13 september 2025 @ 21:30:
[...]
Schijnt vaker voor te komen, zie het engelstalige HA forum. Alles wat Ramses RF oppikt, komt uit je instellingen in de Evohome? Centrale. Namen van kamers, koppeling met ‘parent’ radiatoren. Ik lees dat je daar ook deze fout moet fixen: zie bijv. deze discussie
Deze sensoren worden wel gezien maar er is geen meetwaarde via Ramses. Heeft iemand deze sensor zichtbaar in HA?
"I love the smell of burning diesel in the morning. It smells like ... victory!"
Is deze zone soms de laatste toegevoegde zone en/of de laatste zone in config file die in de .storage directory staat?golfdiesel schreef op zaterdag 20 september 2025 @ 17:24:
In mijn setup voor het Honeywell Evohome systeem heb ik een tweetal losse temperatuursensoren gekoppeld die als temperatuur sensor werken voor de betreffende ruimte.
Deze sensoren worden wel gezien maar er is geen meetwaarde via Ramses. Heeft iemand deze sensor zichtbaar in HA?
[Afbeelding]
Ik heb dit namelijk ook en die zone voldoet aan deze criteria.
Mede oprichter van GoT iRacen & druk met Home Assistant
Dat moet ik nog even bekijken maar ik zie hetzelfde bij twee zones waar ik dit type temperatuur sensor gebruik. In een 3e zone gebruik ik een Honeywell round als sensor (achteraf gezien beter omdat die goedkoper is dan de losse sensor).JoepW schreef op zaterdag 20 september 2025 @ 20:34:
[...]
Is deze zone soms de laatste toegevoegde zone en/of de laatste zone in config file die in de .storage directory staat?
Ik heb dit namelijk ook en die zone voldoet aan deze criteria.
Het is de HCF82 ruimte sensor.
"I love the smell of burning diesel in the morning. It smells like ... victory!"
Dan lijkt het een ander probleem. Ik heb het echt maar bij 1 zone en die heeft enkel een evohome radiatorknop.golfdiesel schreef op zondag 21 september 2025 @ 21:12:
[...]
Dat moet ik nog even bekijken maar ik zie hetzelfde bij twee zones waar ik dit type temperatuur sensor gebruik. In een 3e zone gebruik ik een Honeywell round als sensor (achteraf gezien beter omdat die goedkoper is dan de losse sensor).
Het is de HCF82 ruimte sensor.
[Afbeelding]
Mede oprichter van GoT iRacen & druk met Home Assistant
@golfdiesel Kun je van deze sensor een 10E0 packet en andere berichten uit je log kopiëren voor ranses_rf? Hij staat wel in de Ramses RF code, als PRG “programmer”, maar deze logs ontbreken.
Bedankt voor de PRs en feedback.
Ik ga daar dit weekend naar kijken.ebroerse schreef op dinsdag 23 september 2025 @ 17:47:
[...]
@golfdiesel Kun je van deze sensor een 10E0 packet en andere berichten uit je log kopiëren voor ranses_rf? Hij staat wel in de Ramses RF code, als PRG “programmer”, maar deze logs ontbreken.
"I love the smell of burning diesel in the morning. It smells like ... victory!"
Dit stuurt de THM uit als je handmatig op de zendknop drukt.ebroerse schreef op dinsdag 23 september 2025 @ 17:47:
[...]
@golfdiesel Kun je van deze sensor een 10E0 packet en andere berichten uit je log kopiëren voor ranses_rf? Hij staat wel in de Ramses RF code, als PRG “programmer”, maar deze logs ontbreken.
1
2
3
4
5
6
7
8
| 2025-09-29T20:25:38.910201 040 I 000 03:085164 63:262142 --:------ 1FC9 012 FF10600D4CAC0130C90D4CAC 2025-09-29T20:25:39.481178 045 I 000 03:085164 --:------ 03:085164 30C9 003 01083E 2025-09-29T20:25:39.495248 044 I 000 03:085164 --:------ 03:085164 1060 003 FFFF01 2025-09-29T20:25:44.956405 037 I 001 03:085164 --:------ 03:085164 30C9 003 010852 2025-09-29T20:25:44.970844 037 I 000 03:085164 --:------ 03:085164 1060 003 FFFF01 2025-09-29T20:25:56.304467 041 I 000 03:085164 63:262142 --:------ 1FC9 012 FF10600D4CAC0130C90D4CAC 2025-09-29T20:25:56.478427 040 I 000 03:085164 --:------ 03:085164 30C9 003 01085C 2025-09-29T20:25:56.493367 040 I 000 03:085164 --:------ 03:085164 1060 003 FFFF01 |
Tijdens het normale "bedrijf" zie je deze entries voorbij komen. Het lijkt er overigens wel op dat deze sensor alleen bij temperatuursveranderingen echt een nieuwe waarde stuurt. Als de temperatuur stabiel is zie je geen logs. Als er data gestuurd wordt zie je op het Evohome display de temperatuur ook netjes veranderen.
1
2
| 2025-09-29T20:41:56.981567 040 I 003 03:085164 --:------ 03:085164 30C9 003 0108AC 2025-09-29T20:42:02.456101 039 I 003 03:085164 --:------ 03:085164 30C9 003 0108AC |
[ Voor 18% gewijzigd door golfdiesel op 29-09-2025 20:45 . Reden: toevoeging ]
"I love the smell of burning diesel in the morning. It smells like ... victory!"
Nu zie ik via de OTB ( OpenTherm bridge R8820) de instellingen van de Nefit ketel. Deze worden op dit moment elke 5 minuten geupdate. De vraag is kan ik deze waarde ook elke minuut in HA krijgen?
Zoals beloofd met een andere HR92 geprobeerd en dat werkte meteen! Deze heeft ook netjes een 04:x serienummer i.p.v. 63:x.Kriseh schreef op zondag 14 september 2025 @ 09:06:
[...]
Heb de zone meermaals verwijderd uit de Evohome controller, de toewijzing uit de HR92 gewist, HR92 vervolgens naar fabrieksinstellingen en alles opnieuw. Helaas werkt het nog steeds niet. Ik ga vandaag op vakantie dus ga er mee verder zodra ik terugkom. Ik heb ook nog een reserve HR92 liggen waar ik ook eens mee kan troubleshooten. Ik kom hier op een later moment op terug!
Even samenvattend kreeg ik het met de HR92 met 63:X serienummer niet voor elkaar om de TRV onder de zone te zien, zelfs na meermaals de zone in het evohome systeem verwijderd en opnieuw aangemaakt te hebben. Nu met die spare die ik had liggen dus wel.
[ Voor 34% gewijzigd door Kriseh op 03-10-2025 15:53 ]
Ik had tot voor kort een Nefit ketel en las de ketel uit met https://bbqkees-electroni...fi-editie-v3-kit/?lang=nl via MQTT in Home Assistant.Jongfeli schreef op vrijdag 3 oktober 2025 @ 07:47:
Ik heb een vraag en misschine dat iemand het antwoord weet. Onze Evohome installatie, met nu nog Nefit ketel stuurt 7 radiatorkranen aan via een modulerede ketelsturing en een "Nefit Opentherm Module". Dit werkt al jaren prima. Sinds kort ook een RAMSES_ESP module aangeschaft om via Home Assistant te kijken wat het Evohome systeem nu allemaal uitspookt ipv de Honeywell cloud "oplossing". Ook dit werkt, waarvoor dank :-)
Nu zie ik via de OTB ( OpenTherm bridge R8820) de instellingen van de Nefit ketel. Deze worden op dit moment elke 5 minuten geupdate. De vraag is kan ik deze waarde ook elke minuut in HA krijgen?
Als je interesse hebt kan je voor een zacht prijsje het kale kastje (https://bbqkees-electroni...aard-wifi-editie/?lang=nl) met kabeltje voor de Nefit ketel wel overnemen (ik heb nooit een kit gekocht).
Stuur maar een DM als je interesse hebt.
Mede oprichter van GoT iRacen & druk met Home Assistant
Bedankt voor de test. Er zijn kennelijk HR92-versies die een (vast) serienummer 63:X hebben. Dat nummer kiezen de apparaten vlg. mij zelf, zodra ze beginnen te zenden. Als op dat moment 04:X al in gebruik is zou hij kunnen uitwijken naar 63:? Alleen als dat net zo uniek is als 04: om de functie TRV van het device te herkennen, zou je dat in de RAMSES RF-code kunnen aanpassen.Kriseh schreef op vrijdag 3 oktober 2025 @ 15:48:
[...]
Zoals beloofd met een andere HR92 geprobeerd en dat werkte meteen! Deze heeft ook netjes een 04:x serienummer i.p.v. 63:x.
Even samenvattend kreeg ik het met de HR92 met 63:X serienummer niet voor elkaar om de TRV onder de zone te zien, (…), met die spare die ik had liggen dus wel.
Of we daarmee alle issues met niet-gekoppelde (laatste) TRV’s oplossen blijft nog even de vraag. Ik plak je verslag iig bij het issue op GitHub.
Edit: helaas zit op 63:X ook het ALL-adres 63:262142. Jouw ‘speciale’ TRV zit 1 hoger dus er is echt iets speciaals mee, zoals @Wimpie70 dacht een soort ‘overloop’.
Oudere issues over de HR92 uit 2023 melden trouwens dezelfde problemen:
- Geen Heat demand omdat er te weinig packets binnenkomen (“beter geen info dan foute info”)
- oude schema’s blijven in gebruik na het corrigeren van Zones in evohome.
Kan beide aan slechte ontvangst liggen.
Voor elke vervolgvraag over HR92 TRV’s graag recente 000C packetlogs uit je ramses packetlog in dit issue plakken.
[ Voor 24% gewijzigd door ebroerse op 04-10-2025 10:53 ]
Bedankt voor je antwoord! Ik wil in het najaar nog even een aantal zaken uitproberen met de 'speciale' HR92. Mochten daar nog interessante bevindingen uitkomen dan laat ik het je weten.ebroerse schreef op zaterdag 4 oktober 2025 @ 08:55:
[...]
Bedankt voor de test. Er zijn kennelijk HR92-versies die een (vast) serienummer 63:X hebben. Dat nummer kiezen de apparaten vlg. mij zelf, zodra ze beginnen te zenden. Als op dat moment 04:X al in gebruik is zou hij kunnen uitwijken naar 63:? Alleen als dat net zo uniek is als 04: om de functie TRV van het device te herkennen, zou je dat in de RAMSES RF-code kunnen aanpassen.
Of we daarmee alle issues met niet-gekoppelde (laatste) TRV’s oplossen blijft nog even de vraag. Ik plak je verslag iig bij het issue op GitHub.
Edit: helaas zit op 63:X ook het ALL-adres 63:262142. Jouw ‘speciale’ TRV zit 1 hoger dus er is echt iets speciaals mee, zoals @Wimpie70 dacht een soort ‘overloop’.
Oudere issues over de HR92 uit 2023 melden trouwens dezelfde problemen:
- Geen Heat demand omdat er te weinig packets binnenkomen (“beter geen info dan foute info”)
- oude schema’s blijven in gebruik na het corrigeren van Zones in evohome.
Kan beide aan slechte ontvangst liggen.
Voor elke vervolgvraag over HR92 TRV’s graag recente 000C packetlogs uit je ramses packetlog in dit issue plakken.
Ik heb de door @vliegnerd ontworpen printjes laten maken bij JLCPCB en er een ESP-S3 en CC1101 op gesoleerd. Het was een leuke excersitie en voor mij erg lang geleden dat ik SMD heb gesoldeerd. Ik maak nu nog gebruik van een 2,4GHz antenne, maar er komt al van alles binnen druppelen.
Ik heb hier een EvoHome systeem met HCE80 met 6 thermostaten en een EvoHome controller. De komende periode ga ik me verdiepen in de mogelijkheden en als ik er niet uitkom zal ik me weer melden.
"If it ain't broke, don't fix it!"
Ook zonder antenne werkt het ontvangen meestal prima. Die e07 900m10s modules zijn erg gevoelig.Gerritjuh schreef op zondag 5 oktober 2025 @ 17:07:
Ik lees hier al een tijdje mee en dan lijkt het appeltje eitje, maar het is me gelukt een werkend geheel te krijgen, tenminste zo lijkt het nu.
Ik heb de door @vliegnerd ontworpen printjes laten maken bij JLCPCB en er een ESP-S3 en CC1101 op gesoleerd. Het was een leuke excersitie en voor mij erg lang geleden dat ik SMD heb gesoldeerd. Ik maak nu nog gebruik van een 2,4GHz antenne, maar er komt al van alles binnen druppelen.
Zonder antenne zenden lijkt mij wel riskant, maar een 2,4ghz antenne is vaak even goed/slecht als een 900Mhz.
Ik heb een bordje met een e07 433m10s en die doet het ook prima met 868Mhz…
Tof dat je een bordje gemaakt hebt. Stuur foto’s
4,8kW ZO-NW PVOutput 8x300Wp ZO 12 graden. 8x300Wp NW 12 graden.
De ramses_cc custom integratie vereist HA Core 2025.10.0 of later. Meer in de release notes.
Een van de uitdagingen was het correct verwerken van de MQTT berichten. Beetje naief geweest en de SNTP server nog niet ingesteld, dan werkt het niet lekker. Je ziet wel de verschillende apparaten maar die communiceren verder niet. Vandaag kwam ik daarachter en na het instellen van de SNTP ging bijna alles automatisch. Ik ben nu aan het bestuderen wat alles nu precies betekend (3-letter omschrijvingen en de ID's), maar daar helpt ChatGPT weer heel goed.vliegnerd schreef op zondag 5 oktober 2025 @ 19:19:
[...]
Ook zonder antenne werkt het ontvangen meestal prima. Die e07 900m10s modules zijn erg gevoelig.
Zonder antenne zenden lijkt mij wel riskant, maar een 2,4ghz antenne is vaak even goed/slecht als een 900Mhz.
Ik heb een bordje met een e07 433m10s en die doet het ook prima met 868Mhz…
Tof dat je een bordje gemaakt hebt. Stuur foto’s
De antenne laat ik even voor wat het is, waarschijnlijk een 2,4GHz antenne, maar de gehele huisinstallatie lijkt compleet te worden weergegeven.
Wel een tip voor de beginner (net zoals ik). Als je in de seriele console iets wil aanpassen moet je gewoon blind typen. Tijdens het intoetsen blijven de log regels doorlopen. In het begin dacht ik dat ik iets niet goed had gedaan, maar na het geven van het commando en op enter drukken krijg je wel de bevestiging te zien. Voor de console kan je in Windows gewoon Putty gebruiken en dan de juiste com-poort instellen.
En dan nu de gevraagde foto's:
:strip_exif()/f/image/3xi9d99xGFxKndWVBzO9soXe.jpg?f=fotoalbum_large)
"If it ain't broke, don't fix it!"
Nieuwe optie gemaakt door @Wimpie70 : _Fan parameters_ via 2411 messages. De instellingen verschijnen op een Configuratie paneel onder de Ramses RF integratie als je fan ze ondersteunt. Je kunt instellingen aanpassen met 3 nieuwe Fan actions.
/f/image/z8Xfz7g5cFwCfce5CXCUuOHB.png?f=fotoalbum_large)
Noot: ramses_cc custom integratie versie 0.51.8 en later vereisen HA 2025.10.0 of nieuwer.
Check de release notes voor details.
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.
1
2
3
4
5
6
| "32:153289": bound: "37:168270" class: FAN "37:168270": class: REM faked: true |
Veel plezier ermee, ben benieuwd hoe jullie het kunnen gebruiken
Ramses RF - Ramses Extras - Orcon WTW - Duco WTW
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.
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 CC1101Keesnotals 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.
[ Voor 9% gewijzigd door asaki op 28-11-2025 00:16 ]
Bevat bugfixes en ontwikkeltools (coverage report), plus een mooi configuratiepaneel voor je MQTT-instellingen.
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.rwijnhov schreef op woensdag 10 december 2025 @ 18:39:
Hoe verwijder ik nu de foutief gedetecteerd otb uit het controller overzicht?
Over een tijdje mss deze instructie volgen, al begint die ook met “I don’t advise doing this at all but…” 😙
Dank voor al jullie bijdragen en feedback in 2025!
[ Voor 3% gewijzigd door GroeneBoom456 op 22-12-2025 10:09 ]
Niet direct, maar waar ben je naar opzoek?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)
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!
4,8kW ZO-NW PVOutput 8x300Wp ZO 12 graden. 8x300Wp NW 12 graden.
Ja, die draait hier thuis happy met Ramses RF. Het is de Airios VMN-17LMP01 (zie sticker aan de binnenkant).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)
Plak de volgende code in de HA Ramses RF configuratie > Known Devices (adressen wel aanpassen voor jouw setup):
1
2
3
4
5
6
7
8
9
10
11
12
| "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 ]
"I love the smell of burning diesel in the morning. It smells like ... victory!"
Is door meerdere gebruikers gezien toen ze een nieuw device ontvingen of toen Resideo support hun evohome ging upgraden.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?
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
Eh, watte? Gaat dat upgraden alleen op verzoek, of krijgt ‘iedereen’ op termijn die upgrade?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.
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?
Verdraagzaamheid is het hoogste gebod
en wie dat niet eert die schoppen we rot.
<John O`Mill>
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 liggenHH91 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.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.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 ook net in gebruik genomen, en werkt inderdaad perfect.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.
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.
---
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 ]
Ramses RF - Ramses Extras - Orcon WTW - Duco WTW
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.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?
Erg jammmer dat Residio deze weg ingeslagen is.
"I love the smell of burning diesel in the morning. It smells like ... victory!"
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...?
Ramses RF - Ramses Extras - Orcon WTW - Duco WTW
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
3e optie, staat ook op Ramses_rf github wiki:HH91 schreef op vrijdag 2 januari 2026 @ 23:53:
Hebben jullie aanbevelingen voor hardware?
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.
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.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...?
"If it ain't broke, don't fix it!"
Dus waar dat aan ligt? Ja, zeg het maar…
Verdraagzaamheid is het hoogste gebod
en wie dat niet eert die schoppen we rot.
<John O`Mill>
/f/image/2t9bXkceieUN5Bu8uWuT1V5O.png?f=fotoalbum_large)
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 !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
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 .
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 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]
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:
1
2
3
4
5
6
7
| 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).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:
1 2 3 4 5 6 7 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 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).
https://github.com/ramses-rf/ramses_cc/issues/423
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.
Heeft iemand nog een pcb liggen? En past de ESP32-C6 hier ook op?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.
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:
1
2
3
4
5
6
7
8
9
10
11
| 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 ]
“Life is tough, but it's tougher when you're stupid.” - John Wayne | Last.fm
In (maintainer van Ramses RF) heb n.a.v. je post een nieuw issue 444 op GitHub geopend.oshiro schreef op maandag 19 januari 2026 @ 21:21:
Is dit nu iets wat ik zelf fout doe, of is dit een bug?
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!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.
“Life is tough, but it's tougher when you're stupid.” - John Wayne | Last.fm
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!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.
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 ]
“Life is tough, but it's tougher when you're stupid.” - John Wayne | Last.fm
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?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!
1
| 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
Ramses RF - Ramses Extras - Orcon WTW - Duco WTW
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”).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?
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.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.
Nu heb ik een vergelijkbaar issue als hier: https://github.com/ramses-rf/ramses_cc/issues/424
- Ook ik krijg een unknown error bij het wijzigen van de settings vanuit de fan-tegel
- 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?)
- De settings zoals teruggemeld door de ventilator kloppen niet ("off" of "away" wordt trickle, "high" wordt medium, "automatisch" wordt boost, etcetera)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
| 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 |
Ik heb in de known list ook al dit gezet, helpt nog niet (id van de afstandbediening bij bound):
1
2
3
4
| "32:231021": alias: Orcon MVS-15 mechanische ventilatie bound: "29:172615" class: FAN |
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 ]
“Life is tough, but it's tougher when you're stupid.” - John Wayne | Last.fm
Hier is nog beter integratie nodig voor de Orcon unit denk ik (ik heb hetzelfde, maar heb een eigen dashboard gemaakt)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
- Ook ik krijg een unknown error bij het wijzigen van de settings vanuit de fan-tegel
- 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?)
- De settings zoals teruggemeld door de ventilator kloppen niet ("off" of "away" wordt trickle, "high" wordt medium, "automatisch" wordt boost, etcetera)
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):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.
Fan naar standje 3 (high):
1
2
3
| 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 |
1
2
3
| 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 |
1
2
| 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 |
1
2
3
| 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 ]
“Life is tough, but it's tougher when you're stupid.” - John Wayne | Last.fm
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.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)
En het kan zelfs na een firmware update veranderen!
Voor de korte termijn kunnen we in de wiki wel dashboard yaml per merk delen.
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.
Ramses RF - Ramses Extras - Orcon WTW - Duco WTW
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...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.
In de tussentijd heb ik een template sensor gemaakt om de mapping in orde te krijgen. Vanuit de GUI in dit geval:
1
2
3
4
5
6
7
8
| {% 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 %} |
Minimalistisch dashboard op basis van bubble card:
:strip_exif()/f/image/PBqsh3ZhooxnJUcLudr6DXRq.png?f=user_large)
YAML (de sensor fan_info is de bovengenoemde sensor template):
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
| 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 |
Dit ga ik even bekijken!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).
Ik ben aan het zoeken, maar ik kan deze in geen van beide wiki's vinden!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.
[ Voor 27% gewijzigd door oshiro op 21-01-2026 22:40 ]
“Life is tough, but it's tougher when you're stupid.” - John Wayne | Last.fm
Zet zoiets als dit in je Known devices:
1
2
3
4
5
| "37:168270": class: REM "32:153289": bound: "37:168270" class: FAN |
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 ]
Ramses RF - Ramses Extras - Orcon WTW - Duco WTW
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…
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.
Welkom. Vergelijkbare problemen met evohome zijn ook door anderen gemeld, zie de Issues in de GitHub repo.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.
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.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?
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,
eeh jaren geleden besteld en betaaldasaki schreef op maandag 26 januari 2026 @ 17:03:
Ik ben vooral benieuwd hoe je aan die hgi80 bent gekomen
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
Wie al een pre-release draait, raad ik aan om deze te installeren via het uitklapmenu.
Het zou kunnen dat dit (nieuwe?) device RAMSES III ipv II gebruikt. Zelfde frequentie, beetje ander protocol met encryptie.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?
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
4,8kW ZO-NW PVOutput 8x300Wp ZO 12 graden. 8x300Wp NW 12 graden.
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.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?
Je kunt het schuifje "Log alle MQTT topics" inschakelen. Misschien dat je dan het nieuwe device (adres) ziet langskomen.
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 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,
/f/image/Wfo9LChiflenUgwHwDTL77lI.png?f=fotoalbum_large)
:strip_exif()/f/image/3WpKysxa9UR9GtEMAImxmms9.jpg?f=fotoalbum_large)