De meest voorkomende fouten bij automatiseringen

In het vorige hoofdstuk heb je gezien hoe traces je laten terugkijken naar wat Home Assistant werkelijk heeft gedaan. Dat is belangrijk, want een automatisering die niet doet wat je verwacht, is zelden zomaar “kapot”.

Meestal is er iets anders aan de hand:

• de automatisering is niet gestart;
• een voorwaarde was niet waar;
• een actie kreeg niet de gegevens die je dacht;
• een apparaat reageerde anders dan verwacht;
• of de automatisering deed technisch precies wat je had ingesteld, maar niet wat je eigenlijk bedoelde.

Dat laatste komt verrassend vaak voor.

In dit hoofdstuk bekijken we de fouten die je bij automatiseringen het vaakst tegenkomt. Niet als een lijst met dingen die je vooral niet moet doen, maar als herkenbare patronen.

Als je die patronen leert herkennen, wordt foutzoeken veel eenvoudiger.

Eerst één belangrijk onderscheid

Wanneer een automatisering niet goed werkt, zijn er grofweg twee soorten problemen.

Een technische fout betekent dat Home Assistant iets niet kan uitvoeren.

Bijvoorbeeld:

• een entiteit bestaat niet meer;
• een actie bevat een ongeldige waarde;
• een template geeft een fout;
• een apparaat is niet bereikbaar.

Maar er bestaat ook een tweede categorie.

Een logische fout.

Daarbij werkt Home Assistant technisch correct, maar klopt je redenering niet helemaal.

Bijvoorbeeld:

Als het donker wordt, zet de lamp aan.

Dat klinkt logisch.

Maar wat bedoel je met donker?

Een luxwaarde lager dan 400?

Zonsondergang?

Een bepaalde tijd?

En moet de lamp ook aangaan wanneer niemand thuis is?

De automatisering kan technisch perfect functioneren en toch ongewenst gedrag opleveren.

Juist daarom zijn traces zo nuttig: ze laten niet alleen technische fouten zien, maar ook verkeerde aannames.

Fout 1 — De verkeerde trigger gebruiken

Een trigger bepaalt wanneer Home Assistant naar je automatisering gaat kijken.

Dat klinkt eenvoudig, maar hier ontstaat veel verwarring.

Stel dat je in De Werkplaats een lichtsensor hebt.

De entiteit is bijvoorbeeld:

sensor.werkplaats_licht

Je wilt dat de verlichting aangaat wanneer de lichtsterkte lager wordt dan 400 lux.

Je stelt daarom een numerieke trigger in:

Onder 400 lux

Dat betekent niet:

Zolang het onder 400 lux is, moet deze automatisering actief zijn.

Het betekent:

Start de automatisering op het moment dat de waarde van boven 400 naar onder 400 gaat.

Dat verschil is belangrijk.

Stel dat Home Assistant opnieuw wordt gestart terwijl de sensor al 250 lux aangeeft.

Dan heeft er geen overgang van boven naar onder 400 plaatsgevonden.

De trigger wordt dus niet uitgevoerd.

Voorspel eerst

Stel:

10:00 600 lux

10:15 450 lux

10:30 380 lux

10:45 300 lux

Wanneer verwacht je dat de automatisering start?

Niet om 10:45.

Maar rond het moment waarop de sensor voor het eerst onder 400 lux komt.

Dat soort denken helpt je om triggers beter te begrijpen.

Een trigger kijkt meestal naar een gebeurtenis of verandering, niet voortdurend naar een gewenste toestand.

Fout 2 — Trigger en voorwaarde door elkaar halen

Dit is waarschijnlijk een van de meest voorkomende denkfouten.

Een trigger zegt:

Wanneer moet Home Assistant beginnen?

Een voorwaarde zegt:

Mag Home Assistant daarna doorgaan?

Neem deze regel:

Zet de verlichting aan wanneer het donker wordt, maar alleen als iemand thuis is.

