Van losse automatiseringen naar een begrijpelijk systeem

In het vorige hoofdstuk heb je gezien hoe je automatiseringen betrouwbaarder maakt. Je controleert wat er gebeurt, voorkomt onduidelijke afhankelijkheden en probeert rekening te houden met situaties waarin iets anders loopt dan verwacht.

Maar er ontstaat na verloop van tijd een nieuw probleem.

Niet één automatisering wordt ingewikkeld.

Het zijn er ineens twintig.

Of vijftig.

En afzonderlijk lijken ze allemaal best logisch.

De lamp in De Werkplaats gaat aan wanneer het donker is.
De verwarming schakelt lager wanneer niemand aanwezig is.
De buitenverlichting reageert op zonsondergang.
De ventilator start bij een hoge luchtvochtigheid.

Allemaal keurige automatiseringen.

Toch kun je na een tijdje voor je dashboard zitten en denken:

Waarom is die lamp eigenlijk aan?

Dat is het moment waarop je niet meer alleen automatiseringen aan het bouwen bent.

Je bent een systeem aan het bouwen.

En een goed systeem moet niet alleen werken.

Je moet het later ook nog kunnen begrijpen.

Wanneer losse automatiseringen elkaar gaan beïnvloeden

Stel dat we in De Werkplaats een plafondlamp hebben.

We beginnen eenvoudig:

Als het donker wordt en er beweging wordt gedetecteerd, zet de lamp aan.

Later voegen we een tweede automatisering toe:

Als er tien minuten geen beweging is geweest, zet de lamp uit.

Daarna komt er nog één:

Als je aan het werk bent, mag de lamp niet automatisch uitgaan.

En vervolgens:

Om 23:30 moet alle verlichting worden uitgeschakeld.

Elke regel is afzonderlijk goed te begrijpen.

Maar kijk nu eens naar een mogelijke situatie.

Het is 22:45.
Je bent in De Werkplaats bezig.
De lamp is aan.
Er wordt even geen beweging gemeten.

Wat gebeurt er?

Dat hangt inmiddels van meerdere automatiseringen af.

Misschien schakelt de bewegingsautomatisering de lamp uit.

Misschien voorkomt de werkmodus dat.

Misschien zet een andere automatisering hem enkele seconden later weer aan.

Het probleem zit dan niet noodzakelijk in één foutieve automatisering.

Het probleem is dat verschillende automatiseringen dezelfde toestand proberen te bepalen.

Eén apparaat, meerdere bazen

Een handige vraag is daarom:

Hoeveel automatiseringen mogen dit apparaat bedienen?

Dat hoeft niet altijd precies één te zijn.

Maar wanneer vijf verschillende automatiseringen allemaal light.turn_on en light.turn_off gebruiken voor dezelfde lamp, wordt het steeds moeilijker om te voorspellen wat er gebeurt.

Dat geldt bijvoorbeeld voor:

• verlichting;
• verwarming;
• rolluiken;
• ventilatie;
• slimme stekkers;
• meldingen;
• aanwezigheidssimulatie.

Hoe meer automatiseringen rechtstreeks hetzelfde apparaat besturen, hoe groter de kans dat ze elkaar tegenwerken.

Je kunt dat vergelijken met een werkplaats waarin vijf mensen tegelijk bepalen of een machine aan of uit moet.

Iedereen heeft misschien een goede reden.

Maar niemand heeft nog het volledige overzicht.

Denk eerst in gedrag

Wanneer een systeem groter wordt, helpt het om niet meer te beginnen bij een sensor of apparaat.

Begin bij het gewenste gedrag.

Niet:

Ik heb een bewegingssensor. Wat kan ik daarmee automatiseren?

Maar:

Wanneer moet De Werkplaats verlicht zijn?

Dat lijkt een klein verschil, maar het verandert de manier waarop je ontwerpt.

Je kunt bijvoorbeeld tot deze beschrijving komen:

Tijdens normale uren moet het licht aan wanneer iemand aanwezig is én het buiten donker genoeg is. Tijdens werkzaamheden mag het licht blijven branden. 's Nachts moet het licht altijd uit, tenzij ik het bewust handmatig heb ingeschakeld.

Dit is nog geen Home Assistant-configuratie.

Dat is juist de bedoeling.

Je beschrijft eerst wat het systeem moet doen.

