Ramses II 868MHz communicatie via evofw3 en ramses_rf

[asaki]

Ah, mooi nieuws. Bedankt voor de update!

Blijft het mechaniek hetzelfde voor de climate entities? Ik kan me herinneren dat het was: climate.serialnumberEvoHomeCtl_01

Dat lijkt nu het enige te zijn dat mist.

[ebroerse]

asaki schreef op dinsdag 30 juni 2026 @ 19:08:
(…) Alleen mis ik nu de THM kant van de TRV's, enig idee hoe die ontdekt worden? (…)

Bedankt voor het testen. Dit was ook door een collega-tester op GitHub gemeld. Staat op het lijstje in issue 758

0.57.6 met HVAC fixes staat klaar

[ Voor 4% gewijzigd door ebroerse op 30-06-2026 23:23 ]

[ebroerse]

Ramses RF 0.57.7 bevat een nieuwe Action “Discover Known Devices”/“Ontdek bekende apparaten” met dank aan @Wimpie70 .

Stuurt RQ discovery berichten naar apparaten in de known_list die nog niet (goed) geregistreerd zijn. Handig na cache wis of bij herinstallatie. Je krijgt in je system log een rapportje met evt. nieuw gevonden entities.

Aangeraden voor evohome-gebruikers die in de nieuwste releases sensors misten. Maak een kopie van je oude schema. @asaki @JoepW

Voor nieuwe gebruikers met een blanco schema doet deze Actie niet veel, want hij heeft input nodig.

[asaki]

@ebroerse Bedankt! Heb de versie inmiddels geinstalleerd en een knownIds en system schema gemaakt. Er zijn nu wel zones maar de logs staan vol met:

code:

2026-07-02 15:58:37.269 DEBUG (MainThread) [ramses_rf.systems.zones] Pick Zone.name from: ()[0])

Tevens een reply gemaakt op git issue #758

[ebroerse]

asaki schreef op donderdag 2 juli 2026 @ 16:02:
@ebroerse …

Er zijn nu wel zones maar de logs staan vol met:

code:

2026-07-02 15:58:37.269 DEBUG (MainThread) [ramses_rf.systems.zones] Pick Zone.name from: ()[0])

…

Deze logspam is pas begonnen met 0.57.7? Ik ben er mee bezig.

[asaki]

Dat weet ik niet zeker, dit is pas nadat ik manueel de zones in het schema heb geladen. Voorheen gebeurde dat automatisch.

Om het beter te duiden:
Mijn integratie werkt al enige tijd niet meer, dit is geen probleem omdat ik wist dat jullie bezig zijn met een flinke refactor. Ik heb even de cloud integratie gebruikt

Met 0.57 heb ik alles gereset en ben ik opnieuw begonnen met inregelen. Hierbij werden meteen de 01. 04. 10. 18. en 34. evohome devices gevonden maar geen zones. Je zag de zones wel langskomen in de logs:

code:

2026-07-02 16:17:28.271 INFO (MainThread) [ramses_rf.dispatcher] ||  01:013373 |  01:013373 |  I | unknown_2309     |  00  || [{'zone_idx': '00', 'setpoint': 5.0}, {'zone_idx': '01', 'setpoint': 5.0}, {'zone_idx': '02', 'setpoint': 5.0}, {'zone_idx': '03', 'setpoint': 16.5}, {'zone_idx': '04', 'setpoint': 16.0}, {'zone_idx': '05', 'setpoint': 16.5}, {'zone_idx': '06', 'setpoint': 15.5}, {'zone_idx': '07', 'setpoint': 15.5}, {'zone_idx': '08', 'setpoint': 15.5}]
2026-07-02 16:17:28.295 INFO (MainThread) [ramses_rf.dispatcher] ||  01:013373 |  01:013373 |  I | unknown_30C9     |  00  || [{'zone_idx': '00', 'temperature': 23.35}, {'zone_idx': '01', 'temperature': 22.16}, {'zone_idx': '02', 'temperature': 22.64}, {'zone_idx': '03', 'temperature': 21.91}, {'zone_idx': '04', 'temperature': 22.44}, {'zone_idx': '05', 'temperature': 21.24}, {'zone_idx': '06', 'temperature': 21.45}, {'zone_idx': '07', 'temperature': 21.23}, {'zone_idx': '08', 'temperature': 21.11}]

Daarna dus een update gedaan naar 0.57.7, geen verandering in de discovery. Nog steeds alle evohome devices maar geen evohome zones. Ik heb nu een system schema + een knownIds list ingevoerd:

System Schema

code:

"01:013373":
  system:
    appliance_control: "10:058103"
  zones:
    "00":
      _name: Woonkamer
      actuators:
        - "04:128980"
        - "04:128978"
      class: radiator_valve
      sensor: "01:013373"
    "01":
      _name: Slaapkamer 1
      actuators:
        - "04:128826"
      class: radiator_valve
      sensor: "34:190947"
    "02":
      _name: Slaapkamer 2
      actuators:
        - "04:128820"
      class: radiator_valve
      sensor: "34:096372"
    "03":
      _name: Slaapkamer 3
      actuators:
        - "04:128822"
      class: radiator_valve
      sensor: "04:128822"
    "04":
      _name: Kantoor
      actuators:
        - "04:128824"
      class: radiator_valve
      sensor: "04:128824"
    "05":
      _name: Hal
      actuators:
        - "04:128982"
      class: radiator_valve
      sensor: "04:128982"
    "06":
      _name: Washok
      actuators:
        - "04:128984"
      class: radiator_valve
      sensor: "04:128984"
    "07":
      _name: Garage
      actuators:
        - "04:150084"
      class: radiator_valve
      sensor: "04:150084"
    "08":
      _name: Tuinkamer
      actuators:
        - "04:150086"
      class: radiator_valve
      sensor: "04:150086"

Known Device IDs

code:

"01:013373": {}
"04:128820": {}
"04:128822": {}
"04:128824": {}
"04:128826": {}
"04:128978": {}
"04:128980": {}
"04:128982": {}
"04:128984": {}
"04:150084": {}
"04:150086": {}
"10:058103": {}
"18:156972":
  class: HGI
"34:096372": {}
"34:190947": {}

Hiermee verschijnen de zones dus wel, maar met unknown entities. De temperatuur wordt overigens wel doorgegeven, zie deze screenshots:




De debug logs staan vol met:

code:

2026-07-02 23:58:05.584 DEBUG (MainThread) [custom_components.ramses_cc.coordinator] Coordinator: _async_update_data called (Heartbeat)
2026-07-02 23:58:05.584 DEBUG (MainThread) [custom_components.ramses_cc.coordinator] Finished fetching ramses_cc data in 0.000 seconds (success: True)
2026-07-02 23:58:05.588 DEBUG (MainThread) [ramses_rf.systems.zones] Pick Zone.name from: ()[0])
2026-07-02 23:58:05.590 DEBUG (MainThread) [ramses_rf.systems.zones] Pick Zone.name from: ()[0])
2026-07-02 23:58:05.590 DEBUG (MainThread) [ramses_rf.systems.zones] Pick Zone.name from: ()[0])
2026-07-02 23:58:05.591 DEBUG (MainThread) [ramses_rf.systems.zones] Pick Zone.name from: ()[0])
2026-07-02 23:58:05.592 DEBUG (MainThread) [ramses_rf.systems.zones] Pick Zone.name from: ()[0])
2026-07-02 23:58:05.592 DEBUG (MainThread) [ramses_rf.systems.zones] Pick Zone.name from: ()[0])
2026-07-02 23:58:05.593 DEBUG (MainThread) [ramses_rf.systems.zones] Pick Zone.name from: ()[0])
2026-07-02 23:58:05.594 DEBUG (MainThread) [ramses_rf.systems.zones] Pick Zone.name from: ()[0])
2026-07-02 23:58:05.594 DEBUG (MainThread) [ramses_rf.systems.zones] Pick Zone.name from: ()[0])
2026-07-02 23:58:05.597 DEBUG (MainThread) [ramses_rf.systems.zones] Pick Zone.name from: ()[0])

Zo ver ik kan zien is de zone detectie/registratie nog niet optimaal

Laat maar weten als je meer nodig hebt.

[ Voor 95% gewijzigd door asaki op 03-07-2026 09:06 ]

[ebroerse]

Auto-discovery werkt idd niet meer sinds 0.55.3, en gaat ook niet meer “zomaar” werken. Als je je (oude) schema invult, dan werkt het al 80%. Dus zorg nog even goed voor je oude schema…

Het alternatief komt er binnenkort aan: je zet in Config een service aan, die toont een lijst van gevonden items en dan kruis je aan welke items je wilt gebruiken in HA; dat wordt je schema. Je moet nu ook al de Known List zelf intikken, dat was net zoveel werk.

Voor verwarming en ventilatie werkt het dan (bijna) hetzelfde.

[ebroerse]

Ramses RF pre-release 0.57.10 staat klaar in HACS.

De Wiki is ook bijgewerkt, met o.a. een nieuw voorbeeld van een compleet evohome Schema (nog wel je eigen adressen invullen ) en uitleg over de 2 logs in de FAQ.

[asaki]

Ha @ebroerse: Ik heb net deze versie geinstalleerd en een cache clear gedaan. Schema + knownids lijst ingelezen.

Ik zie nu geen foutmeldingen meer in de logs over de zones, maar de zones werken nog niet. De zone reflecteert zeg maar wat in het schema staat, maar alle entities zijn "unknown", ook na 10 uur gewacht te hebben. Is dat ook jouw beeld in deze versie of zou dat nu moeten werken?

[ Voor 33% gewijzigd door asaki op 07-07-2026 09:03 ]

[ebroerse]

