Het grote Orcon HRC / WtW topic

[ebroerse]

Pinjataaa schreef op woensdag 27 mei 2026 @ 10:19:
Het is mij inmiddels gelukt met Ramses Extra, daarin zit een handige debugger en packet log explorer die je op een dashboard kan plaatsen. Zonder dit fijne tooltje was het nooit gelukt, bedankt!

Hiermee lukte het om op een overzichtelijke manier de pakketjes in te zien met source en ontvanger. Gesorteerd op datum van nieuw naar oud.

Zoals de HA System Log vlak na de opstart al vermeldt, is het aangeraden om in Ramses RF config het schuifje Filter alleen bekendede apparaten in te schakelen, zodat je alleen jouw eigen apparaten ziet die in je Known List staan. Extras is prachtig, maar dit is echt de basis. Als je 73 devices ziet, en er zelf geen 73 hebt, dan staat de rest wss bij de buren.

Wat het adres is van jouw fan? Als je de stekker er ecen uittrekt, zullen de bijbehorende sensors op unavailable springen. Zie verder de Wiki.

[Pinjataaa]

Thanks, het is inmiddels gelukt maar het werkte niet zoals je schetst.

Ik heb het vinkje aangevinkt dat jij alleen de knows devices eruit filtert, maar in Ramses heb in alsnog 80 devices in de buurt die het met alle entities toevoegt.

Mijn yaml bevat maar 4 apparaten; mijn FAN, CO2, Fysieke REM en fictieve REM.

Het uitschakelen van de WTW was een heel fijne tip geweest haha, daar heb ik totaal niet aan gedacht Had mij veel kopzorgen kunnen schelen.

Moet toegeven dat ik een ontzettende noob ben, waardoor de wiki en TS in het begin erg lastig te begrijpen was, maar dat lag echt aan mij. Nu ik ermee geklungeld heb is het heel logisch wat er staat.

edit:
voor de geïnteresseerden, ik heb de hub verwijderd en opnieuw toegevoegd met al m’n instellingen en nu heb ik wel gefilterde apparaten. Het was denk ik een bugje

[ Voor 12% gewijzigd door Pinjataaa op 29-05-2026 16:19 ]

[posttoast]

Ik ben hier lekker aan het prutsen met de bekende IndaloTech stick en heb die inmiddels aan Home Assistant gekoppeld Ik kan nu ook mijn Orcon WTW uitlezen, superfijn.

Volgende stap is het bedienen, en daarvoor volg ik de stappen uit de TS om te koppelen. Ik krijg alleen een foutmelding: "Failed to perform the action ramses_cc.bind_device. Unknown error". Geen idee wat ik hieraan moet doen.

Ik gebruik als device-id het id uit de TS (want waarom niet) en voer dus dit uit in de developer tools:

YAML:

service: ramses_cc.bind_device
data:
  device_id: 29:162275
  offer:
    "22F1":
    "22F3":
    "10E0":
  device_info: " I --- 29:162275 63:262142 --:------ 10E0 038 000001C894030167FFFFFFFFFFFF1B0807E4564D492D313557534A3533000000000000000000"

Ik zie ergens iets over het hoofd, maar ik kom er niet uit. Tips?

Edit, ik ben het toch maar anders gaan aanpakken en heb met MQTT-explorer getracht het id van mijn badkamer-remote te achterhalen. Volgens mij is dat gelukt. Ik wil die dus gaan gebruiken en niet een "nieuwe" remote koppelen. Ik heb nu deze code in mijn Ramses known device ID's staan:

YAML:

"29:172691":
  _note: Orcon 15RF
  class: REM
  commands:
    auto: " I --- 29:172691 32:152794 --:------ 22F1 003 000407"
    auto2: " I --- 29:172691 32:152794 --:------ 22F1 003 000507"
    away: " I --- 29:172691 32:152794 --:------ 22F1 003 000007"
    boost: " I --- 29:172691 32:152794 --:------ 22F1 003 000607"
    bypass_auto: " W --- 29:172691 32:152794 --:------ 22F7 003 00FFEF"
    bypass_close: " W --- 29:172691 32:152794 --:------ 22F7 003 0000EF"
    bypass_open: " W --- 29:172691 32:152794 --:------ 22F7 003 00C8EF"
    disable: " I --- 29:172691 32:152794 --:------ 22F1 003 000707"
    high: " I --- 29:172691 32:152794 --:------ 22F1 003 000307"
    high_15: " I --- 29:172691 32:152794 --:------ 22F3 007 00120F03040404"
    high_30: " I --- 29:172691 32:152794 --:------ 22F3 007 00121E03040404"
    high_60: " I --- 29:172691 32:152794 --:------ 22F3 007 00123C03040404"
    low: " I --- 29:172691 32:152794 --:------ 22F1 003 000107"
    med_60: " I --- 29:172691 32:152794 --:------ 22F3 007 00123C02040404"
    medium: " I --- 29:172691 32:152794 --:------ 22F1 003 000207"
    request10D0: RQ --- 18:203011 32:152794 --:------ 10D0 001 00
    request31DA: RQ --- 29:172691 32:152794 --:------ 31DA 001 00
    reset_filter: " W --- 29:172691 32:152794 --:------ 10D0 002 00FF"
  faked: true
"32:152794":
  class: FAN

Maar, als ik nu dit doe gebeurt er helemaal niets:

YAML:

action: remote.send_command
data:
    command: high
    entity_id: remote.29_172691

Zie ik iets over het hoofd? Ik weet inmiddels niet meer zo goed waar ik verder kan debuggen.

[ Voor 53% gewijzigd door posttoast op 11-06-2026 15:49 ]

[JJJ]

posttoast schreef op donderdag 11 juni 2026 @ 14:35:
Ik ben hier lekker aan het prutsen met de bekende IndaloTech stick en heb die inmiddels aan Home Assistant gekoppeld Ik kan nu ook mijn Orcon WTW uitlezen, superfijn.

Volgende stap is het bedienen, en daarvoor volg ik de stappen uit de TS om te koppelen. Ik krijg alleen een foutmelding: "Failed to perform the action ramses_cc.bind_device. Unknown error". Geen idee wat ik hieraan moet doen.

Ik gebruik als device-id het id uit de TS (want waarom niet) en voer dus dit uit in de developer tools:

YAML:

service: ramses_cc.bind_device
data:
  device_id: 29:162275
  offer:
    "22F1":
    "22F3":
    "10E0":
  device_info: " I --- 29:162275 63:262142 --:------ 10E0 038 000001C894030167FFFFFFFFFFFF1B0807E4564D492D313557534A3533000000000000000000"

Ik zie ergens iets over het hoofd, maar ik kom er niet uit. Tips?

Edit, ik ben het toch maar anders gaan aanpakken en heb met MQTT-explorer getracht het id van mijn badkamer-remote te achterhalen. Volgens mij is dat gelukt. Ik wil die dus gaan gebruiken en niet een "nieuwe" remote koppelen. Ik heb nu deze code in mijn Ramses known device ID's staan:

YAML:

"29:172691":
  _note: Orcon 15RF
  class: REM
  commands:
    auto: " I --- 29:172691 32:152794 --:------ 22F1 003 000407"
    auto2: " I --- 29:172691 32:152794 --:------ 22F1 003 000507"
    away: " I --- 29:172691 32:152794 --:------ 22F1 003 000007"
    boost: " I --- 29:172691 32:152794 --:------ 22F1 003 000607"
    bypass_auto: " W --- 29:172691 32:152794 --:------ 22F7 003 00FFEF"
    bypass_close: " W --- 29:172691 32:152794 --:------ 22F7 003 0000EF"
    bypass_open: " W --- 29:172691 32:152794 --:------ 22F7 003 00C8EF"
    disable: " I --- 29:172691 32:152794 --:------ 22F1 003 000707"
    high: " I --- 29:172691 32:152794 --:------ 22F1 003 000307"
    high_15: " I --- 29:172691 32:152794 --:------ 22F3 007 00120F03040404"
    high_30: " I --- 29:172691 32:152794 --:------ 22F3 007 00121E03040404"
    high_60: " I --- 29:172691 32:152794 --:------ 22F3 007 00123C03040404"
    low: " I --- 29:172691 32:152794 --:------ 22F1 003 000107"
    med_60: " I --- 29:172691 32:152794 --:------ 22F3 007 00123C02040404"
    medium: " I --- 29:172691 32:152794 --:------ 22F1 003 000207"
    request10D0: RQ --- 18:203011 32:152794 --:------ 10D0 001 00
    request31DA: RQ --- 29:172691 32:152794 --:------ 31DA 001 00
    reset_filter: " W --- 29:172691 32:152794 --:------ 10D0 002 00FF"
  faked: true
"32:152794":
  class: FAN

Maar, als ik nu dit doe gebeurt er helemaal niets:

YAML:

action: remote.send_command
data:
    command: high
    entity_id: remote.29_172691

Zie ik iets over het hoofd? Ik weet inmiddels niet meer zo goed waar ik verder kan debuggen.

Ik heb hier zelf ook naar gekeken en heb hetzelfde probleem. In de home assistant logging had ik wel een melding gezien over een gateway (HGI) die in de known devices zou moeten staan.
Daarmee verdween bij mij de bind_device foutmelding.
Maar ik heb mijn fake remote nog steeds niet succesvol kunnen koppelen (ook niet met herstarten WTW voor de koppelingsmodus).
Er zijn diverse stukjes code in omloop om de remote te koppelen, dit kan ook nog verschil maken.

[ebroerse]

posttoast schreef op donderdag 11 juni 2026 @ 14:35:
Ik ben hier lekker aan het prutsen met de bekende …

YAML:

action: remote.send_command
data:
    command: high
    entity_id: remote.29_172691

Zie ik iets over het hoofd? Ik weet inmiddels niet meer zo goed waar ik verder kan debuggen.

Dit lijkt een verouderd voorbeeld. Als je Ramses RF 0.57.0 gebruikt, maar ook in 0.56.x versies: maak een 1e voorbeeld in de HA app onder Ontwikkelaarshulpmiddelen in de Visuele Editor, en schakel voordat je het verstuurt de YAML modus in. Ik krijg dan zoiets:

YAML:

action: ramses_cc.send_command
data:
  command: boost
  num_repeats: 3
  delay_secs: 0.05
target:
  entity_id: remote.29_123456

Noor: Hoofd-/kleine letters in de naam van het commando zijn belangrijk.

Je moet in je Known List onder je FAN ook toevoegen:

bound: "adres_van_je_REM", bijv.:

bound: "29:123456"

zodat ramses_rf de link kan leggen waar het commando naartoe gestuurd moet worden.

[ Voor 3% gewijzigd door ebroerse op 11-06-2026 19:07 ]

