History 2.0.0 verfügbar - eine Zusammenfassung

[apollon77]

Hallo alle zusammen,

Nach einer Alpha-Phase (Danke an alle Alphatester!) kommt im laufe des heutigen nachmittags ein Major-Update des History(und SQL und InfluxDB)-Adapters ins Beta/Latest Repo. Viel Spass!

Diese neue (Major!) Version des History Adapters räumt einige Dinge auf und sorgt bei einigen Themen für mehr transparent und Klarheit und bringt noch dazu einige Features mit. Der Adapter wird sich an einigen Stellen was die aufgezeichneten Daten angeht künftig anders verhalten als bisher!
Ebenso haben sich Einstellungen geändert - es sollten die Einstellungen der alten Version übernommen werden und sollten auch bei einem Downgrade noch vorhanden sein wie vorher eingestellt, dennoch ist diese Version ein Breaking change. Also stellt bitte sicher Backups der Datenfiles und des Systems zu haben!

Bei Fehlern bitte ggf hier schreiben und dann GitHub Issues anlegen.

Auf die wichtigsten Änderungen will ich gern jetzt noch genauer eingehen.

Wichtige Änderungen erklärt

Konfiguration ausschliesslich in der neuen Admin UI verfügbar!

Die Konfiguration ist ausschliesslich in der neuen Admin5 UI verfügbar

Debounce vs "Aufzeichnung zeitlich blockieren"

In der Konfiguration kann man eine sog. "Debounce-Zeit" angeben. Debounce bedeutet an sich, dass ein neuer Wert erst dann als "stabil" gilt wenn er sich für die angegebene Zeit nicht geändert hat. So war es auch (von komischen Effekten mit "Nur Änderungen aufzeichnen mal abgesehen", dazu später mehr) implementiert. Leider hat die Readme davon gesprochen das der Wert sofort geloggt wird aber dann für die angegebene Zeit kein weiterer Wert. Hier herrschte also Verwirrung.

Mit dieser Version gibt es jetzt zwei Werte die man setzen kann:

• Debounce-Zeit: Der Wert wird wirklich erst aufgezeichnet, wenn er sich für die hier angegebene Zeit nicht geändert hat! Wird hier also ein Wert eingetragen der höher ist als die übliche Änderungsfrequenz des States, dann wird faktisch NIE etwas geloggt! Also Achtung hier!
• Block-Zeit: Dieser Wert entspricht dem was die Doku bisher zum "Debounce" gesagt hat und erlaubt es, erst frühestens nach Ablauf dieser Zeit neue Werte zu loggen. Wichtig hier ist das die obige "Debounce-Zeit" vorher geprüft wird, und auch das ein "Gleiche Werte nochmals loggen" diesen Check nicht macht.

Aus Kompatibilitätsgründen wird der frühere "debounce"-Wert als "Block-Wert" übernommen. Also bitte die Einstellungen prüfen falls dies keinen Sinn macht!

"Nur Änderungen aufzeichnen" vs "Debounce"

In dieser Kombination hatten sich einige Bugs und Effekte eingeschlichen, welche dafür gesorgt haben das teilweise Werte geloggt wurden die nicht den Regeln entsprachen. Dies ist jetzt aufgeräumt.

"Nur Änderungen aufzeichnen" und Aufzeichnung zusätzlicher Werte zur besseren Grafischen Darstellung

Ein weiterer großer Verwirrungspunkt war öfters, warum denn noch zusätzliche Werte aufgezeichnet werden, die an sich durch die Regeln (vor allem "Minimale Differenz") gar nicht hätten aufgezeichnet werden dürfen. Dies kam daher, dass der Adapter versucht die Werte so aufzuzeichnen das eine Grafische Darstellung sinnvoll möglich ist, weil in vielen Fällen die Werte nur zur grafischen Darstellung genutzt werden. Vor allem dabei ist es aber ein potentiell größerer Unterschied ob ein Wert der sich mit 1h Abstand geändert hat sich zu einem Zeitpunkt schlagartig geändert hat oder über die gesamte Zeit langsam geändert hat. Die automatisch gewählten zusätzlichen Werte stellen hier eine bessere Darstellung sicher.

Die neue Version nutzt diese darstellungsoptimierte Aufzeichnung immer noch standardmäßig, kann allerdings pro Datenpunkt deaktiviert werden! Dann werden nur wirklich die Werte aufgezeichnet die laut den angegebenen Regeln definiert waren.

Neue Features

