NEWS
Test Adapter influxdb 2.0
-
@apollon77 said in Test Adapter influxdb 2.0:
1.) Offtopic blöd, schiebs bitte in den richtigen Thread
2.) Was hab ich mit zigbee zu tun?Du hast sowas von Recht
Das Off-Topic ist Zustande gekommen, weil ich Dich mit Asgothian verwechselt habe, sorry! -
Hallo zusammen,
irgendwie bekomme ich keine Zugriffsrechte auf meine InfluxDB.
Habe Adapter installiert, Server und Organisation eingeben. Einen Custom Token in der InfluxDB generiert, der lese und schreibrechte für den iobroker Bucket hat.
Nun bekomme ich aber den Fehler:
Error: No organizations exists or the token do not have proper permissions. Please check the token (see Readme for Tipps)!Habe schon mit verschiedenen Token probiert. Immer der gleiche Fehler
Jemand ne Idee? -
@michisa86888 readme vom adapter lesen? Nimm erstmal den Admin Token. Mehr Details da
-
@michisa86888 sagte in Test Adapter influxdb 2.0:
Habe schon mit verschiedenen Token probiert. Immer der gleiche Fehler
Jemand ne Idee?Du benötigst, wenn du nicht den admin Token nimmst, mindestens einen „All Access Token“. Read/Write reicht nicht aus.
Dieser All Access Token funktioniert dann für ALLE Buckets dieser Organization.
-
@marc-berg
Okay, habe ich gestern Abend probiert einen zu generieren. Da kam irgendeine Fehlermeldung. Bin aber erst wieder Montag zuhause.
Das mit dem Admin token habe ich irgendwo gelesen. Nur finde bzw. habe ich den admin token nicht? Kann ich den irgendwo in Influx bzw. über Konsole abfragen? -
@michisa86888 sagte in Test Adapter influxdb 2.0:
@marc-berg
Okay, habe ich gestern Abend probiert einen zu generieren. Da kam irgendeine Fehlermeldung. Bin aber erst wieder Montag zuhause.
Das mit dem Admin token habe ich irgendwo gelesen. Nur finde bzw. habe ich den admin token nicht? Kann ich den irgendwo in Influx bzw. über Konsole abfragen?influx auth list --json
Es sollte der erste sein. Du kannst ihn daran erkennen, dass in den Permissions kein "orgs" enthalten ist. Mit diesem Token hast du Rechte auf alle Organizations und muss auch benutzt werden, um ein Backup/Restore zu machen.
-
Auch wenn der Thread schon etwas älter ist...
Ich stand vor ein paar Wochen vor dem selben Problem beim Umstieg von InfluxDB 1.8.x auf 2.7.Wollte meine 1,6GB Datenbank des IOBrokers nicht einfach wegschmeißen, wollte mir aber auch noch keine Gedanken über ein Downsampling machen. Und irgendwie kam es mir immer komisch vor, dass der IOBroker Influx-Adapter die "Meta-Infos" als Fields speicherte und nicht als Tags. In der Doku der Influx stand auch, dass sowas besser in Tags aufgehoben sei wegen Geschwindigkeit, Speicherplatz, ...
Also mußte ein kleines Bash-Script her, dass die alten Daten in eine neue DB kopiert und dabei die 3 Fields ack, q und from in Tags umwandelt/schreibt. Parallel lief die neue DB schon und wurde parallel auch fleißig vom IOBroker weiter befüllt.
Ich bin nun wahrlich kein Programmierer und dementsprechend ist das Script bestimmt auch für Profis zum Haare raufen, aber es tut was es soll...
Zum Script:
- Es ist nicht wirklich parametrierbar gemacht, d.h. der alte und der neue DB-name stehen des öfteren in den einzelnen Zeilen. Bei mir waren es alt: iobroker/global und neu: iobroker2/global. Wer es anders benötigt muß es anpassen...
- Man braucht die Influx-cli und sie muß konfiguriert sein (so dass man nicht immer Token und Org mit angeben muß)
- Das Script arbeitet immer einzelne Batches ab, deren Größe ist oben im Script anpassbar. Solange die Daten relativ kontinuierlich in der DB sind gibt es kein Problem, ich hatte einige Measurements, in denen ich 15 Minuten-Werte meiner alten Wetterstation hatte und dann seit 1,5 Jahren mit einer neuen Wetterstation alle X Sekunden einen Wert. Da mußte ich dann die Batch-Größe stark runterschrauben...
- Vor dem Abarbeiten jedes neuen Batches prüft das Script, ob noch genug Arbeitsspeicher vorhanden ist (700MB war bei mir ein guter Wert und der steht in der "while" Schleife in Zeile 60). Wenn nicht wartet es 10 Sekunden und testet dann erneut, bis irgendwann wieder genug vorhanden ist...
- Wenn man das Script mal abbricht, fängt es wieder von vorne mit dem ersten verfügbaren Measurement an. In den Fällen habe ich dann vor dem Neustart des Scripts die übertragenen Daten geprüft und die schon abgearbeiteten Measurements aus der alten DB gelöscht
- Wenn einem Datenpunkt der alten DB mal eins der 3 Fields/Tags fehlt wird für q=0 gesetzt, für ack=false und für from=manual (ich hatte einige Werte mal manuell "nachgetragen" ohne die Fields auch zu schreiben...)
Nach dem Umkopieren war die DB dann nicht mehr 1,6GB groß sondern nur noch 600MB. Beim Arbeitsspeicher hat es leider nichts gebracht, der ist seit dem Umstieg von 1.8 auf 2.7 von ca. 1GB auf ca. 1,5GB für die Influx gestiegen...
Hier das Script:
IOBroker_copy_dbGruß
Hefo -
@hefo hey, super! Das ist cool. Wie hast Du den InfluxDB Adater denn für InfluxDB 2 eingestellt das das mit den tags so passt? (So noch vllt als ergänzung zu oben)
-
@apollon77 Einziger Unterschied zu einer Konfiguration des Influx Adapters für eine InfluxDB 2 mit Fields war eigentlich nur der Haken auf der Experten-Seite der Adapter-Config:
Man muß / sollte nur etwas auf die Reihenfolge achten, um ein Mischmasch von Fields und Tags in einer DB zu vermeiden.
Bzw. wollte ich es nicht drauf ankommen lassen herauszufinden, ob der Adapter beim Setzen des Hakens meckert, wenn schon Daten ohne Tags in der DB sind. Das gilt wahrscheinlich vor allem für Nutzer, die schon auf V2.x umgestiegen sind, aber bei den Fields geblieben sind.Vor setzen des Hakens bei "Verwende Tags..." sollte man die Influx auf 2.x (2.7 in meinem Fall) migriert haben. Dabei werden alle Datenbanken mit migriert. Bei mir gab es etwas Probleme durch den komischen Aufbau/Inhalt des Debian-Pakets von Influx, so dass im ersten Versuch alles in meinem User-home landete, beim zweiten Mal dann in /var/lib/influx/.influx... Das konnte ich dann aber ganz am Ende noch auf Dateisystem-Ebene hin- und herschieben...
Wenn man dann auf 2.x ist, einen Token für den IOBroker angelegt hat und der IOBroker wieder/weiter in seine DB schreibt, legt man eine neue DB an (in meinem Fall die iobroker2/global). Dem IOBroker-User dann auch Zugriff auf die neue DB gewähren!
Dann Influx-Adapter stoppen, auf der "DB Settings"-Seite des Adapters die neue DB angeben und auf der "Experteneinstellungen" Seite den Haken setzen.
Dann den Adapter wieder starten.
Mehr habe ich in Hinsicht "Konfiguration" nicht gemacht.Dass ich das "/global" mitschleppe hängt eigendlich nur daran, dass ich meine ganzen Grafana-Dashboards nicht über den Haufen schmeißen wollte, bzw. mir den Anpassungsaufwand ersparen wollte. Ein neues / geändertes DBRP-Mapping in der Influx hätte es wohl auch getan, so fand ich es aber übersichtlicher...
Für diejenigen, die schon mehr als eine Datenbank des Influx-Adapters haben, z.B. weil sie beim Umstieg von 1.8 auf 2.x eine Neue angelegt haben: Auch hier kann man das Script nehmen, dann muß man es halt zwei Mal anwenden. Einmal um die 1.8er Daten umzuscheffeln, einmal um die 2.x umzuscheffeln.
Wichtig in dem Zusammenhang: Das Script geht davon aus, dass keine Tags in der DB vorhanden sind. Was es macht, falls doch welche drin sind? Keine Ahnung, ich habe es nicht ausprobiert. Im besten Fall meckert es nicht und schreibt nur, da es keine passenden Fields findet, in alle Tags die "Manuellen" Werte (s.o.) rein. Die "richtigen" Tags würden dann überschrieben.Gruß
Hefo -
Hallo zusammen, ich hoffe das ich hier Hilfe finde.
Nachdem die SD-Karte meines Raspberrys dein Geist aufgegeben hat, habe ich mein System neu aufgesetzt. Alles funktioniert soweit bis auf den InfluxDB adapter.Folgendes Problem:
Wenn ich in der Konfigurationsoberfläche meine Daten für meine InfluxDB2 Instanz eingebe, sprich organisation, token und db name und auf Verbindung testen drücke, kommt die Meldung das alles in Ordnung ist. Wenn ich jedoch auf Speichern und Schließen drücke funktioniert dies nicht und im Log bekomme ich die Fehlermeldung "Error: {"code":"unauthorized","message":"unauthorized access"}". Wenn ich von der Konfigurationsseite wegnavigiere bekomme ich eine Meldung das einige Daten nicht gespeichert wurden. Ich bekomme keine Verbindung zu meiner Datenbank hin. Interessant ist das der Backitup adapter den Token annimmt und auch das backup erfolgreich eingespielt hat.Ich nutze die Adpaterversion V3.2.0 und Influxdb V2.7.1
Ich sitze nun schon seit 2 Tagen an diesem Problem und komme einfach nicht weiter und ich hoffe das ihr mir helfen könnt.
-
@alex-konradi sagte in Test Adapter influxdb 2.0:
Ich nutze die Adpaterversion V3.2.0 und Influxdb V2.7.1
Ich sitze nun schon seit 2 Tagen an diesem Problem und komme einfach nicht weiter und ich hoffe das ihr mir helfen könnt.Ich vermute, dass du von einem Bug betroffen bist, der in einer (Beta-) Version des ADMIN Adapters auftritt. Installiere den Admin Adapter in einer Version <= 6.8.3, dann funktioniert auch das Speichern.
-
@marc-berg
Perfekt das war die Lösung! Vielen Dank! -
Hi zusammen,
erstmal vielen Dank für diesen coolen influxDB Adapter!!! Ich hoffe ich bin in diesem Thread richtig mit meinem Anliegen.
Ich habe meine InfluxDB 2 schon vor einiger Zeit aufgesetzt und schreibe seitdem insb. Temperaturwerte vom KNX bus über telegraf in ein bucket. Auch von IObroker schreibe ich diverse Werte (z.B. Energie, PV, Wallbox, etc..) – jedoch in ein separates bucket.
Nun habe ich mir vorgenommen, bei der Datenbank etwas aufzuräumen und eine sinnvolle Struktur reinzubringen (z.b. mehrere Buckets mit unterschiedlicher retention für langzeit-archivierung), dafür aber alles strukturiert in ein „master-bucket“. Soweit so gut – wichtig scheint das vernünftige Nutzen von fields und tags.
Bevor jemand fragt: Nein, ich hab mir das Konzept aber noch nicht überlegt, wird ich aber
Beispielweise möchte ich dem Zählerstand, der Momentanleistung, Wallbox Leistung, etc.. das tag "energie" oder etwas in der Richtung mitgeben.Nun zur Frage: Wie kann ich fields und tags mit dem Adapter richtig Nutzen? Das Häkchen „Tags statt Felder“ habe ich schon entdeckt und auch das Alias Feld in der Objekt-Konfiguration. Wenn ich das benutze, wird dieses Alias als „_measurement“ gesetzt und als „_field“ der Wert (value).
Gibt es irgendeine Möglichkeit, andere Tags zu vergeben, z.B. über eine Syntax in diesem alias Feld analog Influx CLI ?
Wenn nicht, weiß jemand ob das Feature bereits geplant ist und ob es einen effizienten Workaround gibt?Vielen Dank für Eure Inputs!
-
@kaffeschluerfer sagte in Test Adapter influxdb 2.0:
Gibt es irgendeine Möglichkeit, andere Tags zu vergeben, z.B. über eine Syntax in diesem alias Feld analog Influx CLI ?
Nein, gibt es nicht.
Wenn nicht, weiß jemand ob das Feature bereits geplant ist und ob es einen effizienten Workaround gibt?
Es gibt einen alten Feature Request in diese Richtung: https://github.com/ioBroker/ioBroker.influxdb/issues/32
Workaround: Daten selbst schreiben per Script/Node Red/Blockly.