Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

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

[Homoran]

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

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

ja das hatte ich gelesen. Aber irgendwie hatte ich diese Möglichkeiten nicht für das loggen in so hoher Frequenz erwartet, sondern nur wenn die Daten spärlich fließen

[apollon77]

@homoran debug logging verrät genau warum er was loggt und tut.