[Beta][Modul] KNXDeviceTools

Symcon PHP-Module (Diskussion)
1

KNX Device Tools für IP-Symcon

Die KNX Device Tools Gruppen bieten verschiedene Module für IP-Symcon, die darauf ausgelegt sind, KNX-Telegramme zu überwachen, zu filtern und automatisch Variablen für definierte Geräte und Gruppenadressen zu erstellen. Diese Module unterstützen eine Vielzahl von KNX-Datentypen (DPTs) und erleichtern die Integration von KNX-Geräten in IP-Symcon.

Aktuell stehen folgende drei Module zur Verfügung:

  • KNXDeviceTickMonitor

  • KNXDeviceTrigger

  • KNXDeviceWatcher

  • KNXTrafficLogger

KNXDeviceTickMonitor: Dieses Modul ermöglicht die Überwachung mehrerer Gruppen- und Geräteadresskombinationen im KNX-Datenfluss. Für jede Kombination wird eine Variable unterhalb des Moduls erstellt. Die Variable wird für die im Modul konfigurierbare Tick-Länge auf „True“ gesetzt, wenn eine gefilterte Gruppen- oder Geräteadresskombination im KNX-Datenfluss erkannt wird. Anschließend fällt die Variable auf „False“ zurück. Dieser „Tick“ kann dann mit den Standard-Symcon-Tools (wie Ereignissen) weiterverarbeitet werden.

KNXDeviceTrigger: Auch mit diesem Modul können mehrere Gruppen- und Geräteadresskombinationen im KNX-Datenfluss überwacht werden. Es richtet sich besonders an Benutzer, die eigene Module entwickeln möchten. KNXDeviceTrigger kann Ereignisse basierend auf Gruppen- oder Geräteadresskombinationen aus den KNX-Telegrammen direkt an andere Module weiterleiten oder Funktionen anderer Module auslösen. Dieses Modul ermöglicht es, den Umweg über die Erstellung von Variablen zu umgehen.

KNXDeviceWatcher: Das Modul KNXDeviceWatcher funktioniert grundsätzlich ähnlich wie der KNXDeviceTickMonitor, jedoch mit dem Unterschied, dass die Variablen unterhalb des Moduls direkt mit den Daten aus dem KNX-Datenfluss befüllt werden. Die Daten werden automatisch übernommen. Es wird jedoch empfohlen, die Daten aus den integrierten KNX-Modulen von Symcon zu verwenden, da die unterstützten Datentypen in diesem Modul begrenzt sind. Für die DPT der Gruppe 1.001 gelten auch die gleichen Werte für 1.002 und ähnliche Gruppen, wobei sich die Einheiten unterscheiden. Das gleiche gilt für die DPT 9.001.

KNXTrafficLogger: Dieses Modul dient zur Protokollierung des gesamten KNX-Telegrammverkehrs in Dateien. Alle empfangenen Telegramme werden im JSONL-Format (eine Zeile pro Telegramm) gespeichert und enthalten Zeitstempel, Gruppenadresse (GA), Geräteadresse, Nutzdaten sowie den erkannten APCI-Typ (read/write/response).

Wieso, weshalb, warum?

KNX überträgt Informationen grundsätzlich über Gruppenadressen. Ein wesentlicher Nachteil dabei ist, dass aus einem Telegramm nicht direkt ersichtlich ist, welches Gerät der Absender ist. In einigen Situationen – insbesondere in der Hausautomation – kann es jedoch sehr hilfreich sein zu wissen, welcher Schalter den Impuls ausgelöst hat.

Befinden sich mehrere Schalter auf derselben Gruppenadresse, lässt sich in einem klassischen KNX-Setup nicht erkennen, welcher Schalter tatsächlich betätigt wurde. Um dieses Problem zu lösen, müsste für jeden Schalter eine eigene Gruppenadresse definiert werden. Das kann jedoch schnell zu komplexen Strukturen führen.

Auch in Symcon-Modulen müssten entsprechend mehrere Gruppenadressen angelegt werden, um dieses Verhalten korrekt abzubilden. Deutlich einfacher ist es hingegen, das KNX-Telegramm direkt auf den Absender auszuwerten. In Kombination aus Gruppenadresse und Geräteadresse kann damit exakt nachvollzogen werden, welcher Schalter wann welchen Befehl gesendet hat.

