Ramses II 868MHz communicatie via evofw3 en ramses_rf

[ebroerse]

Een volgende stabiele versie van Ramses RF is bijna af. Testers kunnen pre-release 0.59.9 dit weekend al uitproberen.

[Wimpie70]

Versie 0.59.11 (RC-4) is uit en beschikbaar via HACS.

Graag testen als je daar de gelegenheid voor hebt, en eventuele problemen posten op https://github.com/ramses-rf/ramses_cc/issues. Zonder feedback weten we ook niet of er nog iets mis gaat.

[Turrican]

@Wimpie70 getest, Orcon HRC-400, ik heb de vorige betas ook getest en regelmatig een issue gemeld, testresultaten van 0.59.11:

1. Parameters wijzigen werkt, waardes zijn correct.
2. Bypass bedienen via fan entity en fan remote entity werkt.
3. Fan speed / mode wijzigen via fan remote entity en fan entity werkt.
4. Metingen werken goed.
5. Regex event werkt goed.

Top!

[ebroerse]

Ramses RF 0.60.0 staat in HACS, en zal ‘vanzelf’ in HA verschijnen. Een “echte” release met de hele config via het Schema.

Je bestaande Known List wordt overgezet, en aangevuld zodra je suggesties van de Passive Device Scan accepteert. Zie de Wiki voor tips.

[vliegnerd]

ebroerse schreef op dinsdag 25 augustus 2026 @ 17:49:
Ramses RF 0.60.0 staat in HACS, en zal ‘vanzelf’ in HA verschijnen. Een “echte” release met de hele config via het Schema.

Je bestaande Known List wordt overgezet, en aangevuld zodra je suggesties van de Passive Device Scan accepteert. Zie de Wiki voor tips.

Geïnstalleerd (geüpdatet) en vrijwel naadloos overgestapt. Na de scan wel een keertje extra moeten herstarten, maar alles lijkt gewoon te werken.

Ik weet niet precies meer van welke versie ik kwam, maar oude. Ik heb wel eerst HA naar 2026.8.3 geüpdatet.

dank weer!

[posttoast]

ebroerse schreef op dinsdag 25 augustus 2026 @ 17:49:
Ramses RF 0.60.0 staat in HACS, en zal ‘vanzelf’ in HA verschijnen. Een “echte” release met de hele config via het Schema.

Je bestaande Known List wordt overgezet, en aangevuld zodra je suggesties van de Passive Device Scan accepteert. Zie de Wiki voor tips.

Draait hier en werkt allemaal prima!

Ik heb mijn devices nu allemaal als YAML in mijn system schema zitten. Maar ik begrijp nu dat dat de "oude manier" is. Heeft het meerwaarde om over te stappen op de nieuwe manier? En hoe doe ik dat?

Bij mij is wel een dingetje dat er HEEL veel langskomt qua verkeer: de hele wijk heeft apparatuur dat via Ramses communiceert.

[Wimpie70]

Je krijgt meldingen dat er iets veranderd/nieuws is gevonden in het systeem. Je kan dan met de 2 Review config opties kiezen wat er mee te doen. Als een apparaat van je buren is (check de RSSI) kan je als _owner bijvoorbeeld 'Buren 29' zetten. Je kan ook overslaan en later besluiten als je meer info hebt.

Je zet de hoofd _owner bijvoorbeeld op 'me'. Alles wat een andere _owner, heeft wordt genegeerd. Commandos vallen nu onder de FAN en hebben een andere vorm. Uiteindelijk willen we deze hard in het systeem zetten, maar kan je ze nog wel overschrijven in je schema.

Als je je oude gegevens nog hebt kan je daarmee vergelijken. Er is ook een backup hiervan gemaakt.

Het systeem probeert te detecteren wat voor soort apparaat het is, en vult zoveel mogelijk het schema in. Er is ook _comment die aangeeft wat de reden is en hoe waarschijnlijk dat het bijvoorbeeld een FAN is.

Ook probeert het om de verbindingen te leggen. Wat hoort waarbij...


Er is veel getest en we denken dat het systeem behoorlijk stabiel is. Eventuele problemen graag melden met een issue op https://github.com/ramses-rf/ramses_cc/issues.

[posttoast]

Wimpie70 schreef op woensdag 26 augustus 2026 @ 11:37:
Je krijgt meldingen dat er iets veranderd/nieuws is gevonden in het systeem. Je kan dan met de 2 Review config opties kiezen wat er mee te doen. Als een apparaat van je buren is (check de RSSI) kan je als _owner bijvoorbeeld 'Buren 29' zetten. Je kan ook overslaan en later besluiten als je meer info hebt.

Je zet de hoofd _owner bijvoorbeeld op 'me'. Alles wat een andere _owner, heeft wordt genegeerd. Commandos vallen nu onder de FAN en hebben een andere vorm. Uiteindelijk willen we deze hard in het systeem zetten, maar kan je ze nog wel overschrijven in je schema.

Als je je oude gegevens nog hebt kan je daarmee vergelijken. Er is ook een backup hiervan gemaakt.

Het systeem probeert te detecteren wat voor soort apparaat het is, en vult zoveel mogelijk het schema in. Er is ook _comment die aangeeft wat de reden is en hoe waarschijnlijk dat het bijvoorbeeld een FAN is.

Ook probeert het om de verbindingen te leggen. Wat hoort waarbij...


Er is veel getest en we denken dat het systeem behoorlijk stabiel is. Eventuele problemen graag melden met een issue op https://github.com/ramses-rf/ramses_cc/issues.

De kans dat ik weet wat van welke buur is, is hier nihil. En (voor mij) ook eigenlijk niet zo relevant. Ik wil gewoon dat ik mijn devices in Home Assistant kan zien en al het andere niet.

Daarom ook de gewetensvraag: het wérkt nu al bij mij, is het voor mij zinvol om dit op de nieuwe manier te gaan doen (ik neig altijd naar "ja" omdat ik nieuwe dingen leuk vind ).

[Wimpie70]

Het nieuwe systeem is Single Source Of Truth...het schema bepaald. Passive scan is enabled by default.

Als het goed is, zie je geen known list meer, maar je kan nog steeds configuration.yaml gebruiken. Die hebben we gemist om te wijzigen bij de update...en gaan we zeker verwijderen. Ik raad aan om dit nu handmatig te doen. Deze wordt nu al genegeerd...

Als je het schema gebruikt, is dit al de nieuwe manier. Je devices zouden al in het nieuwe schema moeten staan.

Gebruik de beide review opties in de config. Het opbouwen kan even duren (een aantal maal), kijk gewoon af en toe even en doe er een paar tegelijk. Vergelijk het met je oude known list...Maar waarschijnlijk is het belangrijkste al goed gezet.

En je gewetensvragen..die moet je zelf beantwoorden

[posttoast]

OK, ik weet niet of ik je helemaal volg, maar voor de duidelijkheid: ik heb nu een mooi gevuld System schema:

YAML:

18:118800:
  _alias: IndaloTech USB-stick
  _class: HGI