asaki schreef op dinsdag 7 juli 2026 @ 09:01: ... maar de zones werken nog niet. De zone reflecteert zeg maar wat in het schema staat, maar alle entities zijn "unknown", ook na 10 uur gewacht te hebben. Is dat ook jouw beeld in deze versie of zou dat nu moeten werken?

Klopt je schema, als je het vergelijkt met de vooebeelden in de Wiki > Config > Stap 3?

De nieuwe evohome fragmenten werken met 0.57.10, maar het is wennen dat Ramses RF tegenwoordig wacht op actuele gegevens i.p.v. uit het archief de vorige temperatuur alvast in te vullen. Sommige info wordt niet vaak verstuurd, als dat kan stuurt hij er dan een RQ (request) voor.

[ Voor 22% gewijzigd door ebroerse op 07-07-2026 22:52 ]

[asaki]

ebroerse schreef op dinsdag 7 juli 2026 @ 22:47:
[...]

Klopt je schema, als je het vergelijkt met de voorbeelden in de Wiki > Config > Stap 3?

Ik denk het wel, dit is mijn schema:

code:

"01:013373":
  system:
    appliance_control: "10:058103"
  zones:
    "00":
      _name: Woonkamer
      actuators:
        - "04:128980"
        - "04:128978"
      class: radiator_valve
      sensor: "01:013373"
    "01":
      _name: Slaapkamer 1
      actuators:
        - "04:128826"
      class: radiator_valve
      sensor: "34:190947"
    "02":
      _name: Slaapkamer 2
      actuators:
        - "04:128820"
      class: radiator_valve
      sensor: "34:096372"
    "03":
      _name: Slaapkamer 3
      actuators:
        - "04:128822"
      class: radiator_valve
      sensor: "04:128822"
    "04":
      _name: Kantoor
      actuators:
        - "04:128824"
      class: radiator_valve
      sensor: "04:128824"
    "05":
      _name: Hal
      actuators:
        - "04:128982"
      class: radiator_valve
      sensor: "04:128982"
    "06":
      _name: Washok
      actuators:
        - "04:128984"
      class: radiator_valve
      sensor: "04:128984"
    "07":
      _name: Garage
      actuators:
        - "04:150084"
      class: radiator_valve
      sensor: "04:150084"
    "08":
      _name: Tuinkamer
      actuators:
        - "04:150086"
      class: radiator_valve
      sensor: "04:150086"

De TRV's rapporteren alles prima. Dus battery, heat demand, temperature en window open komen prima binnen. Maar de zones hebben alleen een heat demand waarde (0.0%), de rest is unknown.

De data voor de zones komt wel langs:

code:

2026-07-08 11:30:45.295 INFO (MainThread) [ramses_rf.dispatcher] ||  01:013373 |  01:013373 |  I | unknown_30C9     |  00  || [{'zone_idx': '00', 'temperature': 23.65}, {'zone_idx': '01', 'temperature': 23.79}, {'zone_idx': '02', 'temperature': 24.22}, {'zone_idx': '03', 'temperature': 21.85}, {'zone_idx': '04', 'temperature': 23.41}, {'zone_idx': '05', 'temperature': 21.58}, {'zone_idx': '06', 'temperature': 21.64}, {'zone_idx': '07', 'temperature': 21.59}, {'zone_idx': '08', 'temperature': 21.53}]

Alleen lijkt het er op dat die data niet bij de zone entities terecht komt.

Moeten de zones ook in de known ids lijst?

[ Voor 18% gewijzigd door asaki op 08-07-2026 11:37 ]

[ebroerse]

asaki schreef op woensdag 8 juli 2026 @ 11:24:
[...]
...
het er op dat die data niet bij de zone entities terecht komt.

Moeten de zones ook in de known ids lijst?

Nee, de zones hoeven niet in de known list te staan. Ze zijn in het schema al onderdeel van je CTL.

[vliegnerd]

Ik heb sinds 0.57.x (denk ik) last van langzaam oplopend CPU (niet geheugen) gebruik. Draai 0.57.10 op HA 2026.7.2 via HAOS 18.1. Alles geupdatet.

Na herstart HA loopt CPU gebruik langzaam op en HA wordt trager. Na een paar uur reageert HA niet meer en is een herstart nodig. Reproduceerbaar. Ramses RF uitschakelen lost het probleem op. Weet niet zeker of het aan RAMSES RF ligt, maar lijkt er wel op.

In ha core logs zie ik alleen maar WARNINGs over legacypacketshims: 2 per minuut ofzo, niet veel en geen ERRORs.

Ik zal als ik meer info heb ook een issue op github aanmaken. Is dit herkenbaar? Tips om uit te sluiten dat het RAMSES RF is?

Ik draai HAOS op proxmox, kan makkelijk een nieuwe VM op spinnen met een "kale" HA met RAMSES RF. Dat zal ik proberen als ik niets anders kan vinden.

EDIT: 0.57.12 pre-release nu maar geinstalleerd.

