history_stats-Sensoren mit jährlicher Laufzeit arbeiten fehlerhaft

Liebe Community,

ich habe mal wieder ein Problem mit den Verlaufsstistik-Sensoren, das ich nicht gelöst bekomme. Kurz beschrieben: Ich möchte neben der täglichen auch die jährliche Brennerlaufzeit einer Gastherme ermitteln. Dass der Brenner läuft, werte ich mit einem Relais aus, dessen Kontakte auf die digitalen Eingänge eines Shelly Add-Ons gehen. Ich habe in der configuration.yaml (nicht mit dem GUI) drei history_stats-Sensoren eingerichtet: 1.) für die tägliche Laufzeit, 2.) für die vergangenen 365 Tage und 3.) für die jährliche Laufzeit während der Abrechnungsperiode des Gaslieferanten.

Die Ermittelung der täglichen Laufzeit funktioniert absolut zuverlässig. Wenn ich jedoch history_stats-Sensoren mit einer jährlichen Laufzeit einrichte, arbeiten diese fehlerhaft. Es kommt sporadisch, aber nahezu täglich zu dem Phänomen, dass die bis dahin bereits aufgezählte Zeit ohne erkennbaren Grund schlagartig um 1 bis 3 Stunden verringert wird. Das passiert zu beliebigen Zeitpunkten und ohne für mich erkennbaren Zusammenhang mit dem Eingangssensor (binary.sensor des Relaiskontakts). Dieser negative Sprung der Zeit kommt exakt zum gleichen Zeitpunkt und mit den gleichen Werten bei beiden jährlichen history_stats-Sensoren vor.

Hier sind die betreffenden Zeile aus meiner configuration.yaml:

  - platform: history_stats
    # Brennerlaufzeit der vergangenen 365 Tage
    # Arbeit fehlerhaft, sporadische Verringerung der Werte, Grund unbekannt
    name: Gastherme Brennerlaufzeit 365
    unique_id: "Gastherme LZ 365"
    entity_id: binary_sensor.gastherme_brenner_input
    state: "on"
    type: time
    end: "{{ now() }}"
    duration:
      days: 365

  - platform: history_stats
    # Brennerlaufzeit von Mitte Oktober bis Mitte Oktober des nächsten Jahres (Abrechnungszeitraum)
    # Arbeit fehlerhaft, sporadische Verringerung der Werte, Grund unbekannt
    name: Gastherme Brennerlaufzeit Jahr
    unique_id: "Gastherme LZ Jahr"
    entity_id: binary_sensor.gastherme_brenner_input
    state: "on"
    type: time
    start: "{{ now().replace(month=10, day=15, hour=0, minute=0, second=0) }}"
    end: "{{ now() }}"
  

Ich habe das ganze nach der Einrichtung nun 10 Tage lang beobachtet. An diesen vergangenen 10 Tagen kam es lediglich an 3 Tagen dazu, dass die jährlichen Sensoren nicht verringert wurden. Dafür wurden an 2 anderen Tagen die Werte der beiden jährlichen Sensoren sogar zweimal am Tag reduziert, sonst einmal. Als Beispiel füge ich hier die Bilder von 2 aufeinanderfolgenden Tagen ein, die beide Extreme (keine Verringerung, zweimal Verringern pro Tag) zeigen.

Die Zeiten, um die die beiden jährlichen Sensoren verringert wurden, lagen zwischen min. 1,13 Std. und max. 3,73 Std. Die Zeitpunkte der Verringerung lagen zwischen 0:12 Uhr und 21:17 Uhr.

Ich habe hier im Forum zumindest einen Beitrag gefunden, der über ähnliche Phänomene berichtet hatte. Ich bin einigermaßen ratlos und frage mich wirklich, durch welchen Einfluss ein history_stats-Sensor überhaupt wieder “rückwärts” zählen (bzw. springen) kann. Ich bin für jeden Tipp und jeden Hinweis dankbar, was an meinen Sensoren falsch sein könnte, bzw. wie ich die negativen Sprünge in den Verlaufsstatistiken vermeiden kann.

Viele Grüße und vielen Dank im Voraus,

