Betrouwbare automatiseringen ontwerpen

In het vorige hoofdstuk heb je gezien hoe je systematisch naar een fout zoekt. Je kijkt niet zomaar wat rond, maar controleert stap voor stap wat er werkelijk gebeurde: kwam de trigger binnen, waren de voorwaarden waar en werden de acties uitgevoerd?

Dat helpt wanneer een automatisering niet doet wat je verwacht.

Maar nog beter is het wanneer je automatiseringen zo ontwerpt dat problemen minder snel ontstaan.

Een betrouwbare automatisering is niet per se een ingewikkelde automatisering. Vaak is juist het tegenovergestelde waar. Hoe duidelijker de bedoeling, hoe beter je kunt voorspellen wat Home Assistant gaat doen.

In dit hoofdstuk gaan we daarom niet kijken naar één bepaalde functie van Home Assistant, maar naar een manier van ontwerpen.

Het doel is dat je automatiseringen maakt die ook over een paar maanden nog begrijpelijk zijn.

Betrouwbaar betekent meer dan: hij werkt nu

Stel dat je in De Werkplaats een lamp automatisch wilt inschakelen wanneer het donker wordt.

Je maakt een automatisering:

Als de lichtsensor minder dan 400 lux meet, zet de lamp aan.

Je test hem.

De sensor geeft 350 lux aan.

De lamp gaat aan.

Technisch gezien werkt de automatisering.

Maar daarmee weet je nog niet of hij betrouwbaar is.

Wat gebeurt er bijvoorbeeld wanneer:

• de lichtwaarde rond 400 lux blijft schommelen;
• Home Assistant opnieuw wordt gestart;
• de lamp handmatig wordt uitgeschakeld;
• de sensor tijdelijk niet beschikbaar is;
• het midden in de nacht donker is;
• iemand helemaal niet in De Werkplaats aanwezig is?

Een automatisering kan dus correct werken tijdens één test en toch onbetrouwbaar zijn in dagelijks gebruik.

Betrouwbaarheid betekent dat je niet alleen naar het gewenste moment kijkt, maar ook naar situaties eromheen.

Begin opnieuw met gewone taal

Voordat je een automatisering maakt, helpt het om de bedoeling eerst in gewone taal op te schrijven.

Bijvoorbeeld:

Als ik tussen 07:00 en 23:30 in De Werkplaats ben en het buiten langere tijd donker is, wil ik dat de verlichting aangaat.

Dat is veel preciezer dan:

Licht aan als het donker is.

Je ziet meteen dat er meerdere onderdelen zijn:

• er is een tijdsvenster;
• er moet iemand aanwezig zijn;
• het moet donker zijn;
• het moet niet om een korte meetfluctuatie gaan.

Dit is precies waarom de stap van gewone taal naar trigger, voorwaarden en acties eerder in deze gids zo belangrijk was.

Je beschrijft eerst wat je werkelijk wilt.

Daarna bouw je de automatisering.

Niet andersom.

Denk in toestanden, niet alleen in gebeurtenissen

Een veelgemaakte fout bij automatiseringen is dat je vooral denkt aan het moment waarop iets gebeurt.

Bijvoorbeeld:

De lichtsensor zakt onder 400 lux.

Dat is een gebeurtenis.

Maar Home Assistant werkt uiteindelijk vooral met toestanden.

De toestand kan bijvoorbeeld zijn:

• het is donker;
• het is licht;
• iemand is aanwezig;
• niemand is aanwezig;
• de verwarming staat aan;
• de deur staat open.

Een betrouwbare automatisering houdt rekening met de toestand waarin het systeem zich bevindt.

Stel bijvoorbeeld dat Home Assistant opnieuw wordt gestart terwijl het buiten al donker is.

Als je automatisering uitsluitend reageert op het moment waarop de lichtsensor van 401 naar 399 lux gaat, gebeurt er na die herstart misschien niets.

