Hallo Zusammen,
wir hatten heute einen Stromausfall. Dadurch kamen an meinem Bitshake (via Tasmota) keine Werte an. Als dann der Strom wieder da war kam der IST Zählerstand zurück, jedoch scheint er zwischendrinnen die Werte genullt zu haben, sodass ich heute im Energie Dashboard einen Stromverbrauch in Höhe des Gesamtzählerstands habe 
Zur Umgebung:
Meinen Stromzähle lese ich mit einem Bitshake Lesekopf via Tasmota aus.
Hier kommt ein Wert für IN und ein Wert für OUT raus.
Diese Werte werden jedoch nicht als Zahlenwerte übermittelt. Deshalb habe ich mir zwei Helfer gebaut die nichts anderes tun, als die Stringwerte in Float zu wandeln. Die Helfer sind korrekt klassifiziert (StateClass = Energy, Measurement = kwh, Instance = total_increase)
Template der Helfer (Beispiel IN)
{{states('sensor.bitshake_smartmeterreader_mt691_total_in') | float}}
Betrachte ich die Statistik von den beiden Helfer sehe ich zum Zeitpunkt des Stromausfalls ein Loch bzw. 0
Um 11:50 hatte ich noch einen korrekten Wert (vor Stromausfall)
11:55-12:05 habe ich ein 0 obgleich ich fast glaube das es ein NULL ist
12:10 ist wieder der korrekte Wert da
(Gleiches Verhalten bei der Einspeisung)
Jetzt habe ich mir in den Entwicklerwerkzeugen unter Statistik den Helfer angesehen:
Hier steht überall 0 drinnen (was grundsätzlich aus meiner Sicht stimmen würde). Zur Sicherheit habe ich im besagten Zeitfenster alle mal neu mit 0 geschrieben. Aber der Ausreisser bleibt drinnen (auch nach vollständigen Neustart).
Hier mal zum Vergleich einen Tag (wo die Batterie nicht ganz gehalten hat):
Habt ihr eine Idee wie ich die Werte so korrigieren kann, dass wieder alles korrekt angezeigt wird?
Danke für eure Ideen
Nachtrag:
Ich habe jetzt mal mit SQLite in die Statistic Table gekuckt:
ID 1006890 denke ich mal ist der Fehler.
Zur Gleichen Zeit habe ich im Einspeisen auch einen Fehler drinnen.
ID 1006891
Da aber mehrere Zeitfenster fehlen habe ich jetzt nochmal in der statistics_short_term nachgesehen und hier finde ich exakt die 4 Werte die falsch sind:
Habe jetzt folgende Updates durchgeführt:
UPDATE statistics set state = 6601.963 where id = 1006890
UPDATE statistics set state = 8135.196 where id = 1006891
UPDATE statistics_short_term set state = 6601.963 where id = 12077638
UPDATE statistics_short_term set state = 6601.963 where id = 12077336
UPDATE statistics_short_term set state = 6601.963 where id = 12077047
UPDATE statistics_short_term set state = 6601.963 where id = 12076714
UPDATE statistics_short_term set state = 8135.196 where id = 12077639
UPDATE statistics_short_term set state = 8135.196 where id = 12077337
UPDATE statistics_short_term set state = 8135.196 where id = 12077048
UPDATE statistics_short_term set state = 8135.196 where id = 12076715
Ergebnis: in der Kurzansicht sind die Ausreisser jetzt weg. Aber in der Langzeitansicht sind sie immernoch da.
Hier habe ich eine interessante Diskussion gefunden zu exakt diesem Thema. Kurzum das Problem liegt wohl daran, dass es ein Total_Increase Zähler ist. Dieser kann dem Prinzip nach nicht “weniger” werden. Darin liegt wohl das Problem mit den Werten.
Weiterer Punkt: Statistic shortterm wird wohl wirklich nur für die Kurzzeitanzeige verwendet. Sprich ein Fehler hier ist in spätestens 14 Tage weg. Das Energy Dashboard bedient sich wohl nur der Statistic Tabelle.
Hier ist der Fehler noch immer da, obwohl der einzige Fehlerhafte Wert den ich gefunden habe korrigiert wurde.
Anhand der Werte in der statistic Tabelle erkennt man, dass diese immer zur vollen Stunde geschrieben werden. Vielleicht wird dann auch die Tabelle neu gelesen und der Fehler verschwindet. Nachtrag: Nein es wird nix neu gelesen.
Für alle die mit der kryptischen Zeit in SQLite ein Problem haben (Spalte start_ts z.b.) hier ein praktischter Konverter.
Jetzt kommt es aber:
Peinlich Peinlich Peinlich…
Die Werte die ich hier editiert habe brauche ich zwar, verwende diese aber nicht im Energy Dashboard. Ich hatte gerade die Idee, dass ich die Werte raus nehme und neu rein nehme um dadurch ein Neuladen zu erzwingen und dann habe ich gemerkt das es ganz andere sind (liegt an Rieman Summ Integration).
Jetzt diese werte direkt über die Ausreisser Funktion (siehe oben) identifiziert, korrigiert und das passt jetzt.