Weihnachtsangebot 2025! 🎄

[Homoran]

Ich versuche meine geloggte Datenflut etwas einzudämmen.
Dazu habe ich in den letzten Tagen mit Blockzeit und minimale Änderung gespielt um nicht jede Sekunde einen Wert zu bekommen, was für den Chart nicht notwendig wäre.
Allerdings erhalte ich jetzt Artefakte in der Kurve.
Außerdem habe ich die Vermutunt, dass die Blockzeit nicht greift, wenn der minimale Unterschied überschritten wird.
Auch den Algorithmus vom minimalen Unterschied kann ich nicht erkennen, zumindest nicht den, den ich erwarten würde.
Beim letzten Wert von z.B. 18 und einer Einstellung von minimaler Differenz von 3 würde ich erwarten, dass der nächste Wert entweder über 21 oder unter 15 liegen muss. anscheinend wird aber immer der letzte Messwert, auch wenn er nicht geloggt wird, als Basis genommen, so dass im schlimmsten Fall bei gleichmäßig steigender Temperatur 18 - 20 - 22 - 24 - 26.... gar nicht geloggt würde, oder bei sehr unruhigem Sensor 18 - 20 - 17 - 19 - 21 - 18... viel zu oft.

Ein weiteres Problem zeigt sich hier

Je nachdem wie ich die beiden Parameter einstelle, wird bei zu großer Differenz oder Blocktime die für den korrekten Chart notwendige 0 nicht geloggt, was zu den gezeigten Artefakten führt.
Gehe ich nur über Blockzeit kann es mir ebenfalls oassieren, dass selbst hohe Verbräuche von kurzer Dauer (z.B. Durchlauferhitzer) nicht oder unvollständig angezeigt werden.

---

Was muss ich einstellen um wenige Daten, aber auf jeden Fall hohe Unterschiede und jede 0 geloggt bekomme?

[AndyGR42]

@homoran Hm, wie oft kommen denn die Daten? Ich würde aus Erfahrung nicht mehrere Mechanismen kombinieren. Also entweder Blockzeit ODER minimale Änderung.

ABER, wenn die Werte zu sehr springen, könnte man sie normalisieren, also glätten. In einem Diagramm über 24h brauchst Du ja nicht einen Wert pro Sekunde, sondern vielleicht einen Pro Minute. Der würde dann auch nicht so springen. Wenn der Sensor also mit 1Hz die Daten schickt, 60 Werte in ein Array schreiben, den Durchschnitt errechnen und den dann als DP abspeichern.

[Homoran]

@andygr42 sagte in Wie die Parameter für History sinnvoll nutzen?:

Wenn der Sensor also mit 1Hz die Daten schickt, 60 Werte in ein Array schreiben, den Durchschnitt errechnen und den dann als DP abspeichern.

das wollte ich nicht für 200 Datenpunkte machen :-)

na gut, in real würde es etwa 50 DPs betreffen, aber selbst das wäre mir zu viel Skripterei.

@andygr42 sagte in Wie die Parameter für History sinnvoll nutzen?:

wie oft kommen denn die Daten?

etwa 30 Daten vom Strom alle 6 Sekunden, jetzt ganz neu mit modbus leider alle Sekunde. mit gerechneten Werten erst nochmal etwa 20, ständig ansteigend bis ich weiß was ich wirklich brauche. Oder noch mehr finde :-)

@andygr42 sagte in Wie die Parameter für History sinnvoll nutzen?:

nicht mehrere Mechanismen kombinieren. Also entweder Blockzeit ODER minimale Änderung.

das habe ich auch so bemerkt, aber selbst dann klappt es ja leider nicht wirklich.
selbst mit Schieberegister wird die fakultative 0 nicht erreicht!
da muss ich bei einer 0 eine separate Logik wirken lassen.

[AndyGR42]

@homoran Ich denke, eine Schieberegister ist hier auch nicht unbedingt nötig. Dafür kommen die Daten schnell genug. Ein Schieberegister nutze ich z.B. bei der Normalisierung der durchschnittlichen Windgeschwindigkeit. Wenn ich da erst 60 Minuten sammeln würde wäre die Anzeige ja quasi statisch. So wird sie alle 30 Sekunden mit einem normalisierten Durchschnitt aus dem Schieberegister aktualisiert.

Der Wert "elektrischer Strom" ist ja eine Momentaufnahme. Die nötige Häufigkeit für eine sinnvolle Abtastung wird durch die Frequenz der Änderung bestimmt. Gehen wir mal davon aus, dass selbst Peaks mindestens mehrere Sekunden, eher Minuten lang sind, reichen die 6 Sekunden vermutlich dicke aus. Bei einer Auflösung von einer Sekunden könntest Du (theoretisch) Änderungen von bis zu 0,5Hz aufzeichnen. Wenn Du es so genau haben willst, dann musst Du die aber auch speichern oder zumindest verarbeiten.

