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.