FHEM Forum

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! 👍

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.

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?

Korrekt.

Min Max kann man natürlich über Formel ermitteln.
Geht aber auch über Fhem direkt.

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

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. 👍

Sorry, folgendes verstehe ich nicht:
Wenn ich FHEM stoppe, geht setreading doch gar nicht. 🤔

Ups, natürlich setstate.

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


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.

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.

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. :-[

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 ?

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.

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! 😊

Kannst mir nochmal kurz erklären wie dein Aufbau ist?

Als Beispiel

Ich hab nenn SML ir lesekopf an tasmota und lese so mein smartmeter aus. (Mir scheint bei dir ist das ähnlich)
Ich kann in dem tasmota zum einen vorfiltern und konzentrieren. Vorfiltern nur relevante Werte. Konzentrieren, die Daten zu einem mqtt packet (json) zusammenpacken und nur die alle 5 o. 10minuten senden.

Dann als Anregung (weil auf lange Sicht, wirst bei der Menge Daten, mit einem statischen Speicher wie einer sd Karte, tot unglücklich)
Was hälst du von einer Datenbank?

Ich habe 2 Devices (MyObis1 und MyObis2) definiert für 2 Hichi USB IR an 2 Stromzählern. Beide hängen direkt am RPi2 (sorry, Tasmota kenne ich nur von Hörensagen), und ich sah bisher alle relevanten Werte im Logfile und Plots. Für Plots machten bisher nur die Leistungen (power) Sinn, weil die Verbräuche (total_consumption) ja ständig steigen - ohne Statistiken mit Stunden-, Tages- etc. Werte sind Plots da sinnlos. Das wollte ich nun ändern, und dabei fiel mir halt auf, dass plötzlich fast alle Werte minütlich kommen.

Irgendwann werde ich evtl. vom Logfile auf DB wechseln, falls es hilft, aber die Lernkurve ist für mich steil.

Außerdem habe ich einen RPi4 mit Home Assistant, wo ich schon einige Werte meiner Heizung und meines Stroms von FHEM via MQTT sehe. Aber ich möchte das jetzt noch nicht weiter aufbohren, weil ich sonst zu viele Baustellen gleichzeitig habe. Auch kann ich nicht FHEM und HA auf ein Gerät bringen.

Erstmal möchte ich dahin kommen, dass Werte in FHEM so selten wie möglich und so häufig wie nötig ins Obis Logfile geschrieben werden und Stromverbrauchswerte pro h/d/m/y für einen Plot verfügbar sind.

Ich hoffe, ich habe mein Setup verständlich erläutert. Ansonsten lege ich gerne noch nach. 😉

Jedenfalls nochmals herzlichen Dank für's Interesse und die Hilfe! 👍

Es ist viel zu tun. Packen wirs an. 8)

ZitatDie Werte sind in Watt mit einer Nachkommestelle.

Fragte ich, um ein Gefühl für die Häufigkeit von Änderungen zu bekommen. Es sind dann Wattstunden u. bei minütlichen Werten u. Zehnteln hast Du bereits Änderungen/min, weshalb event-on-change wenig Sinn macht. Wie Du schon selber festgestellt hast.

ZitatNoch 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.

event-on-change hat aber noch einen anderen Effekt. Den hast Du auch schon erkannt.

ZitatEinzig 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 mache

Also filtern von events. In Deinem Fall nicht attr MyObis1 event-on-change-reading .*,(?!Hersteller_ID).*,(?!Geraetekennung).*sondern attr MyObis1 event-on-change-reading .*consumption.*,power.*alle anderen readings erzeugen nun keine events mehr, können weder gelogged, noch als trigger benutzt werden.

Zitattimestamp-on-change-reading

braucht man eher nicht.

attr MyStatObis1 event-min-interval .*:300
attr MyStatObis1 event-on-change-reading .*Auf die Idee wäre ich nie gekommen. Lass es weg, denn das device ist nur zum definieren. Die readings/events sind ja im Zählerdevice.

Das erst einmal als "Grundausstattung" und dann sehen wir weiter...

