Ramses II 868MHz communicatie via evofw3 en ramses_rf

[JoepW]

ebroerse schreef op vrijdag 8 mei 2026 @ 20:29:
[...]

Pre-release 0.56.7 is uit. Weer een stuk beter met evohome, maar ik kan niet garanderen dat alle sensors werken.

Loop je met de versie die je nu draait in HA tegen meldingen aan?

Ik heb af en toe dat er zone opeens een andere target temperatuur heeft zonder dat ik iets kan vinden in logs…

[ebroerse]

Heb ik 1x gezien: issue https://github.com/ramses-rf/ramses_cc/issues/651

Welke versie draaide je voordat je bijwerkte?

Je cache legen kan het oplossen, maar is natuurlijk niet de bedoeling.

[ Voor 70% gewijzigd door ebroerse op 09-05-2026 12:15 ]

[asaki]

0.56.0, de cache legen werkte. Bedankt!

[woolysheep]

Had hetzelfde probleem, kwam van 56.6. cache legen lost het probleem op.

Filter time remaining werkt nu ook weer, fijn. Dank!

[asaki]

Goed, na het opruimen van de cache werkte eigenlijk helemaal niets meer. Geen enkel device werd nog gevonden. Ik heb het een dagje laten draaien maar niets was bereikbaar. Ze bestonden nog wel als entiteiten maar alles was unavailable.

Ik heb de ramses integratie verwijderd en probeer deze nu weer te installeren, maar ik krijg nu alleen maar de TRV terug, en niet meer de THM devices. Dit is met de laatste versie van Ramses. Terug naar versie 0.56.0 kan niet meer, die geeft onderstaande error:

code:

2026-05-10 14:08:28.884 ERROR (MainThread) [aiohttp.server] Error handling request from 172.22.0.3
Traceback (most recent call last):
  File "/usr/local/lib/python3.14/site-packages/aiohttp/web_protocol.py", line 517, in _handle_request
    resp = await request_handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.14/site-packages/aiohttp/web_app.py", line 569, in _handle
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.14/site-packages/aiohttp/web_middlewares.py", line 117, in impl
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/security_filter.py", line 92, in security_filter_middleware
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/forwarded.py", line 214, in forwarded_middleware
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/request_context.py", line 26, in request_context_middleware
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/ban.py", line 90, in ban_middleware
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/auth.py", line 263, in auth_middleware
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/headers.py", line 41, in headers_middleware
    response = await handler(request)
               ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/http.py", line 89, in handle
    result = await handler(request, **request.match_info)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/decorators.py", line 83, in with_admin
    return await func(self, request, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/data_validator.py", line 74, in wrapper
    return await method(view, request, data, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/config/config_entries.py", line 188, in post
    return await self._post_impl(request, data)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/config/config_entries.py", line 195, in _post_impl
    return await super()._post_impl(request, data)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/data_entry_flow.py", line 83, in _post_impl
    result = await self._flow_mgr.async_init(
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    ...<2 lines>...
    )
    ^
  File "/usr/src/homeassistant/homeassistant/config_entries.py", line 1511, in async_init
    flow, result = await self._async_init(flow_id, handler, context, data)
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/config_entries.py", line 1574, in _async_init
    result = await self._async_handle_step(flow, flow.init_step, data)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/data_entry_flow.py", line 483, in _async_handle_step
    result: _FlowResultT = await getattr(flow, method)(user_input)
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/ramses_cc/config_flow.py", line 1045, in async_step_user
    return await self.async_step_choose_serial_port()
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/ramses_cc/config_flow.py", line 241, in async_step_choose_serial_port
    ports = await async_get_usb_ports(self.hass)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/ramses_cc/config_flow.py", line 107, in async_get_usb_ports
    return await hass.async_add_executor_job(get_usb_ports)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.14/concurrent/futures/thread.py", line 86, in run
    result = ctx.run(self.task)
  File "/usr/local/lib/python3.14/concurrent/futures/thread.py", line 73, in run
    return fn(*args, **kwargs)
  File "/config/custom_components/ramses_cc/config_flow.py", line 89, in get_usb_ports
    usb_device = usb.usb_device_from_port(port)
                 ^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: module 'homeassistant.components.usb' has no attribute 'usb_device_from_port'. Did you mean: 'usb_device_from_path'?

Heeft iemand een idee?

[ebroerse]

asaki schreef op zondag 10 mei 2026 @ 14:13:
Goed, na het opruimen van de cache werkte eigenlijk helemaal niets meer. Geen enkel device werd nog gevonden. Ik heb het een dagje laten draaien maar niets was bereikbaar. Ze bestonden nog wel als entiteiten maar alles was unavailable.

Heeft iemand een idee?

Kun je - met debug aan - je HA system log exporteren en in issue 666 plakken?

Om een oude versie te starten moet je terug naar 0.54.3. Vervang na installatie (voordat je herstart) het bestand init.py in de map custom_components/ramses_cc/. Zie https://github.com/ramses-rf/ramses_cc/issues/601. Het nieuwe init.py bestandje vind je in https://github.com/ramses-rf/ramses_cc/issues/583#issuecomment-4214431956

[ebroerse]

ebroerse schreef op zaterdag 9 mei 2026 @ 12:12:
Heb ik 1x gezien: issue https://github.com/ramses-rf/ramses_cc/issues/651

Je cache legen kan het oplossen

Let op: Alleen de systeemtoestand (2e schuifje) wissen, niet het ontdekte schema.

[asaki]

ebroerse schreef op maandag 11 mei 2026 @ 12:55:
[...]

Kun je - met debug aan - je HA system log exporteren en in issue 666 plakken?

Om een oude versie te starten moet je terug naar 0.54.3. Vervang na installatie (voordat je herstart) het bestand init.py in de map custom_components/ramses_cc/. Zie https://github.com/ramses-rf/ramses_cc/issues/601. Het nieuwe init.py bestandje vind je in https://github.com/ramses-rf/ramses_cc/issues/583#issuecomment-4214431956

Ik heb de logs geupdated bij het issue.

Als ik terug ga naar 0.54.3 en gebruik de init.py uit het andere issue, dan krijg ik na het herstarten deze error:

code:

2026-05-11 20:19:39.776 ERROR (MainThread) [homeassistant.config_entries] Error setting up entry RAMSES RF for ramses_cc
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/config_entries.py", line 787, in __async_setup_with_context
    result = await component.async_setup_entry(hass, self)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/ramses_cc/__init__.py", line 158, in async_setup_entry
    await coordinator.async_setup()
  File "/config/custom_components/ramses_cc/coordinator.py", line 239, in async_setup
    cached_packets = self._get_saved_packets(client_state)
  File "/config/custom_components/ramses_cc/coordinator.py", line 180, in _get_saved_packets
    and pkt[41:45] not in msg_code_filter
        ~~~^^^^^^^
KeyError: slice(41, 45, None)

[ebroerse]

asaki schreef op maandag 11 mei 2026 @ 20:21:
[...]


Ik heb de logs geupdated bij het issue.

Als ik terug ga naar 0.54.3 en gebruik de init.py uit het andere issue, dan krijg ik na het herstarten deze error:

Je moet ook hierbij wel je (nieuwe) systeemtoestand cache wissen (2e schuifje in prefs > cache beheren), omdat de packets anders zijn opgebouwd.

[Swazija]

Sinds een aantal dagen doet ramses_cc het niet meer helemaal lekker bij me. Ik zie dat mijn sensoren allemaal behoorlijk springen tussen verschillende waardes. Ik heb er zelf nog geen patroon in kunnen vinden. Hieronder een plaatje van wat ik bedoel. Ook de fan status wisselt regelmatig tussen een vorige waarde en de echt waarde die de WTW heeft. Cache legen lijkt het heel even te verbeteren maar het probleem komt vanzelf weer terug lijkt het. Gaat om een Orcon WTW. Zijn er meer mensen die hier last van hebben?

[ebroerse]

Swazija schreef op dinsdag 26 mei 2026 @ 22:57:
Sinds een aantal dagen doet ramses_cc het niet meer helemaal lekker bij me. Ik zie dat mijn sensoren allemaal behoorlijk springen tussen verschillende waardes. Ik heb er zelf nog geen patroon in kunnen vinden. Hieronder een plaatje van wat ik bedoel. Ook de fan status wisselt regelmatig tussen een vorige waarde en de echt waarde die de WTW heeft. Cache legen lijkt het heel even te verbeteren maar het probleem komt vanzelf weer terug lijkt het. Gaat om een Orcon WTW. Zijn er meer mensen die hier last van hebben?


[Afbeelding]

Ik heb dit bij mij thuis ook eens gezien, maar dat was een ontwikkelversie en was met 1 regel code verdwenen. Welke versie draai jij? Wat is er verder veranderd in je systeem? Heb je recent mss HA Core bijgewerkt?

[Swazija]

Ik draai Ramses 0.56.8 en HA is up to date met de laatste versie.

[Swazija]

Zou het kunnen zijn dat er in een nieuwe release 31D9 berichten vertaald worden? Ik weet dat die berichten voor Orcon WTWs van mijn type geen werkende informatie bevatten. Dat is ook waarom er in het verleden een scheme optie bestond waarin duidelijk werd dat die genegeerd konden worden. Ook paste dat aan welke waarde fan info kreeg bij een bepaald bericht.

[TijmenvS]

Swazija schreef op dinsdag 26 mei 2026 @ 22:57:
Sinds een aantal dagen doet ramses_cc het niet meer helemaal lekker bij me. Ik zie dat mijn sensoren allemaal behoorlijk springen tussen verschillende waardes. Ik heb er zelf nog geen patroon in kunnen vinden. Hieronder een plaatje van wat ik bedoel. Ook de fan status wisselt regelmatig tussen een vorige waarde en de echt waarde die de WTW heeft. Cache legen lijkt het heel even te verbeteren maar het probleem komt vanzelf weer terug lijkt het. Gaat om een Orcon WTW. Zijn er meer mensen die hier last van hebben?


[Afbeelding]

Ik heb ook een Orcon WTW, maar ik zie dit gedrag niet. Ik draai nog op de 0.56.2 versie en zit op Home Assistant Core 2026.5.3. Draait op 0.56.2 al een hele tijd heel stabiel.

[Swazija]

Ik zal ook mijn hardware eens nakijken of die niet aan het sterven is.

[Swazija]

Heb een power cycle gedaan van mijn HA systeem en het lijkt verholpen te zijn. Wellicht dus toch wat met de hardware. Sorry voor de verwarring.

[Swazija]

Ook de power cycle werkte niet langdurig. Wat ook wel vreemd was is dat er veranderingen in entiteiten waren terwijl er op die timestamps in de packet.log file niets te zien was. Ik heb nu ramses_cc eraf gegooid en opnieuw geinstalleerd.

[Swazija]

Heb toch het idee dat er in ramses_cc wat verkeerd gaat. Hieronder zie je mijn outdoor temperature zoals gelogd door ramses_cc

En hier zie je mijn packet_log file 31DA berichten waaruit deze waardes komen. Zoals te zien is kloppen de timestamps niet met de data punten die ramses_cc maakt. Op punten waarop ramses_cc pollt zijn er datapunten, maar op sommige punten er tussen lijkt er een vaste waarde te worden geselecteerd. Hier zou toch gewoon de waarde van het laatste 31DA bericht moeten staan?

2026-05-28T14:10:59.925674 091 I --- 32:155617 --:------ 32:155617 31DA 030 00EF007FFF2A18098809740955098CF80000182A2A0000EFEF091D090100

2026-05-28T14:12:55.242569 085 I --- 32:155617 --:------ 32:155617 31DA 030 00EF007FFF2A180988097409560995F80000182A2A0000EFEF0939093900

2026-05-28T14:15:44.065670 093 I --- 32:155617 --:------ 32:155617 31DA 030 00EF007FFF2A19098809740957099FF80000182A2A0000EFEF091D090100

2026-05-28T14:16:28.660821 091 I --- 32:155617 --:------ 32:155617 31DA 030 00EF007FFF2A190992097E095709A1F80000182A2A0000EFEF091D091D00

2026-05-28T14:18:04.752873 082 I --- 32:155617 --:------ 32:155617 31DA 030 00EF007FFF2A1809920974095809A1F80000182A2A0000EFEF091D091D00

2026-05-28T14:23:14.255853 093 I --- 32:155617 --:------ 32:155617 31DA 030 00EF007FFF2A1809A60974095A09B1F80000182A2A0000EFEF091D091D00

2026-05-28T14:25:12.394673 082 I --- 32:155617 --:------ 32:155617 31DA 030 00EF007FFF291909A60974095909ADF80000182A2A0000EFEF0939091D00

2026-05-28T14:26:29.054278 091 I --- 32:155617 --:------ 32:155617 31DA 030 00EF007FFF2A1A09A60974095B09B6F80000182A2A0000EFEF091D091D00[/CODE]

[ebroerse]

Swazija schreef op donderdag 28 mei 2026 @ 14:53:
Heb toch het idee dat er in ramses_cc wat verkeerd gaat.

Dit is precies wat ik destijds ook zag (ben nu niet thuis om HA 2026.5.4 te installeren en waardes checken).

WAARDE springt inderdaad terug naar een vaste waarde die de sensor bij herstart uit de oude packet logs heeft gelezen. Had vlgs. mij met de timeout te maken, waardoor een sensor ongeldig wordt. 31DA berichten komen maar af en toe, bij sommige hvac apparaten.

Hoor graag of anderen dit ook zien.

[ebroerse]

ebroerse schreef op donderdag 28 mei 2026 @ 22:11:
[...]

Dit is precies wat ik destijds ook zag (ben nu niet thuis om HA 2026.5.4 te installeren en waardes checken).

…

Hoor graag of anderen dit ook zien.

Heb thuis HA Core net bijgewerkt naar 2026.5.4, maar zie met een ClimaRad HRU niet geen terugspringend patroon, gewoon wat je (met warm weer) verwacht.

[Swazija]

Ik heb een andere cc1101 chip besteld en ga eens de overstap maken naar esp om te kijken of het daaraan zou kunnen liggen.

[Wimpie70]

@Swazija kan je zien of je esp zelf offline gaat ? check je tijdzone instellingen ? heb je de esp dicht bij de unit geplaatst ? Zie je warnings of errors in de logs die hiermee verband kunnen hebben ? zie je dezelfde berichten met bijvoorbeeld MQTT explorer ? Is er een probleem met de sensor zelf in de Orcon ? Zie je dit ook bij andere sensoren ?

[Swazija]

Wimpie70 schreef op maandag 1 juni 2026 @ 09:50:
@Swazija kan je zien of je esp zelf offline gaat ? check je tijdzone instellingen ? heb je de esp dicht bij de unit geplaatst ? Zie je warnings of errors in de logs die hiermee verband kunnen hebben ? zie je dezelfde berichten met bijvoorbeeld MQTT explorer ? Is er een probleem met de sensor zelf in de Orcon ? Zie je dit ook bij andere sensoren ?

Ik draai op een atmega die met een usb kabel verbonden zit. Heb nog niet in de logs zitten kijken of die verbinding wegvalt. Zodra de nieuwe hardware binnen is zal ik een update geven.

[ebroerse]

Swazija schreef op maandag 1 juni 2026 @ 09:53:
[...]

Ik draai op een atmega die met een usb kabel verbonden zit. Heb nog niet in de logs zitten kijken of die verbinding wegvalt. Zodra de nieuwe hardware binnen is zal ik een update geven.

Helaas zie ik na herinstallatie van 0.56.8 ook bij mijn 31DA-sensors hetzelfde terugspringende patroon als @Swazija. Ik had kennelijk een eigen patch toegevoegd, dus dat wordt even zoeken hoe we dit voorkomen.

Ligt dus niet aan je HRU zelf.

Edit: heb het teruggevonden, zie issue 653 Je kunt dit zoals daar staat met File Editor tijdelijk zelf aanpassen in custom_components/ramses_cc/coordinator.pymaar dat was in 0.56.7 al gecorrigeerd. Kennelijk op een andere plek toch een regressie. Ik heb het oude issue heropend.

Om het voor nU te patchen wijzig je coordinator.py line 296 in td(seconds=200)

in 0.56.8 kan je het Scan Interval in Config Flow > Gateway Config op 180 of hoger instellen, afhankelijk van het 31DA interval van de HRU.

[ Voor 34% gewijzigd door ebroerse op 03-06-2026 09:03 ]

[Swazija]

Goed om te horen dat ik toch niet helemaal gek ben De nieuwe hardware ga ik toch nog even installeren aangezien daar ook een betere antenne bij zit als het goed is. Ik heb het scan interval een keer op 200 gezet.

[ebroerse]

Ramses RF 0.57.0 is uit. Nog geen “echte” release omdat evohome systemen niet volledig gevuld worden. Voor hvac raad ik het wel aan, zeker als je nu op 0.56.x zit.

[Swazija]

Ik heb gisterochtend mijn arduino+cc1101 vervangen door ramses_esp op een esp32 S3 met een betere antenne en een andere cc1101 (zelfde als vliegnerd gebruikt in zijn bordjes). Het bereik is beter lijkt het, maar mijn probleem blijft bestaan. Waardes van sensoren (CO2 sensors, fan waardes enz) blijven terugspringen naar ergens opgeslagen waardes. Ik heb scan interval op 300 gezet, helpt ook niet...

[ebroerse]

Swazija schreef op maandag 15 juni 2026 @ 13:23:
Ik heb gisterochtend mijn arduino+cc1101 vervangen door ramses_esp op een esp32 S3 met een betere antenne en een andere cc1101 (zelfde als vliegnerd gebruikt in zijn bordjes). Het bereik is beter lijkt het, maar mijn probleem blijft bestaan. Waardes van sensoren (CO2 sensors, fan waardes enz) blijven terugspringen naar ergens opgeslagen waardes. Ik heb scan interval op 300 gezet, helpt ook niet...

Hoe vaak worden die (verschillende?) Codes verstuurd? Even grep of ramses_extras als filter gebruiken.

Mss moeten we de heartbeat aanpassen. Ik moest ook hem ook al naar 200 sec. zetten in 0.57.0; kreeg bij 180s zelfde effect.

[Swazija]

ebroerse schreef op maandag 15 juni 2026 @ 18:27:
[...]

Hoe vaak worden die (verschillende?) Codes verstuurd? Even grep of ramses_extras als filter gebruiken.

Mss moeten we de heartbeat aanpassen. Ik moest ook hem ook al naar 200 sec. zetten in 0.57.0; kreeg bij 180s zelfde effect.

Ik kan wel een packet.log file met je delen?

[ebroerse]

Swazija schreef op dinsdag 16 juni 2026 @ 09:42:
[...]

Ik kan wel een packet.log file met je delen?

Zet je 24h log ajb als attachment (met .txt extensie) in ramses_cc issue 653.

[Swazija]

ebroerse schreef op dinsdag 16 juni 2026 @ 15:07:
[...]

Zet je 24h log ajb als attachment (met .txt extensie) in ramses_cc issue 653.

Zal ik binnenkort even doen, nog niet aan toegekomen. Wat ik wel heb gedaan is een automation gemaakt die iedere minuut een 31DA request uitvoert en die heeft mijn probleem laten verdwijnen. Heeft dus inderdaad te maken met de hoeveelheid datapunten die binnenkomen. Wat wel interessant is is dat het ook werkt voor de CO2 meters die ik heb die helemaal niet gekoppeld zitten aan een 31DA request naar mijn fans.

edit:
Ik typ dit bericht en ik zie net wat later dat mijn CO2 sensoren deze ochtend weer problemen hebben. De 31DA request lost dat dus niet op...

[ Voor 10% gewijzigd door Swazija op 17-06-2026 10:16 ]

[Swazija]

Zojuist een packet log toegevoegd aan het github issue