De overgang heeft immers al plaatsgevonden.

Daarom is het nuttig om jezelf steeds af te vragen:

Wil ik reageren op een gebeurtenis, of wil ik zorgen dat een bepaalde toestand uiteindelijk klopt?

Dat verschil wordt belangrijker naarmate je automatiseringen meer met elkaar gaan samenwerken.

Laat metingen niet te snel beslissen

Sensorwaarden zijn zelden volledig stabiel.

Een lichtsensor kan bijvoorbeeld achtereenvolgens meten:

403 lux

398 lux

401 lux

396 lux

405 lux

Wanneer je exact op 400 lux schakelt, kan de verlichting daardoor voortdurend aan en uit gaan.

Dit verschijnsel wordt vaak pendelen genoemd.

Je kunt dit voorkomen door niet dezelfde grens te gebruiken voor inschakelen en uitschakelen.

Bijvoorbeeld:

Lamp aan onder 350 lux

Lamp uit boven 450 lux

Het gebied tussen 350 en 450 lux vormt dan een soort buffer.

In de techniek wordt zo'n verschil tussen de in- en uitschakeldrempel hysterese genoemd.

Je hoeft die term niet te onthouden om het principe te gebruiken.

Het belangrijkste is:

Laat een kleine verandering niet meteen de tegenovergestelde actie veroorzaken.

Gebruik tijd als extra zekerheid

Soms is een meetwaarde tijdelijk afwijkend.

Een wolk trekt voor de zon.

Iemand loopt langs een bewegingssensor.

Een deur wordt even geopend.

Een netwerkapparaat meldt kort dat het niet beschikbaar is.

Als iedere korte verandering onmiddellijk een actie veroorzaakt, kan je huis onrustig reageren.

Daarom kun je een toestand soms eerst een bepaalde tijd laten bestaan.

Bijvoorbeeld:

Zet de verlichting aan wanneer het lichtniveau vijf minuten onder 350 lux blijft.

Je reageert dan niet op één meting, maar op een situatie die enige tijd aanhoudt.

Je kunt hetzelfde principe gebruiken bij uitschakelen:

Zet de verlichting pas uit wanneer er vijftien minuten geen aanwezigheid meer is gedetecteerd.

Dat maakt een automatisering meestal rustiger.

Maar gebruik vertragingen niet automatisch overal.

Vraag eerst:

Welk probleem los ik hiermee op?

Een rookmelder wil je uiteraard niet eerst vijf minuten laten wachten.

Zorg dat acties veilig opnieuw uitgevoerd kunnen worden

Een betrouwbare automatisering hoeft niet altijd precies te weten wat er eerder is gebeurd.

Stel dat je actie is:

Zet lamp aan

Wanneer de lamp al aanstaat, is dat meestal geen probleem.

Home Assistant geeft gewoon opnieuw de opdracht om hem aan te zetten.

Dat is vaak betrouwbaarder dan een constructie zoals:

Als lamp uit staat:

zet lamp aan

Die extra controle kan soms nuttig zijn, maar is niet altijd nodig.

Een actie die veilig meerdere keren kan worden uitgevoerd, wordt in de techniek wel idempotent genoemd.

Dat klinkt ingewikkelder dan het is.

Het betekent eenvoudig:

Dezelfde opdracht opnieuw geven mag het systeem niet in een verkeerde toestand brengen.

light.turn_on is daar een goed voorbeeld van.

Maar niet iedere actie werkt zo.

Denk bijvoorbeeld aan:

Verhoog temperatuur met 1 graad

Wanneer die opdracht per ongeluk drie keer wordt uitgevoerd, is de temperatuur drie graden hoger.

Daar moet je dus voorzichtiger mee zijn.

Bepaal altijd ook wanneer iets weer moet stoppen

Bij het ontwerpen van automatiseringen denken we meestal eerst aan inschakelen.

Wanneer moet de lamp aan?