ZitatRPi2

würd ich schleunigst ersetzen. Zum Einstieg noch ok, aber Deine Plots werden erschreckend langsam werden.

Die events haben wir bereits auf das wesentliche reduziert, um das System zu schonen.
Du hast aber noch viel zu viel logging, was der SD u. dem plotten schadet. Also dort weiter reduzieren. Die Statistik-readings willst Du gar nicht loggen, alsodefine .... FileLog .... (power|total).*

aber stündlich willst Du sie halt doch. Unbedingt im selben File oder vielleicht ein separates ?

userreadings und ein eigenes reading helfen
attr MyObis1 userReadings DeinReadinghour:statTotal_consumptionHourLast difference {ReadingsVal($name,'statTotal_consumptionHourLast',0)}

Logging im selben file define .... FileLog .... (power|total|Dein).*

Danke für Deine großartige Geduld! 😊

Wenn ich es richtig verstehe, muss die RegEx so aussehen, dass nur noch folgende Readings von den bisherigen kommen:

ZitatGeraetekennung
Hersteller_ID
power
statPowerDay
statPowerDayLast
statPowerMonth
statPowerYear
statTotal_consumption
statTotal_consumptionDay
statTotal_consumptionDayLast
statTotal_consumptionHour
statTotal_consumptionHourLast
statTotal_consumptionLast
state
total_consumption
total_feed

Evtl. könnte ich auch noch die in Rot hervorgehobenen Parameter rausfiltern, da ich sie m.E. für keine Plots u.a. benötige. Mein 24h-Plot benötigt nur statTotal_consumptionHourLast und mein Monatsplot (wenn genügend Werte vorhanden sind) wird nur statTotal_consumptionDayLast benötigen, wenn ich das richtig sehe.

Der Parameter state (opened) taucht im Logfile aber ohnehin nicht auf.
Der Parameter total_feed ist für mich (noch) nicht relevant, da ich (noch) nichts einspeise.

Ich verstehe die RegEx MyObis1:(power|total).* so, dass dann aber weiterhin auch total_feed geloggt würde, weshalb ich das wohl anders formulieren muss:
define FileLog_MyObis1 FileLog /opt/fhem/log/MyObis1-%Y-%m.log MyObis1:(power|statTotal_consumptionDayLast|statTotal_consumptionHourLast|total_consumption)
Ich habe einige Wikis und Tutorials zu Perl RegEx gelesen, bin mir aber nicht sicher, ob ich hier richtig liege. So wie ich es nun formuliert habe, ist es eigentlich keine echte RegEx mehr, weil die 3 gewünschten Parameter voll ausgeschrieben in Klammern stehen (mal von den Pipes abgesehen). Aber wenn ich nur die 3 Parameter möchte (und auch hier hoffe ich, dass ich damit richtig liege), ist die Schreibweise so ok?

EDIT1:

Zitat von: KölnSolar am 24 Januar 2024, 22:01:47Die Statistik-readings willst Du gar nicht loggen, also

Code Auswählen Erweitern

define .... FileLog .... (power|total).*

Gar nicht? Ich dachte, ich benötige 2-3 davon, um nachher etwas plotten zu können. 🤔 (EDIT-Ende)


Device und Logfile sind nun wie folgt definiert (unter der Annahme, dass das, was ich oben schrieb, korrekt ist und unter Berücksichtigung Deiner Hinweise):
define MyObis1 OBIS /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0041-if00-port0@9600,8,N,1,SML
attr MyObis1 channels {\
"1.0.96.50.1.1"=>"Hersteller_ID",\
"1.0.96.1.0.255"=>"Geraetekennung"}   # Obis-spezifisch, einzelne Kanal-Readings umbenennen
attr MyObis1 pollingMode on  # Obis-spezifisch, Umstellung von Direktbenachrichtigung auf Polling, damit Smartmeter nicht im Sekundentakt Daten sendet
attr MyObis1 interval 60  # Obis-spezifisch, Daten nur alle 60 Sekunden - ggf. noch auf 300 erhöhen (5 Minuten)
attr MyObis1 unitReadings off  # Obis-spezifisch, keine Einheiten anhängen
attr MyObis1 event-min-interval .*:300
attr MyObis1 event-on-change-reading .*consumption.*,power.*
attr MyObis1 alias Haushalts-Strom
attr MyObis1 icon stromzaehler_icon@red
attr MyObis1 room Strom
attr MyObis1 verbose 3

