grafana und edomi - influx nötig?

[ThorstenGehrig]

Hi
ich beschäftige mich gerade mit influx und grafana. Derzeit schreibe ich alle iKO und KNX Adressen auf einen MQTT server - daher habe ich mal ganz entspannt einen node red docker genutzt um Werte von MQTT in eine influx zu schreiben (auch docker).
Dann hab ich in grafana (natürlich auch Docker) genutzt um Werte zu visualisieren => funktioniert :-)

Bei der ganzen "Spielerei" frage ich mich warum eigentlich der Umweg über Influx... eigentlich müsste grafana doch auch die mysql von Edomi direkt aulesen können, oder? Da ich aber hier keinen Bericht gesehen habe der das macht ... Frage ich mich welche Gründe dagegen sprechen...

Danke für euren Input... und weiterhin schöne Festtage!

Gruß
Thorsten

[jonofe]

Aus meiner Sicht spricht vor allem dagegen, dass die mysql DB von EDOMI produktiv genutzt wird und daher Einflüsse auf die Performanz von EDOMi möglich sind. Daher ist es aus meiner Sicht besser Datenanalyse und -visualisierung von der produktiven Logikengine zu entkoppeln. Hängt aber auch von der Leistungsfähigkeit des EDOMi Servers ab. Man sieht den Einfluss ja auch schon gut, wenn die Datenarchive zu groß werden und wenn EDOMi Diagramme generiert.

Auch von mir ein frohes Fest an alle ...

[saegefisch]

Ja, sehe ich genau so (Trennung).

Zudem die edomi DB ist für überschaubare Datenmengen wunderbar integriert. Aber bei größeren Mengen wird offenbar, dass sie genau dafür nicht das richtige Werkzeug ist. Schon technisch ist influxDB für derlei maßgeschneidert, was eine relationale DB mit viel CPU erschlagen muss.

Ganz operativ schlägt zudem das Housekeeping von edomi bei jedem (!) aktivieren zu - mit spürbarer Korrelation von Datenmengen und aktivierungszeit. Schon daher ist eine DEV-edomi-VM ganz ohne Datenarchive so ratsam: nur wenige Sekunden Aktivierung.

[gibsonrocker]

Ich bin gerade dabei bei unserer Heizung alles über eBUS an Edomi/KNX zu bringen und umgekehrt. Bin deshalb auch gerade dabei die Heizungswerte in eine influxDB zu schreiben. Alles auf einer extra Maschine! Ich würde die Edomi DB damit nicht belasten wollen. Auch wenn eines der Systeme ausfällt oder neu gemacht werden muss ist es so irgendwie besser wenn sich nicht alles auf einer Maschine befindet.

Finde Deine Idee alle iKOs und alle KNX-KOs in die influxDB zu schieben gerade sehr ansprechend. Die eine oder andere Auswertung der KNX-KOs kann ganz lustig sein (meine Frau würde an dieser Stelle mit den Augen rollen ).

Sehe ich gerade die einfache Lösung nicht spontan? Wie hast Du die vielen KNX-KOs an MQTT gebracht? Hast Du jedes KO in Edomi mit der Hand angefasst? Oder schreibst Du den ganzen Busverkehr irgendwie weg? Oder ist die Lösung gar nicht einfach und Du hast echt jedes KO angepackt. Wäre ja aufwändig wenn sich etwas ändert.

[jonofe]

Der MQTT Publish Server kann alle GAs und alle iKOs ohne weitere Logik per MQTT publishen.

[gibsonrocker]

Ah...alles klar. Sehr gut. Danke für die Info!

[ThorstenGehrig]

Hi
@all: danke für eure Antworten
@gibsonrocker: ich habe alle per MQTT gepublished... aber bei weitem nicht alles von MQTT in der influxDB gespeichert.
Für´s debugging hab ich noch einen eibd-log auf einem 10-jahre altem Wiregate am laufen (...es läuft und läuft und läuft :-) ). Der macht auch sowas wie "most talker KNX-Address" oder "most talker Source-Address"... ansonsten finde ich diesen Datenpool wenig sinnvoll für´s debuggen.
Bei iKOs sind die "most talker" vermutlich noch weniger interessant...

@all: okay - keine großen Datenarchive auf dem EDOMI?! Gibt es denn eine Möglichkeit die Datenarchive auszulagern (ich denke nicht)? Eine mysql kann man ja ganz leicht auf einem Docker zur verfügung stellen... (eine influxDB wohl eher nicht so einfach - das müssten ja die SQL-Abfragen angepasst werden).
Vermutlich müsste an gaert einen feature request stellen... - oder?