29:123456:
  _alias: Virtuele HA remote
  _class: REM
  _commands:
    _comment: Commands on REM (Phase 3a) — will be deprecated, use FAN instead
    auto: ' I --- 29:123456 32:152794 --:------ 22F1 003 000407'
    auto2: ' I --- 29:123456 32:152794 --:------ 22F1 003 000507'
    away: ' I --- 29:123456 32:152794 --:------ 22F1 003 000007'
    boost: ' I --- 29:123456 32:152794 --:------ 22F1 003 000607'
    bypass_auto: ' W --- 29:123456 32:152794 --:------ 22F7 003 00FFEF'
    bypass_close: ' W --- 29:123456 32:152794 --:------ 22F7 003 0000EF'
    bypass_open: ' W --- 29:123456 32:152794 --:------ 22F7 003 00C8EF'
    disable: ' I --- 29:123456 32:152794 --:------ 22F1 003 000707'
    high: ' I --- 29:123456 32:152794 --:------ 22F1 003 000307'
    high_15: ' I --- 29:123456 32:152794 --:------ 22F3 007 00120F03040404'
    high_30: ' I --- 29:123456 32:152794 --:------ 22F3 007 00121E03040404'
    high_60: ' I --- 29:123456 32:152794 --:------ 22F3 007 00123C03040404'
    low: ' I --- 29:123456 32:152794 --:------ 22F1 003 000107'
    med_60: ' I --- 29:123456 32:152794 --:------ 22F3 007 00123C02040404'
    medium: ' I --- 29:123456 32:152794 --:------ 22F1 003 000207'
    request10D0: RQ --- 29:123456 32:152794 --:------ 10D0 001 00
    request31DA: RQ --- 29:123456 32:152794 --:------ 31DA 001 00
    reset_filter: ' W --- 29:123456 32:152794 --:------ 10D0 002 00FF'
  _faked: true
29:172691:
  _alias: Remote Badkamer 2
  _class: REM
29:175675:
  _alias: Remote Badkamer 1
  _class: REM
32:152794:
  _alias: WTW installatie
  _bound: 29:123456
  _class: FAN
  _commands:
    _comment: Commands on FAN (Phase 3b) — target this entity for automations
    auto:
      code: 22F1
      payload: '000407'
      verb: I
    auto2:
      code: 22F1
      payload: '000507'
      verb: I
    away:
      code: 22F1
      payload: '000007'
      verb: I
    boost:
      code: 22F1
      payload: '000607'
      verb: I
    bypass_auto:
      code: 22F7
      payload: 00FFEF
      verb: W
    bypass_close:
      code: 22F7
      payload: 0000EF
      verb: W
    bypass_open:
      code: 22F7
      payload: 00C8EF
      verb: W
    disable:
      code: 22F1
      payload: '000707'
      verb: I
    high:
      code: 22F1
      payload: '000307'
      verb: I
    high_15:
      code: 22F3
      payload: 00120F03040404
      verb: I
    high_30:
      code: 22F3
      payload: 00121E03040404
      verb: I
    high_60:
      code: 22F3
      payload: 00123C03040404
      verb: I
    low:
      code: 22F1
      payload: '000107'
      verb: I
    med_60:
      code: 22F3
      payload: 00123C02040404
      verb: I
    medium:
      code: 22F1
      payload: '000207'
      verb: I
    request10D0:
      code: 10D0
      payload: '00'
      verb: RQ
    request31DA:
      code: 31DA
      payload: '00'
      verb: RQ
    reset_filter:
      code: 10D0
      payload: 00FF
      verb: W
37:016448:
  _alias: CO2 Sensor Slaapkamer Eefje en Vincent
  _class: CO2
37:056185:
  _alias: CO2 Sensor Slaapkamer Eline
  _class: CO2
37:094214:
  _alias: CO2 Sensor Slaapkamer Ivar
  _class: CO2
37:132953:
  _alias: CO2 Sensor Huiskamer
  _class: CO2
orphans_hvac:
  - 29:123456
  - 29:172691
  - 29:175675
  - 32:152794
  - 37:016448
  - 37:056185
  - 37:094214
  - 37:132953

"Enable passive device scan to discover unknown RF devices" staat aan, maar als ik naar "Review discovered devices" ga staat er "Passive device scan is not enabled."

Zie ik iets over het hoofd?

[Wimpie70]

it may be lame....but did you try to turn it off and on again...

Maar dat is wel voor nu de opplossing. Even de pasisive device scan uit en weer aan zetten. In de logs zou je dan ergens moeten zien: 'DiscoveryManager: started (passive scan running)'

Ik maak een fix voor nieuwe versies.

[posttoast]

haha inderdaad zeg, dat deed het hem. Straks even goed naar kijken.

Edit: bam, in de eerste 3 minuten al 58 devices gevonden

Edit 2: het is me nog steeds niet helemaal duidelijk wat ik in moet vullen in de input als ik voor "accept" kies bij een device. Er staat standaard (bijvoorbeeld) "owner_37:056185". Ik weet welk device dat is (de CO2 sensor in de kamer van één van mijn kinderen).

[ Voor 82% gewijzigd door posttoast op 26-08-2026 14:55 ]

[ebroerse]

posttoast schreef op woensdag 26 augustus 2026 @ 14:45:
...
Edit 2: het is me nog steeds niet helemaal duidelijk wat ik in moet vullen in de input als ik voor "accept" kies bij een device. Er staat standaard (bijvoorbeeld) "owner_37:056185". ...

Je kunt bij alle spullen van de buren simpelweg op "Reject (All)" klikken -> _owner: not-me gaat vanzelf. Ze komen wel in het schema, want we moeten ze érgens onthouden.
Eigen spullen (en die van je dochter, als ze dat OK vindt) -> Accept (wordt _owner: me)
Als je per ongeluk een device weigert, pas je de _owner aan en hij komt weer in HA na Verzenden.

[posttoast]

Het is, met de 121 devices die hij uiteindelijk gevonden heeft, best een klus maar ik ben er volgens mij doorheen. Het resultaat is alleen wel dat het system schema behoorlijk lang is geworden; voorheen had ik hierin alleen mijn eigen devices staan en nu staat alles wat hij gevonden heeft erin (met daarbij commentaar als 'Likely REM (confidence: low). codes: 4401. (auto-generated — do not edit)'). Er staat natuurlijk wel _owner: not-me bij, maar wat is de meerwaarde van al deze zaken in de lijst te hebben (is misschien een heel logisch antwoord op)?

Daarnaast: de lijst "Review discovered devices" heeft zich nu gevuld met items zoals "missing_class_37:119605". Ik kan hier dan kiezen tussen "Skip voor now" en "Add _class: REM". Maar ik wil eigenlijk geen van beiden, ik wil dat deze devices gewoon genegeerd worden (want ze zijn niet van mij en ik weet ook niet zeker wat voor devices het wel zijn).

Tot slot heb ik nog een "mismatch_29:123456:". Dit is, zoals het getal doet vermoeden, geen echt device maar een virtuele remote. Moet ik daar dan ook "Keep REM" kiezen?

[ebroerse]

posttoast schreef op woensdag 26 augustus 2026 @ 16:31:
… een virtuele remote. Moet ik daar dan ook "Keep REM" kiezen?

