Open AIR (open source smart ventilatieaansturing)

[inquestos]

Ik durf het haast niet te vragen maar is er nog een update over een WTW versie?

Of hebben andere zaken de prioriteit gehad afgelopen tijd (zo te lezen wel )

[mrwiggs]

Sinds vandaag 12:15 doet 1 van mijn 5 sensors (temp + vochtigheid) het niet meer. Herstarten heeft ook geen nut. Iemand enig idee?



Ik kwam ook deze log line tegen:

code:

21:51:44    [D] [internal_temperature:075]  
Ignoring invalid temperature (success=0, value=53.3)

[IJsbeer]

@The_ Mad_Ping : Zijn er ook plannen om uit te breiden naar een ander Duco product, namelijk de ventilatieroosters. Er zijn wel wat hobby projecten die een rooster via een actuator aan te sturen, maar ik durf te wedden dat jullie dat veel beter kunnen...

[aMUSEd1985]

IJsbeer schreef op woensdag 4 maart 2026 @ 21:58:
@The_ Mad_Ping : Zijn er ook plannen om uit te breiden naar een ander Duco product, namelijk de ventilatieroosters. Er zijn wel wat hobby projecten die een rooster via een actuator aan te sturen, maar ik durf te wedden dat jullie dat veel beter kunnen...

Daar ben ik ook erg in geïnteresseerd!

[Tazzios]

+1
Ik gebruik nu een klep achter het ventilatierooster maar ideaal is het niet wat betreft inbouwruimte en constructie.

[marvel27]

Goed idee ja! Een compacte, stille connected aansturing van ventilatieroosters zou heel nuttig zijn. Misschien aangestuurd door een batterij, om geen kabels in het zicht te hebben. Ik zou het kopen

[Mithrandir]

Zojuist de eerste 5 valves geinstalleerd (2 slaapkamers beneden, 2 slaapkamers boven, washok). Binnenkort nog 4 aan de andere kant van huis voor woonkamer, slaapkamer, wc en badkamer.

[ Voor 9% gewijzigd door Mithrandir op 06-03-2026 11:57 ]

[Mithrandir]

Ik ben bezig met controller software om de Openair + valves aan te sturen. Het idee is als volgt:

De OpenAIR controller pollt elke 60 seconden de CO2- en luchtvochtigheidswaarden van alle kleppen via HTTP. Op basis van deze sensorwaarden berekent hij per klep een "demand" (0-1): hoe ver de meetwaarde afwijkt van het doel (bijv. CO2 600→1500 ppm schaalt van 0 naar 1). De hoogste demand bepaalt de ventilatorsnelheid.

Elke klep leest elke 60 sec zijn eigen sensoren én de huidige ventilatorsnelheid van de OpenAIR controller. Door zijn eigen demand te delen door de genormaliseerde ventilatorsnelheid bepaalt de klep hoe ver hij open moet staan. Als deze kamer de ventilator aandrijft (hoge CO2), blijft de klep wijd open. Als een andere kamer de reden is dat de ventilator hard draait, gaat de klep juist verder dicht — zo wordt de luchtstroom automatisch naar de kamer geleid die het hardst nodig heeft. Kleppen blijven altijd minimaal ~5% open zodat de sensoren verse lucht meten.

Het systeem werkt volledig zonder Home Assistant. De communicatie is puur HTTP GET in beide richtingen: de controller leest sensorwaarden van de kleppen, en de kleppen lezen de ventilatorsnelheid van de controller. Als een apparaat onbereikbaar is, valt het terug op veilige standaardwaarden (lage ventilatie, kleppen open).

[Mithrandir]

Ik (claude) heb een simulator gemaakt om met het bovenstaande idee te spelen;



[edit] nu kun je de personen in je huishouden door het huis verplaatsen en zien hoe het systeem reageert

[ Voor 40% gewijzigd door Mithrandir op 13-03-2026 16:57 ]

[LinuZZ]

Mithrandir schreef op vrijdag 13 maart 2026 @ 15:10:
Ik ben bezig met controller software om de Openair + valves aan te sturen. Het idee is als volgt:

De OpenAIR controller pollt elke 60 seconden de CO2- en luchtvochtigheidswaarden van alle kleppen via HTTP. Op basis van deze sensorwaarden berekent hij per klep een "demand" (0-1): hoe ver de meetwaarde afwijkt van het doel (bijv. CO2 600→1500 ppm schaalt van 0 naar 1). De hoogste demand bepaalt de ventilatorsnelheid.

Elke klep leest elke 60 sec zijn eigen sensoren én de huidige ventilatorsnelheid van de OpenAIR controller. Door zijn eigen demand te delen door de genormaliseerde ventilatorsnelheid bepaalt de klep hoe ver hij open moet staan. Als deze kamer de ventilator aandrijft (hoge CO2), blijft de klep wijd open. Als een andere kamer de reden is dat de ventilator hard draait, gaat de klep juist verder dicht — zo wordt de luchtstroom automatisch naar de kamer geleid die het hardst nodig heeft. Kleppen blijven altijd minimaal ~5% open zodat de sensoren verse lucht meten.

Het systeem werkt volledig zonder Home Assistant. De communicatie is puur HTTP GET in beide richtingen: de controller leest sensorwaarden van de kleppen, en de kleppen lezen de ventilatorsnelheid van de controller. Als een apparaat onbereikbaar is, valt het terug op veilige standaardwaarden (lage ventilatie, kleppen open).

Interessant! Doe je dit dan in esphome yaml code? Zo ja waar kan ik het vinden?

[Mithrandir]

LinuZZ schreef op vrijdag 13 maart 2026 @ 20:57:
[...]

Interessant! Doe je dit dan in esphome yaml code? Zo ja waar kan ik het vinden?

Let op, dit is WIP! Ik heb het (nog) niet op mijn eigen hardware geflashed. https://github.com/okke-formsma/homelab/tree/main/openair

[edit] Het draait nu lokaal. Morgen 's kijken of het vannacht goed heeft gewerkt

[ Voor 11% gewijzigd door Mithrandir op 13-03-2026 23:22 ]

[Mithrandir]

Het heeft gewerkt vannacht Ik vind 1000 CO2 wel wat te hoog dus even nadenken hoe de parameters zo tune dat hij meer afzuigt.

[edit] je ziet ook dat hij naar minimale RPM & valves open gaat wanneer er geen vraag is.

Het nadeel van sensors in de valve is dat je altijd een minimale ventilatie luchtstroom moet genereren zodat de sensors up-to-date zijn. Wanneer de sensor direct in de ruimte zit zou de ventilatiebox in theorie helemaal kunnen uitschakelen...

[edit2] Nu ook min/max values configureerbaar in HA zodat voor finetunen niet elke keer flashes nodig zijn

[ Voor 79% gewijzigd door Mithrandir op 14-03-2026 10:43 ]

[nairolf]

Mithrandir schreef op zaterdag 14 maart 2026 @ 08:26:
Het heeft gewerkt vannacht

[Afbeelding]

[Afbeelding]

Ik vind 1000 CO2 wel wat te hoog dus even nadenken hoe de parameters zo tune dat hij meer afzuigt.

[edit] je ziet ook dat hij naar minimale RPM & valves open gaat wanneer er geen vraag is.

Het nadeel van sensors in de valve is dat je altijd een minimale ventilatie luchtstroom moet genereren zodat de sensors up-to-date zijn. Wanneer de sensor direct in de ruimte zit zou de ventilatiebox in theorie helemaal kunnen uitschakelen...

[edit2] Nu ook min/max values configureerbaar in HA zodat voor finetunen niet elke keer flashes nodig zijn
[Afbeelding]

Ziet er erg tof uit!

Eventueel zou je kunnen terugzoeken naar mijn werk om relatief makkelijk een PI(D) regelaar erin te zetten. Het idee daarvan is dat als je meting lang boven je gewenste punt uitkomt, een tellertje steeds verder oploopt, en hij steeds harder gaat blazen. Hij verbetert zichzelf als het ware. Als hij er dan onder de gewenste waarde komt loopt het tellertje weer leeg, en loopt hij dus even na.

Wat je nu hebt is een P-regelaar: hij reageert proportioneel op de “fout”, de overschrijding van de waarde. Hoe hoger, hoe harder hij blaast, en daar houdt de logica op. Wat ik voorstel is hier dus de I-regelaar aan toevoegen, de integraal, dus de som van alle fouten uit het verleden.

[thomasv]

Mithrandir schreef op zaterdag 14 maart 2026 @ 08:26:
Het heeft gewerkt vannacht

[Afbeelding]

[Afbeelding]

Ik vind 1000 CO2 wel wat te hoog dus even nadenken hoe de parameters zo tune dat hij meer afzuigt.

[edit] je ziet ook dat hij naar minimale RPM & valves open gaat wanneer er geen vraag is.

Het nadeel van sensors in de valve is dat je altijd een minimale ventilatie luchtstroom moet genereren zodat de sensors up-to-date zijn. Wanneer de sensor direct in de ruimte zit zou de ventilatiebox in theorie helemaal kunnen uitschakelen...

[edit2] Nu ook min/max values configureerbaar in HA zodat voor finetunen niet elke keer flashes nodig zijn
[Afbeelding]

Zelf hanteer ik de waarden die hier staan, waarbij 1200ppm echt een bovengrens is (dus 1000 is niet extreem erg maar aan de hoge kant): https://arbocataloguspo.n...uwen/binnenklimaat-en-co2

In mijn directe omgeving heb ik zelf erg veel last van houtstook van (directe) buren waardoor harder ventileren soms juist een negatief effect heeft op de interne luchtkwaliteit (CO2 maar bijv. ook VOC, NOx waarden). Een afgewogen inschatting maken op basis van "ik ruik weer rook door de ventilatie van het slaapkamerraam" is soms waardevoller dan CO2 ppm > drempel = harder ventileren (positieve feedback loop) en dan schakel ik handmatig de ventilatie tijdelijk naar "laag".

Met dit alles bedoel ik vooral te zeggen dat 1000ppm wellicht ana de hoge kant lijkt maar je ook omgevingsfactoren hebt die van invloed zijn en dat je niet altijd onder of op je gewenste bovengrens blijft ongeacht hoe hard je het probeert te optimaliseren qua automatiseringen.

[Mithrandir]

nairolf schreef op zaterdag 14 maart 2026 @ 11:40:
[...]


Ziet er erg tof uit!

Eventueel zou je kunnen terugzoeken naar mijn werk om relatief makkelijk een PI(D) regelaar erin te zetten. Het idee daarvan is dat als je meting lang boven je gewenste punt uitkomt, een tellertje steeds verder oploopt, en hij steeds harder gaat blazen. Hij verbetert zichzelf als het ware. Als hij er dan onder de gewenste waarde komt loopt het tellertje weer leeg, en loopt hij dus even na.

Wat je nu hebt is een P-regelaar: hij reageert proportioneel op de “fout”, de overschrijding van de waarde. Hoe hoger, hoe harder hij blaast, en daar houdt de logica op. Wat ik voorstel is hier dus de I-regelaar aan toevoegen, de integraal, dus de som van alle fouten uit het verleden.

Ja, dat is precies wat ik zocht. Is nu geimplementeerd en ook aan de simulator toegevoegd.



Dingen die ik nog in m'n hoofd heb om te proberen zijn (1) om de "demands" op te tellen ipv altijd de max() van de demands te nemen, en (2) een "calibratie" factor per ruimte opnemen om verschillen in buislengte/capaciteit/normale bezetting te reflecteren. Maar eerst een paar dagen zien of het huidige systeem goed genoeg werkt, want het brengt allemaal nieuwe complexiteit.

[ Voor 5% gewijzigd door Mithrandir op 14-03-2026 14:44 ]

[Didiers]

Mithrandir schreef op vrijdag 13 maart 2026 @ 15:10:
Ik ben bezig met controller software om de Openair + valves aan te sturen. Het idee is als volgt:

De OpenAIR controller pollt elke 60 seconden de CO2- en luchtvochtigheidswaarden van alle kleppen via HTTP. Op basis van deze sensorwaarden berekent hij per klep een "demand" (0-1): hoe ver de meetwaarde afwijkt van het doel (bijv. CO2 600→1500 ppm schaalt van 0 naar 1). De hoogste demand bepaalt de ventilatorsnelheid.

Elke klep leest elke 60 sec zijn eigen sensoren én de huidige ventilatorsnelheid van de OpenAIR controller. Door zijn eigen demand te delen door de genormaliseerde ventilatorsnelheid bepaalt de klep hoe ver hij open moet staan. Als deze kamer de ventilator aandrijft (hoge CO2), blijft de klep wijd open. Als een andere kamer de reden is dat de ventilator hard draait, gaat de klep juist verder dicht — zo wordt de luchtstroom automatisch naar de kamer geleid die het hardst nodig heeft. Kleppen blijven altijd minimaal ~5% open zodat de sensoren verse lucht meten.

Het systeem werkt volledig zonder Home Assistant. De communicatie is puur HTTP GET in beide richtingen: de controller leest sensorwaarden van de kleppen, en de kleppen lezen de ventilatorsnelheid van de controller. Als een apparaat onbereikbaar is, valt het terug op veilige standaardwaarden (lage ventilatie, kleppen open).

Very interesting, structured and documented project that complements and adds to the initial hardware project an integrated management.

There are obviously many ways to manage a VMC, depending on the hardware everyone has, valves, internal / external sensors, home automation,... That said, being able to have a relatively standard and adapted software configuration is a real plus for the entire project.

I hope that this initiative that starts well will continue to evolve towards a collaborative solution allowing future adjustments, additions, where any ideas are welcome, I am thinking in particular of taking into account sensors external to the valves (Air Sense pro in particular)

Although personally having a Duco set, I recently installed a VMC Renson Healthbox 3 at a friend's house (model imposed by the architect) its automatic operation is quite close to that proposed by Mithrandir, the ventilation runs constantly (sensors integrated into the valves oblige) at about 420 RPM a flow at 40M3/H while the motorized valves have a flow rate of 10% as long as the RH/CO2/COV rates are below the trigger threshold, and go to 100% directly into ace of exceeding the threshold to return quickly enough to the norm.

The ventilation power is obviously a function of the number of areas requiring 100% flow, but remains relatively constant.

In addition, this Box has a pressure sensor that allows automatic calibration of the installation, this process tests each zone one after the other, the motor probably rises to 100%, all the valves are closed except the one being tested which opens at 100% this allows the plant to determine the load of the line in each zone and probably determine the standby and operating power in load when the different parts associations require it.

A Renson API allows me to monitor this box via Home Assistant, this means that if you want to receive the logs from the power plant or valves, I can reasonably provide you with the .CSV files. Corresponding this can possibly be used to determine how a commercial product is managed independently.

Nice evening to all without forgetting a little wink to our friend The Flamingo

BR

Didier

[hikhakhok]

Gisteren ook mijn Duco Silent Slim slim gemaakt met een Open AIR Mini en Open Air sensor. Meteen maar een PID‑regeling met ramp‑up en ramp‑down erin gezet (met hulp van Claude), en het idee hier op het forum. Zodra ik de badkamerverlichting aan doe, slaat hij de actuele RH op als startpunt. Vanaf daar regelt hij bij en blijft hij draaien totdat de RH weer terug is op dat startpunt, met een kleine offset. Werkt gisteren best prima, na het douchen nog even bijgetweakt.
Toch zit ik te twijfelen of dit wel de meest juiste aanpak is. Is werken met de start‑RH slim, of kun je beter met een vast setpoint, delta‑RH of iets als dauwpunt werken? En hoe doen jullie dat: ventilator altijd op een lage stand laten draaien of die ook op schakelaar laten opstarten? Benieuwd naar jullie ideeën en ervaringen.

[GoldenLeafBird]

Ik heb PI(D) regelaars overwogen, maar eigenlijk ben ik er niet van overtuigd dat dat voor een thuis systeem het beste is, of in ieder geval niet het meest praktische.
De uitdaging met het via een PID regelaar proberen te regelen is dat je sterk wisselende invloeden van buiten af hebt. Nu kan je een PID daar in de regel op inregelen, maar deze invloeden wisselen nogal. Het effect van douchen met de deur open, of de deur dicht bijvoorbeeld is best groot op de gemeten luchtvochtigheid, of bijvoorbeeld je raampje open of op een kier.
Zoals je gemerkt hebt blijft de luchtvochtigheid nog lang boven je startwaarde, wat niet gek is met de verdamping van het water uit je douche, van je muren, etc.

Maar niet alleen douchen heeft effect op de luchtvochtigheid, denk ook aan koken.

Hetzelfde probleem heb je ook als je op CO2 wil sturen. Veel mensen in huis, kaarsjes aan, dicht bij een afzuigpunt staan, het heeft allemaal verschillende effecten op de CO2 metingen. De CO2 waarde stijgt en daalt doorgaans veel langzamer dan luchtvochtigheid.

Mijn voorkeur:

Luchtvochtigheid:
Neem een voortschrijdend gemiddelde (moving average) van de afgelopen 60-120 minuten. Luchtvochtigheid veranderd over de loop van de dag, en zo glijdt dat lekker mee. Dan ben je ook niet afhankelijk van andere input zoals lichtschakelaars.
Stel een bandbreedte in waarin de regelaar het goed genoeg vindt (dead band). Als je dan weer genoeg in de buurt van je gemiddelde luchtvochtigheid komt zal de regelaar niet verder proberen te regelen.
Je kan voor een PI regelaar gaan (de D is hier niet heel relevant), maar enkel een P heeft voor mij ook al voldoende effect.

CO2:
Een simpele proportionele regelaar. Zet je setpoint op iets als 900, je max op 1200 en laat het daartussen lekker proportioneel regelen. CO2. Wel zou ik sturen op wederom een voortschrijdend gemiddelde van een paar minuten. Het valt me op dat de sensor, in ieder geval die van mij, nogal noisy wordt bij hoge ventilatorsnelheden, kan ook zijn dat ik alles een keer moet opschonen.
CO2 varieert veel langzamer over de dag, en je hoeft niet zo snel te kunnen reageren als bij het douchen.

In alle gevallen zou ik wel een minimale ventilatorsnelheid aanhouden (ik gebruik zelf 30%) zodat je luchtstroom over de sensoren houdt en voldoende snelle respons.
Ook moet je rekening houden met je minimale ventilatiesnelheid en je regelaar. Je regelaar zal altijd proberen je sensorwaarde naar je setpoint te krijgen, dus als je onder je setpoint komt dan gaat je regelaar proberen juist je luchtvochtigheid/CO2 te verhogen (wat niet gaat lukken). Als je dan een I term hebt geeft dat een probleem omdat dat gaat opbouwen.

Lang verhaal kort: PID regelaars zijn machtig, maar ook lastig. Voor in huis zou ik het lekker bij P regelaars houden.

[aMUSEd1985]

Ik heb ook geprobeerd een PI(D) in te regelen voor de ventilatie, maar mij lukte het niet om die zo ingesteld te krijgen dat die niet heel lang, op vol vermogen na bleef draaien. De I-component bleef te hoog. Ik heb het opgegeven en P-controller gebruikt en dat werkt als een zonnetje. Vind P-controller wel elegant, maar een gestaffelde sturing had waarschijnlijk ook prima gewerkt (en nog eenvoudiger)