[posttoast]

ebroerse schreef op donderdag 11 juni 2026 @ 19:04:
[...]

Dit lijkt een verouderd voorbeeld. Als je Ramses RF 0.57.0 gebruikt, maar ook in 0.56.x versies: maak een 1e voorbeeld in de HA app onder Ontwikkelaarshulpmiddelen in de Visuele Editor, en schakel voordat je het verstuurt de YAML modus in. Ik krijg dan zoiets:

YAML:

action: ramses_cc.send_command
data:
  command: boost
  num_repeats: 3
  delay_secs: 0.05
target:
  entity_id: remote.29_123456

Noor: Hoofd-/kleine letters in de naam van het commando zijn belangrijk.

Je moet in je Known List onder je FAN ook toevoegen:

bound: "adres_van_je_REM", bijv.:

bound: "29:123456"

zodat ramses_rf de link kan leggen waar het commando naartoe gestuurd moet worden.

Kijk, dat verklaart wellicht waarom het niet werkte. Helaas ben ik er nu alleen nog steeds niet, maar waarschijnlijk zie ik nu iets heel kleins/stoms over het hoofd. Zie jij hier iets geks?

Dit heb ik in mijn Known device ID's staan:

YAML:

"18:262143":
  class: HGI
"29:172691":
  _note: Orcon 15RF
  class: REM
  commands:
    auto: " I --- 29:172691 32:152794 --:------ 22F1 003 000407"
    auto2: " I --- 29:172691 32:152794 --:------ 22F1 003 000507"
    away: " I --- 29:172691 32:152794 --:------ 22F1 003 000007"
    boost: " I --- 29:172691 32:152794 --:------ 22F1 003 000607"
    bypass_auto: " W --- 29:172691 32:152794 --:------ 22F7 003 00FFEF"
    bypass_close: " W --- 29:172691 32:152794 --:------ 22F7 003 0000EF"
    bypass_open: " W --- 29:172691 32:152794 --:------ 22F7 003 00C8EF"
    disable: " I --- 29:172691 32:152794 --:------ 22F1 003 000707"
    high: " I --- 29:172691 32:152794 --:------ 22F1 003 000307"
    high_15: " I --- 29:172691 32:152794 --:------ 22F3 007 00120F03040404"
    high_30: " I --- 29:172691 32:152794 --:------ 22F3 007 00121E03040404"
    high_60: " I --- 29:172691 32:152794 --:------ 22F3 007 00123C03040404"
    low: " I --- 29:172691 32:152794 --:------ 22F1 003 000107"
    med_60: " I --- 29:172691 32:152794 --:------ 22F3 007 00123C02040404"
    medium: " I --- 29:172691 32:152794 --:------ 22F1 003 000207"
    request10D0: RQ --- 18:203011 32:152794 --:------ 10D0 001 00
    request31DA: RQ --- 29:172691 32:152794 --:------ 31DA 001 00
    reset_filter: " W --- 29:172691 32:152794 --:------ 10D0 002 00FF"
  faked: true
"32:152794":
  bound: "29:172691"
  class: FAN

En dit is het commando dat ik verstuur als test:

YAML:

action: ramses_cc.send_command
data:
  command: boost
  num_repeats: 3
  delay_secs: 0.05
target:
  entity_id: remote.29_172691

Nog even voor de zekerheid, deze stukjes zijn "uniform" toch, en niet afhankelijk van het id van mijn remote:

code:

22F1 003 000407

[ebroerse]

posttoast schreef op donderdag 11 juni 2026 @ 20:00:
[...]

Kijk, dat verklaart wellicht waarom het niet werkte. Helaas ben ik er nu alleen nog steeds niet, maar waarschijnlijk zie ik nu iets heel kleins/stoms over het hoofd. Zie jij hier iets geks?

Is deze remote id al gebind met je fan? Anders luistert hij gewoon niet. Dat er “bound:” staat in Ramses RF weet de fan niet.

Als hij bound/gekoppeld is, dan kun je één commando packet ook als send_packet actie versturen, dan test je het even direct. Hiervoor moet in je config > Geavanceerd wel de optie “Schakel send_packet service in” ingeschakeld zijn (is keurig NL ;-)

Nog even voor de zekerheid, deze stukjes zijn "uniform" toch, en niet afhankelijk van het id van mijn remote:

code:

22F1 003 000407

Dat klopt.

[posttoast]

ebroerse schreef op vrijdag 12 juni 2026 @ 13:45:
[...]

Is deze remote id al gebind met je fan? Anders luistert hij gewoon niet. Dat er “bound:” staat in Ramses RF weet de fan niet.

Als hij bound/gekoppeld is, dan kun je één commando packet ook als send_packet actie versturen, dan test je het even direct. Hiervoor moet in je config > Geavanceerd wel de optie “Schakel send_packet service in” ingeschakeld zijn (is keurig NL ;-)


[...]

Dat klopt.

Dank! De remote daar was het id van een bestaande (badkamer)-remote die al gekoppeld is. Maar ik heb even een paar stappen terug gedaan en heb Gemini even mee laten kijken (for better or for worse). Ik ben er helaas nog steeds niet, maar ik zal even vertellen wat ik gedaan heb.

In mijn System schema and known devices heb ik het volgende staan:

System schema(s):

YAML:

orphans_hvac:
  - "32:152794"
  - "37:016448"
  - "37:132953"
  - "37:094214"
  - "37:056185"

Known device IDs:

YAML:

"18:203011":
  _note: IndaloTech USB-stick
  class: HGI
"29:123456":
  _note: Virtuele HA remote (verzenden)
  class: REM
  commands:
    auto: " I --- 29:123456 32:152794 --:------ 22F1 003 000407"
    auto2: " I --- 29:123456 32:152794 --:------ 22F1 003 000507"
    away: " I --- 29:123456 32:152794 --:------ 22F1 003 000007"
    boost: " I --- 29:123456 32:152794 --:------ 22F1 003 000607"
    bypass_auto: " W --- 29:123456 32:152794 --:------ 22F7 003 00FFEF"
    bypass_close: " W --- 29:123456 32:152794 --:------ 22F7 003 0000EF"
    bypass_open: " W --- 29:123456 32:152794 --:------ 22F7 003 00C8EF"
    disable: " I --- 29:123456 32:152794 --:------ 22F1 003 000707"
    high: " I --- 29:123456 32:152794 --:------ 22F1 003 000307"
    high_15: " I --- 29:123456 32:152794 --:------ 22F3 007 00120F03040404"
    high_30: " I --- 29:123456 32:152794 --:------ 22F3 007 00121E03040404"
    high_60: " I --- 29:123456 32:152794 --:------ 22F3 007 00123C03040404"
    low: " I --- 29:123456 32:152794 --:------ 22F1 003 000107"
    med_60: " I --- 29:123456 32:152794 --:------ 22F3 007 00123C02040404"
    medium: " I --- 29:123456 32:152794 --:------ 22F1 003 000207"
    request10D0: RQ --- 18:203011 32:152794 --:------ 10D0 001 00
    request31DA: RQ --- 29:123456 32:152794 --:------ 31DA 001 00
    reset_filter: " W --- 29:123456 32:152794 --:------ 10D0 002 00FF"
  faked: true
"29:172691":
  _note: Remote badkamer 2 (Fysiek)
  class: REM
"32:152794":
  _note: WTW installatie
  bound: "29:123456"
  class: FAN
"37:016448":
  _note: CO2 Sensor Slaapkamer Eefje en Vincent
  class: CO2
"37:056185":
  _note: CO2 Sensor Slaapkamer Eline
  class: CO2
"37:094214":
  _note: CO2 Sensor Slaapkamer Ivar
  class: CO2
"37:132953":
  _note: CO2 Sensor Huiskamer
  class: CO2

Die 29:123456 heb ik dus zelf verzonnen.

Vervolgens ga ik in Home Assistant naar Developer Tools - Actions. Hier kies ik uit de lijst de actie "ramses_cc.bind_device" en vul ik de volgende yaml in:

YAML:

action: ramses_cc.bind_device
data:
  device_id: "29:123456"
  offer:
    22F1: "00"
    22F3: "00"
    "10E0": "67"
  device_info: " I --- 29:123456 63:262142 --:------ 10E0 038 000001C894030167FFFFFFFFFFFF1B0807E4564D492D313557534A3533000000000000000000"

Nu zet ik mijn WTW even uit, wacht ik 10 seconden, zet ik hem weer aan, wacht ik weer 5 seconden en klik ik op "Perform action". En dan krijg ik direct deze melding:

code:

Failed to perform the action ramses_cc.bind_device. Unknown error

Ik vraag me af of er überhaupt iets gebroadcast wordt, want zoals gezegd: ik krijg dit direct terug (zonder enige vertraging).

Ik doe waarschijnlijk ergens iets heel stoms en het is in mijn geval denk ik ook een gevalletje "de klok horen luiden maar niet weten waar de klepel hangt", dus ik hoop dat iemand me verder kan helpen. Verder werkt alles perfect: WTW-status uitlezen, CO2 sensors uitlezen, allemaal dikke pret.

[JJJ]

De virtuele remote moet ook in orphans_hvac zitten wat ik zo snel zie.

Bij mij is het zo gelukt, ook door ramses te updaten naar 0.57.0.

[posttoast]

JJJ schreef op vrijdag 12 juni 2026 @ 19:51:
De virtuele remote moet ook in orphans_hvac zitten wat ik zo snel zie.

Bij mij is het zo gelukt, ook door ramses te updaten naar 0.57.0.

Wis en waarachtig, na updaten naar 0.57 kreeg ik opeens geen foutmelding meer. Het leek dus gelukt. Maar, ik lijk hem nog steeds niet aan te kunnen sturen. Voor de zekerheid, dit commando klopt toch:

YAML:

action: remote.send_command
target:
  entity_id: remote.29_123456
data:
  command: high

Edit: bingo! Ik heb hem De entity ID was anders dan ik dacht, ik moest remote.rem_29_123456 hebben! Nu werkt het!!

Bedankt voor het meedenken

Edit 2: Nu ik alles aan de praat heb is het tijd om alle devices van de buren uit mijn lijst te gaan verwijderen. Ik heb dit topic al gezien hoe ik dat moet doen. Waar ik alleen nog over twijfel: ik heb nog één 15RF remote (uit de badkamer) die ik niet in mijn known id's heb staan. Is het nog nuttig om die toe te voegen? Of laat ik die lekker zitten?

[ Voor 35% gewijzigd door posttoast op 13-06-2026 00:33 ]

[Vaevictis_]

Beetje offtopic: Ik vond nog een licht gebruikte warmtewisselaar in de garage. Past dus in de Orcon HRC toestel. Mocht iemand interesse hebben voor een leuk prijsje is ie van jou.

