Grafana und InfluxDB neben Edomi. Installation und Best Practice

[Evolution100]

Hallo zusammen,

ich hätte mal eine best practice Frage zu Edomi und Influxdb. Ich teste das gerade etwas und versuche es optimal aufzubauen.
Aber wie macht man das am besten?

Ich habs einmal mit dem LBS 19002576 versucht. Also alle Tempwerte in Edomi in ein Archiv schreiben und die dann nach Influx mit dem LBS Syncen. Dann hab ich x measurements und keine tags

Alternativ hab ich mal versucht jeden Wert direkt beim ermitteln ins Edomi Archiv schreiben zu lassen (damit ich erstmal noch die Diagramme in Edomi hab) und parallel mit dem LBS 19002380 nach Influx. Hier kann ich dann ja ein Tag etc. mitgeben (z.b. Raumtemperatur, oder Zimmernamen). Heist aber, ich müsste jeden Wert immer "live" nach Influx schreiben.. mit X LBS'n ?! Ob das aus Performance etc. Sicht so gut ist? Oder mach ich mir da zu viel Kopf?

Aus Auswertungssicht wäre es dann natürlich noch super, wenn alle z.B. Temperaturdaten immer zur gleichen Zeit geschrieben werden bzw wenn ich immer den gleichen Zeitstempel mitgebe, da ich in Influx beim Auswerten gesehen habe, dass es deutlich besser wäre, wenn Werte zur gleichen Zeit kommen, sonst sieht man in der Grafik ggf. den anderen Wert nicht genau (oder gibts da eine andere Möglichkeit?

Vielleicht könnt Ihr mal Berichten, wie ihr da so umsetzt?

Vielen Dank

Markus

[jonofe]

Ich habs einmal mit dem LBS 19002576 versucht. Also alle Tempwerte in Edomi in ein Archiv schreiben und die dann nach Influx mit dem LBS Syncen. Dann hab ich x measurements und keine tags

Welche weiteren Tags brauchst du denn bzw.welche zusätzlichen Infos für Tags hast du denn?
Bei einem Datenarchiv gibt es nur Timestamp, Name und Wert und genauso ist doch dann in Influx vorhanden.

Aus Auswertungssicht wäre es dann natürlich noch super, wenn alle z.B. Temperaturdaten immer zur gleichen Zeit geschrieben werden

Da Edomi Event basiert ist, ist das aus meiner Sicht nicht wirklich sinnvoll. Du willst ja am Ende die Werte auch zu den Zeiten sehen, an denen sie gemessen wurden.
Du müsstest also die Werte erst alle zur gleichen Zeit lesen, dann würden sie auch nahezu zeitgleich geschrieben. Wenn du dann das Aggregationsintervall entsprechend setzt, dann sollte auch in Grafana jedes Measuremnt in jedem Intervall einen Wert liefern.

Bsp: Alle Temperaturen minütlich abfragen bzw. senden lassen, In Grafana dann ein Diagramm mit 5 Minuten Intervall und function mean() erstellen. Dann hast du für jede Temperatur alle 5 Minuten einen Wert.

[Evolution100]

jonofe Danke, werde ich so mal testen.

Jetzt hab ich aber ein anderes Problem. Auf meine Edomi Testrechner (Hardware mit CentOS) hat alles gleich funktioniert und ich konnte den LBS 19002576 direkt nach den Installationsbefehlen in Betrieb nehmen.
Nun wollte ich das alles auf Produktion nehmen (und das läuft auf einem Proxmox LXC mit dem Template von starwarsfan in der Version edomi-2.03.6
Da schaffe ich es nicht das Teil zum Laufen zu bekommen. Ich glaub ich hab schon alle Posts hier durch und x-Mal zurückgesetzt und neu getestet.. wenn ich alles korrekt verstanden hab, müsste man laut starwarsfan nur den LBS in Edomi hochladen und dann das hier noch ausführen

PHP Influx Client
=================
cd /usr/local/edomi/www/admin/include/php/
mkdir influx-client
cd influx-client/
composer require influxdata/influxdb-client-php


Dann bekomme ich das hier in der konsole nach dem composer

[root@EdomiProd ~]# cd /usr/local/edomi/www/admin/include/php/
[root@EdomiProd php]# mkdir influx-client
[root@EdomiProd php]# cd influx-client/
[root@EdomiProd influx-client]# composer require influxdata/influxdb-client-php
Do not run Composer as root/super user! See https://getcomposer.org/root for details
Continue as root/super user [yes]? yes
./composer.json has been created
Running composer update influxdata/influxdb-client-php
Loading composer repositories with package information
Updating dependencies
Lock file operations: 14 installs, 0 updates, 0 removals
- Locking clue/stream-filter (v1.7.0)
- Locking influxdata/influxdb-client-php (3.4.0)
- Locking php-http/client-common (2.7.1)
- Locking php-http/discovery (1.19.2)
- Locking php-http/httplug (2.4.0)
- Locking php-http/message (1.16.0)
- Locking php-http/promise (1.2.1)
- Locking psr/http-client (1.0.3)
- Locking psr/http-factory (1.0.2)
- Locking psr/http-message (2.0)
- Locking symfony/deprecation-contracts (v2.5.2)
- Locking symfony/options-resolver (v5.4.21)
- Locking symfony/polyfill-php73 (v1.28.0)
- Locking symfony/polyfill-php80 (v1.28.0)
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 14 installs, 0 updates, 0 removals
- Downloading php-http/discovery (1.19.2)
- Downloading psr/http-message (2.0)
- Downloading psr/http-client (1.0.3)
- Downloading symfony/polyfill-php80 (v1.28.0)
- Downloading symfony/polyfill-php73 (v1.28.0)
- Downloading symfony/options-resolver (v5.4.21)
- Downloading psr/http-factory (1.0.2)
- Downloading clue/stream-filter (v1.7.0)
- Downloading php-http/message (1.16.0)
- Downloading php-http/promise (1.2.1)
- Downloading php-http/httplug (2.4.0)
- Downloading php-http/client-common (2.7.1)
- Downloading influxdata/influxdb-client-php (3.4.0)
php-http/discovery contains a Composer plugin which is currently not in your allow-plugins config. See https://getcomposer.org/allow-plugins
Do you trust "php-http/discovery" to execute code and wish to enable it now? (writes "allow-plugins" to composer.json) [y,n,d,?] y
- Installing php-http/discovery (1.19.2): Extracting archive
- Installing psr/http-message (2.0): Extracting archive
- Installing psr/http-client (1.0.3): Extracting archive
- Installing symfony/polyfill-php80 (v1.28.0): Extracting archive
- Installing symfony/polyfill-php73 (v1.28.0): Extracting archive
- Installing symfony/deprecation-contracts (v2.5.2): Extracting archive
- Installing symfony/options-resolver (v5.4.21): Extracting archive
- Installing psr/http-factory (1.0.2): Extracting archive
- Installing clue/stream-filter (v1.7.0): Extracting archive
- Installing php-http/message (1.16.0): Extracting archive
- Installing php-http/promise (1.2.1): Extracting archive
- Installing php-http/httplug (2.4.0): Extracting archive
- Installing php-http/client-common (2.7.1): Extracting archive
- Installing influxdata/influxdb-client-php (3.4.0): Extracting archive
6 package suggestions were added by new dependencies, use `composer suggest` to see details.
Generating autoload files
5 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
No security vulnerability advisories found
Using version ^3.4 for influxdata/influxdb-client-php
[root@EdomiProd influx-client]#

Danach hab ich nochmal das Projekt aktiviert und den Server neu gestartet.. aber er schreibt keine Daten nach Influx
Das Testbucket dort ist und bleibt leer.

so hab ich den LBS beschalten (ich glaube auf meiner Testmaschine war es damals genau so...)

LBS.jpg

Logs sehen so aus

{EDOMI,CUSTOMLOG_Influx_Data_Archives-LBS19002576.htm,30.12.2023,18:13:01,429280,901}
Zeitstempel	ms	PID	LogLevel	Meldung
2023-12-30 18:13:01	429256	901	debug-mysql	LBS19002576 [v0.3b]: Query: DROP PROCEDURE IF EXISTS influx_update; (4404)
2023-12-30 18:13:01	429574	901	debug-mysql	LBS19002576 [v0.3b]: Query: DROP TRIGGER IF EXISTS influx_insert_trigger; (4404)
2023-12-30 18:13:01	429845	901	debug-mysql	LBS19002576 [v0.3b]: Query: DROP TRIGGER IF EXISTS influx_update_trigger; (4404)
2023-12-30 18:13:01	430073	901	debug-mysql	LBS19002576 [v0.3b]: Query: DROP TRIGGER IF EXISTS influx_delete_trigger; (4404)
2023-12-30 18:13:01	430356	901	debug-mysql	LBS19002576 [v0.3b]: Query: CREATE PROCEDURE influx_update(command VARCHAR(10), archiveId INT(20), archiveName VARCHAR(100), value VARCHAR(10000), timestamp DATETIME, ms INT(11)) BEGIN DECLARE cmd VARCHAR(1000); DECLARE result INT(10); DECLARE logresult INT(10); SET cmd = CONCAT('/usr/bin/bash -c "/usr/bin/php /usr/local/edomi/www/data/liveproject/lbs/EXE19002576.php ',command,' ',archiveId,' \'',archiveName,'\' \'',value,'\' \'',timestamp,'\' ',ms,' & "'); SET logresult = log_error(cmd); SET result = sys_exec(cmd); END (4404)

und das CUSTOMLOG_Influx_Data_Archives-EXEC.log ist leer....



Ich hab jetzt nicht wirklich von vielen gelesen, die es zum Laufen gebracht hatten..?
Geht das ggf. echt nicht.. oder stelle ich mich einfach nur zu doof an?


P.S: Wenn ich den composer noch ausführe ändert sich nichts..

[root@EdomiProd ~]# composer require php-http/guzzle7-adapter
Do not run Composer as root/super user! See https://getcomposer.org/root for details
Continue as root/super user [yes]? yes
./composer.json has been created
Running composer update php-http/guzzle7-adapter
Loading composer repositories with package information
Updating dependencies
Lock file operations: 11 installs, 0 updates, 0 removals
- Locking guzzlehttp/guzzle (7.8.1)
- Locking guzzlehttp/promises (2.0.2)
- Locking guzzlehttp/psr7 (2.6.2)
- Locking php-http/guzzle7-adapter (1.0.0)
- Locking php-http/httplug (2.4.0)
- Locking php-http/promise (1.2.1)
- Locking psr/http-client (1.0.3)
- Locking psr/http-factory (1.0.2)
- Locking psr/http-message (2.0)
- Locking ralouphie/getallheaders (3.0.3)
- Locking symfony/deprecation-contracts (v2.5.2)
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 11 installs, 0 updates, 0 removals
- Downloading guzzlehttp/promises (2.0.2)
- Downloading guzzlehttp/psr7 (2.6.2)
- Downloading guzzlehttp/guzzle (7.8.1)
- Downloading php-http/guzzle7-adapter (1.0.0)
- Installing guzzlehttp/promises (2.0.2): Extracting archive
- Installing ralouphie/getallheaders (3.0.3): Extracting archive
- Installing psr/http-message (2.0): Extracting archive
- Installing psr/http-factory (1.0.2): Extracting archive
- Installing guzzlehttp/psr7 (2.6.2): Extracting archive
- Installing psr/http-client (1.0.3): Extracting archive
- Installing php-http/promise (1.2.1): Extracting archive
- Installing php-http/httplug (2.4.0): Extracting archive
- Installing symfony/deprecation-contracts (v2.5.2): Extracting archive
- Installing guzzlehttp/guzzle (7.8.1): Extracting archive
- Installing php-http/guzzle7-adapter (1.0.0): Extracting archive
3 package suggestions were added by new dependencies, use `composer suggest` to see details.
Generating autoload files
4 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
No security vulnerability advisories found
Using version ^1.0 for php-http/guzzle7-adapter

[DiJai]

Nach

cd /usr/local/edomi/www/admin/include/php/influx-client
composer require influxdata/influxdb-client-php guzzlehttp/guzzle

funktioniert das einmalige einlesen der Edomi-Archive mit "all" an E10 auch - nur das laufende synchronisieren der neuen edomi-Archiv-einträge leider nicht - zumindest bei mir nicht.

[Evolution100]

Hab das nochmal nachgestellt.. ist bei mir auch so, wenn ich an E10 ein all setzte und der E1 auf 1 steht, dann rennt er sofort los und kopiert einmal alles. Wenn ich aber nur mit E7 arbeite, tut sich gar nichts :-(

Gut, man könnte eine Logik anlegen, die bei E11 immer die aktuelle Zeit minus 5 min hat und das dann triggern.. dann hätte man doch, wenn ich das korrekt verstehe, nur einen 5 min Verzug? Oder man triggert das ganze nur Nachts und schaufelt dann alles nach Influx was über den Tag angefallen ist.

jonofe lieg ich da richtig? Wäre ja so ähnlich wie der sync an E7

[jonofe]

Ja könnte man so machen. Ist halt nur ein Workaround.
Da ich selbst kein Proxmox einsetze kann ich leider nichts dazu sagen, warum die eigentliche Funktion nicht ausgeführt wird.
Liegt aber vermutlich daran, dass in mysql die Procedure oder der Trigger nicht ausgeführt wird.

[Evolution100]

Danke für die schnelle Rückmeldung. Ich kann gerne Tester spielen, aber mit meinem rudimentären Linux und MySQL wissen werde ich Dir nicht wirklich eine Hilfe sein können. Ich setzte erstmal auf den Workaround! Danke für die Hilfe und auch den LBS!

[starwarsfan]

Hallo miteinander

Da ich selbst kein Proxmox einsetze kann ich leider nichts dazu sagen, warum die eigentliche Funktion nicht ausgeführt wird.
Liegt aber vermutlich daran, dass in mysql die Procedure oder der Trigger nicht ausgeführt wird.

Ich habe den Verdacht, dass das an der wesentlich aktuelleren MySQL resp. MariaDB-Version liegt, ist das möglich?

jonofe Du könntest das lokal einfach in einem Docker-Container nachstellen, dort ist ja die gleiche Version installiert, wie im LXC-Template.

[jonofe]

Im Docker Container funktioniert doch der MQTT Publish Server, wenn ich mich richtig an die Diskussion erinnere, oder? Und dafür ist auch die MYSQL_UDF Library notwendig und wird ja m.W. schon im Image bereitgestellt. Wenn der also funktioniert, gäbe es zumindest keinen Grund bzgl. MariaDB Version, warum das mit dem Influx LBS nicht funktionieren sollte. Sind denn dieselben Installationen auch im Proxmox LXC Image mit drin?

[starwarsfan]

Ja, das Setup ist im Docker-Image und LXC-Container identisch.

[Evolution100]

Ja könnte man so machen. Ist halt nur ein Workaround.

Sorry jonofe ich muss zur Sicherheit nochmal was fragen.. wenn ich den Workaround nutzten würde und das Startdatum immer beim aktuellen Tag 00 Uhr lasse, dann datet er bereits geschriebene Datensätze nur ab und legt diese nicht irgendwie doppelt an, oder?

[jonofe]

wenn ich den Workaround nutzten würde und das Startdatum immer beim aktuellen Tag 00 Uhr lasse, dann datet er bereits geschriebene Datensätze nur ab und legt diese nicht irgendwie doppelt an, oder?

ja genau!

[starwarsfan]

Hallo und gesundes neues Jahr miteinander!

Es gibt seit ein paar Minuten neue Versionen der LXC-Templates, siehe hier. Wer mag, bitte damit nochmal explizit prüfen, ob sich der Baustein jetzt anders resp. korrekt verhält.

[GermanSniper]

Hi,

hab wohl das selbe Problem das der LBS für das einmalig schreiben funktioniert aber nicht die Archive welche an E7 konfiguriert sind. Nutze auch das LXC Template Version 2.03.7.
Gibt es hierfür schon eine Lösung?

Grüße

[starwarsfan]

Hi

Gibt es hierfür schon eine Lösung?

Ja, gibt es. Die aktuelle Version des Images verwenden, siehe Changelog...