Dan kun je dit logisch opdelen als:

Trigger:

Lichtsterkte wordt lager dan 400 lux

Voorwaarde:

Iemand is thuis

Actie:

Verlichting inschakelen

Een veelgemaakte fout is om alles als trigger te proberen te gebruiken.

Bijvoorbeeld:

Trigger 1: minder dan 400 lux

Trigger 2: iemand komt thuis

Dat betekent iets anders.

Nu kan de automatisering namelijk ook starten wanneer iemand thuiskomt terwijl het buiten nog helemaal niet donker is.

Dat kan correct zijn — maar alleen als je dat bewust zo hebt ontworpen.

Schrijf daarom voordat je gaat bouwen eerst in gewone taal op:

Wanneer moet Home Assistant beginnen?

en daarna:

Wat moet op dat moment ook waar zijn?

Dat ene onderscheid voorkomt veel problemen.

Fout 3 — Denken dat voorwaarden vanzelf opnieuw worden gecontroleerd

Stel dat je automatisering start wanneer het 400 lux wordt.

Je hebt daarnaast een voorwaarde:

Iemand is thuis

Maar op dat moment is niemand thuis.

De automatisering stopt dus.

Vijf minuten later kom je thuis.

Wat gebeurt er?

Niets.

De automatisering stond niet te wachten tot de voorwaarde waar werd.

De voorwaarde is één keer gecontroleerd toen de automatisering werd uitgevoerd.

Dat is een belangrijk principe:

Een voorwaarde is meestal een controlepunt, geen bewaker die blijft wachten.

Wil je dat de lamp ook aangaat wanneer je later thuiskomt terwijl het al donker is?

Dan heb je waarschijnlijk een tweede trigger nodig:

Iemand komt thuis

met als voorwaarde:

Lichtsterkte lager dan 400 lux

Je automatiseert dan twee mogelijke gebeurtenissen:

Het wordt donker

of:

Iemand komt thuis

Daarna controleer je of de overige omstandigheden kloppen.

Fout 4 — De verkeerde entiteit kiezen

Home Assistant kan voor één fysiek apparaat meerdere entiteiten maken.

Een slimme stekker kan bijvoorbeeld bestaan uit:

switch.werkplaats_stekker

sensor.werkplaats_vermogen

sensor.werkplaats_energie

sensor.werkplaats_spanning

Als je een lamp wilt uitschakelen maar per ongeluk de vermogenssensor selecteert, kan Home Assistant daar natuurlijk niets mee.

Soms lijkt de naam bovendien bijna hetzelfde.

Bijvoorbeeld:

light.werkplaats

switch.werkplaats

Dat kan gebeuren wanneer een apparaat zowel een relais als een licht-entiteit aanbiedt.

Controleer daarom bij twijfel eerst onder:

Instellingen

→ Apparaten & diensten

→ Entiteiten

Bekijk daar:

• de naam;
• de entity ID;
• de huidige status;
• en bij welk apparaat de entiteit hoort.

Probeer de entiteit eventueel eerst handmatig te bedienen.

Als dat al niet werkt, hoef je nog niet naar je automatisering te kijken.

Fout 5 — Een apparaatnaam verwarren met een entiteit

In Home Assistant kom je onder andere deze begrippen tegen:

Apparaat

Entiteit

Integratie

Ruimte

Voor beginners lopen die gemakkelijk door elkaar.

Een fysiek apparaat kan bijvoorbeeld zijn:

Slimme stekker Werkbank

Maar de entiteit waarmee je hem schakelt is:

switch.werkbank

De automatisering werkt uiteindelijk meestal met een concrete toestand of functie van zo'n apparaat.

Dus niet alleen:

de stekker

maar bijvoorbeeld:

de schakelaar van de stekker.

Wanneer iets vreemd reageert, controleer daarom altijd welke entiteit werkelijk wordt gebruikt.

Fout 6 — Een status verkeerd interpreteren

