Test Adapter influxdb 2.0
-
@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.
-
@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
-
@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
closed Prevent Admin5 Error #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 -
@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
-
@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.
-
@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
Danke für diese Erklärung. Habe mich die ganze Zeit gefragt für was ein Wechsel auf 2.0 lohnenswert wäre?
Gibt es noch weitere pros und contra?
CPU Last oder sonstiges. -
@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?
-
@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 -
@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.
