:no_upscale():strip_icc():strip_exif()/f/image/YpIa0f5GL3JJexs0hEsmIUbs.jpg?f=user_large)
:strip_icc():strip_exif()/u/4202/crop59500930db0d0_cropped.jpeg?f=community)
Afgelopen dagen zag ik meermaals dat mijn efficiency boven de 100% kwam, bijzonder.. Supply temp is hoger dan de Indoor temp. Enige verklaring die ik kan bedenken is dat de sensoren niet nauwkeurig zijn. Zien meer mensen dit en weet iemand waar het aan ligt?
/f/image/OX4cZxzwu9hNgyHFhnjcxG2v.png?f=fotoalbum_large)
:strip_exif()/f/image/OX4cZxzwu9hNgyHFhnjcxG2v.png?f=user_large)
Ik heb inmiddels toch een poging gedaan om Zigbee aan de gang te krijgen. Dat is bij mij thuis gelukt nu. Ik heb een pull request gedaan naar Ramses cc/rf voor de benodigde code. Ik heb ook een update gedaan aan de Ramses_esp software. Hier zit trouwens ook een verbetering bij voor MQTT:
@denpries, dat is mijn website inderdaad. Het is de bedoeling dat daar in de toekomst nog meer bordjes op komen te staan en tutorials for home automation en andere projecten
@XElD, het was in het begin de bedoeling om te kijken of ik Zigbee communicatie kon implementeren, maar het was al heel veel werk om het uberhaupt werkend te krijgen. Daarnaast is er ook wel wat werk nodig aan de Home Assistant kant. Dus dat is even op een zijspoor beland.
.Je kunt nu met een ramses esp32-c6 bordje vrij switchen tussen wifi en zigbee door 'network wifi' of 'network zigbee' via serial naar het bordje te sturen. Misschien dat ik dat in de toekomst nog kan automatiseren.
:strip_icc():strip_exif()/u/1050101/crop6788c937a61a1_cropped.jpg?f=community)
Hi allen!
Sinds vandaag heb ik mijn Orcon HRC 300 MaxComfort in Home Assistant hangen middels het bordje van @immrmkw.
Ik zag online voorbij komen dat het mogelijk is om bepaalde sensors te faken, net zoals het mogelijk is om een remote te faken.
Graag zou ik mijn IKEA CO2 sensoren willen exposen naar de Orcon middels het Ramses II protocol.
Weet iemand hoe ik dit het beste kan aanvliegen?
Ik heb mijn fake remote werkend en ik kan commando's versturen
Het lijkt er echter wel op dat het niet mogelijk is om via de "fan card" de status aan te passen, ik kan dit enkel via de "developer tools" middels het "remote.send" commando.
Dit is mijn configuratie:
Groet,
Joshua
Sinds vandaag heb ik mijn Orcon HRC 300 MaxComfort in Home Assistant hangen middels het bordje van @immrmkw.
Ik zag online voorbij komen dat het mogelijk is om bepaalde sensors te faken, net zoals het mogelijk is om een remote te faken.
Graag zou ik mijn IKEA CO2 sensoren willen exposen naar de Orcon middels het Ramses II protocol.
Weet iemand hoe ik dit het beste kan aanvliegen?
Ik heb mijn fake remote werkend en ik kan commando's versturen
Het lijkt er echter wel op dat het niet mogelijk is om via de "fan card" de status aan te passen, ik kan dit enkel via de "developer tools" middels het "remote.send" commando.
Dit is mijn configuratie:
code:
Alvast bedankt voor het meedenken! 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
| "18:223040":
_note: Ramses RF USB
class: HGI
"29:123456":
_note: virtual remote
class: REM
commands:
auto: " I --- 29:123456 32:155234 --:------ 22F1 003 000407"
auto2: " I --- 29:123456 32:155234 --:------ 22F1 003 000507"
away: " I --- 29:123456 32:155234 --:------ 22F1 003 000007"
boost: " I --- 29:123456 32:155234 --:------ 22F1 003 000607"
bypass_auto: " W --- 29:123456 32:155234 --:------ 22F7 003 00FFEF"
bypass_open: " W --- 29:123456 32:155234 --:------ 22F7 003 00C8EF"
bypass_close: " W --- 29:123456 32:155234 --:------ 22F7 003 0000EF"
disable: " I --- 29:123456 32:155234 --:------ 22F1 003 000707"
low: " I --- 29:123456 32:155234 --:------ 22F1 003 000107"
medium: " I --- 29:123456 32:155234 --:------ 22F1 003 000207"
med_60: " I --- 29:123456 32:155234 --:------ 22F3 007 00123C02040404"
high: " I --- 29:123456 32:155234 --:------ 22F1 003 000307"
high_15: " I --- 29:123456 32:155234 --:------ 22F3 007 00120F03040404"
high_30: " I --- 29:123456 32:155234 --:------ 22F3 007 00121E03040404"
high_60: " I --- 29:123456 32:155234 --:------ 22F3 007 00123C03040404"
reset_filter: " W --- 29:123456 32:155234 --:------ 10D0 002 00FF"
faked: true
scheme: orcon
"29:173722":
_note: Orcon 15RF
class: REM
scheme: orcon
"32:155234":
_note: Orcon HRC 300 MaxComfort
class: FAN
bound: "29:123456" |
Groet,
Joshua
Joshua Bergman
:strip_icc():strip_exif()/u/1623466/crop65722036eb80b_cropped.jpg?f=community)
Sinds ik HA heb geupdated naar 2026.3.1 werkt mijn co2 sensor niet meer. Ik kom er ook echt totaal niet meer uit waarom, van alles geprobeerd maar blijft unavailable. Iemand een idee?
logs laat ook niet iets spannends zien
/f/image/VxFo0Krc44uNQOkQllt0As9P.png?f=fotoalbum_large)
logs laat ook niet iets spannends zien
:strip_exif()/f/image/VxFo0Krc44uNQOkQllt0As9P.png?f=user_large)
[ Voor 3% gewijzigd door Economics op 08-03-2026 08:31 ]
Weer een stapje verder met mn zone project...Klep kan ik na kalibratie op een percentage open of dicht zetten. De 2PM detecteert de eindstanden zelf (de klep onderbreekt de stroom).
220V Klep: ong. 30 euro, shelly plus 2PM - gen 3 ong. 25 euro.
Vooralsnog verbonden via wifi (eigen VLAN).
Nu nog implementeren in Ramses Extras...
/f/image/ioAysY7u3Am9oGtpziDCkk5X.png?f=fotoalbum_large)
220V Klep: ong. 30 euro, shelly plus 2PM - gen 3 ong. 25 euro.
Vooralsnog verbonden via wifi (eigen VLAN).
Nu nog implementeren in Ramses Extras...
:strip_exif()/f/image/ioAysY7u3Am9oGtpziDCkk5X.png?f=user_large)
Ramses RF - Ramses Extras - Orcon WTW - Duco WTW - esp_9_klep_beregening
:strip_icc():strip_exif()/u/765793/crop57e237b91024a_cropped.jpeg?f=community)
ik heb net het starttopic gelezen maar klopt de volgende samenvatting?
Voor het uitlezen en bediening met een Domotica systeem zoals Home Assistant is een Ramses-II gateway (zender/ontvanger) nodig:
Voor het uitlezen en bediening met een Domotica systeem zoals Home Assistant is een Ramses-II gateway (zender/ontvanger) nodig:
- Honeywell HGI-80 USB serial device. De officiele gateway. Lastig verkrijgbaar. Hiermee kun je wel uitlezen, maar niet besturen. De HGI-80 kan geen andere devices nadoen
- HGI-80 kloon: Een device dat evofw3 draait. Meestal een atmega 32u4. Met USB verbonden aan PC
- Ramses ESP opvolger van evofw3. USB en stand-alone via MQTT
- FanX : gemaakt door tweaker WillieWortel. Niet meer leverbaar
- Airios verkoopt een RF naar rs485 modbus gateway BDRG-02R13. Hiermee is meer informatie uit te lezen dan met een HGI-80 of kloon. Voor HA is nog een extra modbus gateway nodig.
- is inderdaad niet te vinden en valt dus af
- niet helemaal duidelijk waar deze van is samengesteld dus geluk hebben dat @vliegnerd wat gemaakt heeft of mis ik ergens de link hoe ik deze zelf kan bouwen, ik heb wel de FanX RF USB Dongle gezien maar dat is alleen sturen en niet uitlezen volgens mij
- Niet beschikbaar en onduidelijk hoe snel deze stock wordt aangevuld iemand ervaringen?
- niet meer leverbaar dus valt af
- 2 devices dus relatief onhandig en mogelijk duurder dan de andere opties
:strip_exif()/u/90636/nintendo.gif?f=community)
4,8kW ZO-NW PVOutput 8x300Wp ZO 12 graden. 8x300Wp NW 12 graden.
:strip_exif()/u/86833/sheeptrans.gif?f=community){kind=spacer}
4,8kW ZO-NW PVOutput 8x300Wp ZO 12 graden. 8x300Wp NW 12 graden.
dank 
, toevallig dat er dus net nieuwe stock is, want gisteren was het out of stock maar prima ik ga er even naar kijken bedankt allemaal, ook fijn dat de startpost weer geupdate is
heb deze besteld https://elecram.com/products/esp32-c6-wifi-zigbee-to-855-925mhz-wireless?variant=52605637099853
, toevallig dat er dus net nieuwe stock is, want gisteren was het out of stock maar prima ik ga er even naar kijken bedankt allemaal, ook fijn dat de startpost weer geupdate is heb deze besteld https://elecram.com/products/esp32-c6-wifi-zigbee-to-855-925mhz-wireless?variant=52605637099853
[ Voor 39% gewijzigd door Ramkoe op 08-05-2026 09:26 . Reden: kijk eens wat ik besteld heb ]
:strip_icc():strip_exif()/u/188460/horse.jpg?f=community)
Bedankt voor de link, ik kwam dit topic toevallig tegen en heb het direct besteld!:
dank
heb deze besteld https://elecram.com/products/esp32-c6-wifi-zigbee-to-855-925mhz-wireless?variant=52605637099853
Op dit moment heb ik alles slim met Home Assistant en ik baalde al dat m’n wtw als enige nog dom is. Heb ik weet wat te doen de komende weken!
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.
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 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 ]
:strip_exif()/u/5779/posttoast.gif?f=community)
:strip_exif()/u/7320/kuwamai-hime.gif?f=community)
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:
Edit: bingo! Ik heb hem 1
2
3
4
5
| action: remote.send_command target: entity_id: remote.29_123456 data: command: high |
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 ]
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.:strip_exif()/f/image/fm9NMEl9LAW19CkAvj0RIMaW.jpg?f=fotoalbum_large)
:no_upscale():strip_icc():strip_exif()/f/image/fm9NMEl9LAW19CkAvj0RIMaW.jpg?f=user_large)
[ Voor 50% gewijzigd door Vaevictis_ op 15-06-2026 19:41 ]
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:
/f/image/PkjsiFkOKkwjSy5H02QzF5al.png?f=fotoalbum_large)
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?
:strip_exif()/f/image/PkjsiFkOKkwjSy5H02QzF5al.png?f=user_large)
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:
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
Is dit gedrag bekend bij jullie?
@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 ]
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".
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 ]
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
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
:strip_icc():strip_exif()/u/326988/Churiots_small.jpg?f=community)
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.:
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
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:
/f/image/uSce7tHuLYvx0blGrTGIpxkr.png?f=fotoalbum_large)
Bypass open:
afvoerlucht > conform temperatuur &
aanvoerlucht > 13 &
verschil tussen binnen & buiten > 5C
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:
:strip_exif()/f/image/uSce7tHuLYvx0blGrTGIpxkr.png?f=user_large)
Bash:
1
2
3
| 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:
De logica van bypass is volgens vervlogen in "Orcon HRC RF modbus in ESPHome"1
2
3
4
| action: remote.send_command data: command: bypass_open entity_id: remote.37_168272 |
Bypass open:
afvoerlucht > conform temperatuur &
aanvoerlucht > 13 &
verschil tussen binnen & buiten > 5C
[ Voor 19% gewijzigd door RusFighter op 23-06-2026 09:54 ]
Omdat ik jokte realiseer ik me nu
Die check heb ik helemaal niet, ik heb wel een condens-marge erop zitten.Nee, nog geen helpers, ik heb het nu vooral hacky-schmacky erin hangen als test. Netjes maken is de volgende stap
Klinkt ook allemaal wel tof
Die test op minimale buitentemperatuur is eigenlijk alleen bedoeld tegen vrieskou (beetje ruim), maar een condensmarge is zeker een goed idee 
Ramses RF - Ramses Extras - Orcon WTW - Duco WTW - esp_9_klep_beregening
Dit is de sensor die ik gemaakt heb (in samenwerking met Claude en Gemini, de em-dashes verraden het al een beetje:
Die test op minimale buitentemperatuur is eigenlijk alleen bedoeld tegen vrieskou (beetje ruim), maar een condensmarge is zeker een goed idee
):YAML:
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.1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
| - 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 %} |
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...:
[...]
Dit is de sensor die ik gemaakt heb (in samenwerking met Claude en Gemini, de em-dashes verraden het al een beetjeYAML: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?
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:
[...]
Heb je daar documentatie van? Volgens Gemini is dat niet het geval namelijk. En AI liegt nooit
:no_upscale():strip_icc():strip_exif()/f/image/M0B82a9HRcyVLBsALAGIsVyq.jpg?f=user_large)
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
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:
:strip_exif()/f/image/sDRjlWLlveiC4Y1U7kembFKH.jpg?f=fotoalbum_large)
Edit: in de groene cirkel bedoel ik:
:no_upscale():strip_icc():strip_exif()/f/image/sDRjlWLlveiC4Y1U7kembFKH.jpg?f=user_large)
[ Voor 50% gewijzigd door posttoast op 23-06-2026 18:08 ]
Helaas zit de klep daar dus niet, maar op volgende positie(groen). Afzuigende lucht volgt blauwe lijn als de klep open is
:no_upscale():strip_icc():strip_exif()/f/image/XXSxEgdOTHJA5jyUp49in682.jpg?f=user_large)
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:
[...]
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
OK, ik heb reactie:
En ik kreeg er nog een plaatje bij:
:strip_exif()/f/image/iEqF7THtbbYwe1fHLYtyVC7P.png?f=user_large)
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 ]
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":
[...]
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 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:
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:
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
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:
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).1
2
3
4
5
| 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 |
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:
Dit werkt vooralsnog prima, ik krijg geen "spook-data" meer binnen die mijn bypass-logica verstoort.1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
| - 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 %} |
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
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?