Zo zoek je systematisch naar een fout

In het vorige hoofdstuk heb je gezien welke fouten bij automatiseringen vaak voorkomen. Een verkeerde entiteit, een voorwaarde die nooit waar wordt, een trigger die niet afgaat of een actie die net anders werkt dan je dacht: het zijn meestal geen ingewikkelde problemen.

Lastiger is vaak de vraag: waar begin je met zoeken?

Als een automatisering niet doet wat je verwacht, is de verleiding groot om meteen van alles te veranderen. Een andere trigger proberen, een extra voorwaarde toevoegen, de automatisering opnieuw maken of ergens YAML vandaan kopiëren.

Daarmee maak je het probleem meestal juist moeilijker.

Een storing wordt veel beter te begrijpen als je hem opdeelt in kleine stukken en steeds maar één vraag tegelijk probeert te beantwoorden.

Dat is wat we in dit hoofdstuk gaan doen.

Niet repareren voordat je weet wat er fout gaat

Stel dat in De Werkplaats de verlichting automatisch aan moet gaan wanneer het donker is en er beweging wordt gedetecteerd.

Je loopt naar binnen.

Er gebeurt niets.

De automatisering lijkt dus niet te werken.

Maar dat is eigenlijk nog geen bruikbare conclusie. Er kunnen verschillende dingen aan de hand zijn:

de bewegingssensor heeft geen beweging gemeld;
de automatisering is daardoor niet gestart;
de automatisering is wel gestart, maar een voorwaarde hield hem tegen;
de actie is uitgevoerd, maar naar de verkeerde lamp;
de lamp was niet bereikbaar;
de automatisering werkte precies zoals ingesteld, maar niet zoals jij bedoelde.

Dat zijn totaal verschillende oorzaken.

Daarom is de eerste regel bij foutzoeken:

Verander nog niets. Zoek eerst uit tot welk punt het wel goed ging.

Denk weer in trigger, voorwaarden en acties

Eerder in deze gids hebben we automatiseringen steeds opgedeeld in drie hoofdonderdelen:

Trigger → voorwaarden → acties

Diezelfde indeling is ook de eenvoudigste manier om fouten te zoeken.

Bij een probleem stel je daarom achtereenvolgens drie vragen:

Is de automatisering gestart?
Mochten de acties worden uitgevoerd?
Zijn de acties werkelijk uitgevoerd?

Pas wanneer je weet waar het antwoord van ja naar nee verandert, weet je in welk deel je verder moet zoeken.

Stap 1 — Beschrijf eerst wat je verwachtte

Voordat je in Home Assistant gaat kijken, is het verstandig om eerst in gewone taal op te schrijven wat er volgens jou had moeten gebeuren.

Bijvoorbeeld:

Als in De Werkplaats beweging wordt gedetecteerd terwijl het donkerder is dan 200 lux, moet de werkbankverlichting aangaan.

Daarmee heb je meteen drie onderdelen:

Trigger: beweging wordt gedetecteerd.

Voorwaarde: lichtniveau is lager dan 200 lux.

Actie: werkbankverlichting inschakelen.

Maak vervolgens je verwachting iets concreter.

Bijvoorbeeld:

de bewegingssensor moet van off naar on gaan;
de lichtsensor moet bijvoorbeeld 85 lux aangeven;
de automatisering moet starten;
de voorwaarde lager dan 200 lux moet waar zijn;
de lamp moet worden ingeschakeld.

Dit lijkt misschien omslachtig, maar het voorkomt dat je tijdens het foutzoeken steeds je eigen verwachting verandert.

Stap 2 — Controleer eerst de werkelijkheid

Voordat je naar de automatisering kijkt, controleer je of Home Assistant dezelfde werkelijkheid ziet als jij.

Dat klinkt vanzelfsprekend, maar hier ontstaan veel fouten.

Je ziet zelf iemand door De Werkplaats lopen, maar ziet de bewegingssensor dat ook?

