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

[Excodibur]

@robbsen Nee, ich glaube ich hatte da ein Reconnect Verhalten eingebaut, falls es beim Anlegen der DB (und damit einhergehend dem Setzen der Retention Policy zu Problemen kommt, immer in der Annahme, dass Probleme so für nach dem Login auf Schwierigkeiten mit der Verbindung hindeuten. Die Annahme trifft in diesem Fall nicht zu, d.h. ich müsste mir den Adapter-Code nochmal anschauen und da was patchen.

[apollon77]

@sunny1081 Dann bitte GitHub Issue das er ein nen Fail bei Retention nur loggt aber komplett ignoriert ...

[apollon77]

@robbsen Das mit dem Owner Token war nur nötig bzw in der Readme wel wir es nicht hinbekommen hatten ein Token zu erzeugen mit dem der Adapter nach dem Anlegen der DB selbst darauf zugreifen durfte ...

[sunny1081]

@apollon77 done

[sebi85]

Hallo zusammen,

ich habe heute Nachmittag ein Update von der Version 2.0.0 auf die 2.1.1 durchgeführt.

Seit dem erhalte ich allerdings nur noch Influx-Protokollierungen mit ack == null und from == null für die jeweiligen Devices.

In meiner Influx-DB habe ich nun jeweils zwei Messpunkte pro Device - Beispiel:

Vor dem Update wurden alle Werte in den alten DP geschrieben:

Um 14:02 Uhr wurde dann von mir das Update auf die neue Version eingespielt. Das influx-Token ging bei dem Update kaputt und musste neu gesetzt werden, das hatte ich dann erst gegen 15:00 Uhr aktualisiert, daher gibt es ca. 1 Std. keine weiteren Einträge.

Nach der Aktualisierung des Tokens wurden die Daten allerdings in den neuen Datenpunkt geschrieben:

Somit passen nun leider sämtliche Grafana-Dashboards nicht mehr. Hatte sich hier zwischen den Versionen etwas geändert oder müssen zusätzliche Einstellungen vorgenommen werden?

Danke und viele Grüße,
Sebastian

[apollon77]

@sebi85 Du hast hier gelesen das das Logging Format zwischen 2.0 und 2.1 geändert wurde?? Scroll mal ein paar Tage hoch hier in diesem thread

[sebi85]

@apollon77 ich hatte "nur" die Changelog im Fokus, da hatte ich keinen Hinweis auf eine Änderung des Logformats gesehen.

Danke für den Hinweis, dann versuche ich mal die Daten irgendwie zu aggregieren.

[apollon77]

Ok,

der wunderbare @Excodibur hat Euch @sebi85 und @sunny1081 erhört und für InfluxDB 2 eine Einstellung eingeführt mit der man wählen kann wie die Daten abgelegt werden sollen. Im GitHub Readme stehen auch Infos dazu.

Also könntet Ihr jetzt die Daten die euch die 2.1 "falsch" reingeschrieben hat wegwerfen oder irgendwie umstellen (sorry das macht der Adapter nicht für euch). Das neue mit der Einstellung müsste mit dem Format der 2.0 identisch sein.
Oder Ihr fangt nochmal mit einer leeren DB an und schaut wie Ihr die alten Daten reinbekommt.

Bitte versucht es mal. Das neue ist erstmal auf GitHub: Von dort installieren und danach manuell Adapter neu starten. Dann in die Settings und unter "Erweiterte Einstellungen" das neue aktivieren. Bitte Feedback geben. Der Adapter checks das Format der existierenden Daten und meckert gegebenenfalls.

[Excodibur]

Die Doku zu dem Feature findet ihr hier: https://github.com/ioBroker/ioBroker.influxdb/blob/master/README.md#Store-metadata-information-as-tags-instead-of-fields

Das funktioniert nur bei Influx 2, d.h. ihr sollte dann in der Adapter Konfiguration die Verwendung von Tags per Checkbox aktivieren können. Wie von Apollon beschrieben, funktioniert das nicht mit alten DBs, die q, from und ack noch in fields speichern. Der Adapter gibt dann in dem Fall eine Fehlermeldung aus und stoppt. Am einfachsten mit einer neuen, leeren DB testen.

[sunny1081]

@excodibur Besten Dank dafür, es funktioniert.

Nur den alten Bucket konnte ich nicht nutzen. Wie wird den ausgemacht ob bereits TAGS genutzt wurden. Initial wurden den Daten mit TAGS geschrieben und dann einige wenige Tage mit Feldern, kann jetzt aber nicht mit TAGS weiter schreiben.

[apollon77]

@sunny1081 soweit ich weiß so:

Mit fieldKeys und tagKeys kann man das Schema untersuchen. Wenn der Adapter da sieht, das für q, from, ack tags oder fields benutzt wurden, gibt der ggf einen error aus

Reicht das? Sonst muss @Excodibur mehr sagen welche Magie er da gebaut hat.

[Ein ehemaliger Benutzer]

@apollon77

Hmm mit V2.2.20 ist irgendwie die Haltezeit der Daten verschwunden...???

[apollon77]

@ilovegym dann ließ mal Changelog. Das tat noch nie auf Datenpunkt Ebene und daher haben wir es mit der 2.0 dort rausgeworfen. Geht nur auf dB Ebene - da tut es aber jetzt was auch vorher nie tat

[Ein ehemaliger Benutzer]

@apollon77 ach das war das.. gelesen, vergessen, gewundert...

[Sputnik24]

@apollon77 said in Test Adapter influxdb 2.0:

Ich sage jetzt mal frech: Versucht es doch mal ... und schreibt es for uns und die anderen auf. Ich denke "adapter stoppen, updaten, Konfig ändern (ip, port, settings) und starten sollte es sein

Sorry für die späte Rückmeldung. Ich hab die Migration etwas hinausgezögert und wollte das in aller Ruhe machen. Das Mistwetter bietet sich nun dafür an.

Lange Rede: Ich hab heute erfolgreich von v1 auf v2 manuell migriert. Bei mir läuft influxdb als Docker Container auf einer Synology. Hier meine Schritte:

1. Docker Container v2 erstellen, aber noch nicht starten - Umgebungsvariablen passend für setup setzen, z.B.:
   DOCKER_INFLUXDB_INIT_MODE: setup
   DOCKER_INFLUXDB_INIT_BUCKET: iobroker
   DOCKER_INFLUXDB_INIT_ORG: iobroker
   DOCKER_INFLUXDB_INIT_USERNAME: iobroker
   DOCKER_INFLUXDB_INIT_PASSWORD: iobroker

2. optional: Aktuelle v1 DB mit BackItUp sichern (optional, da wir sowieso einen neuen Docker Container für v2 anlegen und damit v1 als Backup vorhanden bleibt)

3. influxDB Instanz stoppen

4. Im Terminal von Docker Container v1 Datenbank exportieren:
   service influxdb stop
   influx_inspect export -waldir /var/lib/influxdb/wal -datadir /var/lib/influxdb/data -database "iobroker" -retention "autogen" -out /var/lib/influxdb/export.db -lponly

5. Docker Container v1 stoppen

6. Docker Container v2 starten und setup abwarten

7. export.db in den gemounteten Data-Ordner Docker Container v2 verschieben

8. Im Terminmal von Docker Containver v2 export db importieren:
   influx write --bucket iobroker --file /var/lib/influxdb2/export.db

9. influxDB Instanz auf 2.x ändern, token eingeben und starten

Die export.db war bei mir fast 10 GByte groß, entsprechend hat der Import gute 1,5 Stunden gedauert, der Export ging mit ca. 10 min deutlich schneller.

Meine Motivation für die Migration war übrigens, dass flux nach Kalendermonaten und Jahren Daten aggregieren kann. Allerdings gibt es bereits einen ersten Wermutstropfen: flux kann aktuell keine Zeitzonen bei der Datenaggregierung. Damit sind die aggregierten Werte leicht falsch, was v.a. bei den Tageswerten deutlich spürbar ist, bei den Monatswerten weniger ins Gewicht fällt. Workaround wäre, für die Tageswerte mit influxql weiterzuarbeiten, allerdings bekomme ich grad die v1 Authentifizierung nicht hin, oder mit fixen timeshifts zu arbeiten, was aufgrund der Zeitumstellung blöd ist.

Insgesamt bin ich aber froh, dass es dann doch so reibungslos funktioniert hat. Leider hat Grafana noch kein QueryBuilder für flux, aber gut.

Danke für den tollen Support hier.

[apollon77]

@sputnik24 Vor der Umstellung graut mir noch ein bissl meine v1-db hat gerade auf der platte 54GB ... keine ahnung was das als export file wird. Was hatte deine denn auf der platte wo 10GB export drauf wurden?

[Sputnik24]

@apollon77 Autsch. Bei mir hatte /var/lib/influxdb 658 MByte

[apollon77]

@sputnik24 Krass ... Faktor fast 20? wtf

Mein ioBroker hat 34GB ... mit faktor 20 also ca. 600GB
Na dann überlege ich mal wie ich das storage technisch mache :-)) Oder ich muss zeitraummässig migrieren

