Suche Lösung zur Aufzeichnung/Historisierung KNX-Busverkehr

[wknx]

Nabend zusammen,

ich suche nach einer Möglichkeit dauerhaft den KNX-Busverkehr mitzuschneiden. Wobei mich da gar nicht der ganze Busverkehr interessiert, sondern eigentlich nur alle Schreibzugriffe auf Gruppenadressen. Ziel ist eine Historisierung zur späteren Auswertung.

Bevorzugt würde ich das gerne auf OpenHabianPi realisieren, da sowieso schon für Anbindung von Homematic vorgesehen. Hätte aber gerne alle Gruppenadressen mit drin, auch ohne dass diese explizit konfiguriert werden.

Ideale Datensenke wäre wohl eine Datenbank speziell für Zeitreihen. InfluxDB kann nach meiner Interpretation von https://www.openhab.org/addons/persi...base-structure jedoch nur Ganzzahlen und Fließkommazahlen speichern. rrd4j hat die gleiche Einschränkung https://www.openhab.org/addons/persistence/rrd4j/ und ich sehe dort zumindest spontan auch keine Möglichkeit die „Kompression“ genauer zu konfigurieren.

Evtl. gibt es auch einen Weg das direkt über knxd zu realisieren. Mangels (für mich auffindbare) Dokumentation zu den knxtools konnte ich da aber auch nichts zu finden.


Habt Ihr da irgendwelche Tipps für mich in welche Richtung ich schauen soll, oder gibt es dafür sogar schon fertige Lösungen?


Gruß
Wilhelm

PS: Irgend eine Anforderung habe ich in der Auflistung womöglich noch vergessen. Nehmt es mir nicht übel wenn ich die ggf. in Antworten noch ergänze ;-)

[ArPa]

Hi!

Nur um sicher zu gehen, wenn Du das in dem openHAB Unterforum postest, meinst Du nur Schreibzugriffe die über openHAB laufen richtig? Also aus Rules oder der openHAB UI oder von sonst wo, mit einem Update auf das jeweilige item/thing? Ich verstehe nämlich gerade nicht so recht das Problem.

Nehmen wir an Du hast ein item/thing, welches mit einer GA verbunden ist. Im einfachsten Fall baust Du dir eine Rule, die auf das Updated Event reagiert, liest den aktuellen Wert aus und speicherst diesen wohin immer Du willst.

Also entweder habe ich noch nicht ganz verstanden was genau die Herausforderung ist vor der Du stehst oder stelle mir das zu einfach vor ;-)

Beste Grüße,
Artur

[wknx]

Nabend Artur,
erst mal Danke für Deine Antwort.

Hi!
..., meinst Du nur Schreibzugriffe die über openHAB laufen richtig? Also aus Rules oder der openHAB UI oder von sonst wo, mit einem Update auf das jeweilige item/thing?

Nein. Ich hätte gerne alles. Auch GAs die in openHAB nicht bekannt sind.

Sowas ließe sich wohl nur mir einer "Universal"-Rule lösen, sofern es bei openHAB sowas gibt.

Vielleicht ist das mit openHAB auch gar nicht möglich. Sollte ich dann besser im Allgemeinen Forum noch mal fragen?

Gruß
Wilhelm

[udo1toni]

Es gibt dafür zwei verschiedene Möglichkeiten, die aber beide nicht schön sind (wir reden über eine Lösung in openHAB):

1. Du versetzt das Logging für das knx Binding in den TRACE Modus und legst einen eigenen Logger für das knx Binding an. Du bekommst alle Buszugriffe geloggt, ob die GA nun in openHAB bekannt sind oder nicht. Allerdings bekommst Du auch jede Menge "Müll" der Dich nicht interessiert, den musst Du dann aus dem Log herausfiltern.
2. Du legst für sämtliche GA Items an (im Zweifel vom Typ String, falls der DPT nicht bekannt ist) und lässt diese mit der MySQL oder JDBC Persistence bei jedem Update wegschreiben. Allerdings ist das a) umständlich und b) ist da die Sache mit den DPT - vielleicht funktioniert noch nicht mal das String Item hier zuverlässig.

openHAB ist hierfür schlicht nicht das richtige Werkzeug.

