UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

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

[Excodibur]

Der Adapter-Code wurde nochmal aktualisiert. Das History-Problem sollte jetzt behoben sein und beim Wechseln auf eine niedrigere Vorhaltezeit sollte es im Admin 5 eine Warnung geben.

Was aktuell noch nicht ganz sauber klappt, ist das Anzeigen von boolean-Werten in der History. Diese werden zwar angezeigt, allerdings werden zusätzlich noch zwei fiktive Werte mit angezeigt. Das passiert aber nur in der neuen Admin 5 Oberfläche und liegt vermutlich nicht am Influx Adapter. Ich bin hier noch auf Ursachen-Suche.

Da es auch nochmal einen wichtigen Fix im Admin 5.1.15 gab, muss jetzt diese Version (aktuell aus Beta/Latest) installiert werden, damit der Influx-Adapter überhaupt startet. Bitte daher zuerst ein Update vom Admin durchführen.

Bitte testet nochmal, ob es nun bei euch funktioniert, oder noch Fehler gibt.

[Feuersturm]

@excodibur Ich hab mir gerade einmal die neue github Version installiert (Admin 5.1.15 ist vorhanden).

Szenario a) Keine automatische Löschung
In der Instanz ist "keine automatische Löschung" ausgewählt und dies sehe ich auch in Influxdb

Wenn ich dann den Wert auf 6 Monate im Adapter setze kommt keine Abfrage mit der Bestätigung.

Nach Beenden und speichern wir 1 Jahr auch in Influx übernommen

Szenario b) Retention: 365 days
Wenn jetzt 1 Jahr in ioBroker und influxdb hinterlegt ist und ich dann 3 Monate z.B. einstelle

aber die Bestätigung nicht anklicke und nur beenden und speichern drücke, dann wird trotzdem der Wert in influxdb geändert

https://github.com/ioBroker/ioBroker.influxdb/issues/126

[apollon77]

@feuersturm machst bitte GitHub issue? Gibt noch ein Admin issue was diese Abfrage angeht. Vllt ist’s genau das. Excodibur ist da aber gerade tiefer drin.

[Feuersturm]

@apollon77 Erledigt. Ist im Beitrag oben referenziert.

[apollon77]

@feuersturm GitHub sollte fix haben

[Feuersturm]

@apollon77 Github Version installiert und das Ticket entsprechend kommentiert.

[Sputnik24]

Hallo zusammen,

habe aktuell noch influxdb 1.8 laufen, wollte auf 2.0 hoch und hab zuerst den Adapter über github installiert. Allerdings sind jetzt ALLE alten Daten weg - auch nach Einspielen eines Backups kurz vorm Update des Adapters. Neue Daten werden geschrieben.

[Thomas Braun]

@sputnik24 Du hast gelesen, dass man seine 1.8er Daten nicht einfach in 2.0 übernehmen kann? Die müssen zuvor konvertiert werden. Das hat aber nix mit dem ioBroker-Adapter zu tun.

[Sputnik24]

@thomas-braun Ich hab den Adapter auf 2.0 geupdatet und Datenbank auf 1.x gestellt. InfluxDB ist noch auf 1.x. Wollte zuerst den Adapter updaten, danach influxdb. Aber nach dem Adapter-Update sind die Daten in influxDB alle weg.

[apollon77]

@sputnik24 Was ist denn Deine Einstellung zu "Retention Time"im Adapter? Nicht das der jetzt "endlich" die korrekte Retention time gesetzt hat ... was dann bei dir diese Auswirkung hatte.
Bitte mla das iobroker Log vom ersten start der 2.0 zeigen (Logfile unter /opt/iobroker/log/...)

[Sputnik24]

@apollon77 Danke für den Hinweis. Die Storage Vorhaltezeit steht auf "Keine automatische Löschung"

Log:

2021-08-01 14:06:11.591  - info: influxdb.0 (31576) starting. Version 2.0.0 in /opt/iobroker/node_modules/iobroker.influxdb, node: v12.20.1, js-controller: 3.3.11
2021-08-01 14:06:11.633  - info: influxdb.0 (31576) No stored data from last exit found
2021-08-01 14:06:11.635  - info: influxdb.0 (31576) Connecting http://10.0.0.9:8086 ...
2021-08-01 14:06:11.636  - info: influxdb.0 (31576) Influx DB Version used: 1.x
2021-08-01 14:06:11.732  - info: influxdb.0 (31576) Connected!
2021-08-01 14:06:11.754  - info: influxdb.0 (31576) Applying retention policy for iobroker to 0 seconds. Shard Duration: 604800 seconds