define FileLog_MyObis1 FileLog /opt/fhem/log/MyObis1-%Y-%m.log MyObis1:(power|statTotal_consumptionDayLast|statTotal_consumptionHourLast|total_consumption)
attr FileLog_MyObis1 archivedir /opt/fhem/log/archive/
attr FileLog_MyObis1 createGluedFile 1
attr FileLog_MyObis1 nrarchive 2

EDIT2:
Jetzt sehe ich ein Problem. Während des (längeren) Schreibens meines Beitrags und Anpassungen in FHEM sehe ich jetzt (10:43), dass die letzten Obis Logfile Einträge von 10:27 sind. Das ist definitiv zu wenig/selten. Irgendwo habe ich wohl bereits um 10:27 etwas verändert, was zu viel des Guten war => Plot-Abriss. (EDIT-Ende)


Deine Idee, verschiedene Logfiles zu nutzen, gefällt mir, und darum kümmere ich mich in einem nächsten Schritt.

Ich finde es sehr freundlich, dass Du Dir Deine Zeit nimmst, mir (und anderen Mitstreitern) weiterzuhelfen. Tausend Dank! 😀👍

Zitat von: sunrise am 25 Januar 2024, 10:42:19Wenn ich es richtig verstehe, muss die RegEx so aussehen, dass nur noch folgende Readings von den bisherigen kommen:

ZitatGeraetekennung
Hersteller_ID
power
statPowerDay
statPowerDayLast
statPowerMonth
statPowerYear
statTotal_consumption
statTotal_consumptionDay
statTotal_consumptionDayLast
statTotal_consumptionHour
statTotal_consumptionHourLast
statTotal_consumptionLast
state
total_consumption
total_feed

Nun schaue ich mir nochmal die Zeile an:
attr MyObis1 event-on-change-reading .*consumption.*,power.*
Das .* vor und hinter consumption bedeutet doch, dass alle Readings betroffen sind, die irgendwo im Namen consumption enthalten. Das .* nur hinter power, dass alle Readings betroffen sind, die mit power im Namen beginnen.

Letzteres bedeutet, dass nur das Reading power berücksichtigt wird, nicht aber die anderen power im Namen enthaltenden Readings, die oben in Rot dargestellt sind. Das ist ja soweit ok, denke ich.

Ersteres bedeutet doch aber, dass auch Readings in Rot dabei wären, d.h. statTotal_consumption, statTotal_consumptionDay, statTotal_consumptionHour und statTotal_consumptionLast. Will ich das wirklich oder können die auch weg? Dann müsste ich die RegEx in der o.g. Zeile nochmal anpassen oder nicht?

Sorry, ich blicke bei den RegEx nicht ganz durch und mir ist auch nicht ganz klar, welche Parameter wirklich zwingend nötig sind, wenn ich Stunden-, Tages-, Monats- und irgendwann auch Jahres-Werte in Plots darstellen möchte (neben dem gerade aktuellen Verbrauch als Zahl). 😳

Ein Punkt im regexp bedeutet genau ein beliebiges Zeichen. Mit folgendem Stern, also .*, bedeutet beliebig viele beliebige Zeichen.

ZitatLetzteres bedeutet, dass nur das Reading power berücksichtigt wird, nicht aber die anderen power im Namen enthaltenden Readings, die oben in Rot dargestellt sind. Das ist ja soweit ok, denke ich.

Ja. Zumal die anderen readings nicht power sondern Power enthalten.