Wenn Du ETS hast, nutze den Gruppenmonitor, der ist genau dafür gedacht.
Wenn Du kein ETS hast, verwende knxd, auch dort gibt es einen Gruppenmonitor. Das ist zwar ein Konsolentool, aber die Ausgabe kann man prima in eine Datei umleiten und mit ein paar Hilfsscripten läuft das automatisch und dauerhaft (wobei natürlich ein Tunnel durch den Gruppenmonitor belegt wird)

Vermutlich gibt es noch andere Tools, ich kenne aber nur diese beiden Varianten.

[wknx]

Es gibt dafür zwei verschiedene Möglichkeiten, die aber beide nicht schön sind (wir reden über eine Lösung in openHAB):

Wären beides keine Lösungen die so richtig sauber erscheinen.
Das Ergebnis von Ansatz 1 schafft offensichtlich wahnsinnigen Overhead.
Bei Ansatz 2 würde mich interessieren ob openHAB so gut skaliert, dass man ~65K Items verwalten kann.

openHAB ist hierfür schlicht nicht das richtige Werkzeug.

Das ist doch schon mal eine klare Aussage. Falls es aus meiner Anfrage nicht deutlich genug hervorgengen sein sollte: Ich hänge nicht an openHAB an dieser Stelle. Ich würde das ganze nur gerne mit auf einer openHabPi-Installation laufen lassen. Wenn sinnvoller auch außerhalb von openHAB.

Wenn Du ETS hast, nutze den Gruppenmonitor, der ist genau dafür gedacht.

Den kenne ich. Würde aber kein großes System mit ETS dauerhaft laufen lassen wollen.

Wenn Du kein ETS hast, verwende knxd, auch dort gibt es einen Gruppenmonitor. Das ist zwar ein Konsolentool, aber die Ausgabe kann man prima in eine Datei umleiten und mit ein paar Hilfsscripten läuft das automatisch und dauerhaft (wobei natürlich ein Tunnel durch den Gruppenmonitor belegt wird)

Hatte in der Richtung auch schon mal ein bisschen experimentiert, aber ohne nennenswertes Ergebnis. Wie kann ich den Gruppenmonitor von knxd denn aufrufen?

knxtool list

liefert zwar eine Lange Liste von Tools:

• busmonitor1
• busmonitor2
• vbusmonitor1
• vbusmonitor2
• vbusmonitor1poll
• busmonitor3
• vbusmonitor3
• vbusmonitor1time

Ich habe leider bislang keine eine Dokumentation zu diesen gefunden. Welches Tool wäre das richtige?


Schon mal vielen Dank für Deine Anregungen!

Gruß
Wilhelm

[udo1toni]

Schau mal hier: https://github.com/knxd/knxd/wiki/KnxTool#vbusmonitor1
Die Unterschiede zwischen den verschiedenen Monitoren sind da leider auch nicht erläutert, aber zumindest sollte vbusmonitor1 die Schreibvorgänge auf dem Bus (GA betreffend) anzeigen. Der Monitor läuft, bis er gestoppt wird. Du müsstest im Zweifel ein systemd-Script anlegen, welches den Befehl aufruft (mit Umleitung der Ausgaben in eine Datei) und sich natürlich auch um das Stoppen des Befehls kümmert - dazu muss die PID bekannt sein und ein entsprechender kill-Befehl abgesetzt werden. Es gibt dazu Beispiele auf den systemd-Seiten.

Das Programm schreibt die Daten einfach weg, vermutlich muss man noch etwas drum herum bauen, damit die Datei nicht zu groß wird bzw. automatisch die datei gewechselt und im Hintergrund das letzte log gepackt wird.

Was die Leistungsfähigkeit von openHAB betrifft, sollte das kein Thema sein. Du musst bedenken, dass knx selbst hier der Flaschenhals ist, die Datenmenge ist pro Linie auf 9600Bit/Sec begrenzt. Selbst auf einem knx Backbone einer großen Firma können maximal 10MBit/Sec unterwegs sein, und das wäre dann der Punkt, an dem der knx-Bus aussteigt. openHAB ist locker in der Lage, einen oder auch mehrere knx-Linien zu 100% auszulasten, und dabei läuft openHAB dann immer noch in Grundlast.
Aber wie gesagt, openHAB ist für die Aufgabe eher ungeeignet.