Je vindt het donker, maar welke waarde geeft de lichtsensor werkelijk?

Je ziet dat een lamp uit is, maar staat de bijbehorende entiteit in Home Assistant ook op off?

Ga daarom naar de betreffende apparaten of entiteiten en kijk naar hun actuele toestand.

Je kunt hiervoor onder andere de entiteitenkaart, de geschiedenis of de ontwikkelaarshulpmiddelen gebruiken.

Eerst voorspellen

Voordat je naar de waarde kijkt, voorspel je wat je verwacht.

Bijvoorbeeld:

Ik verwacht dat binary_sensor.werkplaats_beweging nu on is.

Controleer daarna pas de werkelijke toestand.

Staat hij op off, dan hoef je voorlopig helemaal niet naar je automatisering te kijken. Het probleem zit eerder in de keten.

Misschien reageert de sensor niet.

Misschien gebruik je de verkeerde entiteit.

Misschien heeft de sensor een vertraging voordat hij opnieuw beweging meldt.

Dat is waardevolle informatie.

Stap 3 — Kijk of de trigger werkelijk is opgetreden

Als de gebruikte sensoren de juiste waarden aangeven, kijk je naar de trigger.

De belangrijkste vraag is:

Heeft het startmoment werkelijk plaatsgevonden?

Dat is iets anders dan:

Was de toestand correct?

Een toestandstrigger reageert namelijk meestal op een verandering.

Stel dat een automatisering moet starten wanneer:

bewegingssensor → on

Als de sensor al on was toen jij begon te testen, ontstaat er geen nieuwe overgang naar on.

De trigger hoeft dan dus niet opnieuw af te gaan.

Dat is een belangrijk verschil.

Maak het startmoment opnieuw zichtbaar

Test daarom bij voorkeur vanuit een bekende beginsituatie.

Bij een bewegingssensor kun je bijvoorbeeld wachten totdat deze weer off is.

Voorspel daarna:

Als ik nu voor de sensor langsloop, moet hij naar on gaan en moet de automatisering starten.

Loop daarna langs de sensor en controleer wat er werkelijk gebeurt.

Zo test je de gebeurtenis die de automatisering hoort te starten, in plaats van alleen naar een bestaande toestand te kijken.

Stap 4 — Gebruik de trace

Als de automatisering is gestart, wordt de trace je belangrijkste hulpmiddel.

In het hoofdstuk over traces heb je gezien dat Home Assistant daarmee laat zien welke route een automatisering heeft gevolgd.

Je kunt zien:

waardoor de automatisering werd gestart;
welke voorwaarden zijn gecontroleerd;
wat de uitkomst daarvan was;
welke keuze binnen een choose is gemaakt;
welke acties zijn uitgevoerd;
waar de uitvoering eventueel is gestopt.

Gebruik die informatie niet alleen om te constateren dat iets fout ging.

Zoek naar het laatste onderdeel dat nog wel goed ging.

Bijvoorbeeld:

trigger uitgevoerd: goed;
eerste voorwaarde: goed;
tweede voorwaarde: fout;
acties: niet uitgevoerd.

Dan weet je dat je niet meer naar de trigger hoeft te kijken.

Je zoekgebied is ineens veel kleiner geworden.

Stap 5 — Onderzoek de eerste afwijking

Stel dat de trace laat zien dat deze voorwaarde niet waar was:

Lichtniveau lager dan 200 lux.

Ga dan niet meteen de grens veranderen naar 300 lux.

Controleer eerst waarom de voorwaarde niet waar was.

Misschien verwachtte jij:

85 lux

maar zag Home Assistant:

426 lux

Dan is de voorwaarde technisch gezien correct uitgevoerd.

De interessante vraag wordt nu:

Waarom is de gemeten waarde anders dan ik verwachtte?

Misschien hangt de sensor vlak bij een lamp.

Misschien gebruik je de verkeerde lichtsensor.