Ja, net als eerder in de Known List.
Als ‘user’ heb je bewust het laatste woord, dus dit verzint Ramses RF met opzet niet zelf.
Maar het programma let wel op. Ik heb bijv. een badkamerfan die actuele RH verstuurt; die moest ik even 1x bevestigen als FAN i.p.v. HUM (wat qua Code best klopt).

[Wimpie70]

Ja, het is echt nodig.

Ik heb even gekeken of het mogelijk is om het schema te filteren, maar dat is lastig met bewerken en save (HA gedoe).

Als je het echt een punt vindt...maak er een custom schema editor card voor...

[posttoast]

Nou, ik vind het niet echt een punt, maar ik vraag me af wat het "nut" is van al die devices van buren erin hebben. Het zijn er hier echt heel veel (en dat geldt voor iedereen in een nieuwbouwwijk gok ik). Er kwamen er net ook weer 30 bij

Dit is inmiddels mijn schema, die voelt vrij "bloated" voor de 8 devices (9 als je de Indalo-tech-stick meetelt) waar ik iets mee wil doen, ik zit op 747 regels.

Is het daadwerkelijk de bedoeling dat dit zo'n grote lijst wordt? En moet ik die passive scanning aan laten staan? Het enige dat ik daarmee bereik is dat er potentieel nog meer apparaten van buren bij gaan komen, ik ga er hier zelf geen Ramses devices bij hangen op korte termijn.

Ik krijg heel sterk het gevoel dat ik iets verkeerd aan het doen ben.

[ebroerse]

posttoast schreef op woensdag 26 augustus 2026 @ 21:08:
…
En moet ik die passive scanning aan laten staan?
…

Goed idee. Als je happy bent met je systeem, en geen nieuwe spullen aan het plaatsen/vervangen bent, zsm de Scan uitschakelen. Schema opschonen mag daarna ook, want het is info die alleen de Scan gebruikt.

Verplaats je je in een nieuwe gebruiker, dan is het toch fijner dat er iets binnenkomt dan naar een leeg scherm staren, maar onvermijdelijk dat ze daarna wordt gevraagd of het hun devices zijn.

[Wimpie70]

hier stond een post die alles behalve behulpzaam was...

[ Voor 77% gewijzigd door teacher op 26-08-2026 22:21 ]

[posttoast]

ebroerse schreef op woensdag 26 augustus 2026 @ 21:57:
[...]


Goed idee. Als je happy bent met je systeem, en geen nieuwe spullen aan het plaatsen/vervangen bent, zsm de Scan uitschakelen. Schema opschonen mag daarna ook, want het is info die alleen de Scan gebruikt.

Verplaats je je in een nieuwe gebruiker, dan is het toch fijner dat er iets binnenkomt dan naar een leeg scherm staren, maar onvermijdelijk dat ze daarna wordt gevraagd of het hun devices zijn.

Zeker, helemaal eens. Maar dan is het me duidelijk: het is puur de onboarding, daarna gaat ie uit

Wimpie70 schreef op woensdag 26 augustus 2026 @ 22:00:
[mbr]hier stond een post die alles behalve behulpzaam was...[/mbr]

Ik had de post al gezien en kon er wel om lachen hoor Het ding is alleen: ophangen boven mijn bed, ik kan inmiddels mijn hele huis behangen met dat schema

Voor alle duidelijkheid: het is geen kritiek van mijn kant he, ik vind het supertof dat Ramses RF zo enorm snel doorontwikkeld wordt nu, ik probeer alleen te begrijpen hoe het het best aansluit bij mijn use case.

[ebroerse]

ebroerse schreef op zondag 16 augustus 2026 @ 21:49:
[...]

Voor het bedrijfsbelang zou ik lekker op 0.56.0 blijven.
We proberen het stabiel te krijgen, en over een paar weken - dus ruim voor het stookseizoen - weer eens een “echte” release.

@Vino75 Tijd om over te stappen op 0.60.1 - stable, zeker als je HA ook graag actueel houdt (en een uurtje over hebt).

[Vino75]

@ebroerse Bedankt voor de update!!!

Ik zal komend weekend wel eens kijken. Dan heb ik ook tijd om eventueel om issues of eigen onkunde heen te werken voordat het thuisfront kans krijgt om te klagen Als er uberhaupt issues gaan zijn.

Nogmaals bedankt voor het vele werk dat jullie verzetten!!!

[TijmenvS]

Ik heb (eindelijk) ook maar eens geüpdatet naar versie 0.60.1 (van 0.56.2). Nu lijkt het erop dat sommige commands niet meer werken (en sommige andere wel nog steeds).

Dit is mijn systeemschema. De commands high_15, high_30 en auto werken wel. Maar bijvoorbeeld med_60 of high_60 werken niet. Ook het command medium lijkt niet te werken in een automatisering die ik heb draaien, terwijl de automatisering met command high wel gewoon werkt. Hieronder ook nog wat info uit het HA logboek.

Iemand enig idee waar dit aan zou kunnen liggen?

Logger: ramses_tx.transport.base

Bron: runner.py:290

Eerst voorgekomen: 10:16:10 (129 gebeurtenissen)

Laatst gelogd: 14:45:51

# I --- 37:123789 32:161442 --:------ 22F3 007 00120F03040404 < PacketInvalid(Null packet)

# I --- 37:123789 32:161442 --:------ 22F3 007 00121E03040404 < PacketInvalid(Null packet)

# I --- 37:123789 32:161442 --:------ 22F3 007 00123C03040404 < PacketInvalid(Null packet)

# I --- 37:123789 32:161442 --:------ 22F1 003 000407 < PacketInvalid(Null packet)

# I --- 37:123789 32:161442 --:------ 22F1 003 000207 < PacketInvalid(Null packet)

YAML:

_owner: me
device_comments:
  32:161442: >-
    Likely FAN. may also be DIS (31DA is sent by both). belongs to 32:097951.
    codes: 10D0, 22F1, 22F3, 2411, 31D9. RSSI -62. (auto-generated — do not
    edit)
  37:123789: >-
    Likely REM. belongs to 32:161442. codes: 22F1, 22F3, 2411. (auto-generated —
    do not edit)
  18:183788: 'Likely HGI. codes: 10D0. (auto-generated — do not edit)'
  32:097951: 'Likely CO2. codes: 1298, 31E0. RSSI -66. (auto-generated — do not edit)'
orphans_hvac:
  - 32:097951
  - 32:161442
18:183788:
  _class: HGI
  _owner: me
32:097951:
  _class: CO2
  _owner: me
