Test Adapter influxdb 2.0
-
Ich habe es jetzt noch nicht getestet, aber müsste so in die Richtung gehen:
/* DB auswählen */ use iobroker /* Namen all gespeicherten States rausfinden */ show measurements /* Gespeicherte Daten von alter (autogen) in neue (global) retention kopieren */ SELECT * INTO "iobroker"."global"."<measurement-name>" FROM "iobroker"."autogen"."<measurement-name>" GROUP BY * /* Alte retention policy löschen, damit alle damit verbunden Measurements gelöscht werden. Vorher checken, das sie kopiert wurden!!!! */ DROP RETENTION POLICY "autogen" ON "iobroker" -
@sputnik24 Bevor du migrierst, warte bitte noch kurz. Wir überlegen, ob man den Namen der Retention nicht per Config änderbar machen sollte, sodass man z.B. in deinem Fall den Adapter dazu bringen kann, "autogen" weiter zu nutzen.
-
Moin, habe gerade versucht auf den Adapter 2.0 zu wechseln und bekomme die Instanz nicht mehr ans Laufen:
startInstance system.adapter.influxdb.0: required adapter "admin" has wrong version. Installed "5.1.15", required ">=5.1.19"!Installiert ist Admin 5.1.19.
Meldung bleibt allerdings auch beim Downgrade vom Adapter auf 1.9.5 erhalten.Eine Idee, wo es hier hängt?
Danke vorab.
-
iobroker list adapters iobroker list instances -
system.adapter.accuweather : accuweather - v1.2.0 system.adapter.admin : admin - v5.1.15 system.adapter.alexa2 : alexa2 - v3.9.3 system.adapter.discovery : discovery - v2.7.0 system.adapter.fullybrowser : fullybrowser - v2.0.8 system.adapter.ical : ical - v1.11.1 system.adapter.influxdb : influxdb - v1.9.5 system.adapter.info : info - v1.9.6 system.adapter.javascript : javascript - v5.2.8 system.adapter.knx : knx - v1.0.45 system.adapter.lovelace : lovelace - v2.0.4 system.adapter.luxtronik2 : luxtronik2 - v0.3.0 system.adapter.modbus : modbus - v3.4.9 system.adapter.pushover : pushover - v2.0.5 system.adapter.roomba : roomba - v1.1.2 system.adapter.simple-api : simple-api - v2.6.1 system.adapter.sma-em : sma-em - v0.6.3 system.adapter.sourceanalytix : sourceanalytix - v0.4.9 system.adapter.trashschedule : trashschedule - v1.1.1 system.adapter.unifi-protect : unifi-protect - v0.0.12 system.adapter.web : web - v3.4.7 system.adapter.zigbee : zigbee - v1.5.6Hmm, unter Instanzen wird mir die 5.1.19 angezeigt.
Update, Upgrade Self und Upgrade habe ich laufen lassen.
Weißt du, woran das liegen kann?/edit: Hab den Adapter über die Konsole neu installiert. Jetzt läuft es. Danke.
system.adapter.accuweather : accuweather - v1.2.0 system.adapter.admin : admin - v5.1.19 system.adapter.alexa2 : alexa2 - v3.9.3 system.adapter.discovery : discovery - v2.7.0 system.adapter.fullybrowser : fullybrowser - v2.0.8 system.adapter.ical : ical - v1.11.1 system.adapter.influxdb : influxdb - v2.0.0 system.adapter.info : info - v1.9.8 system.adapter.javascript : javascript - v5.2.8 system.adapter.knx : knx - v1.0.45 system.adapter.lovelace : lovelace - v2.0.4 system.adapter.luxtronik2 : luxtronik2 - v0.3.0 system.adapter.modbus : modbus - v3.4.9 system.adapter.pushover : pushover - v2.0.5 system.adapter.roomba : roomba - v1.1.2 system.adapter.simple-api : simple-api - v2.6.1 system.adapter.sma-em : sma-em - v0.6.3 system.adapter.sourceanalytix : sourceanalytix - v0.4.9 system.adapter.trashschedule : trashschedule - v1.1.1 system.adapter.unifi-protect : unifi-protect - v0.0.12 system.adapter.web : web - v3.4.7 system.adapter.zigbee : zigbee - v1.5.6 -
@lessthanmore mach mal iobroker upload admin nd schau obs dann noch auftritt
-
@sputnik24 Bitte spiele nochmal dein DB-Backup ein, ziehe die aktuelle Version von Github und probiere es nochmal. Für Influx 1.x wurde der Adapter jetzt so angepasst, dass er immer die bestehende Default-Policy bzgl. Retention aktualisiert. D.h. in deinem Fall sollte dann nur "autogen" angepasst werden und auch weiterhin Default bleiben.
-
@excodibur said in Test Adapter influxdb 2.0:
@sputnik24 Bitte spiele nochmal dein DB-Backup ein, ziehe die aktuelle Version von Github und probiere es nochmal. Für Influx 1.x wurde der Adapter jetzt so angepasst, dass er immer die bestehende Default-Policy bzgl. Retention aktualisiert. D.h. in deinem Fall sollte dann nur "autogen" angepasst werden und auch weiterhin Default bleiben.
Ihr seid die Besten! Default policy ist weiterhin autogen, alle Daten sind weiter normal abrufbar und neue werden geschrieben.
Nun kommt der weitaus kompliziertere Part - influxdb auf 2.0 upgraden, läuft bei mir ebenfalls in Docker. Hat das hier schonmal jemand gemacht?
Wie ist das Vorgehen aus Sicht des Adapters?
Adapter stoppen, influxdb upgraden, Adapter-Einstellungen DB-Version auf 2.x ändern, Adapter starten. Wenn die Daten beim influxdb upgrade erfolgreich migriert werden, sollte das unter Erhalt der Daten und retention policy funktionieren? -
@sputnik24 Das würde ich auch gerne wissen.
Habe es eben versucht (proxmox, lxc). Ins WebUI von influx2 komme ich, aber irgendwie waren überall noch config-Dateien, etc. von der 1.x Version.
Im Endeffekt habe ich ein Backup eingespielt und warte jetzt bis eine schöne und ausführliche Anleitung irgendwann mal verfügbar ist
Ansonsten habe ich das Upgrade gemäß dieser Anleitung gemacht: https://docs.influxdata.com/influxdb/v2.0/upgrade/v1-to-v2/automatic-upgrade/#perform-the-upgrade
-
@lessthanmore said in Test Adapter influxdb 2.0:
@sputnik24 Das würde ich auch gerne wissen.
Habe es eben versucht (proxmox, lxc). Ins WebUI von influx2 komme ich, aber irgendwie waren überall noch config-Dateien, etc. von der 1.x Version.
Im Endeffekt habe ich ein Backup eingespielt und warte jetzt bis eine schöne und ausführliche Anleitung irgendwann mal verfügbar istAnsonsten habe ich das Upgrade gemäß dieser Anleitung gemacht: https://docs.influxdata.com/influxdb/v2.0/upgrade/v1-to-v2/automatic-upgrade/#perform-the-upgrade
Für den Docker Container gibt es auch eine Anleitung: https://registry.hub.docker.com/_/influxdb/
Ich hatte gestern meinen bestehenden Container kopiert und wollte es mit der Kopie testen. Hat aber nicht funktioniert und hatte irgendwann keinen Nerv mehr. -
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
-
Es gibt gute und schlecht Neuigkeiten.
Die gute ist, dass ich eine Migration von Influx 1.x nach 2.x mit IOBroker Daten erfolgreich testen konnte und dazu ein paar Sätze in der Adapter-Readme geschrieben habe. Hauptsächlich habe ich diese Schritte verwendet: https://docs.influxdata.com/influxdb/v2.0/upgrade/v1-to-v2/manual-upgrade/#migrate-time-series-data
Die schlechte ist, dass die migrierten Daten nicht mit der letzten Adapter-Version kompatibel waren und ich daher nochmal Anpassungen vornehmen musste, die auch die Datenstruktur in der Influx 2 DB betreffen. Zuvor verwendete der Adapter unter anderem "Tags" für bestimmte Felder, die bei Influx 1 noch "Fields" waren. Das habe ich nun geändert, um die Kompatibilität sicherzustellen und Migrationen überhaupt sinnvoll möglich zu machen. Das bedeutet leider auch, das mit früheren Adapter-Versionen in Influx 2 geschriebene Datensätze vom neuen Adapter (jetzt via Github, oder später als Release) nicht mehr verstanden werden, d.h. nicht weiter verwendet werden können. D.h. hier muss ggf. nochmal mit einer leeren Influx 2 DB (oder einer migrierten Influx 1 DB) gestartet werden.
-
@excodibur Reicht es aus, die Inhalte aus der Datenbank über die influxdb Instanz mit dem Button "Alle Daten in Datenbank löschen" zu löschen oder muss man eine frische Datenbank aufsetzen?
-
@feuersturm Ja, sollte reichen, da der Adapter dabei das ganze Bucket (und alle Measurements darin) löscht.
-
@excodibur War das eigentlich ein Aufruf, die neue github Version zum testen zu installieren?
-
@feuersturm Ja bitte, wollen das dann jetzt mal so langsam richtung Latest bringen
-
@apollon77 @Excodibur
Ich hab vor dem Update "Alle Daten in Datenbank löschen" ausgeführt.
Nach dem Update und beim Start des Adapters waren folgende Errors im Log10 Aug 2021 00:52:44.990 host.ioBrokerTestsystem Restart adapter system.adapter.influxdb.0 because enabled 10 Aug 2021 00:52:44.988 host.ioBrokerTestsystem instance system.adapter.influxdb.0 terminated with code 6 (UNCAUGHT_EXCEPTION) 10 Aug 2021 00:52:44.988 host.ioBrokerTestsystem Caught by controller[0]: at /opt/iobroker/node_modules/@influxdata/influxdb-client/src/impl/node/NodeHttpTransport.ts:111:14 10 Aug 2021 00:52:44.987 host.ioBrokerTestsystem Caught by controller[0]: at at._request (/opt/iobroker/node_modules/@influxdata/influxdb-client/src/impl/node/NodeHttpTransport.ts:242:22) 10 Aug 2021 00:52:44.986 host.ioBrokerTestsystem Caught by controller[0]: at at.requestApi (/opt/iobroker/node_modules/@sentry/node/src/integrations/http.ts:126:10) 10 Aug 2021 00:52:44.986 host.ioBrokerTestsystem Caught by controller[0]: at at.request (http.js:46:10) 10 Aug 2021 00:52:44.985 host.ioBrokerTestsystem Caught by controller[0]: at new ClientRequest (_http_client.js:242:14) 10 Aug 2021 00:52:44.984 host.ioBrokerTestsystem Caught by controller[0]: at ClientRequest.setHeader (_http_outgoing.js:533:3) 10 Aug 2021 00:52:44.983 host.ioBrokerTestsystem Caught by controller[0]: TypeError [ERR_INVALID_CHAR]: Invalid character in header content ["authorization"] 10 Aug 2021 00:52:44.982 host.ioBrokerTestsystem Caught by controller[0]: This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason:10 Aug 2021 00:53:18.449 influxdb.0 (1959) Terminated (UNCAUGHT_EXCEPTION): Without reason 10 Aug 2021 00:53:18.443 influxdb.0 (1959) terminating 10 Aug 2021 00:53:18.417 influxdb.0 (1959) Exception-Code: ERR_INVALID_CHAR: Invalid character in header content ["authorization"] 10 Aug 2021 00:53:18.416 influxdb.0 (1959) TypeError [ERR_INVALID_CHAR]: Invalid character in header content ["authorization"] at ClientRequest.setHeader (_http_outgoing.js:533:3) at new ClientRequest (_http_client.js:242:14) at at.request (http.js:46:10) at at.requestApi (/opt/iobroker/node_modules/@sentry/node/src/integrations/http.ts:126:10) at at._request (/opt/iobroker/node_modules/@influxdata/influxdb-client/src/impl/node/NodeHttpTransport.ts:242:22) at /opt/iobroker/node_modules/@influxdata/influxdb-client/src/impl/node/NodeHttpTransport.ts:111:14 10 Aug 2021 00:53:18.414 influxdb.0 (1959) unhandled promise rejection: Invalid character in header content ["authorization"] 10 Aug 2021 00:53:18.412 influxdb.0 (1959) Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). 10 Aug 2021 00:53:18.241 influxdb.0 (1959) Connecting to InfluxDB 2 10 Aug 2021 00:53:18.239 influxdb.0 (1959) Influx DB Version used: 2.x 10 Aug 2021 00:53:18.238 influxdb.0 (1959) Connecting http://192.168.178.101:8086 ... 10 Aug 2021 00:53:18.235 influxdb.0 (1959) No stored data from last exit found 10 Aug 2021 00:53:18.179 influxdb.0 (1959) starting. Version 2.1.0 in /opt/iobroker/node_modules/iobroker.influxdb, node: v12.22.2, js-controller: 3.3.15Nach dem Update ist der Token in den Einstellungen "kaputt", bzw. enthält irgendwelche Steuerzeichen.
Nachdem ich den Token aus der Influx GUI (welcher sich geändert hat) neu in der Instanz eingetragen hat, ist die Instanz erfolgreich gestartet.
-
@feuersturm Achja ... das hatten wir vergesen zu erwähnen ;-)) Passwort bzw Token wird jetzt verschlüsselt gespeichert und muss dahger einmalig neu eingegeben werden
-
@apollon77 Ah
Irgendwas scheint noch nicht ganz sauber zu funktionieren. Ich lasse den Datenpunkt proxmox.0.node_pve.cpu in die Datenbank speichern. In Influx wird hier folgendes angezeigt:
In ioBroker wird mir der Wert vom Datenpunkt korrekt angezeigt:
Das sind die Einstellungen vom Datenpunkt
Influx Version
proxmox@DatenbankenTest:~$ influx version Influx CLI 2.0.7 (git: 2a45f0c037) build_date: 2021-06-04T19:17:40ZWelche weiteren Infos helfen euch weiter?
Edit:
proxmox@DatenbankenTest:~$ influx query 'from(bucket:"iobroker") |> range(start:-10m) |> filter(fn: (r) => r._measurement == "proxmox.0.node_pve.cpu")' Result: _result Table: keys: [_start, _stop, _field, _measurement] _start:time _stop:time _field:string _measurement:string _time:time _value:bool ------------------------------ ------------------------------ ---------------------- ---------------------- ------------------------------ ------------ 2021-08-09T23:41:06.058022993Z 2021-08-09T23:51:06.058022993Z ack proxmox.0.node_pve.cpu 2021-08-09T23:42:01.093000000Z true 2021-08-09T23:41:06.058022993Z 2021-08-09T23:51:06.058022993Z ack proxmox.0.node_pve.cpu 2021-08-09T23:43:01.075000000Z true 2021-08-09T23:41:06.058022993Z 2021-08-09T23:51:06.058022993Z ack proxmox.0.node_pve.cpu 2021-08-09T23:44:01.155000000Z true 2021-08-09T23:41:06.058022993Z 2021-08-09T23:51:06.058022993Z ack proxmox.0.node_pve.cpu 2021-08-09T23:45:01.086000000Z true 2021-08-09T23:41:06.058022993Z 2021-08-09T23:51:06.058022993Z ack proxmox.0.node_pve.cpu 2021-08-09T23:46:01.129000000Z true 2021-08-09T23:41:06.058022993Z 2021-08-09T23:51:06.058022993Z ack proxmox.0.node_pve.cpu 2021-08-09T23:47:01.082000000Z true 2021-08-09T23:41:06.058022993Z 2021-08-09T23:51:06.058022993Z ack proxmox.0.node_pve.cpu 2021-08-09T23:48:01.104000000Z true 2021-08-09T23:41:06.058022993Z 2021-08-09T23:51:06.058022993Z ack proxmox.0.node_pve.cpu 2021-08-09T23:49:01.089000000Z true 2021-08-09T23:41:06.058022993Z 2021-08-09T23:51:06.058022993Z ack proxmox.0.node_pve.cpu 2021-08-09T23:50:01.119000000Z true 2021-08-09T23:41:06.058022993Z 2021-08-09T23:51:06.058022993Z ack proxmox.0.node_pve.cpu 2021-08-09T23:51:01.088000000Z true Table: keys: [_start, _stop, _field, _measurement] _start:time _stop:time _field:string _measurement:string _time:time _value:string ------------------------------ ------------------------------ ---------------------- ---------------------- ------------------------------ ------------------------ 2021-08-09T23:41:06.058022993Z 2021-08-09T23:51:06.058022993Z from proxmox.0.node_pve.cpu 2021-08-09T23:42:01.093000000Z system.adapter.proxmox.0 2021-08-09T23:41:06.058022993Z 2021-08-09T23:51:06.058022993Z from proxmox.0.node_pve.cpu 2021-08-09T23:43:01.075000000Z system.adapter.proxmox.0 2021-08-09T23:41:06.058022993Z 2021-08-09T23:51:06.058022993Z from proxmox.0.node_pve.cpu 2021-08-09T23:44:01.155000000Z system.adapter.proxmox.0 2021-08-09T23:41:06.058022993Z 2021-08-09T23:51:06.058022993Z from proxmox.0.node_pve.cpu 2021-08-09T23:45:01.086000000Z system.adapter.proxmox.0 2021-08-09T23:41:06.058022993Z 2021-08-09T23:51:06.058022993Z from proxmox.0.node_pve.cpu 2021-08-09T23:46:01.129000000Z system.adapter.proxmox.0 2021-08-09T23:41:06.058022993Z 2021-08-09T23:51:06.058022993Z from proxmox.0.node_pve.cpu 2021-08-09T23:47:01.082000000Z system.adapter.proxmox.0 2021-08-09T23:41:06.058022993Z 2021-08-09T23:51:06.058022993Z from proxmox.0.node_pve.cpu 2021-08-09T23:48:01.104000000Z system.adapter.proxmox.0 2021-08-09T23:41:06.058022993Z 2021-08-09T23:51:06.058022993Z from proxmox.0.node_pve.cpu 2021-08-09T23:49:01.089000000Z system.adapter.proxmox.0 2021-08-09T23:41:06.058022993Z 2021-08-09T23:51:06.058022993Z from proxmox.0.node_pve.cpu 2021-08-09T23:50:01.119000000Z system.adapter.proxmox.0 2021-08-09T23:41:06.058022993Z 2021-08-09T23:51:06.058022993Z from proxmox.0.node_pve.cpu 2021-08-09T23:51:01.088000000Z system.adapter.proxmox.0 Table: keys: [_start, _stop, _field, _measurement] _start:time _stop:time _field:string _measurement:string _time:time _value:float ------------------------------ ------------------------------ ---------------------- ---------------------- ------------------------------ ---------------------------- 2021-08-09T23:41:06.058022993Z 2021-08-09T23:51:06.058022993Z q proxmox.0.node_pve.cpu 2021-08-09T23:42:01.093000000Z 0 2021-08-09T23:41:06.058022993Z 2021-08-09T23:51:06.058022993Z q proxmox.0.node_pve.cpu 2021-08-09T23:43:01.075000000Z 0 2021-08-09T23:41:06.058022993Z 2021-08-09T23:51:06.058022993Z q proxmox.0.node_pve.cpu 2021-08-09T23:44:01.155000000Z 0 2021-08-09T23:41:06.058022993Z 2021-08-09T23:51:06.058022993Z q proxmox.0.node_pve.cpu 2021-08-09T23:45:01.086000000Z 0 2021-08-09T23:41:06.058022993Z 2021-08-09T23:51:06.058022993Z q proxmox.0.node_pve.cpu 2021-08-09T23:46:01.129000000Z 0 2021-08-09T23:41:06.058022993Z 2021-08-09T23:51:06.058022993Z q proxmox.0.node_pve.cpu 2021-08-09T23:47:01.082000000Z 0 2021-08-09T23:41:06.058022993Z 2021-08-09T23:51:06.058022993Z q proxmox.0.node_pve.cpu 2021-08-09T23:48:01.104000000Z 0 2021-08-09T23:41:06.058022993Z 2021-08-09T23:51:06.058022993Z q proxmox.0.node_pve.cpu 2021-08-09T23:49:01.089000000Z 0 2021-08-09T23:41:06.058022993Z 2021-08-09T23:51:06.058022993Z q proxmox.0.node_pve.cpu 2021-08-09T23:50:01.119000000Z 0 2021-08-09T23:41:06.058022993Z 2021-08-09T23:51:06.058022993Z q proxmox.0.node_pve.cpu 2021-08-09T23:51:01.088000000Z 0 Table: keys: [_start, _stop, _field, _measurement] _start:time _stop:time _field:string _measurement:string _time:time _value:float ------------------------------ ------------------------------ ---------------------- ---------------------- ------------------------------ ---------------------------- 2021-08-09T23:41:06.058022993Z 2021-08-09T23:51:06.058022993Z value proxmox.0.node_pve.cpu 2021-08-09T23:42:01.093000000Z 18.98 2021-08-09T23:41:06.058022993Z 2021-08-09T23:51:06.058022993Z value proxmox.0.node_pve.cpu 2021-08-09T23:43:01.075000000Z 18.47 2021-08-09T23:41:06.058022993Z 2021-08-09T23:51:06.058022993Z value proxmox.0.node_pve.cpu 2021-08-09T23:44:01.155000000Z 18.68 2021-08-09T23:41:06.058022993Z 2021-08-09T23:51:06.058022993Z value proxmox.0.node_pve.cpu 2021-08-09T23:45:01.086000000Z 16.12 2021-08-09T23:41:06.058022993Z 2021-08-09T23:51:06.058022993Z value proxmox.0.node_pve.cpu 2021-08-09T23:46:01.129000000Z 17.03 2021-08-09T23:41:06.058022993Z 2021-08-09T23:51:06.058022993Z value proxmox.0.node_pve.cpu 2021-08-09T23:47:01.082000000Z 16.98 2021-08-09T23:41:06.058022993Z 2021-08-09T23:51:06.058022993Z value proxmox.0.node_pve.cpu 2021-08-09T23:48:01.104000000Z 16.77 2021-08-09T23:41:06.058022993Z 2021-08-09T23:51:06.058022993Z value proxmox.0.node_pve.cpu 2021-08-09T23:49:01.089000000Z 18.57 2021-08-09T23:41:06.058022993Z 2021-08-09T23:51:06.058022993Z value proxmox.0.node_pve.cpu 2021-08-09T23:50:01.119000000Z 20.2 2021-08-09T23:41:06.058022993Z 2021-08-09T23:51:06.058022993Z value proxmox.0.node_pve.cpu 2021-08-09T23:51:01.088000000Z 21.49 -
@feuersturm Ich kenne dein Query-Tool nicht, aber kannst du dort die mean-Funktion auf das value-Feld beschränken? ack ist Boolean und from String, darauf wird die mean-Funktion sehr wahrscheinlich solche Fehler werfen. Im Adapter-Code wird die Funktion immer nur auf das value-Feld ausgeführt und dort z.B. bei boolean Werten ausgelassen, um solche Fehler nicht zu produzieren.
Die letzte Query kannst du übersichtlicher gestalten, indem du noch
|> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value")anhängst.