[Thomas Braun]

@sputnik24

node: v12.20.1, js-controller: 3.3.11

Würde ich beides aktuell halten. Beta-Testing ist nur gegen die aktuelle Version sinnvoll.

[Sputnik24]

@thomas-braun said in Test Adapter influxdb 2.0:

@sputnik24

node: v12.20.1, js-controller: 3.3.11

Würde ich beides aktuell halten. Beta-Testing ist nur gegen die aktuelle Version sinnvoll.

Ich nutze iobroker als Docker-Image von https://github.com/buanet/ioBroker.docker , was leider seit längerem kein Update erhalten hat.

[Thomas Braun]

@sputnik24
Und das kann/muss man nicht selber auf Stand halten?

[apollon77]

@sputnik24 Hm ... 0 heisst an sich unendlich ... aoso das kanns nicht sein

[apollon77]

@sputnik24 Kannst DU bitte auch mal im influxdb log schauen?

[Sputnik24]

@apollon77 Gerne und danke.

Aber muss doch an der retention liegen. Log vom gleichen Zeitstempel wie oben:

2021-08-01 12:06:11	stdout	[httpd] 10.0.0.9 - user [01/Aug/2021:12:06:11 +0000] "GET /query?db=iobroker&p=%5BREDACTED%5D&precision=ms&q=CREATE+RETENTION+POLICY+%22global%22+ON+iobroker+DURATION+0s+REPLICATION+1+SHARD+DURATION+604800s+DEFAULT&u=user HTTP/1.1" 200 248 "-" "-" dcd65bb8-f2c0-11eb-9ebb-001132661b83 89601
2021-08-01 12:06:11	stdout	2021-08-01T12:06:11.761523Z info Executing query {"log_id": "0V2ScIbW000", "service": "query", "query": "CREATE RETENTION POLICY global ON iobroker DURATION 0s REPLICATION 1 SHARD DURATION 1w DEFAULT"}
2021-08-01 12:06:11	stdout	[httpd] 10.0.0.9 - user [01/Aug/2021:12:06:11 +0000] "GET /query?db=iobroker&p=%5BREDACTED%5D&precision=ms&q=SHOW+RETENTION+POLICIES+ON+iobroker&u=user HTTP/1.1" 200 164 "-" "-" dcd3211e-f2c0-11eb-9eba-001132661b83 7913
2021-08-01 12:06:11	stdout	2021-08-01T12:06:11.747205Z info Executing query {"log_id": "0V2ScIbW000", "service": "query", "query": "SHOW RETENTION POLICIES ON iobroker"}
2021-08-01 12:06:11	stdout	[httpd] 10.0.0.9 - user [01/Aug/2021:12:06:11 +0000] "GET /query?db=iobroker&p=%5BREDACTED%5D&precision=ms&q=show+databases&u=user HTTP/1.1" 200 122 "-" "-" dccc4a57-f2c0-11eb-9eb9-001132661b83 27108
2021-08-01 12:06:11	stdout	2021-08-01T12:06:11.714386Z info Executing query {"log_id": "0V2ScIbW000", "service": "query", "query": "SHOW DATABASES"}
2021-08-01 12:04:30	stdout	2021-08-01T12:04:30.348661Z info TSM compaction (end) {"log_id": "0V2ScIbW000", "engine": "tsm1", "tsm1_strategy": "full", "tsm1_optimize": false, "trace_id": "0VhPTHN0000", "op_name": "tsm1_compact_group", "op_event": "end", "op_elapsed": "176.472ms"}
2021-08-01 12:04:30	stdout	2021-08-01T12:04:30.348414Z info Finished compacting files {"log_id": "0V2ScIbW000", "engine": "tsm1", "tsm1_strategy": "full", "tsm1_optimize": false, "trace_id": "0VhPTHN0000", "op_name": "tsm1_compact_group", "tsm1_files_n": 1}
2021-08-01 12:04:30	stdout	2021-08-01T12:04:30.348078Z info Compacted file {"log_id": "0V2ScIbW000", "engine": "tsm1", "tsm1_strategy": "full", "tsm1_optimize": false, "trace_id": "0VhPTHN0000", "op_name": "tsm1_compact_group", "tsm1_index": 0, "tsm1_file": "/var/lib/influxdb/data/iobroker/autogen/319/000000011-000000002.tsm.tmp"}
2021-08-01 12:04:30	stdout	2021-08-01T12:04:30.172427Z info Compacting file {"log_id": "0V2ScIbW000", "engine": "tsm1", "tsm1_strategy": "full", "tsm1_optimize": false, "trace_id": "0VhPTHN0000", "op_name": "tsm1_compact_group", "tsm1_index": 2, "tsm1_file": "/var/lib/influxdb/data/iobroker/autogen/319/000000011-000000001.tsm"}
2021-08-01 12:04:30	stdout	2021-08-01T12:04:30.172376Z info Compacting file {"log_id": "0V2ScIbW000", "engine": "tsm1", "tsm1_strategy": "full", "tsm1_optimize": false, "trace_id": "0VhPTHN0000", "op_name": "tsm1_compact_group", "tsm1_index": 1, "tsm1_file": "/var/lib/influxdb/data/iobroker/autogen/319/000000010-000000001.tsm"}
2021-08-01 12:04:30	stdout	2021-08-01T12:04:30.172338Z info Compacting file {"log_id": "0V2ScIbW000", "engine": "tsm1", "tsm1_strategy": "full", "tsm1_optimize": false, "trace_id": "0VhPTHN0000", "op_name": "tsm1_compact_group", "tsm1_index": 0, "tsm1_file": "/var/lib/influxdb/data/iobroker/autogen/319/000000009-000000005.tsm"}
2021-08-01 12:04:30	stdout	2021-08-01T12:04:30.172303Z info Beginning compaction {"log_id": "0V2ScIbW000", "engine": "tsm1", "tsm1_strategy": "full", "tsm1_optimize": false, "trace_id": "0VhPTHN0000", "op_name": "tsm1_compact_group", "tsm1_files_n": 3}
2021-08-01 12:04:30	stdout	2021-08-01T12:04:30.172190Z info TSM compaction (start) {"log_id": "0V2ScIbW000", "engine": "tsm1", "tsm1_strategy": "full", "tsm1_optimize": false, "trace_id": "0VhPTHN0000", "op_name": "tsm1_compact_group", "op_event": "start"}
2021-08-01 12:04:03	stdout	2021-08-01T12:04:03.266358Z info Retention policy deletion check (end) {"log_id": "0V2ScIbW000", "service": "retention", "trace_id": "0VhPRdGG000", "op_name": "retention_delete_check", "op_event": "end", "op_elapsed": "0.444ms"}
2021-08-01 12:04:03	stdout	2021-08-01T12:04:03.265951Z info Retention policy deletion check (start) {"log_id": "0V2ScIbW000", "service": "retention", "trace_id": "0VhPRdGG000", "op_name": "retention_delete_check", "op_event": "start"}