32:161442:
  _class: FAN
  _bound: 37:123789
  remotes:
    - 37:123789
  _commands:
    auto:
      verb: I
      code: 22F1
      payload: '000407'
    auto2:
      verb: I
      code: 22F1
      payload: '000507'
    away:
      verb: I
      code: 22F1
      payload: '000007'
    boost:
      verb: I
      code: 22F1
      payload: '000607'
    bypass_auto:
      verb: W
      code: 22F7
      payload: 00FFEF
    bypass_close:
      verb: W
      code: 22F7
      payload: 0000EF
    bypass_open:
      verb: W
      code: 22F7
      payload: 00C8EF
    disable:
      verb: I
      code: 22F1
      payload: '000707'
    high:
      verb: I
      code: 22F1
      payload: '000307'
    high_15:
      verb: I
      code: 22F3
      payload: 00120F03040404
    high_30:
      verb: I
      code: 22F3
      payload: 00121E03040404
    high_60:
      verb: I
      code: 22F3
      payload: 00123C03040404
    low:
      verb: I
      code: 22F1
      payload: '000107'
    med_60:
      verb: I
      code: 22F3
      payload: 00123C02040404
    medium:
      verb: I
      code: 22F1
      payload: '000207'
    request10D0:
      verb: RQ
      code: 10D0
      payload: '00'
    request31DA:
      verb: RQ
      code: 31DA
      payload: '00'
    reset_filter:
      verb: W
      code: 10D0
      payload: 00FF
    _comment: Commands on FAN (Phase 3b) — target entity for automations
  _owner: me
37:123789:
  _class: REM
  _faked: true
  _commands:
    auto: ' I --- 37:123789 32:161442 --:------ 22F1 003 000407'
    auto2: ' I --- 37:123789 32:161442 --:------ 22F1 003 000507'
    away: ' I --- 37:123789 32:161442 --:------ 22F1 003 000007'
    boost: ' I --- 37:123789 32:161442 --:------ 22F1 003 000607'
    bypass_auto: ' W --- 37:123789 32:161442 --:------ 22F7 003 00FFEF'
    bypass_close: ' W --- 37:123789 32:161442 --:------ 22F7 003 0000EF'
    bypass_open: ' W --- 37:123789 32:161442 --:------ 22F7 003 00C8EF'
    disable: ' I --- 37:123789 32:161442 --:------ 22F1 003 000707'
    high: ' I --- 37:123789 32:161442 --:------ 22F1 003 000307'
    high_15: ' I --- 37:123789 32:161442 --:------ 22F3 007 00120F03040404'
    high_30: ' I --- 37:123789 32:161442 --:------ 22F3 007 00121E03040404'
    high_60: ' I --- 37:123789 32:161442 --:------ 22F3 007 00123C03040404'
    low: ' I --- 37:123789 32:161442 --:------ 22F1 003 000107'
    med_60: ' I --- 37:123789 32:161442 --:------ 22F3 007 00123C02040404'
    medium: ' I --- 37:123789 32:161442 --:------ 22F1 003 000207'
    request10D0: RQ --- 37:123789 32:161442 --:------ 10D0 001 00
    request31DA: RQ --- 37:123789 32:161442 --:------ 31DA 001 00
    reset_filter: ' W --- 37:123789 32:161442 --:------ 10D0 002 00FF'
    _comment: >-
      Commands were moved to FAN — consider removing from REM, or keep as
      downgrade backup
  _owner: me
37:999999:
  _commands:
    request31DA: RQ --- 37:999999 32:161442 --:------ 31DA 001 00
    request10D0: RQ --- 37:999999 32:161442 --:------ 10D0 001 00
    low: ' I --- 37:999999 32:161442 --:------ 22F1 003 000107'
    high: ' I --- 37:999999 32:161442 --:------ 22F1 003 000307'
    away: ' I --- 37:999999 32:161442 --:------ 22F1 003 000007'
    medium: ' I --- 37:999999 32:161442 --:------ 22F1 003 000207'
    auto: ' I --- 37:999999 32:161442 --:------ 22F1 003 000407'
    auto2: ' I --- 37:999999 32:161442 --:------ 22F1 003 000507'
    boost: ' I --- 37:999999 32:161442 --:------ 22F1 003 000607'
    disable: ' I --- 37:999999 32:161442 --:------ 22F1 003 000707'
    bypass_open: ' W --- 37:999999 32:161442 --:------ 22F7 003 00C8EF'
    bypass_close: ' W --- 37:999999 32:161442 --:------ 22F7 003 0000EF'
    bypass_auto: ' W --- 37:999999 32:161442 --:------ 22F7 003 00FFEF'
    high_60: ' I --- 37:999999 32:161442 --:------ 22F3 007 00123C03040404'
    med_60: ' I --- 37:999999 32:161442 --:------ 22F3 007 00123C02040404'
    high_30: ' I --- 37:999999 32:161442 --:------ 22F3 007 00121E03040404'
    high_15: ' I --- 37:999999 32:161442 --:------ 22F3 007 00120F03040404'
    reset_filter: ' W --- 37:999999 32:161442 --:------ 10D0 002 00FF'
  _owner: me

En wellicht nog handig, de packetlog:

YAML:

2026-08-27T14:34:05.687958 ...  I --- 37:123789 32:161442 --:------ 22F1 003 000207
2026-08-27T14:34:41.821000 -70  I --- 32:161442 --:------ 32:161442 31D9 004 00200200
2026-08-27T14:35:31.603732 ...  I --- 37:123789 32:161442 --:------ 22F3 007 00123C02040404
2026-08-27T14:35:31.717000 -68  I --- 32:161442 --:------ 32:161442 31D9 004 00200200
2026-08-27T14:36:55.051000 -62  I --- 32:161442 --:------ 32:161442 31D9 004 00200200
2026-08-27T14:39:02.384000 -69  I --- 32:097951 --:------ 32:097951 1298 003 00027E
2026-08-27T14:40:11.207287 ...  I --- 37:123789 32:161442 --:------ 22F3 007 00120F03040404
2026-08-27T14:40:11.365000 -57  I --- 32:161442 --:------ 32:161442 31D9 004 00200300
2026-08-27T14:40:11.446000 -57  I --- 32:161442 --:------ 32:161442 31DA 029 00EF007FFF42420AC8099C09700AACF800004D8C8C000FEFEF10431043
2026-08-27T14:42:17.696000 -80  I --- 32:161442 --:------ 32:161442 31D9 004 00200300
2026-08-27T14:42:40.330014 ...  I --- 37:123789 32:161442 --:------ 22F3 007 00121E03040404
2026-08-27T14:42:40.456000 -57  I --- 32:161442 --:------ 32:161442 31D9 004 00200300
2026-08-27T14:42:41.108000 -57  I --- 32:161442 --:------ 32:161442 31DA 029 00EF007FFF42420AD209A609700AC9F800004D8C8C001EEFEF16C916AA
2026-08-27T14:42:43.685913 ...  I --- 37:123789 32:161442 --:------ 22F3 007 00123C03040404
2026-08-27T14:42:43.776000 -58  I --- 32:161442 --:------ 32:161442 31D9 004 00200300
2026-08-27T14:42:50.381226 ...  I --- 37:123789 32:161442 --:------ 22F3 007 00123C03040404
2026-08-27T14:42:50.475000 -57  I --- 32:161442 --:------ 32:161442 31D9 004 00200300
2026-08-27T14:42:53.211614 ...  I --- 37:123789 32:161442 --:------ 22F1 003 000407
2026-08-27T14:42:53.315000 -58  I --- 32:161442 --:------ 32:161442 31D9 004 00200400
2026-08-27T14:42:54.088000 -58  I --- 32:161442 --:------ 32:161442 31DA 029 00EF007FFF42420AD209A609710AD4F80000581E1E0000EFEF168F16C9
2026-08-27T14:44:40.919000 -56  I --- 32:161442 --:------ 32:161442 31D9 004 00200400
2026-08-27T14:45:10.928000 -56  I --- 32:161442 --:------ 32:161442 31DA 029 00EF007FFF42420AE609A6097B0AF2F80000581E1E0000EFEF04C304DF
2026-08-27T14:45:51.501265 ...  I --- 37:123789 32:161442 --:------ 22F1 003 000207
2026-08-27T14:45:51.609000 -57  I --- 32:161442 --:------ 32:161442 31D9 004 00200200
2026-08-27T14:45:51.825000 -57  I --- 32:161442 --:------ 32:161442 31DA 029 00EF007FFF42420AE609A6097D0AF6F800004264640000EFEF04DF04DF
2026-08-27T14:46:25.749975 ...  I --- 37:123789 32:161442 --:------ 22F1 003 000307
2026-08-27T14:46:25.817000 -57  I --- 32:161442 --:------ 32:161442 31D9 004 00200300
2026-08-27T14:46:26.767000 -57  I --- 32:161442 --:------ 32:161442 31DA 029 00EF007FFF42420AF009A6097F0AFBF80000438C8C0000EFEF100C1043
2026-08-27T14:47:26.971718 ...  I --- 37:123789 32:161442 --:------ 22F3 007 00121E03040404
2026-08-27T14:47:27.024000 -57  I --- 32:161442 --:------ 32:161442 31D9 004 00200300
2026-08-27T14:47:27.678000 -57  I --- 32:161442 --:------ 32:161442 31DA 029 00EF007FFF42420AFA09B0097A0AF5F800004D8C8C001EEFEF16E216C9
2026-08-27T14:47:40.308000 -57  I --- 32:161442 --:------ 32:161442 31D9 004 00200300

