Wie die Parameter für History sinnvoll nutzen?
-
@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.
-
@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. -
@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.
-
@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 -
@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.
-
@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. -
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 -
@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.
-
@homoran sagte: ärgerlich wenn 4 Jahre Daten dann inkompatibel werden.
History hat einen Alias. Die neuen Daten werden nur seltener historisiert.
-
@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. -
@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.
-
@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. -
@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 -
@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.
-
@homoran na dann schalte doch mal die darstellungsoptimierung aus.
-
@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 -
@homoran sich den thread zur History major increase da ist das alles haarklein beschrieben was das tut und warum es solche Effekte hat.
-
@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
-
@homoran debug logging verrät genau warum er was loggt und tut.