Der Auslöser für diese Überlegung war bei mir ein Modul zur Steuerung meiner Raffstores. Die Steuerung läuft vollständig automatisiert. Ich wollte jedoch erreichen, dass die Automatik für einen definierbaren Zeitraum unterbrochen wird, sobald ein Bewohner den physischen Schalter betätigt. Es war mir schlicht zu umständlich, die Automatik ständig über die Weboberfläche eines Terminals deaktivieren zu müssen.

Danksagung an das Symcon-Team

Ich möchte mich herzlich beim gesamten Symcon-Team bedanken, das das KNX-Gateway um wichtige Eigenschaften erweitert hat, um die Nutzung der neuen Module zu ermöglichen. Diese Funktionalität steht nun allen Anwendern zur Verfügung, die die Version 8.2 oder höher von Symcon verwenden. Eure Arbeit hat einen erheblichen Beitrag dazu geleistet, den Funktionsumfang für unsere KNX-Anwendungen weiter zu verbessern!

Vielen Dank für eure kontinuierliche Unterstützung und hervorragende Arbeit!

5 „Gefällt mir“
Physikalische Adresse in Ereignis abgreifen
2

Hi, dein Modul hört sich interessant an. Bisher hate aber noch keinen Anwendungsfall für deine Module.

Ich stelle mir aber gerade die Frage, ob es mit IPS möglich wäre ein Logging der Telegramme auf dem Bus zu erstellen, so wie es auch mit dem Gruppenmonitor der ETS möglich ist? Wenn dies auch noch ein importierbares XML Format hätte, dann könnte man es auch im Gruppenmonitor im Portieren.

Grüße André

3

Hallo bambam,

mir erschließt sich noch nicht warum man parallel ein Logging aufbauen sollte, was in der ETS schon funktioniert. Ich hatte vielmehr überlegt eine Statistik zu generieren welche Geräte/Gruppenadressen im Netz am meisten genutzt werden. Einfach nur aus Interesse was im Netz am meisten genutzt wird. Bei Zeiten werde ich das mal einbauen. Außerdem hatte ich in der Vergangenheit vor ein Tool “Wer hat das Licht eingeschaltet” einzubauen. Aber laut der letzten Symcon Konferenz wird das Tool in breiter Form bald sowieso kommen. Daher erübrigt sich das. Am Ende kann mit Hilfe meines Modul via Scripting in Symcon alles individuell rausgezogen werden - auch das Logging, wenn es denn so sein soll.

4

Ich habe in entfernten Installationen keine ETS und in meiner eigenen die ETS auf meinem Laptop, der sporadisch nicht an ist oder keine Verbindung hat. Wenn man da für ein paar Tage ein loggin braucht, wäre das schon gut. Jetzt kann IP-Symcon den Debug einer jeden Instanz in eine Datei schicken (über die Konsole aktivierbar). Ein kleiner Konverter würde ggf. schon reichen.

5

Ja, ok, den Use-Case kann ich dahingehend nachvollziehen. Nur, so ein Log kann unter Umständen ganz schön groß werden. Ich habe bei mir beispielsweise Wetterstationen und zig Temperatursensoren mit auf dem KNX - da kommen eine Menge Daten. Im Vorfeld weis man häufig nicht was da am Ende bei raus kommen kann - oder man vergießt, dass da ein Logging eingeschaltet ist. Das kann das System lahm legen. Da ist dann sicher eine rollierende Protokollierung und/oder ein Selbstausschalter hilfreich. Man sieht, dass da noch etwas mehr hinter steckt als nur einfach die vorhandenen Daten wegzuspeichern. Ich nehme das mal in die ToDo Liste auf.

6

So ein Logging ist sehr hilfreich bei der Fehlersuche von sporadischen Ereignissen. Der Monitor oder der Rechner mit der ETS läuft ja nicht immer mit. Das Logging in IPS könnte ja permanent laufen, falls es nicht zu viele Resourcen und Speicherplatz verbraucht.

Ich kenne aktuell nur den S1 von Gira, der KNX-Telegramme loggt und diese täglich in einer XML Datei ablegt.

Die beiden von dir genannten Punkten Statistik und “Wer hat etwas geschaltet”, hören sich aber auch interessant an und gerade das zweite wären bei einer Fehlersuche hilfreich.

