NEWS
Test Adapter influxdb 2.0
-
@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 trueDa 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 1h0m0sIn 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?
@excodibur Wenn ich show retention policies ausführe, erhalte ich:
show retention policies name duration shardGroupDuration replicaN default ---- -------- ------------------ -------- ------- autogen 0s 168h0m0s 1 trueglobal fehlt mir also. Zu deiner letzten Frage: Ich hatte vor dem Update des Adapters (aktuell bin ich wieder auf 1.9.2) manuell weitere Datenpunkte zum Logging in influxdb hinzugefügt und deren Vorhaltezeit auf einen Tag gesetzt, da ich eigentlich nur am aktuellen Wert interessiert bin für Grafana.
Der Punkt ist, selbst wenn ich auf Adapter-Version 2.0 bin, das influxdb Backup einspiele und dann Adapter starte, werden alle Werte immer gelöscht.
-
@excodibur Wenn ich show retention policies ausführe, erhalte ich:
show retention policies name duration shardGroupDuration replicaN default ---- -------- ------------------ -------- ------- autogen 0s 168h0m0s 1 trueglobal fehlt mir also. Zu deiner letzten Frage: Ich hatte vor dem Update des Adapters (aktuell bin ich wieder auf 1.9.2) manuell weitere Datenpunkte zum Logging in influxdb hinzugefügt und deren Vorhaltezeit auf einen Tag gesetzt, da ich eigentlich nur am aktuellen Wert interessiert bin für Grafana.
Der Punkt ist, selbst wenn ich auf Adapter-Version 2.0 bin, das influxdb Backup einspiele und dann Adapter starte, werden alle Werte immer gelöscht.
@sputnik24 Verstehe ich das richtig, dass deiner Datenbank nur vor dem Starten der neuen Adapter-Version die "global" policy fehlt? Nachdem die neue Adapter-Version gestartet wird, sollte diese angelegt werden und in deiner DB neben "autogen" als default sichtbar sein. Die Logs deines Influx-Servers zeigen ja, das das Kommando zum Erstellen der Policy empfangen wurde (Zeile 2). D.h. sie müsste danach da sein.
Sollte dem so sein, vermute ich, dass es an dem Wechsel der default-Policy liegt. In dem Fall sollten die vorigen Daten nicht weg sein, sondern nur mit den regulären DB-Queries nicht mehr angezeigt werden. Gibt man die alte Policy z.B. beim SELECT Query mit an, sollten die Daten wieder sichtbar sein. Siehe auch https://docs.influxdata.com/influxdb/v1.7/troubleshooting/frequently-asked-questions/#why-am-i-missing-data-after-creating-a-new-default-retention-policy für mehr Infos dazu.
Siehst du die alten Daten so nach dem Start der neuen Adapter-Version so direkt in der DB noch?
-
@sputnik24 Verstehe ich das richtig, dass deiner Datenbank nur vor dem Starten der neuen Adapter-Version die "global" policy fehlt? Nachdem die neue Adapter-Version gestartet wird, sollte diese angelegt werden und in deiner DB neben "autogen" als default sichtbar sein. Die Logs deines Influx-Servers zeigen ja, das das Kommando zum Erstellen der Policy empfangen wurde (Zeile 2). D.h. sie müsste danach da sein.
Sollte dem so sein, vermute ich, dass es an dem Wechsel der default-Policy liegt. In dem Fall sollten die vorigen Daten nicht weg sein, sondern nur mit den regulären DB-Queries nicht mehr angezeigt werden. Gibt man die alte Policy z.B. beim SELECT Query mit an, sollten die Daten wieder sichtbar sein. Siehe auch https://docs.influxdata.com/influxdb/v1.7/troubleshooting/frequently-asked-questions/#why-am-i-missing-data-after-creating-a-new-default-retention-policy für mehr Infos dazu.
Siehst du die alten Daten so nach dem Start der neuen Adapter-Version so direkt in der DB noch?
@excodibur Schau ich mir morgen in Ruhe an, aber klingt plausibel. Ich bin aktuell ja wieder auf 1.9.2 und möchte heut nicht mehr am System basteln.
Blöde Frage: Krieg ich die Daten über die default-Policy wieder angezeigt oder zur default-Policy portiert?
-
@excodibur Schau ich mir morgen in Ruhe an, aber klingt plausibel. Ich bin aktuell ja wieder auf 1.9.2 und möchte heut nicht mehr am System basteln.
Blöde Frage: Krieg ich die Daten über die default-Policy wieder angezeigt oder zur default-Policy portiert?
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" -
@excodibur Schau ich mir morgen in Ruhe an, aber klingt plausibel. Ich bin aktuell ja wieder auf 1.9.2 und möchte heut nicht mehr am System basteln.
Blöde Frage: Krieg ich die Daten über die default-Policy wieder angezeigt oder zur default-Policy portiert?
@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.
-
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 -
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.
@lessthanmore mach mal iobroker upload admin nd schau obs dann noch auftritt
-
@excodibur Schau ich mir morgen in Ruhe an, aber klingt plausibel. Ich bin aktuell ja wieder auf 1.9.2 und möchte heut nicht mehr am System basteln.
Blöde Frage: Krieg ich die Daten über die default-Policy wieder angezeigt oder zur default-Policy portiert?
@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.
-
@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? -
@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
-
@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
@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
Beitrag hat geholfen? Votet rechts unten im Beitrag :-) https://paypal.me/Apollon77 / https://github.com/sponsors/Apollon77
- Debug-Log für Instanz einschalten? Admin -> Instanzen -> Expertenmodus -> Instanz aufklappen - Loglevel ändern
- Logfiles auf Platte /opt/iobroker/log/… nutzen, Admin schneidet Zeilen ab
-
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.
-
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?
-
@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?
-
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 War das eigentlich ein Aufruf, die neue github Version zum testen zu installieren?
-
@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
Beitrag hat geholfen? Votet rechts unten im Beitrag :-) https://paypal.me/Apollon77 / https://github.com/sponsors/Apollon77
- Debug-Log für Instanz einschalten? Admin -> Instanzen -> Expertenmodus -> Instanz aufklappen - Loglevel ändern
- Logfiles auf Platte /opt/iobroker/log/… nutzen, Admin schneidet Zeilen ab
-
@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.
Support us
579
Online32.4k
Benutzer81.4k
Themen1.3m
Beiträge