Wieviel ists eigentlich nach der Migration auf Platte? Auch grob die 658MB?

aahh man kann das File auch compressen ... kannst du mal ein "gzip 10GBfile" machen und sagen was rauskommt?

[Ein ehemaliger Benutzer]

@apollon77 hmpff bei mir sinds:

64445168 /var/lib/influxdb/

das bedeutet, Snickers...

[robbsen]

Hallo Zusammen,

habe vor ca. 2-3 Wochen meine alte Influx DB 1.8.3 aufgegeben, Influx 2.x neu aufgesetzt (Proxmox Container) und den Adapter installiert.
Ich habe seitdem allerdings Probleme mit dem Adapter oder der Datenbank selber. Die Daten werden zwar geschrieben und sind in der Datenbank vorhanden, aber der Adapter verliert regelmäßig den Kontakt.

Ich hatte zuerst gehofft das Problem behebt sich von alleine durch die fleißigen Fehlerkorrekturen. Aber bisher leider nicht.

P.s. ich habe ergänzend das Problem, dass ich auch aus der Oberfläche von influxdb (siehe Bild) automatisch und schnell rausgeschmissen werde. ggf. liegt das Problem also auch bei Influx und nicht dem Adapter. Bin mir aber nicht sicher wie ich das überprüfen könnte.