Een status lijkt vaak vanzelfsprekend.

Een schakelaar heeft bijvoorbeeld:

on

of:

off

Maar andere entiteiten kunnen heel andere waarden gebruiken.

Een aanwezigheidssensor kan bijvoorbeeld werken met:

on

off

terwijl de interface dat toont als:

Gedetecteerd

Niet gedetecteerd

Een klimaatsensor kan waarden bevatten zoals:

heat

idle

off

En sommige apparaten gebruiken geheel andere toestanden.

Vertrouw daarom niet alleen op wat je denkt dat de status zal zijn.

Controleer hem.

Dat kan via de ontwikkelaarstools of via de entiteit zelf.

Een goede gewoonte is:

Eerst kijken welke waarde Home Assistant werkelijk ziet, daarna pas de automatisering bouwen.

Fout 7 — Tekst en getallen verwarren

Voor mensen is:

400

gewoon het getal vierhonderd.

Voor computers hoeft dat niet altijd zo te zijn.

Een waarde kan bijvoorbeeld als tekst binnenkomen:

"400"

of als echt numeriek getal:

400

Voor normale sensoren regelt Home Assistant dit meestal netjes.

Maar bij templates, MQTT-waarden of zelfgemaakte sensoren kun je hier tegenaan lopen.

Dan kan een vergelijking onverwacht misgaan.

Bijvoorbeeld wanneer je logisch wilt testen:

waarde < 400

maar waarde eigenlijk tekst bevat.

Zodra je templates gaat gebruiken, wordt dit belangrijker.

Daarom heb je in het hoofdstuk over templates gezien dat je waarden soms expliciet omzet naar een getal.

Bijvoorbeeld:

{{ states('sensor.werkplaats_licht') | float(0) }}

Je zegt daarmee feitelijk:

Gebruik deze waarde als getal. Als dat niet lukt, gebruik dan 0.

Je hoeft dit niet overal toe te passen.

Maar wanneer een numerieke vergelijking vreemd doet, is het iets om te controleren.

Fout 8 — Te precies automatiseren op sensorwaarden

Sensoren zijn niet altijd volledig stabiel.

Een lichtsensor kan bijvoorbeeld achter elkaar meten:

398 lux

402 lux

397 lux

405 lux

399 lux

Als je precies rond 400 lux schakelt, kan je automatisering daardoor meerdere keren worden geactiveerd.

Je verlichting kan dan ongewenst heen en weer schakelen.

Een betere oplossing is vaak om verschillende grenzen te gebruiken.

Bijvoorbeeld:

Lamp aan onder 350 lux

Lamp uit boven 450 lux

Het verschil tussen die twee grenzen voorkomt voortdurend schakelen rond één meetwaarde.

Dit principe heet hysterese.

De naam is minder belangrijk dan het idee:

Gebruik niet altijd exact dezelfde grens voor inschakelen en uitschakelen.

In De Werkplaats zou je bijvoorbeeld kunnen zeggen:

Donker genoeg om verlichting aan te zetten:

lager dan 350 lux

Licht genoeg om verlichting uit te zetten:

hoger dan 450 lux

Zo krijgt het systeem wat speelruimte.

Fout 9 — Geen rekening houden met kleine meetfouten

Een temperatuursensor kan bijvoorbeeld aangeven:

19,9 °C

20,0 °C

20,1 °C

19,9 °C

Dat betekent niet noodzakelijk dat de temperatuur in de ruimte werkelijk zo snel verandert.

Sensoren meten met een bepaalde nauwkeurigheid en resolutie.

Hetzelfde geldt voor:

• luchtvochtigheid;
• lichtsterkte;
• vermogen;
• luchtdruk;
• afstand;
• aanwezigheid.

Gebruik daarom niet iedere kleine verandering als belangrijke gebeurtenis.

Vraag jezelf af:

Is dit verschil voor mijn automatisering werkelijk relevant?

