Ramses II 868MHz communicatie via evofw3 en ramses_rf

dinsdag 20 januari 2026 10:51

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

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

Acties:

dinsdag 20 januari 2026 13:27

Chill, dude.

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

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

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

“Life is tough, but it's tougher when you're stupid.” - John Wayne | Last.fm

Acties:

dinsdag 20 januari 2026 15:54

Chill, dude.

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

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

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

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

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

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

“Life is tough, but it's tougher when you're stupid.” - John Wayne | Last.fm

Acties:

dinsdag 20 januari 2026 16:37

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

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

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

Succes!

Acties:

Kriseh

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

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

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

Succes!

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

dinsdag 20 januari 2026 17:46

Acties:

Wimpie70

@ebroerse yeah, ik kreeg een

code:

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

Fix is onderweg

Ramses RF - Ramses Extras - Orcon WTW - Duco WTW

dinsdag 20 januari 2026 17:54

Acties:

dinsdag 20 januari 2026 18:30

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

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

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

Acties:

woensdag 21 januari 2026 12:54

Klinkt goed! Ik zal hem vanavond eens installeren.

Acties:

woensdag 21 januari 2026 13:24

Chill, dude.

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

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

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

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

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

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

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

code:

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

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

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

code:

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

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

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

“Life is tough, but it's tougher when you're stupid.” - John Wayne | Last.fm

Acties:

werkmane

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

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

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

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

woensdag 21 januari 2026 15:25

Acties:

woensdag 21 januari 2026 20:47

Chill, dude.

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

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

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

Fan naar standje 3 (high):

code:

1
2
3

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

Fan naar standje 1 (low):

code:

1
2
3

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

Fan naar standje Auto:

code:

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

En hier nog iets dat ik opving:

code:

1
2
3

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

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

“Life is tough, but it's tougher when you're stupid.” - John Wayne | Last.fm

Acties:

woensdag 21 januari 2026 21:16

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

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

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

Acties:

Wimpie70

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

Ramses RF - Ramses Extras - Orcon WTW - Duco WTW

woensdag 21 januari 2026 22:34

Acties:

donderdag 22 januari 2026 08:40

Chill, dude.

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

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

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

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

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

code:

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

Code uiteraard naar smaak aan te passen, maar laat de "off" staan.
Minimalistisch dashboard op basis van bubble card:
Afbeeldingslocatie: https://tweakers.net/i/_rap2OLGMXsswVyxUxmrOTzVC38=/fit-in/4000x4000/filters:no_upscale():strip_exif()/f/image/PBqsh3ZhooxnJUcLudr6DXRq.png?f=user_large

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

code:

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

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

Dit ga ik even bekijken!

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

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

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

“Life is tough, but it's tougher when you're stupid.” - John Wayne | Last.fm

Acties:

Wimpie70

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

Zet zoiets als dit in je Known devices:

code:

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

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

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

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

Ramses RF - Ramses Extras - Orcon WTW - Duco WTW

donderdag 22 januari 2026 14:39

Acties:

zondag 25 januari 2026 17:02

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

Acties:

maandag 26 januari 2026 15:53

Nooit geweten dat hier een draadje loopt over de ramsesrf.

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

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

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

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

Acties:

maandag 26 januari 2026 17:03

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

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

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

Acties:

maandag 26 januari 2026 18:23

Ik ben vooral benieuwd hoe je aan die hgi80 bent gekomen

Acties:

maandag 26 januari 2026 18:23

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

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

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

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

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

de sqlite staat uit

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

Acties:

zaterdag 31 januari 2026 16:26

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

eeh jaren geleden besteld en betaald

Acties:

Kriseh

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

zondag 1 februari 2026 18:28

Acties:

RVerheijden

HU051MR.U44 HN091MR.NK5

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

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

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

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

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

Het bordje ziet er dan zo uit:
[Afbeelding]

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

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

zondag 1 februari 2026 21:59

Acties:

maandag 2 februari 2026 10:29

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

Acties:

maandag 2 februari 2026 12:07

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

Afbeeldingslocatie: https://tweakers.net/i/VvcDg7f3DtWvH-hFGJ9nuLcIuao=/800x/filters:strip_icc():strip_exif()/f/image/3WpKysxa9UR9GtEMAImxmms9.jpg?f=fotoalbum_large

Is dit stiekem een ander protocol dan de thermostaat zaken?

Acties:

vliegnerd

Nintendo fan.

868Mhz

Topicstarter

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

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

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

4,8kW ZO-NW PVOutput 8x300Wp ZO 12 graden. 8x300Wp NW 12 graden.

maandag 2 februari 2026 13:00

Acties:

maandag 2 februari 2026 18:15

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

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

Acties:

woensdag 4 februari 2026 17:49

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

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

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

Acties:

Burn_and_Fire

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

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

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

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

de sqlite staat uit

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

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

woensdag 4 februari 2026 20:08

Acties:

donderdag 5 februari 2026 08:18

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

Acties:

vrijdag 6 februari 2026 22:00

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

Acties:

Burn_and_Fire

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

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

maandag 9 februari 2026 09:27

Acties: