Mijn smarthome draait niet op één doosje: zo is de technische basis opgebouwd

In de vorige artikelen schreef ik over de verschillende onderdelen van onze gasloze woning.

De airco’s verzorgen een groot deel van de verwarming. De elektrische boiler maakt warm water. Infraroodpanelen kunnen lokaal extra comfort geven en de zonnepanelen leveren een deel van de benodigde elektriciteit.

Om al die onderdelen rekening met elkaar te laten houden, is meer nodig dan alleen een paar slimme stekkers en een Home Assistant-dashboard.

Achter de schermen draait een kleine infrastructuur van verschillende systemen die ieder een eigen taak hebben.

De basis daarvan is Proxmox.

Daarop draaien onder andere Home Assistant, Node-RED, MQTT en Zigbee2MQTT in afzonderlijke virtuele machines of containers.

Samen vormen die onderdelen de technische fundering van de woning.

Waarom niet alles op één systeem?

Het is mogelijk om Home Assistant relatief eenvoudig te installeren op een kleine computer en daar vrijwel alles op te laten draaien.

Voor veel woningen is dat een prima oplossing.

Mijn doel ging alleen steeds verder dan het bedienen van lampen, het bekijken van sensoren of het uitvoeren van enkele eenvoudige automatiseringen.

Ik wilde onder andere:

• verschillende klimaatregelingen beheren;
• energieverbruik en zonneproductie combineren;
• een centrale Energy Manager bouwen;
• gegevens tussen verschillende systemen uitwisselen;
• complexere beslislogica in Node-RED uitvoeren;
• Zigbee-apparaten lokaal beheren;
• geleerde waarden opslaan;
• dashboards en diagnose beschikbaar houden;
• onderdelen afzonderlijk kunnen onderhouden en herstellen.

Wanneer al die functies binnen één installatie draaien, ontstaat al snel een systeem waarin alles van alles afhankelijk wordt.

Een fout in één onderdeel kan dan gevolgen hebben voor de rest. Een update wordt spannender en het wordt lastiger om uit te zoeken waar een probleem precies ontstaat.

Daarom heb ik de infrastructuur opgedeeld.

Niet omdat ieder onderdeel per definitie een eigen server nodig heeft, maar omdat een duidelijke scheiding het systeem beter beheersbaar maakt.

Proxmox als basis

Proxmox is de virtualisatielaag onder de verschillende systemen.

In plaats van voor iedere toepassing een afzonderlijke fysieke computer te gebruiken, kan ik op één server meerdere kleinere virtuele systemen draaien.

Dat kunnen volledige virtuele machines zijn, maar ook lichtere containers.

Voor ieder onderdeel kan ik afzonderlijk bepalen:

• hoeveel rekenkracht het krijgt;
• hoeveel geheugen beschikbaar is;
• hoeveel opslag nodig is;
• wanneer het wordt gestart;
• hoe het wordt geback-upt;
• of het onafhankelijk opnieuw moet worden opgestart.

Daardoor voelt de server niet als één grote computer waarop toevallig allerlei programma’s zijn geïnstalleerd.

Het is meer een klein platform waarop verschillende gespecialiseerde diensten samenwerken.

Home Assistant als centrale laag

Home Assistant vormt het zichtbare middelpunt.

Hier komen apparaten, sensoren, instellingen, dashboards en historische gegevens samen.

Home Assistant weet bijvoorbeeld:

• wat de temperatuur in een ruimte is;
• of iemand aanwezig is;
• hoeveel vermogen de zonnepanelen leveren;
• hoeveel stroom er van of naar het net gaat;
• wat de temperatuur van de boiler is;
• welke airco actief is;
• op welke stand de ventilatie draait;
• welke apparaten energie gebruiken.

Ook staan hier de instelbare waarden die ik via dashboards kan aanpassen.

Denk aan:

• gewenste temperaturen;
• minimale warmwatertemperatuur;
• maximale netbelasting;
• minimale draaitijden;
• ingestelde deadlines;
• handmatige overrides;
• onderhoudsgrenzen.

Home Assistant is daarmee niet alleen een afstandsbediening voor apparaten.

Het is de centrale omgeving waarin de actuele toestand van de woning zichtbaar en instelbaar wordt.

Node-RED voor de uitgebreidere beslissingen

Eenvoudige automatiseringen kunnen prima rechtstreeks in Home Assistant worden gemaakt.

Bijvoorbeeld:

Als een deur opengaat, zet dan een lamp aan.

De regelingen in onze woning bestaan vaak uit meer voorwaarden.

De boiler mag bijvoorbeeld alleen op zonne-energie verwarmen wanneer:

• er voldoende overschot beschikbaar is;
• dat overschot lang genoeg aanwezig is;
• de boiler niet kort geleden is gestopt;
• de watertemperatuur nog niet op het hogere doel zit;
• de totale netbelasting binnen de ingestelde grens blijft;
• er geen belangrijker apparaat voorrang heeft.

Wanneer de boiler eenmaal draait, gelden weer andere voorwaarden om hem door te laten gaan.

Daarvoor gebruik ik Node-RED.

Node-RED maakt het mogelijk om informatie uit verschillende bronnen te combineren en stap voor stap door een beslisflow te sturen.

Ik kan daarmee niet alleen bepalen wat er moet gebeuren, maar ook vastleggen waarom een beslissing is genomen.

Bijvoorbeeld:

• wachten vanwege onvoldoende zonneproductie;
• geblokkeerd vanwege een minimale pauzetijd;
• starten omdat de watertemperatuur het minimum nadert;
• tijdelijk terugschakelen vanwege een lopend wasprogramma;
• niets doen omdat het apparaat al in de juiste toestand staat.

Dat maakt de automatisering beter te volgen dan wanneer er alleen een opdracht wordt uitgevoerd zonder verdere uitleg.

MQTT als berichtenlaag

Verschillende onderdelen van de infrastructuur moeten voortdurend informatie met elkaar kunnen uitwisselen.

Daarvoor gebruik ik MQTT.

MQTT is een relatief lichte manier om berichten tussen systemen te versturen.

Een apparaat of dienst kan informatie publiceren, waarna andere onderdelen die informatie kunnen ontvangen en gebruiken.

Dat kan bijvoorbeeld gaan over:

• een nieuwe temperatuurmeting;
• een verandering in aanwezigheid;
• de status van een apparaat;
• een schakelopdracht;
• een diagnostische waarde;
• een nieuwe instelling.

MQTT voorkomt dat ieder systeem rechtstreeks een aparte koppeling met alle andere onderdelen nodig heeft.

Een sensor kan zijn waarde publiceren zonder precies te hoeven weten welke automatisering die waarde later gebruikt.

Dat maakt uitbreiden eenvoudiger.

Wanneer ik later een nieuwe regeling toevoeg, kan die gebruikmaken van bestaande meetwaarden zonder dat de sensor zelf aangepast hoeft te worden.

Zigbee2MQTT voor Zigbee-apparaten

Veel kleinere sensoren en schakelaars in de woning communiceren via Zigbee.

Denk aan:

• temperatuur- en luchtvochtigheidssensoren;
• bewegingssensoren;
• aanwezigheidssensoren;
• knoppen;
• slimme stekkers;
• relais;
• deur- en raamcontacten.

Zigbee2MQTT verzorgt de communicatie met deze apparaten.

De Zigbee-apparaten worden lokaal gekoppeld en hun gegevens worden via MQTT beschikbaar gemaakt voor de rest van de infrastructuur.

Dat heeft voor mij verschillende voordelen.

Ik ben minder afhankelijk van losse apps en afzonderlijke cloudplatforms. Ook kan ik apparaten van verschillende fabrikanten binnen dezelfde infrastructuur gebruiken.

Een sensor hoeft niet van hetzelfde merk te zijn als de slimme stekker of het relais dat uiteindelijk wordt aangestuurd.

Home Assistant en Node-RED kijken vooral naar de informatie en mogelijkheden die beschikbaar zijn, niet naar het logo op het apparaat.

Een voorbeeld: douchen en ventilatie

De samenwerking tussen de verschillende onderdelen wordt duidelijker met een concreet voorbeeld.

Wanneer iemand gaat douchen, stijgt de luchtvochtigheid in de badkamer.

Een sensor meet die verandering en stuurt de waarde via Zigbee door. Zigbee2MQTT maakt de meting beschikbaar via MQTT. Home Assistant registreert de actuele luchtvochtigheid en Node-RED beoordeelt of de ventilatie naar een hogere stand moet.

Daarbij kan de flow rekening houden met:

• de huidige luchtvochtigheid;
• hoe snel deze stijgt;
• aanwezigheid in de badkamer;
• de huidige ventilatiestand;
• de maximale looptijd;
• de gewenste nalooptijd.

Vervolgens wordt het juiste relais aangestuurd en wordt de gekozen reden zichtbaar in Home Assistant.

De mechanische ventilatie zelf is nog steeds oude meuk.

Door de infrastructuur eromheen reageert hij alleen wel een stuk verstandiger dan toen hij afhankelijk was van een statische knop in de keuken.

Sinds ik de ventilatie zo heb ingericht, heb ik geen beslagen spiegel meer gehad.