[ Voor 50% gewijzigd door Vaevictis_ op 15-06-2026 19:41 ]

[posttoast]

Ik heb mijn Home Assistant integratie nu aardig op orde, het valt me alleen op dat de fan-info sensor nogal gekke resultaten geeft. Die springt vrij vaak heen en weer:



Die speed 3 temporary override zou natuurlijk veel meer stroom moeten gebruiken, maar dat gebeurt niet: hij verbruikt sinds 0800 uur vanmorgen (nadat iedereen klaar was met douchen ) consequent 27 watt, gewoon stand 2 dus.

Is dit gedrag bekend bij jullie?

[ebroerse]

posttoast schreef op dinsdag 16 juni 2026 @ 09:38:
Ik heb mijn Home Assistant integratie nu aardig op orde, het valt me alleen op dat de fan-info sensor nogal gekke resultaten geeft. Die springt vrij vaak heen en weer:

[Afbeelding]

Die speed 3 temporary override zou natuurlijk veel meer stroom moeten gebruiken, maar dat gebeurt niet: hij verbruikt sinds 0800 uur vanmorgen (nadat iedereen klaar was met douchen ) consequent 27 watt, gewoon stand 2 dus.

Is dit gedrag bekend bij jullie?

Als je de Ramses RF integratie gebruikt, kun je dan over deze tijdsperiode je HA system log en een ramses RF packet log delen? Mag als attachments (files droppen op edit venster) in een nieuw issue op github.ramses_cc

@posttoast Toont jouw fan af en toe wel de juiste stand bij ‘Fan Info’? Ik heb zelf o.a. een (niet-Orcon) HRU die nooit iets zinvols laat zien bij ‘Fan Info’, maar wel bij ‘Fan Mode’.

Zet je exactie model fan er ook even bij in het issue.

[ Voor 11% gewijzigd door ebroerse op 16-06-2026 15:26 ]

[Vaevictis_]

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

Als je de Ramses RF integratie gebruikt, kun je dan over deze tijdsperiode je HA system log en een ramses RF packet log delen? Mag als attachments (files droppen op edit venster) in een nieuw issue op github.ramses_cc

Mijn speed 3 zit op 230W heb afvoer huis zijde op 130mm buis aangesloten inblaas is 220mm dus heel veel weerstand.

[posttoast]

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

Als je de Ramses RF integratie gebruikt, kun je dan over deze tijdsperiode je HA system log en een ramses RF packet log delen? Mag als attachments (files droppen op edit venster) in een nieuw issue op github.ramses_cc

@posttoast Toont jouw fan af en toe wel de juiste stand bij ‘Fan Info’? Ik heb zelf o.a. een (niet-Orcon) HRU die nooit iets zinvols laat zien bij ‘Fan Info’, maar wel bij ‘Fan Mode’.

Zet je exactie model fan er ook even bij in het issue.

Ik heb een issue aangemaakt, ik hoop dat het zo voldoende info is

Mijn fan toont af en toe wel de juiste stand onder fan info, maar hij pendelt op bepaalde momenten heen en weer naar de verkeerde status. Fan Mode staat bij mij altijd op "Unknown".

Vaevictis_ schreef op dinsdag 16 juni 2026 @ 15:20:
[...]

Mijn speed 3 zit op 230W heb afvoer huis zijde op 130mm buis aangesloten inblaas is 220mm dus heel veel weerstand.

Misschien mis ik iets, maar is dit een reactie op mijn probleem? Indien ja, dan snap ik het niet

[ Voor 14% gewijzigd door posttoast op 16-06-2026 19:55 ]

[posttoast]

Nog een andere vraag: ik wil zelf een beetje aan de slag met de bypass. Ik vind dat de Orcon zelf nogal "conservatief" is in het opengooien. Als het binnen 23 graden is en buiten 19 of 20 graden (bijvoorbeeld in de nacht), dan wil ik dat de bypass open staat.

Er zijn met de Ramses extensie twee manieren om hem open te zetten:
test_bypass_valve_0_auto_1_open_2_closed op waarde 1 zetten of het bypass_open commando sturen met ramses_cc.send_command.

Wat is nu de logische keuze? Als ik bypass_open stuur, dan verandert er niets aan test_bypass_valve_0_auto_1_open_2_closed. Dus als die op 0 (auto) staat, gaat de Orcon dan zelf de bypass weer sluiten terwijl ik hem open wil hebben?

Mijn probleem zit hem vooral in het feit dat ik het fool-proof wil maken. Stel dat mijn Home Assistant of Ramses ESP stick de geest geeft, dan wil ik dat ik (met een powercycle van de Orcon) weer terug ga naar z'n eigen gedrag. En niet straks in de winter buitenlucht van 2 graden mijn huis in blaas

[Churitos]

Ik heb dezelfde 'frustratie'. Ik ben hiervoor in Node red een regeling aan het maken. Als die klaar is wil ik die wel delen. Op dit moment is het nog niet perfect.

Fail-proof werking weet ik niet. ik kijk er zelf af en toe naar, dus heb deze manier nog een stukje controle. Maar tot nu toe draait HA zeer stabiel, dus maak me niet zo'n zorgen.

[Wimpie70]

@posttoast Ik ben er eens op gaan letten en inderdaad gaat de bypass slecht open als je wilt koelen (lage comfort temperatuur) en het buiten wel kouder is.

Ik zal een nieuwe feature maken voor Ramses Extras zodat deze de sturing hiervan ook kan overnemen.

Het duurt overigens eventjes voordat de bypass helemaal open of gesloten is...

[Vaevictis_]

posttoast schreef op vrijdag 19 juni 2026 @ 19:47:
Nog een andere vraag: ik wil zelf een beetje aan de slag met de bypass. Ik vind dat de Orcon zelf nogal "conservatief" is in het opengooien. Als het binnen 23 graden is en buiten 19 of 20 graden (bijvoorbeeld in de nacht), dan wil ik dat de bypass open staat.

Er zijn met de Ramses extensie twee manieren om hem open te zetten:
test_bypass_valve_0_auto_1_open_2_closed op waarde 1 zetten of het bypass_open commando sturen met ramses_cc.send_command.

Wat is nu de logische keuze? Als ik bypass_open stuur, dan verandert er niets aan test_bypass_valve_0_auto_1_open_2_closed. Dus als die op 0 (auto) staat, gaat de Orcon dan zelf de bypass weer sluiten terwijl ik hem open wil hebben?

Mijn probleem zit hem vooral in het feit dat ik het fool-proof wil maken. Stel dat mijn Home Assistant of Ramses ESP stick de geest geeft, dan wil ik dat ik (met een powercycle van de Orcon) weer terug ga naar z'n eigen gedrag. En niet straks in de winter buitenlucht van 2 graden mijn huis in blaas

Dit is een bekend "probleem" met een laatste versie van de besturingsprint en de RF15 bedieningsdisplay kun je comfort temperatuur instellen. Helaas kan ik dat ook niet (testen) maar heb wel via modbus dat ik bypass kan automatiseren. Dus helaas niet standalone.

[RusFighter]

Je kunt onderstaande commandos gebruiken met HA + ramses. Het is wel belangrijk om de 37:168272 (REM) en 32:155471 (FAN) aan te passen naar jouw nummers.

Zoals boven gezegd kan je ook de conform temperatuur veranderen. Deze heb ik zelf op 20.5 staan ipv standaard 23 (of 22). Dit verander ik via de ramses integratie slider:

Bash:

bypass_auto: " W --- 37:168272 32:155471 --:------ 22F7 003 00FFEF"
bypass_close: " W --- 37:168272 32:155471 --:------ 22F7 003 0000EF"
bypass_open: " W --- 37:168272 32:155471 --:------ 22F7 003 00C8EF"

code:

action: remote.send_command
data:
  command: bypass_open
  entity_id: remote.37_168272

De logica van bypass is volgens vervlogen in "Orcon HRC RF modbus in ESPHome"

Bypass open:

afvoerlucht > conform temperatuur &
aanvoerlucht > 13 &
verschil tussen binnen & buiten > 5C

[ Voor 19% gewijzigd door RusFighter op 23-06-2026 09:54 ]

[posttoast]

Dank! Ik heb in Home Assistant iets geknutseld waardoor hij iets minder conservatief is: ik gooi de bypass al open als:

Indoor temperature >= 23
Outside temperature <= indoor temperature -1
Outside temperature >= 18

Ik check ook nog iets met luchtvochtigheid/condensatie, maar dat weet ik niet uit mijn hoofd. Ook heb ik er timings op gegooid, zodat ie niet continu gaat pendelen. Ik zal mijn Home Assistant code hier binnenkort even plakken, ben benieuwd wat jullie vinden. De eerst testnacht verliep in ieder geval prima.

[ Voor 7% gewijzigd door posttoast op 23-06-2026 13:36 ]

[Wimpie70]

@posttoast Mooi, dat het werkt.

Klein vraagje: waarom Outside temperature >= 18 ?

Ik check op >= 10 (default) met inderdaad ook een extra timing check tegen pendelen. Je zou helpers kunnen maken om het wat dynamischer in te kunnen stellen (als je dat al niet gedaan hebt). Ben benieuwd naar je oplossingen.

Ik ben zelf al aardig opgeschoten met de 'Temp Control' feature. Deze gaat samen werken met humidity control, CO2 checks en eventuele andere sensoren in het systeem (areas, DIY zones). Een 'controller/arbiter' checkt wat er werkelijk moet gebeuren, afhankelijk van de vraag en wat belangrijker is: CO2 > humidity > temp.

Ik ging eerst uit van de supply temperatuur, omdat de unit zelf ook wat warmte toevoegd, maar dat bleek toch niet zo handig in het grote geheel te passen.

Daarnaast check ik ook of het binnen te warm of juist te koud is (comfort temperatuur) met een instelbare marge van 1 graad zodat ik er niet meer naar hoef te kijken. Eventueel alleen de comfort temp aanpassen.

[posttoast]

Wimpie70 schreef op dinsdag 23 juni 2026 @ 15:02:
@posttoast Mooi, dat het werkt.

Klein vraagje: waarom Outside temperature >= 18 ?

Omdat ik jokte realiseer ik me nu Die check heb ik helemaal niet, ik heb wel een condens-marge erop zitten.

Ik check op >= 10 (default) met inderdaad ook een extra timing check tegen pendelen. Je zou helpers kunnen maken om het wat dynamischer in te kunnen stellen (als je dat al niet gedaan hebt). Ben benieuwd naar je oplossingen.

Nee, nog geen helpers, ik heb het nu vooral hacky-schmacky erin hangen als test. Netjes maken is de volgende stap

