influxdb 3.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 InfluxDB(und History und SQL)-Adapters ins Beta/Latest Repo. Viel Spass!

Diese neue (Major!) Version des influxdb Adapters räumt einige Dinge auf und sorgt bei einigen Themen für mehr Transparenz 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! An den Daten in der Datenbank bzw deren Strukturen ändert sich nichts!

Da dies jetzt einiges an Änderungen ist starten wir erst einmal mit einem Alpha Test von GitHub. Bitte als im Admin den Expertenmodus aktivieren und vom GitHub installieren.

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. Wenn möglich berechnet die DB die Ergebnisse.
• 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. Wenn möglich berechnet die DB die Ergebnisse.
• 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.
• Die Aufbewahrungszeit kann nun neben den vorgeschlagenen zeiträumen auch selbst in tagen definiert werden (Custom)
• Wenn Buffering genutzt wird, so werden bei einer History-Anfrage alle noch nicht gespeicherten Daten vor der Datenabfrage in die Datenbank geschrieben.
• Eine neue Message erlaubt es den gesamten Buffer in die die DB zu schreiben - oder nur einen einzelnen Datenpunkt.
• Für InfluxDB 2.x kann nun in den Einstellungen ein Pfad für die Verbindung angegeben werden, falls z.B. ein Reverse Proxy genutzt wird.
• Standardmäßig loggt der Adapter zum Start den letzten Wert eines States mit aktuellem Wert nochmals mit aktuellem Zeitstempel. Dies kann nun konfiguriert 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

[TbsJah]

@apollon77 ist geplant dass die Vorhaltezeit individuell pro Objekt eingestellt werden kann?

[oFbEQnpoLKKl6mbY5e13]

@apollon77

Was muss bei einem Datenpunkt eingestellt werden, damit nicht bei jedem Neustart der Influxdb-Instanz der letzte Wert erneut aufgezeichnet wird, obwohl "Nur Änderungen aufzeichnen" und "Optimierte Protokollierung übersprungener Werte für Diagramme deaktivieren" aktiviert ist?

[apollon77]

@tbsjah Da das in der InfluxDB nicht wirklich geht (es sei denn der Adapter löscht die Daten selbst), Nein. Die Retention Zeit bei der InfluxDB setzt man pro Bucket/DB ...

[apollon77]

@ofbeqnpolkkl6mby5e13 Ich habe den Beitrag mal ins InfluxDB Thema verschoben.

In den Instanzeinstellungen gibt es eine Einstellung dafür "Protokollieren Sie den letzten Wert erneut beim Start" ... Damit vllt?

[oFbEQnpoLKKl6mbY5e13]

@apollon77

Ich schon wieder...

Ich habe bisher mit einem Javaskript Einträge in die DB geschrieben. Zuletzt habe ich das erfolgreich am 10.05. gemacht. Nach dem Update auf die neue Version funktioniert das nun nicht mehr. Es wird kein neuer Eintrag in der DB erstellt, obwohl folgendes ausgegeben wird:

2022-05-13 09:33:21.322  - debug: influxdb.0 (2521) Incoming message storeState from system.adapter.javascript.0
2022-05-13 09:33:21.324  - debug: influxdb.0 (2521) storeState 1 item

Hier der Kern meines Skripts:

  sendTo('influxdb.0', 'storeState', {

     id: '0_userdata.0.Haus.Energie.Zaehler.Wasser',

      state: {ts: Date.UTC(getState("0_userdata.0.Haus.Energie.Zaehler.Jahr").val, monat, 
        getState("0_userdata.0.Haus.Energie.Zaehler.Tag").val, 
        getState("0_userdata.0.Haus.Energie.Zaehler.Stunde").val, 
        getState("0_userdata.0.Haus.Energie.Zaehler.Minute").val, 0),

            val: wasser,

            ack: false,

            from: "VIS",

            q: delta
      }
    });
  }

[apollon77]

@ofbeqnpolkkl6mby5e13 Naja mal ganz frech: Nutzt du Buffering? Wenn ja wird es natürlich erst dann geschrieben wenn der Buffer "voll" ist ... Das Log sagt mir das der Wert erstmmal nur im Buffer landet und noch nicht geschrieben ist

PS: "from" hat formal ein falsches Format, aber am ende wohl egal

Und was schreibst du da bei "q" rein?

[oFbEQnpoLKKl6mbY5e13]

@apollon77 sagte in influxdb 3.0.0 verfügbar - eine Zusammenfassung:

@ofbeqnpolkkl6mby5e13 Naja mal ganz frech: Nutzt du Buffering? Wenn ja wird es natürlich erst dann geschrieben wenn der Buffer "voll" ist ... Das Log sagt mir das der Wert erstmmal nur im Buffer landet und noch nicht geschrieben ist>

Keine Ahnung, hätten die Werte dann nicht beim Beenden der Instanz (als ich auf Debug umgestellt habe) geschrieben werden müssen?

An der DB und den Einstellungen habe ich ja dbzgl. nichts geändert. Schreibaktionen zusammenfassen steht auf 0.

[oFbEQnpoLKKl6mbY5e13]

