Einmalig negative Ausreisser im Energydashboard

J

jochen.neuschwa

New member
Hallo zusammen,
ich habe eine Frage an euch. Ich habe in meinem Energysdashboard einmalig an an einem Tag in der Vergangenheit zur jeweils gleichen Stunde einen negativen Ausreisser bei allen Energiesensoren (Strom, Gas und Wasserzähler)
Kennt jemand diese Problem bzw. die Ursache? Gibt es die Möglichkeit diese Werte im Nachgang zu korrigieren? Für HIlfe wäre ich sehr dankbar.
Vorab vielen Dank.
 

Anhänge

  • HA_Screenshot 2026-03-20 132939.jpg
    HA_Screenshot 2026-03-20 132939.jpg
    82,1 KB · Aufrufe: 6
Ja, das Problem kenne ich auch. Wie man es korrigieren kann hat Loxley ja schon gesagt.
Wie man es vermeiden kann, nun...
Nach meiner Erfahrung ist das gerne mal wenn die Verbindung verloren geht. Sprich "unavailabel" oder so was. Wenn dann die Werte wieder kommen gibt es diesen Sprung.
Also z.B. dein Stromzähler steht auf 5.000 kWh bisheriger verbrauch. Nun fällt eine Messung aus, weil nicht verfügbar und die nächste Messung sagt dann 5.001 kWh und schwupps, denkt HA es wären heute 5001 kWh verbraucht worden.
Ich habe deswegen in meiner templates.yaml folgenden Code.
Code: 
- sensor:
    - name: Haus-Verbrauch-Summe
      device_class: energy
      unit_of_measurement: kWh
      state_class: total_increasing
      #      state: >
      #        {{ states('sensor.bitshake_smartmeterreader_e320_e_in')|float(0) }}
      state: |
        {% set sensor_in = states('sensor.bitshake_smartmeterreader_e320_e_in') %}
        {% if sensor_in == 'unavailable' or sensor_in == 'unknown'  %}
        {{ this.state }}
        {% else %}
        {{ sensor_in }}
        {% endif %}
Der sensor ist der irLesekopf auf dem Stromzähler. Der Variablen 'sensor_in' wird nun dieser Wert zugewiesen.
Dann prüfen wir auf 'unavailable' oder 'unknown'.
Wenn das zutrifft, wird der vorherige Wert von sensor_in genutzt, ansonsten der aktuelle Wert.

Das hat bei mir bisher geholfen.
 
Interessant, so ein Phänomen habe ich bei meinem Lesekopf für die IME noch nicht erlebt.
Der wird sicher auch schon mehr als einmal die Verbindung zum HA verloren haben, so dass einzelne Lesungen "ins Wasser" gefallen sind.
Aber es gab dann bisher nie einen Flaschwert-Ausschlag.
 
Fing bei mir auch irgendwann mal an, weiß nicht mehr genau wann. Davor lief das auch alles problemlos.
Bei dem ir Lesekopf von bitShake steht in der Anleitung auch drin, der der "zwingend" mit dem USB Anschluß nach unten betrieben werden muß. Da hat er bei mir aber sehr oft Aussetzer gehabt. Jetzt betreibe ich den um 180 Grad gedreht, also entgegen dem, was in der Anleitung steht und es läuft deutlich besser.
 
Okay, es könnte also an dem eingesetzten IR Lesekopf liegen das verhalten, ob es zu solchen Fehlanzeigen kommt.
Wie gesagt, ich bin mir absolut sicher, dass auch mein Lesekopf schon mehrfach die Verbindung zum HA verloren hat,
z.B. wenn ich den AccessPoint im Keller reboote oder sowas. Aber danach gab es bisher nie so einen "Anzeigefehler".
Ich nutze einen Lesekopf von "IOmeter". Ich lese die Werte aber auch nur alle 30 Sekunden... also Ist-Verbrauch, usw.
 