derblauedirk

Diese kleine Notiz in der Doku hast Du gelesen?

Gruß Osorkon

Hallo Osorkon,

vielen Dank für deine schnelle Reaktion und den Hinweis. Auf diese Einschränkung bin ich bisher noch nicht gestoßen. Bei mir ist der Wert der purge_keep_days offenbar auf 10 eingestellt. Ich sehe jedenfalls die Verlaufswerte 10 Tage lang detailliert. Erst noch ältere Werte werden gröber dargestellt und stammen dann aus der “Langzeitstatistik”.

Ich bin jedoch bisher davon ausgegangen, dass auch die Laufzeit eines Gerätes über ein ganzes Jahr aufsummiert werden kann, ähnlich wie ein Verbrauchszähler-Sensor die Verbräuche eines ganzen Jahres aufsummieren kann. Wenn ich es nun richtig verstanden habe, könnte dies ein Verlaufsstatistik-Sensor nur dann, wenn der Wert für die purge_keep_days auf 365 oder höher gestellt würde. Das würde jedoch zu einer riesigen Datenbankgröße führen. Eigentlich wären die Verlaufsstatistiken über ein ganzes Jahr auch nur für einige wenige Sensoren sinnvoll und interessant. Gäbe es eine Möglichkeit, nur explizit für bestimmte Sensoren eine längere Zeit der purge_keep_days zu definieren? Oder anders gefragt: Was könnte ich machen, um von einem bestimmten Verlaufsstatistik-Sensor längere Zeiträume erfassen zu lassen, als durch die purge_keep_days limitiert sind?

Vielen Dank für deine Zeit und Mühe und viele Grüße

derblauedirk

Hallo nochmal,

ich bin einer Lösung für mein Problem (Jährliche Laufzeiterfassung) leider noch keinen Schritt näher gekommen. Ich würde mich sehr über einen Tipp freuen, wie ich eine korrekte Auswertung der jährlichen Einschaltdauer (Verlaufsstatistik über einen Jahreszeitraum) eines binary-Sensors hinbekomme. Welche Grundvoraussetzungen sind dafür nötig (wie z.B. Einstellungen der recorder-Integration) und welcher yaml-Code für den history_stats-Sensor selbst?

Vielleicht stelle ich mich auch nur doof an. Aber hat jemand von euch eine funktionierende Verlaufsstatistik über einen ganzen Jahreszeitraum hinbekommen? Und wenn ja, was war dafür notwendig? Vielen Dank für eure Tipps und Hinweise.

Viele Grüße,

derblauedirk

Verwende den Helfer Verbrauchszähler. Als Eingangssensor verwendest Du den Statistik Sensor. Zyklus: Jährlich. Zusätzlich muss die Option „ Regelmäßige Rückstellung“ aktiviert sein.

Gruß Osorkon

Damit die Werte eines Sensors in der HA Langzeit-Statistik gespeichert werden muss er die passende state_class haben, sprich entweder:

  • SensorStateClass.MEASUREMENT
  • SensorStateClass.TOTAL
    oder
  • SensorStateClass.TOTAL_INCREASING

VG Jim

Vielen Dank Osorkon,

ich glaube, das war der entscheidende Hinweis. Ich bin bisher davon ausgegangen, dass ein Verbrauchszähler nur Verbrauchswerte aufaddieren kann, also kWh, m³, oder ähnliches. Aber verstrichene Zeit ist ja auch irgendwie “verbraucht”. Ich habe jetzt einen Verbrauchszähler mit dem Verlaufsstatistik-Sensor der täglichen Laufzeit (der ja problemlos funktioniert hat) als Eingangsentität nach deinen Empfehlungen eingerichtet und beobachte dessen Wert mal eine Woche lang. Ich melde mich nochmal und markiere deinen Vorschlag dann gerne als Lösung, wenn es geklappt hat.

Vielen Dank für deine unermüdliche Arbeit in den diversen Foren. Ich bin sehr froh, dass es Menschen wie dich gibt und habe sehr viel aus den unzähligen Beiträgen gelernt.

Viele Grüße

derblauedirk

Hallo Jim_OS,

