Het grote Orcon HRC / WtW topic

[ebroerse]

Bra-Jo schreef op zaterdag 27 september 2025 @ 11:15:
[...]

Fake remote pairen had ik ff gemist. Dacht dat dat niet nodig was als je dezelfde codes gebruikt als van de RF15?

Als je de “echte” al gepaird hebt, dan hoeft dat geen 2e keer. Maar als je alleen een fake aanmaakt, dan moet er nog wel iets worden uitgewisseld (pairen). Was me nog niet helder uit je beschrijving.
Maar gun iedereen om zonder een €€ remote, die met een fris batterijtje in de kast niks ligt te doen, het huis fris te houden.

[vervlogen]

TijmenvS schreef op vrijdag 22 augustus 2025 @ 10:31:
Ik heb een Orcon HRC300 EcoMax uit 2019 die via een Indalo tech module kan worden aangestuurd met de ramses_cc integratie in Home Assistant. De fan speeds werken prima, heb er automations mee gemaakt zodat de Orcon al bij een CO2 van 800 hoger gaat.

Alleen ik krijg de bypass aansturing niet aan de praat. Ik heb in de known device id's de op het forum hier bekende codes toegevoegd, de code wordt verstuurd, maar lijkt verder genegeerd te worden door de Orcon unit. Ik heb nog opnieuw gebind met de 22F7 code, maar ook dan krijg ik hetzelfde resultaat. Heeft iemand hier enig idee waarom het niet werkt?

He Tijmen,

Ik heb toch de bypass aan de praat gekregen (in mijn Ecomax van 2019) na posts hier in dit forum.

code:

bypass_auto: " W --- 37:xxxxxx 32:xxxxxx --:------ 2411 023 00004B0000000000000000000000000002000000010000"
    bypass_close: " W --- 37:xxxxxx 32:xxxxxx --:------ 2411 023 00004B0000000000020000000000000002000000010000"
    bypass_open: " W --- 37:xxxxxx 32:xxxxxx --:------ 2411 023 00004B0000000000010000000000000002000000010000"

Kan de bypass nu goed aansturen, en krijg ook de positie te zien in mijn WTW device.

[Wimpie70]

@vervlogen Dank je. Ik heb een PR gemaakt voor deze 2411 parameter. Zie: https://github.com/ramses-rf/ramses_rf/pull/293

[Bra-Jo]

Ik ben ondertussen ook weer wat verder, dankzij de hulp hier. Ben nu zover dat de commando's die ik bij de fake remote heb gezet, geaccepteerd worden wanneer ik ze handmatig verzend vanuit de developer tools. Dus ik kan de unit nu bedienen, in ieder geval.
Maar de grafische weergave en bediening willen nog niet... ik krijg nog steeds fouten wanneer ik een instelling op de WTW wil aanpassen, unknown error. Die commando's zie ik ook niet terug in de packet log. Ook zijn diverse sensoren niet actief/onbekend. Iemand nog een idee hoe ik dit kan troubleshooten?

[Wimpie70]

Kijk eens naar de home-assistant.log. Je kan in in HA ook 'enable debug logging' aanzetten voor ramses RF (3 puntjes rechtsboven)

[Bra-Jo]

@Wimpie70 Tnx voor de tip. Vrees alleen dat ik daar helemaal geen chocola van kan maken...

code:

2025-10-05 16:48:00.109 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection] [139968408719008] Unexpected exception
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 264, in handle_call_service
    response = await hass.services.async_call(
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    ...<7 lines>...
    )
    ^
  File "/usr/src/homeassistant/homeassistant/core.py", line 2835, in async_call
    response_data = await coro
                    ^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/core.py", line 2878, in _execute_service
    return await target(service_call)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 850, 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 922, in _handle_entity_call
    result = await task
             ^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 1682, in async_turn_off
    await self.hass.async_add_executor_job(ft.partial(self.turn_off, **kwargs))
  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/helpers/entity.py", line 1678, in turn_off
    raise NotImplementedError
NotImplementedError

Ik heb Turn off aangeklikt op de RF15, dat zie ik terug in de debug log als "self.turn_off,". Ik snap dat er iets mis gaat bij de actie, ik zie "NotImplemented" maar waarom dat niet implemented is en hoe ik het moet herstellen...

[Wimpie70]

@Bra-Jo Ah, ik zie nu wat je probeerde te doen. Ik kan het ook reproduceren. Maar wat is het nut om een REM aan of uit te kunnen zetten ?

The error occurs because the async_turn_on and _off are not implemented...To avoid the error we could add an empty method that logs 'on' or 'off'...

Maar misschien maak ik er morgen nog wel even een PR voor.

Kijk even naar de begin post. Daar staan een aantal commando's en hoe je deze kan gebruiken.

[ebroerse]

Bra-Jo schreef op zondag 5 oktober 2025 @ 16:56:

"NotImplemented" maar waarom dat niet implemented is en hoe ik het moet herstellen...

Ter geruststelling: dat knopje is bij ons allemaal ‘not implemented’ voor HVAC (ventilatie). Staat op de To Do lijst, zonder deadline gelukkig 😜
Voor evohome/verwarming werkt het wel, met binnenkort nog wat correcties.

[Wimpie70]

te laat
PR met 2 lege (logger) methods...

[Xilvaro]

Dag allen, misschien een domme vraag, maar ik heb een HRC300 WTW die sinds gisteren 1 van de ventilatoren op 100% heeft zuigen, althans, het klinkt als 150% om eerlijk te zijn.

Als ik de stekker eruit haal en er weer in doe gaat hij zijn opstartprocedure af, even optoeren en weer stoppen, bij de 2e keer "optoeren" gaat (volgens mij) de afzuigventilator op 150% draaien en blijft dat doen.

De afzuigventielen in huis klinken als een vliegtuig. Met de CO2 afstandsbediening het toestel handmatig op 1,2,3,auto of het huisje zetten helpt niets.

Iemand enig idee voor ik de monteur moet gaan bellen? Kan ik ergens nog wat resetten ofzo?

[Vaevictis_]

Xilvaro schreef op zondag 5 oktober 2025 @ 20:48:
Dag allen, misschien een domme vraag, maar ik heb een HRC300 WTW die sinds gisteren 1 van de ventilatoren op 100% heeft zuigen, althans, het klinkt als 150% om eerlijk te zijn.

Als ik de stekker eruit haal en er weer in doe gaat hij zijn opstartprocedure af, even optoeren en weer stoppen, bij de 2e keer "optoeren" gaat (volgens mij) de afzuigventilator op 150% draaien en blijft dat doen.

De afzuigventielen in huis klinken als een vliegtuig. Met de CO2 afstandsbediening het toestel handmatig op 1,2,3,auto of het huisje zetten helpt niets.

Iemand enig idee voor ik de monteur moet gaan bellen? Kan ik ergens nog wat resetten ofzo?

Ja er zit een reset knop op de printplaat, maar ik denk dat 1 ventilator defect is.

[Wimpie70]

Ik zal hem hier maar even reposten:

Ramses RF 0.51.8 is uit, met dank voor jullie bijdragen.
De ramses_cc custom integratie vereist HA Core 2025.10.0 of later. Meer in de release notes.

[Bra-Jo]

Wimpie70 schreef op zondag 5 oktober 2025 @ 18:55:
@Bra-Jo Ah, ik zie nu wat je probeerde te doen. Ik kan het ook reproduceren. Maar wat is het nut om een REM aan of uit te kunnen zetten ?

The error occurs because the async_turn_on and _off are not implemented...To avoid the error we could add an empty method that logs 'on' or 'off'...

Maar misschien maak ik er morgen nog wel even een PR voor.

Kijk even naar de begin post. Daar staan een aantal commando's en hoe je deze kan gebruiken.

Het ging me niet perse om die handeling, was gewoon een willekeurige knop om te testen.

Ik zou verwachten dat ik bv wel de fan-snelheid vanuit de gui zou kunnen aanpassen, zie 1e screenshot uit mijn vorige post. Daar kan ik wel bv Fan Mode kiezen, en kiezen voor hoog/laag/enz, maar dan komt ook dezelfde fout in beeld.

Maar goed, als dat bij niemand werkt, dan ga ik me er niet moe mee maken, dan houd ik het voorlopig wel bij directe commando's zoals beschreven in de startpost. Tnx in ieder geval!

[Wimpie70]

Er zijn een aantal voorbeelden van scripts, cards en automations (van mij staat er ook nog wat tussen). Kijk in dit forum, maar ook bijvoorbeeld in de wiki van Ramses RF (even uitvouwen). Ik weet niet hoe up-to-date deze zijn.

[vervlogen]

Xilvaro schreef op zondag 5 oktober 2025 @ 20:48:
Dag allen, misschien een domme vraag, maar ik heb een HRC300 WTW die sinds gisteren 1 van de ventilatoren op 100% heeft zuigen, althans, het klinkt als 150% om eerlijk te zijn.

Als ik de stekker eruit haal en er weer in doe gaat hij zijn opstartprocedure af, even optoeren en weer stoppen, bij de 2e keer "optoeren" gaat (volgens mij) de afzuigventilator op 150% draaien en blijft dat doen.

De afzuigventielen in huis klinken als een vliegtuig. Met de CO2 afstandsbediening het toestel handmatig op 1,2,3,auto of het huisje zetten helpt niets.

Iemand enig idee voor ik de monteur moet gaan bellen? Kan ik ergens nog wat resetten ofzo?

Ik heb precies hetzelfde probleem gehad. Het was idd een van de sensoren op de fan die defect was. Helaas heb ik nergens de sensor los kunnen vinden (en Orcon gaf ook aan dat die niet los verkrijgbaar was), dus heb uiteindelijk een nieuwe geen gekocht.

Laat de fan niet te lang op hoog vermogen draaien, ik had een hele bak water onderin de WTW liggen, bijna kortsluiting in de fan.

[Turrican]

vervlogen schreef op maandag 6 oktober 2025 @ 23:10:
Laat de fan niet te lang op hoog vermogen draaien, ik had een hele bak water onderin de WTW liggen, bijna kortsluiting in de fan.

Hm, als het goed is zit er een afvoer onderin de WTW-unit, dus als het water erin blijft staan is er denk ik iets verstopt, dat hoort namelijk niet te gebeuren.

[TijmenvS]

Sinds vanavond weer een probleem met ramses_cc. Ik krijg geen info meer binnen uit de Orcon HRC 300. Alles is niet beschikbaar. Alleen dit keer werkt de CO2 remote als enige nog wel. En ik kan ook de standen aansturen met mijn fake remote.

Als ik de packetlog bekijk zie ik geen RP berichten meer. En ik krijg onderstaande foutmelding. Volgens ChatGPT heeft dat met elkaar te maken. Heeft iemand een idee wat er aan de hand kan zijn?

code:

Logger: homeassistant.util.loop
Bron: util/loop.py:137
Eerst voorgekomen: 20:56:43 (5 gebeurtenissen)
Laatst gelogd: 20:56:43