Misschien wordt de waarde slechts om de paar minuten bijgewerkt.

Misschien heb je lux en een andere meetwaarde met elkaar verward.

De mislukte voorwaarde is dan geen storing, maar een aanwijzing.

Stap 6 — Test onderdelen los van elkaar

Wanneer je weet in welk onderdeel het probleem zit, kun je dat onderdeel afzonderlijk testen.

Dit is veel betrouwbaarder dan steeds de volledige automatisering opnieuw uitvoeren.

Een actie afzonderlijk testen

Stel dat de trace laat zien dat de automatisering volledig is doorlopen, maar de lamp bleef uit.

Test de lamp dan rechtstreeks vanuit Home Assistant.

Schakel hem handmatig in.

Werkt dat?

Dan weet je dat:

Home Assistant de lamp kan bereiken;
de integratie waarschijnlijk werkt;
de lamp zelf reageert.

Daarna kun je specifieker naar de actie in je automatisering kijken.

Wordt misschien een andere entiteit aangestuurd?

Wordt light.turn_on gebruikt terwijl het apparaat als switch beschikbaar is?

Of wordt de lamp direct daarna door een andere automatisering weer uitgezet?

Een voorwaarde afzonderlijk controleren

Bij een eenvoudige toestandvoorwaarde kun je rechtstreeks naar de gebruikte entiteit kijken.

Bijvoorbeeld:

Alleen doorgaan wanneer binary_sensor.workday_sensor on is.

Controleer dan eerst die entiteit.

Staat hij werkelijk op on?

Bij complexere templates kun je de template afzonderlijk testen voordat je hem weer in de automatisering gebruikt.

Het doel blijft steeds hetzelfde:

Haal zoveel mogelijk andere onderdelen tijdelijk uit je onderzoek.

Stap 7 — Verander maar één ding tegelijk

Dit is misschien de belangrijkste gewoonte bij technisch foutzoeken.

Stel dat een automatisering niet werkt en je verandert tegelijkertijd:

de trigger;
de luxgrens;
de lamp;
een wachttijd;
de uitvoeringsmodus.

Daarna werkt hij ineens wel.

Wat heb je dan geleerd?

Eigenlijk niets.

Je weet niet welke wijziging het probleem heeft opgelost.

Erger nog: misschien heb je ondertussen een nieuw probleem toegevoegd dat je pas later ontdekt.

Verander daarom steeds precies één onderdeel.

Bijvoorbeeld:

De automatisering start correct, maar de luxvoorwaarde is onverwacht fout.

Controleer eerst alleen die voorwaarde.

Blijkt dat de verkeerde entiteit wordt gebruikt, pas dan alleen die entiteit aan.

Test opnieuw.

Voorspel opnieuw wat je verwacht.

Controleer opnieuw wat er gebeurt.

Pas daarna ga je verder.

Een praktische foutzoekvolgorde

Voor vrijwel iedere automatisering kun je dezelfde volgorde gebruiken.

1. Is de automatisering ingeschakeld?

Het klinkt simpel, maar controleer het toch.

2. Zijn de betrokken apparaten en entiteiten beschikbaar?

Kijk of je geen toestanden als unavailable of unknown ziet.

3. Geeft iedere sensor de waarde die je verwacht?

Controleer de werkelijke toestand in Home Assistant.

4. Heeft de trigger werkelijk plaatsgevonden?

Let daarbij vooral op toestandsovergangen en eventuele tijdsduren.

5. Is er een trace aangemaakt?

Zo niet, dan is de automatisering waarschijnlijk niet gestart.

6. Welke voorwaarden zijn waar en welke niet?

Controleer daarbij niet alleen de uitkomst, maar ook de gebruikte waarden.

7. Welke acties zijn uitgevoerd?

Kijk tot waar de trace komt.

8. Werkt de betreffende actie afzonderlijk?