Zusätzlich zu den oben genannten Änderungen gibt es einige neue Features in der neuen Version:

• Mittels zwei neuer Einstellungen pro Datenpunkt ("Nicht loggen wenn kleiner als" und "Nicht loggen wenn größer als") können noch besser Fehlerwerte ausgeklammert werden. Die Einstellung "Nicht loggen wenn kleiner als" ersetzt das vor kurzem hinzugefügte "Keine Werte kleiner als 0 loggen", die Einstellung wird aber automatisch konvertiert.
• Eine Einstellung pro Datenpunkt ist dazugekommen, mit der man angeben kann auf wie viele Stellen nach dem Komma die Werte beim lesen (GetHistory) gerundet werden.
• Neue Aggregationsmethoden "percentile" und "quartile" wurden hinzugefügt, um das n-te Percentile bzw. das 0.x Quartile zu ermitteln. Ohne weitere Infos wird das 50er Percentile bzw. das 0.5er Quartile (Mean) zurückgegeben, was ein besserer Average ist.
• Neue Aggregationsmethode "integral" wurde hinzugefügt, um das Integral (Fläche unter den Werten) zu errechnen. Im Standard ist die Integral-Unit 1s und eine schrittweise Interpolation wird genutzt (also quasi keine, weil die werte für die ganze Zeit konstant berechnet werden). Alternativ kann eine lineare Interpolation genutzt werden. Mit einem Integral und zB Unit von 3600s kann man aus einem Stromverbrauch in Watt die Wh ermitteln,
• Standardmäßig ermitteln die Aggregationsmethoden immer auch zwei Randwerte und geben diese im Ergebnis zurück um die grafische Darstellung zu optimieren. Mittels der neuen Option "removeBorderValues" bei einem GetHistory Aufruf können die zurückgegebenen Werte so limitiert werden wie Sie per step bzw. count angefordert wurden und diese Randwerte entfernt werden. Dies ist vor allem Hilfreich wenn ein Skript die Daten verarbeiten soll. Mit dem (kommenden!) Admin 5.3.8 ist auch die Darstellung der Werte bei den Datenpunkt-Einstellungen wieder korrekt, wenn man Zeitbereiche von mehr als 24 gewählt hat und mehr als 500 Werte in dem Zeitraum geloggt wurden.
• Da das schreiben von Debug Logs vor allem bei schwächeren Systemen ziemlich auf die performance drückt und auch ein Debug Log immer sehr unübersichtlich wurde, weil alles oder nichts geloggt wurde, kann nun zusätzliches Debug pro Datenpunkt aktiviert werden! Dies wird aber nur dann ausgegeben wenn der Loglevel der Instanz auch auch Debug steht.
• Bei storeState kann nun mittels dem Parameter "rule=true" festlegen das die Daten nicht direkt geloggt werden sondern alle Rules angewendet werden wie für jeden normalen Wert - inkl. Debounce u.ä. Bitte vorsichtig nutzen das nicht unabsichtlich Werte nicht geschrieben werden!
• Die Aufbewahrungszeit kann nun neben vorgegebenen Optionen auch als eigene Dauer in Tagen angegeben werden

Die neuen Aggregationsmethoden sind (natürlich) noch nicht in flot oder echarts verfügbar und können daher nur in Skripten genutzt werden. Hierzu müssten, wenn alles geht dann noch Issues an den relevanten Stellen angelegt werden.

Die neuen Optionen für getHistory sind in https://github.com/ioBroker/ioBroker.history/blob/master/docs/en/README.md#access-values-from-javascript-adapter auch alle erklärt

Weitere Änderungen

Weiterhin gibt es folgende relevante Änderungen im Verhalten

• GetHistory-Anfragen müssen nun bei start/end Angaben in ms erfolgen! Zeitangaben in Sekunden werden nicht mehr umgerechnet! Bitte sicherstellen das alle UIs und Charting-Adapter aktuell sind!
• Die Objekt-ID wird nun immer wenn angefordert mit in den Ergebnissen von GetHistory zurückgegeben
• Spezielle Behandlung von früher aufgezeichneten Daten mit Timestamps in Sekunden bzw. Logiken die verhindert haben Werte vor 1.1.2010 zu verarbeiten wurden entfernt.

Neue Aufzeichnungslogik erklärt

Am Ende gilt jetzt folgende Reihenfolge der Checks:

• Ein Wert ist erst nach Debounce-zeit stabil. Unstabile werte werden nicht aufgezeichnet
• Wenn die Blockzeit seit dem zuletzt regulär aufgezeichneten Wert nicht erreicht ist, wird der Wert nicht aufgezeichnet
• Wenn "Null-Werte" ignoriert werden und der Wert 0 ist, dann wird der Wert nicht aufgezeichnet
• Wenn Grenzen der Werte definiert sind (Nicht loggen wenn kleiner/größer als) und der Wert ist ausserhalb der Grenzen, wird der Wert nicht aufgezeichnet
• Wenn "Nur Änderungen aufzeichnen" definiert ist:
  • Wenn der Wert seit letzter Aufzeichnung unverändert war und "gleichen Wert aufzeichnen" deaktiviert ist, wird der Wert nicht aufgezeichnet. Der Wert wird ggf. erinnert für spätere Aufzeichnung zur Darstellungsoptimierung.
  • Wenn der Wert seit letzter Aufzeichnung unverändert war und "gleichen Wert aufzeichnen" aktiviert ist und das angegebene "Nochmals Aufzeichnen Interval" noch nicht erreicht ist, wird der Wert nicht aufgezeichnet. Der Wert wird ggf. erinnert für spätere Aufzeichnung zur Darstellungsoptimierung.
• Wenn der Wert eine Zahl ist und eine "Minimale Differenz" definiert ist, diese aber nicht erreicht ist, wird der Wert nicht aufgezeichnet. Der Wert wird ggf. erinnert für spätere Aufzeichnung zur Darstellungsoptimierung.

Der zuletzt erinnerte Wert wird geschrieben sobald auch der nächste reguläre Wert geschrieben wird, allerdings mit seinem alten Zeitstempel - und nur wenn die Darstellungsoptimierung nicht deaktiviert wurde..

Ingo

[Marty56]

@apollon77

Ich habe einen sehr hohen Schwellwert eingetragen, weil ich das automatische Loggen beim Schreiben des Datenpunkts verhindern möchte.

Einmal am Tag, schreibe ich direkt in die history DB an einem von mir definierten Zeitpunkt (mit send("history.0 .....) und setze danach den Datenpunkt auf 0.
Ich möchte also, dass durch eine Änderung des Datenpunkt überhaupt keine Einträge in die History DB gespeichert werden.

Leider scheint der Adapter die Veränderungsschwelle zu ignorieren.

Es sieht so aus, als ob er den ersten Wert am Tag, also in dem Bild den Übergang von 0 auf 4,54999 immer schreibt, obwohl der Unterschied zwischen 0 und 4,5999 deutlich geringer ist als 1 000 000.

Ist das Fehler oder ein Feature?

[apollon77]

@marty56

1.) Bevor ich Dir antworte liesst Du bitte jetzt mal den ersten Post oben vollständig durch und sagst mir ob Die Frage danach nicht einfach selbst beantwortet ist.
Ansonsten schalte doch mal Debug log für den einen Datenpunkt an und stelle die Instanz auf Debug Log und dann liess Dir durch was er loggt. Das sollte dann auch genau erklären was er warum tut.

2.) Meinst Du nicht das es mit diesen Anforderungen viel sinnvoller ist einfach einen eigenen State anzulegen in den Du selbst das reinschreibst was Du wann willst per JavaScript/Blockly ohne das du das so verbiegen musst?

[Marty56]

@apollon77
Danke für die Rückmeldung
zu 1. Ich habe mir jetzt die Schreiblogik durchgelesen. So richtig verstanden habe ich die leider nicht. Vor allen Dingen ist mir der Begriff "Darstellungsoptimierung" nicht klar und auch der Satz "Der Wert wird ggf. erinnert für spätere Aufzeichnung zur Darstellungsoptimierung". Was soll "erinnert" in diesem Kontext bedeuten.

Aber ok. Ich habe jetzt mal (ohne wirkliches Verständnis) diese Darstellungsoptimierung deaktiviert und schaue mal was dann passiert.

Zu 2. Ich möchte ein monatliches und ein Mehr -Jahresdiagramm machen. Mit Deinem Vorschlag habe ich die endgültigen Werte am Ende der jeweiligen Periode. D.h. sich sehe z.B. auf dem Jahresdiagramm nur Werte vom vollständig abgelaufenen Jahren. Ich möchte aber nach jedem Tag auch den aktuellen Wert des noch laufenden Jahres sehen. Analog im Monat.