ZitatErsteres bedeutet doch aber, dass auch Readings in Rot dabei wären, d.h. statTotal_consumption, statTotal_consumptionDay, statTotal_consumptionHour und statTotal_consumptionLast. Will ich das wirklich oder können die auch weg? Dann müsste ich die RegEx in der o.g. Zeile nochmal anpassen oder nicht?

Da hast Du recht. Aber nicht, dass die etwas im statistics-Modul triggern.  ???  Also erst einmal drin lassen. Optimierungsversuche kann man dann immer noch schrittweise machen.

Wichtig, und deshalb hatte ich es in 3 Beiträgen geschrieben:
1. Schritt: welche events soll mein device erzeugen ? (fürs logging, aber auch als trigger für z.B. statistics, notify, userReadings...) evtl. mehr als ich im Logfile haben möchte
2. Schritt: was möchte ich plotten(filelog) oder sonstwie historisch auswerten

Daher hatte ich bei meinem event-on-change-regexp auch die statTotal... eingeschlossen.
Und erst beim filelog-regexp habe ich die statTotal... gefiltert.

Klarer ?

So wie Du es jetzt machen möchtest, könnte der Code so aussehen(wenn ich nichts übersehen habe)
attr MyObis1 event-on-change-reading .*consumption.*,power.*
define FileLog_MyObis1 FileLog /opt/fhem/log/MyObis1-%Y-%m.log MyObis1:(power|.*Last|total_consumption).*

Zitat von: KölnSolar am 25 Januar 2024, 15:07:27Ja. Zumal die anderen readings nicht power sondern Power enthalten.

Oja, ist case sensitive - danke für die Erinnerung!

Zitat von: KölnSolar am 25 Januar 2024, 15:07:27Daher hatte ich bei meinem event-on-change-regexp auch die statTotal... eingeschlossen.
Und erst beim filelog-regexp habe ich die statTotal... gefiltert.

Der Groschen ist bei mir gefallen, denke ich. Wobei ich noch eine andere Fragen offen habe (s.u.).


Nach den entsprechenden Anpassungen (s.u.) sehe ich nun im Obis Logile keine neunen statTotal Werte mehr.
EDIT: Wie gewünscht, gibt es nun zur vollen Stunde:
2024-01-25_16:59:55 MyObis1 statTotal_consumptionLast: Hour: xxx0.9 Day: xxxx2.3 Month: - Year: - (since: 2024-01-24_09:21:25 )
2024-01-25_16:59:55 MyObis1 statTotal_consumptionHourLast: xxx0.9(EDIT-Ende)

Allerdings tauchen total_consumption und power dort immer noch minütlich auf. Das würde ich gerne auch noch reduzieren (auf alle 5 Minuten, damit die Plots eine einigermaßen gute Auflösung haben). Nur verstehe ich nicht, weshalb die dort überhaupt minütlich auftauchen. Ich habe doch attr MyObis1 event-min-interval .*:300 gesetzt. Demnach sollten doch alle(?) Readings nur alle 5 Minuten kommen und können dann nicht häufiger im Obis Logile auftreten, oder irre ich mich? Liegt's am Modul-spezifischen Polling und 60 Sekunden-Intervall? 🤔 Ich hatte angenommen, dass trotzdem die Readings gemäß event-min-interval .*:300 nur alle 5 Minuten kommen.

define MyObis1 OBIS /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0041-if00-port0@9600,8,N,1,SML
attr MyObis1 alias Haushalts-Strom
attr MyObis1 channels {\
"1.0.96.50.1.1"=>"Hersteller_ID",\
"1.0.96.1.0.255"=>"Geraetekennung"}
attr MyObis1 event-min-interval .*:300
attr MyObis1 event-on-change-reading .*consumption.*,power.*
attr MyObis1 icon stromzaehler_icon@red
attr MyObis1 interval 60
attr MyObis1 pollingMode on
attr MyObis1 room Strom
attr MyObis1 unitReadings off
attr MyObis1 verbose 3

define FileLog_MyObis1 FileLog /opt/fhem/log/MyObis1-%Y-%m.log MyObis1:(power|.*Last|total_consumption).*
attr FileLog_MyObis1 archivedir /opt/fhem/log/archive/
attr FileLog_MyObis1 createGluedFile 1
attr FileLog_MyObis1 nrarchive 2

