De Ochtend Dat Mijn Slimme Batterij Stopte met Denken
Afgelopen dinsdag werd ik wakker met een Home Assistant melding die ik niet verwachtte. Negen automations — allemaal mislukt. Mijn Sessy batterij, die normaal oplaadt tijdens de goedkoopste uren en ontlaadt wanneer stroom duur is, was gestopt met beslissingen nemen. De hardware was in orde. De batterij was nog verbonden. Maar het brein — de Jinja2 templates die het optimale laadschema berekenden — was dood.
Dit is het verhaal van hoe een kleine Home Assistant upgrade (2026.7) stilletjes mijn hele slimme energie-opstelling lamlegde, en wat ik leerde over de verborgen prijs van template-gebaseerde automations.
Wat Er Eigenlijk Brak
Home Assistant 2026.7 heeft de Jinja2 sandbox aangescherpt. Dat klinkt als een kleine security-verbetering — en voor de meeste gebruikers is dat ook zo. Maar als je, zoals ik, custom template sensors hebt gebouwd die list.append() of dict() constructors gebruiken om dynamische schema’s te berekenen, dan gooien die templates nu SecurityError: access to attribute 'append' of 'list' object is unsafe.
Ik had negen automation-varianten die de goedkoopste stroomuren berekenden, sorteerden en de batterij daarop inplanden. Alle negen faalden. De sensor die de goedkoopste uren van vandaag toonde, ging naar unavailable. 129 template errors in 48 uur. Mijn batterij draaide nog — het hardware-side DSMQ-schema werkte nog — maar de slimme optimalisatielaag was weg.
Het Echte Probleem: Template Breekbaarheid
Dit is niet de eerste keer dat een Home Assistant upgrade mijn automations brak. Het is de vijfde keer in zes maanden. Elke keer duurt de fix langer omdat de templates complexer zijn geworden. Het patroon is duidelijk: template-gebaseerde logica is breekbaar. Een kleine sandbox-wijziging, een verouderde functie, een data-type verschuiving — en je zorgvuldig gebouwde automations stoppen met werken.
De ironie is dat de hardware — de Sessy batterij, het DSMQ-vermogensschema — perfect bleef werken. De fysieke laag is robuust. Het is de software-logica-laag die breekt. Mijn batterij laadde en ontlaadde nog, maar was zijn intelligentie kwijt. Alsof je een slimme thermostaat hebt die je huis nog kan verwarmen maar vergeten is hoe hij je schema leert.
Wat Ik Eraan Deed
Ik had twee opties. Optie één: alle negen automations herschrijven met Home Assistant’s nieuwe namespace en update() patroon in plaats van list.append() en dict(). Dat lost het directe probleem op, maar laat me kwetsbaar voor de volgende sandbox-wijziging.
Optie twee: de template-aanpak vervangen door een eenvoudigere, robuustere automation met native Home Assistant triggers en conditions — geen Jinja2 templates meer. Gebruik de Zonneplan goedkoopste-uur sensor als trigger, stel een vast avondvenster in voor ontladen, en accepteer dat de optimalisatie iets minder precies is maar oneindig beter onderhoudbaar.
Ik ging voor optie twee. Het kostte ongeveer 20 minuten om te bouwen. Het is minder elegant dan de dynamische berekening. Maar het overleeft de volgende Home Assistant upgrade.
Wat Ik Leerde
Drie dingen die ik meeneem:
- Templates zijn geen code. Jinja2 is geweldig voor simpele variabele-substitutie, niet voor algoritmische logica. Als je template loops, condities en data-manipulatie bevat, hoort het thuis in een echt script of blueprint.
- Hardware overleeft software-upgrades. De fysieke laag (DSMQ, batterijcontroller) bleef werken. De software-laag (templates, automations) brak. Ontwerp je systemen zo dat de hardware onafhankelijk kan draaien wanneer de software-laag faalt.
- Eenvoud verslaat slimheid. Mijn negen dynamische automations waren slim. De ene simpele automation die ze verving is saai. Maar hij werkt, en hij blijft werken.
Jouw Ervaring
Heb jij ook meegemaakt dat een Home Assistant upgrade je automations brak? Of heb je een manier gevonden om template-gebaseerde logica sandbox-wijzigingen te laten overleven? Ik hoor graag je aanpak — laat een reactie achter.
Wat vond je van dit bericht?