Dat resultaat komt dus niet uit één slimme ventilatiebox. Het ontstaat doordat meerdere eenvoudige onderdelen informatie met elkaar delen.

Een voorbeeld: de Energy Manager

Bij energiebeheer wordt de samenwerking nog uitgebreider.

De Energy Manager gebruikt informatie over:

• zonneproductie;
• actuele netbelasting;
• werkelijk verbruik van apparaten;
• boilertemperatuur;
• klimaatstatus;
• lopende programma’s;
• ingestelde comfortgrenzen;
• beschikbare flexibiliteit.

Home Assistant verzamelt en toont de waarden. Node-RED gebruikt ze voor de beslislogica. MQTT helpt bij het uitwisselen van gegevens en opdrachten. Energiemeters en sensoren leveren de werkelijke metingen.

Stel dat de wasmachine is voorbereid en vóór een bepaalde tijd klaar moet zijn.

De Energy Manager kan later het verwachte programma, de zonneproductie en de andere verbruikers gebruiken om een geschikt startmoment te kiezen.

Zodra de wasmachine werkelijk begonnen is, mag deze niet meer worden onderbroken.

Vanaf dat moment kunnen andere flexibele apparaten tijdelijk ruimte maken.

De boiler kan bijvoorbeeld wachten zolang het water warm genoeg blijft. Een infraroodpaneel kan tijdelijk worden uitgeschakeld. De klimaatregeling kan binnen vooraf ingestelde of later geleerde grenzen terugschakelen.

Zo ontstaat een keten van beslissingen die veel verder gaat dan:

Er is zon, dus zet een slimme stekker aan.

Waarom lokale aansturing belangrijk is

Een belangrijk deel van de infrastructuur draait lokaal.

Dat betekent dat de centrale regelingen niet volledig afhankelijk zijn van externe cloudautomatiseringen.

Dat heeft verschillende voordelen:

• kortere reactietijden;
• meer controle over gegevens;
• minder afhankelijkheid van diensten van fabrikanten;
• automatiseringen blijven vaker werken wanneer internet uitvalt;
• apparaten van verschillende merken kunnen centraal samenwerken;
• ik bepaal zelf wanneer onderdelen worden aangepast.

Niet ieder apparaat werkt volledig lokaal.

De boiler gebruikt bijvoorbeeld nog een eigen koppeling en sommige apparatuur blijft afhankelijk van de mogelijkheden die de fabrikant beschikbaar stelt.

Toch probeer ik de centrale logica zoveel mogelijk in mijn eigen infrastructuur te houden.

Een apparaat mag van mij best een cloudverbinding gebruiken. Ik wil alleen niet dat de complete woning onbruikbaar wordt wanneer één externe dienst tijdelijk niet bereikbaar is.

Onderdelen afzonderlijk kunnen herstellen

Een van de voordelen van de Proxmox-opzet is dat ik onderdelen afzonderlijk kan beheren.

Wanneer Node-RED opnieuw moet worden gestart, hoeft Home Assistant niet automatisch mee.

Wanneer ik Zigbee2MQTT bijwerk, blijven de andere virtuele systemen bestaan.

Ook kunnen per onderdeel back-ups of snapshots worden gemaakt.

Dat betekent niet dat er nooit iets misgaat.

Juist tijdens het bouwen kwam ik situaties tegen waarin gegevens na een herstart niet op de juiste manier terugkwamen. Sommige geleerde waarden bleken alleen in tijdelijk geheugen te staan of werden bij het starten door standaardwaarden overschreven.

Daardoor werd duidelijk dat niet alleen de actieve regeling belangrijk is.

Ik moet ook nadenken over:

• waar gegevens worden opgeslagen;
• wat er na een herstart gebeurt;
• welke waarde leidend is;
• hoe een onderdeel zijn vorige status herstelt;
• wat er gebeurt als een sensor tijdelijk niet beschikbaar is.

Een slimme woning die na iedere herstart opnieuw moet beginnen met leren, is uiteindelijk niet erg slim.

Daarom sla ik belangrijke instellingen en leerwaarden blijvend op en laat ik de automatiseringen deze bij het starten opnieuw inlezen.

Die foutanalyse verdient later een eigen artikel.

Niet iedere storing mag het huis stilleggen

Een ander belangrijk uitgangspunt is fouttolerantie.

Wanneer een buitensensor tijdelijk geen waarde doorgeeft, moet de klimaatregeling niet automatisch een onlogische beslissing nemen.

Wanneer de zonneproductie niet beschikbaar is, moet de boiler kunnen terugvallen op veilige temperatuurgrenzen.