[Excodibur]

@sputnik24
Die Sache ist die: In Influx kann man "by Design" keine Retention von weniger als einer Stunde setzen, da die Entwickler explizit verhinden wollten, dass so etwas passiert.

Eine Retention von 0s ist gleichbedeutend mit unendlich (INF). In der Retention Tabelle kannst du das selbst sehen, wenn du Folgendes ausführst:

show retention policies
name    duration shardGroupDuration replicaN default
----    -------- ------------------ -------- -------
autogen 0s       168h0m0s           1        false
global  0s       168h0m0s           1        true

Da siehst man, dass nicht nur unsere custom Retention-Policy "global" mit 0s gesetzt ist, sondern auch die Default-Policy "autogen" die Influx immer anlegt und auf unendlich stellt. Wir packen diese im Adapter auch nicht an.

Folgende Befehle zeigen auch, das Influx unter 0s "unendlich" versteht:

> alter retention policy global on iobroker duration 0s
> show retention policies
name    duration shardGroupDuration replicaN default
----    -------- ------------------ -------- -------
autogen 0s       168h0m0s           1        false
global  0s       168h0m0s           1        true
>
> alter retention policy global on iobroker duration INF
> show retention policies
name    duration shardGroupDuration replicaN default
----    -------- ------------------ -------- -------
autogen 0s       168h0m0s           1        false
global  0s       168h0m0s           1        true
>
> alter retention policy global on iobroker duration 1s
ERR: retention policy duration must be at least 1h0m0s

In den ersten beiden Fällen setzt Influx unabhängig von INF, oder 0s die Retention in der Tabelle immer auf 0s. Im letzten Fall bei 1s beschwert sich Influx, da die Retention zu kurz ist.

Mir ist nur bekannt, dass Influx alle Daten löscht, wenn man die alte Retention Policy löscht und danach eine neue anlegt. Der Adapter macht das aber explizit nicht, sondern aktualisiert immer die bestehende Policy. Hast du sonst noch andere Änderungen an der Retention manuell in der DB durchgeführt?