Barungar schrieb:
Okay, es könnte also an dem eingesetzten IR Lesekopf liegen das verhalten, ob es zu solchen Fehlanzeigen kommt.
Zum Vergrößern anklicken....
Leider nein. Ich hatte vorher einen anderen Lesekopf drauf, der irgendwann mal mit genau diesem Fehler anfing, bis dahin aber prima gelaufen war. Deswegen hatte ich mir einen neuen geholt.
Barungar schrieb:
Wie gesagt, ich bin mir absolut sicher, dass auch mein Lesekopf schon mehrfach die Verbindung zum HA verloren hat,
z.B. wenn ich den AccessPoint im Keller reboote oder sowas. Aber danach gab es bisher nie so einen "Anzeigefehler".
Zum Vergrößern anklicken....
Erklären kann ich es mir auch nicht. Wie ist den dein templates Eintrag, um die Werte in ein Energy Dashboard brauchbares Format zu bringen ?
Barungar schrieb:
Ich nutze einen Lesekopf von "IOmeter". Ich lese die Werte aber auch nur alle 30 Sekunden... also Ist-Verbrauch, usw.
Zum Vergrößern anklicken....
Ich habe alle 10 Sekunden eingestellt, da ich über Verbrauch und Einspeisung ein paar Dinge regel. Aber kann ich mir grad nicht Vorstellen, das es daran liegt.
Auffallend ist halt, wie ich oben beschrieben habe, das der Ausreißer immer exakt den Wert wiederspiegelt, der aktuell verbraucht wird.
 
u5zzug schrieb:
wenn man |float(0) hinten anhängt, muss man sich nicht wundern, wenn aus allem eine (ggf unpassende) Zahl wird.
Zum Vergrößern anklicken....
Das solltest Du mal näher erklären, was der float(0) damit zu tun hat.
Wenn der Sensor nicht erreichbar ist, kommt eventuell ein String mit der das Energy Dashboard auch nichts anfangen kann.
u5zzug schrieb:
Wie wäre es mit einem availability: Eintrag?
https://www.home-assistant.io/integrations/template/#common-device-configuration-options
Zum Vergrößern anklicken....
Sieht mir leider schon wieder viel zu kompliziert aus und die Übersetzung ins Deutsch ist grauselig.
Die Lösung oben, die ich hier von jemandem in diesem Forum bekommen habe, funktioniert ja anscheinend und ist logisch einfacher nachvollziehbar. (Sorry, bin halt alt :))
 
Du sagst dem Sensor, wenn er nichts Auswertbares hat, soll er 0 als DEfaultwert verwenden und dann gefällt dir 0 nicht :)

Ja, du kannst da irgendwas selbst if elsen.
Oder eben das dafür vorgesehene Verfügbarkeitstemplate verwenden.
Beispiel:
YAML: 
availability: "{{ my_entity | has_value }}"

Definiert ein Template für den Verfügbarkeitsstatus der Entität. Wenn das Template entweder fehlschlägt oder wahr zurückgibt, also "1", "true", "yes", "on", "enable" oder eine Zahl, die nicht Null ist, ist die Entität verfügbar. Bei jedem anderen Wert unverfügbar. Wenn nicht konfiguriert, ist die Entität immer verfügbar.
 
u5zzug schrieb:
Du sagst dem Sensor, wenn er nichts Auswertbares hat, soll er 0 als DEfaultwert verwenden und dann gefällt dir 0 nicht :)
Zum Vergrößern anklicken....
Jain. Irgendwas muß er zurück geben, was nicht zu einem riesen Chaos führt. Ich meine mich zu erinnern, das da durchaus auch mal Zeichenketten ankamen, die dann eben zu Problemen führten und da ist "0" das kleinere Problem.
Ich kann aber auch nicht sagen "wenn da 0 kommt, vergiss den Wert". Es kann ja durch aus mal sein, das ich 0 Watt vom Versorger beziehe.
u5zzug schrieb:
Ja, du kannst da irgendwas selbst if elsen.
Oder eben das dafür vorgesehene Verfügbarkeitstemplate verwenden.
Beispiel:
YAML: 
availability: "{{ my_entity | has_value }}"

Definiert ein Template für den Verfügbarkeitsstatus der Entität. Wenn das Template entweder fehlschlägt oder wahr zurückgibt, also "1", "true", "yes", "on", "enable" oder eine Zahl, die nicht Null ist, ist die Entität verfügbar. Bei jedem anderen Wert unverfügbar. Wenn nicht konfiguriert, ist die Entität immer verfügbar.
Zum Vergrößern anklicken....
Puh, hat es jetzt nicht wirklich klarer gemacht, was den nun wann zurückgegeben wird, aber ich werde mich mal damit befassen, wenn es mir wieder was besser geht. Momentan hält mich eine Erkältung davon ab, einen klaren Gedanken zu fassen.
 