[ Voor 3% gewijzigd door vliegnerd op 12-07-2026 17:34 ]

[Wimpie70]

@vliegnerd het lijkt hierop: https://github.com/ramses-rf/ramses_cc/issues/795

Ben benieuwd of het voor jou met 0.57.12 verholpen is.

[ Voor 16% gewijzigd door Wimpie70 op 12-07-2026 18:10 ]

[vliegnerd]

Wimpie70 schreef op zondag 12 juli 2026 @ 18:08:
@vliegnerd het lijkt hierop: https://github.com/ramses-rf/ramses_cc/issues/795

Ben benieuwd of het voor jou met 0.57.12 verholpen is.

0.57.12 lost dit inderdaad op!

CPU gebruik weer laag en blijft laag.

dank!

[ebroerse]

Ramses RF 0.57.12 staat klaar in HACS.

Met evohome blijven enkele sensors nog Onbekend, maar de basis loopt.
HVAC bypass_positie en filter_remaining zijn gefixt. Zie de release notes voor meer.

[posttoast]

Sinds ik op 0.57.12 zit valt het me op dat de status van mijn Orcon WTW (wtw_fan_info) veel trager update. Als ik naar stand 3 ga duurt het zomaar een minuut voordat wtw_fan_info dat ook weergeeft. Hebben meer mensen dit probleem? Het zou kunnen dat het al in een eerdere update zat, ik heb een paar versies overgeslagen.

[Wimpie70]

Klopt, voor een aantal entities is polling teruggezet naar HA. Zo was het in oudere versies ook en is de aanbevolen manier voor HA. De methode die in een aantal versies (met snelle respons) gaf andere problemen.

Ik weet even niet of dit voor het zetten van de mode nog gaat veranderen, maar je kan altijd zelf een 31DA er achteraan sturen als je het direct wilt weten.

[posttoast]

Wimpie70 schreef op dinsdag 14 juli 2026 @ 11:22:
Klopt, voor een aantal entities is polling teruggezet naar HA. Zo was het in oudere versies ook en is de aanbevolen manier voor HA. De methode die in een aantal versies (met snelle respons) gaf andere problemen.

Ik weet even niet of dit voor het zetten van de mode nog gaat veranderen, maar je kan altijd zelf een 31DA er achteraan sturen als je het direct wilt weten.

Ik heb het nu iets anders aangepakt: ik laat HA alle rf-frames een custom sensor triggeren, die checkt of er een wijziging is:

YAML:

  sensor:
    - name: "Orcon WTW Fan Info Clean"
      unique_id: orcon_wtw_fan_info_clean
      icon: mdi:fan
      state: >
        {% set bad = ['unknown', 'unavailable', 'none', 'None', none] %}
        {% set d = trigger.to_state.attributes.get('data', {}) if trigger.id == 'rf' else {} %}
        {% set p = d.get('payload', {}) if d is mapping else {} %}
        {% if d.get('code') == wtw_code and d.get('src') == wtw_src and p.get('fan_info') %}
          {{ p.get('fan_info') }}
        {% elif this.state not in bad %}
          {{ this.state }}
        {% else %}
          {{ states('sensor.orcon_wtw_fan_info') }}
        {% endif %}

Beetje van mezelf, en een beetje van Claude

Het voordeel hiervan is dat ik het ook direct te zien krijg als ik met een fysieke remote de stand aanpas. Die "31DA-truc" werkt natuurlijk alleen als ik vanuit Home Assistant de stand trigger.

[ebroerse]

Wimpie70 schreef op dinsdag 14 juli 2026 @ 11:22:
… voor een aantal entities is polling teruggezet naar HA.
…
je kan altijd zelf een 31DA er achteraan sturen als je het direct wilt weten.

HA polling wordt nu alleen gebruikt om filter_remaining (10D0) op te vragen, wat nooit spontaan wordt verstuurd (en dat werkt weer, zonder herstart).

Alle sensors die van 31DA afhankelijk zijn (temps, RVs, mode, CO2, flow etc) zitten rustig te wachten tot de Fan zo’n bericht zelf stuurt. De ene Fan doet dat vaker dan de andere, maar zeker niet zo vaak als 12A0 (ook temp, RV) of 22F1 (fan speed). Behalve na het opstarten heeft het niet veel zin om dat te pollen, want als het verandert, dan komt er met een minuutje wel een berichtje.

Bij mijn MiniBox Fan lijkt de "reactiesnelheid" afh. van of je net voor, of net na het vaste ritme van updates opdracht geeft... Max. 90 s.

TRVs (radiatorknoppen) zijn echt traag, i.v.m. de batterij.

[ Voor 8% gewijzigd door ebroerse op 15-07-2026 17:47 ]

[ebroerse]

Ramses RF 0.58.0 is net uit, met als belangrijkste nieuwigheid de Passive Discovery Scan (dank @Wimpie70) Die tool helpt je om je System Schema in te vullen op basis van je known_list en binnenkomend RF-verkeer.