ZitatDemnach sollten doch alle(?) Readings nur alle 5 Minuten kommen und können dann nicht häufiger im Obis Logile auftreten, oder irre ich mich?

Du irrst. event-on-change UND min-interval haben eine Oder-Verknüpfung. Es zieht also immer die Änderung des readings, die ja vermutlich minütlich stattfindet.
min-interval nimmt man hingegen dafür, dass, obwohl keine Änderung stattgefunden hat, das event erzeugt wird. Macht z.B. Plots lesbarer, wo selten Änderungen der readings stattfinden.

Wenn Du also sowieso nur einen 5-Minuten-Rythmus zum plotten haben willst und auch sonst keine weiteren Abhängigkeiten(notify....) hast, dann setz doch das interval am device auf 300. 

Stunde ist um. Passt es jetzt ?

Edit: Dein Edit beantwortet es.
Edit2: Anstatt meinem Vorschlag, könntest Du Dich auch noch an min-interval, aber einem zusätzlichen threshold bei event-on-change versuchen. Dann löst entweder threshold oder spätestens min-interval aus.
attr MyObis1 event-min-interval .*:300
attr MyObis1 event-on-change-reading .*consumption.*:10,power.*

Zitat von: KölnSolar am 25 Januar 2024, 17:07:55Du irrst. event-on-change UND min-interval haben eine Oder-Verknüpfung. Es zieht also immer die Änderung des readings, die ja vermutlich minütlich stattfindet.
min-interval nimmt man hingegen dafür, dass, obwohl keine Änderung stattgefunden hat, das event erzeugt wird. Macht z.B. Plots lesbarer, wo selten Änderungen der readings stattfinden.

Danke! :) Wer lesen kann, ist klar im Vorteil - ich hätte es halt nur lesen müssen:
https://wiki.fhem.de/wiki/Event-min-interval

Zitat von: KölnSolar am 25 Januar 2024, 17:07:55Wenn Du also sowieso nur einen 5-Minuten-Rythmus zum plotten haben willst und auch sonst keine weiteren Abhängigkeiten(notify....) hast, dann setz doch das interval am device auf 300. 

Zitat von: KölnSolar am 25 Januar 2024, 17:07:55Anstatt meinem Vorschlag, könntest Du Dich auch noch an min-interval, aber einem zusätzlichen threshold bei event-on-change versuchen. Dann löst entweder threshold oder spätestens min-interval aus.
Code Auswählen Erweitern

Code Auswählen Erweitern

attr MyObis1 event-min-interval .*:300
attr MyObis1 event-on-change-reading .*consumption.*:10,power.*