Ich installiere mir bei Gelegenheit mal dein Modul und schauen dann mal, wie man damit so ein Logging erstellen könnte. Da komme ich aber sicher nochmal auf dich zu :wink:

7

Cool :+1:

Ich würde generell täglich einen neue Datei anlegen. Wäre gut, wenn man noch die Größe der Logging-Datei prüfen könnte und und bei >xxxMB wird eine neue angelegt. Falls die Größe innerhalb von 24h ein Problem sein sollte.

8

Jau, das drum herum verursacht dann die meiste Komplexität. In Linux lässt sich so etwas über Logrotation realisieren, damit das System nicht zumüllt. In Windows gibt es da nichts. Man muss das System dann aber so aufbauen, dass auch “nichtversierte” Nutzer bei Nutzung nicht vom Überlaufen eines Systems überascht werden. Die automatischen Einrichtungen derartiger Systeme bedeuten dann viel Arbeit. Einfacher ist es dann eine einzelne Datei zu rollieren, zumal das ja auch eigentlich nur über einen definierten Zeitraum verwendet werden sollte. Naja, mal schauen was ich mit überschaubaren Aufwand machen kann.

9

Ich habe schon mal etwas tiefer reingeschaut. Ein ets kompatible Datei erfordert die Aufzeichnung von cEMI-Frame basierten Inhalten. Das würde das Nutzen/Aufwand Verhältnis sprengen. Ich kann mir vorstellen eine “jsonl” Logdatei mit Rotation und all dem zu erstellen, dass auch eine Größenkontrolle beinhaltet. Beispielinhalt wäre:

{
  "ts": "20260221-144353",
  "unix": 1769064233,
  "ga": "1/2/3",
  "pa": "1.1.15",
  "data": "01",
  "raw": "2900BCD011143A010300802432"
}

Ein solche Log Datei kann zwar nicht in die ets importiert werden, man kann diese aber mit zig anderen Tools im Nachgang analysieren und auch als Benutzer beim Öffnen direkt lesen.

Würde das ausreichen?

10

Also wenn das mit für dich vertretbarem Aufwand machbar ist, dann fände ich das auf jeden Fall gut :+1:

Man kann in so einer Datei ja dann auch leicht nach einer GA suchen und schauen, wer diese GA, wann gesendet hat und so sehen, ob das von IPS kam oder von einem KNX Gerät.

Wenn IPS auf der Symbox läuft und man von einem Win-Rechner die Datei ansehen will, dann ist das zwar mit Putty immer etwas umständlich, aber daran kannst du ja nix ändern. Und so häufig wird es ja auch nicht vorkommen, dass man sich die Datei ansehen möchte.

Ist aber auf jeden Fall hilfreich, wenn sowas im Hintergrund mitläuft und man bei Bedarf darauf zugreifen kann.

Hast du ein Gefühl dafür wie viele Telegramm in so eine Datei passen, bevor die ältesten überschrieben werden? Je nach Installation kommen da ja so 4…20k zusammen.

11

Bei 100.000 Einträgen wie vorherigen Beitrag dargestellt, wären das etwa 12MB. Das lässt sich noch gut mit Notepad++ etc öffnen. Was da an Daten zusammen kommt ist jedoch sehr individuell. Da muss man dann gerade am Anfang etwas den Blick drauf haben und die Parameter nachstellen. Im Modul werde ich dann ein paar Standardparameter vordefinieren wie beispielsweise Menge an Zeile je Datei und die Anzahl der Logdateien bis die alten gelöscht werden sollen. Je nach Leistungsfähigkeit des Systems kann man dann selbst skallieren.

1 „Gefällt mir“
12

Klasse, dass du das direkt angehst!

Ich teste es dann gerne, wenn es soweit ist.

13

So, das zusätzliche Modul ist nun bei mir in der Alpha-Version. In Kürze gebe ich die Beta-Version raus.

1 „Gefällt mir“
14

Klasse! Ich bin schon gespannt​:hugs:

15

v0.2.0-beta4
Neues Modul „KNXTrafficLogger“ hinzugefügt, zum Logging was alles auf dem KNX Bus läuft. Die Logs werden zu einer einstellbaren zeit rotiert und alte logs nach anzugebener Zeit gelöscht.
Alle Module umgestellt auf IPSModuleStrict.
Diverse Fix zu Verbesserung der Stabilität.