Test bijvoorbeeld de lamp, melding of het script rechtstreeks.

9. Kan een andere automatisering het resultaat weer veranderen?

Een lamp die correct wordt aangezet en één seconde later weer uitgaat, kan eruitzien alsof de eerste automatisering nooit heeft gewerkt.

10. Pas één onderdeel aan en test opnieuw.

Begin daarna opnieuw bij je voorspelling.

Voorbeeld — De verlichting in De Werkplaats gaat niet aan

Laten we het hele proces doorlopen.

De bedoeling is:

Als er beweging wordt gedetecteerd en het lichtniveau lager is dan 200 lux, moet de werkbankverlichting aangaan.

Je loopt de Werkplaats binnen.

De lamp blijft uit.

Eerste gedachte

Je zou meteen kunnen denken:

De automatisering werkt niet.

Maar dat weten we nog niet.

Controle 1 — Bewegingssensor

Je verwacht:

binary_sensor.werkplaats_beweging = on

Home Assistant toont inderdaad:

Dat lijkt dus goed.

Controle 2 — Lichtsensor

Je verwacht ongeveer:

120 lux

Home Assistant toont:

97 lux

Ook dat past bij je verwachting.

Controle 3 — Trace

Je opent de laatste trace.

Daar zie je dat de automatisering helemaal niet gestart is.

Dat is belangrijke informatie.

De voorwaarden en acties hoef je dus nog niet te onderzoeken.

Controle 4 — Trigger

Je kijkt opnieuw naar de trigger.

Daar staat dat de bewegingssensor van off naar on moet veranderen.

Vervolgens kijk je naar de geschiedenis van de sensor.

Daar zie je dat de sensor al enkele minuten on was.

Je hebt dus wel gecontroleerd dat de sensor on stond, maar je hebt niet gecontroleerd of de overgang van off naar on tijdens je test heeft plaatsgevonden.

Je wacht totdat de sensor weer off wordt.

Daarna voorspel je:

Als ik nu opnieuw binnenloop, moet de sensor naar on gaan en moet er een trace ontstaan.

Je loopt opnieuw naar binnen.

De sensor gaat naar on.

De trace verschijnt.

De voorwaarden zijn waar.

De lamp gaat aan.

De automatisering was dus niet kapot.

De testmethode was onvolledig.

Dat verschil is belangrijk.

Als er helemaal geen trace is

Geen trace kan zelf al een sterke aanwijzing zijn.

Als je verwacht dat een automatisering gestart had moeten zijn, maar er verschijnt geen nieuwe trace, kijk dan vooral naar:

de trigger;
de gebruikte entiteit;
de toestandsovergang;
een ingestelde for-duur;
tijd- of zontriggers;
of de automatisering is ingeschakeld.

Begin dan niet bij de acties. Die zijn immers waarschijnlijk nooit bereikt.

Als de trace halverwege stopt

Dan wordt het zoeken juist eenvoudiger.

Stopt de trace bij een voorwaarde, onderzoek dan die voorwaarde.

Stopt hij in een choose, kijk dan waarom geen of juist een bepaalde route is gekozen.

Stopt hij bij een actie met een foutmelding, onderzoek dan eerst die actie en de bijbehorende entiteit of service.

De trace vertelt je dus niet altijd direct waarom iets misging, maar meestal wel waar je verder moet zoeken.

Als de trace volledig goed lijkt

Dit is een interessanter geval.

De trace laat zien:

trigger correct;
voorwaarden correct;
actie uitgevoerd.

Toch zie jij niet het verwachte resultaat.

Dan verschuift je onderzoek van de logica naar de buitenwereld.

Bijvoorbeeld:

reageert het apparaat zelf?
is de gebruikte entiteit de juiste?
is het apparaat tijdelijk offline?
voert een andere automatisering direct daarna een tegengestelde actie uit?
verandert het apparaat zijn eigen toestand?
wordt de nieuwe toestand correct teruggekoppeld naar Home Assistant?

