The Morning My Smart Battery Stopped Thinking
Last Tuesday I woke up to a Home Assistant notification I did not expect. Nine automations — all failed. My Sessy battery, which normally charges during the cheapest hours and discharges when electricity is expensive, had stopped making decisions. The hardware was fine. The battery was still connected. But the brain — the Jinja2 templates that calculated the optimal charging schedule — was dead.
This is the story of how a Home Assistant minor version upgrade (2026.7) silently broke my entire smart energy setup, and what I learned about the hidden cost of template-based automation.
What Actually Broke
Home Assistant 2026.7 tightened the Jinja2 sandbox. This sounds like a small security improvement — and for most users it is. But if you, like me, built custom template sensors that use list.append() or dict() constructors to calculate dynamic schedules, those templates now throw SecurityError: access to attribute 'append' of 'list' object is unsafe.
I had nine automation variants that calculated the cheapest electricity hours, sorted them, and scheduled the battery accordingly. Every single one failed. The sensor that showed today’s cheapest hours went unavailable. 129 template errors in 48 hours. My battery was still running — the hardware-side DSMQ schedule still worked — but the smart optimization layer was gone.
The Real Problem: Template Fragility
This is not the first time a Home Assistant upgrade broke my automations. It is the fifth time in six months. Each time, the fix takes longer because the templates have grown more complex. The pattern is clear: template-based logic is fragile. A minor sandbox change, a deprecated function, a data type shift — and your carefully crafted automations stop working.
The irony is that the hardware — the Sessy battery, the DSMQ power schedule — kept working perfectly. The physical layer is robust. It is the software logic layer that breaks. My battery was still charging and discharging, but it had lost its intelligence. It was like having a smart thermostat that can still heat your home but forgot how to learn your schedule.
What I Did About It
I had two options. Option one: rewrite all nine automations to use Home Assistant’s new namespace and update() pattern instead of list.append() and dict(). This would fix the immediate problem but leave me vulnerable to the next sandbox change.
Option two: replace the template-based approach with a simpler, more robust automation that uses native Home Assistant triggers and conditions — no Jinja2 templates at all. Use Zonneplan’s cheapest-hour sensor as a trigger, set a fixed evening window for discharging, and accept that the optimization is slightly less precise but infinitely more maintainable.
I went with option two. It took about 20 minutes to build. It is less elegant than the dynamic calculation. But it will survive the next Home Assistant upgrade.
What I Learned
Three things I will carry forward:
- Templates are not code. Jinja2 is great for simple variable substitution, not for algorithmic logic. If your template has loops, conditionals, and data manipulation, it belongs in a proper script or blueprint.
- Hardware survives software upgrades. The physical layer (DSMQ, battery controller) kept working. The software layer (templates, automations) broke. Design your systems so the hardware can run independently when the software layer fails.
- Simplicity beats cleverness. My nine dynamic automations were clever. The one simple automation that replaced them is boring. But it works, and it will keep working.
Your Turn
Have you had a Home Assistant upgrade break your automations? Or have you found a way to make template-based logic survive sandbox changes? I would love to hear your approach — drop a comment below.
Wat vond je van dit bericht?