Wanneer Node-RED opnieuw wordt gestart, moeten de airco’s niet direct allemaal onverwacht omschakelen.

Daarom probeer ik onderscheid te maken tussen:

• een geldige meting;
• een ontbrekende meting;
• een oude meting;
• een onwaarschijnlijke waarde;
• een handmatige instelling;
• een automatische beslissing.

Niet iedere afwijking hoeft direct te worden opgelost. Soms is tijdelijk niets doen de veiligste keuze.

Dashboards zijn niet alleen voor mooie grafieken

Home Assistant-dashboards zijn het zichtbare deel van de infrastructuur.

Ze geven mij bediening en inzicht, maar hun belangrijkste functie is niet dat alles er mooi uitziet.

Ik wil kunnen zien:

• wat een regeling op dit moment doet;
• waarom een apparaat aan of uit staat;
• welke grens actief is;
• hoeveel vermogen beschikbaar is;
• of een waarde betrouwbaar is;
• hoeveel geldige metingen verzameld zijn;
• wanneer een timer afloopt;
• of een handmatige override actief is.

Wanneer een automatisering onverwacht gedrag vertoont, moet ik niet eerst verschillende systemen doorzoeken om te begrijpen wat er gebeurt.

De diagnose hoort onderdeel van het ontwerp te zijn.

Monitoring van de infrastructuur zelf

De woning kan alleen slim worden aangestuurd wanneer de onderliggende infrastructuur betrouwbaar blijft draaien.

Daarom wil ik uiteindelijk niet alleen de woning, maar ook de serveromgeving beter monitoren.

Denk aan:

• processorbelasting;
• geheugengebruik;
• beschikbare opslag;
• temperatuur van de hardware;
• bereikbaarheid van virtuele machines;
• mislukte back-ups;
• ongebruikelijk energieverbruik;
• diensten die niet meer reageren.

Ook het energiegebruik van de IT-infrastructuur zelf hoort daarbij.

Het zou vreemd zijn om uitgebreid te optimaliseren wanneer de servers, computers en netwerkapparatuur ongemerkt een groot deel van het sluipverbruik veroorzaken.

Dat wordt later een apart onderdeel van de serie.

Niet iedereen heeft deze opzet nodig

Ik wil niet de indruk wekken dat iedere Home Assistant-gebruiker direct Proxmox, meerdere virtuele machines en losse containers nodig heeft.

Voor een beperkt aantal apparaten kan één Home Assistant-installatie veel eenvoudiger en logischer zijn.

Mijn infrastructuur is meegegroeid met het project.

De opdeling wordt interessant omdat:

• steeds meer systemen samenwerken;
• de automatiseringen complexer worden;
• belangrijke gegevens behouden moeten blijven;
• diagnose en monitoring belangrijker worden;
• ik onderdelen afzonderlijk wil kunnen beheren;
• toekomstige uitbreidingen ruimte nodig hebben.

De juiste opzet hangt dus af van het doel.

Een simpele automatisering moet simpel blijven. Complexiteit toevoegen zonder duidelijke reden maakt een systeem niet professioneler.

De technische basis maakt verdere optimalisatie mogelijk

Proxmox, Home Assistant, Node-RED, MQTT en Zigbee2MQTT zijn afzonderlijk geen energiebesparing.

Ze vormen de infrastructuur waarmee ik informatie kan verzamelen, beslissingen kan nemen en bestaande apparaten beter kan laten samenwerken.

De werkelijke waarde ontstaat pas wanneer de techniek een concreet probleem oplost.

Zoals:

• geen beslagen spiegel meer na het douchen;
• een melding wanneer een aircofilter gereinigd moet worden;
• de boiler laten wachten op een gunstiger moment;
• een wasprogramma op tijd afronden zonder onnodige piekbelasting;
• lokale warmte gebruiken waar iemand daadwerkelijk zit;
• later herkennen dat een apparaat afwijkend begint te presteren.

De techniek op de achtergrond mag uitgebreid zijn.

Voor ons moet het resultaat uiteindelijk juist eenvoudiger worden.

In het volgende artikel ga ik dieper in op de klimaatregeling. De airco’s werden vanaf het begin al aangestuurd met externe temperatuursensoren en een eigen thermostaat per verdieping. Toch bleek daar nog voldoende ruimte te zijn voor verdere optimalisatie, zoals het combineren van meerdere sensoren en het leren hoe snel iedere zone werkelijk opwarmt en afkoelt.

Dit is een persoonlijk praktijkproject. Vanuit Floor-IT pas ik dezelfde manier van denken toe op IT, automatisering en slimme integraties voor bedrijven.