Je kunt dan bijvoorbeeld de geschiedenis van de betreffende lamp bekijken.

Misschien zie je:

19:42:10 → on

19:42:11 → off

Dan heeft de automatisering de lamp waarschijnlijk wel degelijk ingeschakeld.

De vraag wordt vervolgens:

Wie of wat zette hem een seconde later weer uit?

Dat is een veel gerichtere vraag dan:

Waarom werkt mijn automatisering niet?

Tijdstippen zijn vaak belangrijke aanwijzingen

Bij moeilijkere problemen helpt het om exacte tijdstippen te vergelijken.

Noteer bijvoorbeeld:

20:14:03 beweging gedetecteerd

20:14:03 automatisering gestart

20:14:04 lamp aan

20:14:06 lamp uit

Nu zie je dat de oorspronkelijke automatisering waarschijnlijk wel werkte.

Je kunt vervolgens in geschiedenis, logboek en traces rond 20:14:06 zoeken.

Misschien ontdek je een tweede automatisering:

Als er voldoende daglicht is, lamp uitschakelen.

Die automatisering gebruikt misschien een andere lichtsensor of grenswaarde.

Twee automatiseringen kunnen afzonderlijk volledig correct zijn en samen toch ongewenst gedrag veroorzaken.

Maak een ingewikkeld probleem tijdelijk eenvoudiger

Soms bevat een automatisering zoveel onderdelen dat je niet goed meer ziet waar het misgaat.

Bijvoorbeeld:

beweging

alleen tussen bepaalde tijden

alleen wanneer iemand thuis is

alleen onder 200 lux

andere regels in het weekend

wachttijd

choose

meerdere lampen

Probeer dan niet alles tegelijk te begrijpen.

Maak een tijdelijke kopie of vereenvoudig je testopstelling.

Bijvoorbeeld eerst:

beweging → lamp aan

Werkt dat betrouwbaar?

Voeg daarna de luxvoorwaarde toe:

beweging

lux < 200

→

lamp aan

Test opnieuw.

Voeg daarna pas de volgende regel toe.

Zo ontdek je precies bij welke uitbreiding het gedrag verandert.

Dit is dezelfde werkwijze die je ook bij elektronica of software gebruikt: eerst een kleine werkende basis, daarna stap voor stap uitbreiden.

Gebruik tijdelijke meldingen als meetinstrument

Soms is een automatisering lastig te observeren.

Dan kan een tijdelijke melding erg nuttig zijn.

Je kunt bijvoorbeeld tijdens het testen een notificatie toevoegen:

Automatisering Werkplaats gestart

Of iets specifieker:

Beweging gedetecteerd — lichtniveau: 87 lux

Daarmee maak je een onzichtbaar intern moment zichtbaar.

Als zo'n melding wel verschijnt maar de lamp niet aangaat, weet je alweer meer.

Verwijder dergelijke tijdelijke testacties wel wanneer je klaar bent. Een automatisering moet uiteindelijk zo eenvoudig mogelijk blijven.

Let op aannames in je eigen hoofd

Een van de lastigste onderdelen van foutzoeken is dat je vaak ongemerkt dingen als vanzelfsprekend beschouwt.

Bijvoorbeeld:

Deze sensor heet werkplaats_beweging, dus dat zal wel de juiste zijn.

Of:

Het is hier donker, dus de luxwaarde zal wel onder 200 liggen.

Of:

Deze lamp ging niet aan, dus de actie is niet uitgevoerd.

Probeer dergelijke aannames steeds om te zetten in iets wat je kunt controleren.

Niet:

Volgens mij is de sensor goed.

Maar:

Ik verwacht nu on. Home Assistant toont on.

Niet:

De automatisering zal wel gestart zijn.

Maar:

Er is een trace van 20:31:14.

Niet:

De lamp reageert niet.

Maar:

Als ik deze entiteit handmatig inschakel, gebeurt er niets.