Voor een lamp maakt het bijvoorbeeld nauwelijks uit of de sensor 398 of 402 lux meet.

Gebruik liever bruikbare marges dan theoretisch perfecte grenzen.

Fout 10 — Geen for-tijd gebruiken wanneer dat wel verstandig is

Stel dat de bewegingssensor in De Werkplaats heel even geen beweging detecteert.

Je wilt niet direct de lamp uitschakelen.

Een regel zoals:

Geen beweging

→ lamp uit

is daarom meestal te agressief.

Veel praktischer is:

Geen beweging gedurende 5 minuten

→ lamp uit

De toestand moet dan een bepaalde tijd blijven bestaan voordat de trigger wordt uitgevoerd.

Hetzelfde is nuttig bij bijvoorbeeld:

Vermogen lager dan 5 watt gedurende 10 minuten

of:

Lichtsterkte lager dan 350 lux gedurende 2 minuten

Daarmee filter je korte schommelingen weg.

Maar gebruik zo'n tijd niet zomaar overal.

Een deur die opent hoeft bijvoorbeeld meestal niet eerst twee minuten open te staan voordat je wilt reageren.

Fout 11 — Vergeten dat for opnieuw begint na een herstart

Dit is subtieler.

Stel dat je trigger zegt:

Geen beweging gedurende 10 minuten

De sensor staat al acht minuten op geen beweging.

Dan wordt Home Assistant opnieuw gestart.

Je zou kunnen verwachten dat er nog twee minuten over zijn.

Maar bij bepaalde tijdsafhankelijke triggers wordt zo'n lopende tijd niet simpelweg als timer bewaard over een herstart heen.

Daarom moet je voorzichtig zijn wanneer een automatisering absoluut betrouwbaar moet zijn over herstarts.

Voor gewone verlichting is dat meestal geen groot probleem.

Voor belangrijkere processen kan het wel uitmaken.

Daar komen helpers soms van pas, omdat je daarmee bijvoorbeeld een concreet tijdstip of een toestand kunt bewaren.

Fout 12 — Te veel acties in één automatisering stoppen

In het begin lijkt het aantrekkelijk om één grote automatisering te maken.

Bijvoorbeeld:

Als ik thuiskom:

- verlichting aan;

- verwarming aan;

- televisie aan;

- gordijnen dicht;

- muziek starten;

- ventilatie aanpassen;

- telefoonmelding sturen.

Technisch kan dat.

Maar zodra één onderdeel niet goed werkt, wordt foutzoeken lastig.

Een grote automatisering bevat veel mogelijke oorzaken.

Vaak is het beter om logische onderdelen van elkaar te scheiden.

Bijvoorbeeld:

Thuiskomst → verlichting

Thuiskomst → klimaat

Avond → gordijnen

Aanwezigheid woonkamer → multimedia

Of gebruik een script wanneer meerdere automatiseringen dezelfde reeks acties moeten uitvoeren.

Een goede vuistregel is:

Eén automatisering moet één duidelijk doel hebben.

Niet per se één actie.

Wel één begrijpelijk doel.

Fout 13 — Dezelfde logica op meerdere plaatsen kopiëren

Stel dat drie automatiseringen allemaal deze acties uitvoeren:

Werkplaatslamp aan

Bureaulamp aan

LED-strip aan

Je kunt die drie acties drie keer kopiëren.

Maar later vervang je de LED-strip.

Nu moet je drie automatiseringen aanpassen.

Dat werkt, maar het wordt steeds moeilijker om overzicht te houden.

Zoals je eerder hebt gezien, is een script hiervoor vaak geschikter.

Bijvoorbeeld:

script.werkplaats_verlichting_aan

Daarin staan de drie acties.

De automatiseringen hoeven vervolgens alleen dat script aan te roepen.

Zo ontstaat één plek waar je het gedrag beheert.

Fout 14 — Automatiseringen die elkaar tegenwerken

Dit is een klassieker.

Automatisering A zegt:

Om 23:00

