Wartung am 15.11. – Forum ab 22:00 Uhr nicht erreichbar

[Feuersturm]

@stenmic ich denke diese Frage geht eher an @apollon77 oder @Excodibur

[stenmic]

@feuersturm upps, da hast du recht

[Excodibur]

@stenmic Mit dem aktuellen Release geht es erst einmal darum eine grundlegende Unterstützung für InfluxDB 2 zu schaffen.

Die Möglichkeit verschiedene Retention-Policies (wie im Ticket beschrieben) je nach Datenpunkt zu nutzen, sieht für mich auf den ersten Blick technisch machbar aus (zumindest mit Influx 2.0), allerdings steckt da augenscheinlich einiges an zusätzlicher Arbeit drin:

• Man muss ggf. im Adapter die Konfigurationsseiten "aufbohren", damit man verschiedene Retention-Policies per Datenbank/Bucket pflegen (hinzufügen, ändern, entfernen) kann.
• Da der Adapter mit dem neuen Release zwei völlig unterschiedliche Bibliotheken zum Zugriff auf Influx 1/2 nutzt, müsste man "im Hintergrund" die Logik zweimal implementieren. in der Hoffnung natürlich, dass das Konzept bei beiden DB-Versionen auch gleich umgesetzt wurde, da es ansonsten für den normalen Nutzer bzgl. Adapter-Konfiguration zu komplex wird.
• Wenn es pro Datenpunkt einstellbar sein soll, muss man da auch nochmal an den Konfigurationsseiten Einiges optimieren.

Alles in allem denke ich, dass es sich hierbei um ein zustätzliches Wunsch-Feature handelt, das man sich nochmal separat anschauen muss. Interessant ist es auf jeden Fall.

[stenmic]

@excodibur für mich wäre das kein Wunsch, sondern eher eine Pflichtfunktion.

Zusammenfassung der Probleme:
Beim alten Adapter werden alle Werte aus der Datenbank gelöscht die älter als ein Jahr sind.
Beim alten Adapter spielt es überhaupt keine Rolle was man in der Vorhaltezeit einstellt.

Wäre super, wenn du da eine Lösung findest.

[e-s]

@stenmic
Danke für diese Erklärung. Habe mich die ganze Zeit gefragt für was ein Wechsel auf 2.0 lohnenswert wäre?
Gibt es noch weitere pros und contra?
CPU Last oder sonstiges.

[apollon77]

@stenmic sagte in Test Adapter influxdb 2.0:

Beim alten Adapter werden alle Werte aus der Datenbank gelöscht die älter als ein Jahr sind.

