Een aanwezigheidssensor die beweging ziet en daarna een lamp inschakelt, is vrij eenvoudig. Een systeem dat beslist of het op dat moment verstandiger is om te verwarmen, te ventileren, te wachten of juist niets te doen, vraagt veel meer informatie.
Dat is de richting waarin ik mijn eigen installatie de afgelopen tijd heb uitgebouwd. Niet door alles in één grote automatisering te stoppen, maar door verschillende onderdelen een eigen verantwoordelijkheid te geven.
Wat er in huis wordt gemeten
Ik gebruik onder meer temperatuur- en luchtvochtigheidssensoren in de ruimtes, aanwezigheidssensoren, een P1-meter en metingen van de zonnepanelen. Waar nodig komen daar lichtmetingen, apparaatstatussen en buitentemperaturen bij.
De losse sensoren zijn daarbij geen doel op zich. Ze beantwoorden verschillende vragen. Hoe warm voelt een ruimte aan? Is er iemand aanwezig of was er alleen kort beweging? Wordt het vochtiger door douchen? Hoeveel vermogen wordt er op dat moment uit het net gehaald? En hoe snel veranderen die waarden?
Een mmWave-aanwezigheidssensor kan bijvoorbeeld iets anders vertellen dan een traditionele bewegingssensor. Toch is ook een mmWave-meting geen onfeilbare waarheid. De positie van een sensor, vertragingen en onjuiste detectie kunnen de regeling beïnvloeden.
Daarom probeer ik niet blind op één signaal te vertrouwen wanneer de gevolgen groter zijn dan een lamp die een keer te laat uitschakelt.
Vier lagen met ieder een eigen taak
De huidige installatie is opgebouwd rond Home Assistant op mijn Proxmox-infrastructuur, met afzonderlijke diensten voor sensoren, berichtverkeer, regelingen en analyse. Niet alles draait op dezelfde virtuele machine of container.
Sensoren en koppelingen
Zigbee-apparaten leveren via Zigbee2MQTT en MQTT hun gegevens aan. Andere apparaten, zoals airco's en energiemeters, worden via hun eigen integraties of koppelingen uitgelezen. Het belangrijkste is dat de gegevens op één plek beschikbaar komen.
Home Assistant
Home Assistant vormt de centrale laag waarin de actuele status van ruimtes en apparaten samenkomt. Daar zijn ook bediening, dashboards en historische gegevens aan gekoppeld.
Node-RED
Node-RED gebruik ik voor de regels die meerdere voorwaarden en uitzonderingen combineren. Hier hoort de logica thuis die controleert of iets werkelijk uitgevoerd mag worden, bijvoorbeeld een minimale temperatuur, ventilatieprioriteit of handmatige override.
De ML-worker
De aparte ML-worker onderzoekt historische patronen en actuele omstandigheden. Daarmee kan hij advies geven over het moment of de manier waarop een apparaat aangestuurd wordt. De uitvoerende regels moeten zulke adviezen nog steeds kunnen afwijzen.
Dit betekent ook dat een defect model niet automatisch mag betekenen dat alle gewone basisfuncties stoppen.
Een eerdere technische rondleiding door mijn smarthome gaat dieper in op de infrastructuur.
Voorbeeld: is de woonkamer echt toe aan verwarming?
Stel dat de temperatuur onder de gewenste waarde komt. Dan lijkt verwarmen logisch. Maar ik wil eerst kunnen meewegen of de ruimte gebruikt wordt, wat de temperatuurtendens is, of een andere warmtebron al actief is en welke comfortgrenzen gelden.
Er kunnen ook andere factoren meespelen. De woonkamer grenst aan een open trap, waardoor warmte zich niet uitsluitend op de plek van de airco gedraagt. Zoninstraling en de buitentemperatuur beïnvloeden vervolgens hoe snel een ruimte afkoelt of opwarmt.
Het model kan helpen bij een inschatting van het toekomstige gedrag. Node-RED en Home Assistant moeten de daadwerkelijke actie echter binnen de geldende grenzen uitvoeren.
En als de verwarming niet aan gaat terwijl dat wel logisch lijkt, wil ik de reden kunnen terugvinden. Een beslissing zonder uitlegbare oorzaak is lastig te verbeteren.
Voorbeeld: ventileren zonder overbodig warmteverlies
Een hoge relatieve luchtvochtigheid kan reden zijn om meer te ventileren. Alleen zegt die meting niet automatisch of buitenlucht werkelijk helpt om vocht kwijt te raken.
Daarom neem ik ook buitenomstandigheden en het verloop in de tijd mee. Het systeem moet onderscheid kunnen maken tussen kortstondige vochtpieken en een situatie waarin echt extra ventilatie nodig is.
Dat bleek in de praktijk niet vanzelf goed te gaan. Ik heb regels moeten bijstellen om te voorkomen dat gewone aanwezigheid in een ruimte dezelfde boost gaf als douchen. In koudere periodes telt ook de hoeveelheid warmte mee die je door extra ventileren kwijt kunt raken.
De comfort- en luchtkwaliteitsgrenzen blijven daarbij leidend.
Voorbeeld: wanneer een lamp niet doet wat je verwacht
Het meest tastbare voorbeeld van een verkeerde regeling is soms een gewone lamp.
De keukenverlichting bleef eerder veel te lang branden na vertrek. Een aanpassing om sneller uit te schakelen leverde vervolgens een ander probleem op: de verlichting ging niet betrouwbaar aan of bleef niet aan bij gebruik.
Het is verleidelijk om dat steeds met één extra tijdvertraging of voorwaarde op te lossen. Maar dan stapel je uitzonderingen op zonder te begrijpen welk signaal het probleem veroorzaakt.
Ik probeer daarom steeds meer naar de volledige keten te kijken: detectie, timing, toestand, keuze en werkelijk apparaatgedrag. Pas dan is een aanpassing een verbetering in plaats van een volgende gok.
Waarom historische data nuttig is, en ook gevaarlijk kan zijn
Ik verzamel al jaren gegevens, maar meer data maakt een model niet automatisch betrouwbaarder. Een verkeerde sensor, afwijkend meetinterval of onjuist geïnterpreteerde gebeurtenis kan een schijnbaar overtuigende uitkomst geven.
Daarom kijk ik naar datakwaliteit en vergelijk ik nieuwe strategieën met bestaande regels. Een model mag een voorstel doen, maar het moet ook mogelijk blijven om een wijziging uit te stellen, terug te draaien of op een beperktere manier te testen.
Het doel van die extra laag is niet om een huis te bouwen waar alleen een programmeur nog in kan wonen. Ik wil juist dat normale bediening blijft werken en dat de techniek op de achtergrond betere keuzes maakt.
De volgende fase: van mooi schema naar dagelijks gedrag
De opzet werkt technisch, maar daarmee is het werk niet klaar. Nu de temperaturen dalen, komt de verwarmingsregeling in situaties die in de warmere maanden nog weinig voorkwamen.
Dat maakt de komende periode belangrijk. Ik wil kijken naar comfort per ruimte, het aantal handmatige correcties, onnodig schakelen, ventilatiegedrag en het energiegebruik dat daarbij hoort.
In mijn actuele verhaal over de eerste koudere periode beschrijf ik wat die praktijkcontrole inhoudt. In mijn eerdere artikel over de verschuiving van automatiseren naar slimmer sturen met data en historie leg ik uit waarom die verandering nodig was.