→ lamp uit

Automatisering B zegt:

Bij beweging

→ lamp aan

Om 23:01 loop je door de ruimte.

De lamp gaat weer aan.

Technisch hebben beide automatiseringen precies gedaan wat je hebt ingesteld.

Maar samen leveren ze niet het gewenste gedrag.

Dit soort fouten vind je vaak niet door één automatisering afzonderlijk te bekijken.

Je moet dan vragen:

Welke andere automatisering kan dezelfde entiteit bedienen?

Gebruik daarvoor onder andere:

• de geschiedenis;
• het logboek;
• traces;
• en de lijst met automatiseringen.

Wanneer een apparaat “uit zichzelf” lijkt te schakelen, doet het dat meestal niet uit zichzelf.

Er is ergens een commando gegeven.

De kunst is uitzoeken waar dat vandaan kwam.

Fout 15 — Een automatisering maakt zijn eigen trigger opnieuw waar

Soms kan een actie indirect opnieuw de trigger veroorzaken.

Bijvoorbeeld:

Trigger:

status van apparaat verandert

Actie:

status van hetzelfde apparaat aanpassen

Afhankelijk van hoe je de trigger hebt opgebouwd, kan de actie daardoor opnieuw een wijziging veroorzaken.

Dat kan leiden tot:

• extra uitvoeringen;
• onverwachte lussen;
• voortdurend schakelen.

Dit gebeurt vooral bij brede triggers zoals:

Wanneer de status verandert

zonder precies te definiëren van welke toestand naar welke toestand.

Wees daarom zo specifiek mogelijk.

In plaats van:

Als de schakelaar verandert

kun je bijvoorbeeld gebruiken:

Als de schakelaar van off naar on gaat

Hoe preciezer je trigger beschrijft wat belangrijk is, hoe minder onbedoelde gebeurtenissen hem kunnen starten.

Fout 16 — Verkeerde uitvoeringsmodus gebruiken

Eerder hebben we gezien dat automatiseringen verschillende uitvoeringsmodi kunnen gebruiken.

Die bepalen wat er gebeurt wanneer een automatisering opnieuw wordt gestart terwijl de vorige uitvoering nog bezig is.

Bijvoorbeeld bij:

Beweging gedetecteerd

→ lamp aan

→ wacht 5 minuten

→ lamp uit

Stel dat na vier minuten opnieuw beweging wordt gedetecteerd.

Wat moet er dan gebeuren?

Dat hangt mede af van de gekozen modus.

Misschien wil je:

Begin de vijf minuten opnieuw.

Maar misschien wil je:

Negeer nieuwe triggers zolang de automatisering nog loopt.

Of:

Laat meerdere uitvoeringen naast elkaar lopen.

Er bestaat geen modus die altijd goed is.

De fout ontstaat meestal wanneer je hier niet bewust over nadenkt.

Bij automatiseringen met:

• wachttijden;
• vertragingen;
• herhalingen;
• langdurige acties;

is de uitvoeringsmodus daarom altijd iets om te controleren.

Fout 17 — Een lange delay gebruiken als verborgen timer

Deze automatisering lijkt logisch:

Beweging

→ lamp aan

→ wacht 5 minuten

→ lamp uit

Maar stel dat er ondertussen opnieuw beweging is.

Wat moet er dan gebeuren?

Een gewone vertraging weet niets over nieuwe omstandigheden.

Hij wacht alleen.

Dat maakt lange delays soms kwetsbaar.

Vaak is het beter om te denken vanuit toestand:

Geen beweging gedurende 5 minuten

→ lamp uit

Nu wordt niet geteld vanaf het moment waarop iemand binnenkwam.

Er wordt gekeken naar hoe lang er werkelijk geen beweging meer is geweest.

Dat past vaak beter bij wat je bedoelt.

Fout 18 — Aannemen dat een apparaat onmiddellijk reageert

Home Assistant stuurt een commando.