Ich speichere immer am 1. der Abrechnungsperiode. D.h. den Jahreswert des laufenden Jahres am 1.1. des Jahres. Warum, weil wenn ich ihn am z.B. 31.12. des laufenden Jahres speichere, die relative Darstellung in den Flotdiagrammen nicht mehr funktioniert.

[Homoran]

@marty56 ich habe eine ganz andere Frage:
ist das überhaupt eine Zahl?
üblicherweise sind die nit Dezimalpunkt, mit Komma könnte es ein String sein

[apollon77]

@marty56 sagte in History 2.0.0 verfügbar - eine Zusammenfassung:

zu 1. Ich habe mir jetzt die Schreiblogik durchgelesen. So richtig verstanden habe ich die leider nicht. Vor allen Dingen ist mir der Begriff "Darstellungsoptimierung" nicht klar und auch der Satz "Der Wert wird ggf. erinnert für spätere Aufzeichnung zur Darstellungsoptimierung". Was soll "erinnert" in diesem Kontext bedeuten.

"Erinnert" heisst das Sie auch mit geloggt wird mit dem "letzten zeitstempel" damit die Darstellung sinnvoll ist

WIe gesatt: Deine Anforderungen sind so speziell das ich einfach nen eigenen "logging "Datenpunkt machen würde an deiner Stelle und da nur das reinschreibst was Du haben willst.

[Marty56]

@homoran Ja, es ist ein Zahl.

[Marty56]

@apollon77

Es wäre wirklich super, wenn man diese ganzen Regeln zum automatisieren Schreiben einfach mit einem Click abschalten könnte.
Also ein Click "schreibe nie in History DB, wenn der Datenpunkt geändert oder neu gesetzt wird".

Ich möchte nur mit "send(history ... " in die Datenbasis schreiben und schaffe es nicht, das Regelwert für das automatische Schreiben so zu konfigurieren, dass das automatische Schreiben völlig unterbunden wird.

Ich habe Änderung konfiguriert, die Optimierung der Darstellung deaktiviert und dazu noch einen riesigen Wert für den Unterschied zwischen den Werten angegeben, wann geschrieben werden soll. Aber jeden neuen Tag wird trotzdem immer der erste Wert geschrieben, was für meine Auswertungen und Diagramme nicht passt.

Mache ich irgendetwas falsch oder wird die Überprüfung der Änderung des Wert an jedem neuen Tag beim ersten Mal ignoriert?

[apollon77]

@marty56 Dann poste bitte jetzt mal einen Debug log für diesen Datenpunkt. Sonst raten wir weiter rum.

Und dein Wunsch für einen "ausschlieslich manuell loggen" Modus (wo Du glaube der einzige bist der das aktuell willst) Wäre ein Feature Request. GitHub Issue bitte

[Marty56]

@apollon77

Wenn ich der Einzige bin, dann könnte es sein, dass ich den History Adapter vielleicht nicht verstanden habe.

Was ich machen will, ist ein Monats- und Jahres Verbrauchsdiagramm jeweils von meinem Stromverbrauch, Eigenverbrauch, PV Lieferung, PV Erzeugung und EV-Verbrauch zuhause und unterwegs.

Dabei will ich pro Jahr jeweils nur einen Wert speichern und nicht 365.
Ich möchte das laufende Jahr mit den vergangenen Jahren in einem Balkendiagramm darstellen.

Bei den Monaten analog, also nur nur 12 Werte pro Jahr.

Wie kann ich das mit dem history Adapter machen ohne meinen zugegebener maßen komplizierten Ansatz?

[paul53]

@marty56 sagte: Monats- und Jahres Verbrauchsdiagramm

Dafür ist History nicht gedacht. Das macht man mit dem Sourceanalytix-Adapter oder je einem kleinen Skript pro Zähler. Die dabei erzeugten Monats- und Jahres-Werte kann man problemlos historisieren.

[Marty56]

@apollon77

Anbei das Log. Es wird wieder der erste Wert des Datenpunks "javascript.0.strom.Erz_Energie_Tag" in die History DB geschrieben.

Wenn das einmal passiert, dann funktioniert das Regelwert und es werden keine weiteren Werte mehr geschrieben.

Dann sieht mein Diagram halt so aus.

und so sollte es aussehen, nachdem ich den Datenpunkt manuell gelöscht habe

Hier das Log. Ich Teile vom Vortag und von heute morgen zusammenkopiert. Ich hoffe, dass hilft.iobroker.log

[Marty56]

@paul53

Danke für den Hinweis.
Ich habe den Source Analytics Adapter ausprobiert.