[ Voor 22% gewijzigd door TijmenvS op 27-08-2026 15:07 ]

[Wimpie70]

Het lijkt erop dat de FAN wel degelijk reageert en de FAN in de juiste mode zet ?
De log met de comment ('#') gebeurde in 0.56.2 ook al...Maar is wel een fout.

Commando's worden nu bij de FAN bewaard, Hiervoor moet je misschien je automation aanpassen.

Command	Sent	31D9 response	Mode
medium	22F1 003 000207	00200200	2 (medium) ✓
med_60	22F3 007 00123C02040404	00200200	2 (medium) ✓
high_15	22F3 007 00120F03040404	00200300	3 (high) ✓
high_30	22F3 007 00121E03040404	00200300	3 (high) ✓
high_60	22F3 007 00123C03040404	00200300	3 (high) ✓
auto	22F1 003 000407	00200400	4 (auto) ✓
high	22F1 003 000307	00200300	3 (high) ✓

Je kan het volgen op https://github.com/ramses-rf/ramses_cc/issues/1067

[ Voor 5% gewijzigd door Wimpie70 op 27-08-2026 16:09 ]

[TijmenvS]

Hi @Wimpie70: Hij reageerde vanmiddag niet door harder of zachter te gaan blazen. Nu weer even getest en de commando's high_60, medium en med_60 doen het nu wel. Heel vreemd. Geen idee wat er aan de hand zou kunnen zijn, maar blij dat het weer werkt. Ook de automatisering lijkt nu weer te werken.

Ik merk ook nog wel iets anders. De exhaust fan gaat regelmatig naar 1 of 2% als hij auto stand staat en dan op low (15%). Ik vraag me af of hij dat echt doet, want de exaust flow blijft wel gewoon op wat het moet zijn bij 15%. Dus ik denk dat het een weergave issue is. De Supply fan speed blijft gewoon op 15%.

[Wimpie70]

@TijmenvS hmm, die 1 of 2 % is vreemd. Heb je daar logs van ?
Naast de % kan je ook naar de werkelijke flow kijken. Heb je toevallig _extras ook draaien ?


Die # echo blijkt een hardware echo van evofw3 te zijn. ipv RSSI (signaalsterkte) geeft ie een '#' marker. Fix komt eraan...

[ Voor 29% gewijzigd door Wimpie70 op 27-08-2026 16:26 ]

[TijmenvS]

Hij staat nu 16:34 uur sinds 4 minuten op 1,0% volgens Home Assistant. In het logboek en de packetlog staat alleen dit. Hij staat nu op stand medium, de exhaust flow is wel gewoon wat het moet zijn.

code:

Logboek Details (WAARSCHUWING)
Logger: ramses_tx.transport.base
Bron: runner.py:290
Eerst voorgekomen: 10:16:10 (144 gebeurtenissen)
Laatst gelogd: 16:30:54

# I --- 37:123789 32:161442 --:------ 22F3 007 00123C03040404 < PacketInvalid(Null packet)
# I --- 37:123789 32:161442 --:------ 22F1 003 000407 < PacketInvalid(Null packet)
# I --- 37:123789 32:161442 --:------ 22F3 007 00120F03040404 < PacketInvalid(Null packet)
# I --- 37:123789 32:161442 --:------ 22F1 003 000207 < PacketInvalid(Null packet)
# RQ --- 18:183788 32:161442 --:------ 3150 001 00 < PacketInvalid(Null packet)

YAML:

2026-08-27T16:29:50.257000 -58  I --- 32:161442 --:------ 32:161442 31D9 004 00200200
2026-08-27T16:30:54.334207 ... RQ --- 18:183788 32:161442 --:------ 3150 001 00

[Wimpie70]

@TijmenvS nice find. This is also a bug...fix in https://github.com/ramses-rf/ramses_rf/pull/1133

[TijmenvS]

En net stond hij eventjes weer gewoon op 50%, inmiddels weer op 1%. Enige wat ik in de packetlog zie is dit (systeem logboek geeft niets). In de auto modus (en op low) gaf hij trouwens 2% aan.

code:

2026-08-27T16:54:29.189000 -65  I --- 32:161442 --:------ 32:161442 31D9 004 00200200
2026-08-27T16:54:59.158000 -62  I --- 32:161442 --:------ 32:161442 31DA 029 00EF007FFF3D390C440A3C09F60BCAF800004264640000EFEF10431043
2026-08-27T16:57:34.337000 -64  I --- 32:161442 --:------ 32:161442 31D9 004 00200200

Nog een andere puntje: er staan in mijn configuratie-afdeling een aantal sensors met Climarad Ventura in de naam. Die waren er volgens mij in de 0.56.2 versie nog niet. En voor de duidelijkheid: ik heb geen Climarad Ventura.

[Wimpie70]

Ah...dat zijn 2411 params, ofwel FAN configuratie.

Niet alle FAN's ondersteunen dezelfde parameters, maar ze worden (nog) wel allemaal getoond. Als er tenminste 1 param wordt verzonden door de FAN vraagt ie ze allemaal op.

Er staat ClimaRad Ventura achter omdat we deze bij die apparaten hebben gevonden. Ze zijn unknown omdat we ze nog niet goed gedecodeerd hebben.

[ Voor 4% gewijzigd door Wimpie70 op 27-08-2026 17:08 ]

[ebroerse]

Wimpie70 schreef op donderdag 27 augustus 2026 @ 17:05:
Ah...dat zijn 2411 params, ofwel FAN configuratie.