Hat einer ähnliche Probleme oder eine Lösung?

2021-09-02 06:13:56.095 - error: influxdb.0 (339) Error during ping: Error: connect ECONNREFUSED 192.168.2.209:8086. Attempting reconnect.
2021-09-02 06:14:06.095 - info: influxdb.0 (339) Connecting http://192.168.2.209:8086 ...
2021-09-02 06:14:06.095 - info: influxdb.0 (339) Influx DB Version used: 2.x
2021-09-02 06:14:06.097 - error: influxdb.0 (339) Error: connect ECONNREFUSED 192.168.2.209:8086
2021-09-02 06:14:16.097 - info: influxdb.0 (339) Connecting http://192.168.2.209:8086 ...
2021-09-02 06:14:16.098 - info: influxdb.0 (339) Influx DB Version used: 2.x
2021-09-02 06:14:16.099 - error: influxdb.0 (339) Error: connect ECONNREFUSED 192.168.2.209:8086
2021-09-02 06:14:26.099 - info: influxdb.0 (339) Connecting http://192.168.2.209:8086 ...
2021-09-02 06:14:26.099 - info: influxdb.0 (339) Influx DB Version used: 2.x
2021-09-02 06:14:26.107 - info: influxdb.0 (339) Applying retention policy for iobroker to 63072000 seconds. Shard Group Duration (calculated): 604800 seconds
2021-09-02 06:14:26.169 - info: influxdb.0 (339) Connected!