Betriebstundenzähler auswerten

[SebastianOH]

Hallo Leute,

ich habe in meiner HA folgende Betriebsstundenzähler angelegt. Beide funktionieren gut und der Tageszähler setzt sich auch brav zurück. Jedoch ist mir nicht klar wie ich die Werte zur weiteren Automatisierung abfragen kann. Ich würde gerne einen Helfer setzten wenn der Betriebsstundenzähler Pool am Tag 2 Stunden gelaufen anzeigt um die Zeitsteuerung dann zu unterbrechen, da der Pool auch über eine Solarsteuerung zusätzlich gesteuert wird. Kann mir hierfür jemand Hilfestellung geben?

/configaration.yaml:

# Betriebsstundenzähler
sensor:
  - platform: history_stats
    name: Betriebstunden_Teich_Monat
    entity_id: switch.shelly_shsw_1_3494546a5717
    state: "on"
    type: time
    start: "{{ now().replace(day=1, hour=0, minute=0) }}"
    end: "{{ now() }}"
  
  - platform: history_stats
    name: Betriebstunden_Pool_Tag
    entity_id: switch.shelly_shsw_1_244cab43ddc4
    state: "on"
    type: time
    start: "{{ now().replace(hour=0, minute=0) }}"
    end: "{{ now() }}"

In der HA sehen die Ausgaben dann so aus:

 

[blurrrr]

Ich würde gerne einen Helfer setzten wenn der Betriebsstundenzähler Pool am Tag 2 Stunden gelaufen anzeigt um die Zeitsteuerung dann zu unterbrechen

Hab jetzt von HA nicht soviel Ahnung, aber wäre das nicht eher eine Automatisierung statt ein Helfer? Irgendwas in die Richtung:

WENN "Betriebsstunden_Pool_Tag" >= "2:00:00" DANN "Automatik Pool" = "aus"

Ist aber auch nur so eine Idee, kann richtig sein, kann aber auch weit entfernt davon sein, wäre jedenfalls so mein laienhafter Ansatz, aber vielleicht kann ja noch jemand anderweitige Ansätze liefern

 

[SebastianOH]

Ja die Bedingung ist schon richtig, nur wie werte ich den Betriebsstundenzähler nun aus?

Was für ein Bedinungstyp in der Automatisierung ist das "Numerischer Zustand", "Zustand", "Gerät" etc. und wie ist der dann anzulegen.

Wenn ich es als Numerischen Zustand anlege bekomme ich die folgende Fehlermeldung:

 

[blurrrr]

Hab leider grade kein HA zur Hand, wo ich mal kurz schauen könnte, aber mögliche Ansätze (rein aus der Luft gegriffen, sorry)...:

1) Bedingungstyp - gibt es da vllt auch sowas wie "Zeit"? (float steht eigentlich für Fließkomma-Werte, was dann so natürlich nicht funktionieren kann (Doppelpunkte und so))

2) Schau mal in den Dev-Tools bzgl. der Entität was da an Attributen vorhanden ist, ggf. muss man da auch noch entsprechendes angeben

Wie gesagt, kann leider grade nicht nachschauen, von daher sind das erstmal nur "Vermutungen", ich würde aber einfach mal stark darauf tippen, dass "Numerischer Zustand" nicht ganz richtig ist (eben aufgrund der Formatierung des Zeitwertes)

EDIT: Noch eine kleine Idee am Rande.... Eventuell die "Zeit" nochmal umrechnen in in dezimal (2:00:00 -> 2)

 

[SebastianOH]

Moin blurrrr,

folgende Attribute sind vorhanden:

state_class: measureme
unit_of_measurement: h
device_class: duration
icon: mdi:chart-line
friendly_name: Betriebstunden_Pool_Tag

Unter Zustand steht 0.0 (Shelly war heute morgen ja auch nicht on)

 

[Nival]

Mhm, ein Doppelpunkt ist eben nicht numerisch. Die einfachste Lösung die mir einfallen würde wäre, noch einen Sensor anzulegen der nur die Stunden ausgibt und mit diesem dann den numerischen Zustand zu verwenden.

Wenn ich Deinen Poolstatus grob nachstelle:

  - platform: template
    sensors:
      pool:
        value_template: "{{ now() - now().replace(hour=0, minute=0) }}"

und den dann abgreife (in Deinem Fall natürlich den richtigen Wert verwenden):

  - platform: template
    sensors:
      pool_dauer:
        value_template: >-
          {% set pooltime = states('sensor.pool') |string %}
          {{ pooltime[:1] |int }}

habe ich diese Ausgaben:

und mit letzterem müsstest dann soweit arbeiten können.

Ach, ergänzend - wenn der "Zustand" bei der float-Angabe bleiben sollte, dann könntest den auch direkt nehmen ohne diesen Umweg - wäre dann eben "> 1.9" vermutlich.

 

[SebastianOH]

Ok das ist alles schonmal hilfreich, mir ist soeben aufgefallen das mein Betriebsstundenzähler nach 9 Minuten stoppt obwohl die Pumpe (der Shelly) auf on steht. Es sieht nach Diagramm so aus als würde er nicht erkennen das der Shelly on ist. der Status ist aber auf on. Gibt nach Zeit unterschiedliche Abfrageintervalle?

 

[Nival]

Hat er das denn sonst auch gemacht?

 

[SebastianOH]

Es wird immer wilder. Im moment stürzt der Pi jedesmal ab wenn ich auf das Logbuch zugreifen will.

 

[SebastianOH]

Hier einmal das Diagramm, verstehe nicht ganz warum er innerhalb von 24 Stunden wieder abfällt, normalerweise sollten Sie doch die gemessenen Stunden innerhalb von 24 Stunden summieren.

 