@apollon77 sagte in influxdb 3.0.0 verfügbar - eine Zusammenfassung:

Und was schreibst du da bei "q" rein?

Die Differenz zum vorherigen Wert.

[apollon77]

@ofbeqnpolkkl6mby5e13 sagte in influxdb 3.0.0 verfügbar - eine Zusammenfassung:

Keine Ahnung, hätten die Werte dann nicht beim Beenden der Instanz (als ich auf Debug umgestellt habe) geschrieben werden müssen?

Nein, der InfluxDB Adapter schreibt beim beenden die Daten in ein Temporäres file und Lädt Sie wieder zum start.

Mach doch mal Debug log fpr die Instanz und den Datenpunkt an ... dann zeig mal

[apollon77]

@ofbeqnpolkkl6mby5e13 Das ist auch komplett "falsch" ... Es sollte ncihts kaputt gehen aber der q(uality) wert ist was gaaanz anderes

[oFbEQnpoLKKl6mbY5e13]

@apollon77 sagte in influxdb 3.0.0 verfügbar - eine Zusammenfassung:

@ofbeqnpolkkl6mby5e13 Das ist auch komplett "falsch" ... Es sollte ncihts kaputt gehen aber der q(uality) wert ist was gaaanz anderes

Ich bin mir der Zweckentfremdung bewusst.

[oFbEQnpoLKKl6mbY5e13]

@apollon77 sagte in influxdb 3.0.0 verfügbar - eine Zusammenfassung:

Mach doch mal Debug log fpr die Instanz und den Datenpunkt an ... dann zeig mal

Ich schreibe die Daten wie gesagt manuell mit einem Skript in die Datenbank.

Die Meldung ist dieselbe:

2022-05-13 11:37:44.131  - debug: influxdb.0 (9994) Incoming message storeState from system.adapter.javascript.0
2022-05-13 11:37:44.132  - debug: influxdb.0 (9994) storeState 1 item

[apollon77]

@ofbeqnpolkkl6mby5e13 Ok, verstehe ich nicht. Bitte mal GitHub version installieren (Versionsnummer bleibt gleich, danach Adapter manuell neu starten). Dann bitte nochmal Debug log posten, sollte jetzt ggf mehr sein

[oFbEQnpoLKKl6mbY5e13]

@apollon77

Crasht:

2022-05-13 13:55:16.385  - debug: influxdb.0 (18439) Incoming message storeState from system.adapter.javascript.0
2022-05-13 13:55:16.386  - debug: influxdb.0 (18439) storeState 1 item
2022-05-13 13:55:16.394  - error: influxdb.0 (18439) uncaught exception: adapter.log.warning is not a function
2022-05-13 13:55:16.396  - error: influxdb.0 (18439) TypeError: adapter.log.warning is not a function
    at Immediate.<anonymous> (/opt/iobroker/node_modules/iobroker.influxdb/main.js:1745:76)
    at processImmediate (internal/timers.js:466:21)
2022-05-13 13:55:16.397  - error: influxdb.0 (18439) adapter.log.warning is not a function

2022-05-13 13:55:16.944  - info: influxdb.0 (18439) terminating
2022-05-13 13:55:16.945  - debug: influxdb.0 (18439) Plugin sentry destroyed
2022-05-13 13:55:16.946  - warn: influxdb.0 (18439) Terminated (UNCAUGHT_EXCEPTION): Without reason
2022-05-13 13:55:17.534  - error: host.iobroker instance system.adapter.influxdb.0 terminated with code 6 (UNCAUGHT_EXCEPTION)
2022-05-13 13:55:17.535  - info: host.iobroker Restart adapter system.adapter.influxdb.0 because enabled
2022-05-13 13:55:37.186  - info: host.iobroker "system.adapter.influxdb.0" disabled

[apollon77]

@ofbeqnpolkkl6mby5e13 Ok, da war ich zu fix :-)) Nochmal bitte

[oFbEQnpoLKKl6mbY5e13]

@apollon77

2022-05-13 15:24:13.648  - debug: influxdb.0 (23941) Incoming message storeState from system.adapter.javascript.0
2022-05-13 15:24:13.649  - debug: influxdb.0 (23941) storeState 1 item
2022-05-13 15:24:13.652  - warn: influxdb.0 (23941) Error writing state for 0_userdata.0.Haus.Energie.Zaehler.Wasser: ID 0_userdata.0.Haus.Energie.Zaehler.Wasser not activated for logging, Data: [object Object]

[apollon77]

@ofbeqnpolkkl6mby5e13 Reicht Dir das als Antwort?

[oFbEQnpoLKKl6mbY5e13]

@apollon77

Natürlich nicht, denn das war über Jahre möglich. Weshalb sollte man nicht mehr manuell in die DB speichern können?

[apollon77]

@ofbeqnpolkkl6mby5e13 Naja, weil damit sämtliche Settings fehlen ... Man könnte es ausschliesslich für storeState wieder erlaube ... sind halt Edge cases die immer wirder für die Lustigsten Fehler sorgen.

Bitte lege ein GitHub issue als Feature Request (jaja ... ging ja immer ... sollte es aber nie) an. Danke