Maar dat betekent niet dat het fysieke apparaat op exact hetzelfde moment is veranderd.

Een wifi-apparaat kan bijvoorbeeld:

• een commando ontvangen;
• zijn relais schakelen;
• de nieuwe toestand terugmelden;
• waarna Home Assistant de status bijwerkt.

Dat kan kort duren.

Bij sommige apparaten duurt het langer.

Wanneer je direct na een actie controleert:

Zet lamp aan

Controleer meteen of lamp aan is

kan die controle soms te vroeg komen.

Dit gebeurt vooral bij:

• cloudapparaten;
• trage integraties;
• batterijapparaten;
• apparaten met slechte netwerkverbinding.

Daarom is de werkelijke status van een apparaat soms belangrijker dan alleen het verzonden commando.

Fout 19 — Onbeschikbare entiteiten niet meenemen

Een sensor kan soms de status krijgen:

unavailable

Dat betekent dat Home Assistant tijdelijk geen geldige waarde heeft.

Bijvoorbeeld doordat:

• wifi is weggevallen;
• de batterij leeg is;
• MQTT geen verbinding heeft;
• een integratie opnieuw start;
• een apparaat offline is.

Er bestaat ook:

unknown

Daarmee geeft Home Assistant aan dat de toestand niet bekend is.

Een automatisering die alleen rekening houdt met normale waarden kan daardoor onverwacht gedrag vertonen.

Stel dat je een template maakt:

Als temperatuur lager is dan 15 °C

Wat moet er gebeuren als de temperatuursensor unavailable is?

Dat moet je soms bewust bepalen.

Voor niet-kritische automatiseringen kun je eenvoudigweg niets doen.

Voor belangrijke automatiseringen wil je misschien een melding ontvangen.

Fout 20 — Namen wijzigen zonder te controleren wat er afhankelijk van is

Tijdens het bouwen verander je regelmatig namen.

Bijvoorbeeld:

sensor.lichtsensor

wordt:

sensor.werkplaats_licht

Dat maakt je installatie overzichtelijker.

Maar wanneer andere automatiseringen nog naar de oude entity ID verwijzen, kan dat problemen opleveren.

Home Assistant helpt je hierbij steeds beter, maar het blijft verstandig om na wijzigingen te controleren welke automatiseringen afhankelijk zijn van een entiteit.

Geef entiteiten daarom liefst vroeg duidelijke namen.

Bijvoorbeeld:

sensor.werkplaats_temperatuur

sensor.werkplaats_luchtvochtigheid

binary_sensor.werkplaats_beweging

light.werkplaats_plafond

Dat is later veel prettiger dan:

sensor.temperature_2

sensor.sensor_4

switch.basic_relay

Fout 21 — Te veel tegelijk veranderen

Wanneer een automatisering niet werkt, is de verleiding groot om verschillende dingen tegelijk aan te passen.

Bijvoorbeeld:

• andere trigger;
• andere luxgrens;
• extra voorwaarde;
• uitvoeringsmodus wijzigen;
• delay toevoegen;
• template aanpassen.

Daarna werkt het misschien.

Maar je weet niet waarom.

En wanneer het later opnieuw misgaat, heb je weinig geleerd.

Een betere werkwijze is:

Verander steeds één ding.

Voer daarna opnieuw dezelfde test uit.

Dat klinkt langzaam, maar het is meestal sneller.

Je verkleint namelijk voortdurend het gebied waarin de fout kan zitten.

Fout 22 — Testen met steeds andere omstandigheden

Stel dat je de werkplaatsverlichting test.

De ene keer test je 's middags.

De volgende keer 's avonds.

Daarna verander je de luxgrens.

Vervolgens staat iemand anders in de ruimte.

Nu verander je telkens meerdere omstandigheden zonder dat je het bewust doet.

Het wordt dan moeilijk om twee tests met elkaar te vergelijken.

Probeer tijdens foutzoeken daarom zoveel mogelijk dezelfde beginsituatie te gebruiken.