Pas daarna bepaal je welke sensoren, helpers, voorwaarden en acties daarvoor nodig zijn.

Schrijf de regels eerst in gewone taal

Bij grotere automatiseringen is dit een bijzonder nuttige gewoonte.

Schrijf eerst de beslisregels op.

Bijvoorbeeld voor De Werkplaats:

• Overdag is de verlichting normaal uit.
• Bij onvoldoende buitenlicht mag de verlichting automatisch aan.
• Dat gebeurt alleen wanneer iemand aanwezig is.
• Tijdens werkmodus blijft de verlichting aan.
• Na tien minuten zonder aanwezigheid mag de verlichting uit.
• Na 23:30 wordt automatisch inschakelen geblokkeerd.
• Handmatige bediening moet altijd mogelijk blijven.

Lees die regels nog eens zonder aan Home Assistant te denken.

Kun je voorspellen wat er gebeurt?

Dan heb je een redelijke basis.

Ontdek je nu al tegenstrijdigheden, dan is dat juist nuttig.

Het is veel eenvoudiger om een zin te veranderen dan later vijf automatiseringen te debuggen.

Van apparaten naar toestanden

Tot nu toe hebben we vaak direct naar apparaten gekeken.

Een lamp is aan of uit.

Een schakelaar staat aan of uit.

Maar een groter automatiseringssysteem wordt overzichtelijker wanneer je ook kijkt naar de toestand van de ruimte.

Denk bijvoorbeeld aan:

• niemand aanwezig;
• iemand aanwezig;
• werkmodus actief;
• nachtmodus actief;
• voldoende daglicht;
• onvoldoende daglicht.

Sommige van die toestanden komen rechtstreeks van sensoren.

Andere kun je zelf vastleggen met helpers.

Een input_boolean kan bijvoorbeeld aangeven:

Werkmodus is actief.

Dat is begrijpelijker dan wanneer drie verschillende automatiseringen proberen af te leiden of je waarschijnlijk aan het werk bent.

Je hebt daarmee één duidelijke toestand waarop andere onderdelen kunnen reageren.

Geef belangrijke toestanden een naam

Dat is een belangrijk ontwerpprincipe:

Maak belangrijke beslissingen zichtbaar.

Stel dat de verlichting alleen automatisch mag werken wanneer:

• het tussen 07:00 en 23:30 is;
• iemand aanwezig is;
• het buiten donkerder is dan 400 lux.

Je zou al deze voorwaarden telkens opnieuw in verschillende automatiseringen kunnen opnemen.

Maar als die logica belangrijker wordt, kun je ook gaan denken in een duidelijke toestand zoals:

Automatische verlichting toegestaan.

Dat hoeft niet meteen een nieuwe helper of templatesensor te betekenen.

Het belangrijkste is eerst dat je zelf herkent dat deze combinatie een betekenis heeft.

Zodra een combinatie van voorwaarden regelmatig terugkomt, verdient die vaak een duidelijke naam.

Daarmee maak je van losse technische voorwaarden een begrijpelijk concept.

Herhaal belangrijke logica niet overal

Stel dat drie automatiseringen allemaal controleren:

• of het een werkdag is;
• of het na 07:00 is;
• of het vóór 23:30 is;
• of de lichtsensor minder dan 400 lux meet.

Dat werkt.

Maar stel dat je later besluit dat 400 lux eigenlijk 300 lux moet zijn.

Dan moet je drie automatiseringen aanpassen.

Vergeet je er één, dan gedragen ze zich verschillend.

Dat soort verschillen zijn vervelend omdat ze niet direct zichtbaar zijn.

Je kunt zulke gedeelde waarden daarom beter centraliseren.

Bijvoorbeeld met een numerieke helper waarin je de lichtgrens opslaat.

Conceptueel wordt het dan:

Als de gemeten lichtsterkte lager is dan de ingestelde lichtgrens…

in plaats van:

Als de gemeten lichtsterkte lager is dan 400…

Het voordeel is niet alleen dat je de waarde gemakkelijker verandert.

Je maakt duidelijk dat die grens onderdeel is van het systeemontwerp.

Gebruik helpers als instellingen

In het hoofdstuk over helpers zag je al dat Home Assistant daarmee geheugen en instellingen kan krijgen.