... was Du aktuell problemlos manuell inder Infuxdb fixen kannst indem Du die Retentionzeit anpasst (also ich hatte schon immer "unbegrenzt" ausgewählt und es wird da nichts gelöscht. Klar -das ist nicht Convenient aber ein valider Workaround

[Feuersturm]

@apollon77 Der Workaround ist natürlich möglich, wenn man von dem Problem weiß

Ich hatte mich auch auf die Einstellungen verlassen und bin dann erst auf die Suche gegangen, warum bei meinen Wetter und Lüftungsdaten der Zeitraum >1 Jahr nicht mehr da ist.

Aus Sicht des Users ist es irreführend, wenn ich eine Speicherdauer auswählen kann dies aber keinen Einfluss auf die Datenbank hat. Wäre es hier nicht zielführender das Auswahlmenü entfallen zu lassen, wenn da keine Funktion hinter steckt und z.B. auf die influxdb readme zu verweisen, wo man das Thema RETENTION dokumentiert, bzw. auf weitergehende Links in der influx Doku verweiset. Oder gibt es einen Use-Case wo die Auswahl der Speicherdauer etwas bewirkt?

[apollon77]

@feuersturm naja partiell. Wenn man es in der Haupt konfig vor dem anlegen der dB angibt wird es genutzt. Änderungen danach bzw das ganze ad Datenpunkt Ebene hat keine Auswirkungen

[stenmic]

@apollon77 ich sehe das genau wie Feuersturm.
Wenn man das Problem kennt, gibt es Lösungen. Das Problem steht aber nirgends.

Angestoßen von diesem Beitrag habe ich mich auch mal wieder mit dem Problem beschäftigt.
Mit Hilfe von @liv-in-sky habe ich mir eine bash erstellt, welches die Vorhaltezeit beim bereinigen berücksichtigt.
Mehr dazu hier: https://forum.iobroker.net/topic/41773/html-tabelle-für-dp-mit-history-einträgen?page=1

[Excodibur]

@stenmic Mit der aktuellen Version aus dem Github Repo sollte die Änderung der Vorhaltezeit jetzt berücksichtigt werden und das unabhängig vom Erstellungszeitpunkt der DB. In der README gibt es zudem nochmal eine ausführlichere Erklärung der Zusammenhänge bzgl. Vorhaltezeit (Retention Period).

Individuelle Vorhaltezeiten je State lassen sich allerdings nicht mehr konfigurieren, wobei es ja zugegeben auch vorher keinen Effekt hatte. Der Grund warum es ganz entfernt wurde, ist, weil Influx 2 das ganze Konzept von Retention-Periods überarbeitet hat und nur noch eine aktive Retention-Period pro Bucket/DB zulässt.

[tigiba]

Hab mir die Testversion zum Verbinden mit der Influxdb 2.0 auch installiert.
Das Einspielen von Daten aus dem IO-Broker in die Influxdb funktioniert gut, aber der IOBroker schafft's nicht die Daten wieder auszulesen. Sehe sehr viele solche Zeilen im Log:

(145261) Error in query "from(bucket: "iobroker") |> range(start: 2021-07-23T11:22:32.049Z) |> filter(fn: (r) => r["_measurement"] == "0_userdata.0.lm-sensors.acpitz")

Ich hab die query manuell aus dem Log rauskopiert und über die InfluxDB UI (http port 8086) ausgeführt, da funtkioniert sie einfwandfrei. Wobei vielleicht ist das führende Anfürungszeichen das Problem?

[apollon77]

@tigiba Bitte GitHub Issue mit Debug log von so einer Query anlegen. Am besten aus dem Logfile auf Platte holen das log das es vollständig ist

[Dolomiti]

@Excodibur @apollon77
Habe mir zum testen einen neuen LXC mit influxdb 2.0 aufgesetzt. Dann Adapter über Github auf meinem Test-Raspi installiert. Hat soweit geklappt. Dann habe ich einen Datenpunkt in die neue DB schreiben lassen.Die Werte kommen auch an, was ich im Web-GUI der DB sehen kann. Wenn ich mir die Werte des DP im ioBroker unter Verlaufsdaten anzeigen lasse sehe ich nur einen laufenden blauen Balken und es kommt folgendes im Log:

2021-07-24 00:27:23.275 - warn: influxdb.0 (20925) Error in query "from(bucket: "influx2test") |> range(start: 2021-07-23T22:27:24.258Z) |> filter(fn: (r) => r["_measurement"] == "shelly.0.SHSW-1#058D8E#1.Relay0.Switch") |> sort(columns: ["_time"], desc: false) |> group() |> limit(n: 1)": HttpError: error in building plan while starting program: cannot query an empty range
2021-07-24 00:27:32.350 - warn: influxdb.0 (20925) Error in query "from(bucket: "influx2test") |> range(start: 2021-07-23T22:27:33.334Z) |> filter(fn: (r) => r["_measurement"] == "shelly.0.SHSW-1#058D8E#1.Relay0.Switch") |> sort(columns: ["_time"], desc: false) |> group() |> limit(n: 1)": HttpError: error in building plan while starting program: cannot query an empty range

Wenn ich die Zeit auf "letzte Stunde" ändere, änert sich zwar rechts die Zeit/Datum, es werden aber keine Werte geholt.
Beo


Ich habe den Admin 5.1.13 mit neuem UI installiert

[apollon77]

@dolomiti dann bitte siehe letzter Post und meine Antwort. Scheint ja das gleiche Thema zu sein. Bitte GitHub issue mit mehr log

[tigiba]

@apollon77 wo finde ich / bzw wie erzeuge ich das "Debug log von so einer Query"?

[apollon77]

@tigiba debug log: Im admin: instanzen , expertenmodus und dann loglevel auf debug setzen. Dann startet adapter neu mit mehr logging. Logfile auf Platte ist /opt/iobroker/log/…

[tigiba]

@apollon77 okey, hier ein ausschnitt des debug logs:

2021-07-24 13:18:44.011  - debug: influxdb.0 (413113) value not changed 0_userdata.0.lm-sensors.battery_voltage, last-value=13.11, new-value=13.11, ts=1627125524008
2021-07-24 13:18:44.011  - debug: influxdb.0 (413113) value not changed 0_userdata.0.lm-sensors.battery_current, last-value=0.001, new-value=0.001, ts=1627125524008
2021-07-24 13:18:44.026  - debug: influxdb.0 (413113) Incoming message getHistory from system.adapter.admin.0
2021-07-24 13:18:44.026  - debug: influxdb.0 (413113) from(bucket: "iobroker")  |> range(start: -0ms, stop: 2021-07-24T11:18:54.020Z) |> filter(fn: (r) => r["_measurement"] == "0_userdata.0.lm-sensors.acpitz")  |> sort(columns:["_time"], desc: true) |> group() |> limit(n: 50),from(bucket: "iobroker")             |> range(start: 2021-07-24T11:18:54.020Z)             |> filter(fn: (r) => r["_measurement"] == "0_userdata.0.lm-sensors.acpitz")             |> sort(columns: ["_time"], desc: false)             |> group()             |> limit(n: 1)
2021-07-24 13:18:44.026  - debug: influxdb.0 (413113) Query to execute: from(bucket: "iobroker")  |> range(start: -0ms, stop: 2021-07-24T11:18:54.020Z) |> filter(fn: (r) => r["_measurement"] == "0_userdata.0.lm-sensors.acpitz")  |> sort(columns:["_time"], desc: true) |> group() |> limit(n: 50)
2021-07-24 13:18:44.042  - debug: influxdb.0 (413113) Query to execute: from(bucket: "iobroker")             |> range(start: 2021-07-24T11:18:54.020Z)             |> filter(fn: (r) => r["_measurement"] == "0_userdata.0.lm-sensors.acpitz")             |> sort(columns: ["_time"], desc: false)             |> group()             |> limit(n: 1)
2021-07-24 13:18:44.047  - warn: influxdb.0 (413113) Error in query "from(bucket: "iobroker")             |> range(start: 2021-07-24T11:18:54.020Z)             |> filter(fn: (r) => r["_measurement"] == "0_userdata.0.lm-sensors.acpitz")             |> sort(columns: ["_time"], desc: false)             |> group()             |> limit(n: 1)": HttpError: error in building plan while starting program: cannot query an empty range
2021-07-24 13:18:44.047  - debug: influxdb.0 (413113) Parsing retrieved rows:[[],[]]
2021-07-24 13:18:44.048  - debug: influxdb.0 (413113) sendTo "getHistory" to system.adapter.admin.0 from system.adapter.influxdb.0
2021-07-24 13:18:44.965  - debug: influxdb.0 (413113) system.adapter.admin.0: logging false
2021-07-24 13:18:45.020  - debug: influxdb.0 (413113) Min-Delta reached 0_userdata.0.lm-sensors.cpu_package, last-value=64, new-value=70, ts=1627125525019
2021-07-24 13:18:45.020  - debug: influxdb.0 (413113) Datatype 0_userdata.0.lm-sensors.cpu_package: Currently: number, StorageType: false
2021-07-24 13:18:45.020  - debug: influxdb.0 (413113) Datatype 0_userdata.0.lm-sensors.cpu_package: Currently: number, StorageType: false

UPDATE: Hier das github-Issue dazu:
https://github.com/ioBroker/ioBroker.influxdb/issues/124

thomas725 created this issue in ioBroker/ioBroker.influxdb

closed Data cannot be read back out from influxdb2.0 #124

[MichMein]

Hallöchen,
ist vielleicht etwas OT aber ich würde gerne wissen wollen wie ich die Einstellung der Speicherdauer in der influxdb prüfen und ggf. ändern kann?
@Excodibur oder kann ich einfach den Adapter von github aktualisieren und die o.g. Probleme sind passé?

Danke

[apollon77]

@michmein sagte in Test Adapter influxdb 2.0:

@Excodibur oder kann ich einfach den Adapter von github aktualisieren und die o.g. Probleme sind passé?

So ist die Idee. Mach vorher Backup und teste es

[MichMein]

@apollon77 danke dir. Das ist dann was für morgen.