Bitte um Hilfe: Berechnung des (Oel-)Verbrauchs aktuell/gestern/vorgestern/xyz

[Beta-User]

Was genau meinst du mit "(ordentlich getriggertes!)" Reading bzw wie kann ich sicherstellen, dass das Reading "ordentlich getriggert" wird?

Ich wollte erst mal auf das das eingehen, denn das sollte in jedem Fall sauber sein:

Die userReadings werden neu berechnet, wenn sie getriggert werden. Das macht grundsätzlich jeder Vorgang zur Reading-Aktualisierung, mit Ausnahme der "internen" Aktualisierung. Mit "interner" Aktualisierung ist z.B. der update von einem userreadings-Wert gemeint; das verhindert Endlosschleifen (ist bei/innerhalb notify+setreading ähnlich, was hier aber keine Rolle spielt)...

Ergo: Dein Oelverbrauch wird auch aktualisiert, wenn "StartsStufe1" aktualisiert wird (oder sonst eben "irgendwas". Aufgrund des Perl-Codes tippe ich mal darauf, dass es eigentlich nur Sinn macht, das Ding neu zu berechnen, wenn sich BetrStdStufe2 oder BetrStdStufe1 ändern?
Das ergäbe:

Code Auswählen Erweitern

attr userReadings Oelverbrauch:BetrStdStufe[12].* monotonic { my $Oelverbrauch; $Oelverbrauch = (1.74 / 0.84 * (ReadingsVal("SOB_Diagnose","BetrStdStufe1","") - ReadingsVal("SOB_Diagnose","BetrStdStufe2","")) + (2.18 / 0.84 * ReadingsVal("SOB_Diagnose","BetrStdStufe2",""))); sprintf("%.2f", $Oelverbrauch); }
Allerdings: "monotonic" ist eigentlich dafür gemacht, weiterzuzählen, wenn der zugrundeliegende Zähler auch mal wieder "bei 0" anfangen kann, und dem Gefühl nach setzt das auch voraus, dass es _ein_ Zählerwert ist - du hast hier zwei, das hatte ich bei deinem Eingangsbeitrag wohl übersehen . Ich vermute, dass dein Zähler "hart" ist und nicht zurückgesetzt wird?

Dann würde ich "monotonic" doch eher nicht nutzen, sorry für den hier irreführenden Hinweis. So sollte es klappen (vorausgesetzt, die Formel paßt):

Code Auswählen Erweitern

attr userReadings Oelverbrauch:BetrStdStufe[12].* { my $Oelverbrauch; $Oelverbrauch = (1.74 / 0.84 * (ReadingsVal("SOB_Diagnose","BetrStdStufe1","") - ReadingsVal("SOB_Diagnose","BetrStdStufe2","")) + (2.18 / 0.84 * ReadingsVal("SOB_Diagnose","BetrStdStufe2",""))); sprintf("%.2f", $Oelverbrauch); }

Wenn wider Erwarten doch ein Rücksetzen erfolgen sollte, müßten wir uns was anderes überlegen...

[Schotty]

Ergo: Dein Oelverbrauch wird auch aktualisiert, wenn "StartsStufe1" aktualisiert wird (oder sonst eben "irgendwas". Aufgrund des Perl-Codes tippe ich mal darauf, dass es eigentlich nur Sinn macht, das Ding neu zu berechnen, wenn sich BetrStdStufe2 oder BetrStdStufe1 ändern?

Danke, das stimmt, im Grunde würde eine Neuberechnung reichen, wenn sich der Wert von BetrStdStufe1&2 ändert, die Starts sind für den Ölverbrauch in dem Fall uninteressant. Wenn ich irgendwann mal verstanden habe, wie das Ganze funktioniert, dann würde ich evtl auch nochmal die Starts überwachen, ist für weitere Optimierungen des Brennerverhaltens ja auch nicht uninteressant

Allerdings: "monotonic" ist eigentlich dafür gemacht, weiterzuzählen, wenn der zugrundeliegende Zähler auch mal wieder "bei 0" anfangen kann, und dem Gefühl nach setzt das auch voraus, dass es _ein_ Zählerwert ist - du hast hier zwei, das hatte ich bei deinem Eingangsbeitrag wohl übersehen . Ich vermute, dass dein Zähler "hart" ist und nicht zurückgesetzt wird?

Genau, der Zähler wird nicht zurückgesetzt, der Heizungsregler zählt fleißig vor sich hin und ich frage nur die Werte ab.
Zwei Zählerwerte habe ich, da ich zwei Brennerstufen habe. In meiner ersten 'Berechnungsformel' hatte ich einen kg/h-Wert (Ölmassenstrom) für beide Stufen genommen, nach Durchsicht der Unterlagen dann aber für die unterschiedlichen Stufen angepasst (Stufe 2 haut mehr Öl durch als Stufe 1). Evtl muss ich den Wert irgendwann auch nochmal korrigieren (muss nochmal genau den Pumpendruck messen etc).

Dann würde ich "monotonic" doch eher nicht nutzen, sorry für den hier irreführenden Hinweis. So sollte es klappen (vorausgesetzt, die Formel paßt):

Code Auswählen Erweitern

attr userReadings Oelverbrauch:BetrStdStufe[12].* { my $Oelverbrauch; $Oelverbrauch = (1.74 / 0.84 * (ReadingsVal("SOB_Diagnose","BetrStdStufe1","") - ReadingsVal("SOB_Diagnose","BetrStdStufe2","")) + (2.18 / 0.84 * ReadingsVal("SOB_Diagnose","BetrStdStufe2",""))); sprintf("%.2f", $Oelverbrauch); }

Das 'monotonic' hatte ich auch vorhin erst hinzugefügt, hab's jetzt so wie du geschrieben hattest angepasst - danke!

Für mein Verständnis:
Wenn ich das richtig sehe, dann hast du also 'nur'

Code Auswählen Erweitern

:BetrStdStufe[12].* hinter "Oelverbrauch" hinzugefügt.

D.h., der Doppelpunkt zeigt quasi an, dass danach eine Bedingung der Trigger kommt, den es zu berücksichtigen gibt? In diesem Fall dann also: Wenn sich

Code Auswählen Erweitern

BetrStdStufe ändert, dann ist das der Trigger, um

Code Auswählen Erweitern

userReadings Oelverbrauch neu zu berechnen. Ist das

Code Auswählen Erweitern

[12] dann die 'Zusammenfassung' für die Readings BetrStdStufe1 & BetrStdStufe2 und

Code Auswählen Erweitern

.* nimmt dann quasi alles mit, was bei BetrStdStufe an Werten kommt?
Wenn es also BetrStdStufeX und BetrStdStufeY heißen würde, würde man dann [XY] schreiben? Ist vermutlich gerade richtig doof ausgedrückt, aber ich weiß nicht, wie ich es anders formulieren soll, um die Logik/Syntax dahinter etwas besser zu verstehen

EDIT: Formulierung ver(schlimm?)bessert

[Beta-User]

Für mein Verständnis:
Wenn ich das richtig sehe, dann hast du also 'nur'

Code Auswählen Erweitern

:BetrStdStufe[12].* hinter "Oelverbrauch" hinzugefügt.
D.h., der Doppelpunkt zeigt quasi an, dass danach eine Bedingung der Trigger kommt, den es zu berücksichtigen gibt?

Ja. Ungefährer Link zur Doku: https://fhem.de/commandref_modular_DE.html#readingFnAttributes

In diesem Fall dann also: Wenn sich

Code Auswählen Erweitern

BetrStdStufe ändert, dann ist das der Trigger, um

Code Auswählen Erweitern

userReadings Oelverbrauch neu zu berechnen. Ist das

Code Auswählen Erweitern

[12] dann die 'Zusammenfassung' für die Readings BetrStdStufe1 & BetrStdStufe2 und

Code Auswählen Erweitern

.* nimmt dann quasi alles mit, was bei BetrStdStufe an Werten kommt?

Wenn es also BetrStdStufeX und BetrStdStufeY heißen würde, würde man dann [XY] schreiben? Ist vermutlich gerade richtig doof ausgedrückt, aber ich weiß nicht, wie ich es anders formulieren soll, um die Logik/Syntax dahinter etwas besser zu verstehen

EDIT: Formulierung ver(schlimm?)bessert

Genau. Ist eigentlich eine "einfache regex", zu Testen z.B. mit "unseren pdf-Links".

Vermutlich bin ich hier "zu exakt", weil es ja nur 1 und 2 gibt, und man das daher hier auch weglassen könnte, also einfach nur "Oelverbrauch:BetrStdStufe.*" schreiben... Aber es ging ja auch ums Lernen .

[Schotty]

Ja. Ungefährer Link zur Doku: https://fhem.de/commandref_modular_DE.html#readingFnAttributes

Ja danke, u.a. da treibe ich mich ja auch rum - aber du weißt ja, Theorie und Praxis und so..

Vermutlich bin ich hier "zu exakt", weil es ja nur 1 und 2 gibt, und man das daher hier auch weglassen könnte, also einfach nur "Oelverbrauch:BetrStdStufe.*" schreiben... Aber es ging ja auch ums Lernen .

Perfekt

Bzgl der statistics-Geschichte beobachte ich das dann jetzt erstmal ein paar Tage, wie es sich mit dem geänderten userReadings verhält? Oder fallen dir da bereits grobe Schnitzer auf, die grundsätzlich falsch sind..?

[Beta-User]

 
Grobe Schnitzer? ...habe ansonsten nicht danach gesucht , und bin selbst noch recht neu in der "statistics"-Materie. Will sagen: viel mehr als (mit geschultem Auge...) Doku wälzen ist an der Stelle bei mir auch nicht, und wenn's jetzt einigermaßen plausibel funktioniert, bin ich auch froh .

[Schotty]

Achso, ok, dann erstmal danke für's Optimieren des userReadings

Also für mich sehen die Statistiken nicht passend aus, aber dann warte ich einfach noch ein bissl und vielleicht meldet sich ja noch jemand, der den 'Hasen im Pfeffer' sieht (oder ich versuche mein Glück nochmal mit einem entspr neuen Thread)..

[Schotty]

Moin Beta-User,
ich habe gerade mal einen Blick auf 'Oelverbrauch' geworfen:

Code Auswählen Erweitern


   READINGS:
     2020-04-15 10:08:52   BetrStdStufe1   3768
     2020-04-15 10:08:52   BetrStdStufe2   391
     2020-04-15 10:08:52   Oelverbrauch    8009.95
     2020-04-15 10:08:52   StartsStufe1    22815
     2020-04-15 10:08:52   StartsStufe2    22834
     2020-04-15 10:59:55   statOelverbrauch Hour: 0.00 Day: 277.14 Month: 277.14 Year: 277.14 (since: 2020-03-18_20:00:35 )
     2020-04-15 10:59:55   statOelverbrauchHour24 10.88
     2020-04-15 10:59:55   statOelverbrauchLast Hour: 2.07 Day: - Month: - Year: -

Demzufolge wurden die Statistiken um 10:59 aktualisiert, obwohl 'BetrStdStufe' und 'Oelverbrauch' zu dem Zeitpunkt nicht aktualisiert wurden (bzw. vorher um 10:08).
Ist das so korrekt?
Ich hätte jetzt angenommen, die Aktualisierung der Statistiken würden mit deiner Anpassung des userReadings (Oelverbrauch:BetrStdStufe[12].*) dann auch nur stattfinden, wenn sich 'Oelverbrauch' aktualisiert..? Oder hat das quasi nichts miteinander zu tun?

EDIT:
Nachtrag: Um 11:08 wurden die Daten des Heizungsreglers korrekt aktualisiert (alle 60min), damit fand auch eine Aktualisierung (nur!) von 'statOelverbrauch' statt:

Code Auswählen Erweitern


READINGS:
     2020-04-15 11:08:52   BetrStdStufe1   3768
     2020-04-15 11:08:52   BetrStdStufe2   391
     2020-04-15 11:08:52   Oelverbrauch    8009.95
     2020-04-15 11:08:52   StartsStufe1    22817
     2020-04-15 11:08:52   StartsStufe2    22836
     2020-04-15 11:08:52   statOelverbrauch Hour: 0.00 Day: 277.14 Month: 277.14 Year: 277.14 (since: 2020-03-18_20:00:35 )
     2020-04-15 10:59:55   statOelverbrauchHour24 10.88
     2020-04-15 10:59:55   statOelverbrauchLast Hour: 2.07 Day: - Month: - Year: -

Also wurde 'Oelverbrauch' auch aktualisiert, obwohl sich die Werte bei 'BetrStdStufe' nicht geändert haben
So ganz verstehe ich die Arbeitsweise dahinter nicht

Btw: Was ist deiner Meinung nach der richtige Ort für meine Frage hinsichtlich 'statistics' - hier bei den Anfängerfragen oder im Board 'Unterstützende Dienste'?

[Beta-User]

Hmm, der richtige Ort? Schwierig... Der Modulautor liest vermutlich hier nicht mit, aber ich bin auch nicht überzeugt, dass wir ihn wirklich brauchen:

Es ist m.E. richtig, dass statistics die periodischen Werte (bzw. die zwischenzetlichen Änderungen) jeweils zum Ende der Periode "wegschreibt". Ziel ist es ja, (via FileLog, das afaik keine Datenbankauswertung unter Berücksichtigung von Zeitstempeln kennt) Daten so aufzubereiten, dass man sie vor allem auch plotten kann. Dafür braucht man eben diese Aktualisierungsvorgänge, die dann auch wieder von FileLog (als Eventhandler) erkannt werden.

Ergo: in meiner Gedankenwelt ist alles iO., wenn um kurz vor der ganzen Stunde die statistics-Readings erneuert werden.

[Schotty]

Ok, das klingt ja schonmal gut
Was mich (neben den m.M.n. nicht-passenden Statistiken -> das wäre dann ja auch das Fragethema für den neuen Thread) nur eben wundert ist, dass 'Oelverbrauch' auch aktualisiert wurde, obwohl sich die Werte von BetrStdStufe ja nicht geändert haben. Meinem Verständnis nach hätte das nach der gestrigen Ergänzung des Triggers doch nicht passieren 'dürfen'?
Es stört mich jetzt nicht wirklich, wundert mich nur eben, dass der Trigger anscheinend nicht 'berücksichtigt' wurde..?

[Beta-User]

An den Zeitstempeln der Readings kann man m.E. nicht ablesen, dass der Trigger nicht richtig wirkt: Es wurden alle Readings um 10:08:52 bzw. genau eine Stunde später aktualisiert. Dass sich der Wert ggf. nicht ändert, ist sachlich richtig, da ja keine Änderung stattfand, sondern nur getriggert wurde.

Wenn du das auschalten wolltest (was ich nicht empfehle, da alle Stunde ja nicht ständig ist), wäre event-on-change die richtige Adresse.

[Schotty]

Achso - ich nahm jetzt an, dass userReadings in dem Fall dann auch gar nicht erst aktualisiert wird. Alln's kloar, dann lasse ich das alles so

event-on-change ist (für mich persönlich) ein anderes 'Problem'-Thema, wo es beim Verständnis auch noch hakt - ich sag ja: ich muss mich für's PDF gar nicht groß anstrengen, um den 'DAU' zu mimen 

[Beta-User]

event-on-change ist (für mich persönlich) ein anderes 'Problem'-Thema, wo es beim Verständnis auch noch hakt

Das ist ziemlich facettenreich und insgesamt sehr viel spannender, als es zunächst vielleicht den Anschein macht. Wer da in die Irre läuft, ist nicht zwangsläufig ein DAU, und was man in diesem Umfeld wie macht, hängt auch von den konkreten Umständen und Bedürfnissen ab .

Vielleicht eine Kurzfassung:

In Schritt 1 entscheidet der Modulautor, ob die Anweisung triggern soll, ein oder mehrere Readings zu schreiben. Mit event-on-change kann jetzt der User in Schritt 2 entscheiden, ob er es doch nicht triggernd haben will bzw. bei welchen Abweichungen usw. (zum ungekehrten Fall: event-on-update).

Manchmal ist es auch nicht der Modulautor selbst, der das Zusammenspiel beeinflusst:
Denn manche Geräte senden nur Infos, wenn sich was ändert bzw. wenn gemessen wurde. Das ist an sich der einfachste Fall, aber gelegentlich kommt es vor, dass auch das "schlecht" ist, weil der User bestimmte Zustände plotten will, und daher eben hin und wieder den aktuellen (unveränderten) Wert in den LogFiles braucht.
Aber andere Geräte melden ständig auch unveränderte Werte (die Shelly@MQTT@default-Einstellung), die an sich eher statisch sind, z.B. der Zustand eines Relais. Das kann auch Probleme machen, wenn du das z.B. dazu nutzen willst, ein anderes Gerät zu schalten, aber eben nur dann, wenn es angeschaltet wird, nicht, wenn es meldet "bin immer noch an"...

FHEM selbst kann nicht wissen, ob eine bloße Erneuerung vorliegt oder ein neuer Meßwert, selbst, wenn der unverändert ist. Ergo muß man das ggf. mühsam abschichten und dann ggf. die Gegenausnahmen und zeitlichen Grenzen festlegen (event-min-interval, event-on-update)...

[Schotty]

Wer da in die Irre läuft, ist nicht zwangsläufig ein DAU

Ach, du bist so gut zu mir, danke (auch für die Erklärung)

[Beta-User]

Ach, du bist so gut zu mir, danke (auch für die Erklärung)

Gern geschehen; ich (bzw. wir) brauch(en) diese Art der "anderen Erklärung" m.E. ja "irgendwann" (wenn sie taugt); wiederfinden wäre dann schön .

[Schotty]

Yupp, das Wiederfinden sollte nicht das Problem sein, ich werde bei Gelegenheit auch nochmal gezielt nach deinen Erklärungen für mich suchen und sie gesammelt abspeichern.
Der Grund für das 'Nicht-Funktionieren' bei mir, wenn ich e-o-c gesetzt hatte (Problem war: es wurde nichts mehr aktualisiert, auch wenn sich bspw der Brennerstatus geändert hatte), war jedoch offensichtlich ein ganz anderer (trivial und DAU-anmutend): Ich hatte e-o-c im Device gesetzt, aber keine Readings angegeben, da ich annahm, dass es dann für alle Readings von dem Device gelten würde. Funktioniert so aber anscheinend nicht
Jetzt habe ich explizit die Readings mit angegeben und es scheint zu funktionieren
EDIT: Evtl hätte es mit

Code Auswählen Erweitern

attr SOB_Brenner event-on-change-reading .* funktioniert, dass e-o-c auf alle Readings im Device SOB_Brenner greift..?! Muss ich mal testen..