Wanneer moet de ventilator starten?

Wanneer moet de boiler verwarmen?

Maar minstens zo belangrijk is:

Wanneer moet het weer stoppen?

Een automatisering zonder duidelijke uitschakelvoorwaarde kan technisch prima werken en toch vervelend worden.

Voor de verlichting in De Werkplaats kun je bijvoorbeeld besluiten:

Aan:

• tussen 07:00 en 23:30;
• wanneer het donker genoeg is;
• wanneer iemand aanwezig is.

Uit:

• wanneer het weer licht genoeg wordt;
• wanneer niemand meer aanwezig is;
• uiterlijk om 23:30.

Je hebt dan meerdere manieren waarop het systeem weer naar een veilige of normale toestand terugkeert.

Denk na over ontbrekende informatie

Sensoren zijn niet altijd beschikbaar.

Een apparaat kan opnieuw opstarten.

Wifi kan tijdelijk wegvallen.

Een Zigbee-apparaat kan zijn verbinding verliezen.

Home Assistant kan dan een toestand tonen zoals:

unknown

of:

unavailable

Bij eenvoudige verlichting is dat vooral vervelend.

Bij verwarming, pompen, sloten of andere belangrijke apparaten kan het veel belangrijker zijn.

Vraag daarom bij iedere relevante sensor:

Wat wil ik dat er gebeurt wanneer deze informatie ontbreekt?

Dat is een andere manier van denken dan:

Wat moet er gebeuren wanneer alles goed werkt?

Bijvoorbeeld:

• geen lichtwaarde beschikbaar → verlichting niet automatisch uitschakelen;
• temperatuursensor niet beschikbaar → verwarming niet onbeperkt door laten verwarmen;
• aanwezigheid onbekend → geen risicovolle actie uitvoeren.

Er bestaat niet één juiste reactie.

Het hangt af van het apparaat en van wat in jouw situatie de veiligste toestand is.

Kies bewust tussen automatiseren en beveiligen

Sommige voorwaarden bepalen wat prettig is.

Andere voorwaarden beschermen tegen ongewenst gedrag.

Dat verschil is belangrijk.

Bijvoorbeeld:

Alleen licht inschakelen wanneer het donker is

is vooral comfort.

Maar:

Boiler uitschakelen wanneer temperatuur 60 °C bereikt

kan onderdeel zijn van een veiligheidsgrens.

Een nuttige ontwerpregel is:

Vertrouw voor belangrijke beveiliging niet uitsluitend op één Home Assistant-automatisering.

Als een apparaat zelf een thermostaat, overstroombeveiliging, temperatuurbegrenzer of andere beveiliging heeft, laat die dan gewoon bestaan.

Home Assistant kan daar bovenop slim regelen.

Het moet niet de enige bescherming worden tegen een gevaarlijke situatie.

Voorkom dat automatiseringen tegen elkaar werken

Stel dat je twee automatiseringen hebt:

Automatisering 1

Als het donker wordt, zet de lamp aan.

Automatisering 2

Als er vijftien minuten niemand aanwezig is, zet de lamp uit.

Op zichzelf zijn beide logisch.

Maar wat gebeurt er wanneer het donker is én niemand aanwezig?

Automatisering 1 kan de lamp inschakelen.

Automatisering 2 schakelt hem weer uit.

Even later kan een nieuwe trigger hem misschien opnieuw inschakelen.

Je krijgt dan automatiseringen die elkaar corrigeren zonder dat er één duidelijke eigenaar van de toestand is.

Wanneer je merkt dat meerdere automatiseringen hetzelfde apparaat besturen, stel jezelf dan deze vraag:

Wie bepaalt uiteindelijk wat de gewenste toestand is?

Soms kun je automatiseringen beter combineren.

Soms kun je een helper gebruiken om de gewenste modus vast te leggen.

En soms is het prima om meerdere automatiseringen te houden, zolang hun verantwoordelijkheden duidelijk gescheiden zijn.

