Einfaches Logging von Telegrammen

[tobo]

Hallo zusammen,

ich habe jahrelang meine KNX-Telegramme mit Edomi geloggt und in Elasticsearch verarbeitet. Ich möchte Edomi nun abschalten, und suche nach einer simplen und zuverlässigen Möglichkeit, die Telegramme in eine Datei zu schreiben und von dort aus weiter zu verarbeiten.

An sich scheint mir die Antwort klar: knxd / knxtool. Nur leider bekomme ich es nicht hin, dass die Ausgabe der Werte nicht Hexadezimal erfolgt:

knxtool groupsocketlisten ip:localhost > /tmp/knxlogtest.log

Write from 1.1.77 to 3/1/9: 0C 1A
Write from 1.1.52 to 6/0/14: 00
Write from 1.1.12 to 9/1/0: 00 00 00 00
Write from 1.1.12 to 9/1/5: 41 58 00 00
Write from 1.1.98 to 0/2/3: 36 1A
Write from 1.1.6 to 1/1/171: 00
Write from 1.1.98 to 0/2/2: 54 0B
Write from 1.1.12 to 9/1/6: 43 43 33 33​

Hat jemand einen Tipp wie sich die Ausgabe von knxd so ändern lässt dass die Werte lesbar ausgegeben werden? Smurf ? Ich fürchte ich bin nicht mehr so auf dem Laufenden wie vor ein paar Jahren als ich alles aufgebaut habe.

Wie sieht es ansonsten mit andern Möglichkeiten aus?
- Ich wäre offen dafür ein notfalls ein IP-Interface zu kaufen welches die Telegramm zwecks Logging separat irgendwo hinschreibt, gibt es da was?
- Software zu installieren (Linux) wäre mir auch recht, evtl IOBroker mal anschauen, Homeassistant mit KNX Anbindung ist auch vorhanden
Aber etwas simples, wartungsfreies und zuverlässiges wie knxd wäre perfekt.

Danke euch schonmal für eure Hilfe!

[Smurf]

knxtool ist nicht fürs Datenloggen geeignet. Es kann genausowenig wie der knxd selber eine Spannung von einer Temperatur von einem Zähler unterscheiden. Das ist nicht sein Job.

Der einfachste Weg: verwende Python und das xknx-Modul.

[Tru]

suche nach einer simplen und zuverlässigen Möglichkeit, die Telegramme in eine Datei zu schreiben und von dort aus weiter zu verarbeiten.

Hat jemand einen Tipp wie sich die Ausgabe von knxd so ändern lässt dass die Werte lesbar ausgegeben werden?

linknx wäre allenfalls eine Möglichkeit. Im xml Konfigfile musst du für jede GA den Typ definieren, womit dann im Log der lesbare Wert ausgegeben wird. Du kannst dann auch pro Objekt ein eigenes Log für die Werte führen. linknx verbindet sich mit knxd und bekommt so alle Telegramme.

Othmar

[ewfwd]

InfluxDB mit Telegraf wäre auch ne Möglichkeit. Aber da müssen die GAs erst hinterlegt werden mit ner config Datei. also bisschen aufwand ist das schon dafür kann man es später auswerten mit grafana beispielsweise

[tobo]

Danke euch für die Ideen, ich werde das in den nächsten Tagen mal testen.

[Smurf]

Um eine Konfigdatei "welche GAs bedeuten was" kommt man so oder so nicht herum. Die Idee, erstmal alles in die Influx zu pfeifen und danach die Auswertung zu machen, wenn man dazu Lust hat, funktioniert hier nicht.

So rein theoretisch gibt es diese Konfig schon, nämlich die Datei der ETS, mit der das System konfiguriert wurde. Nur leider gibt's keine freie Software, um die auseinanderzunehmen. XML mit x-fachen indirekten internen Verweisen (natürlich als Text, den man erst auseinanderpflücken muss) ist ehrlich gesagt ziemlich spaßbefreit.

[meti]

Nur leider gibt's keine freie Software, um die auseinanderzunehmen.