[ArPa]

Ggf. bietet auch das hier eine Lösung? https://knx-user-forum.de/forum/supp...ctor-beta-test

[wknx]

Schau mal hier: https://github.com/knxd/knxd/wiki/KnxTool#vbusmonitor1

vbusmonitor1 schaut schon mal ganz gut aus. Vielen Dank!

So richtig testen konnte ich das ganze bisher leider noch nicht.

Was ich allerdings schon feststellen musste: Direkt auf dem Raspberry mit OpenHabian konnte ich die knxtools leider nicht erfolgreich ausführen:

openHABianPi:~$ knxtool vbusmonitor1 ip:localhost
Open failed: Connection refused

(auch wenn nicht wenn ich direkt die IP eingebe die in der Konfiguration von OpenHab auch für die Bereitstellung der Schnittstelle nach außen angegeben habe.)
Von einem anderen System auf dem ich knxd laufen habe funktioniert es allerdings lokal. In sofern wird das Thema wohl irgendwie mit Openhabianpi zusammenhängen.

Was die Leistungsfähigkeit von openHAB betrifft, sollte das kein Thema sein. [...] openHAB ist locker in der Lage, einen oder auch mehrere knx-Linien zu 100% auszulasten, und dabei läuft openHAB dann immer noch in Grundlast.

Von der nötigen Bandbreite hatte ich da auch keine Bedenken. Eher von Konfigurativer Seite, falls man tatsächlich für jede Adresse eine Regel hätte anlegen müssen.

[ArPa]

Von der nötigen Bandbreite hatte ich da auch keine Bedenken. Eher von Konfigurativer Seite, falls man tatsächlich für jede Adresse eine Regel hätte anlegen müssen.

Glaub mir, das willst Du nicht

[udo1toni]

Direkt auf dem Raspberry mit OpenHabian konnte ich die knxtools leider nicht erfolgreich ausführen:

Hast Du mal versucht, ob die knxtools mit sudo laufen? Manchmal hapert es bei solchen Fehlern einfach an den passenden Rechten, wenn es mit sudo geht, hast Du einen heißen Bereich, wo Du forschen musst.

[wknx]

Hast Du mal versucht, ob die knxtools mit sudo laufen?

Hatte ich bislang nicht explizit geprüft, da es auf einem anderen System ohne root-Rechte läuft.

Macht auf OpenHabianPi allerdings keinen Unterschied:

openhabian@openHABianPi:~$ sudo knxtool vbusmonitor1 ip:localhost
[sudo] password for openhabian:
Open failed: Connection refused

Noch andere Ideen?

[udo1toni]

hmmm... du könntest es auch noch mal als user root versuchen, evtl. dropt knxtool die Rechte, also mit
sudo su zu root werden und anschließend den Befehl absetzen. Aber vermutlich wird auch das nicht funktionieren, denn die knxtools sollten natürlich keine root-Rechte erfordern, egal auf welcher Maschine.
Du könntest auf github im knxd-repo nachfragen, vermutlich gibt es da mehr Leute, die das einsetzen.

[wknx]

[…]noch mal als user root versuchen[…], also mit sudo su zu root […] Aber vermutlich wird auch das nicht funktionieren

Funktioniert tatsächlich wie erwartet nicht…

Du könntest auf github im knxd-repo nachfragen, vermutlich gibt es da mehr Leute, die das einsetzen.

Irgendwie habe ich eher den Eindruck, dass es hier an der konfiguration von knxd über OpenHAB liegt. Auf dem System auf dem es läuft habe ich knxd direkt konfiguriert.

Btw.: vbusmonitor1time ist noch besser geeignet, da es noch jeweils einen Timestamp voranstellt :-)
Bedient sich laut Quellcode ansonsten der selben Funktion um Daten vom bus zu lesen…

[udo1toni]

Super! Grundsätzlich sollte es doch möglich sein, knxd frei zu konfigurieren?! openHAB2 selbst "kennt" kein knxd, allenfalls ist also eine Konfiguration von den openHABian Scripten eingerichtet, aber die sollte doch genauso funktionieren, wie bei einer "normalen" Installation? Du müsstest also nur schauen, was Du bei Dir auf dem anderen System anders konfiguriert hast.