Bijvoorbeeld:

Lichtsterkte: ongeveer 300 lux

Aanwezigheid: thuis

Lamp: uit

Beweging: niet gedetecteerd

Daarna veroorzaak je bewust één gebeurtenis:

beweging detecteren

Nu kun je veel beter voorspellen wat er moet gebeuren.

Fout 23 — Alleen controleren of het eindresultaat klopt

Stel dat de lamp niet aangaat.

Je kunt dan alleen constateren:

Het werkt niet.

Maar daarmee weet je nog bijna niets.

Controleer liever stap voor stap:

Is de trigger uitgevoerd?

Zo ja:

Waren de voorwaarden waar?

Zo ja:

Is de actie uitgevoerd?

Zo ja:

Heeft het apparaat het commando ontvangen?

Dat is precies waar traces zo bruikbaar voor zijn.

Je maakt van:

De lamp werkt niet.

een veel preciezere waarneming:

De trigger werd uitgevoerd, maar de luxvoorwaarde was niet waar.

Dat is geen vaag probleem meer.

Dat is bruikbare informatie.

Fout 24 — Een handmatige test verwarren met een echte trigger

Wanneer je in Home Assistant een automatisering handmatig uitvoert, test je meestal vooral de acties.

Dat betekent niet automatisch dat ook je trigger correct is.

Stel dat je automatisering bestaat uit:

Trigger:

om 18:00

Voorwaarde:

lager dan 400 lux

Actie:

lamp aan

Je drukt om 14:00 handmatig op uitvoeren.

Afhankelijk van hoe je test, kun je daarmee niet bewijzen dat de tijdtrigger om 18:00 goed zal functioneren.

Een handmatige uitvoering is nuttig, maar je moet weten welk onderdeel je daarmee test.

Daarom is een goede test vaak opgesplitst:

Test 1:

kan de actie de lamp bedienen?

Test 2:

werkt de voorwaarde zoals verwacht?

Test 3:

start de echte trigger de automatisering?

Fout 25 — Een automatisering bouwen vanuit mogelijkheden in plaats van gedrag

Home Assistant biedt ontzettend veel mogelijkheden.

Daardoor ontstaat gemakkelijk de neiging om eerst te kijken:

Welke trigger kan ik gebruiken?

Een betere vraag is:

Wat wil ik dat er in de echte wereld gebeurt?

Bijvoorbeeld:

Als ik 's avonds De Werkplaats binnenloop en het is donker, wil ik dat het licht aangaat. Als ik er vijf minuten niet meer ben, mag het weer uit.

Pas daarna vertaal je dat naar techniek.

Bijvoorbeeld:

Automatisering 1

Trigger:

beweging gedetecteerd

Voorwaarden:

lichtsterkte lager dan 350 lux

tijd tussen 07:00 en 23:30

Actie:

werkplaatsverlichting aan

en:

Automatisering 2

Trigger:

geen beweging gedurende 5 minuten

Actie:

werkplaatsverlichting uit

Dat is veel begrijpelijker dan eerst allerlei functies aan elkaar koppelen en daarna proberen te bedenken welk gedrag daaruit ontstaat.

Een voorbeeld waarin meerdere fouten samenkomen

Stel dat je deze automatisering hebt gemaakt:

Trigger:

lichtsterkte lager dan 400 lux

Voorwaarde:

beweging gedetecteerd

Acties:

lamp aan

wacht 10 minuten

lamp uit

Op het eerste gezicht lijkt dat redelijk.

Maar laten we hem onderzoeken.

Om 18:00 wordt het donker.

De luxwaarde gaat onder 400.

De trigger start.

Op dat moment is er niemand in De Werkplaats.

De bewegingssensor staat dus op:

Geen beweging

De voorwaarde mislukt.

De automatisering stopt.

Om 18:05 loop je De Werkplaats binnen.

De bewegingssensor wordt actief.