Niet alle FAN's ondersteunen dezelfde parameters, maar ze worden (nog) wel allemaal getoond. Als er tenminste 1 param wordt verzonden door de FAN vraagt ie ze allemaal op.

Wel duidelijk, die param is niet voor jou. Overslaan, maar iemand anders heeft wel een Ventura.

Omdat de fabrikanten allemaal hun eigen invulling laten inbouwen, kunnen we ze ook niet verbergen. Tip uit de Wiki: gebruik de lijst zoals hij in de integratie op je fan verschijnt ook niet voor de bediening. Zet alles wat wel reageert op je eigen dashboard, kan je het ook zelf groeperen ipv onder Diagnose of Configuratie tegen 20 ongebruikte sliders aan te kijken.

Lekker naar je eigen smaak maatwerk, daar is zijn HA dashboards voor.
Ramses RF brengt alleen alles naar de UI, en gast niet met truukjes proberen het ideale setje voor jou te maken, want die zitten in code echt in de weg en HA hiervoor de beste alle tools.

[TijmenvS]

Top, dan negeer ik die gewoon!

Ik heb vandaag weer een paar nieuwe foutmeldingen. Blijkbaar ontvangt mijn gateway al >10 min geen packets. Match wel met de status in HA (auto/low), terwijl de Fan nu op medium draait. Alhoewel die al 25 minuten geleden via diezelfde gateway op medium is gezet. Dat lijkt erop alsof die veranderde stand niet terug is gekomen na het command.

Wellicht kunnen jullie hier iets mee?

code:

Deze fout is ontstaan door een aangepaste integratie.

Logger: custom_components.ramses_cc.coordinator
Bron: custom_components/ramses_cc/coordinator.py:2646
Integratie: RAMSES RF (documentatie, problemen)
Eerst voorgekomen: 10:54:16 (3 gebeurtenissen)
Laatst gelogd: 13:03:15

Gateway appears offline: no packets received for 10+ min(s)

code:

Logger: ramses_tx.transport.base
Bron: runner.py:290
Eerst voorgekomen: 27 augustus 2026 om 10:16:10 (277 gebeurtenissen)
Laatst gelogd: 12:49:16

# RQ --- 37:123789 32:161442 --:------ 2411 003 00004C < PacketInvalid(Null packet)
# RQ --- 37:123789 32:161442 --:------ 2411 003 000088 < PacketInvalid(Null packet)
# RQ --- 37:123789 32:161442 --:------ 2411 003 0000DA < PacketInvalid(Null packet)
# RQ --- 18:183788 32:161442 --:------ 3150 001 00 < PacketInvalid(Null packet)
# I --- 37:123789 32:161442 --:------ 22F1 003 000207 < PacketInvalid(Null packet)

code:

Logger: ramses_rf.pipeline.polling
Bron: runner.py:290
Eerst voorgekomen: 10:31:16 (1 gebeurtenis)
Laatst gelogd: 10:31:16

PollingManager failed to send command 10E0 to 37:999999: <ProtocolContext state=WantEcho cmd_=10E0|RQ|37:999999, tx_count=3/4>: Expired global timer after 20.0 sec

code:

Logger: ramses_tx.protocol.core
Bron: runner.py:290
Eerst voorgekomen: 10:31:16 (1 gebeurtenis)
Laatst gelogd: 10:31:16

QosProtocol(IsInIdle, len(queue)=0): Send timed out for RQ|10E0: <ProtocolContext state=WantEcho cmd_=10E0|RQ|37:999999, tx_count=3/4>: Expired global timer after 20.0 sec

code:

Logger: ramses_tx.protocol.fsm
Bron: runner.py:290
Eerst voorgekomen: 10:31:16 (1 gebeurtenis)
Laatst gelogd: 10:31:16

TOUT.. = <ProtocolContext state=WantEcho cmd_=10E0|RQ|37:999999, tx_count=3/4>: send_timeout=20.0 (True)

[Wimpie70]

Bedankt, dit is gedeeltelijk al gefixed in https://github.com/ramses-rf/ramses_rf/pull/1132, (Packet Invallid) maar is nog niet gereleased.

De timeout en Gateway offline zijn consequenties van deze fout. (en dus ook gefixed)

De FAN status niet geupdate...waarschijnlijk geen bug in de software.

De 10E0 to 37:999999 zal ik nog bekijken. Lijkt een bericht naar een faked device ?

-- edit --

Ja waarschijnlijk. De 1132 fix zou dit ook moeten verhelpen, maar ik zal een extra beveiliging maken dat 'polling' wordt overgeslagen voor faked devices.

[ Voor 16% gewijzigd door Wimpie70 op 28-08-2026 13:47 ]

[ebroerse]

Wimpie70 schreef op vrijdag 28 augustus 2026 @ 13:39:
Bedankt, dit is gedeeltelijk al gefixed [...]

Ramses RF pre-release 0.60.2 staat in HACS, bovenaan de drop down. Bovenstaande fixes zitten daar ook in.

Wie HA Core 2026.9.0 wil installeren zodra die uitkomt begin september, moet eerst Ramses RF 0.60.2 installeren, want door een paar veranderingen in HA start hij anders niet op. We hebben het met de beta-versie getest en het draait ook "gewoon" met de huidige HA Core 2026.8.x.

[Vino75]

Dit weekend, voor mijn EvoHome-only systeem, de upgrade van 56.0 naar 60.1 gedaan. Aanvankelijk dacht ik dat de discovery een probleem had, maar dat lag aan een TRV met lege batterijen. Batterijtjes vervangen, TRV meteen opgepikt door de discovery. Aan de software kant dus geen problemen zover. Aansturing met nieuwe versie werkt ook zoals verwacht.

Deze morgen de upgrade naar 60.2 gedaan en dat ging ook zonder issues.

Voor EvoHome-only eigenaren zie ik geen directe bezwaren om te upgraden.

Aan het Ramses RF team: Een dikke merci!!!

[Turrican]

ebroerse schreef op donderdag 27 augustus 2026 @ 19:14:
[...]


Wel duidelijk, die param is niet voor jou. Overslaan, maar iemand anders heeft wel een Ventura.

Omdat de fabrikanten allemaal hun eigen invulling laten inbouwen, kunnen we ze ook niet verbergen. Tip uit de Wiki: gebruik de lijst zoals hij in de integratie op je fan verschijnt ook niet voor de bediening. Zet alles wat wel reageert op je eigen dashboard, kan je het ook zelf groeperen ipv onder Diagnose of Configuratie tegen 20 ongebruikte sliders aan te kijken.

Lekker naar je eigen smaak maatwerk, daar is zijn HA dashboards voor.
Ramses RF brengt alleen alles naar de UI, en gast niet met truukjes proberen het ideale setje voor jou te maken, want die zitten in code echt in de weg en HA hiervoor de beste alle tools.

Je kunt in je schema bij de fan nu al “_scheme: orcon” invullen. Dan zou je toch best entitities voor andere apparaten automatisch kunnnen verbergen? Is wel iets gebruiksvriendelijker. Dan kun je in ramses_rf ook iets minder op basis van heuristics bepalen wat de juiste mapping is voor fan speeds en modes, want de praktijk heeft al laten zien dat het soms onmogelijk is om het alleen maar vanuit ontvangen radioverkeer af te leiden.