auch an dich vielen Dank für deine Zeit und Mühe, mir zu antworten. Den Hinweis auf die state_class hatte ich schon mal versucht zu verstehen, bin da aber noch nicht richtig dahintergestiegen, welche state_class in meinem Fall die richtige gewesen wäre und wie ich die von der Syntax her in die configuration.yaml hineinbekomme. Mein jährlicher Verlaufsstatistik-Sensor hatte ja durchaus Werte in der Langzeitstatistik gespeichert. Es kam nur aus mir unverständlichen Gründen dazu, dass der bis dahin erreichte Wert sporadisch (zwischen 0x und 2x am Tag) schlagartig um einen für mich nicht nachvollziehbaren Wert reduziert wurde.

Aber ich glaube, dass dieses Problem mit dem Tipp von Osorkon für mich gelöst ist und ich für mich abspeichern kann, dass auch Zeit in einem Verbrauchszähler aufaddiert werden kann.

Viele Grüße

derblauedirk

Moin

Was da bei Dir diese “Sprünge” bzw. Reduzierungen

auslöst kann ich leider nicht nachvollziehen und ja eigentlich sollte man das was Du möchtest über einen Helfer realisieren können. Denn u.a. genau dafür sind manche Helfer da, sprich zusätzlich irgendwelche Werte bereit zu stellen, bzw. zu berechnen, die über die bereits vom dem Gerät gelieferten Werte und HA-Darstellungen nicht vorhanden sind. Als Beispiel mal Helfer für die Berechnung des Stromverbrauches über verschiedene Zeiträume.

Das kann ich Dir so auch nicht sagen, aber nur die drei erwähnten state_class speichern eben die Daten auch in der HA Langzeit-Statisttik. Auf welche Sensoren das aktuell bei Dir zutrifft kannst Du Dir ja über die Entwicklerwerkzeuge anzeigen lassen, in dem Du dort einfach mal nach state_class filterst.

Nur die Werte dieser Sensoren werden dann in der HA Langzeit-Statistik gespeichert.

Wenn ich das mal auf meine Wolf Heizungsanlage beziehe sind das dann z.B.


und bei dem da z.B. zu sehenden Sensor für die Außentemperatur kann ich dann eben auch die Werte über z.B. einen Monat

oder von mir aus einem Jahr


aus der HA Langzeit-Statistik abrufen.

Wenn man dann also einen Sensor hat der nicht einen der drei state_class Zustände hat dann kommt das Thema Helfer sind Spiel.

VG Jim

Hallo Jim_OS,

vielen Dank für deine weiteren Erläuterungen. Daraus entnehme ich, dass du die Verbrauchswerte deines Iskra Stromzählers (Woche, Monat, Quartal und Jahr) über Verbrauchszähler realisiert hast. Das funktioniert ja bei mir auch problemlos. Es geht in meinem speziellen Fall aber um die Verlaufsstatistik eines Binär-Sensors (Einschaltzeiten der Gastherme) über einen längeren Zeitraum als einem (1) Tag. Jeder meiner Versuche, in der configuration.yaml einen history_stats-Sensor einzurichten, der einen längeren Zeitraum (z.B. letzte 7 Tage, letzte 365 Tage, 1 Jahr) überwacht, führte zu dem von mir beschriebenen Problem der sporadischen Reduzierung der bereits aufaddierten Laufzeit, ohne dass ich dafür einen Grund oder Auslöser erkennen konnte.

Ich habe inzwischen alle dieser fehlerhaft arbeitenden history_stats-Sensoren wieder gelöscht, bin aber sicher, dass ich in den Entwicklerwerkzeugen unter “Zustände” deren state_class “total” gesehen habe. Weil diese Sensoren alle nicht wunschgemäß gearbeitet hatten, habe ich versucht, dort in “Zustände” probeweise deren state_class manuell auf “total_increasing” zu setzen. Das ist mir aber damals nicht gelungen, weil nach einem Neustart von HA die von mir gemachte Änderung wieder rückgängig gemacht wurde. Ebenso wurden manuelle Änderungen an den Werten des Sensors wieder rückgängig gemacht. Ich hab dann aufgegeben und mich hilfesuchend an euch gewendet.

