9
Daten zwischen InfluxDBs kopieren
Hallo zusammen,
wir haben hier im Haus eine Solaranlage von Enpal. Sie wurde im März in Betrieb genommen und funktioniert grundsätzlich wunderbar.
Die Steuerungseinheit der Anlage bringt unter anderem eine eigene kleine InfluxDB v2 mit, in der alle Messwerte aus den verschiedensten Quellen für drei Monate gespeichert werden. Wofür genau sie diese Datenbank benötigen, weiß ich nicht, ist aber auch egal.
Der Punkt ist, dass man API Token, Bucket und Organization auf dem zugehörigen Webportal der Anlage auslesen kann. Es ist also möglich, die Datenbank abzufragen und zum Beispiel eine eigene Grafana-Instanz anzubinden.
Ich würde gerne, bevor die ersten Daten gelöscht werden, diese in eine eigne InfluxDB kopieren, in der ich die Messwerte über mehrere Jahre aufbewahren kann. Einen wirklichen Use Case habe ich zwar noch nicht, aber jeder fängt mal an, und irgendwann werde ich bestimmt froh sein, das gemacht zu haben. Auch bietet mir das die Möglichkeit, mich ein bisschen mit Themen wie Grafana und eben der InfluxDB zu beschäftigen, wenn ich mal Zeit und Lust dazu habe.
Ich habe noch einen alten Raspberry Pi (müsste ein Pi 3B+ sein) in der Ecke liegen, der seit knapp zehn Jahren nicht mehr in Betrieb war. Dem habe ich jetzt eine neue Speicherkarte spendiert, denn mit der alten war die Geschwindigkeit so unterirdisch, dass das Teil völlig unbrauchbar war. Jetzt lässt sich die Geschwindigkeit zumindest mit einem Glas Martini zwischenzeitlich irgendwie ertragen.
Ich habe also einen quasi fertig eingerichteten Pi. Eine InfluxDB kriege ich da auch noch irgendwie drauf, dann sollte ich erst mal alles haben. Und trotzdem werden Linux und ich in diesem Leben keine Freunde mehr, aber das nur am Rande.
Die Herausforderung ist jetzt: Wie kriege ich die Daten aus der Enpal-Datenbank in meine eigene? Ich habe absolut null Erfahrung mit der Software und weiß daher nicht, welche Optionen auf dem Tisch liegen. Es gibt wohl einen Weg, eine Synchronisierung einzurichten, was der präferierte Weg wäre, aber dafür bräuchte ich wohl auch einen User mit Schreibrechten in der Quell-Datenbank. Ich habe aber wie gesagt nur den API Token mit Lesezugriff. Besser als nichts.
Könnt ihr mir sagen, welche Möglichkeiten ich habe? Der Abgleich muss nicht live passieren. Ich dachte zum Beispiel an einen Cronjob, der von mir aus einmal täglich läuft und die Daten des Vortages rüber kopiert. Oder idealerweise das gesamte Delta seit dem letzten Durchlauf, falls der Job mal ein paar Tage nicht läuft – warum auch immer. Vermutlich wäre influx CLI hier das passende Werkzeug, aber was mache ich dann damit? Innerhalb einer InfluxDB ist das Kopieren zwischen verschiedenen Buckets wohl relativ simpel, aber wie kann es zwischen verschiedenen Datenbank-Instanzen auf zwei verschiedenen Hosts klappen?
Theoretisch wäre auch der Umweg über eine CSV-Datei o. ä., die ich dann in meine Datenbank einlese, eine denkbare Lösung. Aber ein direkter Transfer zwischen beiden Datenbanken wäre natürlich technisch schöner. Und ich weiß nicht mal, ob influx CLI Dateien einlesen kann. Ich habe gelesen, dass man hier zum Beispiel mit Telegraf arbeiten könnte, aber das wäre dann noch eine Komponente in der Gleichung, von der ich auch keine Ahnung habe.
Derzeit will ich es einfach nur ans Laufen kriegen, bevor ich die ersten Daten verliere. Und vielleicht habe ich ja irgendwann mal Lust, mich tiefer mit der Materie zu beschäftigen und das Konstrukt zu optimieren oder sogar mehr aus dem Pi rauszuholen. Aktuell ist das aber nicht drin.
Vielen Dank vorab für euren Input.
Viele Grüße
Festus94
wir haben hier im Haus eine Solaranlage von Enpal. Sie wurde im März in Betrieb genommen und funktioniert grundsätzlich wunderbar.
Die Steuerungseinheit der Anlage bringt unter anderem eine eigene kleine InfluxDB v2 mit, in der alle Messwerte aus den verschiedensten Quellen für drei Monate gespeichert werden. Wofür genau sie diese Datenbank benötigen, weiß ich nicht, ist aber auch egal.
Der Punkt ist, dass man API Token, Bucket und Organization auf dem zugehörigen Webportal der Anlage auslesen kann. Es ist also möglich, die Datenbank abzufragen und zum Beispiel eine eigene Grafana-Instanz anzubinden.
Ich würde gerne, bevor die ersten Daten gelöscht werden, diese in eine eigne InfluxDB kopieren, in der ich die Messwerte über mehrere Jahre aufbewahren kann. Einen wirklichen Use Case habe ich zwar noch nicht, aber jeder fängt mal an, und irgendwann werde ich bestimmt froh sein, das gemacht zu haben. Auch bietet mir das die Möglichkeit, mich ein bisschen mit Themen wie Grafana und eben der InfluxDB zu beschäftigen, wenn ich mal Zeit und Lust dazu habe.
Ich habe noch einen alten Raspberry Pi (müsste ein Pi 3B+ sein) in der Ecke liegen, der seit knapp zehn Jahren nicht mehr in Betrieb war. Dem habe ich jetzt eine neue Speicherkarte spendiert, denn mit der alten war die Geschwindigkeit so unterirdisch, dass das Teil völlig unbrauchbar war. Jetzt lässt sich die Geschwindigkeit zumindest mit einem Glas Martini zwischenzeitlich irgendwie ertragen.
Ich habe also einen quasi fertig eingerichteten Pi. Eine InfluxDB kriege ich da auch noch irgendwie drauf, dann sollte ich erst mal alles haben. Und trotzdem werden Linux und ich in diesem Leben keine Freunde mehr, aber das nur am Rande.
Die Herausforderung ist jetzt: Wie kriege ich die Daten aus der Enpal-Datenbank in meine eigene? Ich habe absolut null Erfahrung mit der Software und weiß daher nicht, welche Optionen auf dem Tisch liegen. Es gibt wohl einen Weg, eine Synchronisierung einzurichten, was der präferierte Weg wäre, aber dafür bräuchte ich wohl auch einen User mit Schreibrechten in der Quell-Datenbank. Ich habe aber wie gesagt nur den API Token mit Lesezugriff. Besser als nichts.
Könnt ihr mir sagen, welche Möglichkeiten ich habe? Der Abgleich muss nicht live passieren. Ich dachte zum Beispiel an einen Cronjob, der von mir aus einmal täglich läuft und die Daten des Vortages rüber kopiert. Oder idealerweise das gesamte Delta seit dem letzten Durchlauf, falls der Job mal ein paar Tage nicht läuft – warum auch immer. Vermutlich wäre influx CLI hier das passende Werkzeug, aber was mache ich dann damit? Innerhalb einer InfluxDB ist das Kopieren zwischen verschiedenen Buckets wohl relativ simpel, aber wie kann es zwischen verschiedenen Datenbank-Instanzen auf zwei verschiedenen Hosts klappen?
Theoretisch wäre auch der Umweg über eine CSV-Datei o. ä., die ich dann in meine Datenbank einlese, eine denkbare Lösung. Aber ein direkter Transfer zwischen beiden Datenbanken wäre natürlich technisch schöner. Und ich weiß nicht mal, ob influx CLI Dateien einlesen kann. Ich habe gelesen, dass man hier zum Beispiel mit Telegraf arbeiten könnte, aber das wäre dann noch eine Komponente in der Gleichung, von der ich auch keine Ahnung habe.
Derzeit will ich es einfach nur ans Laufen kriegen, bevor ich die ersten Daten verliere. Und vielleicht habe ich ja irgendwann mal Lust, mich tiefer mit der Materie zu beschäftigen und das Konstrukt zu optimieren oder sogar mehr aus dem Pi rauszuholen. Aktuell ist das aber nicht drin.
Vielen Dank vorab für euren Input.
Viele Grüße
Festus94
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 41972792121
Url: https://administrator.de/contentid/41972792121
Ausgedruckt am: 21.11.2024 um 20:11 Uhr
9 Kommentare
Neuester Kommentar
Hallo,
Gruss,
Peter
Zitat von @Festus94:
in der alle Messwerte aus den verschiedensten Quellen für drei Monate gespeichert werden. Wofür genau sie diese Datenbank benötigen
Da werden die Daten gespeichert die du drei Monate lang dir ansehen kannst. Oder erwartest du das dort die Lottozahlen der nächsten 3 Jahre drin stehen?in der alle Messwerte aus den verschiedensten Quellen für drei Monate gespeichert werden. Wofür genau sie diese Datenbank benötigen
dafür bräuchte ich wohl auch einen User mit Schreibrechten in der Quell-Datenbank
Warum willst du in der Quelle Schreiben?Gruss,
Peter
wenn du eine api hast is es doch einfach... cronjob bauen der einmal am tag die daten auslesen und in deine beliebige datenbank ganz normal mit insert.... om duplicate key update eintragen... das sollte nich zu schwer sein und durch die api is dir auch egal was die als db nutzen,,,, (was wäre zb wenn die in 6 monaten die db wechseln, dann stehst mit ner langzeitanalyse blöd da)
Moin Peter.
Eben nicht. Es gibt keine Möglichkeit, in der Web UI der Steuerungseinheit historische Werte einzusehen. Du kannst lediglich aktuelle Rohdaten auslesen. Die Weboberfläche ist nicht für die dauerhafte Benutzung durch den User gebaut worden. Es gab in einer früheren Version der Steuerungseinheit, damals glaube ich sogar nicht mit InfluxDB v1, ein vorinstalliertes Grafana, das man ansteuern konnte. Darin waren dann auch historische Daten sichtbar.
Das gibt es in der Form aber nicht mehr. Der einzige, von Enpal offiziell unterstütze Weg ist – was auch sonst – eine App, in der du dir die Live-Daten sowie historische Werte ansehen kannst. Die App bezieht ihre Daten aber aus der Cloud, wo sie mit einer längeren Retention Period gespeichert werden. Da sich die Steuerungseinheit gehen einen Azure IoT Hub verbindet, würde es mich nicht überraschen, wenn die Langzeitdaten auch in Azure liegen, von wo aus sich die App dann bedient.
Aber wie auch immer: Für historische Daten ist die InfluxDB schon mal nicht an Board.
Wie ich geschrieben habe: Man kann in InfluxDBs eine Synchronisierung einrichten, indem man auf beiden Datenbanken eine Partnerschaft einrichtet. Das hatte ich vor Kurzem mal irgendwo in der Doku gefunden. Und da zu einer Partnerschaft immer zwei gehören, muss die Konfiguration auch in der Quell-Datenbank eingerichtet werden. Und das geht halt nur mit Schreibrechten.
Ich wünsche euch einen schönen Sonntag.
Viele Grüße
Fesstus94
Zitat von @Pjordorf:
Zitat von @Festus94:
in der alle Messwerte aus den verschiedensten Quellen für drei Monate gespeichert werden. Wofür genau sie diese Datenbank benötigen
Da werden die Daten gespeichert die du drei Monate lang dir ansehen kannst. Oder erwartest du das dort die Lottozahlen der nächsten 3 Jahre drin stehen?in der alle Messwerte aus den verschiedensten Quellen für drei Monate gespeichert werden. Wofür genau sie diese Datenbank benötigen
Eben nicht. Es gibt keine Möglichkeit, in der Web UI der Steuerungseinheit historische Werte einzusehen. Du kannst lediglich aktuelle Rohdaten auslesen. Die Weboberfläche ist nicht für die dauerhafte Benutzung durch den User gebaut worden. Es gab in einer früheren Version der Steuerungseinheit, damals glaube ich sogar nicht mit InfluxDB v1, ein vorinstalliertes Grafana, das man ansteuern konnte. Darin waren dann auch historische Daten sichtbar.
Das gibt es in der Form aber nicht mehr. Der einzige, von Enpal offiziell unterstütze Weg ist – was auch sonst – eine App, in der du dir die Live-Daten sowie historische Werte ansehen kannst. Die App bezieht ihre Daten aber aus der Cloud, wo sie mit einer längeren Retention Period gespeichert werden. Da sich die Steuerungseinheit gehen einen Azure IoT Hub verbindet, würde es mich nicht überraschen, wenn die Langzeitdaten auch in Azure liegen, von wo aus sich die App dann bedient.
Aber wie auch immer: Für historische Daten ist die InfluxDB schon mal nicht an Board.
Zitat von @Pjordorf:
dafür bräuchte ich wohl auch einen User mit Schreibrechten in der Quell-Datenbank
Warum willst du in der Quelle Schreiben?Wie ich geschrieben habe: Man kann in InfluxDBs eine Synchronisierung einrichten, indem man auf beiden Datenbanken eine Partnerschaft einrichtet. Das hatte ich vor Kurzem mal irgendwo in der Doku gefunden. Und da zu einer Partnerschaft immer zwei gehören, muss die Konfiguration auch in der Quell-Datenbank eingerichtet werden. Und das geht halt nur mit Schreibrechten.
Ich wünsche euch einen schönen Sonntag.
Viele Grüße
Fesstus94
Hatten mal kurz gesucht und da es wohl eine Mietanlage ist ...... wo andere schon was Versucht haben wäre auf Github wohl des Projekt was für dich.
Einbindung einer gemieteten PV-Anlage von Enpal mittels InfluxDB in evcc
Einbindung einer gemieteten PV-Anlage von Enpal mittels InfluxDB in evcc
Mal als Ansatz, ungetestet ungefähr so täglich einmal ausgeführt
Mit der CSV kannst du natürlich auch in andere Datenbanken etc. gehen und bist nicht auf Influx festgelötet.
Ansonsten, da du ja selbst auch was lernen willst, ist wie immer die Doku dein Freund zum Ziel
... https://docs.influxdata.com/
Gruß
influx query 'from(bucket: "example-bucket") |> range(start: -1d)' --host "http://xxx.xxx.xxx.xxx:8086" --raw --token xxxxxxxx --org-id xxxxx >"path/to/data.csv"
influx write --bucket "my-solar-bucket" --file "path/to/data.csv" --format csv --host http://localhost:8086 Ansonsten, da du ja selbst auch was lernen willst, ist wie immer die Doku dein Freund zum Ziel
... https://docs.influxdata.com/
Gruß
Danke euch. Ich habe vorhin erst mal feststellen müssen, dass es sich bei meinem Pi nicht um das Modell 3B, sondern noch um einen Pi 1B+ handelt. Dann wundert es mich auch nicht mehr, dass der so furchtbar langsam ist.
Ich hatte leider Probleme beim Starten der InfluxDB. Die Installation klappte, aber InfluxDB startet einfach nicht. Im Log steht, es gebe Fehler in der Programmdatei. Kann der Pi 1 überhaupt aktuelle arm64 Images ausführen? Ich kriege das Ding nämlich schlicht nicht ans Laufen.
Raspberry Pi OS habe ich in der 32-Bit-Version installiert, denn 64 Bit wollte nicht starten. Vermutlich klappt das so gar nicht und ich brauche einen etwas neueren Pi, bevor ich weitermachen kann.
Ja, das hatte ich schon mal gefunden, aber hier ist das Ziel ja etwas anders. Ich hänge gedanklich an dem Punkt, an dem ich die Daten, die auf der Quell-Datenbank rauskommen, dann in meine eigene Datenbank schreiben muss.
Das Auslesen Schreiben für sich gesehen sollte ich irgendwie hinkriegen, auch mit der Doku. (Trotzdem danke, @13034433319.). Aber mir fehlt gerade die Idee, wie ich den Output der Quelle direkt in das Kommando zum Schreiben im Ziel einkippe. Dafür stecke ich da einfach zu wenig drin und denke zu kompliziert.
Der Mittelweg über eine CSV-Datei geht vermutlich, aber eine direkt Übertragung ohne Mittelschritt wäre irgendwie schöner.
Könnt ihr mir sagen, ob meine Vermutung richtig ist, dass ich mit dem alten Pi 1 nicht weit komme? Dann kann ich mir erst mal ein anderes Board besorgen.
Danke euch.
Ich hatte leider Probleme beim Starten der InfluxDB. Die Installation klappte, aber InfluxDB startet einfach nicht. Im Log steht, es gebe Fehler in der Programmdatei. Kann der Pi 1 überhaupt aktuelle arm64 Images ausführen? Ich kriege das Ding nämlich schlicht nicht ans Laufen.
Raspberry Pi OS habe ich in der 32-Bit-Version installiert, denn 64 Bit wollte nicht starten. Vermutlich klappt das so gar nicht und ich brauche einen etwas neueren Pi, bevor ich weitermachen kann.
Zitat von @kaiand1:
Hatten mal kurz gesucht und da es wohl eine Mietanlage ist ...... wo andere schon was Versucht haben wäre auf Github wohl des Projekt was für dich.
Hatten mal kurz gesucht und da es wohl eine Mietanlage ist ...... wo andere schon was Versucht haben wäre auf Github wohl des Projekt was für dich.
Ja, das hatte ich schon mal gefunden, aber hier ist das Ziel ja etwas anders. Ich hänge gedanklich an dem Punkt, an dem ich die Daten, die auf der Quell-Datenbank rauskommen, dann in meine eigene Datenbank schreiben muss.
Das Auslesen Schreiben für sich gesehen sollte ich irgendwie hinkriegen, auch mit der Doku. (Trotzdem danke, @13034433319.). Aber mir fehlt gerade die Idee, wie ich den Output der Quelle direkt in das Kommando zum Schreiben im Ziel einkippe. Dafür stecke ich da einfach zu wenig drin und denke zu kompliziert.
Der Mittelweg über eine CSV-Datei geht vermutlich, aber eine direkt Übertragung ohne Mittelschritt wäre irgendwie schöner.
Könnt ihr mir sagen, ob meine Vermutung richtig ist, dass ich mit dem alten Pi 1 nicht weit komme? Dann kann ich mir erst mal ein anderes Board besorgen.
Danke euch.
überhaupt aktuelle arm64 Images ausführen
Der läuft auf der ARM11 Platform somit ein RISC 32bit Prozessor, also nein.Aber mir fehlt gerade die Idee, wie ich den Output der Quelle direkt in das Kommando zum Schreiben im Ziel einkippe. Dafür stecke ich da einfach zu wenig drin und denke zu kompliziert.
Laut Doku mit den obigen Befehlen nicht direkt möglich über Stdout/Stdin zu pipen.Da müsstest du dann mit einer For-Schleife oder xargs die Zeilen der Query abarbeiten, das wird eher langsamer als schneller wenn man influx write jeweils pro Datenzeile aufrufen muss, da ist dann die CSV effizienter. Die kannst du ja auf einer RAMdisk oder einem Netzwerkspeicher zwischenspeichern wenn du Angst hast das die SD deines PIs darunter auf Dauer leidet.
Hallo zusammen,
inzwischen bin ich ein bisschen weiter. Ich konnte die Daten aus der Quelldatenbank exportieren. Die erstellte CSV-Datei konnte ich in die Zieldatenbank importieren. So weit, so gut.
Was mir gerade fehlt ist eine Möglichkeit, um beim Schreiben in meine Datenbank doppelte Einträge zu verhindern, denn irgendwann wird es mal passieren, dass sich Datensätze doppeln, weil sie vielleicht in zwei Files drin sind. Das würde den Transfer auf jeden Fall deutlich flexibler gestalten.
Auf Anhieb habe ich keinen Weg gefunden, der influx CLI zu sagen, dass sie doppelte Werte überspringen soll. Habt ihr da zufällig eine schlaue Idee. Dann hätte ich schon alles, was ich bräuchte.
Viele Grüße
inzwischen bin ich ein bisschen weiter. Ich konnte die Daten aus der Quelldatenbank exportieren. Die erstellte CSV-Datei konnte ich in die Zieldatenbank importieren. So weit, so gut.
Was mir gerade fehlt ist eine Möglichkeit, um beim Schreiben in meine Datenbank doppelte Einträge zu verhindern, denn irgendwann wird es mal passieren, dass sich Datensätze doppeln, weil sie vielleicht in zwei Files drin sind. Das würde den Transfer auf jeden Fall deutlich flexibler gestalten.
Auf Anhieb habe ich keinen Weg gefunden, der influx CLI zu sagen, dass sie doppelte Werte überspringen soll. Habt ihr da zufällig eine schlaue Idee. Dann hätte ich schon alles, was ich bräuchte.
Viele Grüße
I.d.R. entstehen dabei keine Dubletten wenn du das selbe File nochmal importierst. Da bestehende Einträge mit den selben Daten und Timestamp nicht nochmal angehängt werden sondern überschrieben.
Ansonsten wenn man in irgendeiner Art und Weise etwas doppeltes hat, mit group() die Daten gruppieren und doppelte Einträge mit reduce() auf einen einzelnen Eintrag der Gruppe reduzieren.
Ansonsten wenn man in irgendeiner Art und Weise etwas doppeltes hat, mit group() die Daten gruppieren und doppelte Einträge mit reduce() auf einen einzelnen Eintrag der Gruppe reduzieren.