In een groter systeem worden helpers nog waardevoller.

Een input_number kan bijvoorbeeld de grens voor buitenlicht bevatten.

Een input_boolean kan werkmodus aangeven.

Een input_datetime kan aangeven tot welk tijdstip automatische verlichting actief mag zijn.

Zo verschuift informatie uit je automatiseringen naar herkenbare instellingen.

Je automatisering hoeft dan niet meer te weten:

23:30 betekent het einde van de normale periode.

Hij kan simpelweg controleren:

Is automatische verlichting nu toegestaan?

Dat maakt de automatisering zelf eenvoudiger.

En eenvoudiger is meestal beter te controleren.

Laat apparaten niet onnodig rechtstreeks op elkaar reageren

Stel dat de lichtsensor minder dan 400 lux meet.

Je zou dan direct kunnen zeggen:

Sensor onder 400 lux → lamp aan.

Maar er ontbreekt informatie.

Is iemand thuis?

Is iemand in De Werkplaats?

Is het midden in de nacht?

Staat de ruimte in werkmodus?

Is de lamp misschien bewust handmatig uitgezet?

Een sensor vertelt iets over de werkelijkheid.

Hij hoeft niet automatisch te bepalen wat het systeem moet doen.

Een betere gedachte is:

De lichtsensor levert informatie waarmee het systeem een beslissing kan nemen.

Dat onderscheid wordt steeds belangrijker wanneer je meer apparaten toevoegt.

Sensoren meten.

Helpers onthouden.

Automatiseringen beslissen.

Scripts voeren herbruikbare handelingen uit.

Apparaten voeren acties uit.

Dat is geen harde technische regel van Home Assistant.

Het is een manier om je systeem begrijpelijk te houden.

Een voorbeeld uit De Werkplaats

Laten we het verlichtingssysteem iets netter ontwerpen.

We hebben:

• een aanwezigheidssensor;
• een buitensensor die lux meet;
• een plafondlamp;
• een helper voor werkmodus;
• een instelbare grenswaarde voor de lichtsterkte.

Onze gewenste regel wordt:

Wanneer iemand aanwezig is en het donkerder is dan de ingestelde grens, mag de verlichting aan. In werkmodus blijft de verlichting aan. Wanneer niemand meer aanwezig is en werkmodus niet actief is, mag de verlichting na tien minuten uit.

Let op het woord mag.

We maken onderscheid tussen:

• informatie;
• voorwaarden;
• uiteindelijke actie.

Dat maakt het gemakkelijker om later nog een regel toe te voegen.

Bijvoorbeeld:

Na 23:30 mag automatische verlichting niet meer starten.

Je hoeft dan niet je hele systeem opnieuw te bedenken.

Je voegt een nieuwe voorwaarde toe aan het bestaande gedrag.

Maak één plek verantwoordelijk voor een beslissing

Een nuttig streven is:

Eén logische beslissing heeft bij voorkeur één duidelijke eigenaar.

Voor de verlichting zou je bijvoorbeeld één hoofdautomatisering kunnen gebruiken die bepaalt wanneer de lamp aan of uit moet.

Je kunt daarin eventueel choose gebruiken.

Conceptueel:

ALS werkmodus actief is

lamp aan

ANDERS ALS iemand aanwezig is EN het donker genoeg is

lamp aan

ANDERS ALS niemand aanwezig is

lamp uit

Dit is niet automatisch beter dan meerdere kleine automatiseringen.

Soms zijn meerdere automatiseringen juist duidelijker.

Het belangrijkste is dat je bewust kiest.

Vraag jezelf af:

Waar kijk ik als ik wil weten waarom deze lamp aanstaat?

Als het antwoord luidt:

Dat kan in één van zeven automatiseringen zitten…

dan is het systeem waarschijnlijk moeilijker geworden dan nodig.

Klein hoeft niet hetzelfde te betekenen als versnipperd

Je hebt eerder gezien dat kleine automatiseringen prettig kunnen zijn.

Dat blijft zo.

Je hoeft dus niet alles in één enorme automatisering te stoppen.

Een automatisering van honderden regels waarin verlichting, verwarming, ventilatie en meldingen door elkaar lopen, wordt evenmin begrijpelijk.

Het doel is niet:

Zo weinig mogelijk automatiseringen.

Het doel is:

Elke automatisering heeft een duidelijke verantwoordelijkheid.

Bijvoorbeeld:

Werkplaats — Verlichting automatisch aan

Regelt alleen het automatisch inschakelen.

Werkplaats — Verlichting automatisch uit

Regelt alleen het automatisch uitschakelen.

Werkplaats — Nachtbeveiliging

Voorkomt dat bepaalde apparatuur 's nachts actief blijft.

Aan de namen kun je al zien wat hun taak is.

Dat helpt later enorm.

Gebruik consequente namen

Zodra je meer automatiseringen hebt, worden goede namen belangrijk.

Een naam zoals:

Automatisering 27

vertelt je niets.

Ook:

Bewegingssensor lamp

kan na verloop van tijd onduidelijk worden.

Een herkenbare structuur helpt.

Bijvoorbeeld:

Werkplaats — Verlichting — Aan bij aanwezigheid

Werkplaats — Verlichting — Uit bij afwezigheid

Werkplaats — Ventilatie — Aan bij hoge luchtvochtigheid

Woonkamer — Verlichting — Avond

Je kunt daarbij denken in:

ruimte — functie — gedrag

Welke naamstructuur je kiest is minder belangrijk dan dat je consequent bent.

Je wilt later op het woord Werkplaats kunnen zoeken en direct alle relevante automatiseringen herkennen.

Beschrijvingen zijn geen overbodige luxe

Bij een eenvoudige automatisering lijkt een beschrijving misschien overbodig.

Je ziet immers direct wat hij doet.

Maar over een jaar weet je mogelijk niet meer waarom je een bepaalde wachttijd hebt gekozen.

Stel dat er staat:

Wacht 7 minuten voordat de lamp wordt uitgeschakeld.

Waarom zeven?

Misschien bleek uit testen dat vijf minuten te kort was.

Of misschien heeft je aanwezigheidssensor een bepaalde updatefrequentie.

Schrijf dat op.

Bijvoorbeeld:

Zeven minuten gekozen zodat korte perioden zonder gedetecteerde beweging niet direct tot uitschakelen leiden.

Nu weet je later niet alleen wat je hebt ingesteld.

Je weet ook waarom.

Dat verschil is belangrijk bij onderhoud.

Documenteer uitzonderingen

De normale situatie is meestal eenvoudig.

De uitzonderingen maken een systeem ingewikkeld.

Bijvoorbeeld:

Licht aan bij aanwezigheid.

Eenvoudig.

Maar daarna komen de uitzonderingen:

• niet overdag;
• wel tijdens werkmodus;
• niet na 23:30;
• wel bij handmatige bediening;
• niet wanneer vakantie-modus actief is.

Juist die uitzonderingen moet je zichtbaar maken.

Wanneer je merkt dat een automatisering veel uitzonderingen bevat, schrijf ze dan eerst onder elkaar.

Vraag jezelf vervolgens af:

Zijn dit werkelijk uitzonderingen, of probeer ik meerdere verschillende situaties in één automatisering te stoppen?

Dat kan aanleiding zijn om de structuur opnieuw te bekijken.

Handmatige bediening hoort bij het ontwerp

Een slimme woning moet niet alleen automatisch werken.

Je moet hem ook gewoon kunnen bedienen.

Dat klinkt vanzelfsprekend, maar automatiseringen kunnen handmatige keuzes ongemerkt weer ongedaan maken.

Stel:

Je schakelt de lamp handmatig uit.

Vijf seconden later detecteert de bewegingssensor opnieuw beweging.

De lamp gaat weer aan.

Technisch werkt de automatisering perfect.

Voor jou voelt hij irritant.

Daarom hoort deze vraag bij het ontwerp:

Wat moet er gebeuren wanneer ik zelf ingrijp?

Mogelijke keuzes zijn:

• automatisering blijft altijd leidend;
• handmatige bediening krijgt tijdelijk voorrang;
• automatisering blijft uit tot de volgende trigger;
• een helper schakelt automatische bediening tijdelijk uit.

Er bestaat geen universeel juiste keuze.

Maar je moet er wel over nadenken.

Ontwerp ook wat er gebeurt na een herstart

Een systeem bestaat niet alleen tijdens normaal gebruik.

Home Assistant kan opnieuw starten.

Een sensor kan tijdelijk unavailable zijn.

