on-update oder on-change

dsoxygen · 31 August 2019, 08:41:38

Hallo Gemeinde.

Ich habe das Problem dass wenn ich on-update verwende werden zuviel "unnütze" Logdaten gesammelt was den Speicher unnötig füllt und FHEM langsam macht.
Wenn ich dagegen on-change verwende sehe die Plots nicht mehr gut aus.

Beispiel Gaszähler im Sommer mit EM1000-GZ:
Bei on-update bekomme ich im 5min takt einen Logeintrag mit 0m³. Bis auf ca 16 einträge mal wo die Heizung Warmwasser warmhält.
Bei on-change bekomme ich nur die 16 Einträge plus die 0 Meldung nach der Warmhaltperiode.
Ersteres Flutet das Log und zweiteres schieht im Plot nicht gut bzw. falsch aus.

Meine angedachte Lösung wäre dass ich weiter mit on-update arbeite aber das Logfile beim Schreibern eines Eintrages der vorherigen Eintrag prüft ob dieser gleich dem Eintrag davor und gleich dem neuen Eintrag ist. Wann ja wird dieser mit dem neuen Eintag überschrieben. Ansonsten wird der neuen einfach angefügt.

Beispiel:

Standart Log mit on-update:	Standart Log bei on-change:	Modifizierter Log bei on-change:
timestamp name 0	timestamp name 0	timestamp name 0
timestamp name 0
timestamp name 0
timestamp name 0		timestamp name 0
timestamp name 5	timestamp name 5	timestamp name 5
timestamp name 4	timestamp name 4	timestamp name 4
timestamp name 5	timestamp name 5	timestamp name 5
timestamp name 0	timestamp name 0	timestamp name 0
Ich hoffe man kann nachvollziehen was ich bezwecken will. Ist das irgendwie möglich?

KölnSolar · 31 August 2019, 09:27:10

neben on-change event-on-min-interval ?

frank · 31 August 2019, 10:07:23

ich nutze logproxy für die plots.
da sehen die plots auch mit event-on-change schön aus.

dsoxygen · 31 August 2019, 13:19:04

Zitat von: KölnSolar am 31 August 2019, 09:27:10
neben on-change event-on-min-interval ?

Wenn ich das richtig verstehe würde ich damit nur nach Zeit ein willkürliches reading erzeugen. Das Log wird dadurch sicher weniger aber je nach Zeitintervall sieht das Plot immer noch nicht gut aus weil das reading VOR der Wertänderung mit großer Wahrscheinlichkeit immer noch fehlt.

Zitat von: frank am 31 August 2019, 10:07:23
ich nutze logproxy für die plots.
da sehen die plots auch mit event-on-change schön aus.

Schaut ziemlich mächtig aus.
Ich lese das mal durch, kann mir aber nicht vorstellen woher logproxy den Wert und die Zeit vor der Wertänderung herbekommt.

frank · 31 August 2019, 13:36:40

über die option extend schaut fhem entsprechend weit in die vergangenheit. und option predict "verlängert" den letzten wert bis zum aktuellen zeitpunkt.

dsoxygen · 31 August 2019, 13:54:37

Zitat von: frank am 31 August 2019, 13:36:40
über die option extend schaut fhem entsprechend weit in die vergangenheit. und option predict "verlängert" den letzten wert bis zum aktuellen zeitpunkt.

Die beiden verlängern den Plot am Anfang und am Ende?
Mit geht es aber um die Daten zwischen den Spitzen.

Ich habe mal ein Bild angehängt. Das verdeutlicht vielleicht das Problem.

frank · 31 August 2019, 14:21:14

du nutzt eigentlich den "falschen" linientyp.
ich nutze grundsätzlich den linientyp steps, da dieser die zeitdiskreten werte am wenigsten "verfälscht".

um der "realität" noch näher zu sein, müsste man eigentlich den linientyp points nutzen, dann aber auch mit allen eingehenden daten, also on-update. denn nur so sieht man auch, wenn keine daten reinkommen. diese art nutze ich zum beispiel immer bei der darstellung von rssi werten.

dsoxygen · 31 August 2019, 14:25:50

An steps habe ich auch schon gedacht. Gefällt mir aber nicht wegen der "rechteckigen" Darstellung. Das sieht mir wiederum zu unnatürlich aus.

fiedel · 01 September 2019, 10:44:18

Vermutlich musst du on-update, on-change und min-interval sinnvoll kombinieren:
Mit on-update legst du fest, welche Readings überhaupt upgedatet werden sollen
(was da nicht drinsteht, erzeugt kein Event mehr!!!).
Mit min- interval gibst du ein Zeitfenster vor, in welchem kein erneut eingehender
Wert akzeptiert wird (kein Reading erzeugt).
Mit on-change untergräbst du das min- interval indem du festlegst ab welcher
Schwelle (Abweichung der neuen Daten vom letzten akzeptierten Wert) der neue
Wert akzeptiert wird, obwohl min-interval das noch nicht zulassen würde.

dsoxygen · 01 September 2019, 19:58:43

Events die geloggt werden sind bei mir immer auf die Events begrenzt die ich wirklich brauch. ".*" nutze ich nur wenn kein Log dahinter steht.
min-interval würde schon mal gleiche werte die hintereinander auftreten etwas filter. Aber leider nur etwas und nicht ganz (was für den Speicher eine enorme Entlastung wäre und in Plot's nicht auffallen würde egal welche Linientyp).
on-change liefert dann wieder den ansteigenden Wert aber der alles entscheidende Logeintrag VOR der Wertänderung fehlt immer noch. Und genau dieser versaut das Liniendiagramm.

Ich bin leider in perl nicht so fit. Sonst würde ich das mit dem Filter, wie im anfangs Post beschrieben, beim schrieben eines Logeintages versuchen umzusetzen.
Dieser Filter würde das Log sauber komprimieren/säubern ohne das sinnvolle Daten verloren gehen.

Carsten1981 · 05 September 2019, 16:51:50

Hallo.
Ich habe das folgendermaßen gelöst.
Sensor Gaszähler misst jede Minute erzeugt über event on change aber nur nei änderung ein Intervall
Dieses Event triggert ein DoIf
Ich habe einen Dummy Gaszähler und dieser wird gelogt

DoIf:
1. Der Wert des Dummys Gaszählers wird erneut in den Dummy geschtieben in deinem Beispiel set Dummy Gas 0
2. Der neue Wert (aktueller Verbrauch) wird in den Dummy geschrieben
3. Der Dummy wird wieder auf den Wert 0 gesetzt.

Dies erzeugt nur readings wenn sich wirklich was ändert und zusätzlich sieht die Grafik so aus wie du es haben willst.

Zumindest wenn ichbdich richtig verstanden habe.

Gruß Carsten