[Nival]

Was sagt denn der Verlauf von switch.shelly_shsw_1_244cab43ddc4 genau?

 

[SebastianOH]

Das ist ja das wunderliche, sobald ich den Log des Shellys abfragen will rödelt sich der Pi zu Tode, also rote und grüne LED leuchten dauerhaft und irgendwann bootet er neu durch. GUI lässt sich aber noch ansteuern.

 

[SebastianOH]

Wie gesagt, sobald man auf den Verlauf zugreift rödelt er bis zum reboot.

Hier einmal die 2 Verläufe:

 

[blurrrr]

Wie gesagt, sobald man auf den Verlauf zugreift rödelt er bis zum reboot.

Ist die SD-Card vielleicht hinüber?

verstehe nicht ganz warum er innerhalb von 24 Stunden wieder abfällt, normalerweise sollten Sie doch die gemessenen Stunden innerhalb von 24 Stunden summieren.

Könnte ggf. auch was mit der SD-Card zu tun haben (sofern das überhaupt ein Problem ist). Hast Du vom Shelly evtl. nochmal einen Graphen vom 03.08.? Da steigen die Werte ja auch, aber dann springen sie auch wieder ein ganzes Stück weit zurück.

Ich geh mal davon aus, dass der Raspi ansonsten schon die ganze Zeit durchläuft, oder? Weiss ja nicht, ob Du das irgendwie im Blick hast, wenn das Ding sporadisch neustartet

 

[SebastianOH]

Hallo Leute,

ich denke der Fehler ist erstmal behoben. Habe dem Pi einen vernünftigen Lüfter spendiert und nun läuft er sauber. Ok beim Zugriff auf das Logbuch stürzt er hin und wieder immer noch ab.

Ich habe in meinen /System Logs bei verschiedenen Automatisierungen immer Fehlermeldungen wie die hier angehängte mit Verweis auf die Source: helpers/script.py:1442. Kann mir jemand sagen was mir das System sagen will?

Logger: homeassistant.components.automation.steuerung_fussbodenheizung_bad
Source: helpers/script.py:1442
Integration: Automatisierung (documentation, issues)
First occurred: 00:26:38 (52 occurrences)
Last logged: 00:37:09

Steuerung Fußbodenheizung Bad Arbeit: Already running

 

[blurrrr]

Scheint mir so, als soll da etwas gestartet werden, konkret:

homeassistant.components.automation.steuerung_fussbodenheizung_bad

...aber anscheinend läuft es schon... Ich lehn mich einfach mal aus dem Fenster und behaupte etwas in folgende Richtung:

Vermutlich sollte die Fussbodenheizung im Badezimmer zum Zeitpunkt des Log-Eintrages eingeschaltet werden, aber sie war zu diesem Zeitpunkt schon eingeschaltet, deswegen auch die Meldung "läuft bereits" (already running).

 

[SebastianOH]

Ok dann muss ich mir ja keine Sorgen machen. Liegt wohl daran das die Fußbodenheizung durch mehrere Automatisierungen gesteuert wird. Muss mal sehen das ich die gegeneinander verriegele.

Habe es jetzt geschafft mal einen längeren Verlauf des Ursprungsproblem aufzuzeichnen, vielleicht werdet ihr daraus schlau.

Hat jemand einen Tip warum bei mir beim Aufruf des Logbuchs meine Pi neu startet, SD habe ich getauscht.

 

[blurrrr]

Sag mal... kann das vielleicht mal sein, dass da mit der Zählung irgendwas völlig verwurschtelt ist? Also wenn wir jetzt mal davon ausgehen, dass a) die Betriebsstunden "hochgezählt" werden, ist dieses Graphenverhalten "ZACK, direkt um X Zeit gestiegen!" schon mal völlig daneben und b) die langsam "ansteigenden" Graphen (so wie es auch sein sollte), springen wieder zurück auf den Wert, "bevor" der Graph mit seiner korrekten Zählung angefangen hat. Also das macht für mich irgendwie so alles gar keinen Sinn...

Hat jemand einen Tip warum bei mir beim Aufruf des Logbuchs meine Pi neu startet, SD habe ich getauscht.

Da sollte sich "theoretisch" noch was in den Logs finden lassen... Am besten mal einen Zeitraum suchen, wo wenig los ist (wenige Events), dann auf die Uhr schauen, Zeit merken, Log aufmachen, Gerät neu starten lassen und dann - wenn möglich - auf anderem Wege in die Logs schauen. Irgendwo muss ja etwas fehlerhaftes dokumentiert sein, was dann schlussendlich den Neustart des Gerätes auslöst.

 

[SebastianOH]

Ja da gehe ich mit.

Habe die Zähler so wie oben beschrieben in die /configaration.yaml geschrieben. Und das kommt dabei raus, ist dort etwas fehlerhaft?

 

[blurrrr]

Naja, ich sag mal so: "richtig" sieht das ja irgendwie nicht aus... es sollte ja eigentlich - so wie ich das bisher verstanden habe - einfach nur langsam ansteigen ("an"), oder beim letzten Stand bleiben ("aus") und um 0 Uhr setzt sich es sich dann wieder auf "0" zurück. Das wäre jetzt zumindestens das Verhalten, was ich persönlich erwarten würde. Dieses ständige rauf und runter spricht eindeutig dagegen, womit die Vermutung nahe liegt, dass diesbezüglich irgendwas nicht stimmt, dann dieser Absacker dürfte es auf gar keinen Fall geben. Habe da leider auch keine Ahnung von, aber ich würde sagen, dass man ggf. nochmal hingeht und sich diese Sache bzgl. "Laufzeit zählen" nochmal genauer anschaut.