Detected blocking call to glob with args ('/dev/ttyACM*',) inside the event loop by custom integration 'ramses_cc' at custom_components/ramses_cc/broker.py, line 166: await self.client.start(cached_packets=chpkt) (offender: /usr/local/lib/python3.13/site-packages/ramses_tx/transport.py, line 166: devices.update(glob.glob(items[1] + "*"))), please create a bug report at https://github.com/ramses-rf/ramses_cc/issues For developers, please see https://developers.home-assistant.io/docs/asyncio_blocking_operations/#glob Traceback (most recent call last): File "<frozen runpy>", line 198, in _run_module_as_main File "<frozen runpy>", line 88, in _run_code File "/usr/src/homeassistant/homeassistant/__main__.py", line 229, in <module> sys.exit(main()) File "/usr/src/homeassistant/homeassistant/__main__.py", line 215, in main exit_code = runner.run(runtime_conf) File "/usr/src/homeassistant/homeassistant/runner.py", line 271, in run return loop.run_until_complete(setup_and_run_hass(runtime_config)) File "/usr/local/lib/python3.13/asyncio/base_events.py", line 712, in run_until_complete self.run_forever() File "/usr/local/lib/python3.13/asyncio/base_events.py", line 683, in run_forever self._run_once() File "/usr/local/lib/python3.13/asyncio/base_events.py", line 2050, in _run_once handle._run() File "/usr/local/lib/python3.13/asyncio/events.py", line 89, in _run self._context.run(self._callback, *self._args) File "/usr/src/homeassistant/homeassistant/config_entries.py", line 906, in async_setup_locked await self.async_setup(hass, integration=integration) File "/usr/src/homeassistant/homeassistant/config_entries.py", line 672, in async_setup await self.__async_setup_with_context(hass, integration) File "/usr/src/homeassistant/homeassistant/config_entries.py", line 761, in __async_setup_with_context result = await component.async_setup_entry(hass, self) File "/config/custom_components/ramses_cc/__init__.py", line 141, in async_setup_entry await broker.async_setup() File "/config/custom_components/ramses_cc/broker.py", line 166, in async_setup await self.client.start(cached_packets=chpkt)
Detected blocking call to iglob with args ('/dev/ttyACM*',) inside the event loop by custom integration 'ramses_cc' at custom_components/ramses_cc/broker.py, line 166: await self.client.start(cached_packets=chpkt) (offender: /usr/local/lib/python3.13/glob.py, line 31: return list(iglob(pathname, root_dir=root_dir, dir_fd=dir_fd, recursive=recursive,), please create a bug report at https://github.com/ramses-rf/ramses_cc/issues For developers, please see https://developers.home-assistant.io/docs/asyncio_blocking_operations/#iglob Traceback (most recent call last): File "<frozen runpy>", line 198, in _run_module_as_main File "<frozen runpy>", line 88, in _run_code File "/usr/src/homeassistant/homeassistant/__main__.py", line 229, in <module> sys.exit(main()) File "/usr/src/homeassistant/homeassistant/__main__.py", line 215, in main exit_code = runner.run(runtime_conf) File "/usr/src/homeassistant/homeassistant/runner.py", line 271, in run return loop.run_until_complete(setup_and_run_hass(runtime_config)) File "/usr/local/lib/python3.13/asyncio/base_events.py", line 712, in run_until_complete self.run_forever() File "/usr/local/lib/python3.13/asyncio/base_events.py", line 683, in run_forever self._run_once() File "/usr/local/lib/python3.13/asyncio/base_events.py", line 2050, in _run_once handle._run() File "/usr/local/lib/python3.13/asyncio/events.py", line 89, in _run self._context.run(self._callback, *self._args) File "/usr/src/homeassistant/homeassistant/config_entries.py", line 906, in async_setup_locked await self.async_setup(hass, integration=integration) File "/usr/src/homeassistant/homeassistant/config_entries.py", line 672, in async_setup await self.__async_setup_with_context(hass, integration) File "/usr/src/homeassistant/homeassistant/config_entries.py", line 761, in __async_setup_with_context result = await component.async_setup_entry(hass, self) File "/config/custom_components/ramses_cc/__init__.py", line 141, in async_setup_entry await broker.async_setup() File "/config/custom_components/ramses_cc/broker.py", line 166, in async_setup await self.client.start(cached_packets=chpkt)
Detected blocking call to scandir with args ('/dev',) inside the event loop by custom integration 'ramses_cc' at custom_components/ramses_cc/broker.py, line 166: await self.client.start(cached_packets=chpkt) (offender: /usr/local/lib/python3.13/glob.py, line 170: with os.scandir(arg) as it:), please create a bug report at https://github.com/ramses-rf/ramses_cc/issues For developers, please see https://developers.home-assistant.io/docs/asyncio_blocking_operations/#scandir Traceback (most recent call last): File "<frozen runpy>", line 198, in _run_module_as_main File "<frozen runpy>", line 88, in _run_code File "/usr/src/homeassistant/homeassistant/__main__.py", line 229, in <module> sys.exit(main()) File "/usr/src/homeassistant/homeassistant/__main__.py", line 215, in main exit_code = runner.run(runtime_conf) File "/usr/src/homeassistant/homeassistant/runner.py", line 271, in run return loop.run_until_complete(setup_and_run_hass(runtime_config)) File "/usr/local/lib/python3.13/asyncio/base_events.py", line 712, in run_until_complete self.run_forever() File "/usr/local/lib/python3.13/asyncio/base_events.py", line 683, in run_forever self._run_once() File "/usr/local/lib/python3.13/asyncio/base_events.py", line 2050, in _run_once handle._run() File "/usr/local/lib/python3.13/asyncio/events.py", line 89, in _run self._context.run(self._callback, *self._args) File "/usr/src/homeassistant/homeassistant/config_entries.py", line 906, in async_setup_locked await self.async_setup(hass, integration=integration) File "/usr/src/homeassistant/homeassistant/config_entries.py", line 672, in async_setup await self.__async_setup_with_context(hass, integration) File "/usr/src/homeassistant/homeassistant/config_entries.py", line 761, in __async_setup_with_context result = await component.async_setup_entry(hass, self) File "/config/custom_components/ramses_cc/__init__.py", line 141, in async_setup_entry await broker.async_setup() File "/config/custom_components/ramses_cc/broker.py", line 166, in async_setup await self.client.start(cached_packets=chpkt)
Detected blocking call to glob with args ('/dev/*',) inside the event loop by custom integration 'ramses_cc' at custom_components/ramses_cc/broker.py, line 166: await self.client.start(cached_packets=chpkt) (offender: /usr/local/lib/python3.13/site-packages/ramses_tx/transport.py, line 147: for device in glob.glob("/dev/*") + glob.glob("/dev/serial/by-id/*"):), please create a bug report at https://github.com/ramses-rf/ramses_cc/issues For developers, please see https://developers.home-assistant.io/docs/asyncio_blocking_operations/#glob Traceback (most recent call last): File "<frozen runpy>", line 198, in _run_module_as_main File "<frozen runpy>", line 88, in _run_code File "/usr/src/homeassistant/homeassistant/__main__.py", line 229, in <module> sys.exit(main()) File "/usr/src/homeassistant/homeassistant/__main__.py", line 215, in main exit_code = runner.run(runtime_conf) File "/usr/src/homeassistant/homeassistant/runner.py", line 271, in run return loop.run_until_complete(setup_and_run_hass(runtime_config)) File "/usr/local/lib/python3.13/asyncio/base_events.py", line 712, in run_until_complete self.run_forever() File "/usr/local/lib/python3.13/asyncio/base_events.py", line 683, in run_forever self._run_once() File "/usr/local/lib/python3.13/asyncio/base_events.py", line 2050, in _run_once handle._run() File "/usr/local/lib/python3.13/asyncio/events.py", line 89, in _run self._context.run(self._callback, *self._args) File "/usr/src/homeassistant/homeassistant/config_entries.py", line 906, in async_setup_locked await self.async_setup(hass, integration=integration) File "/usr/src/homeassistant/homeassistant/config_entries.py", line 672, in async_setup await self.__async_setup_with_context(hass, integration) File "/usr/src/homeassistant/homeassistant/config_entries.py", line 761, in __async_setup_with_context result = await component.async_setup_entry(hass, self) File "/config/custom_components/ramses_cc/__init__.py", line 141, in async_setup_entry await broker.async_setup() File "/config/custom_components/ramses_cc/broker.py", line 166, in async_setup await self.client.start(cached_packets=chpkt)
Detected blocking call to open with args ('/sys/devices/platform/fd840000.usb/usb5/5-1/bNumInterfaces',) inside the event loop by custom integration 'ramses_cc' at custom_components/ramses_cc/broker.py, line 166: await self.client.start(cached_packets=chpkt) (offender: /usr/local/lib/python3.13/site-packages/serial/tools/list_ports_linux.py, line 84: with open(os.path.join(*args)) as f:), please create a bug report at https://github.com/ramses-rf/ramses_cc/issues For developers, please see https://developers.home-assistant.io/docs/asyncio_blocking_operations/#open Traceback (most recent call last): File "<frozen runpy>", line 198, in _run_module_as_main File "<frozen runpy>", line 88, in _run_code File "/usr/src/homeassistant/homeassistant/__main__.py", line 229, in <module> sys.exit(main()) File "/usr/src/homeassistant/homeassistant/__main__.py", line 215, in main exit_code = runner.run(runtime_conf) File "/usr/src/homeassistant/homeassistant/runner.py", line 271, in run return loop.run_until_complete(setup_and_run_hass(runtime_config)) File "/usr/local/lib/python3.13/asyncio/base_events.py", line 712, in run_until_complete self.run_forever() File "/usr/local/lib/python3.13/asyncio/base_events.py", line 683, in run_forever self._run_once() File "/usr/local/lib/python3.13/asyncio/base_events.py", line 2050, in _run_once handle._run() File "/usr/local/lib/python3.13/asyncio/events.py", line 89, in _run self._context.run(self._callback, *self._args) File "/usr/src/homeassistant/homeassistant/config_entries.py", line 906, in async_setup_locked await self.async_setup(hass, integration=integration) File "/usr/src/homeassistant/homeassistant/config_entries.py", line 672, in async_setup await self.__async_setup_with_context(hass, integration) File "/usr/src/homeassistant/homeassistant/config_entries.py", line 761, in __async_setup_with_context result = await component.async_setup_entry(hass, self) File "/config/custom_components/ramses_cc/__init__.py", line 141, in async_setup_entry await broker.async_setup() File "/config/custom_components/ramses_cc/broker.py", line 166, in async_setup await self.client.start(cached_packets=chpkt)

[ebroerse]

TijmenvS schreef op donderdag 9 oktober 2025 @ 22:35:
… En ik krijg onderstaande foutmelding. …

Is zelfde als ramses_cc issue 296. Verschil met jouw post van 23/9?
Wat zijn je Ramses RF instellingen voor Packet Log? Was er een HA herstart rond deze tijd? Kan je de dongle/HA herstarten? Dongle zit aan USB, zo te zien.

Heb je nog andere apparaten in Ramses, en geven die wel info? Als de CO2 REM een “echte” is dan werkt dat gelukkig gewoon, al crasht Ramses RF.

[ Voor 17% gewijzigd door ebroerse op 10-10-2025 09:49 ]

[TijmenvS]

@ebroerse Het verschil is dat nu de Orcon HRC300 geen data geeft, en de CO2 remote wel, terwijl het eerder andersom was. Dit heb ik ook nog niet eerder meegemaakt.

Ik zag in de data geen verandering van status als ik de stand van de ventilatie aanpaste. De unit veranderde de stand wel, maar ik zag bijvoorbeeld niet dat de fan speed omhoog ging. Dat gebeurt sinds de laatste update wel vaker, dan helpt herladen van de integratie. Dat heb ik gisteren dus ook gedaan en daarna stond alles oo niet beschikbaar. Herstarten van home assistant hielp daar niet tegen. De automatisering voor verhogen van de fan speed werkte ook nog want co2 waarde werkte nog en aansturing ook. Vanochtend was de missende info ineens vanzelf weer terug trouwens (met een gat in de data tussen gisteravond en vanochtend).

Qua apparaten heb ik de indalo tech module, de Orcon HRC300, een co2 remote en een fake remote. Dus alleen de Orcon en de co2 remote geven data. Dongle zit inderdaad direct in de usb poort van de home assistant green.

[Paprika]

Zonder hulp was ik hier waarschijnlijk dagen mee bezig geweest, maar met wat hulp van ChatGPT en een paar Tweakers-posts als input werkte alles eigenlijk direct. In de logs duiken naast mijn eigen WTW nog drie andere exemplaren op. Gezien mijn woning een rijtjeshuis is en ik aan één kant eenzelfde soort buren heb en aan de andere kant een beneden- en bovenwoning, is dat ook niet zo vreemd, maar ergens wel een grappig idee dat die data gewoon rond zweeft.

[ Voor 3% gewijzigd door Paprika op 10-10-2025 15:45 ]

[ebroerse]

Paprika schreef op vrijdag 10 oktober 2025 @ 15:43:
… ergens wel een grappig idee dat die data gewoon rond zweeft.

Vond ik ook bijzonder om te ontdekken, vooral dat de installateur/fabrikant dat niet meldt bij aankoop, en dat je het niet uit kan zetten.

[ebroerse]

TijmenvS schreef op vrijdag 10 oktober 2025 @ 13:21:
... Vanochtend was de missende info ineens vanzelf weer terug trouwens (met een gat in de data tussen gisteravond en vanochtend)…

@TijmenvS Is de ontvangst (1e 3 cijfertjes in message payload) wel goed? Had je de dongel al eens verplaatst? Was bij mij thuis reden om de dongel in een stopcontact in de buurt van één fan te prikken en dan via MQTT in HA te krijgen. Vooral het signaal van de Vasco D60 fan is te zwak (metalen voorkant al vervangen door hardboard, maar zelfs dan).

[ Voor 9% gewijzigd door ebroerse op 11-10-2025 12:23 ]

[TijmenvS]

@ebroerse De ontvangst zit meestal tussen 50 en 60. Heel af en toe zitten er bepaalde packets tussen rond de 80. De dongel staat op ongeveer 2-2,5 meter van de ventilatie unit. De ventilatie unit hangt boven de deur buiten de kamer waar de dongel (en dus de home assistant green) staat. De enige plek dichterbij is het stopcontact van de Orcon zelf, die zou ik dan moeten aanpassen naar een dubbel stopcontact.

[ebroerse]

Net uitgekomen: Ramses RF 0.51.9

Nieuwe optie gemaakt door @Wimpie70 : _Fan parameters_ via 2411 messages.
De instellingen verschijnen op een Configuratie paneel onder de Ramses RF integratie als je fan ze ondersteunt. Je kunt instellingen aanpassen met 3 nieuwe Fan actions.


Check de release notes voor details.

Noot: ramses_cc custom integratie 0.51.8 en later vereisen HA 2025.10.0 of nieuwer.

[Wimpie70]

Meer info over 2411 support in de doc. De action calls staan ergens onderaan.
Even voor de duidelijkheid: dit zijn configuratie instellingen voor je FAN, voorzichtig hiermee. Het lijkt me niet handig om de aanvoer op 10% en de afvoer op 100% te zetten...
Ik heb het zelf getest op een Orcon fan. Het heeft vergelijkbare mogelijkheden als een RF15 display.
Op dit moment worden 15 parameters ondersteund, maar er zijn er meer (info graag delen). Zo kun je nu o.a. de comfort temperatuur instellen en percentages voor low, mid en high.

Om waardes te kunnen veranderen heb je een 'bound' REM nodig. Dit is een extra optie die je in je configuratie plaatst bij je fan. Deze REM kun je zelf aanmaken als 'faked', die je natuurlijk nog wel even moet binden op de gebruikelijke manier.

code:

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

Veel plezier ermee, ben benieuwd hoe jullie het kunnen gebruiken

[Turrican]

Wel een beetje vreemd om de relatie tussen fan en remote zo te moeten opgeven, daar heb je toch het schema voor (dat bestaat al)?

Zoiets dus:

code:

"32:153289":
  remotes:
    - "37:168270"

Als je dit invoert logt de integratie nu een warning: "The config schema is not minimal (consider minimising it)".

Lijkt me netter om dit werkend te maken dan om dit in de `known_list` te prutsen.

[ Voor 11% gewijzigd door Turrican op 13-10-2025 11:07 ]

[Wimpie70]

Er is geen 'remotes' trait in config_flow. De code in broker.py lijkt vooral bedoeld voor het bewaren van gevonden commando's.
Wat als je meerdere FAN's hebt, met meerder remotes die niet met alle fan's praten ? Dan wil je een dedicated REM hebben die deze 2411 commando's mag sturen.
Een FAN reageerd voor het veranderen van config waarden alleen op een bound REM. Dit is de eenvoudigste manier om dit aan te geven.
En duidelijk, Dit is de REM die je in automations en scripts kan gebruiken.

Remotes onder een fan hangen in de config kan ook, Maar geeft weer andere problemen.

Ik ben nog bezig om een .js card te maken waarbij je alleen de device van een Orcon fan hoeft te kiezen. De bound REM wordt erbij gezocht en je hoeft geen commando's meer in te vullen. WIP

[Sjoerd_W]

Hoi allemaal,

Na het doorlezen van allerlei WTW topics op Tweakers zie ik door de bomen het bos niet meer. De Orcon units lijken mij top vanwege de prijs en sensoren waar hij standaard mee geleverd wordt. Daarnaast zie ik dat mensen klagen over de voorverwarmer die Orcon gebruikt, aangezien deze een aan/uit variant is en dus als het koud is veel stroom verbruikt.

Ik vroeg me af of jullie een Orcon HRCx00 (ecocomfort of maxcomfort) zouden aanbevelen aangezien jullie hem al een tijdje hebben hangen.

Alvast bedankt!

[Turrican]

Wimpie70 schreef op maandag 13 oktober 2025 @ 11:41:
Er is geen 'remotes' trait in config_flow. De code in broker.py lijkt vooral bedoeld voor het bewaren van gevonden commando's.

Ik weet niet wat dit met config_flow te maken heeft. Dit is gewoon het schema dat al bestaat voor fans. Het doet alleen in de praktijk niets.

Je kunt dit invoeren bij "Systeemschema en erkende apparaten", en dan bij "Systeemschema('s)".

Wat als je meerdere FAN's hebt, met meerder remotes die niet met alle fan's praten ? Dan wil je een dedicated REM hebben die deze 2411 commando's mag sturen.

Meerdere fans met meerdere remotes? Dat kan hoor, met dit schema bijvoorbeeld:

YAML:

"32:153289":
  remotes:
    - "37:168270"

"32:123456":
  remotes:
    - "37:123456"

Een FAN reageerd voor het veranderen van config waarden alleen op een bound REM. Dit is de eenvoudigste manier om dit aan te geven.

Het matched niet echt met hoe het voor de verwarmingsspullen (actuators, sensors) is opgezet.

En duidelijk, Dit is de REM die je in automations en scripts kan gebruiken.

Zou niet uit moeten maken, elke bound & faked remote zal werken.

Remotes onder een fan hangen in de config kan ook, Maar geeft weer andere problemen.

Wat dan? Dat is wel veel meer hoe het werkt voor het Evohome-spul.

[TijmenvS]

Ik heb de integratie geüpdatet, maar ik zie helaas de extra mogelijkheden met het 2411 commando niet. Zouden die vanzelf tevoorschijn moeten komen als de
FAN ondersteund wordt of is er nog een actie nodig?

[Wimpie70]

@TijmenvS Je hebt een Orcon WTW toch ? Na de upgrade moet je HA herstarten. Het kan een paar minuten duren voordat de entities gemaakt worden.
Bij opstarten stuurt hij een detectie berichtje met param 3F naar de ventilator. Als de FAN reageerd, dan worden de andere bekende parameters opgehaald en entities gemaakt.
Als dit toch niet gebeurt, kan je proberen om een action uit te voeren: update_fan_params voor alle bekende Orcon parameters of get_fan_param voor een specifieke.
Success !

[ebroerse]

TijmenvS schreef op maandag 13 oktober 2025 @ 20:12:
Zouden die vanzelf tevoorschijn moeten komen als de FAN ondersteund wordt of is er nog een actie nodig?

Hier - een ander merk - kwam de optie bij mijn HRU vanzelf in HA, maar bij de badkamerafzuigfan nooit. Mss is ook bij eenvoudiger Orcon fans 2411 config niet ondersteund.

[Wimpie70]

Ik heb 3F (low mode supply rate) gekozen voor automatische detectie, maar misschien is een andere wel beter...Laten we zien wat er terugkomt aan feedback.

Als mensen voor 2411 waardes krijgen die anders zijn voor een ander merk dan voor de Orcon of een andere assertion error, graag melden op https://github.com/ramses-rf/ramses_cc/issues/317 met zoveel mogelijk relevante info.
We kunnen alleen decoderen en Ramses RF uitbreiden met genoeg feedback.
Voor andere onbekende codes kan je natuurlijk ook een issue of PR aanmaken.

[vervlogen]

Turrican schreef op woensdag 8 oktober 2025 @ 12:26:
[...]


Hm, als het goed is zit er een afvoer onderin de WTW-unit, dus als het water erin blijft staan is er denk ik iets verstopt, dat hoort namelijk niet te gebeuren.

De afvoer zit maar op een kant van de unit aangesloten...

[Turrican]

vervlogen schreef op dinsdag 14 oktober 2025 @ 14:09:
[...]

De afvoer zit maar op een kant van de unit aangesloten...

Ja, bij de aanvoer van buiten neem ik aan.
In mijn vorige huis met een niet-WTW woonhuisventilator had ik ook geen condensafvoer.

[TijmenvS]

@Wimpie70 Ja ik heb een Orcon HRC300 EcoMax, uit 2019. Na herstarten home assistant is er niets verschenen, en ook met de actie update_fan_params komt het niet tevoorschijn. Ik zie wel onderstaande in de packetlog. Er komt dus wel iets terug over de parameters, maar niet in de integratie zo lijkt het.

code:

2025-10-16T19:27:06.099917 000 RQ --- 37:123789 32:161442 --:------ 2411 003 000031
2025-10-16T19:27:06.129196 055 RP --- 32:161442 37:123789 --:------ 2411 022 0000312610000000B400000000000007080000001E70
2025-10-16T19:27:06.337920 000  I --- 18:183788 63:262142 --:------ 7FFF 023 00110199EE0FA34132343131525133323A313631343432
2025-10-16T19:27:06.400867 000 RQ --- 37:123789 32:161442 --:------ 2411 003 00003D
2025-10-16T19:27:06.444067 056 RP --- 32:161442 37:123789 --:------ 2411 022 00003D2F0F0000001400000000000000500000000170
2025-10-16T19:27:06.637906 000  I --- 18:183788 63:262142 --:------ 7FFF 023 00110199EE0FA46D32343131525133323A313631343432
2025-10-16T19:27:06.700858 000 RQ --- 37:123789 32:161442 --:------ 2411 003 00003E
2025-10-16T19:27:06.727933 055 RP --- 32:161442 37:123789 --:------ 2411 022 00003E300F0000001400000000000000500000000170
2025-10-16T19:27:06.935834 000  I --- 18:183788 63:262142 --:------ 7FFF 023 00110199EE0FA59832343131525133323A313631343432
2025-10-16T19:27:06.999711 000 RQ --- 37:123789 32:161442 --:------ 2411 003 00003F
2025-10-16T19:27:07.027949 055 RP --- 32:161442 37:123789 --:------ 2411 022 00003F310F0000001E00000000000000A00000000170
2025-10-16T19:27:07.235960 000  I --- 18:183788 63:262142 --:------ 7FFF 023 00110199EE0FA6C332343131525133323A313631343432
2025-10-16T19:27:07.299940 000 RQ --- 37:123789 32:161442 --:------ 2411 003 000040
2025-10-16T19:27:07.337036 055 RP --- 32:161442 37:123789 --:------ 2411 022 000040320F0000001E00000000000000A00000000170
2025-10-16T19:27:07.536977 000  I --- 18:183788 63:262142 --:------ 7FFF 023 00110199EE0FA7F032343131525133323A313631343432
2025-10-16T19:27:07.600795 000 RQ --- 37:123789 32:161442 --:------ 2411 003 000041
2025-10-16T19:27:07.632030 055 RP --- 32:161442 37:123789 --:------ 2411 022 000041330F0000006400000000000000C80000000170
2025-10-16T19:27:07.839088 000  I --- 18:183788 63:262142 --:------ 7FFF 023 00110199EE0FA91D32343131525133323A313631343432
2025-10-16T19:27:07.901945 000 RQ --- 37:123789 32:161442 --:------ 2411 003 000042
2025-10-16T19:27:07.931933 055 RP --- 32:161442 37:123789 --:------ 2411 022 000042340F0000006400000014000000C80000000170
2025-10-16T19:27:08.136993 000  I --- 18:183788 63:262142 --:------ 7FFF 023 00110199EE0FAA4A32343131525133323A313631343432
2025-10-16T19:27:08.200912 000 RQ --- 37:123789 32:161442 --:------ 2411 003 000043
2025-10-16T19:27:08.231941 055 RP --- 32:161442 37:123789 --:------ 2411 022 000043350F0000008C00000000000000C80000000170
2025-10-16T19:27:08.435866 000  I --- 18:183788 63:262142 --:------ 7FFF 023 00110199EE0FAB7532343131525133323A313631343432
2025-10-16T19:27:08.499763 000 RQ --- 37:123789 32:161442 --:------ 2411 003 000044
2025-10-16T19:27:08.535941 055 RP --- 32:161442 37:123789 --:------ 2411 022 000044360F0000008C00000014000000C80000000170
2025-10-16T19:27:08.736783 000  I --- 18:183788 63:262142 --:------ 7FFF 023 00110199EE0FAC9F32343131525133323A313631343432
2025-10-16T19:27:08.800923 000 RQ --- 37:123789 32:161442 --:------ 2411 003 00004B
2025-10-16T19:27:08.839936 055 RP --- 32:161442 37:123789 --:------ 2411 022 00004B39000000000000000000000000020000000170
2025-10-16T19:27:09.036783 000  I --- 18:183788 63:262142 --:------ 7FFF 023 00110199EE0FADCD32343131525133323A313631343432
2025-10-16T19:27:09.101912 000 RQ --- 37:123789 32:161442 --:------ 2411 003 00004E
2025-10-16T19:27:09.139946 055 RP --- 32:161442 37:123789 --:------ 2411 022 00004E3C000000000100000000000000010000000170
2025-10-16T19:27:09.337935 000  I --- 18:183788 63:262142 --:------ 7FFF 023 00110199EE0FAEFB32343131525133323A313631343432
2025-10-16T19:27:09.400900 000 RQ --- 37:123789 32:161442 --:------ 2411 003 000052
2025-10-16T19:27:09.434107 055 RP --- 32:161442 37:123789 --:------ 2411 022 00005240010000001400000000000000FA0000000170
2025-10-16T19:27:09.637064 000  I --- 18:183788 63:262142 --:------ 7FFF 023 00110199EE0FB02532343131525133323A313631343432
2025-10-16T19:27:09.700883 000 RQ --- 37:123789 32:161442 --:------ 2411 003 000054
2025-10-16T19:27:09.729085 056 RP --- 32:161442 37:123789 --:------ 2411 022 00005442000000000F0000000F0000003C0000000170
2025-10-16T19:27:09.938134 000  I --- 18:183788 63:262142 --:------ 7FFF 023 00110199EE0FB15132343131525133323A313631343432
2025-10-16T19:27:10.000890 000 RQ --- 37:123789 32:161442 --:------ 2411 003 000075
2025-10-16T19:27:10.038031 055 RP --- 32:161442 37:123789 --:------ 2411 022 0000755292000007D000000000000075300000000170
2025-10-16T19:27:10.236716 000  I --- 18:183788 63:262142 --:------ 7FFF 023 00110199EE0FB27C32343131525133323A313631343432
2025-10-16T19:27:10.300767 000 RQ --- 37:123789 32:161442 --:------ 2411 003 000095
2025-10-16T19:27:18.541134 057  I --- 32:097951 32:161442 --:------ 31E0 008 0000000001001E00
2025-10-16T19:27:18.562065 055  I --- 32:161442 --:------ 32:161442 31D9 004 00200400

[Wimpie70]

@TijmenvS Vreemd, de eerste RP zou al support voor 2411 params moeten triggeren.
Zie je iets in de home-assistant.log hierover: 'supports 2411 parameters' ?
En daarna: 'Creating parameter entities' ?
Er zou ook iets van 'Device initialized' in moeten staan.
Of een foutmelding ?

[TijmenvS]

@Wimpie70 Ik heb deze meldingen in het logboek. Geen supports 2411, creating parameter entities of device initialized.

code:

2025-10-16 19:27:06.131 WARNING (MainThread) [ramses_tx.message] RP --- 32:161442 37:123789 --:------ 2411 022 0000312610000000B400000000000007080000001E70 < Payload doesn't match '^(00|01|15|16|17|21)00[0-9A-F]{6}[0-9A-F]{8}(([0-9A-F]{8}){3}[0-9A-F]{4})?$': 0000312610000000B400000000000007080000001E70
2025-10-16 19:27:06.445 WARNING (MainThread) [ramses_tx.message] RP --- 32:161442 37:123789 --:------ 2411 022 00003D2F0F0000001400000000000000500000000170 < Payload doesn't match '^(00|01|15|16|17|21)00[0-9A-F]{6}[0-9A-F]{8}(([0-9A-F]{8}){3}[0-9A-F]{4})?$': 00003D2F0F0000001400000000000000500000000170
2025-10-16 19:27:06.729 WARNING (MainThread) [ramses_tx.message] RP --- 32:161442 37:123789 --:------ 2411 022 00003E300F0000001400000000000000500000000170 < Payload doesn't match '^(00|01|15|16|17|21)00[0-9A-F]{6}[0-9A-F]{8}(([0-9A-F]{8}){3}[0-9A-F]{4})?$': 00003E300F0000001400000000000000500000000170
2025-10-16 19:27:07.029 WARNING (MainThread) [ramses_tx.message] RP --- 32:161442 37:123789 --:------ 2411 022 00003F310F0000001E00000000000000A00000000170 < Payload doesn't match '^(00|01|15|16|17|21)00[0-9A-F]{6}[0-9A-F]{8}(([0-9A-F]{8}){3}[0-9A-F]{4})?$': 00003F310F0000001E00000000000000A00000000170
2025-10-16 19:27:07.338 WARNING (MainThread) [ramses_tx.message] RP --- 32:161442 37:123789 --:------ 2411 022 000040320F0000001E00000000000000A00000000170 < Payload doesn't match '^(00|01|15|16|17|21)00[0-9A-F]{6}[0-9A-F]{8}(([0-9A-F]{8}){3}[0-9A-F]{4})?$': 000040320F0000001E00000000000000A00000000170
2025-10-16 19:27:07.633 WARNING (MainThread) [ramses_tx.message] RP --- 32:161442 37:123789 --:------ 2411 022 000041330F0000006400000000000000C80000000170 < Payload doesn't match '^(00|01|15|16|17|21)00[0-9A-F]{6}[0-9A-F]{8}(([0-9A-F]{8}){3}[0-9A-F]{4})?$': 000041330F0000006400000000000000C80000000170
2025-10-16 19:27:07.933 WARNING (MainThread) [ramses_tx.message] RP --- 32:161442 37:123789 --:------ 2411 022 000042340F0000006400000014000000C80000000170 < Payload doesn't match '^(00|01|15|16|17|21)00[0-9A-F]{6}[0-9A-F]{8}(([0-9A-F]{8}){3}[0-9A-F]{4})?$': 000042340F0000006400000014000000C80000000170
2025-10-16 19:27:08.233 WARNING (MainThread) [ramses_tx.message] RP --- 32:161442 37:123789 --:------ 2411 022 000043350F0000008C00000000000000C80000000170 < Payload doesn't match '^(00|01|15|16|17|21)00[0-9A-F]{6}[0-9A-F]{8}(([0-9A-F]{8}){3}[0-9A-F]{4})?$': 000043350F0000008C00000000000000C80000000170
2025-10-16 19:27:08.537 WARNING (MainThread) [ramses_tx.message] RP --- 32:161442 37:123789 --:------ 2411 022 000044360F0000008C00000014000000C80000000170 < Payload doesn't match '^(00|01|15|16|17|21)00[0-9A-F]{6}[0-9A-F]{8}(([0-9A-F]{8}){3}[0-9A-F]{4})?$': 000044360F0000008C00000014000000C80000000170
2025-10-16 19:27:08.841 WARNING (MainThread) [ramses_tx.message] RP --- 32:161442 37:123789 --:------ 2411 022 00004B39000000000000000000000000020000000170 < Payload doesn't match '^(00|01|15|16|17|21)00[0-9A-F]{6}[0-9A-F]{8}(([0-9A-F]{8}){3}[0-9A-F]{4})?$': 00004B39000000000000000000000000020000000170
2025-10-16 19:27:09.141 WARNING (MainThread) [ramses_tx.message] RP --- 32:161442 37:123789 --:------ 2411 022 00004E3C000000000100000000000000010000000170 < Payload doesn't match '^(00|01|15|16|17|21)00[0-9A-F]{6}[0-9A-F]{8}(([0-9A-F]{8}){3}[0-9A-F]{4})?$': 00004E3C000000000100000000000000010000000170
2025-10-16 19:27:09.435 WARNING (MainThread) [ramses_tx.message] RP --- 32:161442 37:123789 --:------ 2411 022 00005240010000001400000000000000FA0000000170 < Payload doesn't match '^(00|01|15|16|17|21)00[0-9A-F]{6}[0-9A-F]{8}(([0-9A-F]{8}){3}[0-9A-F]{4})?$': 00005240010000001400000000000000FA0000000170
2025-10-16 19:27:09.730 WARNING (MainThread) [ramses_tx.message] RP --- 32:161442 37:123789 --:------ 2411 022 00005442000000000F0000000F0000003C0000000170 < Payload doesn't match '^(00|01|15|16|17|21)00[0-9A-F]{6}[0-9A-F]{8}(([0-9A-F]{8}){3}[0-9A-F]{4})?$': 00005442000000000F0000000F0000003C0000000170
2025-10-16 19:27:10.039 WARNING (MainThread) [ramses_tx.message] RP --- 32:161442 37:123789 --:------ 2411 022 0000755292000007D000000000000075300000000170 < Payload doesn't match '^(00|01|15|16|17|21)00[0-9A-F]{6}[0-9A-F]{8}(([0-9A-F]{8}){3}[0-9A-F]{4})?$': 0000755292000007D000000000000075300000000170

[Wimpie70]

@TijmenvS, interessant, ik kijk er naar.

[Wimpie70]

@TijmenvS Zie https://github.com/ramses-rf/ramses_rf/pull/310.
Als je wilt testen of het voor jou werkt voordat er een nieuwe versie uitkomt kan je de verandering in
ramses_rf/src/ramses_tx/ramses.py overnemen.

[Bra-Jo]

Paprika schreef op vrijdag 10 oktober 2025 @ 15:43:
Zonder hulp was ik hier waarschijnlijk dagen mee bezig geweest, maar met wat hulp van ChatGPT en een paar Tweakers-posts als input werkte alles eigenlijk direct. In de logs duiken naast mijn eigen WTW nog drie andere exemplaren op. Gezien mijn woning een rijtjeshuis is en ik aan één kant eenzelfde soort buren heb en aan de andere kant een beneden- en bovenwoning, is dat ook niet zo vreemd, maar ergens wel een grappig idee dat die data gewoon rond zweeft.

[Afbeelding]

Die is heel fraai! Voor de knoppen heb ik iets vergelijkbaars, maar hoe krijg je dat plaatje voor elkaar, met alle waardes die daar zichtbaar zijn?

[Wimpie70]

Ah leuk, Ik ben ook bezig met iets dergelijks. Plaatjes gemaakt met .svg:

De commando's staan in javascript, dus niet meer nodig om deze in de known list te plaatsen. Verder wil ik nog de configuratie settings (2411 params) toevoegen zodat je full control over je FAN krijgt via 1 card.
Ik zal m wel vrijgeven als ik wat verder ben.

[Xilvaro]

Xilvaro schreef op zondag 5 oktober 2025 @ 20:48:
Dag allen, misschien een domme vraag, maar ik heb een HRC300 WTW die sinds gisteren 1 van de ventilatoren op 100% heeft zuigen, althans, het klinkt als 150% om eerlijk te zijn.

Als ik de stekker eruit haal en er weer in doe gaat hij zijn opstartprocedure af, even optoeren en weer stoppen, bij de 2e keer "optoeren" gaat (volgens mij) de afzuigventilator op 150% draaien en blijft dat doen.

De afzuigventielen in huis klinken als een vliegtuig. Met de CO2 afstandsbediening het toestel handmatig op 1,2,3,auto of het huisje zetten helpt niets.

Iemand enig idee voor ik de monteur moet gaan bellen? Kan ik ergens nog wat resetten ofzo?

Net de Orcon uit elkaar gehaald. Na wat zoeken bleek op de foutieve motor het "kijkgaatje" voor de sensor op de motor ernstig vervuild. Deze schoongemaakt en weer in elkaar gezet, probleem opgelost!

@vervlogen bedankt nog voor de uitleg en foto's, heb er een hoop aan gehad!

[immrmkw]

Hoi allemaal,

Nog even weer een bericht over https://github.com/IMMRMKW/Ventilation_controller_cc. De integratie met als doel het ventilatiesysteem beter te kunnen regelen, met als input verscheidene sensoren die al in je Home Assistant aanwezig zijn. Sinds mijn laatste bericht ben ik samen met @homeautomate bezig geweest met testen, debuggen, en het toevoegen van nieuwe functionaliteit.

De belangrijkste toevoeging is multi-zone ondersteuning. De integratie heeft nu een binding functie waarmee hij fake CO2 sensoren in de Ramses RF integratie kan binden met de zonecontroller. De integratie houdt voor elke zone met een regelaar bij welke fan intensiteit nodig is, en stuurt dat via de fake CO2 sensoren naar de zonecontroller. De zonecontroller bepaalt zelf hoe hard de fan moet en hoe de luchtstroom verdeeld wordt. Dit werkt naadloos samen met al gekoppelde CO2 sensoren die bij het systeem horen. De commandos worden via een fake remote gestuurd (een verbetering zou nog zijn dat fake CO2 sensoren in de Ramses RF integratie ook commands ondersteunen).

We hebben dit nu getest en het werkt best aardig. Mochten jullie dit ook willen testen dan kan dit nu met de nieuwste release. Feedback kan gegeven worden in de vorm van een issue of een berichtje

[Wimpie70]

@immrmkw, Interessant. Misschien moeten we maar eens overleggen hoe en wat we kunnen samenvoegen. Ik heb een bound trait toegevoegd aan ramses voor REM. Deze kan gebruikt worden om commando's mee te zenden vanaf een faked REM (bedoeld voor 2411), Maar je kan deze ook gebruiken voor andere codes natuurlijk.
Verder wil ik de frontend kant beter organiseren...hmm, eten...i'll be back
zie ook: https://github.com/ramses-rf/ramses_cc/issues/325

[JP1980]

immrmkw schreef op zondag 19 oktober 2025 @ 19:31:
Hoi allemaal,

Nog even weer een bericht over https://github.com/IMMRMKW/Ventilation_controller_cc. De integratie met als doel het ventilatiesysteem beter te kunnen regelen, met als input verscheidene sensoren die al in je Home Assistant aanwezig zijn. Sinds mijn laatste bericht ben ik samen met @homeautomate bezig geweest met testen, debuggen, en het toevoegen van nieuwe functionaliteit.

De belangrijkste toevoeging is multi-zone ondersteuning. De integratie heeft nu een binding functie waarmee hij fake CO2 sensoren in de Ramses RF integratie kan binden met de zonecontroller. De integratie houdt voor elke zone met een regelaar bij welke fan intensiteit nodig is, en stuurt dat via de fake CO2 sensoren naar de zonecontroller. De zonecontroller bepaalt zelf hoe hard de fan moet en hoe de luchtstroom verdeeld wordt. Dit werkt naadloos samen met al gekoppelde CO2 sensoren die bij het systeem horen. De commandos worden via een fake remote gestuurd (een verbetering zou nog zijn dat fake CO2 sensoren in de Ramses RF integratie ook commands ondersteunen).

We hebben dit nu getest en het werkt best aardig. Mochten jullie dit ook willen testen dan kan dit nu met de nieuwste release. Feedback kan gegeven worden in de vorm van een issue of een berichtje

Dus je hebt uitgevogeld hoe je een fake co2 remote aanmeld bij de zone controller, dat zijn de zone kleppen neem ik aan? Daar ben ik erg blij mee top gedaan. Ben nog even met vakantie dan wil ik wel even kijken of het mij lukt. Hopelijk kan ik dan het verschrikkelijk zenuwachtige jojo effect voorkomen van de orcon co2 sturing.

[immrmkw]

@Wimpie70, lijkt me een goed idee!

@JP1980, ja we hebben idd uitgevogeld hoe we de fake CO2 kunnen aanmelden bij de zonekleppen. Prettige vakantie nog!

[JP1980]

immrmkw schreef op zondag 19 oktober 2025 @ 23:07:
@Wimpie70, lijkt me een goed idee!

@JP1980, ja we hebben idd uitgevogeld hoe we de fake CO2 kunnen aanmelden bij de zonekleppen. Prettige vakantie nog!

Thanks. Inmiddels weer terug. Paar vraagjes:

1.
Bij stap 4.4 in je documentatie moet ik controleren of de binding is gelukt. Waar moet je dan op letten?
Onderstaand de output die ik kan vinden in de ramses log waarbij ik 2 zones probeer te binden.

2.
De vraag 'Select your remote control device'. Waar dient deze instelling voor? Wij hebben 2 CO2 remotes en 1 handmatige remote. Ik heb hem maar ingesteld op de handmatige remote maar weet niet waar het voor dient, en of dit correct is.

3.
In de documentatie beginnen de CO2 devices met "29:". Bij mij beginnen de echte CO2 devices echter met "37:". Ik weet niet wat dit nummer betekent. Ik heb mijn fake CO2 devices maar begonnen met "29:", maar is dit wel correct?
Dus:
- Zone 1: CO2 remote 37:005250 wordt CO2 fake remote 29:225250
- Zone 2: CO2 remote 37:005253 wordt CO2 fake remote 29:225253

code:

2025-10-24T12:37:36.163036 000  I --- 18:174888 63:262142 --:------ 7FFF 023 0011019A15CB99EE31464339204936333A323632313432
2025-10-24T12:37:36.253535 000  I --- 29:225250 63:262142 --:------ 1FC9 030 0031E0776FE20131E0776FE2001298776FE26710E0776FE2001FC9776FE2
2025-10-24T12:37:36.492325 000  I --- 18:174888 63:262142 --:------ 7FFF 023 0011019A15CB9B3231464339204933323A313331343735
2025-10-24T12:37:36.555132 000  I --- 29:225250 32:131475 --:------ 1FC9 001 00
2025-10-24T12:37:37.513925 000  I --- 18:174888 63:262142 --:------ 7FFF 023 0011019A15CB9F2831304530204932393A323235323530
2025-10-24T12:37:37.605762 000  I --- 29:225250 63:262142 --:------ 10E0 038 000001C8500B0167FEFFFFFFFFFF090307E1564D532D31354331360000000000000000000000
2025-10-24T12:37:39.516701 000  I --- 18:174888 63:262142 --:------ 7FFF 024 0011019A15CBA70033314439525133323A3133313437357C
2025-10-24T12:37:39.580516 000 RQ --- 29:225250 32:131475 --:------ 31D9 001 00
2025-10-24T12:37:49.069029 000 RQ --- 18:174888 10:040343 --:------ 3220 005 0000000000
2025-10-24T12:37:50.284818 061  I --- 32:153741 --:------ 32:153741 31DA 030 00EF007FFF3A2E054607E407D4053EF00000432D2D0000EFEF0742074200
2025-10-24T12:37:52.115096 000 RQ --- 18:174888 10:040343 --:------ 3220 005 0000180000
2025-10-24T12:37:55.157403 000 RQ --- 18:174888 10:040343 --:------ 3EF0 001 00
2025-10-24T12:37:58.208901 000 RQ --- 18:174888 10:040343 --:------ 3220 005 0080190000
2025-10-24T12:38:01.271537 000 RQ --- 18:174888 10:040343 --:------ 2401 001 00
2025-10-24T12:38:04.324720 000 RQ --- 18:174888 10:040343 --:------ 3220 005 0080010000
2025-10-24T12:38:04.393006 000 RQ --- 18:174888 10:040343 --:------ 3220 005 0080730000
2025-10-24T12:38:07.431132 000 RQ --- 18:174888 10:040343 --:------ 3220 005 0000110000
2025-10-24T12:38:08.698100 000  I --- 18:174888 63:262142 --:------ 7FFF 023 0011019A15CC190F31464339204936333A323632313432
2025-10-24T12:38:08.781164 000  I --- 29:225253 63:262142 --:------ 1FC9 030 0031E0776FE50131E0776FE5001298776FE56710E0776FE5001FC9776FE5
2025-10-24T12:38:08.962160 000  I --- 18:174888 63:262142 --:------ 7FFF 023 0011019A15CC19F931464339204933323A313331343735
2025-10-24T12:38:09.026644 000  I --- 29:225253 32:131475 --:------ 1FC9 001 00
2025-10-24T12:38:09.951908 000  I --- 18:174888 63:262142 --:------ 7FFF 023 0011019A15CC1DF031304530204932393A323235323533
2025-10-24T12:38:10.040514 000  I --- 29:225253 63:262142 --:------ 10E0 038 000001C8500B0167FEFFFFFFFFFF090307E1564D532D31354331360000000000000000000000
2025-10-24T12:38:10.476779 000 RQ --- 18:174888 10:040343 --:------ 3220 005 0000120000
2025-10-24T12:38:10.705256 074 RP --- 01:056680 30:083299 --:------ 0006 004 000501B4
2025-10-24T12:38:12.067411 000  I --- 18:174888 63:262142 --:------ 7FFF 024 0011019A15CC25F433314439525133323A3133313437357C
2025-10-24T12:38:12.161303 000 RQ --- 29:225253 32:131475 --:------ 31D9 001 00
2025-10-24T12:38:13.529847 000 RQ --- 18:174888 10:040343 --:------ 3220 005 0080130000
2025-10-24T12:38:13.618068 000 RQ --- 18:174888 10:040343 --:------ 3220 005 00801A0000
2025-10-24T12:38:13.670696 000 RQ --- 18:174888 10:040343 --:------ 3220 005 00001B0000
2025-10-24T12:38:16.720265 000 RQ --- 18:174888 10:040343 --:------ 3220 005 00801C0000
2025-10-24T12:38:16.785798 000 RQ --- 18:174888 10:040343 --:------ 3220 005 0000050000
2025-10-24T12:38:49.824530 000 RQ --- 18:174888 10:040343 --:------ 3220 005 0000000000
2025-10-24T12:38:55.187169 000 RQ --- 18:174888 10:040343 --:------ 3EF0 001 00
2025-10-24T12:38:57.389422 000 RQ --- 18:174888 01:056680 --:------ 313F 001 00
2025-10-24T12:38:57.405139 057 RP --- 01:056680 18:174888 --:------ 313F 009 00FCBB268C180A07E9
2025-10-24T12:39:01.300775 000 RQ --- 18:174888 10:040343 --:------ 2401 001 00
2025-10-24T12:39:02.803388 056  I --- 01:056680 --:------ 01:056680 1F09 003 FF05E1
2025-10-24T12:39:02.822680 056  I --- 01:056680 --:------ 01:056680 2309 015 0008340106A40206A4030708040672
2025-10-24T12:39:02.839452 056  I --- 01:056680 --:------ 01:056680 30C9 015 0008560106C9020782030773040770
2025-10-24T12:39:07.973675 056 RP --- 01:056680 30:083299 --:------ 0006 004 000501B4
2025-10-24T12:39:15.687552 056  I --- 01:056680 --:------ 01:056680 0008 002 FC00

[immrmkw]

@JP1980

Antwoorden op je vragen:

1.
Om zeker te weten of ze succesvol gebind zijn, kun je het best even wat testcommando's toevoegen aan je fake remote en kijken of je controller daarop reageert. Met de volgende commando's kun je een hoge flow aanroepen en moeten horen dat de fan reageert:

code:

test_zone1: " I --- 29:225250 32:131475 --:------ 31E0 008 0000FF000100FF00"
test_zone2: " I --- 29:225253 32:131475 --:------ 31E0 008 0000FF000100FE00"

In jouw logs kun je in ieder geval zien dat de juiste commando's uitgevoerd zijn:
1FC9 030 - Device offer
1FC9 001 00 - Device confirm naar controller
10E0 038 - Device info broadcast
31D9 001 00 - Sensor config request

Maar volgens mij is jouw controller 32:131475, en deze stuurt geen antwoord op de requests. De controller staat in pairing mode? Welk merk systeem heb je?

2.
Waar ik het over remotes heb, bedoel ik niet de CO2 devices, maar het device dat je in 'known devices' in Ramses RF op deze manier aan kunt maken:

code:

"29:162275":
  class: REM
  commands:
    auto: " I --- 29:162275 32:146231 --:------ 22F1 003 000407"

De ventilatiecontroller integratie gebruikt deze remote omdat je hier custom commando's toe kunt voegen aan de commands list met de functie 'add_command'. Wanneer de ventilatiecontroller draait, voegt hij alle commando's eerst to aan de remote, waarna hij het commando aanroept met 'send_command'.

Dus voor een werkende integratie, heb je zo'n fake remote nodig in je 'known_devices'.

3.
Volgens mij zijn er 2 typen CO2 sensoren. Bij mij heeft de 37:xxxxxx een aantal van dezelfde functies als een remote (vandaar misschien de verwarring hierboven), maar heeft daarnaast ook een CO2 sensor. De 29:xxxxxx heeft een CO2 sensor en daarnaast kun je alleen nog instellen hoe 'strikt' hij de CO2 regelt.

Wij hebben het binding proces getest met 29:xxxxxx, dus zoals jij het hier gedaan hebt, lijkt me prima.

[JP1980]

immrmkw schreef op zaterdag 25 oktober 2025 @ 10:14:
@JP1980

Antwoorden op je vragen:

1.
Om zeker te weten of ze succesvol gebind zijn, kun je het best even wat testcommando's toevoegen aan je fake remote en kijken of je controller daarop reageert. Met de volgende commando's kun je een hoge flow aanroepen en moeten horen dat de fan reageert:

code:

test_zone1: " I --- 29:225250 32:131475 --:------ 31E0 008 0000FF000100FF00"
test_zone2: " I --- 29:225253 32:131475 --:------ 31E0 008 0000FF000100FE00"
spoof_test_zone1: " I --- 37:005250 32:131475 --:------ 31E0 008 0000FF000100FF00"
spoof_test_zone2: " I --- 37:005253 32:131475 --:------ 31E0 008 0000FF000100FE00"

In jouw logs kun je in ieder geval zien dat de juiste commando's uitgevoerd zijn:
1FC9 030 - Device offer
1FC9 001 00 - Device confirm naar controller
10E0 038 - Device info broadcast
31D9 001 00 - Sensor config request

Maar volgens mij is jouw controller 32:131475, en deze stuurt geen antwoord op de requests. De controller staat in pairing mode? Welk merk systeem heb je?

2.
Waar ik het over remotes heb, bedoel ik niet de CO2 devices, maar het device dat je in 'known devices' in Ramses RF op deze manier aan kunt maken:

code:

"29:162275":
  class: REM
  commands:
    auto: " I --- 29:162275 32:146231 --:------ 22F1 003 000407"

De ventilatiecontroller integratie gebruikt deze remote omdat je hier custom commando's toe kunt voegen aan de commands list met de functie 'add_command'. Wanneer de ventilatiecontroller draait, voegt hij alle commando's eerst to aan de remote, waarna hij het commando aanroept met 'send_command'.

Dus voor een werkende integratie, heb je zo'n fake remote nodig in je 'known_devices'.

3.
Volgens mij zijn er 2 typen CO2 sensoren. Bij mij heeft de 37:xxxxxx een aantal van dezelfde functies als een remote (vandaar misschien de verwarring hierboven), maar heeft daarnaast ook een CO2 sensor. De 29:xxxxxx heeft een CO2 sensor en daarnaast kun je alleen nog instellen hoe 'strikt' hij de CO2 regelt.

Wij hebben het binding proces getest met 29:xxxxxx, dus zoals jij het hier gedaan hebt, lijkt me prima.

Bedankt voor je reactie.

Ik denk dat ik het begrijp. Fysiek is de CO2 sensor en Remote 1 apparaat maar voor Ramses zijn het gewoon 2 verschillende.
En een faked device in Ramsus stuurt z'n commando's met zijn ID als afzender, maar je kan gewoon meerdere afzenders definieren in de commando's zelf. Naar mijn idee minder instinctief, maar wel flexibel. Dus ik heb een remote gedefinieerd, die heeft wel het ID van een echte remote maar dat maakt in feite helemaal niks uit want dat ID wordt toch niet gebruikt bij het verzenden van commando's.

Ben al stukken verder. Het lijkt er op dat pairing is gelukt
Mijn setup is als volgt:
Orcon zone controller -> 32:131475
Orcon HRC-425 -> 32:153741
Orcon CO2 15RF zone 1 -> 37:005250
Orcon CO2 15RF zone 2 -> 37:005253

Kortom ik heb gepaired met de zone controller en niet de HRC. Maar dat lijkt goed.

De fan reageert soms op de door jouw gegeven commando's.
Maar ik merk ook dat de fan heel vaak niet reageert. En het maakt niet uit of ik het commando stuur via de ID van een bestaande fysieke CO2 sensor remote of een faked.
test_zone2: " I --- 37:005253 32:131475 --:------ 31E0 008 0000FF000100FE00"
woonkamer_stand_2: " I --- 37:005250 32:131475 --:------ 22F3 007 00520D02040404"
De 005253 en 005250 zijn bestaande fysieke CO2 sensors die gepaired zijn.

Moet nog zien uit te vogelen waarom dat zo is. CO2 in het huis is nu wat opgelopen dus de normale CO2 sensors hebben momenteel ook even een eigen wil

Volgende stap, de PID controller werkend krijgen want volgens mij doet deze niks:
Zone 1 heeft nu een air quality index van 1,76
Zone 2 heeft nu een air quality index van 0,64.
Setpoint heb ik maar even op 3.0 gezet als test.
De Fan Rate blijft echter 0%.
^^ EDIT: Laat maar heb de instellingen wat getweaked, en nu begint het te reageren

Klopt dat? Ik ging er vanuit dat de fan rate omhoog zou gaan.

En er is denk ik nog een bug. Ik kan het niet simuleren maar zo af en toe krijg ik een nieuwe "Air Quality Index Zone x" sensor bij. Heb er nu 4. Dat waren er eerst 2. Iets triggert denk ik onnodig het aanmaken van een nieuwe sensor.

[ Voor 4% gewijzigd door JP1980 op 25-10-2025 18:59 ]

[immrmkw]

@JP1980

Ja dat klopt. Het is nu zo gedaan omdat de remote als enige het toevoegen van commando's ondersteunt. Dus hoewel de commando's van je fake sensors lijken te komen, stuurt je fake remote ze eigenlijk.

Pairen moet met de zonecontroller inderdaad.

Ik heb zelf niet een systeem met zones. Misschien kan @homeautomate, daar nog iets over zeggen. In ieder geval zou ik wel verwachten dat wanneer je een 31E0 commando stuurt, er altijd iets gebeurt. Bij mij gaat de ventilator instantaan naar maximaal wanneer ik een 31E0 commando stuur met FF als 3de byte, wat de maximale ventilatiesterkte aangeeft.

De PID controller reageert alleen als het setpoint lager is dan je huidige index, maar dat had je denk ik al uitgevonden nu.

Dat is inderdaad een bug. Ik dacht dat ik deze had opgelost, maar er zijn blijkbaar nog omstandigheden waarbij het alsnog optreedt... Mocht het toch nog lukken om de stappen waarbij het optreedt te achterhalen, laat het me dan weten, dan kan ik het iets makkelijker oplossen. Ik denk dat het is wanneer je de opties later nogmaals opent om dingen aan te passen. Ik ga er zelf ook naar kijken.

[JP1980]

immrmkw schreef op zondag 26 oktober 2025 @ 09:51:
@JP1980
De PID controller reageert alleen als het setpoint lager is dan je huidige index, maar dat had je denk ik al uitgevonden nu.

Dat had ik inderdaad niet uitgevogeld, en is waarschijnlijk het cruciale gegeven wat ik miste. Ik ging er vanuit dat een hogere stand een heftigere reactie oplevert. Denk dat ik die flink ga verlagen dan. Wat ik wil bereiken is dat de HA aansturing net m'n normale aansturing iets voor is. Het systeem moet vrij snel een basisventilatie gaan geven. We wonen maar met ons 2'en en 2 katten en eigenlijk alles wat ik nodig heb is zodra de CO2 maar iets verhoogt is (zeg ongeveer 700ppm) dan wil ik dat deze precies gaat ventileren alsof er 2 mensen in de kamer zijn.

immrmkw schreef op zondag 26 oktober 2025 @ 09:51:
@JP1980
Dat is inderdaad een bug. Ik dacht dat ik deze had opgelost, maar er zijn blijkbaar nog omstandigheden waarbij het alsnog optreedt... Mocht het toch nog lukken om de stappen waarbij het optreedt te achterhalen, laat het me dan weten, dan kan ik het iets makkelijker oplossen. Ik denk dat het is wanneer je de opties later nogmaals opent om dingen aan te passen. Ik ga er zelf ook naar kijken.

Het viel mij op na aanpassen van de CO2 index treshold. Maar als ik die nu aanpas dan gebeurd het niet meer. Ik heb de 2 extra sensoren verwijderd als ik het ontdek meld ik het wel.

Nog 1 vraagje: ik zou graag het gedrag een beetje willen simuleren. Is er ook een mogelijkheid om handmatig de air quality en fan rate te herberekenen? Dan kan ik met gesimuleerde CO2 sensors eens kijken wat hij gaat doen onder welke omstandigheden. Nu moet ik elke keer wachten op de update interval. Of kan ik voor het testen deze ook op 10 seconden zetten (Ramses update om de 60 seconden)?

[JP1980]

immrmkw schreef op zondag 26 oktober 2025 @ 09:51:
@JP1980

Ja dat klopt. Het is nu zo gedaan omdat de remote als enige het toevoegen van commando's ondersteunt. Dus hoewel de commando's van je fake sensors lijken te komen, stuurt je fake remote ze eigenlijk.

Pairen moet met de zonecontroller inderdaad.

Ik heb zelf niet een systeem met zones. Misschien kan @homeautomate, daar nog iets over zeggen. In ieder geval zou ik wel verwachten dat wanneer je een 31E0 commando stuurt, er altijd iets gebeurt. Bij mij gaat de ventilator instantaan naar maximaal wanneer ik een 31E0 commando stuur met FF als 3de byte, wat de maximale ventilatiesterkte aangeeft.

De PID controller reageert alleen als het setpoint lager is dan je huidige index, maar dat had je denk ik al uitgevonden nu.

Dat is inderdaad een bug. Ik dacht dat ik deze had opgelost, maar er zijn blijkbaar nog omstandigheden waarbij het alsnog optreedt... Mocht het toch nog lukken om de stappen waarbij het optreedt te achterhalen, laat het me dan weten, dan kan ik het iets makkelijker oplossen. Ik denk dat het is wanneer je de opties later nogmaals opent om dingen aan te passen. Ik ga er zelf ook naar kijken.

Nog 2 ontdekkingen:

1. verdwijnen CO2 devices settings
Is nu voor de 2e keer gebeurd. Maar soms verdwijnen ineens de instellingen van beide Device Configuration van zone 1 en zone 2. Ook hier heb ik nog niet kunnen ontdekken wanneer dit gebeurd maar je merkt er niets van behalve dat de Fan Rate 0 blijft.

2. standaard waarde ik Proportional Gain (Kp)
Deze bevat bij mij 25,5 terwijl de decimal separator een punt is. Naar mijn idee heb ik dit getal niet gewijzigd.
Ben niet thuis in Pyton maar volgens ChatGPT moet deze wijziging gemaakt worden in config.flow.py regel 175:

code:

vol.Required("kp", default=25.5): vol.Coerce(float),

moet zijn

code:

vol.Required("kp", default=25.5): cv.small_float

EDIT nog een update:
Elke keer als ik bij kp 25.5 invul dan veranderd het HA dit weer naar 25,5. Dus ik heb er nu even 25 van gemaakt. En nu heb ik een fan rate. En ook weer die 2 extra Air Qualirty Index Zone 3 en 4. Dus ik ging van een incorrecte setup naar een correcte setup.

[ Voor 6% gewijzigd door JP1980 op 26-10-2025 16:06 ]

[immrmkw]

@JP1980

De controller maakt van elke sensorwaarde een getal tussen 0 en 5. Dit gebeurt met de indexwaarden die je voor dit type sensor hebt opgegeven. Voor de CO2 is het als volgt:

code:

[400, 650, 1500, 2000, 2500, 5000]

Als de sensor een waarde uitleest die exact gelijk is met 1 van deze getallen, dan krijg je 0, 1, 2, 3, 4 of 5. Als het een waarde is die ertussen ligt, dan interpoleert hij deze. 700 ppm zoals in jouw voorbeeld leidt tot een index van 1.059. Als je de controller dus een setpoint van 1 geeft, zou hij vrij dicht in de buurt van 700 ppm moeten blijven.

Je kunt het gedrag simuleren door de PID berekening handmatig uit te voeren. Je fan output is de som van een proportioneel deel en een integrator (de D is altijd nul, dus eigenlijk is het een PI controller). De fout is je huidige index minus je setpoint. Dus als je index 2 is, terwijl je hem op 1 in had gesteld, is je fout 1. Het proportionele deel doet je fout maal de gain (Kp). Dus als je fout 1 is, en je gain 25, dan gaat je ventilatie op 25% draaien. De integrator integreert je fout, en vermenigvuldigt dat met de gain (Ki). Ik heb dit intuitief proberen te maken door gebruikers het aantal seconden op te laten geven dat het duurt voordat de fan op 100% staat bij een fout van 1, 2, 3, 4, of 5. Dus stel je fout is 1, en je zet de gain op 900 seconden, dan duurt het een kwartier voordat je fan op 100% staat.

Dus, stel je zet je controller nu aan, en je fout is 1, dan gaat je ventilator instantaan op 25%, en grofweg een kwartier later staat hij op 100%.

Wat betreft je ontdekkingen:
1. Dit ben ik in het verleden ook tegengekomen, maar meende ik al gefixt te hebben. Net als de vorige bug die je rapporteerde. Welk versienummer staat er in je manifest? Ik ga hoe dan ook nog een nieuwe versie maken met nog een paar kleine verbeteringen erin. Hopelijk is het dan helemaal verholpen.

2. Dit heb ik nog niet eerder gezien. Zoals je code al aangeeft, is de waarde default 25.5, niet 25,5. Dit kan te maken hebben met hoe we in het Nederlands de komma gebruiken ipv de punt. Ik kijk of Chatgpts oplossing werkt.

[immrmkw]

@JP1980 , ik heb een nieuwe release gemaakt, v2.1.0-dev, die hopelijk alle vandaag genoemde punten verbetert.

[ Voor 6% gewijzigd door immrmkw op 26-10-2025 21:11 ]

[JP1980]

immrmkw schreef op zondag 26 oktober 2025 @ 20:29:
@JP1980

De controller maakt van elke sensorwaarde een getal tussen 0 en 5. Dit gebeurt met de indexwaarden die je voor dit type sensor hebt opgegeven. Voor de CO2 is het als volgt:

code:

[400, 650, 1500, 2000, 2500, 5000]

Als de sensor een waarde uitleest die exact gelijk is met 1 van deze getallen, dan krijg je 0, 1, 2, 3, 4 of 5. Als het een waarde is die ertussen ligt, dan interpoleert hij deze. 700 ppm zoals in jouw voorbeeld leidt tot een index van 1.059. Als je de controller dus een setpoint van 1 geeft, zou hij vrij dicht in de buurt van 700 ppm moeten blijven.

Je kunt het gedrag simuleren door de PID berekening handmatig uit te voeren. Je fan output is de som van een proportioneel deel en een integrator (de D is altijd nul, dus eigenlijk is het een PI controller). De fout is je huidige index minus je setpoint. Dus als je index 2 is, terwijl je hem op 1 in had gesteld, is je fout 1. Het proportionele deel doet je fout maal de gain (Kp). Dus als je fout 1 is, en je gain 25, dan gaat je ventilatie op 25% draaien. De integrator integreert je fout, en vermenigvuldigt dat met de gain (Ki). Ik heb dit intuitief proberen te maken door gebruikers het aantal seconden op te laten geven dat het duurt voordat de fan op 100% staat bij een fout van 1, 2, 3, 4, of 5. Dus stel je fout is 1, en je zet de gain op 900 seconden, dan duurt het een kwartier voordat je fan op 100% staat.

Dus, stel je zet je controller nu aan, en je fout is 1, dan gaat je ventilator instantaan op 25%, en grofweg een kwartier later staat hij op 100%.

Wat betreft je ontdekkingen:
1. Dit ben ik in het verleden ook tegengekomen, maar meende ik al gefixt te hebben. Net als de vorige bug die je rapporteerde. Welk versienummer staat er in je manifest? Ik ga hoe dan ook nog een nieuwe versie maken met nog een paar kleine verbeteringen erin. Hopelijk is het dan helemaal verholpen.

2. Dit heb ik nog niet eerder gezien. Zoals je code al aangeeft, is de waarde default 25.5, niet 25,5. Dit kan te maken hebben met hoe we in het Nederlands de komma gebruiken ipv de punt. Ik kijk of Chatgpts oplossing werkt.

Dank je. Het is duidelijk en het percentage gaat met de KP van 25 (dus zonder decimalen) goed.
Alleen de aansturing van de ventilatie zie ik nog niet terug in het ramses log, alleen in het begin lijkt er enige communicatie te zijn.

Ik heb versie 0.2 en zie inderdaad een nieuwe versie 2.1.0 dev binnenkomen. Die ga ik installeren en ik houd je op de hoogte of dat beter gaat.

[JP1980]

immrmkw schreef op zondag 26 oktober 2025 @ 20:29:
@JP1980

De controller maakt van elke sensorwaarde een getal tussen 0 en 5. Dit gebeurt met de indexwaarden die je voor dit type sensor hebt opgegeven. Voor de CO2 is het als volgt:

code:

[400, 650, 1500, 2000, 2500, 5000]

Als de sensor een waarde uitleest die exact gelijk is met 1 van deze getallen, dan krijg je 0, 1, 2, 3, 4 of 5. Als het een waarde is die ertussen ligt, dan interpoleert hij deze. 700 ppm zoals in jouw voorbeeld leidt tot een index van 1.059. Als je de controller dus een setpoint van 1 geeft, zou hij vrij dicht in de buurt van 700 ppm moeten blijven.

Je kunt het gedrag simuleren door de PID berekening handmatig uit te voeren. Je fan output is de som van een proportioneel deel en een integrator (de D is altijd nul, dus eigenlijk is het een PI controller). De fout is je huidige index minus je setpoint. Dus als je index 2 is, terwijl je hem op 1 in had gesteld, is je fout 1. Het proportionele deel doet je fout maal de gain (Kp). Dus als je fout 1 is, en je gain 25, dan gaat je ventilatie op 25% draaien. De integrator integreert je fout, en vermenigvuldigt dat met de gain (Ki). Ik heb dit intuitief proberen te maken door gebruikers het aantal seconden op te laten geven dat het duurt voordat de fan op 100% staat bij een fout van 1, 2, 3, 4, of 5. Dus stel je fout is 1, en je zet de gain op 900 seconden, dan duurt het een kwartier voordat je fan op 100% staat.

Dus, stel je zet je controller nu aan, en je fout is 1, dan gaat je ventilator instantaan op 25%, en grofweg een kwartier later staat hij op 100%.

Wat betreft je ontdekkingen:
1. Dit ben ik in het verleden ook tegengekomen, maar meende ik al gefixt te hebben. Net als de vorige bug die je rapporteerde. Welk versienummer staat er in je manifest? Ik ga hoe dan ook nog een nieuwe versie maken met nog een paar kleine verbeteringen erin. Hopelijk is het dan helemaal verholpen.

2. Dit heb ik nog niet eerder gezien. Zoals je code al aangeeft, is de waarde default 25.5, niet 25,5. Dit kan te maken hebben met hoe we in het Nederlands de komma gebruiken ipv de punt. Ik kijk of Chatgpts oplossing werkt.

Mijn hele device configuration had ik fout opgezet.
Persoonlijker had ik het wat inituatiever gevonden dat je bijvoorbeeld de CO2 sensor en overige sensors bij de zone kan configureren. Nu kan je CO2 sensors opgeven maar ik neem aan dat de eerste die je opgeeft zone 1 is, de 2e zone 2 maar dat is niet direct duidelijk.

Dingen lijken nu te gaan werken.

Nog wat dingen tegengekomen:
1. setup wijzigen wil niet
Wijziging in de PID setup kan ik niet meer doen krijg daar altijd een melding zowel bij "Air Quaility Setpoint" en "Proportional Gain" -> "Value must be at most 1".

2. wijzigen in de setup hebben geen effect
Totdat ik de integratie handmatig herlaad.

3. Is het echt zuiver multizone?
Als ik de code goed begrijp stuur je wel alle beide zones aan, maar wordt de fan rate bepaald op basis van zone met de slechtste kwaliteit. De andere zone ontvangt dan een bericht dat deze op de min waarde moet ventileren. Begrijp ik dat goed en zo ja, waarom is dat?
Naar mijn idee klopt dit conceptueel niet, en moet elke zone een eigen Fan Rate hebben en op die basis een "Fan Demand" indienen bij de controller. De controller zoekt op basis van alle input de stand van de kleppen en het totale luchtdebiet van de ventilator om te voldoen aan de gecombineerde verzoeken van de sensoren.

[immrmkw]

@JP1980

Ik heb het nu zo gedaan dat je eerst alle sensoren kunt selecteren, en in het volgende venster kun je aan elke sensor een zone toekennen. Dit vond ik aardig intuitief. De config flow laat het niet toe om dynamisch zowel een sensor als een zone te selecteren. Wat ik kan doen is dat ik gebruikers per zone een willekeurige lijst met sensoren laat maken, en dan later check welk type sensoren is geselecteerd en de volgende stappen in de config flow daarop baseer. Ik vond het nu eigenlijk al best prima.

1. Dit gebeurt bij mij niet. Zou misschien ook weer aan de taalinstellingen kunnen liggen oid. Ik moet er even naar kijken.
2. Als ik een wijziging maak en de log open, zie ik dat de integratie herstart. Heb jij dit niet?
3. Ik heb zelf geen multi-zone systeem, dus ik weet niet 100% hoe dit werkt. Zoals ik het begrijp, sturen sensoren in de verschillende zones allemaal een demand (in de vorm van een getal van 0 - 255), en vogelt de zonecontroller de stand van de kleppen en de ventilator uit. Vaak zit daar een algoritme achter dat een ratio bepaalt tussen de kleppen inderdaad. Hij prioriteert de zone met de slechtste kwaliteit en die zal vanzelf een betere kwaliteit krijgen dan de andere zone. Vervolgens wordt deze zone geprioriteerd. Dan regelt het allemaal vanzelf naar de juiste waarde. Je hoeft hiervoor niet expliciet met debieten te werken.

[JP1980]

immrmkw schreef op maandag 27 oktober 2025 @ 22:12:
@JP1980
1. Dit gebeurt bij mij niet. Zou misschien ook weer aan de taalinstellingen kunnen liggen oid. Ik moet er even naar kijken.

Bij mij gebeurde dit in versie 0.2 ook niet.

immrmkw schreef op maandag 27 oktober 2025 @ 22:12:
@JP1980
2. Als ik een wijziging maak en de log open, zie ik dat de integratie herstart. Heb jij dit niet?

ok ik zie dat bij sommige instellingen dat dit wel gebeurd. Maar niet nadat ik de device configuratie (1 en 2) had gewijzigd.

immrmkw schreef op maandag 27 oktober 2025 @ 22:12:
3. Ik heb zelf geen multi-zone systeem, dus ik weet niet 100% hoe dit werkt. Zoals ik het begrijp, sturen sensoren in de verschillende zones allemaal een demand (in de vorm van een getal van 0 - 255), en vogelt de zonecontroller de stand van de kleppen en de ventilator uit. Vaak zit daar een algoritme achter dat een ratio bepaalt tussen de kleppen inderdaad. Hij prioriteert de zone met de slechtste kwaliteit en die zal vanzelf een betere kwaliteit krijgen dan de andere zone. Vervolgens wordt deze zone geprioriteerd. Dan regelt het allemaal vanzelf naar de juiste waarde. Je hoeft hiervoor niet expliciet met debieten te werken.

ok dan is het wel lastig testen maar het is exact zoals je zegt.
Eigenlijk moet je elke zone zien als een apart systeem. De WTW zoekt zelf uit wat die moet doen.
Als ik op 1 zone 100% vraag en op de andere zone 0%, dan draait de WTW op 65%. (vermoed dat er nog steeds 15% naar de andere zone gaat).
Die prioritering hoef je dan ook niet in je applicatie te regelen. Je applicatie hoeft alleen maar een verzoek in te dienen per zone.
Ik dacht in je code te lezen dat alleen de slechtste zone aangestuurd werd maar kan het ook niet meer vinden. zal het nog in de gaten houden.

Ik zal de komende dagen nog even kijken of deze regeling wat is maar neig toch na om mijn doel met een eigen script te bereiken. Enige wat ik wil is dat de ventilatie iets eerder op een basisniveau begint te draaien. Als de CO2 dan nog oploopt dan mogen de normale sensoren het wel overnemen. Daar is niet een super geavanceerde regeling voor nodig. Ben wel blij dat door je applicatie het aanmelden van de fake sensoren is gelukt

[homeautomate]

Mooi om te zien dat er weer stappen zijn gemaakt @immrmkw! goede feedback @JP1980

Ben ook in het bezit van zonesturing met een aantal Orcon sensoren en een aantal niet Orcon sensoren ongeveer elke kamer heeft een Netatmo. In dit geval is dit een ideale oplossing. Niet Orcon CO2 melders en Orcon CO2 melders worden dan samengebracht in een "groep AQI" om op basis van de kwaliteit eerder in te spelen op de behoefte.

De fan demand die wordt afgegeven middels een E31 bericht is bepalend voor het bepalen van de ratio conform de ingestelde verhouding tussen zone 1 en zone 2 (bijv 65% zone 1 en 35% zone 2) op de kleppen. Vandaar dat de PID fan rate sensor ook niet gelijk loopt met de supply fan speed sensor (althans dat is mijn theorie). Volgens mijn analyse klopt het ook dat een klep nooit helemaal wordt afgesloten ongeacht de ingestelde verhouding. Hij blijft altijd afhankelijk van de verdeling een minimale hoeveelheid lucht doorvoeren aan de zone waar geen vraag is.

@immrmkw het gebeurd nog regelmatig hier dat de fan rate sensor blijft hangen zonder dat er enig bericht wordt verstuurd naar de zone controller. Dan moet ik opnieuw de config volledig doorlopen om het weer werkend te krijgen. Niet erg maar dacht misschien kunnen we dit issue nog ergens terugvinden.

@JP1980 Stel dat de PID rond een setpoint van 1 is ingesteld, zal de unit sneller optoeren en de verdeling juist worden gedaan. Ik kan mij wel vinden in wat je zegt maar ben nog zoekende hoe de waardes bijvoorbeeld vastgehouden kunnen worden in de vorm van een trend. Aan wat voor type script denk je aan?

Wellicht een idee @immrmkw dat je kan sturen op twee manieren dat kan dan voor niet zone en zonesturing, daarmee realiseren we een soort 'supervisory laag':
1 via PID modulair (voor de dynamische aanpassing), en
2 aanvullend met vooraf gedefinieerde bandbreedtes of hysterese
Een idee: Stel je bent met 2 / 3 personen in een ruimte en CO2 loopt op setpoint zorgt dat de Unit sneller acteert wil je dat er op basis van een bepaalde bandbreedte een fan speed voor die "trend" vastgehouden wordt om te voorkomen dat de unit continue aan het opspinnen en afspinnen is.

Heb wel eens de apps van andere partijen bekeken maar die lijken lang niet zo ver te gaan als wat wij hier bespreken dus dat is zeker motiverend!

[JP1980]

homeautomate schreef op dinsdag 28 oktober 2025 @ 14:56:
Mooi om te zien dat er weer stappen zijn gemaakt @immrmkw! goede feedback @JP1980

Ben ook in het bezit van zonesturing met een aantal Orcon sensoren en een aantal niet Orcon sensoren ongeveer elke kamer heeft een Netatmo. In dit geval is dit een ideale oplossing. Niet Orcon CO2 melders en Orcon CO2 melders worden dan samengebracht in een "groep AQI" om op basis van de kwaliteit eerder in te spelen op de behoefte.

De fan demand die wordt afgegeven middels een E31 bericht is bepalend voor het bepalen van de ratio conform de ingestelde verhouding tussen zone 1 en zone 2 (bijv 65% zone 1 en 35% zone 2) op de kleppen. Vandaar dat de PID fan rate sensor ook niet gelijk loopt met de supply fan speed sensor (althans dat is mijn theorie). Volgens mijn analyse klopt het ook dat een klep nooit helemaal wordt afgesloten ongeacht de ingestelde verhouding. Hij blijft altijd afhankelijk van de verdeling een minimale hoeveelheid lucht doorvoeren aan de zone waar geen vraag is.

@immrmkw het gebeurd nog regelmatig hier dat de fan rate sensor blijft hangen zonder dat er enig bericht wordt verstuurd naar de zone controller. Dan moet ik opnieuw de config volledig doorlopen om het weer werkend te krijgen. Niet erg maar dacht misschien kunnen we dit issue nog ergens terugvinden.

@JP1980 Stel dat de PID rond een setpoint van 1 is ingesteld, zal de unit sneller optoeren en de verdeling juist worden gedaan. Ik kan mij wel vinden in wat je zegt maar ben nog zoekende hoe de waardes bijvoorbeeld vastgehouden kunnen worden in de vorm van een trend. Aan wat voor type script denk je aan?

Wellicht een idee @immrmkw dat je kan sturen op twee manieren dat kan dan voor niet zone en zonesturing, daarmee realiseren we een soort 'supervisory laag':
1 via PID modulair (voor de dynamische aanpassing), en
2 aanvullend met vooraf gedefinieerde bandbreedtes of hysterese
Een idee: Stel je bent met 2 / 3 personen in een ruimte en CO2 loopt op setpoint zorgt dat de Unit sneller acteert wil je dat er op basis van een bepaalde bandbreedte een fan speed voor die "trend" vastgehouden wordt om te voorkomen dat de unit continue aan het opspinnen en afspinnen is.

Heb wel eens de apps van andere partijen bekeken maar die lijken lang niet zo ver te gaan als wat wij hier bespreken dus dat is zeker motiverend!

Het slim aansturen is een heel lastig probleem. Blijkt ook omdat de standaard Orcon CO2 sturing bij mij niet lekker werkt. De systemen meten CO2, maar wat je eigenlijk nodig hebt is de CO2 productie. Aan de hand van de CO2 toename zou je moeten ventileren. Maar die is niet te meten, dus het beste wat je hebt is het huidige CO2 niveau. Lijkt mij erg moeilijk om een algoritme te bedenken die dit perfect doet. Maar om dichtbij perfectie te komen zou je de CO2 delta moeten nemen tussen 2 tijdstippen, en deze weer compenseren met hoeveel je al ventileert om een klein beetje te berekenen hoeveel mensen er in een ruimte zijn feitelijk. Maar zoals gezegd erg ingewikkeld dus kom je op systemen die met vertraging op toeren. Wat jullie nu doen is dan ook prima dat je alle parameters een beetje instelbaar maakt. Echter moet je best wel wat weten om dat allemaal in te stellen, en daarmee alleen voor prosumers. Vind het zelf wel lastig.

Wat betreft je vraag (als ik die goed begrijp) maar ik dacht gisteren nog eigenlijk mist er een belangrijke sensor in Ramses zelf. Ieder CO2 device zou een sensor moeten hebben die de laatst verstuurde 'fan demand' weergeeft. In 1-255 of percentage, maakt niet zoveel uit. Daarmee krijg je ook inzicht in wat je normale fysieke sensors doen. En het zou natuurlijk mooi zijn dat binnen ramses dan ook commands verzonden kunnen worden op die CO2 devices. Die sensor kan je wellicht ook maken in jullie integratie maar in Ramses is veel logischer want die kent ook echt alle devices. Misschien moet daarvoor ook wel een nieuwe device class CO2_REM worden geïntroduceerd. Als die sensors er zouden zijn, dan is in feite de fan rate in jullie integratie overbodig geworden. (vind het nu al een rare metric zoals eerder gezegd, het is maar 1 waarde voor de slechtste zone)

Ik heb overigens ook een paar netatmo devices maar die zijn voor CO2 nu eigenlijk overbodig sinds ik via Ramses nu die van Orcon ontvang.

[Wimpie70]

Ik ben bezig met het maken van een integratie die het installeren van cards, automations, entities, maar evt ook extra py-hooks, servicecalls of websockets voor .js wat gebruikersvriendeljker maakt. Althans, dat is het doel, het is nog niet helemaal af...
Deze 'ramses-extras' draait bovenop ramses RF.
Zogenaamde 'features' kunnen worden aan- en uitgezet, en worden dan automatisch geinstalleerd of verwijderd.
Als voorbeeld heb ik een hvac-card (WIP) in javascript. De card komt automatisch beschikbaar in dashboards, en je hoeft eigenlijk alleen maar de device te kiezen en de integratie doet de rest. Deze card gebruikt 2 extra entities (absolute humidity) die automatisch worden aangemaakt voor (door ramses RF) gevonden FAN devices.
De bound REM van deze FAN wordt gebruikt om berichten te verzenden. De commando's hiervoor zitten in de card gebakken, deze hoef je dus niet meer in Ramses RF config te zetten.
Een andere feature werkt samen met de card. Als je deze 'aan' zet, dan worden nog een paar entities gemaakt, samen met een automation. Deze 'dehumidifier' regelt de FAN als het relative vochtpercentage in huis te hoog is, maar alleen als de buitenlucht ook echt droger is...anders heeft het geen zin natuurlijk.
De automations is een template waarbij de verschillende entities per FAN worden ingevuld door de integratie.

Het systeem is zo opgezet dat andere 'features' relatief eenvoudig kunnen worden toegevoegd. Het lijkt me mooi om het uit te breiden, maar niet alleen met mijn eigen baksels.
Ik ben benieuwd wat jullie er van vinden...https://github.com/wimpie70/ramses_extras

[ebroerse]

JP1980 schreef op dinsdag 28 oktober 2025 @ 15:59:
[...]

Ik heb overigens ook een paar netatmo devices maar die zijn voor CO2 nu eigenlijk overbodig sinds ik via Ramses nu die van Orcon ontvang.

Leuke toepassingen! Ik heb het in de slaapkamer - 1 zone dus, en zonder Ramses RF - simpel gehouden met prima “fris” effect.
Meting met een Netatmo CO2, streefwaarde: 700 ppm, een “domme” buisventilator Ø150 met PWM toerenregeling 0-10V hangt aan een M5stack met ESPHome. Harder dan 80% mag hij niet toeren want dan wordt ik wakker. Besturing in stappen van 10% = 1V, overdag uit, begin van de nacht/slaap produceer je meer CO2.
Mijn “automatische” regeling simpel: boven de streefwaarde naar 70% optoeren, niet vaker dan elke 5 min. aanpassen, vlakt ook de metingen af. Zakt dan 40-50% tegen 03u. Je kunt dit dus in de praktijk “trimmen”. WTW beviel niet, want dat werd te warm.
Wel blij met de losse CO2 sensor, die kan je in de kamer een slimme plek geven. Ook best belangrijk hoe de luchtstroom door de kamer gaat: ik heb de afzuiging onder een kast vlakbij het bed, tegenover het aanvoerrooster. Als die luchtstroom niet goed door de kamer gaat (“kortsluiting”), heb je weinig aan de fan.


Hoop dat de grafiekjes jullie helpen om het niet té ingewikkeld te maken 😙

[immrmkw]

@JP1980, @homeautomate,

De error in het invoerveld kwam door de suggestie van Chatgpt. De cv.small_float gaat maar van 0 tot 1. Klaarblijkelijk had ik dit niet goed getest. Dit heb ik nu helemaal anders opgelost. Hopelijk werkt het ook op Home Assistant in het Nederlands.

Na heel lang zoeken uiteindelijk ook een bug gevonden bij het updaten van de zone-opties. Als hij bepaalde commando's al in zijn geheugen had staan, dan werden deze niet opnieuw toegevoegd aan de lijst en zag je nog de oude informatie.

Wanneer Ramses RF in de tussentijd opnieuw opstart, kon het voorkomen dat commando's waarvan de integratie dacht dat Ramses RF deze al kende niet gestuurd werden.

Ik ga weer een nieuwe development release maken die jullie kunnen testen. 2.2.0-dev.

@JP1980, dat is feitelijk wat de ventilatiecontroller nu doet. Niet precies op de fysische manier die jij nu omschrijft. Maar een integrator integreert de fout waardoor je over tijd een baseline ventilatie krijgt die gelijk is aan de toevoeging van CO2 in de ruimte. Daarnaast hebben sommige systemen nog een afgeleide term. Deze kijkt ook naar de toename van je fout en probeert daar feedforward al wat voor te compenseren. Deze term heb ik achterwege gelaten omdat dit instabiel gedrag kan veroorzaken.

Wat trouwens misschien ook nog kan, is dat de ventilatiecontroller tegelijkertijd ook berichten stuurt naar je ventilator, zodat je de snelheid kunt overrulen.

[ Voor 5% gewijzigd door immrmkw op 28-10-2025 21:39 ]