Er passt für mich nicht. Unterstützt keine Zählerwechsel weil keine negativen Jahres/Monatszähler. Mit Workaround könnte da was machen.
Ich wüsste auch nicht, wie ich meine 12 jährigen historischen Daten einpflegen könnte.
Abgeleitete Zähler wie Eigenverbrauch und Gesamtverbrauch funktionieren auch nicht.
Ein Flot Diagram mit History DB geht auch nicht direkt, sondern nur per Script und speziellen Diagramm Datenpunkten, die man sich aus den Daten des Source Analytics Adapter per Script generieren müsste und dann per send(history.... einpflegen müsste.

Das wäre deutlich komplizierter als das kleine Skript, was ich jetzt habe und das bis auf das History Issue gut funktioniert.

[apollon77]

Hallo alle zusammen,

mit dem Feedback hier und auf GitHub und noch ein paar Sentry Fehlermeldungen, gibts jetzt hier die 2.1.0 mit noch ein paar Neuerungen:

Die wichtigste Neuerung ist das storeState und auch GetHistory jetzt auch für "unbekannte Objects-IDs" geht. Es fehlen natürlich sämtliche Filteroptionen und alles was man pro Datenpunkt einstellen kann, aber das sollte klar sein

• (Apollon77) Fix several crash cases reported by Sentry
• (Apollon77) Make sure disabling "Log changes only" also really do not log the changes anymore
• (Apollon77) Allow storeState and GetHistory also to be called for "unknown ids"

Das Update sollte im Laufe des Abends im latest Repo aufauchen,

Viel Spass damit.

Ingo

[apollon77]

Und damit es nicht ganz langweilig wird hier noch ein kleines Update auf die 2.1.3 ... Ich habe nochmal in so einige Performancethemen vor allem bei GetHistory reingeschau und optimiert.

Wenn alles klappt geht das dann demnächst auch in Stable.

[afuerhoff]

@apollon77
Hallo, ich habe da mal eine Frage zu den zusätzlichen Werten.

Ich logge einen Boolean Wert und möchte mit einem Script immer den aktuellen Tag auslesen.
Aggregat Funktion = onchange

Hier mal ein paar Beispiel Werte aus dem Script (inklusive den beiden Randwerten):

10:53:03.221	info	javascript.0 (1622) script.js.Haus.Skript_2: history: Sun Jun 19 2022 00:00:00 GMT+0200 (Central European Summer Time)false
10:53:03.221	info	javascript.0 (1622) script.js.Haus.Skript_2: history: Sun Jun 19 2022 10:51:11 GMT+0200 (Central European Summer Time)false
10:53:03.221	info	javascript.0 (1622) script.js.Haus.Skript_2: history: Sun Jun 19 2022 10:52:22 GMT+0200 (Central European Summer Time)true
10:53:03.221	info	javascript.0 (1622) script.js.Haus.Skript_2: history: Sun Jun 19 2022 10:53:03 GMT+0200 (Central European Summer Time)true

Im Historydiagramm des Adapters sieht es so aus.

Der Boolean Wert war seit Mitternacht auf TRUE und hat dann um 10:51 nach FALSE und wieder nach TRUE gewechselt.
Jetzt würde ich erwarten, das der erste zus. Wert ebenfalls auf TRUE ist. Gelesen wird aber mit dem Script FALSE. Der letzte Wert passt.
Falls kein Wert für den Tag in der History gelogged wurde, gibt es auch keine zus. Werte. Da würde ich erwarten, das es ebenfalls zwei zus. Werte gibt.

Habe ich da einen Denkfehler?

[apollon77]

@afuerhoff Da müsste man jetzt exakt auch Deine Einstellungen kennen. Am allereinfachsten aktiviere doch mal das zusätzliche Debug für den relevanten Datenpunkt und liess Dir durch was er loggt bzw poste es hier. Da steht quasi exakt drin warum ein Wert geloggt wird oder verspätet geloggt wird oder verworfen wird.

[afuerhoff]

@apollon77
Die zusätzlichen Werte werden doch vom History Adapter ermittelt. Die werden doch dann nicht gelogged.

[apollon77]

@afuerhoff zusätzliche Werte sind anmelde nur werte Wonder adapter entscheidet sie nicht jetzt zu loggen aber ggf später. Und das sieht man im log.

[apollon77]

Hey all,

von History gibts jetzt die 2.1.6 mit letzten Fixes. Wenn keiner mehr was meldet wäre das die Version die die Tage in Stable geht.

Bitte checkt es nochmal

Ingo