Das Device interval habe ich auf 300 gesetzt. Die Sache mit dem threshold (https://wiki.fhem.de/wiki/Event-on-change-reading) schaue ich mir morgen an, wenn ich einen neuen Blick auf's Logfile werfen kann. Bis dahin lasse ich es so:

define MyObis1 OBIS /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0041-if00-port0@9600,8,N,1,SML
attr MyObis1 alias Haushalts-Strom
attr MyObis1 channels {\
"1.0.96.50.1.1"=>"Hersteller_ID",\
"1.0.96.1.0.255"=>"Geraetekennung"}
attr MyObis1 event-min-interval .*:300
attr MyObis1 event-on-change-reading .*consumption.*,power.*
attr MyObis1 icon stromzaehler_icon@red
attr MyObis1 interval 300
attr MyObis1 pollingMode on
attr MyObis1 room Strom
attr MyObis1 unitReadings off
attr MyObis1 verbose 3
Nochmals meinen ganz herzlichen Dank für Deine Engelsgeduld - wünsche Dir und Euch allen einen entspannten Abend! 🌝

Zitat von: KölnSolar am 24 Januar 2024, 22:01:47

ZitatRPi2

würd ich schleunigst ersetzen. Zum Einstieg noch ok, aber Deine Plots werden erschreckend langsam werden.

Was kommt denn außer z.B. RPi 3/4 noch in Betracht? Es muss ja nur ein Desktop-loses OS drauf laufen können mit mehr CPU-Leistung für FHEM, ggf. auch mehr Speicher. Sorry, es wird etwas OT, merke ich. 😉

PS: Die Daten kommen jetzt wie gewünscht nur noch alle 5 Minuten bzw. zur vollen Stunde, und die Plots sehen trotzdem immer noch prima aus. Einen Threshold benötige ich wohl nicht. 😊 Würde eine Aufteilung auf 2 separate Logfiles irgendwelche Vorteile bringen?

Ne frage vom Geldbeutel. Ich nutz nen bj2011 Mac mini mit ubuntu drauf.(Core i5 mit 16gb ram und ssd)

Viele hier setzten micro pcs wie eine NUC ein.

Zum log, ja kann man machen, muß aber nicht. Viel wichtiger ist die Logs zeitlich zu trennen(-%Y-%m-%d). Und sie mit creategluedfiles wieder zusammenkleben, für die svg Plots.

Werden die logfiles zu groß wird das parsen langsam. Hilft auch das nicht, sollte man auf ne Datenbank setzen.

NUCs haben wir, aber schon anderweitig im Beschlag. 😉 Außerdem könnte ich eine VM auf meiner Synology nutzen. Dazu müsste ich das RS232-USB-Adapterkabel deutlich verlängern für den Weg vom Zählerstand zum Netzwerkschrank und zur Heizung. Aber es wäre möglich.

Logfiles erstelle ich alle monatlich und glue diese. Bisher werden alle Plots flott genug erstellt, wobei ich den einen oder anderen noch via MQTT nach Home Assistant sende und (auch) dort plotte.

Außerdem habe ich regelmäßig automatische Backups von FHEM für den Fall, dass die SD-Karte kaputt geht (ist übrigens eine Transcend High Endurance 128 GB, TS128GUSD350V).

Ein RPi3 verrichtet hier problemlos seine Dienste. Der macht nur FHEM und ein bißchen pi-hole(lokaler DNS).
Was da alles so dranhängt siehst Du ja in meiner Signatur.  ;)

Pi-Hole mit unbound laufen bei mir in einer Synology VM (Debian bullseye). Da wäre für FHEM noch locker Platz. 🤔 Es wäre deutlich performanter, und mittels Snapshots der VM wären Backup & Restore auch simpel. Mal sehen ...

Jedenfalls habe ich hier wieder viel gelernt dank der tollen Unterstützung. Herzlichen Dank nochmals dafür! ❤️

Der Dank geht zurück, deine Fragestellung war vorbildlich :D

Sauber formatiert ordentlich formuliert, davon könnte sich der ein oder andere Fragesteller ein Scheibchen abschnibbeln.

Und ich denk auch es macht den Mitlesern mehr Spaß solche Threads zu verfolgen als das müßige aus der Nase ziehen und pingpong antworten.


 :) ein Q

Danke für die Blumen! 💐

Übrigens las ich eben diesen Beitrag und frage mich, ob auch diesem User geholfen werden kann. 😉

Zitat von: Jackie am 30 Januar 2024, 11:40:26danke, genau der Gedanke kam mir auch, ich finde das ist insgesamt eine riesengroßer Nachteil von fhem insgesamt als Lösung dass es keine Trennung gibt zwischen Reading- und Logintervallen. Wo könnte man sowas denn als Feature Request am besten anbringen? Ich habe den Anwendungsfall auch bei anderen Geräten, nicht immer brauche ich wirklich viele Logeinträge, aber für die Livedarstelungen am besten sofort. Das macht die ganze Sache leider ziemlich unflexibel :-(

PS:
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. 😊

sorry wenn ich des jetzt mal so hard reinhauen muß

aber
attr .* DbLogExclude .*
sorgt schlagartig für ruhe (absolute ruhe) auf allen devices wenn man logdb nutzt  ::)  :-X

danach gibt man explizit das "frei" was man auch wirklich haben will.