Getest met HVAC en met CH/evohome. Maak een backup, nooit verkeerd, en probeer het. Lees eerst ramses_cc Wiki pag. 2.1 voor uitleg.

[ Voor 4% gewijzigd door ebroerse op 15-07-2026 17:29 ]

[posttoast]

ebroerse schreef op woensdag 15 juli 2026 @ 15:55:
Ramses RF 0.58.0 is net uit, met als belangrijkste nieuwigheid de Passive Discovery Scan. Die helpt je om je schema in te vullen op basis van je known_list en binnenkomend RF-verkeer.

Getest met HVAC en met CH/evohome. Maak een backup, nooit verkeerd, en probeer het. Lees eerst ramses_cc Wiki pag. 2.1 voor uitleg.

Is er eigenlijk ook een manier om oude/verkeerde devices te verwijderen? Ik heb een device waarvan ik destijds dacht dat ie van mij was, maar dat is toch niet het geval. Ik heb hem disabled, maar verwijderen kan niet.

Ik weet dat de "workaround" is om heel ramses_cc weg te gooien en opnieuw te beginnen (met de known id's ingevuld), maar dat voelt wat omslachtig

[Wimpie70]

De known Id's lijst gaat uiteindelijk verdwijnen. Het schema blijft, maar wordt de 'single source of thruth'.

Hierin komen alle devices die het systeem tegenkomt. Je kan dan idd wel aangeven of een device _disabled is, of beter nog: _owner: buurman nr 63.

Met de automatische discovery moet het systeem wel weten of een device al bekeken en geclassificeerd is.

Als je een device uit je schema verwijderd, en er weer berichten van binnenkomen, dan zal je een melding krijgen. Vervolgens kan je via de opties deze weer accepteren of juist niet (of overslaan voor latere beslissing).

[ Voor 40% gewijzigd door Wimpie70 op 15-07-2026 19:34 ]

[posttoast]

Wimpie70 schreef op woensdag 15 juli 2026 @ 17:08:
De known Id's lijst gaat uiteindelijk verdwijnen. Het schema blijft, maar wordt de 'single source of thruth'.

Hierin komen alle devices die het systeem tegenkomt. Je kan dan idd wel aangeven of een device _disabled is, of beter nog: _owner: buurman nr 63.

Met de automatische discovery moet het systeem wel weten of een device al bekeken en geclassificeerd is.

Als je een device uit je schema verwijderd, en er weer berichten van binnenkomen, dan zal je een melding krijgen. Vervolgens kan je via de opties deze weer accepteren of juist niet (of overslaan voor latere beslissing).

OK, maar als ik je goed begrijp krijg ik hier straks dan een gigantische lijst van devices? Ik woon in een nieuwbouwwijk waar iedereen Orcon WTW's met afstandsbedieningen én Itho WPU's met Spiders en AutoTemps heeft die over 868MHz communiceren.

[Wimpie70]

Als je van alle 868 devices in je buurt berichten krijgt, dan heb je een uitstekende HGI. Welke is dat ?

[posttoast]

Wimpie70 schreef op woensdag 15 juli 2026 @ 20:05:
Als je van alle 868 devices in je buurt berichten krijgt, dan heb je een uitstekende HGI. Welke is dat ?

Nou, ik durf niet te zeggen of ze het allemaal zijn, maar wel veel Ik gebruik die van Indalotech

[Wimpie70]

Prima ding. Ik heb er zelf 2. Op dit moment kan er maar 1 gebruikt worden in Ramses RF, maar het is de bedoeling dat er meerdere kunnen worden aangestuurd (die het beste bereik naar je device heeft). Juist omdat mensen soms last hebben om de ontvangst betrouwbaar te krijgen (dikke muren, grote afstand).

Nog steeds kan je een aardige lijst krijgen, maar deze wordt meen ik (nog even nakijken of dit goed werkt) nu al gesorteed op heat/hvac en op _owner. Dus alles wat je nodig hebt staat bij elkaar. 1 keer aangeven dat een device niet van jou is en je hebt er geen last meer van. Sterker nog, je kan juist altijd zien dat ie niet van jou is.

In de device_comments wordt niet alleen aangegeven wat waarschijnlijk het type device is, maar ook de RSSI. Hiermee kan je zien of het apparaat ver of dichtbij je HGI staat, en kan je dus helpen om te bepalen of het van jou of van je buurman 3 huizen verderop is.

Het schema wordt zelfs nog iets langer. Nu staan commando's nog in de known list. Deze gaan ook naar het schema, maar uiteindelijk wordt dit ingebakken in Ramses zelf. Alleen overrides staan er dan nog in. Als je meer over de ontwikkelingen wilt weten...er staat aardig wat over op github.

[ Voor 33% gewijzigd door Wimpie70 op 15-07-2026 20:46 ]

[ebroerse]

[quote]
posttoast schreef op woensdag 15 juli 2026 @ 20:01:
[...]

als ik je goed begrijp krijg ik hier straks dan een gigantische lijst van devices? Ik woon in een nieuwbouwwijk ....

Dat hadden we altijd al, totdat je "Alleen van bekende apparaten" aanzet. Ook dan had je als beginner geen idee, wat jouw Orcon was...
Waar Ramses RF tijdens de scan nu allemaal op let, is een stuk beter opgebouwd, waardoor we fouten ook kunnen vinden (en fixen). Er was echt vraag naar een vorm van Discovery, en dit is het geworden.
Stel dat we een minimum signaalsterkte zouden toevoegen, zal je zien dat gebruikers hun eigen Orcon door al het beton niet in de lijst zien.

[posttoast]

ebroerse schreef op woensdag 15 juli 2026 @ 20:46:
[quote]
posttoast schreef op woensdag 15 juli 2026 @ 20:01:
[...]


[...]

Dat hadden we altijd al, totdat je "Alleen van bekende apparaten" aanzet. Ook dan had je als beginner geen idee, wat jouw Orcon was...
Waar Ramses RF tijdens de scan nu allemaal op let, is een stuk beter opgebouwd, waardoor we fouten ook kunnen vinden (en fixen). Er was echt vraag naar een vorm van Discovery, en dit is het geworden.
Stel dat we een minimum signaalsterkte zouden toevoegen, zal je zien dat gebruikers hun eigen Orcon door al het beton niet in de lijst zien.

Klopt inderdaad, ik heb Accept packets from known devices IDs only nu aan staan. Maar zit de nieuwe functionaliteit er nu al in (in 0.58.0)? Of komt ie nog? Ben wel benieuwd

[ebroerse]

posttoast schreef op woensdag 15 juli 2026 @ 21:00:
[...]

… Maar zit de nieuwe functionaliteit er nu al in (in 0.58.0)?

Ja, vanaf 0.58.0 kan je dit inschakelen in Integraties > Ramses RF > Config tandwiel > Geavanceerde Opties > Schakel passieve apparaat-scan in. Zie de ramses_cc Wiki, p. 2.1.

[ebroerse]

Ramses RF pre-release 0.58.1 bevat een fix om de laatste waarde van je sensors uit de packet cache te laden na herstart.
Je moet na update nog wel je packet cache wissen in Voorkeuren > Cache beheren omdat de oude ongeldig waren.

[ebroerse]

Ramses RF 0.58.2 staat in HACS, popt op in HA.

Een “echte” release, stabiel met de bugjes voor evohome en hvac opgelost.

In Config moet je een schema invullen, en daarvoor is er de passieve apparaat-scan die je aanzet op de achtergrond is een waardige opvolger van het ‘eavesdroppen’ en dit werkt ook voor Ventilatie. Zie de Wiki

En: eerst backuppen, natuurlijk. Als het nu “gewoon werkt” kun je updates overslaan.

[ Voor 8% gewijzigd door ebroerse op 17-07-2026 15:06 ]

[ebroerse]

Ramses RF 0.58.4 is uit, met weer div. kleine foutjes gefixt, verfijningen in de notificaties van de Passieve Apparaat Scan en correcte DHW class toewijzing.

[JoepW]

Ik voel een moment aankomen dat ik maar eens van stokoude cc en rf naar de laatste versie ga.

Complimenten @ebroerse & @Wimpie70 (en andere bijdragers) voor het vele werk dat jullie gedaan hebben en doen!

[JoepW]

De dongle voorzien van de laatste FW en all software bijgewerkt. Nu ook alles via MQTT geregeld. Werkt perfect!

[ebroerse]

Wie mee wil testen kan Ramses RF pre-release 0.59.1 in HACS vinden.

Eerst even backuppen; er is onder de motorkap veel verbeterd, maar het moet zich in het echt bewijzen. Het Config schema en de passive device scan is compleet en heel mooi geworden.

Foutmeldingen in versies t/m 0.58.x niet meer in GitHub melden. Werk eerst bij naar de meest recente versie, en zet er duidelijk bij welke je draait (niet: “de laatste”). Hiermee help je de ontwikkelaars.

[Phyth0n]

Zelf aan het klooien om in 0.59.0 de entities gevuld te krijgen met data, ik heb al mijn devices in de Ramses integratie staan, met naar mijn idee de juiste known devices met goede classes.

In de packet log zie ik de juiste informatie voorbij komen tussen de juiste devices, dus deze data bereikt ramses cc/rf goed. Na een update naar 0.59.1 zie ik helemaal niets meer in de packet log. Als ik passive device scan aanzet zie ik prima allemaal mogelijke devices in de lijst komen, dus dat werkt wel.

Nu terug op 0.59.0(na verwijderen en opnieuw installeren+configureren) zie ik weer van alles in de pocketlog, maar mijn entities blijven unknown.

Paar maanden terug lukte het mij ook niet om dit netjes in Home Assistant te krijgen, nu weer een paar uur bezig zonder resultaat. Wat doe ik verkeerd? of loop ik tegen een bug aan?







Situatie:

• Ramses ESP via MQTT verbonden met HA
• Orcon HRC400 en RF15 die ik wil uitlezen/aansturen

[ebroerse]

Phyth0n schreef op zaterdag 1 augustus 2026 @ 21:27:
... Na een update naar 0.59.1 zie ik helemaal niets meer in de packet log. Als ik passive device scan aanzet zie ik prima allemaal mogelijke devices in de lijst komen, dus dat werkt wel. …

Ik zou 0.59.1 proberen.

Passive device scan vraagt je om die gevonden apparaten te accepteren, pas dan gaat Ramses RF er mee “praten”. Je log toont alleen RQ’s, geen antwoorden. Heb je alle devices geaccepteerd met owner:me incl. je bridge (18:xxxxxx) ?

Kan je dan het schema (bovenste vakje) uit je config hier plakken?

[Phyth0n]

ebroerse schreef op zondag 2 augustus 2026 @ 08:01:
[...]

Ik zou 0.59.1 proberen.

Passive device scan vraagt je om die gevonden apparaten te accepteren, pas dan gaat Ramses RF er mee “praten”. Je log toont alleen RQ’s, geen antwoorden. Heb je alle devices geaccepteerd met owner:me incl. je bridge (18:xxxxxx) ?

Kan je dan het schema (bovenste vakje) uit je config hier plakken?

Bedankt dat je meekijkt/denkt. ik heb 0.59.1 al geprobeerd, dat helpt niet om de entities te vullen en dan zijn de packet logs ook leeg.

Zoals je omschrijft heb ik de passive device scan ook gebruikt; mijn known devices:

YAML:

oud, zie nieuwe post 

Schema:

YAML:

oud, zie nieuwe post

Ik heb het idee 2 problemen te hebben:

1. in Ramses RF/CC worden de binnenkomende pakketen niet goed doorgegeven aan de entiteiten.
2. als ik zelf handmatig een command verstuur(opgesteld m.b.v. Gemini) dan zie ik deze ook niet in de packetlog voorbij komen. Hier is wellicht iets niet goed ingesteld op/met de Ramses ESP, dit zou ik wel raar vinden omdat ik wel de MQTT berichten voorbij zie komen als ik daar meekijk.

Update: Het lijkt aan de SNTP settings te liggen op de Ramses ESP, als ik in de debuglog kijk, ik ga dat verhelpen en dan kom ik hier weer terug.

Update2: Het lag aan de SNTP settings, wel vaag dat de timezone op een URL stond en ook niet op CET gezet wilde worden. Op geen enkele manier lukte dit, als ik CEST invulde lukte dit wel. Als ik daarna weer op CET wilde configureren kwam de MQTT URL terug. Uiteindelijk gelukt om hem op CET-1CEST,M3.5.0,M10.5.0/3 te zetten, dat accepteerde hij wel. Hiermee punt 1 verholpen, punt 2 nog niet. ik zie de command ook niet voorbij komen als ik serieel meelees.

[ Voor 47% gewijzigd door Phyth0n op 02-08-2026 17:04 ]

[ebroerse]

Phyth0n schreef op zondag 2 augustus 2026 @ 09:47:
[...]

...

Update: Het lijkt aan de SNTP settings te liggen op de Ramses ESP, als ik in de debuglog kijk, …

Goed om bij elk probleem debug logging aan te zetten en in het HA system log te kijken inderdaad.

Als je SNTP niet goed staat, keurt Ramses RF elk packet af als te oud/te nieuw. Dus dat is belangrijk. Kan via MQTT, maar ik heb de dongle even via serial aan de terminal gehangen.

[ebroerse]

Ramses RF pre-release 0.59.2 staat in HACS. Fixes en veel efficiency wins, vooral in de ramses_rf lib.

[ebroerse]

Weekje later: Ramses RF 0.59.4 is uit met fixes en verbeteringen. Bedankt voor de feedback

[asaki]

Is het upgrade pad (vanaf 0.59) nog steeds laatste versie via HACS binnen halen en na de herstart een clear system state?

[Gerritjuh]

Vandaag kreeg ik een update aangeboden. Ik heb die achteloos geïnstalleerd en door omstandigheden vergeten. Totdat ik de badkamer in liep en de CV vrolijk op vol vermogen stond te verwarmen. Ik twijfelde eerst aan de Honeywell apparatuur, maar later werd duidelijk dat het door de automatische update kwam.

Ik heb nu alles losgekoppeld en pik het later wel weer op. Aangezien ik nu met andere dingen bezig ben heb ik even geen zin in troubleshooten, dat kost me teveel waardevolle tijd.

Ik wil het wel even melden, wellicht dat anderen er ook hinder van ondervinden.

[asaki]

Goed om te weten van welke versie je af komt. Er is flink wat veranderd onder de motorkap

[Gerritjuh]

asaki schreef op maandag 10 augustus 2026 @ 23:24:
Goed om te weten van welke versie je af komt. Er is flink wat veranderd onder de motorkap

Ik kom van 0.59.1 of 0.59.2 af… door de frustratie heb ik alles verwijderd. Als het buiten nog en aangename temperatuur is en binnen staat de kachel aan… dan doet dat iets met mij.

Overigens, de CV stond gewoon op 100% te branden.

Zoals ik ik eerder aangaf dacht ik aan het evohome systeem, die doet ook soms gek (daarom was ik met Ramses gestart). Aangezien ik in de vluggigheid geen storing kon vinden heb ik dat als eerste afgekoppeld en een normale thermostaat teruggezet. Enig moment later realiseerde ik me dat ik ook een update had gedaan van Ramses. Toen zag ik pas dat, dat de oorzaak was.

[ebroerse]

Ramses RF 0.59.6 staat in HACS.

Onder de motorkap weer veel verbeteringen: geheugengebruik, minder schrijven naar SD, 2411 parameters, sensors faken en passief scannen (configuratieschema).

[Vino75]

@ebroerse & team, Allereerst, bedankt voor jullie geweldige werk aan dit project!

Ik draai enkel EvoHome middels de hardware van @immrmkw en doe dat op Ramses RF 0.56.0. Op dit moment is mijn opzet de simpelste variant, waarbij ik lokaal de EvoHome controller commando's stuur zodat ik de TotalConnectComfort cloud niet nodig heb. Dus geen setup waarbij ik de Evohome controller overbodig maak.

Inmiddels staat HACS al een tijdje aan te geven dat de update naar 0.59.3 klaar staat. Nu zit ik echter te twijfelen of ik moet upgraden voor mijn specifieke installatie. Als ik het motto "don't fix if it aint broken" volg, dan skip ik die upgrade. Anderzijds zie ik zoveel updates voorbij komen dat het begint te kriebelen om die nieuwe versie te gaan proberen. Alleen zit ik hier thuis met een zelfstandige met een massagepraktijk, de voornaamste reden om toendertijd de stap naar Evohome te zetten. Het moet dus allemaal wel blijven werken. De WAF van mijn HA hobby krijgt serieuze minpunten als het niet (goed) werkt en dat ze mij continue als helpdesk moet inschakelen.

Dus bij deze mijn vraag of eigenlijk 2:

- blijf ik beter nog even op 0.56.0 met alleen Evohome gebruik of kan ik relatief veilig upgraden naar 0.59.3?

- is er een roadmap met changes die voor de komende releases op de planning staan, en zo ja, waar kan ik die vinden?

[ebroerse]

Vino75 schreef op zondag 16 augustus 2026 @ 12:39:

(…)
Dus bij deze mijn vraag of eigenlijk 2:

- blijf ik beter nog even op 0.56.0 met alleen Evohome gebruik of kan ik relatief veilig upgraden naar 0.59.3?

- is er een roadmap met changes die voor de komende releases op de planning staan, en zo ja, waar kan ik die vinden?

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.

[ebroerse]

Ramses RF pre-release 0.59.7 staat in HACS met fixes voor evohome, maar als je ramses_extras ook gebruikt dan kun je beter wachten met updaten want _extras 0.21.1 (en eerder) start niet foutloos op met deze versie.

Dat staat ook in grote letters bovenaan de release notes, maar die lees je mss heeeel snel 🥵

[ Voor 20% gewijzigd door ebroerse op 16-08-2026 21:54 ]

[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!

[Wimpie70]

Testers gezocht.

Er is een nieuwe pre-release uit voor Ramses RF (0.60.6). Deze heeft naast een aantal bugfixes nu ook ondersteuning voor meerdere HGI's. Dit kan problemen met slecht bereik, etc. oplossen.

Zowel MQTT als USB devices kunnen worden gebruikt in een 'pool'. Als je de mogelijkheid hebt, graag testen. Mocht je iets tegenkomen, graag een issue aanmaken op https://github.com/ramses-rf/ramses_cc/issues


Zigbee ondersteuning komt er aan.


P.s, laat het ook even weten als je het hebt getest en er geen problemen zijn...Er zullen nog niet zoveel mensen zijn met meerdere HGI's...

[ Voor 12% gewijzigd door Wimpie70 op 15-09-2026 18:31 ]

[Wimpie70]

Ramses RF 0.60.7 pre-release heeft nu ook ondersteuning voor Zigbee HGI's. Daarnaast nog een aantal wijzigingen van actions, status/device etc. Zie de release-notes, vooral als je actions gebruikt in je automations. Er waren 6 verschillende get/set - param-actions, nu nog maar 2.

Ramses Extras 0.22.0 pre-release heeft een nieuwe feature met dashboard kaart die een overzicht geeft van je devices met hun status, signaalsterkte naar de best beschikbare HGI en de status van je HGI-pool