RudiP schrieb:
Ja, das Problem kenne ich auch. Wie man es korrigieren kann hat Loxley ja schon gesagt.
Wie man es vermeiden kann, nun...
Nach meiner Erfahrung ist das gerne mal wenn die Verbindung verloren geht. Sprich "unavailabel" oder so was. Wenn dann die Werte wieder kommen gibt es diesen Sprung.
Also z.B. dein Stromzähler steht auf 5.000 kWh bisheriger verbrauch. Nun fällt eine Messung aus, weil nicht verfügbar und die nächste Messung sagt dann 5.001 kWh und schwupps, denkt HA es wären heute 5001 kWh verbraucht worden.
Ich habe deswegen in meiner templates.yaml folgenden Code.
Code: 
- sensor:
    - name: Haus-Verbrauch-Summe
      device_class: energy
      unit_of_measurement: kWh
      state_class: total_increasing
      #      state: >
      #        {{ states('sensor.bitshake_smartmeterreader_e320_e_in')|float(0) }}
      state: |
        {% set sensor_in = states('sensor.bitshake_smartmeterreader_e320_e_in') %}
        {% if sensor_in == 'unavailable' or sensor_in == 'unknown'  %}
        {{ this.state }}
        {% else %}
        {{ sensor_in }}
        {% endif %}
Der sensor ist der irLesekopf auf dem Stromzähler. Der Variablen 'sensor_in' wird nun dieser Wert zugewiesen.
Dann prüfen wir auf 'unavailable' oder 'unknown'.
Wenn das zutrifft, wird der vorherige Wert von sensor_in genutzt, ansonsten der aktuelle Wert.

Das hat bei mir bisher geholfen.
Zum Vergrößern anklicken....
Vielen Dank für den Hinweis, was ich halt nicht verstehe, es ist nicht nur an einem Sensor sondern bei allen, wahrscheinlich war mein Raspy nicht erreichbar. I
 
sowas wie
YAML: 
availability: states('sensor.bitshake_smartmeterreader_e320_e_in')|has_value
sollte bei Wert true sein, bei unbekannt/unverfügbar false
 
Ich habe mir das jetzt mal in der Datenbank angesehen.
Wer wissen will, wie man das macht, darf hier gerne weiter lesen. Alle anderen, ab ins Bett. :p
Man braucht dazu das "SQLite Web" Addon. Wie man vermuten kann, findet man das bei den Addons.
Ruft man dieses auf, sieht man eine Oberfläche und links eine Liste der Tabellennamen.
event_data
event_types
events
usw.
Für uns Interesant:
states
states_meta
Wir klicken erst einmal auf states_meta und dann ganz oben auf QUERY
Im mittleren Feld sehen wir dann "SELECT * FROM "states_meta". Das ergänzen wir durch WHERE entity_id = "sensor.bitshake_smartmeterreader_e320_e_in" "wobei das sensor.bitshake_smartmeterreader_e320_e_in" durch den Namen eures Sensor ersetzt werden muß, den ihr abfragen wollt.
Nun klicken wir auf das blau unterlegte "Execute" und wenn alles richtig eingegeben wurde, sollte eine Zeile ausgegeben werden.
Für uns wichtig ist die Zahl unter "metadata_id"
Jetzt wählen wir links die Tabelle "states" aus, oben wieder Query.
Wieder steht im mittleren Feld "SELECT * FROM "states", welches wir mit WHERE metadata_id = 6802 <-- gemerkte Nummer
Jetzt sehen wir 1000 Zeilen mit Daten. Warum nur 1000 ? Nun, ihr könnt euch denken, das bei vielen Einträgen die Anzeige reichlich lange dauern würde. Das interessiert uns aber erst mal nicht.
In der Spalte "state" sehen wir nun die Meßwerte und in der Spalte "last_updated_ts" das Datum und die Zeit, wann dieser Eintrag erfolgte.
Datum und Zeit sind im Linux Format. Im Internet gibt es einige Converter, die einem das wieder in reale Werte übersetzen.
Jetzt hängen wir noch ein "AND state > 5000" an die Befehlszeile dran und drücken wieder Execute.
5000 deswegen, weil ich eher selten mehr als 5000 Watt beziehe. Ihr könnte da aber auch jeden anderen Wert eintragen.
Entscheident ist, das man nun auch Zeilen mit "unavailable" und "unknown" in der spalte state sehen KANN.
Kann deswegen, weil bei euch das ja nicht so sein muß, aber bei mir werden da 41 Zeilen angezeigt.
Nimmt man nun den Wert aus der Spalte "last_updated_ts" und lässt das übersetzen, sieht man Datum und Uhrzeit, wann das Ereignis aufgetreten ist.
Hängt man an die Befehlszeile noch ein "ORDER BY last_updated_ts" hinten dran und führt dann Execute wieder aus, wird die Tabelle nach Datum und Uhrzeit sortiert angezeigt. Das älteste Ereignis oben, das neueste unten.
So kann man sich einen schnellen Überblick über den Zeitraum verschaffen.
In meinem Fall war das erste Ereignis am 12. März und das letzte am 22. März.