Een apparaat kan offline zijn.

Een helper kan een oude toestand bevatten.

Vraag daarom bij belangrijke automatiseringen:

Welke informatie is nodig om na een herstart weer tot de juiste toestand te komen?

Een systeem dat alleen goed werkt wanneer gebeurtenissen precies in de juiste volgorde hebben plaatsgevonden, is kwetsbaar.

Een begrijpelijk systeem kan zo veel mogelijk opnieuw bepalen wat de huidige situatie hoort te zijn.

Bijvoorbeeld:

Niet alleen:

Om 18:00 lamp aan.

Maar mogelijk:

Wanneer Home Assistant start én het is tussen 18:00 en 23:00 én het is donker, controleer of de lamp aan moet zijn.

Of dat nodig is, hangt af van de toepassing.

Maar de gedachte erachter is belangrijk:

Ontwerp niet alleen gebeurtenissen. Denk ook aan toestand.

Geef veiligheid altijd voorrang

Sommige acties mogen nooit afhankelijk zijn van een ingewikkelde keten die je zelf nauwelijks nog kunt volgen.

Denk aan:

• verwarming;
• boilers;
• pompen;
• apparatuur met hoge vermogens;
• apparaten die schade kunnen veroorzaken wanneer ze te lang ingeschakeld blijven.

Daar wil je duidelijke grenzen hebben.

Bijvoorbeeld:

De boiler mag alleen inschakelen wanneer aan de normale voorwaarden is voldaan.

Maar daarnaast:

Boven een bepaalde temperatuur altijd uitschakelen.

Die tweede regel is geen slimme optimalisatie.

Het is een harde begrenzing.

Hoe belangrijker de functie, hoe duidelijker zulke veiligheidsregels moeten zijn.

Bouw in lagen

Een grotere Home Assistant-installatie kun je zien als een aantal lagen.

Onderaan zitten de apparaten en sensoren.

Daarboven zitten de toestanden en instellingen.

Daarboven komt de beslislogica.

En uiteindelijk volgen de acties.

Bijvoorbeeld:

Sensoren

↓

aanwezigheid + lichtsterkte + tijd

Toestanden en instellingen

↓

werkmodus + lichtgrens + nachtmodus

Beslissing

↓

moet de verlichting aan zijn?

Actie

↓

lamp aan of lamp uit

Je hoeft Home Assistant technisch niet precies zo in te richten.

Maar deze manier van denken voorkomt dat alles rechtstreeks met alles verbonden raakt.

Voorspel eerst het systeemgedrag

Wanneer je een nieuw onderdeel toevoegt, doe dan hetzelfde als bij eerdere experimenten.

Voorspel eerst wat er gebeurt.

Stel dat je een nachtmodus toevoegt.

Schrijf voor jezelf op:

Ik verwacht dat de lamp na 23:30 niet meer automatisch aangaat, behalve wanneer werkmodus actief is.

Test vervolgens een paar situaties:

Daarna voer je de situaties werkelijk uit.

Zo controleer je niet alleen of een afzonderlijke automatisering wordt uitgevoerd.

Je controleert of het systeemgedrag klopt.

Verander één regel tegelijk

Bij grotere systemen wordt dit nog belangrijker.

Stel dat je tegelijk:

• de luxgrens verandert;
• een nachtmodus toevoegt;
• de uitschakelvertraging wijzigt;
• een nieuwe aanwezigheidssensor toevoegt.

En daarna werkt de verlichting niet meer zoals verwacht.

Waar begin je?

Je hebt vier variabelen tegelijk veranderd.

Doe daarom hetzelfde wat je bij storingzoeken al hebt geleerd:

Verander één onderdeel en controleer het effect.

Pas de lichtgrens aan.

Test.

Voeg daarna nachtmodus toe.

Test opnieuw.

Zo weet je bij welk onderdeel het gedrag veranderde.

Wanneer moet je opnieuw ontwerpen?

Een automatisering hoeft niet perfect te zijn.

En je hoeft een werkend systeem niet voortdurend te herschrijven.

Maar er zijn signalen dat de structuur aandacht nodig heeft.

Bijvoorbeeld wanneer je regelmatig denkt:

Ik weet niet meer welke automatisering dit doet.

Of:

Als ik deze verander, weet ik niet wat er ergens anders stukgaat.