Maak uitzonderingen zichtbaar

Een volledig automatisch systeem kan irritant worden wanneer je niet gemakkelijk kunt ingrijpen.

Stel dat de verlichting in De Werkplaats automatisch wordt geregeld.

Normaal is dat prettig.

Maar misschien wil je tijdens het filmen de lampen tijdelijk handmatig bedienen.

Als de automatisering iedere paar minuten jouw keuze weer ongedaan maakt, voelt de automatisering niet slim maar koppig.

Een eenvoudige oplossing kan een helper zijn:

Automatische verlichting Werkplaats

Wanneer die helper aanstaat, mag Home Assistant automatisch schakelen.

Wanneer hij uitstaat, blijft de automatisering van de verlichting af.

De voorwaarde wordt dan bijvoorbeeld:

Automatische verlichting Werkplaats = aan

Je bouwt daarmee bewust een handmatige uitzondering in.

Dat is geen zwakte van de automatisering.

Het maakt het systeem juist bruikbaarder.

Geef belangrijke automatiseringen een duidelijke naam

Wanneer je vijf automatiseringen hebt, herken je Automation 3 misschien nog.

Bij vijftig automatiseringen niet meer.

Gebruik daarom namen die uitleggen wat de automatisering doet.

Bijvoorbeeld:

Werkplaats - Verlichting aan bij donker en aanwezigheid

in plaats van:

Lamp werkplaats

En:

Werkplaats - Verlichting uit na 15 minuten geen aanwezigheid

in plaats van:

Lamp uit

Een goede naam helpt niet alleen in de automatiseringslijst.

Je ziet hem ook terug in traces, logboeken en foutonderzoek.

Daar merk je later pas hoeveel verschil dat maakt.

Gebruik beschrijvingen voor het waarom

De naam vertelt meestal wat een automatisering doet.

De beschrijving is een goede plek om vast te leggen waarom.

Bijvoorbeeld:

Schakelt de werkplaatsverlichting automatisch in wanneer het buiten

langdurig donker is en aanwezigheid wordt gedetecteerd.

350 lux is bewust lager gekozen dan de uitschakelgrens van 450 lux

om pendelen rond de grenswaarde te voorkomen.

Dat lijkt misschien overbodig wanneer je de automatisering net hebt gemaakt.

Maar zes maanden later weet je waarschijnlijk niet meer waarom je precies 350 en 450 lux hebt gekozen.

Zo'n korte uitleg kan dan veel tijd besparen.

Vermijd onnodige complexiteit

Home Assistant biedt veel mogelijkheden:

• templates;
• helpers;
• choose;
• variabelen;
• scripts;
• meerdere triggers;
• ingewikkelde voorwaarden.

Dat betekent niet dat je ze allemaal in één automatisering moet gebruiken.

Een goede regel is:

Gebruik de eenvoudigste constructie die het gewenste gedrag betrouwbaar uitvoert.

Wanneer een gewone tijdvoorwaarde voldoende is, heb je geen template nodig.

Wanneer twee duidelijke automatiseringen gemakkelijker te begrijpen zijn dan één enorme automatisering met tien vertakkingen, dan zijn twee automatiseringen waarschijnlijk beter.

Het doel is niet om zo weinig mogelijk regels te maken.

Het doel is dat je later nog kunt begrijpen waarom Home Assistant iets doet.

Bouw stap voor stap

Stel dat je uiteindelijk deze automatisering wilt:

De verlichting in De Werkplaats moet automatisch worden ingeschakeld wanneer iemand aanwezig is, het donker genoeg is en het tussen 07:00 en 23:30 is. De verlichting moet minimaal vijftien minuten aanblijven en weer uitschakelen wanneer het licht genoeg wordt of wanneer niemand meer aanwezig is.

Je kunt proberen dit meteen volledig te bouwen.

Maar betrouwbaarder is:

• eerst alleen aanwezigheid testen;
• daarna de lichtvoorwaarde toevoegen;
• daarna het tijdsvenster;
• daarna het uitschakelgedrag;
• daarna de vertraging;
• daarna uitzonderingen testen.

Na iedere stap voorspel je eerst wat er zou moeten gebeuren.

Daarna observeer je wat er werkelijk gebeurt.

Pas wanneer dat klopt, voeg je het volgende onderdeel toe.

Dat principe heb je inmiddels meerdere keren gezien:

Verander steeds één onderdeel tegelijk.

Test ook situaties die niet horen te gebeuren

We testen meestal het normale scenario.

Bijvoorbeeld:

• ruimte leeg;
• iemand komt binnen;
• lamp gaat aan.

Maar betrouwbare automatiseringen ontstaan vooral door ook vreemde situaties te testen.

Probeer bijvoorbeeld:

• Home Assistant herstarten terwijl de lamp aanstaat;
• de sensor tijdelijk uitschakelen;
• de lamp handmatig bedienen;
• meerdere keren snel achter elkaar aanwezigheid veroorzaken;
• de lichtwaarde rond de grens laten bewegen;
• de automatisering uitvoeren terwijl een voorwaarde niet klopt.

Je probeert het systeem daarmee niet kapot te maken.

Je probeert te ontdekken welke aannames je onbewust hebt gemaakt.

Iedere onverwachte uitkomst geeft informatie over je ontwerp.

Een kleine ontwerpcheck

Voordat je een automatisering als klaar beschouwt, kun je een paar vragen nalopen.

Wat start deze automatisering?

Kun je duidelijk aanwijzen welke gebeurtenis het startsein geeft?

Welke voorwaarden moeten op dat moment waar zijn?

Zijn dat werkelijk voorwaarden, of zouden sommige zaken eigenlijk een trigger moeten zijn?

Wat is de gewenste eindtoestand?

Weet je niet alleen welke actie wordt uitgevoerd, maar ook wat uiteindelijk waar moet zijn?

Hoe wordt die toestand weer beëindigd?

Is duidelijk wanneer iets uit, dicht of terug naar normaal moet?

Wat gebeurt er bij ontbrekende sensordata?

Is unknown of unavailable een probleem?

Kan de automatisering meerdere keren starten?

En zo ja: is dat veilig?

Kan een andere automatisering hetzelfde apparaat besturen?

Zo ja: kunnen die elkaar tegenspreken?

Kun je handmatig ingrijpen?

En blijft jouw handmatige keuze dan lang genoeg bestaan?

Kun je over een half jaar nog begrijpen waarom dit zo is gebouwd?

Als het antwoord nee is, voeg dan een duidelijke naam of beschrijving toe.

Betrouwbaarheid ontstaat door voorspelbaarheid

Een goede automatisering voelt uiteindelijk bijna saai.

Je weet wat hij gaat doen.

Je weet wanneer hij niets doet.

Je weet hoe hij reageert wanneer informatie ontbreekt.

En wanneer iets onverwachts gebeurt, kun je via de trace terugvinden waarom.

Dat is veel waardevoller dan een automatisering die indrukwekkend ingewikkeld is.

Je hoeft Home Assistant niet steeds slimmer te maken.

Je moet vooral zorgen dat het gedrag steeds beter voorspelbaar wordt.

Tot nu toe hebben we vooral naar afzonderlijke automatiseringen gekeken. Maar zodra je er meer maakt, ontstaat een nieuw probleem.

Welke automatisering hoort waarbij?

Welke helper wordt waarvoor gebruikt?

En hoe voorkom je dat je uiteindelijk een verzameling losse regels hebt waarvan niemand meer precies weet hoe ze samenwerken?

Daarom gaan we in het volgende hoofdstuk een stap verder.

Dan kijken we naar Van losse automatiseringen naar een begrijpelijk systeem.