KNXTrafficLogger: Dieses Modul dient zur Protokollierung des gesamten KNX-Telegrammverkehrs in Dateien. Alle empfangenen Telegramme werden im JSONL-Format (eine Zeile pro Telegramm) gespeichert und enthalten Zeitstempel, Gruppenadresse (GA), Geräteadresse, Nutzdaten sowie den erkannten APCI-Typ (read/write/response).

16

Ich werde es heute mal installieren​:+1:

Das Modul funktioniert auch stand alone?

17

Alle Einzelmodule in der Sammlung von KNXDeviceTools lassen sich eigenständig nutzen. :innocent:

18

Hallo Ian,

ich finde das ein echt hilfreiches Tool um sporadischen Anomalien aufzuspüren. Aber da scheint ja von Symcon auch noch was Neues zu kommen :slight_smile:
Bei mir kamen jetzt über Nacht ca. 1000 Telegramme/h zusammen und die Datei hatte nach 10h etwa 1Mb. Das ist ja noch absolut im Rahmen!

Ich werde bei Gelegenheit auch interessehalber den ETS Busmonitor mitlaufen lassen um zu prüfen, ob die Anzahl der Telegramme gleich ist.

Hier mal für alle, die es interessiert, wie so ein Logging aussieht beim Ein-Schalten eines dimmbaren Lichtes:

{"ts":"20260322-082912","unix":1774164552,"ga":"1/1/11","pa":"1.0.17","payload":"81","apci":"write","len":1}
{"ts":"20260322-082912","unix":1774164552,"ga":"1/4/11","pa":"1.0.3","payload":"81","apci":"write","len":1}
{"ts":"20260322-082912","unix":1774164552,"ga":"1/3/11","pa":"1.0.3","payload":"80FF","apci":"write","len":2}

Ich dachte zuerst, dass der Zustand Ein/Aus nicht in dem String enthalten ist, weil ich nicht kapiert habe, dass das in payload steckt. könntest du das vielleicht noch so wie hier darstellen? Dann wären GA/Data/PA übersichtlich direkt nebeneinander.

"ga":"1/1/11","data":"1","pa":"1.0.17",

Zur Analyse wäre das auch erst mal ausreichend so. Sollte ich das Loging öfter nutzen, dann werde ich vielleicht irgendwann mal versuche mit Chatty vor einer Analyse eine Datei zu erzeugen, die dein Loging noch mit dem GA-Export aus der ETS um die GA-Namen und Datentypen erweitert. Gleiches kriegt man evtl. auch mit der PA und den Gerätenamen hin.

Vom mir auf jeden Fall schon mal ein großes Dankeschön für die Möglichkeit nun ein permanentes Loging der KNX-Telegramme zu haben :slight_smile:

19

Hallo bambam,

schön, dass ich dir damit helfen konnte. Die 80 bzw. 81 stehen für Ein/Aus, also ein reiner Schalter. In diesme Fall noch einfach. Die verschiedenen DPTs in KNX können sehr umfangreich werden. Aus den Daten kann man nicht exakt sagen was das jeweils für ein Datentyp ist. Das ist in der ETS festgelegt. Durch verbinden der Geräte in der ETS weiß man ja welches Gerät was kann und man verbindet das als Nutzer so, dass die Datentypen zusammen passen. Wenn man sich im Datenstrom dazwischen hängt weiß man den Datentyp nicht. Der Typ wird auch nicht übermittelt. Über Heuristik könnte man versuchen das zu ermitteln. Das führt aber an dieser Stelle zu weit. In einem der anderen Module habe ich wesentlich wichtige Datentypen ermittelt. In Zukunft könnte ich das ggf. an dieser Stelle für einige wenige Datentypen auch einbauen. Ggf. lösst man das auch so, dass man eine Matrix als Nutzer eingibt die aus der ETS kommt, dann kann sicher gehen, dass das passt.

20

Nee, das stimmt nicht.

Die grundlegende Decodierung der Nutzdaten funktioniert auch ohne das Projekt, siehe Screenshot. In den Rohdaten gibt’s vemutlich mehr Information als IPS sie dir hier liefert.

dpt1a
dpt1a640×333 71.8 KB