Bedarfsgerechte Einschränkung der Events und Logfile-Einträge

Begonnen von sunrise, 24 Januar 2024, 10:43:51

Vorheriges Thema - Nächstes Thema

sunrise

EDIT:
Den Titel dieses ganzen Threads habe ich angepasst. Vorher hieß er "Ergänzung von in Excel nachberechneter Statistik-Werte ins Logfile eines Moduls?".

Da wir aber weit über das Thema hinausgegangen und andere tolle Lösungen besprochen haben, die auch von anderen Nutzern gefunden werden sollten, falls sie danach suchen, macht ein neuer Titel Sinn. 😊 
(EDIT-Ende)


Hallo zusammen!

Bekanntlich führen viele Wege nach Rom. 😉 Damit ich mich nicht allzusehr verlaufe, wollte ich hier nachfragen, wie Ihr folgendes "Problem" angehen würdet:

Seit 01.01.2024 logge ich u.a. den Strom-Verbrauch in FHEM (Obis Modul). Erst seit dem 24.01. habe ich auch das Statistics Modul am Start, welches anhand des aktuellen(!) Verbrauchswerts (total_consumption) statistische Werte wie Verbrauch pro Stunde, pro Tag, pro Monat und pro Jahr ins Obis Logile schreibt (Die Tages-, Monats- und Jahres-Werte entsprechen im Moment noch dem Stunden-Wert, aber das wird sie ja in den kommenden Tagen und Monaten ändern.

D.h., dass mir diese Statisik-Werte (Stunden-, Tages-, Monats- und Jahres-Werte des Verbrauchs) vom 01.01.-23.01. im Logile fehlen, wobei ich diese (aktuell wenigstens Stunden- und Tages-Werte) wohl außerhalb von FHEM nachberechnen und anschließend ins Obis Logfile schreiben könnte.

Soweit ich es richtig verstanden habe, könnte ich dazu das aktuelle Obis Logfile in Excel importieren, dort anhand entsprechender Formeln die seit dem 01.01. bis 23.01. fehlenden Statistik-Werte des Verbrauchs ausrechnen und dann das damit "angereicherte" Obis Logfile zurück nach FHEM schreiben (z.B. über WinSCP o.ä. - FHEM sollte dabei vermutlich temporär angehalten werden).

Ist das so in etwa möglich und sinnvoll? Welche Alternativen gibt es noch, z.B. auch direkt in FHEM?


Falls in Excel:

Sollte ich das komplette Obis Logfile vom Januar 2024 (bisher ca. 44.000 Zeilen - passt also noch) in Excel importieren oder nur Zeilen, welche die total_consumption, also den Verbrauch, enthalten?
Alle Werte pro Tag? (damit auch die "pro Stunde" Statistik nachher passt)
Reicht dann der Wert 1x/h? (ich habe Werte im 4-Minutentakt im Logfile)

Wie gehe ich mit den Zeitstempeln um? Sollte ich die auch alle (also die kompletten Zeilen aus dem Obis Logile) in Excel importieren, damit ich dann beim Berechnen in Excel auch irgendwie den zeitlichen Zusammenhang für die berechneten Statistik-Werte habe, oder macht es anders mehr Sinn?

Was sollte ich sonst noch beachten?


Mit Excel kann ich eigentlich ganz gut umgehen, allerdings fehlt mir derzeit etwas der Überblick, wie ich am sinnvollsten vorgehe - daher ja auch meine Frage hier im Forum. 😊


Herzlichen Dank schonmal für Eure Gedanken und Hinweise! 👍
Viele Grüße/kind regards
sunrise
_________________
Tecalor THZ 303 (SOL, 2006/09-2008/08), FW 2.16 | FHEM THZ module testing with FW 2.06 (INTEGRAL, 2006/12-2008/08) & FW 2.14 (SOL, 2002/10-2004/08) on Raspberry Pi 2

DasQ

Ich empfehle drastisch die Daten zu reduzieren.

Keep it simple.

Und natürlich kannst du bestehende Logs ,,manipulieren" (is halt viel Handarbeit)
Excel ist da sehr gut geeignet. Es tut aber auch ein guter Texteditor(z.b. sublime Text).

Als Format würde ist cvs Datei nutzen. Formeln brauchst du eigentlich nicht. ,,Suchen und ersetzen" ist dein Freund.
Fhem on MacMini/Ubuntu.
Absoluter Befürworter der Konsequenten-Kleinschreibung https://de.wikipedia.org/wiki/Kleinschreibung
Infos zu Klimawandel http://www.globalcarbonatlas.org

sunrise

Die Log-Frequenz werde ich reduzieren - hatte das bisher so eng gesetzt, um einige Dinge besser zu verstehen.

Wie soll das aber mit "Suchen & Ersetzen" gehen? Ich benötige doch für die fehlenden Statistik-Werte irgendwelche Formeln, zumindest, wenn ich Min./Max./Avg. u.ä. benötige. Allerdings merke ich gerade, dass ich wohl für schlichtes "pro Stunde", "pro Tag" etc. tatsächlich nur die entsprechenden Werte finden und als neue (Statistik-)Events setzen muss. Ist mein Verständnis korrekt?
Viele Grüße/kind regards
sunrise
_________________
Tecalor THZ 303 (SOL, 2006/09-2008/08), FW 2.16 | FHEM THZ module testing with FW 2.06 (INTEGRAL, 2006/12-2008/08) & FW 2.14 (SOL, 2002/10-2004/08) on Raspberry Pi 2

DasQ

Korrekt.

Min Max kann man natürlich über Formel ermitteln.
Geht aber auch über Fhem direkt.
Fhem on MacMini/Ubuntu.
Absoluter Befürworter der Konsequenten-Kleinschreibung https://de.wikipedia.org/wiki/Kleinschreibung
Infos zu Klimawandel http://www.globalcarbonatlas.org

KölnSolar

Dann auch hier mal wieder ich.  ;D

Brauchst Du denn wirklich die paar Tage ? Ist es die Mühe wert ? Du wirst irgendwann sowieso nicht mehr auf einen konkreten Tag gucken wollen. Zumal Tagesdaten stark vom individuellen Verhalten abhängen.

Der Wunsch nach korrektem Monats- und Jahreswert ist hingegen nachvollziehbar. Es könnte folgende Vorgehensweise funktionieren:

 - Ermittlung des Wertes Year-to-Date(=Month-To-Date)
 - FHEM stoppen
 - fhem.save editieren: setreading OBIS-device .... stat.... Zeilen an die ermittelten Year-To-Date Werte anpassen
 - FHEM starten

Grüße
Markus



RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

sunrise

#5
Danke! 😀

Ich möchte die Verbrauchs-Werte (Wh) gerne in Korrelation mit Werten meiner Wärmepumpe sehen. Das geht eigentlich auch prima mit den Leistungs-Werten (W), aber mich hat das Thema halt gejuckt. 🤭

Deinem Einwand stimme ich jedoch gerne zu. 👍
Viele Grüße/kind regards
sunrise
_________________
Tecalor THZ 303 (SOL, 2006/09-2008/08), FW 2.16 | FHEM THZ module testing with FW 2.06 (INTEGRAL, 2006/12-2008/08) & FW 2.14 (SOL, 2002/10-2004/08) on Raspberry Pi 2

sunrise

Sorry, folgendes verstehe ich nicht:
Wenn ich FHEM stoppe, geht setreading doch gar nicht. 🤔
Viele Grüße/kind regards
sunrise
_________________
Tecalor THZ 303 (SOL, 2006/09-2008/08), FW 2.16 | FHEM THZ module testing with FW 2.06 (INTEGRAL, 2006/12-2008/08) & FW 2.14 (SOL, 2002/10-2004/08) on Raspberry Pi 2

KölnSolar

RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

sunrise

Ok, aber setstate geht doch (wie alles andere auch) nicht, wenn FHEM gestoppt wurde, oder missverstehe ich etwas?


Und noch etwas:
Weshalb legt statistics jede Minute(!) Werte im Logfile ab? Die SD-Karte wird das nicht lange mitmachen. Wie kann ich das reduzieren?
Vor allem verstehe ich nicht, weshalb Stunden- und Tages-Werte nicht nur jeweils 1x/h bzw. 1x/Tag abgelegt werden:

2024-01-24_09:22:14 MyObis1 statTotal_consumptionHour: 37.3
2024-01-24_09:22:14 MyObis1 statTotal_consumptionDay: 37.3

2024-01-24_09:23:14 MyObis1 statTotal_consumptionHour: 57.2
2024-01-24_09:23:14 MyObis1 statTotal_consumptionDay: 57.2

Und schließlich ist mir nicht klar, weshalb es im Logfile kein statTotal_consumptionHourLast gibt, was aber im Plot-Editor verfügbar und für meine Balkendiagramme auch korrekt ist. Woher kommt das ...Last, wenn es nicht im Obis Logfile enthalten ist?

set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title '<L1>'
set ytics
set y2tics
set grid ytics y2tics
set ylabel "Wh"
set y2label "Wh"

#FileLog_MyObis1 4:MyObis1.statTotal_consumptionHourLast\x3a::

plot "<IN>" using 1:2 axes x1y2 title 'Elektrischer Verbrauch (Wh)' ls l0fill lw 1 with bars
Viele Grüße/kind regards
sunrise
_________________
Tecalor THZ 303 (SOL, 2006/09-2008/08), FW 2.16 | FHEM THZ module testing with FW 2.06 (INTEGRAL, 2006/12-2008/08) & FW 2.14 (SOL, 2002/10-2004/08) on Raspberry Pi 2

sunrise

Wenn ich nun mit event-min-interval und evtl. auch mit event-on-change-reading hantiere, wie stelle ich dann sicher, dass ich wenigstens zur vollen Stunde einen Hour-Wert vom statistics Modul bekomme? Ih blick da gerade nicht so durch, fürchte ich.
Viele Grüße/kind regards
sunrise
_________________
Tecalor THZ 303 (SOL, 2006/09-2008/08), FW 2.16 | FHEM THZ module testing with FW 2.06 (INTEGRAL, 2006/12-2008/08) & FW 2.14 (SOL, 2002/10-2004/08) on Raspberry Pi 2

KölnSolar

Zitatoder missverstehe ich etwas?
ja.
FHEM steht und Du änderst in fhem.save nur die gewünschten Zahlen. Bei restart wird fhem.save gelesen und die readings mit diesen Werten "initialisiert".
ZitatWeshalb legt statistics jede Minute(!) Werte im Logfile ab? Die SD-Karte wird das nicht lange mitmachen. Wie kann ich das reduzieren?
Vor allem verstehe ich nicht, weshalb Stunden- und Tages-Werte nicht nur jeweils 1x/h bzw. 1x/Tag abgelegt werden:
Das hängt einerseits von Deinem regexp der filelog-Definition ab und andererseits wird der Statistik-Wert laufend, also bei jedem event berechnet. Um überhaupt den Datenwust einzudämmen, musst Du Dir mal event-on-change ansehen. Dann werden wenigstens nur noch bei Änderungen Statistikwerte berechnet und gelogged. Und natürlich den regexp auf das beschränken, was Du als trigger(notify, filelog,....) auch wirklich benötigst.
Dein Ziel, nur jeweils 1x/h bzw. 1x/Tag zu loggen kannst Du erreichen, indem per zyklischen at's setreading(s) ausführst und nur diese über den regexp loggst. Oder userreadings mit trigger von ....Last(wird wie gewünscht nur /Std. u. /Tag gesetzt).
ZitatUnd schließlich ist mir nicht klar, weshalb es im Logfile kein statTotal_consumptionHourLast gibt, was aber im Plot-Editor verfügbar und für meine Balkendiagramme auch korrekt ist.
Das kann eigentlich nicht sein. Du kannst nur etwas plotten oder im Ploteditor angezeigt bekommen, was auch wirklich im Logfile steht.

ZitatWenn ich nun mit event-min-interval und evtl. auch mit event-on-change-reading hantiere, wie stelle ich dann sicher, dass ich wenigstens zur vollen Stunde einen Hour-Wert vom statistics Modul bekomme? Ih blick da gerade nicht so durch, fürchte ich.
Da hast Du ja schon die richtigen Kandidaten erwähnt. mit on-change sagst Du: nur event/trigger bei Veränderung des Werts. Mit min-interval definierst Du einen Zeitraum, dass nach Ablauf der Zeit auch ohne Änderung des Werts ein event/trigger erzeugt wird.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

sunrise

Achso, Du meintest mit setstate, dass ich das in fhem.save (wenn FHEM gestoppt ist) editieren soll. Ich hatte Dich missverstanden, dass ich setstate als Kommando in FHEM aufrufen soll, sorry.

Wenn ich event-min-interval und event-on-change-reading nutze, benötige ich aber keine zyklischen at's setreading(s), richtig?

Bzgl. ...Last hast Du natürlich recht - ich hatte schlicht einen Typo im Filter. :-[
Viele Grüße/kind regards
sunrise
_________________
Tecalor THZ 303 (SOL, 2006/09-2008/08), FW 2.16 | FHEM THZ module testing with FW 2.06 (INTEGRAL, 2006/12-2008/08) & FW 2.14 (SOL, 2002/10-2004/08) on Raspberry Pi 2

KölnSolar

ZitatWenn ich event-min-interval und event-on-change-reading nutze, benötige ich aber keine zyklischen at's setreading(s), richtig?
Kommt halt darauf an, was Du genau haben möchtest. Einen stundenscharfen Wert wirst Du mit event-min-interval schwierig(ich spekuliere: gar nicht) hinbekommen.
Du bekommst je nach Verlauf bei minütlichen Werten min-interval < x < 60 Werte je reading.

Mit welcher Genauigkeit kommen denn Deine Werte ? Wie in Deinem o.g. Beispiel mit einer Nachkommastelle und ich vermute in Einheit Watt ?

RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

sunrise

#13
Momentan kommen die total_consumption und statTotal_consumptionXXX Werte minütlich, was ich tatsächlich gerne reduzieren möchte. Damit schone ich die SD-Karte und habe mehr Überblick. Außerdem brauche für ersteres nur eine zeitliche Auflösung von 5 Minuten (und nur, wenn sich der Wert ändert) und für letzteres nur zur vollen Stunde bzw. 1x/h, falls es exakt zur vollen Stunde für mich zu kompliziert wird (at's etc.).

Wenn ich es bisher richtig verstanden habe, werde ich wohl nur mit zyklischen at's setreading(s) das stundengenaue Ziel erreichen, allerdings fehlt mir dafür noch das Wissen zur Umsetzung (bin immer noch FHEM-Anfänger). Andererseits sehe ich momentan keinen zwingenden Grund, dass die Werte zur vollen Stunde kommen müssen.

Wie wäre das aber bei den Tageswerten? Da macht es ja schon einen größeren Unterschied, ob ein Wert um 23:01 Uhr oder "pünktlich" um 00:00 Uhr kommt, oder irre ich mich?

Die Werte sind in Watt mit einer Nachkommastelle.

Noch eine Verständnisfrage zu event-on-change-reading: Muss ich das nicht weglassen, weil sich der Strom-Verbrauch ja laufend ändert? Das würde doch nur Sinn machen z.B. bei einer Wetterstation, wo sich die Temperatur nicht jede Minute ändert.
Viele Grüße/kind regards
sunrise
_________________
Tecalor THZ 303 (SOL, 2006/09-2008/08), FW 2.16 | FHEM THZ module testing with FW 2.06 (INTEGRAL, 2006/12-2008/08) & FW 2.14 (SOL, 2002/10-2004/08) on Raspberry Pi 2

sunrise

Zitat von: sunrise am 24 Januar 2024, 18:31:38Noch eine Verständnisfrage zu event-on-change-reading: Muss ich das nicht weglassen, weil sich der Strom-Verbrauch ja laufend ändert? Das würde doch nur Sinn machen z.B. bei einer Wetterstation, wo sich die Temperatur nicht jede Minute ändert.

Momentan ist der Stromzähler so definiert:
attr MyObis1 event-min-interval .*:300
attr MyObis1 event-on-change-reading .*
attr MyObis1 pollingMode on
attr MyObis1 timestamp-on-change-reading .*

Und das statistics Modul so:
attr MyStatObis1 event-min-interval .*:300
attr MyStatObis1 event-on-change-reading .*

Ich hatte erwartet, dass nur alle 5 Minuten (300 Sekunden) ein Wert kommt.

Tatsächlich kamen bis zum Zeitpunkt, zu dem ich das statistics Modul hinzugefügt hatte, die Werte der Obis Parameter alle 4 Minuten (warum alle 4 und nicht alle 5, verstehe ich auch nicht, aber das ist momentan mein kleineres Pobleme, denke ich).

Seit dem ich das statistics Modul in Gebrauch habe, kommen jede Minute für (fast) alle Obis Parameter Werte ins Obis Logfile:
2024-01-24_19:31:23 MyObis1 power: xx41
2024-01-24_19:31:23 MyObis1 statTotal_consumption: Hour: xx1.9 Day: xxx00.0 Month: xxx00.0 Year: xxx00.0 (since: 2024-01-24_09:21:25 )
2024-01-24_19:31:23 MyObis1 statTotal_consumptionHour: xx1.9
2024-01-24_19:31:23 MyObis1 statTotal_consumptionDay: xxx00.0
2024-01-24_19:32:23 MyObis1 total_consumption: xxxxx24
2024-01-24_19:32:23 MyObis1 power: xx42
2024-01-24_19:32:23 MyObis1 statTotal_consumption: Hour: xx6.0 Day: xxx24.1 Month: xxx24.1 Year: xxx24.1 (since: 2024-01-24_09:21:25 )
2024-01-24_19:32:23 MyObis1 statTotal_consumptionHour: xx6.0
2024-01-24_19:32:23 MyObis1 statTotal_consumptionDay: xxx24.1
2024-01-24_19:33:25 MyObis1 total_consumption: xxxxx48.5
2024-01-24_19:33:25 MyObis1 power: xx49
2024-01-24_19:33:25 MyObis1 statTotal_consumption: Hour: xx0.5 Day: xxx48.6 Month: xxx48.6 Year: xxx48.6 (since: 2024-01-24_09:21:25 )
2024-01-24_19:33:25 MyObis1 statTotal_consumptionHour: xx0.5
2024-01-24_19:33:25 MyObis1 statTotal_consumptionDay: xxx48.6

Einzig Hersteller_ID und Geraetekennung kommen wie erwartet alle 5 Minuten - wobei ich das dringend abstellen muss, denn die bleiben ja stets gleich. Das würde ich dann wohl so machen:
attr MyObis1 event-on-change-reading .*,(?!Hersteller_ID).*,(?!Geraetekennung).*
Allerdings ist mir dann immer noch nicht klar, weshalb die anderen Werte seit Nutzung des statistics Moduls minütlich kommen. Ich übersehe vermutlich das Offensichtliche. 😳

Danke für's Augenöffnen! 😊
Viele Grüße/kind regards
sunrise
_________________
Tecalor THZ 303 (SOL, 2006/09-2008/08), FW 2.16 | FHEM THZ module testing with FW 2.06 (INTEGRAL, 2006/12-2008/08) & FW 2.14 (SOL, 2002/10-2004/08) on Raspberry Pi 2