[Wimpie70]

@Turrican We zijn daar op dit moment mee bezig. Maar er moeten nog aardig wat stappen worden gemaakt.

Ik denk dat we een heel eind kunnen komen met de analyse van de berichten, maar dit moet zeker door de gebruiker te overrulen zijn.

[Wimpie70]

@Vino75 Goed om te horen

[ebroerse]

Turrican schreef op zondag 30 augustus 2026 @ 11:19:
[...]

Je kunt in je schema bij de fan nu al “_scheme: orcon” invullen. Dan zou je toch best …

Dacht ik ook, jaren geleden, en het klinkt niet zo ingewikkeld. Tot je concreet naar alle merken, modellen, extra opties en firmware updates kijkt.

En o ja, ondertussen beweegt HA ook nog…Ramses RF 0.60.3 staat voor je klaar in HACS!

[ebroerse]

Ramses RF pre-release 0.60.5 is beschikbaar in HACS.

Het bevat fixes voor CV en HVAC, plus een gloednieuwe optie om de RF-dekking in grote huizen (of met dikke wanden) te verbeteren door meerdere HGI RF-dongels te gebruiken en naar elk apparaat het sterkste sugnaal te gebruiken (nu nog alleen via MQTT, maar een mix met USB staat gepland). Eerst natuurlijk back-uppen!

[jandema]

Ik heb een oude orcon fan die niet past bij de standaard orcon template:
0 is away
1 low
2 medium
3 high
7 disable

29:151989:
_class: REM
_commands:
auto: ' I --- 29:151989 32:231719 --:------ 22F1 003 000404'
away: ' I --- 29:151989 32:231719 --:------ 22F1 003 000004'
disable: ' I --- 29:151989 32:231719 --:------ 22F1 003 000704'
high: ' I --- 29:151989 32:231719 --:------ 22F1 003 000304'
low: ' I --- 29:151989 32:231719 --:------ 22F1 003 000104'
medium: ' I --- 29:151989 32:231719 --:------ 22F1 003 000204'
_faked: true
_owner: me
32:231719:
_class: FAN
_commands:
_comment: Commands on FAN (Phase 3b) — target entity for automations
auto:
code: 22F1
payload: '000404'
verb: I
away:
code: 22F1
payload: '000004'
verb: I
disable:
code: 22F1
payload: '000704'
verb: I
high:
code: 22F1
payload: '000304'
verb: I
low:
code: 22F1
payload: '000104'
verb: I
medium:
code: 22F1
payload: '000204'
verb: I
_owner: me
remotes:
- 29:151989
_owner: me

[jandema]

Ik heb ook een evohome waarbij ik de zone van de interne evohome heb gekoppeld aan een bdr91.
Ik krijg de temperatuur van de evohome te zien, als Woonkamer RAD via CTL 01:123456, ik krijg wel de temperatuur te zien maar geen heat demand. Vroeger met versie ergens tussen 50 en 53.3 kreeg ik wel heat demand te zien en ik heb een vloerverwarming die voor zijn regeling daar van afhankelijk is. Ik ben heel lang op de oude versie blijven hangen omdat ik de nieuwe niet stabiel werkend kreeg..
Onlangs moest ik overgaan vanwege augustus update van home assistant op de laatste versie ramses cc, dat kon ik niet vanwege een bug in een eigen script die er niet tegen kon dat de temperatuur soms via een glitch even none geeft. Blijkbaar crashte die fout de nieuwere versies van ramses. Nadat ik dat had opgelost werkt het geheel weer ok, behalve de heat demand dan die blijft op Unknown staan.

[ebroerse]

jandema schreef op dinsdag 8 september 2026 @ 23:09:
… werkt het geheel weer ok, behalve de heat demand dan die blijft op Unknown staan.

Voor UFH heat_demand komt er een fix in 0.60.6, zie dit issue.

[ebroerse]

jandema schreef op dinsdag 8 september 2026 @ 22:46:
Ik heb een oude orcon fan die niet past bij de standaard orcon template:

0 away
1 low
2 medium
3 high
7 disable

code:

29:151989:
  _class: REM
  _commands:
    auto: ' I --- 29:151989 32:231719 --:------ 22F1 003 000404'
    away: ' I --- 29:151989 32:231719 --:------ 22F1 003 000004'
    disable: ' I --- 29:151989 32:231719 --:------ 22F1 003 000704'
    high: ' I --- 29:151989 32:231719 --:------ 22F1 003 000304'
    low: ' I --- 29:151989 32:231719 --:------ 22F1 003 000104'
    medium: ' I --- 29:151989 32:231719 --:------ 22F1 003 000204'
  _faked: true
  _owner: me
32:231719:
  _class: FAN
  _commands:
    _comment: Commands on FAN (Phase 3b) — target entity for automations
    auto:
      code: 22F1
      payload: '000404'
      verb: I
    away:
      code: 22F1
      payload: '000004'
      verb: I
    disable:
      code: 22F1
      payload: '000704'
      verb: I
    high:
      code: 22F1
      payload: '000304'
      verb: I
    low:
      code: 22F1
      payload: '000104'
      verb: I
    medium:
      code: 22F1
      payload: '000204'
      verb: I
  _owner: me
  remotes:
    - 29:151989
_owner: me

Je mag je YAML het best in een code blok zetten, dan zien we het makkelijker.

En 04 is auto. Geen probleem.
Zolang je deze custom commands in je schema hebt staan onder de FAN, plus een gekoppelde REM, dan pakt hij die.
De lange commando’s onder de REM kun je verwijderen (soms komen ze helaas weer terug, bugje).

Probeer de naam eerst als Hulpmiddelen > Acties > Verstuur afstandbedieningscommando.

[oshiro]

Op de achtergrond alle releases mee geüpdatet, en ik moet zeggen dat ik de vooruitgang echt fantastisch vind! De features om de Evohome zones nu individueel uit te kunnen zetten heb ik echt met blijdschap ontvangen. En ook de persistant notification wanneer de Ramses ESP offline gaat: daar werd ik erg blij van. Scheelt een hoop zoekwerk om te zien waarom er geen data binnenkomt!

Vraag: reflecteert de Gateway Status entity van de HGI ook de online/offline status in MQTT? Of is dat wat anders?

ebroerse schreef op woensdag 9 september 2026 @ 11:21:
[...]


Je mag je YAML het best in een code blok zetten, dan zien we het makkelijker.

En 04 is auto. Geen probleem.
Zolang je deze custom commands in je schema hebt staan onder de FAN, plus een gekoppelde REM, dan pakt hij die.
De lange commando’s onder de REM kun je verwijderen (soms komen ze helaas weer terug, bugje).

Probeer de naam eerst als Hulpmiddelen > Acties > Verstuur afstandbedieningscommando.