Was bringt uns das ganze nun ?
Wir wissen jetzt zumindest auf die Millisekunde genau, wann dieser Sensor nicht erreichbar war bzw. einen unbekannten Wert geschickt hat. Wer also den Verdacht hat, das bei ihm Regelmäßig bzw. immer zur selben Zeit ein Ausfall auftritt, der kann das hiermit überprüfen.

Interessant ist die Zeile ganz rechts in der Tabelle. "Edit / Delete"
Ja, man kann hier falsche Werte auch entsprechend korrigieren oder halt auch löschen. Wobei ich eher davon abrate, in der Datenbank rum zu spielen, wenn man nicht genau weiß. was man tut.
 
Wenn es Dir "nur" um den Zeitraum geht... kannst Du direkt folgendes SQL ausführen.

SQL: 
SELECT datetime(MIN(last_updated_ts), 'unixepoch', 'localtime') AS Minimum, 
       datetime(MAX(last_updated_ts), 'unixepoch', 'localtime') AS Maximum
FROM states
WHERE metadata_id=
   (
      SELECT metadata_id
      FROM states_meta
      WHERE entity_id="sensor.bitshake_smartmeterreader_e320_e_in"
   );

Ist einfacher, schneller und man muss nicht x-mal rumklicken oder irgendwelche Tools im Internet suchen. ;)
 
Ging mir nicht nur um den Zeitraum, sondern anderen zu zeigen, wie sie bei sich nach ähnlichen Fehlern suchen können.
Vor allem ja auch wiederkehrende Fehler, wo man mit allen Angaben in der Tabelle eventuell ein Muster erkennen kann.
Verschachtelte SQL Abfragen sind da aber dann doch schon etwas zu heftig, denke ich.
Aber danke für den Tipp.

Ich habe deinen Code mal so weit modifiziert, das er nun alle Zeilen mit "state > 5000", also unavailable und unknown anzeigt und das Linux Time Stamp dann in unserer Zeit.
Code: 
SELECT datetime((last_updated_ts), 'unixepoch', 'localtime') AS Minimum, state
FROM states
WHERE metadata_id=
   (
      SELECT metadata_id
      FROM states_meta
      WHERE entity_id="sensor.bitshake_smartmeterreader_e320_e_in" AND state > 5000
   );
 
Sicher, das Dein SQL funktioniert? Du hast die >5000 an die Sub-Query gehangen, die Tabelle hat gar kein Attribut state...

Es müsste eher so lauten:
SQL: 
SELECT datetime(last_updated_ts, 'unixepoch', 'localtime') AS Datum, state
FROM states
WHERE metadata_id=
   (
      SELECT metadata_id
      FROM states_meta
      WHERE entity_id="sensor.bitshake_smartmeterreader_e320_e_in"
   ) AND state > 5000;
 
Du musst dich einloggen oder registrieren, um hier zu antworten.

Neueste Beiträge

Letzte Anleitungen

Statistik des Forums

Themen
7.887
Beiträge
77.447
Mitglieder
8.534
Neuestes Mitglied
Dinkel Smart Ho

Teilen

Zurück
Oben