Für Temperaturen reicht in aller Regel eine deutlich geringere Abtastrate, das System ist halt viel träger.

Warum der minimale Unterschied nicht korrekt funktioniert, könnte an der hohen Frequenz liegen. Der Adapter hat ja bei 200 DP mit der Frequenz gut zu tun.

Ich wüsste jetzt nicht, wie man aus der Nummer ohne Berechnung des Durchschnitts rauskommt. Du brauchst die hohe Frequenz bei der Abtastung, um keine Peaks beim Strom zu verlieren, du möchtest aber eine geglättete Ausgabe. Einfach Werte zu verwerfen verfälscht auch das Ergebnis. Ideal wäre as natürlich, wenn man die Abtastfrequenz für einzelne Werte einstellen könnte. Z.B. 1 Minjte für Temperatur und 1-3 Sekunden für den Strom.

[Homoran]

@andygr42 sagte in Wie die Parameter für History sinnvoll nutzen?:

Du brauchst die hohe Frequenz bei der Abtastung, um keine Peaks beim Strom zu verlieren, du möchtest aber eine geglättete Ausgabe. Einfach Werte zu verwerfen verfälscht auch das Ergebnis. Ideal wäre as natürlich, wenn man die Abtastfrequenz für einzelne Werte einstellen könnte. Z.B. 1 Minjte für Temperatur und 1-3 Sekunden für den Strom.

letzteres sollte ja jetzt über die Blockzeit gehen.

ersteres hatte ich gedacht über entsprechend hohe Werte bei minimaler Änderung zu erreichen.
Wenn ich allerdings 100W nähme, der Verbrauch von 1500 auf 98 fällt ist es ok, dann auf 0 wird diese 0, die Flot für die Basislinie braucht, nicht geloggt, sondern erst wieder bei 212W ggf. Stunden später. Und jetzt wird die Kurve von 98 bis 212 gezogen, obwohl sie die ganze Zeit bei 0 war.

[AndyGR42]

@homoran Ok, so wird die praktisch nie 0. Über die Durchschnittsberechnung schon :)

Alternativ den Wert per Skript beim Unterschreiten von 100 auf 100 Setzen. Dann sollte die nächste 0 auch wirken. Allerdings ist das auch ein Script, da kannst Du auch gleich den Durchschnitt errechnen.

[Homoran]

@andygr42 sagte in Wie die Parameter für History sinnvoll nutzen?:

Über die Durchschnittsberechnung schon

nein. Nur wenn länger 0 ist.

bei einem Wert aus 60 Zahlen müssen 60x0 vorliegen.
dei 118x0 und 2x2 wären nach Murphy beide Mittelwerte >0

[AndyGR42]

@homoran 60x0 habe ich jetzt mal vorausgesetzt. Ansonsten wäre der Wert ja auch nicht wirklich 0 und die Aufzeichnung damit falsch. Runden geht auch immer. Bei deinem Beispiel wäre der Wert 0,033 und kann damit problemlos auf ganze Zahlen gerundet werden, was dann 0 wäre.

P.S.: oder von mir aus auch auf die erste 10er Stelle, dann wird es noch ruhiger.

[Homoran]

@andygr42 aber jetzt hat sich @apollon77 so viel Mühe mit den neuen Parametern gegeben, die müssen doch sinnvoll nutzbar sein.

es gibt ein ignore 0, da muss es doch auch ein ignore rules at 0 o.ä. geben.
ich hab ja extra die optimierte Aufzeichnung für Graphen nicht deaktiviert.

[klassisch]

Zum neuen history kann ich nichts sagen, weil ich wegen des breaking change noch beim alten bin.
Für den smartmeter hat @paul53 mal ein Skript geschrieben; für Dich in blockly
https://forum.iobroker.net/post/479385

[apollon77]

@Homoran erst einmal schau ob die „darstellungsoptimierung“ an ist. Wenn ja kann es manchmal. Unlogisch erscheinen. Was geloggt wird weil unerwartete zusatzwerte mit geloggt werden. Sonst schalte bei einem Datenpunkt mal ds erweitere logging ein und setze debug log. Dann steht im log ganz genau warum er was loggt oder verwirft.

[paul53]

@homoran sagte: ärgerlich wenn 4 Jahre Daten dann inkompatibel werden.

History hat einen Alias. Die neuen Daten werden nur seltener historisiert.

[Andreios]

@andygr42 sagte in Wie die Parameter für History sinnvoll nutzen?:

@homoran Hm, wie oft kommen denn die Daten? Ich würde aus Erfahrung nicht mehrere Mechanismen kombinieren. Also entweder Blockzeit ODER minimale Änderung.

ABER, wenn die Werte zu sehr springen, könnte man sie normalisieren, also glätten. In einem Diagramm über 24h brauchst Du ja nicht einen Wert pro Sekunde, sondern vielleicht einen Pro Minute. Der würde dann auch nicht so springen. Wenn der Sensor also mit 1Hz die Daten schickt, 60 Werte in ein Array schreiben, den Durchschnitt errechnen und den dann als DP abspeichern.

Nur mal so:
Man braucht nicht unbedingt ein Array, um den Durchschnittswert zu bilden, sondern nur 2 DP, wenn man davon ausgehen kann, dass die Werte nicht stark springen.
Das Array macht mehr Sinn, wenn man stark springende Werte hat und immer den ältesten Wert hinten rausfallen lässt (gleitender Mittelwert), dann ist der Verlauf etwas genauer.

Ansonsten reicht ein DP (DPDW) für den Durchschnittswert und einer als Zähler (DPZ).

Ist DPZ <= 0 wird DPDW = Wert gesetzt und DPZ = 1.

Ist DPZ > 0 wird
DPDW = (DPDW * DPZ + Wert) / (++DPZ) ;

Will man einen gleitenden Mittelwert über die letzte 50 Werte, dann muss, sobald DPZ = 50 ist,
DPDW = (DPDW * (DPZ - 1) + Wert) / DPZ;
daraus werden.

[AndyGR42]

@Andreas-5 der Thread ist ausgelagert, was die Posts aus dem Zusammenhang reißt.

https://forum.iobroker.net/topic/62812/werteabhängiges-loggen-per-skript

Bei Hormoran ändern sich die Werte aber sehr schnell und stark.

[Andreios]

@andygr42 sagte in Wie die Parameter für History sinnvoll nutzen?:

@Andreas-5 der Thread ist ausgelagert, was die Posts aus dem Zusammenhang reißt.

https://forum.iobroker.net/topic/62812/werteabhängiges-loggen-per-skript

Bei Hormoran ändern sich die Werte aber sehr schnell und stark.

Ok, da habe ich mich unscharf ausgedrückt!
Ich bin davon ausgegangen, dass es im aktuellen Fall ja darum geht, tatsächlich den Durchschnittswert zu bilden, da reichen die 2 DP, ggfs. auch als gleitenden Mittelwert.

Beispiel:
Wenn alle 30 Sekunden ein Wert aufgezeichnet werden soll, die Werte jede Sekunde kommen, dann kann man auch 30 Werte als gleitenden Mittelwert bilden. So kann man in einer Anzeige den Mittelwert der letzten 30 Sekunden anzeigen und alle 30 Sekunden den Wert in die DB schreiben.
Wenn das immer noch zu zappelig ist, kann man auch über einen längeren Zeitraum den Mittelwert bilden und trotzdem alle 30 Sekunden aufzeichnen. Das glättet dann halt mehr.

[Homoran]

@andreas-5 sagte in Wie die Parameter für History sinnvoll nutzen?:

Das glättet dann halt mehr.

das war nicht der Knackpunkt!
entscheidend war, dass ich unbedingt eine 0 benötige, damit es nicht zu Artefakten im Chart kam.
Außerdem sollten Leistungsspitzen über xxxxW nicht geglättet werden.

Aber da das anscheinend auch mit den neuen Filtern von History nicht annähernd klappt, muss das mit 1-100 Scripten umgesetzt werden.
Daher wurde der darauf bezogene 7nhalt in die Rubrik Blockly verschoben

[Homoran]

@apollon77 sagte in Wie die Parameter für History sinnvoll nutzen?:

erst einmal schau ob die „darstellungsoptimierung“ an ist. Wenn ja kann es manchmal. Unlogisch erscheinen.

mal eben auf die Schnelle

Es ist nur mindestens 50! als Änderung eingetragen.

[apollon77]

@homoran na dann schalte doch mal die darstellungsoptimierung aus.

[Homoran]

@apollon77 sagte in Wie die Parameter für History sinnvoll nutzen?:

@homoran na dann schalte doch mal die darstellungsoptimierung aus.

getan.....und vergessen :-(

jetzt nachgesehen und gestaunt

Hab ehrlich nicht geglaubt, dass dieser Punkt in der hohen Abtastrate zu solchen Effekten führt.

Gut zu wissen!
Danke

[apollon77]

@homoran sich den thread zur History major increase da ist das alles haarklein beschrieben was das tut und warum es solche Effekte hat.