Is het ook mogelijk om op deze manier een override te doen op de data die de ventilator uitstuurt? Nu heb ik zelf een helper die de foute waarden van Ramses omzet naar de juiste waarden voor Home Assistant (staat een aantal pagina's terug in dit topic). Dit voelt wat slordig.

Een andere vraag: zit er een feature in de pijplijn om apparaten uit Home Assistant te kunnen deleten? Tijdens de testreleases zijn er wat onbekende apparaten in mijn lijst terecht gekomen, die wil ik er graag uithalen zonder dat ik de hele integratie weggooi en weer terugzet.

En, een laatste vraag: ik heb in de woonkamer een temperatuurzone waarbij de Evohome controller de temperatuursensor is. Die zone fluttert een beetje in temperatuur:


Dit is de enige zone die dit gedrag vertoont, verder werkt alles perfect. Waar zou dit door kunnen komen?

[Wimpie70]

De gateway status checks of er geen bericht is geweest binnen de GATEWAY_MESSAGE_TIMEOUT (10 min default).

Dit is niet hezelfde als een MQTT drop-off.

We zijn bezig om meerdere HGI's te kunnen gebruiken in een pool. Dit kunnen uiteindelijk zelfs verschillende types zijn (MQTT, serial, zigbee). In deze pool wordt er een aparte LWT check gedaan die sneller werkt en probeerd over te schakelen naar een andere HGI in de pool. Deze heeft (nog) geen koppeling met de gateway status.

Dit is op het moment nog in een testfase, waarbij we ook zullen kijken hoe we de status per HGI en ook van de hele pool kunnnen doorzetten naar een entiteit.


Als de waardes die je krijgt van Ramses niet kloppen voor je systeem, maak dan een issue aan. Misschien is er iets niet correct hoe we de codes vertalen voor jouw apparaat. Wel even extra info geven over het device enzo.

Zie Developer Tools → Actions → "RAMSES CC: Remove Device"

Je kan ook een device uitzetten in het schema. Ik denk dat als je dan je caches leegt en herstart hij niet meer terugkomt, maar dat zou je even moeten proberen. Wel eerst even een backup van je schema maken.


Temperature zone flutter: Waarschijnlijk niet een probleem van ramses, maar de evohome controller's eigen ambient sensor. Mijn collega zegt dit erover:

This is almost certainly not a ramses_rf/ramses_cc bug — it's the Evohome controller's own ambient sensor. The chain:

• The zone's temperature comes from 30C9 packets routed into the zone's temp_state 
  
  ingestion.py:394-399.
• When the controller is the zone sensor, those 30C9s originate from the controller itself, and ramses_rf passes the value through verbatim — no smoothing, no dedup, no averaging 
  
  ingestion.py:1018-1040. Whatever the controller broadcasts is what HA shows.

The Evohome controller's internal NTC sensor is known to be noisier than a dedicated TRV/THM — it's inside a wall-mounted box with electronics dissipating heat, so it reads slightly high and oscillates as the box's internal temperature shifts. This is a well-known Evohome characteristic, not a decoding artefact. The other zones use dedicated sensors (TRVs/THMs) which is why only this one flutters.

Practical mitigations oshire can try himself:

• Put a statistics / median / `low-pass sensor** in HA** over the controller-sourced zone temperature (a 5-sample median kills single-step jitter cleanly). This is the standard workaround.
• If feasible, pair a dedicated THM/THM sensor to that zone so the controller stops being the temperature source — the controller will then relay the THM's readings, which are far more stable.

[ebroerse]

oshiro schreef op woensdag 9 september 2026 @ 16:20:
...
een laatste vraag: ik heb in de woonkamer een temperatuurzone waarbij de Evohome controller de temperatuursensor is. Die zone fluttert een beetje in temperatuur: (...) Waar zou dit door kunnen komen?

Die koppeling luistert Ramses RF af van het verkeer/packets die we horen. Kan je laten zien hoe je config schema (onder de CTL) er nu uitziet?
Lijkt ook op het patroon als twee sensors met dezelfde naam (bijv. 'temperature') om en om hun meting naar deze ene HA sensor sturen.

[oshiro]

Wimpie70 schreef op woensdag 9 september 2026 @ 16:48:
De gateway status checks of er geen bericht is geweest binnen de GATEWAY_MESSAGE_TIMEOUT (10 min default).

Dit is niet hezelfde als een MQTT drop-off.

Als mijn Ramses-ESP offline gaat komt er in het MQTT topic "offline" te staan. Dat is voor mij een goede indicator om mijn Ramses-ESP een power cycle te geven (ik geloof dat IMMRMKW al een firmware update heeft gemaakt om dit op te lossen trouwens).

We hebben nu een aantal statussen in Ramses RF (zoals de HGI status). Dat is dus niet hetzelfde? Als het inderdaad niet hetzelfde is, maak ik via MQTT Discovery een extra entity om de MQTT status (online/offline) van de Ramses-ESP weer te geven.

We zijn bezig om meerdere HGI's te kunnen gebruiken in een pool. Dit kunnen uiteindelijk zelfs verschillende types zijn (MQTT, serial, zigbee). In deze pool wordt er een aparte LWT check gedaan die sneller werkt en probeerd over te schakelen naar een andere HGI in de pool. Deze heeft (nog) geen koppeling met de gateway status.

Dit is op het moment nog in een testfase, waarbij we ook zullen kijken hoe we de status per HGI en ook van de hele pool kunnnen doorzetten naar een entiteit.


Als de waardes die je krijgt van Ramses niet kloppen voor je systeem, maak dan een issue aan. Misschien is er iets niet correct hoe we de codes vertalen voor jouw apparaat. Wel even extra info geven over het device enzo.

Zie Developer Tools → Actions → "RAMSES CC: Remove Device"

Dit werkte perfect! (Alleen een bogus evohome temperatuurzone kan niet worden verwijderd - die komt niet door de regex heen vanwege de underscore, zoals: 01:072034_06).

Is er een specifieke reden dat dit niet in de UI van de Ramses RF entities zit? (geen kritiek, pure nieuwsgierigheid - ik had devices met de hand uit het schema verwijderd, maar toen kon ik ze niet meer verwijderen uit HA. Met de hand toegevoegd aan het schema en het verwijderen werkte weer. Boel is mooi opgeschoond!)

Je kan ook een device uitzetten in het schema. Ik denk dat als je dan je caches leegt en herstart hij niet meer terugkomt, maar dat zou je even moeten proberen. Wel eerst even een backup van je schema maken.


Temperature zone flutter: Waarschijnlijk niet een probleem van ramses, maar de evohome controller's eigen ambient sensor. Mijn collega zegt dit erover:


[...]

Temperatuur flutter is opgelost! Naar aanleiding van tip van ebroerse:

ebroerse schreef op donderdag 10 september 2026 @ 09:56:
[...]

Die koppeling luistert Ramses RF af van het verkeer/packets die we horen. Kan je laten zien hoe je config schema (onder de CTL) er nu uitziet?
Lijkt ook op het patroon als twee sensors met dezelfde naam (bijv. 'temperature') om en om hun meting naar deze ene HA sensor sturen.

Er was in het schema inderdaad een sensor automatisch bij gezet. Die sensor heb ik eruit gewipt en nu ziet de grafiek er zo uit:



Bij de pijl had ik de sensor verwijderd en nu is de temperatuur dus keurig zonder dipjes!

Nogmaals dank allemaal - dit is echt een mooie integratie. Ook mooi dat hij al op Silver kwaliteit zit!