Gibt es einen LBS, um Meta-Daten zu einem KO zu erhalten?

[ruppsn]

Hallo,

gibt es einen LBS oder eine andere Möglichkeit in EDOMI zu einem KO Metadaten zu erhalten?

Was habe ich vor?

Ich würde gerne in EDOMI mit wenig Aufwand den Inhalt einiger GAs strukturiert in eine InfluxDB schreiben, um mir die Veränderungen im Zeitverlauf anschauen und auswerten zu können. Ich könnte zwar mit Telegraf und dem KNX Go Plugin sowas direkt machen, allerdings würde ich gerne sämtliche "Logik" in EDOMI haben.

Daher wäre es praktisch, wenn es ein System-KO gäbe, dass das aktuell empfangene KO bzw. dessen Sender-GA als Wert enthielte oder einen LBS, der zu einer GA die Meta-Daten aus des zugehörigen, in EDOMI definierten KO in den internen Datenbanken zurückliefert (GA, DPT, Wert, Edomi KO-Name).

Dann wäre es ein Leichtes eine generische Umsetzung zu schreiben, die dann strukturiert in eine InfluxDB schreibt, bspw. (Influx Line Protocol):
KO-Name,groupaddress="5/5/4",source="1.1.12",unit="lux",dtp=7.012 value=17.889999389648438

Gibt es sowas bzw. wäre sowas vorstellbar?

[jonofe]

Dann wäre es ein Leichtes eine generische Umsetzung zu schreiben, die dann strukturiert in eine InfluxDB schreibt, bspw. (Influx Line Protocol):
KO-Name,groupaddress="5/5/4",source="1.1.12",unit="lux",dtp=7.012 value=17.889999389648438

Gibt es sowas bzw. wäre sowas vorstellbar?

Wenn man mal source, unit und dpt außen vor lässt, dann könnte das mit iKO-ID/KNX-GA, Name und Value ähnlich funktionieren, wie im MQTT Publish Server. D.h. eine MySQL Stored Procedure, die bei jedem iKO/GA Update ein PHP Skript (LBS) aufruft, welches dann die Daten nicht per MQTT published sondern auf Ausgänge oder direkt nach Influx schreibt. Bei der Wahlen von "Ausgängen" könnte man diese dann in Datenarchive schreiben, welche dann nach Influx gesynct werden.

[ruppsn]

Hi und danke für die schnelle Antwort. Das schaue ich mir mal an. Wäre es nicht eine Überlegung Wert den Stored Procedure Mechanismus generischer zu halten und quasi einen (oder zwei, s.u.) LBS zu basteln (der von der SP aufgerufen wird) und einfach nur iKO-ID, KNX-GA, Name und Wert als Ausgänge bereitstellt? Dann hätte man die Flexibilität sich an diese Hooks zu hängen, beliebig weiterzuverarbeiten (MQTT Publishing, InfluxDB oder oder oder) und erspart sich pro Anwendungsfall eine SP zu basteln, sondern hat nur eine bzw. zwei (iKO und KNX-GA).

Stored Procedures heißen bei MySQL UDF (user defined functions), richtig? Ich habe mir auch schon mal Deinen Fork der lib_mysqludf_sys angesehen, verstehe aber gerade nicht, was die anderes macht als das "original". Oder anders gefragt, wozu braucht man die? Erweitert man mysql damit um die grundsätzliche Stored Procedure Funktionalität?

Ansonsten habe ich Deinen LBS soweit nachvollziehen können - glaube ich . Grob zusammengefasst wäre für obiges Unterfangen relevant:
- Abhängig vom Triggern (E1) in einer Edomi-Logik wird im LBS im LBS-Abschnitt nur die Stored Procedure installiert oder entfernt. Es wird der LBS selbst nicht aufgerufen (weil ja auch keine GA / iKO Informationen vorliegen)
- Die Trigger (auf insert und update auf den entsprechenden Edomi Datenbanken) rufen dann schließlich den Baustein über die Shell aus auf, was dann den EXEC Abschnitt ausführt. Als Command Line Args werden entsprechend die iKO-ID bzw. KNX-GA, Name und Wert übergeben.
- Die Command Line Argumente werden im EXEC Abschnitt des LBS dann über argv[] referenziert und müssten dann ja eigentlich nur noch auf die Ausgänge gesetzt werden, oder?

Habe ich das so in etwa richtig umrissen?

Ich hoffe, es ist okay, wenn ich auf Basis Deines LBS mal einen generischen iKO-Listener LBS und einen generischen GA-Listener LBS schreibe. Ich würde beide trennen (Separation of concerns) und dann einfach an die Ausgänge die entsprechenden Infos leiten. Filtern etc. kann man dann ja später noch ergänzen oder durch nachgeschaltete LBS.

Danke nochmal für den Hinweis, da wäre ich sonst nicht weitergekommen.

VG, Stephan

[starwarsfan]

Hallo Stephan

Ich würde gerne in EDOMI mit wenig Aufwand den Inhalt einiger GAs strukturiert in eine InfluxDB schreiben, um mir die Veränderungen im Zeitverlauf anschauen und auswerten zu können.

Mit anderen Worten: Du willst einen Busmonitor bauen, oder?

[ruppsn]