Gruß
Thorsten

[saegefisch]

Relationale DB sind konzeptionell nicht optimal für diese Daten(Mengen) und Abfragen - ob in edomi oder abseits. Aber geht natürlich auch, klar. Bei edomi kommt das housekeeping beim Aktivieren noch dazu. Daher würde ich raten zu: kritische Bewertung, welche Daten mit welcher Residenzzeit überhaupt sinnvoll sind. Kleine Datenmengen in edomi. Größere Bedarfe dann:
Per Docker influxDB. Bewirtschaftung per LBS.
Per Docker Grafana für die Abfragen und Diagramme.
Bei Bedarf Einbindung in edomi-Visu oder links auf Grafana in edomi.

[jonofe]

Relationale DB sind konzeptionell nicht optimal für diese Daten(Mengen) und Abfragen - ob in edomi oder abseits. Aber geht natürlich auch, klar. Bei edomi kommt das housekeeping beim Aktivieren noch dazu. Daher würde ich raten zu: kritische Bewertung, welche Daten mit welcher Residenzzeit überhaupt sinnvoll sind. Kleine Datenmengen in edomi. Größere Bedarfe dann:
Per Docker influxDB. Bewirtschaftung per LBS.

Dem kann ich nur zu stimmen.

Daher habe ich mal eine neuen LBS 19002576 Influx Data Archives gebaut, welcher ein automatisches copy/sync mit Influx auf Basis der EDOMI Datenarchive ermöglicht.

Mit diesem LBS kann man:

• Einzelne/Ausgewählte/Alle Datenarchive 1:1 nach Influx spiegeln
• Datenarchive können komplett, zeitlich absolut oder zeitlich relativ kopiert werden
• Neue Einträge in EDOMI Datenarchive können automatisch kopiert (INSERT) oder auch gesynced (INSERTs + DELETEs) werden.

D.h. der LBS wird einmalig in EDOMI eingefügt und schiebt dann alle Datenarchiveinträge nach Influx.
Im Modus "sync" werden auch alle Löschungen im EDOMI Datenarchiv auf Influx angewandt. D.h. die EDOMI Retention Policy wirkt sich auch auf Influx aus.
Im Modus "copy" werden nur neue Einträge nach Influx kopiert, d.h. die Rentention Policy in EDOMI wirkt sich nicht auf Influx aus. Damit kann man ALLE Datenpunkte in Influx halten, während die EDOMI Datenarchive überschaubar bleiben und nur die Daten enthält, die man in EDOMI Diagrammen visualisieren kann.

Ich habe den LBS jetzt seit ca. 2 Wochen in Betrieb. Derzeit 1,5 Mio Einträge in ca. 30 Datenarchiven in EDOMI, was jetzt durch neu definierte Retention Policies ziemlich konstant bleibt. In Influx wachsen jetzt die Datenbestände. Hier kann man dann separate Retention Policies definieren, da auch Influx bei größer werdenden Buckets/Measurements in Abh. des Infrastruktursizings irgendwann an Grenzen stößt.

Anfangs hatten meine EDOMI Datenarchive insggesamt ca. 5-6 Mio Einträge. Das Kopieren nach Influx hat innerhalb von 15-20 Minuten problemlos funktioniert, allerdings war mein Influx Docker Container dann am Limit. Daher sollte auch das richtige Sizing der Influx Infrastruktur nicht vernachlässigt werden.

Der LBS ist noch als beta eingestuft. Daher sollten natürlich immer aktuelle Backups beider Datenbanken (EDOMI/Influx) gemacht werden.
Der LBS-Code enthält weder DELETE noch UPDATE Statements auf die EDOMI Datenarchive, sondern nur SELECTs, daher sollte auf EDOMI-Seite auch nichts gelöscht oder überschrieben werden können.

In der Influx DB werden alle Werte in ein Bucket geschrieben.
Innerhalb des Buckets gibt es je EDOMI Datenarchiv ein Measurement. Das Measurement in Influx hat dann den Namen des EDOMI Datenarchive.
Der EDOMI Datenpunkt ist dann der Measurement-Value in Influx.
Der Timestamp aus dem EDOMI Datenarchiv ist auch der Timestamp in Influx.
Als Tags werden in der Influx DB noch die EDOMI Datenarchiv-ID und der ms-Wert des Timestamps angegeben.

Der LBS setzt eine lauffähive Influx v2 DB mit Org, Bucket, und Read/Write-Token voraus.