Maar de automatisering start niet opnieuw.

De trigger was immers:

lichtsterkte gaat onder 400 lux

Dat gebeurde vijf minuten geleden al.

De lamp blijft uit.

Hier is technisch niets misgegaan.

Je ontwerp beschreef alleen niet volledig wat je wilde.

Een betere redenering is:

De lamp moet aangaan wanneer er beweging komt terwijl het donker is.

Dan wordt beweging de trigger:

Trigger:

beweging gedetecteerd

en lichtsterkte de voorwaarde:

Voorwaarde:

lager dan 400 lux

Nu werkt de automatisering ook wanneer het al uren donker is.

Daarna kun je het uitschakelen apart regelen:

Trigger:

geen beweging gedurende 5 minuten

Actie:

lamp uit

Dat is niet alleen betrouwbaarder.

Het is ook gemakkelijker te begrijpen.

Maak fouten klein

Een goede automatisering hoeft niet in één keer perfect te zijn.

Begin bijvoorbeeld met:

Bij beweging

→ lamp aan

Test dat.

Voeg daarna toe:

alleen onder 400 lux

Test opnieuw.

Voeg daarna eventueel toe:

alleen tussen bepaalde tijden

Test opnieuw.

Maak vervolgens een aparte automatisering voor uitschakelen.

Zo weet je na iedere stap precies wat je hebt toegevoegd.

Wanneer iets misgaat, weet je dus ook ongeveer waar je moet zoeken.

Een bruikbare gewoonte: voorspel vóór je test

Voordat je een automatisering uitvoert, schrijf of bedenk je:

Beginsituatie:

lamp = uit

licht = 280 lux

beweging = uit

Daarna:

Gebeurtenis:

beweging wordt gedetecteerd

Je voorspelling:

De automatisering start.

De lichtvoorwaarde is waar.

De lamp wordt ingeschakeld.

Pas daarna test je.

Wanneer het resultaat afwijkt, heb je een concrete vraag:

Op welk punt wijkt de werkelijkheid af van mijn voorspelling?

Dat is veel sterker dan willekeurig instellingen veranderen.

Veel fouten zijn eigenlijk verkeerde aannames

Wanneer Home Assistant iets onverwachts doet, is de eerste gedachte al snel:

Home Assistant doet iets verkeerd.

Soms is er inderdaad een technisch probleem.

Maar veel vaker heeft Home Assistant precies uitgevoerd wat je hebt ingesteld.

Het verschil zit tussen:

wat je dacht dat je had ingesteld

en:

wat er werkelijk staat.

Daarom zijn de belangrijkste hulpmiddelen bij automatiseringen niet ingewikkelde templates of grote YAML-bestanden.

Het zijn:

• duidelijk denken;
• kleine stappen;
• goede namen;
• gecontroleerd testen;
• traces bekijken;
• en steeds één verandering tegelijk uitvoeren.

Tot slot

De meeste problemen met automatiseringen vallen uiteindelijk terug op een beperkt aantal patronen:

• de trigger start niet wanneer je denkt;
• een voorwaarde wordt op het verkeerde moment gecontroleerd;
• de verkeerde entiteit of status wordt gebruikt;
• sensoren schommelen rond een grens;
• automatiseringen beïnvloeden elkaar;
• wachttijden en uitvoeringsmodi gedragen zich anders dan verwacht;
• of de automatisering beschrijft simpelweg niet helemaal het gedrag dat je voor ogen had.

Dat is goed nieuws.

Want als problemen terugkerende patronen hebben, kun je ook een vaste methode gebruiken om ze te vinden.

En dat is precies waar we in het volgende hoofdstuk mee verdergaan.

Niet meer willekeurig instellingen veranderen tot iets toevallig werkt, maar stap voor stap bepalen:

Waar gaat de werkelijkheid afwijken van wat ik had voorspeld?

In het volgende hoofdstuk bekijken we daarom hoe je systematisch naar een fout zoekt.