Ik ben zelf al aardig opgeschoten met de 'Temp Control' feature. Deze gaat samen werken met humidity control, CO2 checks en eventuele andere sensoren in het systeem (areas, DIY zones). Een 'controller/arbiter' checkt wat er werkelijk moet gebeuren, afhankelijk van de vraag en wat belangrijker is: CO2 > humidity > temp.

Ik ging eerst uit van de supply temperatuur, omdat de unit zelf ook wat warmte toevoegd, maar dat bleek toch niet zo handig in het grote geheel te passen.

Daarnaast check ik ook of het binnen te warm of juist te koud is (comfort temperatuur) met een instelbare marge van 1 graad zodat ik er niet meer naar hoef te kijken. Eventueel alleen de comfort temp aanpassen.

Klinkt ook allemaal wel tof

[Wimpie70]

Die test op minimale buitentemperatuur is eigenlijk alleen bedoeld tegen vrieskou (beetje ruim), maar een condensmarge is zeker een goed idee

[RusFighter]

Ik ben wel benieuwd wat voor "verkoelend" effect de WTW ventilatie heeft. Heb op diverse plaatsen gelezen dat het nauwelijks koelt. Grootste nadeel van mijn WTW unit (Orcon OptiAir), maar volgens mij relevant aan alle orcon units, is dat als bypass open staat, de afzuigende lucht vanuit de woning niet meer door de filter heen gaat waardoor je uitblaasventilator natuurlijk sneller vies/vervuild raakt. Vandaar dat ik persoonlijk niet te aggresief ben met het openen van bypass.

[posttoast]

Wimpie70 schreef op dinsdag 23 juni 2026 @ 15:12:
Die test op minimale buitentemperatuur is eigenlijk alleen bedoeld tegen vrieskou (beetje ruim), maar een condensmarge is zeker een goed idee

Dit is de sensor die ik gemaakt heb (in samenwerking met Claude en Gemini, de em-dashes verraden het al een beetje ):

YAML:

- sensor:
  - name: "Bypass Smart oordeel"
    unique_id: bypass_smart_oordeel
    state: >
      {% set mode = states('input_select.bypass') %}
      {% if mode == 'Auto' %}
        auto — WTW beslist zelf
      {% elif mode == 'Open' %}
        open — handmatig
      {% elif mode == 'Dicht' %}
        dicht — handmatig
      {% elif mode == 'Smart' %}
        {# ── Sources ── #}
        {% set indoor       = states('sensor.orcon_wtw_indoor_temperature') | float(none) %}
        {% set outdoor      = states('sensor.orcon_wtw_outdoor_temperature') | float(none) %}   {# ← MVHR outdoor intake sensor #}
        {% set rh           = states('sensor.orcon_wtw_indoor_humidity')     | float(none) %}
        {% set supply       = states('sensor.orcon_wtw_supply_temperature')  | float(none) %}
        {% set bypass_pos   = states('sensor.orcon_wtw_bypass_positie')      | float(none) %}
        {% set cooling_mode = states('sensor.autotemp_cooling_mode') == '1' %}

        {# ── Thresholds (tunable) ── #}
        {% set upper_threshold     = 23   %}   {# indoor above this → cooling needed, free cooling allowed #}
        {% set lower_threshold     = 20   %}   {# indoor below this → overcooling, close bypass #}
        {% set cooling_margin      = 1.5  %}   {# free cooling only if outdoor <= indoor - this #}
        {% set small_margin        = 0.5  %}   {# outdoor above (indoor - this) → not cool enough #}
        {% set condensation_margin = 1    %}   {# PREDICTIVE: do not open if outdoor <= dew_point + this #}
        {% set supply_margin       = 1    %}   {# SAFETY NET: close if supply < dew_point + this #}

        {# ── Magnus-Tetens Coefficients (for dew point) ── #}
        {% set m_a = 17.625 %}
        {% set m_b = 243.04 %}

        {% if indoor is none or outdoor is none or rh is none or bypass_pos is none %}
          {% set hold = 'open' if (bypass_pos is not none and bypass_pos > 50) else 'dicht' %}
          {{ hold }} — gegevens onbekend (vasthouden)
        {% else %}
          {% set current_state = 'open' if bypass_pos > 50 else 'dicht' %}
          {# Dew point via Magnus on MVHR return air (indoor + RH) #}
          {% set g = (m_a * indoor / (m_b + indoor)) + log(rh / 100) %}
          {% set dew_point = m_b * g / (m_a - g) %}
          {% if not cooling_mode %}
            dicht — geen koelmodus
          {% elif indoor < lower_threshold %}
            dicht — overkoeling
          {% elif current_state == 'open' and supply is not none and supply < (dew_point + supply_margin) %}
            dicht — condens (inblaas te koud)
          {% elif outdoor <= (dew_point + condensation_margin) %}
            dicht — condens-bescherming
          {% elif indoor > upper_threshold and outdoor < (indoor - cooling_margin) %}
            open — vrijkoelen
          {% elif outdoor > (indoor - small_margin) %}
            dicht — niet koel genoeg
          {% else %}
            {{ current_state }} — wachtstand (vasthouden)
          {% endif %}
        {% endif %}
      {% else %}
        auto — onbekende modus
      {% endif %}

Ik heb een automation die deze sensor gebruikt, maar die ben ik nog een beetje aan het opschonen. Dit geeft denk ik al een aardig beeld.

RusFighter schreef op dinsdag 23 juni 2026 @ 16:37:
Ik ben wel benieuwd wat voor "verkoelend" effect de WTW ventilatie heeft. Heb op diverse plaatsen gelezen dat het nauwelijks koelt. Grootste nadeel van mijn WTW unit (Orcon OptiAir), maar volgens mij relevant aan alle orcon units, is dat als bypass open staat, de afzuigende lucht vanuit de woning niet meer door de filter heen gaat waardoor je uitblaasventilator natuurlijk sneller vies/vervuild raakt. Vandaar dat ik persoonlijk niet te aggresief ben met het openen van bypass.

Misschien is het psychisch, maar ik voel een (relatief) koele bries door mijn slaapkamer gaan als 's nachts de bypass open staat. Er komt lucht van (bijvoorbeeld) 21 graden uit mijn inblaasventielen in plaats van 24 graden.

Het verbaast me wat je zegt over die filters, dat klinkt helemaal niet handig inderdaad en dat was mij niet bekend. Waarom filtert hij de lucht alleen maar als hij door de warmtewisselaar gaat?

[RusFighter]

posttoast schreef op dinsdag 23 juni 2026 @ 16:52:
[...]

Dit is de sensor die ik gemaakt heb (in samenwerking met Claude en Gemini, de em-dashes verraden het al een beetje ):

YAML:

- sensor:
  - name: "Bypass Smart oordeel"
    unique_id: bypass_smart_oordeel
    state: >
      {% set mode = states('input_select.bypass') %}
      {% if mode == 'Auto' %}
        auto — WTW beslist zelf
      {% elif mode == 'Open' %}
        open — handmatig
      {% elif mode == 'Dicht' %}
        dicht — handmatig
      {% elif mode == 'Smart' %}
        {# ── Sources ── #}
        {% set indoor       = states('sensor.orcon_wtw_indoor_temperature') | float(none) %}
        {% set outdoor      = states('sensor.orcon_wtw_outdoor_temperature') | float(none) %}   {# ← MVHR outdoor intake sensor #}
        {% set rh           = states('sensor.orcon_wtw_indoor_humidity')     | float(none) %}
        {% set supply       = states('sensor.orcon_wtw_supply_temperature')  | float(none) %}
        {% set bypass_pos   = states('sensor.orcon_wtw_bypass_positie')      | float(none) %}
        {% set cooling_mode = states('sensor.autotemp_cooling_mode') == '1' %}

        {# ── Thresholds (tunable) ── #}
        {% set upper_threshold     = 23   %}   {# indoor above this → cooling needed, free cooling allowed #}
        {% set lower_threshold     = 20   %}   {# indoor below this → overcooling, close bypass #}
        {% set cooling_margin      = 1.5  %}   {# free cooling only if outdoor <= indoor - this #}
        {% set small_margin        = 0.5  %}   {# outdoor above (indoor - this) → not cool enough #}
        {% set condensation_margin = 1    %}   {# PREDICTIVE: do not open if outdoor <= dew_point + this #}
        {% set supply_margin       = 1    %}   {# SAFETY NET: close if supply < dew_point + this #}

        {# ── Magnus-Tetens Coefficients (for dew point) ── #}
        {% set m_a = 17.625 %}
        {% set m_b = 243.04 %}

        {% if indoor is none or outdoor is none or rh is none or bypass_pos is none %}
          {% set hold = 'open' if (bypass_pos is not none and bypass_pos > 50) else 'dicht' %}
          {{ hold }} — gegevens onbekend (vasthouden)
        {% else %}
          {% set current_state = 'open' if bypass_pos > 50 else 'dicht' %}
          {# Dew point via Magnus on MVHR return air (indoor + RH) #}
          {% set g = (m_a * indoor / (m_b + indoor)) + log(rh / 100) %}
          {% set dew_point = m_b * g / (m_a - g) %}
          {% if not cooling_mode %}
            dicht — geen koelmodus
          {% elif indoor < lower_threshold %}
            dicht — overkoeling
          {% elif current_state == 'open' and supply is not none and supply < (dew_point + supply_margin) %}
            dicht — condens (inblaas te koud)
          {% elif outdoor <= (dew_point + condensation_margin) %}
            dicht — condens-bescherming
          {% elif indoor > upper_threshold and outdoor < (indoor - cooling_margin) %}
            open — vrijkoelen
          {% elif outdoor > (indoor - small_margin) %}
            dicht — niet koel genoeg
          {% else %}
            {{ current_state }} — wachtstand (vasthouden)
          {% endif %}
        {% endif %}
      {% else %}
        auto — onbekende modus
      {% endif %}

Ik heb een automation die deze sensor gebruikt, maar die ben ik nog een beetje aan het opschonen. Dit geeft denk ik al een aardig beeld.


[...]

Misschien is het psychisch, maar ik voel een (relatief) koele bries door mijn slaapkamer gaan als 's nachts de bypass open staat. Er komt lucht van (bijvoorbeeld) 21 graden uit mijn inblaasventielen in plaats van 24 graden.

Het verbaast me wat je zegt over die filters, dat klinkt helemaal niet handig inderdaad en dat was mij niet bekend. Waarom filtert hij de lucht alleen maar als hij door de warmtewisselaar gaat?

Ik heb geen idee waarom het zo ontworpen is, maar de klep zit voor de filter...

[posttoast]

RusFighter schreef op dinsdag 23 juni 2026 @ 16:57:
[...]

Ik heb geen idee waarom het zo ontworpen is, maar de klep zit voor de filter...

Heb je daar documentatie van? Volgens Gemini is dat niet het geval namelijk. En AI liegt nooit

[Vaevictis_]

RusFighter schreef op dinsdag 23 juni 2026 @ 16:37:
Ik ben wel benieuwd wat voor "verkoelend" effect de WTW ventilatie heeft. Heb op diverse plaatsen gelezen dat het nauwelijks koelt. Grootste nadeel van mijn WTW unit (Orcon OptiAir), maar volgens mij relevant aan alle orcon units, is dat als bypass open staat, de afzuigende lucht vanuit de woning niet meer door de filter heen gaat waardoor je uitblaasventilator natuurlijk sneller vies/vervuild raakt. Vandaar dat ik persoonlijk niet te aggresief ben met het openen van bypass.

Bij mij gaat ie nu rond 3 uur open en om 7 uur weer dicht

[RusFighter]

posttoast schreef op dinsdag 23 juni 2026 @ 16:58:
[...]

Heb je daar documentatie van? Volgens Gemini is dat niet het geval namelijk. En AI liegt nooit

Als je de afvoerleiding vanuit de woning (bij de unit) lost haalt, zie je de filter en de klep zitten. Voor mij unit zit de klep in de rode cirkel

Ik heb toen der tijd volgens mij ook de handleiding van maxcoform opgezocht om te zien of zelfde constructie heeft. Als ik me niet vergis zat de klep ook voor de filter

[posttoast]

Ik geloof dat ik het niet helemaal snap dan, maar het klepje zit toch ná het filter? Dat is toch dat ding waar precies de rechterkant van je getekende cirkel doorheen loopt? Vlak na het filter dus.

Edit: in de groene cirkel bedoel ik:

[ Voor 50% gewijzigd door posttoast op 23-06-2026 18:08 ]

[RusFighter]

posttoast schreef op dinsdag 23 juni 2026 @ 18:06:
Ik geloof dat ik het niet helemaal snap dan, maar het klepje zit toch ná het filter? Dat is toch dat ding waar precies de rechterkant van je getekende cirkel doorheen loopt? Vlak na het filter dus.

Edit: in de groene cirkel bedoel ik:

[Afbeelding]

Helaas zit de klep daar dus niet, maar op volgende positie(groen). Afzuigende lucht volgt blauwe lijn als de klep open is

[posttoast]

RusFighter schreef op dinsdag 23 juni 2026 @ 18:16:
[...]

Helaas zit de klep daar dus niet, maar op volgende positie(groen). Afzuigende lucht volgt blauwe lijn dus als de klep open is

[Afbeelding]

Oh, dat is wel stom ontworpen dan...

[Wimpie70]

Ramses Extras 0.20.0 is beschikbaar, inclusief de nieuwe Temperature Control (bypass) feature.

Zie ook de wiki.

[ Voor 9% gewijzigd door Wimpie70 op 23-06-2026 19:06 ]

[posttoast]

Wimpie70 schreef op dinsdag 23 juni 2026 @ 19:06:
Ramses Extras 0.20.0 is beschikbaar, inclusief de nieuwe Temperature Control (bypass) feature.

Zie ook de wiki.

Cool Doe je hierin ook iets met condens-bescherming?

[Wimpie70]

Nog niet specifiek. Wel krijgt de humidity control voorrang

Ik zal er nog eens over denken.

[JJJ]

Wimpie70 schreef op dinsdag 23 juni 2026 @ 19:06:
Ramses Extras 0.20.0 is beschikbaar, inclusief de nieuwe Temperature Control (bypass) feature.

Zie ook de wiki.

Bedankt, ik heb deze geinstalleerd (ook samen met de hvac fan card).
Echter, deze hvac fan card (en de controle van de fan control) werken niet bij mij. Ik krijg in het geheel geen waardes.

In de ha core logs zie ik ook het volgende:

2026-06-23 21:28:52.602 INFO (MainThread) [homeassistant.components.websocket_api.http.connection] [139919768465344] Received unknown command: ramses_extras/ramses_debugger/traffic/subscribe_stats
2026-06-23 21:28:52.770 INFO (MainThread) [homeassistant.components.websocket_api.http.connection] [139919768465344] Received unknown command: ramses_extras/ramses_debugger/traffic/get_stats

Maar ook veel

026-06-23 21:28:40.279 INFO (MainThread) [custom_components.ramses_extras.framework.helpers.ramses_commands] Sending Ramses command to 32:136723: 31DA Request 31DA status
2026-06-23 21:28:40.281 INFO (MainThread) [ramses_tx.transport.mqtt] mq Tx: {"msg": "RQ --- 29:123456 32:136723 --:------ 31DA 001 00"}
2026-06-23 21:28:40.418 INFO (MainThread) [ramses_tx.protocol.base] Recv'd: 000 RQ --- 29:123456 32:136723 --:------ 31DA 001 00
2026-06-23 21:28:40.452 INFO (MainThread) [custom_components.ramses_extras.features.default.services] REM packet received: src=None dst=None code=31DA payload=00 verb=RQ
2026-06-23 21:28:40.456 INFO (MainThread) [ramses_rf.dispatcher] || 29:123456 | 32:136723 | RQ | unknown_31DA | 00 || {}
2026-06-23 21:28:40.464 INFO (MainThread) [ramses_tx.protocol.base] Recv'd: 063 RP --- 32:136723 29:123456 --:------ 31DA 030 00EF007FFF3F3009BA0A8209690A256000C81822110000EFEF04C6076000
2026-06-23 21:28:40.488 INFO (MainThread) [custom_components.ramses_extras.features.default.services] REM packet received: src=None dst=None code=31DA payload=00EF007FFF3F3009BA0A8209690A256000C81822110000EFEF04C6076000 verb=RP
2026-06-23 21:28:40.489 INFO (MainThread) [custom_components.ramses_extras.features.default.services] Packet parser: code=31DA (type=str), payload=00EF007FFF3F3009BA0A8209690A256000C81822110000EFEF04C6076000 (type=str)
2026-06-23 21:28:40.489 INFO (MainThread) [custom_components.ramses_extras.features.default.services] Parser string payload: '00EF007FFF3F3009BA0A8209690A256000C81822110000EFEF04C6076000'
2026-06-23 21:28:40.489 INFO (MainThread) [custom_components.ramses_extras.features.default.services] Parser: unhandled code 31DA
2026-06-23 21:28:40.489 INFO (MainThread) [custom_components.ramses_extras.features.default.services] REM packet parsed: src=None dst=None command=None
2026-06-23 21:28:40.490 INFO (MainThread) [ramses_rf.dispatcher] || 32:136723 | 29:123456 | RP | unknown_31DA | 00 || {'hvac_id': '00', 'exhaust_fan_speed': 0.17, 'fan_info': 'auto', '_unknown_fan_info_flags': [0, 0, 0], 'air_quality': None, 'co2_level': None, 'indoor_humidity': 0.63, 'outdoor_humidity': 0.48, 'exhaust_temp': 24.9, 'supply_temp': 26.9, 'indoor_temp': 24.09, 'outdoor_temp': 25.97, 'speed_capabilities': ['low_med_h
igh', 'timer'], 'bypass_position': 1.0, 'supply_fan_speed': 0.085, 'remaining_mins': 0, 'post_heat': None, 'pre_heat': None, 'supply_flow': 12.22, 'exhaust_flow': 18.88, '_extra': '00'}
2026-06-23 21:28:40.505 INFO (MainThread) [custom_components.ramses_extras.framework.helpers.ramses_commands] Sending Ramses command to 32:136723: 10D0 Request system status
2026-06-23 21:28:40.506 INFO (MainThread) [ramses_tx.transport.mqtt] mq Tx: {"msg": "RQ --- 29:123456 32:136723 --:------ 10D0 001 00"}
2026-06-23 21:28:40.715 INFO (MainThread) [ramses_tx.protocol.base] Recv'd: 000 RQ --- 29:123456 32:136723 --:------ 10D0 001 00
2026-06-23 21:28:40.751 INFO (MainThread) [custom_components.ramses_extras.features.default.services] REM packet received: src=None dst=None code=10D0 payload=00 verb=RQ
2026-06-23 21:28:40.755 INFO (MainThread) [ramses_rf.dispatcher] || 29:123456 | 32:136723 | RQ | unknown_10D0 | 00 || {}
2026-06-23 21:28:40.762 INFO (MainThread) [ramses_tx.protocol.base] Recv'd: 063 RP --- 32:136723 29:123456 --:------ 10D0 006 005DB4670000
2026-06-23 21:28:40.786 INFO (MainThread) [custom_components.ramses_extras.features.default.services] REM packet received: src=None dst=None code=10D0 payload=005DB4670000 verb=RP
2026-06-23 21:28:40.786 INFO (MainThread) [custom_components.ramses_extras.features.default.services] Packet parser: code=10D0 (type=str), payload=005DB4670000 (type=str)
2026-06-23 21:28:40.786 INFO (MainThread) [custom_components.ramses_extras.features.default.services] Parser string payload: '005DB4670000'
2026-06-23 21:28:40.786 INFO (MainThread) [custom_components.ramses_extras.features.default.services] Parser: unhandled code 10D0
2026-06-23 21:28:40.786 INFO (MainThread) [custom_components.ramses_extras.features.default.services] REM packet parsed: src=None dst=None command=None

Wanneer ik in ramses zelf kijk krijg ik alle fan parameters wel te zien (die volgens mij meekomen met de 31DA messages e.d.
Weet jij wat er mis gaat?

[Wimpie70]

@jjj, i created an issue and looking into it now.

https://github.com/wimpie70/ramses_extras/issues/86

[posttoast]

RusFighter schreef op dinsdag 23 juni 2026 @ 18:16:
[...]

Helaas zit de klep daar dus niet, maar op volgende positie(groen). Afzuigende lucht volgt blauwe lijn als de klep open is

[Afbeelding]

Ik heb de stoute schoenen aangetrokken en het nagevraagd bij Orcon zelf (ik heb gevraagd naar de MaxComfort en de OptiAir):

Bedankt voor uw vraag over de bypass. Wanneer deze geopend wordt dan zal de lucht inderdaad niet meer door het filter gaan en rechtstreeks naar de exhaust.

Je wist het zelf natuurlijk al, maar je hebt inderdaad helemaal gelijk

[Wimpie70]

@jjj Je gebruikt waarschijnlijk een oudere versie van Ramses RF (voor 0.55.6) waarin nog de oude HA bus event 'ramses_cc_message' werd gebruikt.

Ik heb een fallback gemaakt voor deze versies. Niet live getest op oudere versies, maar zou moeten werken.

Geef even feedback of dit inderdaad nu werkt voor je.

versie 0.20.1 is beschikbaar

[RusFighter]

posttoast schreef op woensdag 24 juni 2026 @ 08:59:
[...]

Ik heb de stoute schoenen aangetrokken en het nagevraagd bij Orcon zelf (ik heb gevraagd naar de MaxComfort en de OptiAir):


[...]


Je wist het zelf natuurlijk al, maar je hebt inderdaad helemaal gelijk

Bedankt voor de navraag maar ik snap eerlijk gezegd niet waarom ze dit zo ontworpen hebben (wss iets met filter zo dicht mogelijk bij de warmtewisselaar). Jammer dat je geen verklaring bij gekregen hebt ;P

[posttoast]

RusFighter schreef op woensdag 24 juni 2026 @ 13:17:
[...]

Bedankt voor de navraag maar ik snap eerlijk gezegd niet waarom ze dit zo ontworpen hebben (wss iets met filter zo dicht mogelijk bij de warmtewisselaar). Jammer dat je geen verklaring bij gekregen hebt ;P

De verklaring heb ik vervolgens ook gevraagd, dáár heb ik nog geen antwoord op. Als ik die heb deel ik die uiteraard hier.

[Vaevictis_]

Ik vrees dat mijn hoofdprint aan het overlijden is, nu 3 dagen op rij foutcode 14 (I2C communication fault). Even zien wat Orcon zegt, aan de andere kant met een nieuw board ook weer nieuwe firmware. Print is nu bijna 7 jaar oud.

[posttoast]

posttoast schreef op woensdag 24 juni 2026 @ 13:18:
[...]

De verklaring heb ik vervolgens ook gevraagd, dáár heb ik nog geen antwoord op. Als ik die heb deel ik die uiteraard hier.

OK, ik heb reactie:

Bedankt voor uw vraag.
Deze kan net zo vies worden als de kanalen waardoor de lucht wordt aanzogen.
Daarom is het advies ook om elke 4 jaar de kanalen te laten reinigen door de installateur.

En ik kreeg er nog een plaatje bij:



Enerzijds een beetje een flauw antwoord, anderzijds heeft hij natuurlijk wel een punt: alle kanalen in huis worden ook niet gefilterd

Edit: ik zie nu dat ik twee keer per jaar de installateur langs moet laten komen om de behuizing te laten reinigen

[ Voor 6% gewijzigd door posttoast op 24-06-2026 15:19 ]

[RusFighter]

posttoast schreef op woensdag 24 juni 2026 @ 15:18:
[...]

OK, ik heb reactie:


[...]


En ik kreeg er nog een plaatje bij:

[Afbeelding]

Enerzijds een beetje een flauw antwoord, anderzijds heeft hij natuurlijk wel een punt: alle kanalen in huis worden ook niet gefilterd

Edit: ik zie nu dat ik twee keer per jaar de installateur langs moet laten komen om de behuizing te laten reinigen

Ik snap eerlijk gezegd de reactie niet. De filters zitten juist voor om de de motoren + warmtewisselaar te beschermen tegen stof/vuil. Dit is zelfde als het zeggen van "gebruik geen filters en doe maar vaker de kanalen schoonmaken en je huis stofzuigen"

[posttoast]

RusFighter schreef op woensdag 24 juni 2026 @ 15:47:
[...]

Ik snap eerlijk gezegd de reactie niet. De filters zitten juist voor om de de motoren + warmtewisselaar te beschermen tegen stof/vuil. Dit is zelfde als het zeggen van "gebruik geen filters en doe maar vaker de kanalen schoonmaken en je huis stofzuigen"

Maar het hele punt is dat, als de bypass open staat, de motor en warmtewisselaar gepasseerd worden toch? Alleen het exhaust kanaal wordt dan viezer. Maar de vraag is of dat erg is.

[RusFighter]

posttoast schreef op woensdag 24 juni 2026 @ 15:52:
[...]

Maar het hele punt is dat, als de bypass open staat, de motor en warmtewisselaar gepasseerd worden toch? Alleen het exhaust kanaal wordt dan viezer. Maar de vraag is of dat erg is.

Alleen de warmtewisselaar wordt gepasseerd. De motor kan je niet passeren, anders kan je niet afzuigen...

[posttoast]

RusFighter schreef op woensdag 24 juni 2026 @ 15:56:
[...]

Alleen de warmtewisselaar wordt gepasseerd. De motor kan je niet passeren, anders kan je niet afzuigen...

Touché

[JJJ]

Wimpie70 schreef op woensdag 24 juni 2026 @ 09:05:
@jjj Je gebruikt waarschijnlijk een oudere versie van Ramses RF (voor 0.55.6) waarin nog de oude HA bus event 'ramses_cc_message' werd gebruikt.

Ik heb een fallback gemaakt voor deze versies. Niet live getest op oudere versies, maar zou moeten werken.

Geef even feedback of dit inderdaad nu werkt voor je.

versie 0.20.1 is beschikbaar

Dank voor je snelle reactie. Ik zit op Ramses RF 0.57.1 en Ramses Extras 0.20.1 (heb geupdate na je bericht). Ik stond hiervoor (met de error op 0.57.0 en 0.20.0).

Oorspronkelijk heb ik wel 0.55 geinstalleerd gehad bij de verse installatie van mijn HAOS dus misschien gaat er iets mis met de update? Ik heb van 0.55 meteen een nieuwe versie gedownload naar 0.57 maar misschien is dat niet helemaal clean gegaan?

Helaas krijg ik nog steeds geen waarden te zien in de HVAC fan card. Jammer, ook omdat de temp control (die ik graag wil gebruiken met dit weer) dan ook nog niet werkt.

De errors die ik krijg zijn als volgt (met bovenstaande versienummers):

2026-06-24 18:41:06.088 INFO (MainThread) [ramses_tx.protocol.base] Recv'd: 065 RP --- 32:136723 29:123456 --:------ 31DA 030 00EF007FFF3F430D020A5A09F60CDD6000001822220000EFEF07B4074500
2026-06-24 18:41:06.109 INFO (MainThread) [custom_components.ramses_extras.features.default.services] REM packet received: src=32:136723 dst=29:123456 code=31DA payload=00EF007FFF3F430D020A5A09F60CDD6000001822220000EFEF07B4074500 verb=RP
2026-06-24 18:41:06.110 INFO (MainThread) [custom_components.ramses_extras.features.default.services] Packet parser: code=31DA (type=str), payload=00EF007FFF3F430D020A5A09F60CDD6000001822220000EFEF07B4074500 (type=str)
2026-06-24 18:41:06.110 INFO (MainThread) [custom_components.ramses_extras.features.default.services] Parser string payload: '00EF007FFF3F430D020A5A09F60CDD6000001822220000EFEF07B4074500'
2026-06-24 18:41:06.110 INFO (MainThread) [custom_components.ramses_extras.features.default.services] Parser: unhandled code 31DA
2026-06-24 18:41:06.110 INFO (MainThread) [custom_components.ramses_extras.features.default.services] REM packet parsed: src=32:136723 dst=29:123456 command=None
2026-06-24 18:41:06.111 INFO (MainThread) [ramses_rf.dispatcher] || 32:136723 | 29:123456 | RP | unknown_31DA | 00 || {'hvac_id': '00', 'exhaust_fan_speed': 0.17, 'fan_info': 'auto', '_unknown_fan_info_flags': [0, 0, 0], 'air_quality': None, 'co2_level': None, 'indoor_humidity': 0.63, 'outdoor_humidity': 0.67, 'exhaust_temp': 33.3, 'supply_temp': 26.5, 'indoor_temp': 25.5, 'outdoor_temp': 32.93, 'speed_capabilities': ['low_med_high', 'timer'], 'bypass_position': 0.0, 'supply_fan_speed': 0.17, 'remaining_mins': 0, 'post_heat': None, 'pre_heat': None, 'supply_flow': 19.72, 'exhaust_flow': 18.61, '_extra': '00'}
2026-06-24 18:41:06.153 INFO (MainThread) [custom_components.ramses_extras.framework.helpers.ramses_commands] Sending Ramses command to 32:136723: 10D0 Request system status
2026-06-24 18:41:06.155 INFO (MainThread) [ramses_tx.transport.mqtt] mq Tx: {"msg": "RQ --- 29:123456 32:136723 --:------ 10D0 001 00"}
2026-06-24 18:41:06.310 INFO (MainThread) [ramses_tx.protocol.base] Recv'd: 000 RQ --- 29:123456 32:136723 --:------ 10D0 001 00
2026-06-24 18:41:06.361 INFO (MainThread) [custom_components.ramses_extras.features.default.services] REM packet received: src=29:123456 dst=32:136723 code=10D0 payload=00 verb=RQ
2026-06-24 18:41:06.366 INFO (MainThread) [ramses_rf.dispatcher] || 29:123456 | 32:136723 | RQ | unknown_10D0 | 00 || {}
2026-06-24 18:41:06.367 INFO (MainThread) [ramses_tx.protocol.base] Recv'd: 066 RP --- 32:136723 29:123456 --:------ 10D0 006 005DB4670000
2026-06-24 18:41:06.391 INFO (MainThread) [custom_components.ramses_extras.features.default.services] REM packet received: src=32:136723 dst=29:123456 code=10D0 payload=005DB4670000 verb=RP
2026-06-24 18:41:06.391 INFO (MainThread) [custom_components.ramses_extras.features.default.services] Packet parser: code=10D0 (type=str), payload=005DB4670000 (type=str)
2026-06-24 18:41:06.391 INFO (MainThread) [custom_components.ramses_extras.features.default.services] Parser string payload: '005DB4670000'
2026-06-24 18:41:06.392 INFO (MainThread) [custom_components.ramses_extras.features.default.services] Parser: unhandled code 10D0

Ook errors als:

2026-06-24 18:41:05.961 INFO (MainThread) [homeassistant.components.websocket_api.http.connection] [139716839405056] Received unknown command: ramses_extras_card_refresh

Laat maar weten als je verdere info kan gebruiken voor het debuggen...!

[Wimpie70]

@JJJ , Jammer dat je nieuwe problemen bent tegengekomen. Ik heb een nieuwe issue gemaakt (https://github.com/wimpie70/ramses_extras/issues/88) en zal het onderzoeken. Als je nog meer problemen tegenkomt is het handig om zelf een issue aan te maken op github.

[Wimpie70]

0.20.3 is beschikbaar met bugfixes en dauwpunt protectie (optioneel). Eerdere versies kunnen een fout bevatten die je systeem langzaam kan maken.

Als de bypass open staat werkt de WTW eigenlijk als een gewone (balans) ventilator. Ik verwacht dat condensatie alleen een probleem is met koelen en binnen hoge temperaturen, hoge vochtigheid en slecht geisoleerde kanalen. Maar deze situatie kan voorkomen.

Ik heb het voor de liefhebbers toegevoegd als optie.

[Wimpie70]

Ik had problemen met het verlies van connectie met de server/trage UI en was bang dat het aan RF or _extras lag, Maar waarschijnlijk kwam dit door HA zelf die voor de nieuwere versies veel meer verkeer genereerd en extra beveiligingen heeft.
Tot nu toe (fingers crossed) kon ik het oplossen door in de configuration.yaml m'n IP's te zetten onder:

YAML:

http:
  use_x_forwarded_for: true
  trusted_proxies:
    - 192.168.0.1       # Je Omada router/gateway
    - 192.168.VLAN.0/24    # Volledige VLAN van je HA-server zelf
    - 192.168.VLAN.0/24    # Volledige VLAN van je werklaptop/apparaten

[posttoast]

Ik heb de afgelopen twee nachten getest met mijn smart-bypass en ben tegen wat gekke dingen aangelopen. Ik ben benieuwd of @Wimpie70 dit ook is tegengekomen.

Ik gebruik de geaggregeerde sensoren die ramses_cc aanmaakt (sensor.orcon_wtw_outdoor_temperature, _indoor_temperature, _supply_temperature, _indoor_humidity). Die werken prima, maar af en toe (vooral 's nachts) sprong de waarde plots terug naar een momentopname van uren eerder, om bij het volgende moment weer goed te staan. Mijn bypass-logica flipte daardoor van besluit en de klep ging klapperen.

In mijn log zag dat er zo uit:

code:

03:55  aanzuig 30.38   <- stale
03:56  aanzuig 23.46   <- echt
03:57  aanzuig 30.38   <- stale
04:00  aanzuig 23.37   <- echt
04:01  aanzuig 30.38   <- stale

Je ziet de echte waarde langzaam zakken (wat de verwachting is in de nacht), maar hij schiet elke keer terug naar die exacte 30.38 (wat een temperatuur is die hij eerder op de dag een keer echt heeft gehad).

Ik ben met Claude door logs en configs gaan spitten, om te kijken waar die 30.38 vandaan komt. Claude heeft vervolgens een debug-sensor voor me gemaakt om te kijken waar de 31DA-frames vandaan komen. Ik ben elk frame gaan loggen met afzender en de temperaturen. Daaruit bleek dat mijn WTW (32:152794) de enige was die temperaturen stuurde, en dat was elke keer de "echte" temperatuur. Die 30.38 kwam dus nergens vandaan.

Het lijkt er dus op dat ramses_cc die af en toe teruggeeft. Geen idee waarom.

Ik heb het uiteindelijk opgelost door trigger-based template-sensors te maken die rechtstreeks de 31DA-payloads uitlezen via event.ramses_cc_regex_event en die alleen updaten op een vers frame van de WTW zelf. Dit is zo'n sensor:

YAML:

- trigger:
    - trigger: state
      entity_id: event.ramses_cc_regex_event
      id: rf
    - trigger: homeassistant
      event: start
      id: init
    - trigger: event
      event_type: event_template_reloaded
      id: init
  variables:
    wtw_src: "32:152794"   # <- jouw FAN-adres
    wtw_code: "31DA"
  sensor:
    - name: "Orcon WTW Outdoor Temperature Clean"
      unique_id: orcon_wtw_outdoor_temperature_clean
      unit_of_measurement: "°C"
      device_class: temperature
      state_class: measurement
      state: >
        {% set d = trigger.to_state.attributes.get('data', {}) if trigger.id == 'rf' else {} %}
        {% set p = d.get('payload', {}) if d is mapping else {} %}
        {% if d.get('code') == wtw_code and d.get('src') == wtw_src and p.get('outdoor_temp') is not none %}
          {{ p.get('outdoor_temp') | float(0) | round(2) }}
        {% else %}
          {{ this.state }}
        {% endif %}

Dit werkt vooralsnog prima, ik krijg geen "spook-data" meer binnen die mijn bypass-logica verstoort.

Ik snap alleen nog niet zo goed waarom ramses_cc die oude waarden af en toe teruggeeft. Ik heb het probleem hiermee opgelost, maar het voelt wel een beetje als een omweg

[Wimpie70]

zie https://github.com/ramses-rf/ramses_cc/issues/723

[posttoast]

Wimpie70 schreef op donderdag 25 juni 2026 @ 13:41:
zie https://github.com/ramses-rf/ramses_cc/issues/723

Ja, dat issue had ik geopend, maar ik had (heel stom) de link niet gelegd met het probleem dat ik hier nu heb Dat issue ging in principe over de status, niet over andere data. Maar goed, da's feitelijk hetzelfde verhaal natuurlijk.

Maar goed, ik heb nu dus in ieder geval een enigszins werkbare workaround. Zijn er nog nadelen aan hoe ik het nu heb aangepakt?

[posttoast]

Ik bestuur mijn bypass nu al een tijdje met mijn eigen "smart"-logica in Home Assistant, die kijkt naar binnentemperatuur, buitentemperatuur en dauwpunt. Dat werkt prima, in de nacht komt er lekker koele lucht mijn slaapkamer in. Niet genoeg om de temperatuur significant te laten dalen, wel een aangenaam briesje:



Hier zie je een grafiek van een paar dagen geleden. Zodra de buitentemperatuur (aanzuig buiten) gedurende langere tijd 1,5 graad onder de binnentemperatuur (aanzuig binnen) zit, gooit hij de bypass open. Dat zie je hier gebeuren vanaf ongeveer 0200 uur, in de loop van de ochtend gooit hij hem weer dicht. Er zit wat logica in om te zorgen dat hij niet gaat klepperen, een soort "wachtstand" dus.

Nu heb ik, als test, afgelopen nacht mijn smart logica uitgezet en de bypass weer op auto gezet, dus de controle bij de WTW zelf. En wat er toen gebeurde zal je doen verbazen



De Orcon is midden in de nacht continu de klep op 80% open, en vlak daarna weer 100% open aan het zetten. Dus precies het klepperen dat ik met mijn smart-logica probeer te voorkomen (omdat ik bang ben dat de klep-motor slijt als ik dit heel vaak doe). Vanochtend rond 0800 uur is hij wel volledig dicht gegaan, dat staat hij nu nog steeds. Wat ik eigenlijk ook vreemd vind, want de buitentemperatuur ligt nu nog best een stuk onder de binnentemperatuur.

Dit roept bij mij een paar vragen op, ik ben benieuwd of iemand hier daar iets van vindt:

1. Waarom gooit de Orcon de klep maar voor 80% open? "Een beetje bypass" lijkt me vrij zinloos.
2. Wat is überhaupt de bypass-logica van de Orcon zelf? Ik heb het hier of in het Ramses-topic langs zien komen, maar ik kan het niet meer terugvinden. Zie ook dit:

RusFighter schreef op maandag 25 mei 2026 @ 09:28:
[...]


[...]

Ik heb ergens in een andere topic (Ramses) gezien wat de formule was wanneer de bypass open gaat. Het zou fijn als iemand deze hier ook benoemd.

Ander ding over bypass is dat de afzuigende lucht uit de woning bij mijn unit (Orcon Optiair) niet door de filter gaat als de bypass open staat. Risico hiervan is dat de afzuigende ventilator sneller vies wordt.

[FRGert]

Goedemorgen allemaal,

Ik heb een WTW unit (nogal een oude) maar ik had een ESP bordje die communiceerde met deze WTW unit. Het uitlezen van een MQTT sensor kon ik dan de WTW unit automatisch aan en uit laten gaan (of bepaalde standen 50% 75% of 100%). Nu weet ik niet meer bij wie ik dat esp bord je had besteld, maar zou dat wel weer willen. Nu zie ik ook allemaal alternatieven hierboven. Hoe/wat moet ik kijken of mijn WTW ondersteunt?

Hoor graag van jullie.
(p.s. ben beetje lerende mbt allemaal)

[Vaevictis_]

FRGert schreef op vrijdag 3 juli 2026 @ 11:26:
Goedemorgen allemaal,

Ik heb een WTW unit (nogal een oude) maar ik had een ESP bordje die communiceerde met deze WTW unit. Het uitlezen van een MQTT sensor kon ik dan de WTW unit automatisch aan en uit laten gaan (of bepaalde standen 50% 75% of 100%). Nu weet ik niet meer bij wie ik dat esp bord je had besteld, maar zou dat wel weer willen. Nu zie ik ook allemaal alternatieven hierboven. Hoe/wat moet ik kijken of mijn WTW ondersteunt?

Hoor graag van jullie.
(p.s. ben beetje lerende mbt allemaal)

Welke unit heb je exact? En welke microcontroller? Misschien een foto plaatsen?

[FRGert]

Vaevictis_ schreef op vrijdag 3 juli 2026 @ 11:28:
[...]


Welke unit heb je exact? En welke microcontroller? Misschien een foto plaatsen?

Ik kon geen unit nummer vinden (ga zo mijn foto's bekijken van de verbouwing toen) Hij lijkt in ieder geval op deze. Exact deze versie. De microcontroller is een Wemos D1 mini met daaronder een CC1101V2 gekoppeld. Dus die pinnetjes zijn allemaal doorverbonden. Heb je hier voldoende aan of wil je daar dan ook nog een foto van?

[wesleym]

@Wimpie70 bedankt voor ramses_extra.

Ik gebruik ramses extra 0.20.11 en ramses 0.57.10 alleen de fan map blijft leeg. De comfort temperatuur resolved ook niet (wel op ramses_cc is beschikbaar als entity). Ik heb nu via settings van ramses_Extra de comfort temperatuur entity alsnog ingesteld. De fan map blijft volledig leeg. Weet jij hoe dit komt en wil je bepaalde logging hebben?

Ik heb op ramses_cc bij geavanceerde opties:

Schakel send_packet service in om maatwerk-berichten te versturen: aan

expressie: 31DA|10D0





Dit is mijn ramses schema:

code:

orphans_hvac:
  - "32:162315"
  - "29:167752"
  - "37:090561"


"18:207688":
  class: HGI
"29:167752":
  alias: Orcon echte bediening / HA spoof
  class: REM
  commands:
    auto: " I --- 29:167752 32:162315 --:------ 22F1 003 000404"
    away: " I --- 29:167752 32:162315 --:------ 22F1 003 000004"
    stand_1: " I --- 29:167752 32:162315 --:------ 22F1 003 000104"
    stand_2: " I --- 29:167752 32:162315 --:------ 22F1 003 000204"
    stand_3: " I --- 29:167752 32:162315 --:------ 22F1 003 000304"
    timer: " I --- 29:167752 32:162315 --:------ 22F3 007 00020F03040000"
  faked: true
"32:162315":
  alias: Orcon HRC400
  bound: "37:090561"
  class: FAN
"37:012247":
  alias: Orcon CO2 Werkkamer
  class: CO2
"37:012251":
  alias: Orcon CO2 Woonkamer
  class: CO2
"37:012270":
  alias: Orcon CO2 Slaapkamer
  class: CO2
"37:090561":
  alias: Orcon HRC inbouwdisplay 15RF
  class: REM

[ Voor 10% gewijzigd door wesleym op 08-07-2026 14:30 ]

[Wimpie70]

@wesleym Dank voor je bericht, ik heb een issue aangemaakt (https://github.com/wimpie70/ramses_extras/issues/102) zodat je (en ik) het kunnen volgen.

Ik ben op het moment druk met PR's voor Ramses RF, en af en toe is er ook een pre release van _extras (0.20.13 is net uit), dus het zou kunnen dat het inmiddels weer werkt.

De comfort temperatuur is idd iets veranderd ivm timing bij de opstart. Probeer eens de parameters te verversen (Hvac Fan card, tandwieltje voor opties).

Ik heb al even niet meer naar de FAN Map gekeken. Deze heb ik gemaakt om DIY zones te kunnen checken, eigenlijk als voorbereiding van een 2e systeem dat ik nog moet aansluiten.

Als Ramses RF (dit is de basis, met veel veranderingen deze periode) wat verder is, zal ik hier weer naar kijken.

[ Voor 10% gewijzigd door Wimpie70 op 08-07-2026 15:39 ]

[studiostevus]

Ik heb een Orcon HRC220 (en via Ramses kan ik hem in home assistant uitlezen/bedienen). Hierover heb ik 2 vragen:

1. Volgens de manual zou de bypass automatisch moeten schakelen bij binnentemperatuur >23C en buitentemp >15C (ja er staat echt 'boven de 15C' buitentemp). Dit zou de afgelopen dagen het geval moeten zijn maar ik zie dit niet gebeuren. De bypass position status staat altijd op 'off' in home assistant'. De bypass mode staat altijd op unknown. De schakelaar '(Test) Bypass Valve (0=auto, 1=open, 2=closed)' lijkt ook niks te doen.
2. In de HRC220 zitten geen ingebouwde sensoren (CO2, vocht), zou ik die kunnen retrofitten? (Hoewel ik in het forum lees dat dit blijkbaar niet zo goed werkt)

Alvast dank!

[ Voor 14% gewijzigd door studiostevus op 15-07-2026 10:39 ]

[Wimpie70]

Niet direct antwoord op je vragen, maar je kan Ramses_extras proberen. Hiermee kan je dit soort dingen zelf regelen. Waarschijnlijk heb je wel even nodig om alles goed in te stellen.

Met _extras kan je externe sensoren gebruiken voor vocht/temperatuur voor binnen en buiten. De absolute luchtvochtigheid wordt berekend en hierop kan de snelheid van de FAN worden gestuurd. Ook is er een feature om de bypass te sturen. En een hvac fan card om alles te bekijken en regelen.

Zie de wiki.

[FRGert]

Vaevictis_ schreef op vrijdag 3 juli 2026 @ 11:28:
[...]


Welke unit heb je exact? En welke microcontroller? Misschien een foto plaatsen?

Dit bordje heb ik voor het besturen van mijn WTW unit.

[Wimpie70]

Er zijn aardig wat updates voor Ramses RF (en _extras). Dit is te volgen op github, maar ook o.a. op: Ramses II 868MHz communicatie via evofw3 en ramses_rf

Het betreft soms pre-releases. Als je deze wilt gebruiken (en helpen met testen), maak dan altijd eerst een backup.

0.58.1 is net uit. 0.58.0 introduceerde een verandering in hoe we het schema (gaan) gebruiken.

[studiostevus]

Wimpie70 schreef op woensdag 15 juli 2026 @ 11:46:
Niet direct antwoord op je vragen, maar je kan Ramses_extras proberen. Hiermee kan je dit soort dingen zelf regelen. Waarschijnlijk heb je wel even nodig om alles goed in te stellen.

Met _extras kan je externe sensoren gebruiken voor vocht/temperatuur voor binnen en buiten. De absolute luchtvochtigheid wordt berekend en hierop kan de snelheid van de FAN worden gestuurd. Ook is er een feature om de bypass te sturen. En een hvac fan card om alles te bekijken en regelen.

Zie de wiki.

Ik heb de laatste (pre)releases geinstalleerd en zie nu bijvoorbeeld dit. Lijkt me dat dit onjuist gedrag is. Hij zou nu toch de bypass open moeten gooien om koelere buitenlucht naar binnen te blazen?

[Wimpie70]

Je moet even op de Temp control button drukken, deze staat op off. Het kan even duren voordat de bypass visueel op open staat.
Maar misschien is deze uitgezet door een fout in de code. Ik zie dat zelf ook wel gebeuren. Zal daar naar kijken.

[studiostevus]

Zit iets raars in.

Ik heb op temp control gedrukt, maar dit lijkt geen effect te hebben (zowel in de interface als op gedrag van de Orcon). Ten tweede ging hij daarna op 'offline' in de interface. Toen hij na een tijdje niet meer online kwam heb ik via de achterkant van Ramses even fan speed op high gezet, wat gewoon lukte (hoorde hem optoeren) en toen kwam hij in de interface ook weer online.

Intussen heeft het drukken op de temp control knop geen effect gehad voor zover ik kan zien. Ook aan de achterkant blijft de 'bypass position' op 'off' (terwijl bypass mode op auto blijft staan).

[studiostevus]

Wat gaat er mis?

[Wimpie70]

thanks, i don't have the time right now to look at it. I did add a little reminder on https://github.com/wimpie70/ramses_extras/issues/106

[studiostevus]

Dank je!

De aan/uit (MS) was door mij handmatig geinitieerd met de knop. De vraag is meer waarom hij op 'disabled' blijft staan, ook al zet ik temp control op aan.

[Wimpie70]

Er zit een vertraging op die knop. Dit om snel open en dichtzetten van de bypass te voorkomen. Geef het een half minuutje...
pre-release 0.20.19 zou de andere issues moeten oplossen. Ik heb het zelf nog niet uitgebreid getest, mijn focus ligt op het moment op Ramses RF zelf.

Laat even weten of het nu beter werkt.

[studiostevus]

Ik heb 20.16 gedownload (laatste prerelease in HACS van vanochtend) maar nu staat er bij devices dat het 20.15 is.

In elk geval, in deze versie had ik eerste waiting for comfort temp. Het lukt me niet om param 75 in te stellen, dus heb ik een helper aangemaakt. Nu is waiting for comfort temp weg, maar staat er disabled is de status.

[Wimpie70]

Kijk even bij de settings (tandwiel boven-midden) en ververs daar de comf. temp.

Het versie nummer is blijkbaar niet goed doorgekomen, dat kan ik even snel verbeteren. Ik zie dat de Temperatuur Control nog niet goed werkt. Ik moet er even wat langer naar kijken, maar op dit moment gaat Ramses RF voor.

[studiostevus]

Ik ben nu zo ver dat ik de fan speed kan bediening via Extras, maar de bypass kan ik nog niet bedienen.

Ik kan de bypass wel bedienen via een 2411 code via Developers/Actions, en ook via een normaal commando 'bypass_open' (dat een 2411 aanroept).

Extras blijft stug vasthouden aan 22F3 003 0000EF, en dat werkt niet bij mij.

(ook kan ik in Extras setup geen REM toevoegen aan mijn FAN (dropdown is leeg), maar weet niet of dat wel nodig is aangezien de fan speed wel werkt)

[ Voor 43% gewijzigd door studiostevus op 20-07-2026 16:47 ]

[Wimpie70]

Ik heb 2 problemen gevonden en verholpen:

- voor de bypass worden nu zowel 22F7 als 2411 berichten verzonden

- de dropdown filtert wat minder streng.

Ik zal proberen een snel een nieuwe (pre) release van _extras vrij te geven.


Het kan nog steeds zijn dat je REM nog niet helemaal goed in het schema stond (via de nieuwe discovery functie.

De laatste versie van RF heeft wat regressie problemen. Daar zijn al wel oplossingen voor, maar er komt pas eind van de week een nieuwe release.

[ Voor 90% gewijzigd door Wimpie70 op 20-07-2026 18:29 ]

[studiostevus]

20.18 geinstalleerd. Ik heb een HRC220 uit 2025, dus geen oude versie.

• Ik zie nog geen uitgaande 2411 berichten uitgaan voor het instellen van de bypass (wel de 22F7 maar dat werkt ook in mijn 2025 WTW niet, lijkt tegenstrijdig met eerdere forumposts).
• De REM is ook nog niet beschikbaar in de dropdown. Er komen verder geen acties meer uit het discovery menu voor deze remote dus ga ervan uit dat hij goed staat.
• Ik heb inmiddels ook geprobeerd param75 in te stellen via Developer/Actions, gebruik makende van de message/payload die jij ergens op github hebt gezet. Ik zie dan wel een param75 bericht terugkomen uit de Orcon, maar Extras pikt de param75 niet op (weet niet of het misgaat bij het instellen van de param75 in de WTW, of dat hij wel is ingesteld maar Extras hem niet oppikt).

[Wimpie70]

waarschijnlijk een probleem met Ramses RF

Ik draai op mijn productie server (ook Orcon WTW) RF 0.58.2, Ik krijg nog steeds alle 2411 params binnen en kan ook wijzigen.
Na deze versie is er een verandering geweest (0.58.3 of .4) die o.a. problemen met de params verooorzaakten. Even geduld nog.

Mochten na de volgende release nog problemen zijn, dan kan ik dat beter onderzoeken dan nu, omdat er grote stappen worden gemaakt met RF.

[ Voor 94% gewijzigd door Wimpie70 op 21-07-2026 10:09 ]

[Wimpie70]

@studiostevus Ik denk dat de laatste releases van _extras en RF behoorlijk stabiel zijn, je zou ze kunnen proberen. (maak altijd eerst een backup)

[studiostevus]

ik heb ze er op staan. Inderdaad kan de bypass nu bedient worden.

Ik zie alleen nog geen activiteit van de temp control.

[Wimpie70]

Ik zie dat mijn reactie die ik eerder had getypt niet is geplaatst. (zal wel niet op het knopje hebben geklikt...)

Er was een blokkade door een dauwpunt protectie. Deze werkt niet met jouw FAN (geen luchtvochtigheid sensoren).

De fix zit in 0.20.21

[studiostevus]

even wachten voor ik conclusies trek

[ Voor 91% gewijzigd door studiostevus op 26-07-2026 10:31 ]

[Wimpie70]

@studiostevus vreemd, kan je hier een issue van maken op Github, met logbestanden ? Ik heb meer info nodig.