Kommentare, Feedback, Bugs zum LBS gerne in einem separaten Thread.

[ThorstenGehrig]

Danke Jonofe
Ich frage mich jetzt gerade wie ich meine Daten zukünftig in influx Rüberkopiere.
Der derzeitige MQTT->Publish und dann per Node-Red einzeln nach Influx ist wenig skalierbar.
Es gibt Bausteine (influxdbwriter) um direkt in die Influx zu schreiben - oder "batch-writer" um einige paralell in die influx zu schreiben.
Und dann deinen Baustein der es erlaubt Archive zu syncen - dazu muss man aber erstmal lokal ins Archiv schreiben
Eigentlich wäre es doch cool wenn man das bei beim MQTT mit MPUB im Kommenrtarfeld des KOs definieren kann... dann könnte man sich die Archive im Edomi sparen, oder?
Gruß
Thorsten

[jonofe]

Eigentlich wäre es doch cool wenn man das bei beim MQTT mit MPUB im Kommenrtarfeld des KOs definieren kann... dann könnte man sich die Archive im Edomi sparen, oder?

Kommt auf den Anwendungsfall an. Zum einen sichert EDOMI in den Datenarchiven immer noch Werte, auch wenn mal die Verbindung zur Influx-DB ausfällt, außerdem schreibt man ja auch manchmal nicht die iKO Werte, sondern einen durch Logik angepassten iKO Wert in ein Datenarchiv. Daher finde ich den kleinen Overhead des EDOMI Datenarchivs sogar sinnvoll. Man kann somit sicher sein, dass solange EDOMI läuft die Werte auch gesichert werden. Die Speicherdauer des Datenarchivs kann man in EDOMI entsprechend anpassen, d.h. wenn die Speicherdauer z.B. 24h beträgt, dann darf die influx DB auch mal 24h offline sein, ohne das man Daten verliert.

Ein LBS der es hingegen ähnlich wie der MQTT Publish Server macht, würde dazu führen, dass erneut alle iKO/GA Schreibvorgänge geprüft werden müssen, ob sie nach Influx gesendet werden müssen. Das wäre erheblich aufwändiger aus Sicht der benötigten Prozessorleistung. Sowas würde nur dann Sinn machen, wenn man die Funktionalität solcher LBS in einem PHP Skript bündeln würde. D.h. ein gäbe einen mySQL Trigger und eine mySQL Procedure, welche bei einer GA/iKO Änderung ein EXEC Skript aufruft und dieses EXEC Skript führen dann je nach Konfiguration in EDOMI ein MQTT Publish, ein Influx Publish, etc, durch. Sowas könnte man dann zukünftig um weitere Funktionen erweitern.

Evtl. mal ein Projekt für den nächsten Monsun.

[MaPa]

Daher habe ich mal eine neuen LBS 19002576 Influx Data Archives gebaut, welcher ein automatisches copy/sync mit Influx auf Basis der EDOMI Datenarchive ermöglicht.

Hi Jonofe,

ich versuche gerade deinen neuen LBS zu testen, leider bekomme ich immer die Fehlermeldung im LOG:

2022-10-10 21:13:48 START
2022-10-10 21:13:48 Data archive IDs to be sent to InfluxDB: all
2022-10-10 21:13:48 UTC Timestamp: 20221010T191348Z
2022-10-10 21:13:48 UTC Time: 20221010T191348Z
2022-10-10 21:13:48 Writing data to InfluxDB ...
2022-10-10 21:13:48 INSERT : archiveName: Zählerstand in kWh, archiveId: 292, us: 642729, value: 10874.793, timestamp_utc: 1665429228
2022-10-10 21:13:48 INSERT-EXCEPTION
2022-10-10 21:13:48 EXCEPTION Message: No PSR-18 clients found. Make sure to install a package providing "psr/http-client-implementation". Example: "php-http/guzzle7-adapter".
2022-10-10 21:13:48 END​

hast du eine Idee was ich hier machen kann, natürlich wird auch nichts in die Influx Datenbank geschrieben

Grüße
Marcus

[jonofe]

hast du eine Idee was ich hier machen kann

Sind alle Installationen aus der Hilfe des LBS durchgeführt und erfolgreich durchgelaufen?

[MaPa]

Sind alle Installationen aus der Hilfe des LBS durchgeführt und erfolgreich durchgelaufen?

Ja ist alles durchgelaufen

[jonofe]

Ich würde die Installation nochmal durchführen und dann mal die gesamte Ausgabe hier posten.
ich denke, dass das composer statement eingentlich alle Abhängigkeiten installieren sollte.