Oh doch 😉 https://github.com/XKNX/xknxproject
gibt auch irgendwo ein Repo das das benutzt um ein Config-file für Telegraf zu generieren.

XML mit x-fachen indirekten internen Verweisen (natürlich als Text, den man erst auseinanderpflücken muss) ist ehrlich gesagt ziemlich spaßbefreit.

Da geb ich dir zu 100% recht 🙃 besonders weils keine ordentliche, frei zugängliche Dokumentation dafür gibt 🙄

[DirtyHarry]

XML mit x-fachen indirekten internen Verweisen

Naja, wenn es sich nur um die Liste der GA mit den Datentypen dreht, gibt es schon einfachere Listen, als das aus der knxproj raus zu holen.
Selbst der CSV-Export der Gruppenadressen (Nicht ETS3) beinhaltet die Datentypen:

"Rollo Zentral Fahrt"    "0/2/1"    ""    ""    ""    "DPST-1-8"    "Auto"

Das Gleiche gilt für den XML-Export:

<GroupAddress Name="Rollo Zentral Fahrt" Address="0/2/1" DPTs="DPST-1-8" />

Die ESF-Datei (OPC-Export) beinhaltet nur die EIS-Typen:

Zentrale Befehle.Rolladen.0/2/1    Rollo Zentral Fahrt    EIS 1 'Switching' (1 Bit)    Low

(ESF und CSV sind Tab-getrennt, bzw. bei CSV wählbar)

Bei CSV und XML sind halt auch unbenutzte GAs und die Haupt-/Mittelgruppen drin. Diese haben dann keine Datentypen und müssten ausgefiltert werden. Zudem müssen die Datentypen entweder durch das verknüpfte KO vorgegeben oder per Hand nachgepflegt worden sein.
Bei der ESF sind nur die benutzten GAs drin. Die EIS-Typen stehen aber immer drin (soweit einer sich zuordnen lässt). Beispiel einer Szene, bei der kein Datenyp zugeordnet ist:

Rolladen.Szenen.2/5/0    Gruppe Süd    Uncertain (1 Byte)    Low

Aus einer dieser Dateien sollte sich mit relativ wenig Aufwand und ein bisschen "Magie" in der bevorzugten Programmiersprache ein Tool für ein Konfig-File bauen lassen.

[tobo]

Tatsächlich war ich vor einiger Zeit auch schon erfolgreich mit Node-Red und node-red-contrib-knx-ultimate. Dort kann man den OPC-Export einfügen und an sich funktioniert es, die Telegramme dann einfach in eine Textdatei schreiben zu lassen. Die wird dann per Filebeat an Logstash übertragen und dort per Lookup verarbeitet.

Was leider - trotz korrekt eingetragener KO und Datentypen - nicht funktioniert sind DPT13 oder 14 (z.B. KWh). Obwohl die auf dem Bus korrekt sind (z.B. im Gruppenmonitor geprüft), landen die in der Logdatei immer als 0.

Ich versuche mich gerade an xknx, das scheint genau das zu machen was ich erreichen will.

[tobo]

Aus einer dieser Dateien sollte sich mit relativ wenig Aufwand und ein bisschen "Magie" in der bevorzugten Programmiersprache ein Tool für ein Konfig-File bauen lassen.

Ich habe hierzu irgendwann mal eine Excel-Tabelle erstellt, in die ich auf dem ersten Tab einfach die OPC-Datei einfüge, dann wird mit ein bisschen Logik (um neue Einträge zu berücksichtigen) auf dem nächsten Tab die komplette Datei nach und nach mit allen anderen Informationen die ich pro GA haben will (Raum, Stockwerk, Gewerk, Datentyp etc) angereichert und alle paar Monate mal aktualisiert. Daraus bastele ich im dritten Tab dann die Zeilen genau so wie ich es für die Lookup Datei brauche. Etwas umständlich, funktioniert aber und ist vom Aufwand her nach dem ersten Brocken absolut vertretbar.