Op 3 oktober om 19:45 kwam er een vreemd plan uit EMHASS: 1 kW export, en een thuisbatterij die meehielp de auto te laden. Twee dingen die mijn opzet juist moet voorkomen. De oorzaak zat niet in EMHASS, maar in de minuten na een herstart van Home Assistant.
Wat er gebeurde
Ik had Home Assistant net herstart. De omvormer wordt uitgelezen via de Sunsynk-add-on, en die entiteiten zijn na een herstart pas na een paar minuten beschikbaar. In die tijd draaide de optimalisatie van het lopende kwartier.
De payload voor EMHASS had voor de batterijstand (state of charge, SoC) een terugvalwaarde: 50 %. De echte stand was 57 %. EMHASS rekende dus vanaf een verzonnen beginpunt, en kwam met een plan dat daar logisch bij paste, maar niet bij de werkelijkheid.
De oplossing
De optimalisatie draait alleen nog als de SoC een echt getal groter dan nul is. Als voorwaarde in de automatisering:
condition:
- condition: template
value_template: >
{{ states('sensor.ss_battery_1_soc') | float(0) > 0 }}unavailable en unknown worden met float(0) nul, en vallen dus af. Valt er een run uit, dan draait het volgende kwartier gewoon weer. De translator die het plan uitvoert, wacht na een herstart ook drie minuten tot de entiteiten van de omvormer er zijn, voor hij iets schrijft.
De les
Een terugvalwaarde is een verzonnen waarde. Voor een weergave op een dashboard is dat handig; voor een berekening die beslist wat de batterij doet, is het een risico. Liever geen plan dan een plan op een aanname. Een plan ouder dan 45 minuten zet de translator sowieso in een veilige stand.
De hele opzet: EMHASS en de batterij. Alle incidenten: Lessen uit de praktijk.
Deze waarden gelden voor één installatie. Controleer ze tegen je eigen documentatie; werk aan 230/400 V laat je over aan een erkend installateur.
Geef een reactie