Dat maakt foutzoeken veel minder afhankelijk van vermoedens.

Schrijf moeilijke problemen kort op

Als je langer dan een paar minuten aan dezelfde automatisering werkt, kan een eenvoudig lijstje verrassend nuttig zijn.

Bijvoorbeeld:

Probleem:

Werkbanklamp gaat 's avonds niet aan.

Verwacht:

Beweging → lux < 200 → lamp aan.

Gecontroleerd:

- bewegingssensor reageert

- lux = 86

- automatisering start

- luxvoorwaarde is waar

- actie wordt uitgevoerd

- lamp reageert handmatig wel

Nog onderzoeken:

- juiste lamp-entiteit?

- andere automatisering die lamp uitschakelt?

Hiermee voorkom je dat je dezelfde dingen steeds opnieuw controleert.

Je maakt bovendien onderscheid tussen wat je weet en wat je alleen nog vermoedt.

Wanneer opnieuw laden of herstarten?

Een herstart is soms nodig, maar gebruik hem niet als standaardoplossing.

Als iets na een herstart ineens werkt, heb je nog steeds niet noodzakelijk begrepen wat er aan de hand was.

Bij automatiseringen die je via de normale interface aanpast, verwerkt Home Assistant wijzigingen doorgaans zonder volledige herstart.

Gebruik een herstart daarom alleen wanneer daar een concrete reden voor is.

Anders loop je het risico dat je een probleem tijdelijk laat verdwijnen zonder de oorzaak te vinden.

Foutzoeken is eigenlijk informatie verzamelen

Een foutmelding, mislukte voorwaarde of onverwachte sensorwaarde voelt misschien alsof je niet verder komt.

In werkelijkheid gebeurt het tegenovergestelde.

Iedere controle verkleint het aantal mogelijke oorzaken.

Eerst wist je alleen:

De lamp gaat niet aan.

Even later weet je misschien:

De sensor werkt.

Daarna:

De trigger werkt.

Daarna:

De eerste twee voorwaarden zijn waar.

En uiteindelijk:

De derde voorwaarde gebruikt de verkeerde entiteit.

Dat is systematisch foutzoeken.

Niet raden totdat iets werkt, maar stap voor stap vaststellen waar werkelijkheid en verwachting van elkaar beginnen af te wijken.

Een vaste routine voor later

Als je maar één werkwijze uit dit hoofdstuk onthoudt, laat het dan deze zijn:

Voorspel → voer uit → observeer → zoek de eerste afwijking → verander één ding → test opnieuw.

Die aanpak werkt bij een eenvoudige lampautomatisering, maar net zo goed bij uitgebreidere automatiseringen met scripts, helpers, templates en meerdere apparaten.

Hoe complexer je Home Assistant-installatie later wordt, hoe waardevoller deze gewoonte wordt.

Je hoeft dan niet iedere storing onmiddellijk te begrijpen.

Je hoeft alleen te weten wat je als volgende moet controleren.

Van fouten oplossen naar fouten voorkomen

Tot nu toe hebben we vooral gekeken naar automatiseringen die al bestaan en niet doen wat je verwacht.

Maar er is nog een betere aanpak.

Je kunt automatiseringen namelijk zo ontwerpen dat ze vanaf het begin gemakkelijker te begrijpen, te testen en te herstellen zijn.

Dat betekent onder andere dat je nadenkt over wat er gebeurt wanneer een sensor tijdelijk niet beschikbaar is, wanneer twee automatiseringen tegelijk iets willen veranderen of wanneer Home Assistant opnieuw wordt gestart.

Daarmee verschuift de vraag van:

Hoe repareer ik mijn automatisering?

naar:

Hoe ontwerp ik hem zodat er zo weinig mogelijk onverwachts kan gebeuren?

Dat is het onderwerp van het volgende hoofdstuk:

Betrouwbare automatiseringen ontwerpen.