NEWS
Test Adapter influxdb 2.0
-
Danke für deine Testversuche!
Es scheint als wäre der "Verbindung testen" Button in der Admin 5 Oberfläche noch buggy. Bei mir funktioniert der Verbindungstest dort aktuell leider auch noch nicht, obwohl die richtigen Verbindungsdaten eingetragen sind. Wenn man die Einstellungen speichert, sollte der Adapter sich aber erfolgreich verbinden können. In der alten Admin 4 Oberfläche funktioniert "Verbindung testen" wie erwartet.
Zudem ist die Flexibilität beim Usermanagement für Influx 2.0 (zumindest mit dem aktuellen Adapter-Code) noch nicht ganz ausgereift: Wenn es um Zugangsdaten geht,
-
am Besten (aktuell) die Organisation auswählen, unter der die Datenbank (in Influx 2 "Bucket") liegen soll. Verfügbare Organisationen kann man via Influx CLI auch per influx org list sehen. Das Anlegen und Verwenden weiterer Organisation müsste ebenfalls gehen.
-
als Auth-Token funktioniert im Moment fehlerfrei nur das bereits per Default existierende Super-Admin-Token, welches nicht mit der Organisation verknüpft ist. Alle Tokens kann man mit influx auth list sehen. Dort den (meistens ersten) Eintrag mit der längsten Berechtigungsliste nehmen.
- Versucht man es stattdessen mit eigens angelegten Nutzern und Tokens, hängt anscheinend in den Berechtigungen immer die ID der Organisation mit drin, was prinzipiell zwecks Zugriffsbeschränkung auf Influx-Ebene gut ist, aber dann funktioniert (zumindest aktuell) beim Verbindungsversuch das Abrufen der Organisationsdaten nicht um man kriegt eine Fehlermeldung TypeError: Cannot read property 'id' of undefined.
Beide Probleme sollten natürlich noch behoben werden, sobald Ingo oder ich die Zeit finden.
@excodibur sagte in Test Adapter influxdb 2.0:
Bei mir funktioniert der Verbindungstest dort aktuell leider auch noch nicht, obwohl die richtigen Verbindungsdaten eingetragen sind. Wenn man die Einstellungen speichert, sollte der Adapter sich aber erfolgreich verbinden können. In der alten Admin 4 Oberfläche funktioniert "Verbindung testen" wie erwartet.
Danke für deine Rückmeldung. Ist das hier ein Thema für Admin5 oder für den influx Adapter?
-
-
@excodibur sagte in Test Adapter influxdb 2.0:
Bei mir funktioniert der Verbindungstest dort aktuell leider auch noch nicht, obwohl die richtigen Verbindungsdaten eingetragen sind. Wenn man die Einstellungen speichert, sollte der Adapter sich aber erfolgreich verbinden können. In der alten Admin 4 Oberfläche funktioniert "Verbindung testen" wie erwartet.
Danke für deine Rückmeldung. Ist das hier ein Thema für Admin5 oder für den influx Adapter?
@feuersturm
Nee definitiv liegt es am influxdb adapter. Ich sehe auch die Code-Stelle an der es hängt.Idealerweise sollte wir alle Funde mit Issue direkt im Influx-Adapter Github Repo tracken, sodass Ingo oder ich direkt dran arbeiten können. In diesem Fall würde ich das aber schon selbst mitnehmen.
-
@feuersturm
Nee definitiv liegt es am influxdb adapter. Ich sehe auch die Code-Stelle an der es hängt.Idealerweise sollte wir alle Funde mit Issue direkt im Influx-Adapter Github Repo tracken, sodass Ingo oder ich direkt dran arbeiten können. In diesem Fall würde ich das aber schon selbst mitnehmen.
@excodibur issues anlegen ist kein Problem. Bin noch influx Anfänger, daher wollte ich erstmal hier fragen ob es ein Konfigurationsproblem bei mir ist oder ein Bug.
-
Ich habe übrigens auch den Admin-Adapter 5 (5.1.9) im Einsatz und den neuen InfluxDB Adapter (2.0.0) und kann über den Button "Verbindung testen" erfolgreich eine Verbindung zu meiner InfluxDB 2.0 herstellen. Das Popup mit dem Test-Ergebnis ist zwar optisch etwas "mager" aber es zeigt immerhin eine erfolgreiche Verbindung an ("OK").
P.S. node.js 14.17.2
-
Ich habe übrigens auch den Admin-Adapter 5 (5.1.9) im Einsatz und den neuen InfluxDB Adapter (2.0.0) und kann über den Button "Verbindung testen" erfolgreich eine Verbindung zu meiner InfluxDB 2.0 herstellen. Das Popup mit dem Test-Ergebnis ist zwar optisch etwas "mager" aber es zeigt immerhin eine erfolgreiche Verbindung an ("OK").
P.S. node.js 14.17.2
-
@maeb3 Hi, hast du die neue React UI in Betrieb oder noch die alte Ansicht?
-
@feuersturm Die alte Ansicht
@maeb3 ok. Der Fehler tritt nur mit der neuen Ui auf.
-
@Excodibur Das Löschen der Daten in der Datenbank funktioniert auch nicht: https://github.com/ioBroker/ioBroker.influxdb/issues/119
-
@Excodibur Das Löschen der Daten in der Datenbank funktioniert auch nicht: https://github.com/ioBroker/ioBroker.influxdb/issues/119
@feuersturm Wi ebeschrieben ist das eher ein "Neues Admin 5 Feature was aktuell nur sql kann"
Hab Dein Issue angepasst, würde ich aber eher im zweiten Schritt sehen -
@maeb3 ok. Der Fehler tritt nur mit der neuen Ui auf.
@apollon77 oder @Excodibur
wird mit dem neuen Adapter das Problem mit der Vorhaltezeit gelöst?
https://forum.iobroker.net/topic/43128/influx-adapter-vorhaltezeit-bug?_=1625283496188
https://github.com/ioBroker/ioBroker.influxdb/issues/29 -
@apollon77 oder @Excodibur
wird mit dem neuen Adapter das Problem mit der Vorhaltezeit gelöst?
https://forum.iobroker.net/topic/43128/influx-adapter-vorhaltezeit-bug?_=1625283496188
https://github.com/ioBroker/ioBroker.influxdb/issues/29@stenmic ich denke diese Frage geht eher an @apollon77 oder @Excodibur
-
@stenmic ich denke diese Frage geht eher an @apollon77 oder @Excodibur
-
@feuersturm upps, da hast du recht
@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 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.
@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.
-
@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.
-
@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.
@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
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
-
@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
@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 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?
@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
-
@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
@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 -
@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@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.
Support us
537
Online32.4k
Users81.4k
Topics1.3m
Posts