Das hat mich ja nun zum Glück offenbar auch zu einer Lösung gebracht. Bisher ist der heute von mir eingerichtete jährliche Verbrauchszähler (dessen Eingangsentität der fehlerfrei arbeitende Verlaufsstatistik-Sensor der täglichen Laufzeit der Gastherme ist), noch nicht wieder abgesunken. Ich hoffe, dass das so bleibt und melde mich in ca. 1 Woche nochmal, um zu berichten.

Vielen Dank nochmals an euch alle für eure Zeit und eure Gedanken.

derblauedirk

Wie gesagt, woher diese “sporadischen Reduzierungen” kommt, bzw. jetzt kamen, kann ich Dir auch nicht sagen. Wenn ich eine Vermutung dazu abgeben soll wird vermutlich das

dafür als mögliche Ursache in Frage kommen.

Bei mir wird u.a. die Brennerlaufzeit direkt über einen Sensor der Wolf Integration zur Verfügung gestellt und wie man hier sehen kann wird die Zeit auch nur in der Kurzzeit-Statistik von HA und somit nur für 10 Tage erfasst,


eben weil der Sensor nicht die passende state_class hat. Oder genauer gesagt hat er gar keine state_class. :laughing:

Ergo müsste ich mir da auch etwas mit einem Helfer zusammenbasteln.

Vor allen dann wenn mind. 10 Tage vorbei sind, denn erst dann kommt auch die Langzeit-Statistik mit ins Spiel. :slightly_smiling_face:

VG JIm

Er wertet die Laufzeit über ein History Stats Sensor aus. Als Eingangs Entität dient ein Binary Sensor, Binary Sensoren, da es sich um keine Messwerte handelt, werden nicht in der Langzeitstatistik erfasst. In dem Fall kann er nur die Kurzzeitstatistik auswerten.
Die Lösung an der Stelle kann also nur sein, den History Stats Sensor als Eingangs Sensor für einen Verbrauchszähler zu nutzen, um die Gesamt Einschaltzeit für Zeiträume > purge_keep_days zu erhalten.
Man könnte auch einen Trigger based Template Sensor verwenden. Aber warum kompliziert, wenn es auch einfach geht.

Gruß Osorkon

Das war ja schon lange klar und ich sehe nicht wo ich hier etwas anderes geschrieben habe. :laughing:

VG Jim

Vielen Dank nochmals an euch beide. Mir ist inzwischen einiges klarer geworden und ich habe viel dazugelernt. Vor allem, wie ich einem Template-Sensor eine state_class zuweisen kann. Das war bei meinen ersten Versuchen (noch) nicht möglich, weil ich die Sensoren unter dem Bereich

sensor:
  - platform: template
    sensors:
      ***********

angelegt hatte. In diesem Bereich war die Angabe einer state_class nicht zulässig. Jetzt habe ich alle Sensoren in den Bereich

template:
  -sensor:
    - name: "**********"

verlegt. Die von den Sensoren erzeugten Werte stimmen weiterhin und ich kann jetzt sogar den geschätzten Jahresenergieverbrauch in kWh (Produkt aus Brennerlaufzeit, Brennerdurchsatz und Brennwert des Gases) als Eingangsentität für den Gasverbrauch im Energie-Dashboard verwenden. Jetzt bin ich wieder glücklich, auch dank eurer vielen Tipps und Hinweise. :slightly_smiling_face:

Ich melde mich abschließend nochmal. Mindestens 10 Tage abwarten ist sicher keine schlechte Idee. Dann ist es ganz sicher.

Viele Grüße

derblauedirk

1 „Gefällt mir“

Hallo Osorkon,

nach 10 Tagen kann ich bestätigen, dass dein Lösungsvorschlag funktioniert. Der Verbrauchszähler, der die tägliche Brennerlaufzeit als Eingangsentität verwendet, arbeitet zuverlässig und fehlerfrei. Vielen Dank nochmals an dich und auch an Jim_OS für eure Mühe und Tipps.

Viele Grüße und eine schöne Weihnachtszeit,

derblauedirk