Hallo Yves,
Gruppenmonitor würde mir reichen ;-) Naja, mich interessiert tatsächlich in dem Anwendungsfall weniger die Reihenfolge von unterschiedlichen GAs und ob bzw. wann welches kommt bzw. in dem Sinne nicht, was alles auf dem Bus los ist, sondern eher der Komfort nicht für jede GA (iKO) Bausteine auf Logikblätter zu ziehen und wie blöd zu duplizieren. So kann ich auf einer Logikseite mit einem solchen Baustein und einem LBS zum InfluxDB Schreiben eine ganze Schar von gleichartigen GAs wegschreiben und erspare mir das eigentlich etwas überflüssige Rumklicken (Eingangsbaustein für GAs, die mich interessieren; measurement, tags und values händisch in den InfluxWriter LBS einzutragen) - die Infos liegen ja schon vor.

Auch wenn es nur um die Werte geht, für die eine Verlaufsmessung interessant sein könnte (Temperaturen, Luftfeuchtigkeiten, Helligkeiten, Leistungsaufnahme....), spart man sich selbst bei einem normalgroßen EFH schon einiges an Konfigurierarbeit (und Wartung) und verringert gleichzeitig die Fehleranfälligkeit durch Copy/Paste.

[starwarsfan]

Hi

Gruppenmonitor würde mir reichen ;-)
...
Auch wenn es nur um die Werte geht, für die eine Verlaufsmessung interessant sein könnte (Temperaturen, Luftfeuchtigkeiten, Helligkeiten, Leistungsaufnahme....), spart man sich selbst bei einem normalgroßen EFH schon einiges an Konfigurierarbeit (und Wartung) und verringert gleichzeitig die Fehleranfälligkeit durch Copy/Paste.

Da lobe ich mir doch den Timberwolf Server, da wird out of the Box alles aufgezeichnet und kann nach allen Regeln der Kunst analysiert, gefiltert und dargestellt werden...

[ruppsn]

Ja, das verstehe ich. Ich glaube, dass das bei IPSymcon auch mit einem Klick geht. Bei iobroker ist es wohl auch recht schnell getan. Hilft mir nur gerade bei Edomi nicht :-) ... und der Timberwolf kostet ja auch nen Euro :-)

jonofe s MQTT Publisher Server hat aber eigentlich schon die Lösung parat. Da muss man nur ein bissl den MQTT-Teil rausschmeißen, dann sollte das gehen. Bin gerade dabei und warte darauf, dass mein Edomi Docker Container (nach Deinem Image ;-) ) gesnapshotet wird. Dann kann ich es mal ausprobieren. Sollte es klappen, hat es in Summe 2h Stunden gedauert. Ich finde das geht und spricht für die Erweiterbarkeit und Flexibilität von Edomi.

[jonofe]

MQTT Publisher Server hat aber eigentlich schon die Lösung parat. Da muss man nur ein bissl den MQTT-Teil rausschmeißen, dann sollte das gehen. Bin gerade dabei und warte darauf, dass mein Edomi Docker Container (nach Deinem Image ;-) ) gesnapshotet wird. Dann kann ich es mal ausprobieren. Sollte es klappen, hat es in Summe 2h Stunden gedauert. Ich finde das geht und spricht für die Erweiterbarkeit und Flexibilität von Edomi.

Mir ist da gerade noch eine einfachere Möglichkeit in den Sinn gekommen, die ich gerade mal teste ...

[kingolli]

Hallo.

ich nutze bei mir die Notizen zu den KOs ,siehe hier , das schreibe ich minütlich in die InfluxDB. Ist halt nicht Push, aber vielleicht kannst du damit was anfangen.

Grüße
David

[ruppsn]

Hallo.
ich nutze bei mir die Notizen zu den KOs ,siehe hier , das schreibe ich minütlich in die InfluxDB.

Hi David,
ich muss gestehen, dass ich es beim ersten Mal Lesen nicht ganz verstanden habe, aber ich nehme an, dass Du ein Vorgehen meinst wie hier beschrieben?

Grüße
Stephan

[jonofe]

Mir ist da gerade noch eine einfachere Möglichkeit in den Sinn gekomme

Dabei ist der LBS 19002645 "KO Monitor" herausgekommen. Er funktioniert ähnlich zum MQTT Publish LBS, nur viel einfacher, da keinerlei Zusatz-Installationen notwendig und auch kein EXEC Skript benötigt. Die MySQL Procedure schreibt einfach die iKO/GA-Daten in ein an Eingang E2 definiertes iKO und zwar in JSON oder CSV Format, wobei der Separator des CSV über E4 gesetzt werden kann.

E1=0 löscht Procedure und Trigger und stoppt somit das Monitoring.
E2=Edomi ID des Ziel-iKOs, in dass die iKO/GA Daten geschrieben werden sollen
E3=CSV|JSON je nach gewünschtem Format
E4=Separator für den CSV Output Default ist das Semikolon

Ich werde mal sehen, ob ich den MQTT Publish Server auch entsprechend umbaue. Der bräuchte dann im Zielzustand ggf. nur noch das iKO, welches hier an E2 spezifiziert wurde als Eingang.

[ruppsn]

Dabei ist der LBS 19002645 "KO Monitor" herausgekommen.

Top, funktioniert bei mir prima. Vielen Dank!

[kingolli]

Hallo zusammen.

Falls mal jemand -wie ich gerade- das Problem hat, dass man den Trigger nicht anlegen kann ("Error 1359 Trigger already exists"), aber er nicht angezeigt wird und auch nicht gelöscht werden kann (das kommt wohl nach einem SQL Dump vor!): man muss dann im Datenbank Verzeichnis (bei mir /var/lib/mysql/edomiLive/) die entsprechende .TRN Datei löschen. Ab dann kann man den Trigger wieder per mysql anlegen/löschen.

Grüße
David