Of:

Deze voorwaarde staat inmiddels op zes verschillende plaatsen.

Of:

Ik durf deze automatisering eigenlijk niet meer aan te passen.

Dat zijn geen tekenen dat Home Assistant te ingewikkeld is.

Het zijn aanwijzingen dat de structuur niet meer overeenkomt met hoe groot het systeem geworden is.

Dan is opnieuw indelen vaak zinvoller dan nog een extra voorwaarde toevoegen.

Eenvoud is geen gebrek aan mogelijkheden

Wanneer je meer ervaring krijgt met Home Assistant, kom je steeds meer mogelijkheden tegen.

Templates.

Blueprints.

Scripts.

Helpers.

Events.

Complexe voorwaarden.

Meerdere triggers.

Dat betekent niet dat je ze allemaal moet gebruiken.

Een goed ontworpen systeem gebruikt niet de meeste technieken.

Het gebruikt precies genoeg techniek om het gewenste gedrag duidelijk en betrouwbaar uit te voeren.

Als drie eenvoudige regels voldoende zijn, zijn drie eenvoudige regels vaak beter dan één slimme template die niemand over zes maanden meer begrijpt.

Ook jijzelf niet.

De belangrijkste vraag verandert

Aan het begin van deze gids was een belangrijke vraag:

Hoe krijg ik Home Assistant zover dat dit automatisch gebeurt?

Nu komt daar een tweede vraag bij:

Hoe zorg ik dat ik later nog begrijp waarom het gebeurt?

Dat is een belangrijke stap.

Want zodra je huis steeds meer beslissingen voor je neemt, wordt begrijpelijkheid onderdeel van betrouwbaarheid.

Een systeem dat technisch correct werkt maar waarvan niemand meer weet waarom, is moeilijk te onderhouden.

Een systeem dat je kunt uitleggen, controleren en aanpassen, kan jarenlang meegroeien.

Een praktische controle voor je eigen systeem

Pak eens één ruimte in je eigen Home Assistant-installatie.

Bijvoorbeeld de woonkamer, keuken of De Werkplaats.

Kijk vervolgens naar alle automatiseringen die daar invloed op hebben.

Probeer deze vragen te beantwoorden:

• Welke automatiseringen horen bij deze ruimte?
• Welke apparaten worden door meerdere automatiseringen bestuurd?
• Welke voorwaarden komen steeds opnieuw terug?
• Welke belangrijke toestanden hebben nog geen duidelijke naam?
• Welke waarden staan op meerdere plaatsen hard ingesteld?
• Wat gebeurt er wanneer je handmatig ingrijpt?
• Wat gebeurt er na een herstart van Home Assistant?
• Kun je in gewone taal uitleggen waarom ieder apparaat op dit moment aan of uit staat?

Je hoeft daarna niet direct alles te veranderen.

Alleen al het beantwoorden van deze vragen laat vaak zien waar je systeem duidelijk is en waar niet.

Wat je uit dit hoofdstuk moet meenemen

Losse automatiseringen zijn eenvoudig te maken.

De echte uitdaging ontstaat wanneer ze samen één systeem vormen.

Probeer daarom niet alleen te denken in triggers en acties, maar ook in gedrag, toestanden, verantwoordelijkheden en uitzonderingen.

Geef automatiseringen duidelijke namen.

Centraliseer instellingen die je op meerdere plaatsen gebruikt.

Gebruik helpers voor betekenisvolle toestanden.

Voorkom dat veel automatiseringen zonder duidelijke structuur hetzelfde apparaat besturen.

En stel jezelf regelmatig deze vraag:

Kan ik nog uitleggen waarom Home Assistant dit doet?

Als het antwoord ja is, heb je niet alleen een slim systeem gebouwd.

Je hebt een systeem gebouwd dat je begrijpt.

En dat wordt belangrijk in het volgende hoofdstuk.

Want zodra automatiseringen ingewikkelder worden, ligt het voor de hand om hulp te zoeken bij AI. Die kan verrassend goed helpen bij het verklaren van YAML, het bedenken van voorwaarden of het vinden van fouten.

Maar AI kan ook heel overtuigend iets voorstellen dat niet klopt.

Daarom bekijken we hierna:

Wanneer AI nuttig is — en wanneer je de uitkomst moet wantrouwen.