NEWS
History Adpater (History vs. influxdb vs SQL)
-
- es wird eng auf RasPi2 `
Die DB muss ja nicht auf dem Raspi laufen… :mrgreen:
Ich habe versucht meine MySQL vom PC anzubinden - klappt tadellos 8-)
Mein Wunsch: (resp. werde bei nächster Gelegenheit selbst mal reinschauen...)
Die DB auf dem PC ist nicht immer verfügbar, da dieser nicht 24/7 läuft.
Der SQL Adapter soll die Daten so lange selber cachen, bis die DB auf dem PC verfügbar wird und dann alles rüberspielen.
Da mich die History normalerweise sowieso nur interessiert wenn der PC läuft passt das...
Alternative Idee: Eine DB im Internet benutzen.
viele Grüsse
Daniel
- es wird eng auf RasPi2 `
-
endlich habe ich etwas Zeit gefunden um mich um meine Wunschliste zu kümmern. Ich habe den SQL-Adapter als Vorlage genommen und erweitert:
-
mit "node-persist" werden alle gewählten Daten gecached und jeweils alle 10min lokal persistiert.
-
In Intervallen von X Minuten werden die gecachten Daten in die SQL Datenbank geschrieben (wenn diese erreichbar ist [1])
-
Zum Abrufen der Historieserten Daten gibt's dann zwei Vairanten
-
DB ist verfügbar: Daten werden per SQL aus der DB gelesen
-
DB nicht verfügbar: Daten werden aus dem Cache gelesen (soweit dort verfügbar)
zum Testen:
original SQL-Adapter deinstallieren und mit diesem ersetzen
npm install https://github.com/dschaedl/iobroker.sq … ll/master/
Wichtig: im MySQL Schema habe ich in den Datentabellen eine Spalte "dt" vom Datentyp "datetime" eingefügt um ein lesbares Datum in der DB zu haben.
-> ALTER TABLE
iobroker.ts_numberADD COLUMNdtDATETIME NULL AFTERq; (für ts_number, ts_boolean, ts_string)ein paar Details:
-
Die gecachten Werte werden nach dem Transfer in die DB nicht gelöscht, sondern nur markiert; damit beim Abrufen ohne DB genügend Daten zurück kommen
-
Ein Aufräum-Job löscht die gecachten Daten nach X Tagen (lässt sich konfigurieren)
-
Das überspielen der Daten in die SQL-DB findet synchron statt; Asynchron/parallel ist der Raspi rasch überfordert mit der grossen Menge an Daten.
-
Ich arbeite mit MySQL. Die anderen Schemen habe ich aktuell nicht berücksichtigt.
-
[1] Ich habe es nicht hingekriegt einen SQL-Verbindungsfehler zu fangen, ohne dass der Adapter beendet wird. Als Workaorund macht der Adapter nun einen 'Ping' um zu überprüfen ob der PC mit der MySQL DB am laufen ist -> nehme gerne Tips entgegen.
-
Der Timestamp in der DB enspricht dem ts-Attribut des ioBroker States (was leider nicht einem Javascript Date entspricht)
==> Bitte Vorsicht mit diesem Adapter; es ist eine erste Version eines Updates. Wenn ihr wichtige Daten in der DB habt, unbedingt vorher backuppen.
viele Grüsse
Daniel
-
-
Sehr interessantes Thema, Danke! Auch die Lösung mit dem langen cachen der Daten für einen externen Datenbankrechner ist clever gemacht.
Was spricht denn gegen eine SQL-Versionauf dem Raspi selbst? Also dem Raspberry 3 mit zB 32 GB Speicherkarte (Class 10 UHD). Sollte doch problemlos reichen, oder? Würde gerne diesen Raspi 3 mit iobroker betreiben und allen Diensten, samt Weboberfläche für den 7'' Raspi-Touchscreen. Angebunden an einem 2. Raspi mit Homematic.
-
endlich habe ich etwas Zeit gefunden um mich um meine Wunschliste zu kümmern. Ich habe den SQL-Adapter als Vorlage genommen und erweitert:
-
mit "node-persist" werden alle gewählten Daten gecached und jeweils alle 10min lokal persistiert.
-
In Intervallen von X Minuten werden die gecachten Daten in die SQL Datenbank geschrieben (wenn diese erreichbar ist [1])
-
Zum Abrufen der Historieserten Daten gibt's dann zwei Vairanten
-
DB ist verfügbar: Daten werden per SQL aus der DB gelesen
-
DB nicht verfügbar: Daten werden aus dem Cache gelesen (soweit dort verfügbar)
zum Testen:
original SQL-Adapter deinstallieren und mit diesem ersetzen
npm install https://github.com/dschaedl/iobroker.sq … ll/master/
Wichtig: im MySQL Schema habe ich in den Datentabellen eine Spalte "dt" vom Datentyp "datetime" eingefügt um ein lesbares Datum in der DB zu haben.
-> ALTER TABLE
iobroker.ts_numberADD COLUMNdtDATETIME NULL AFTERq; (für ts_number, ts_boolean, ts_string)ein paar Details:
-
Die gecachten Werte werden nach dem Transfer in die DB nicht gelöscht, sondern nur markiert; damit beim Abrufen ohne DB genügend Daten zurück kommen
-
Ein Aufräum-Job löscht die gecachten Daten nach X Tagen (lässt sich konfigurieren)
-
Das überspielen der Daten in die SQL-DB findet synchron statt; Asynchron/parallel ist der Raspi rasch überfordert mit der grossen Menge an Daten.
-
Ich arbeite mit MySQL. Die anderen Schemen habe ich aktuell nicht berücksichtigt.
-
[1] Ich habe es nicht hingekriegt einen SQL-Verbindungsfehler zu fangen, ohne dass der Adapter beendet wird. Als Workaorund macht der Adapter nun einen 'Ping' um zu überprüfen ob der PC mit der MySQL DB am laufen ist -> nehme gerne Tips entgegen.
-
Der Timestamp in der DB enspricht dem ts-Attribut des ioBroker States (was leider nicht einem Javascript Date entspricht)
==> Bitte Vorsicht mit diesem Adapter; es ist eine erste Version eines Updates. Wenn ihr wichtige Daten in der DB habt, unbedingt vorher backuppen.
viele Grüsse
Daniel `
Eine tolle Erweiterung. Ich denke, falls Caching konfigurierbar währe, dann konnte es in Main rein fließen.Wenn du so fit bist, kannst du ein Message mit messagebox implementieren, die beliebige quieries ausführen lässt?
sendTo('sql.0', 'query', 'select * from bla', function(result){
// Array
});
-
-
Hallo,
Ich weiss nicht ob ich in diesem Thread richtig bin, aber wenn nicht, müsste der Admin verschieben…
Habe bei mir auf SQL History umgestellt. Konfig der DB und sonstige Einrichtung hab ich nach Anleitung gut hinbekommen. Habe aber bei der Einstellung der geloggten Datenpunkte Probleme. Ich kann die Punkt "aktivieren" nicht speichern. (siehe Anhang) Ich denke dass ist ein Berechtigungsproblem ?!
Ein Beispiel-State würde problemlos gespeichert u. ich kann ihn auch über Rickshaw anzeigen lassen.
Nur bei neuen Daten hab ich Probleme.
Wäre dankbar für Unterstützung.
crepp
686_err.png -
Moin moin!
Ich habe (dämlicherweise) mit einer SQLite-DB angefangen und dort bereits Monate von Daten. Ich würde gerne umstellen auf MySQL von meinem 24/7-laufenden NAS. In die DB schreiben klappt, aber wie kann ich die bisherigen Daten der SQLite übernehmen?
Meine bisherigen Recherchen ergaben keine wirklich sinnvollen Migrationswege, der Adapter selbst "spricht" aber ja sowohl SQLite als auch MySQL - könnte der evtl. eine Art Copy-Job im Konfig-Bereich erhalten? Wäre doch eine Idee, oder?
Danke!
Gruß, Jan
-
Du musst die Daten manuell übernehmen …
Ich würde eine zweite SQL-Instanz anlegen , auf die MySQL einrichten um die DB-Struktur anzulegen.
Dann musst du schauen ob es Tools gibt die dir die Daten aus der SQLite exportiern lassen und dann kannst Du das in die MySQL importieren.
Beispiel (Google gefunden): https://stackoverflow.com/questions/186 ... 3-to-mysql
-
Moin
Also bei der Entscheidungsfindung möchte ich auch noch einmal kurz meine Erfahrung beisteuern: Ich habe am 7. September vom History Adapter auf SQL umgestellt. Das ganze "frisst" etwa 1GB Arbeitsspeicher auf meinem Rock64, dafür ist es aber deutlich entspannter bei der Prozessorlast, wenn mal wieder alle Flot-Diagramme gleichzeitig aktualisieren.
Lieben Gruß
Daniel -
Hallo
Verstehe ich das dann richtig das mysql besser ist als influx ? Ist vielseitiger (zum weiter arbeiten) und auch die Prozessorbelastung ?
Grüße Alex
691
Online32.4k
Benutzer81.4k
Themen1.3m
Beiträge