.knxprod parser aus OpenKNXProducer

[mgil]

Ich versuche gerade den Aufwand für die Entwicklung eines .knxprod Parsers abzuschätzen um diese in die XKNX Lib zu integrieren. Da das grundsätzlich ein recht komplexes Unterfangen ist und Dokumentation zum Format spärlich vorhanden ist, möchte ich hier ein paar Infos und Einschätzungen von KNX Profis einholen.

Einige OpenKNX tools wie das KAENX haben bereits die Möglichkeit geschaffen auch ohne ETS KNX-Devices zu parametrisieren. Hierfür ist natürlich ein verstehen/parsen des entsprechenden .knxprod Files nötig. Es sollte daher eine entsprechende Parser-Implementierung in deren Repo geben. Gibt es abseits des dortigen Repos noch andere Orte wo entsprechende Dokumentation zu finden ist? Hier sind vor allem die Binärdaten in den Applikationsprogrammen zu erwähnen.

Wo sind all die Infos zu den Applikationsprogrammen und dem Dateiformat zu finden?

[thewhobox]

Es gibt keinen gesammelten Ort.
Alles was wir wissen ist aus vielen Tests und langem Suchen zusammen gekommen.

Das ist auch viel zu viel Info um das iwo in ein Wiki zu schreiben oder so.
Am besten stellst konkrete Fragen, dann schauen wir wie wir helfen können.

Gruß Mike

[mumpf]

Zum OpenKNXproducer (das Ding ist von mir): Der parsed nicht ein knxprod-File, sondern erzeugt es. Und als Basis wird ein manuell erstelltes xml genommen, dass einer ETS-Applikation entspricht.

Wir haben uns existierende ETS-Applikationen angeguckt und durch reverse-engineering rausgefunden, wie das läuft. In vielen Roundtrips, bei den man was am xml verändert hat und geschaut hat, wie die ETS darauf reagiert. Wie thewhobox schon schrieb, keine zentale Stelle, die das interpretiert (außer der ETS selbst).

Des weiteren arbeiten wir nur mit SystemB, das ist nur ein Bruchteil dessen, was in der knxprod stehen kann.

Am besten schreibst Du, was ihr beim parsen der kxnprod rausfinden wollt, dann können wir wahrscheinlich Tipps geben.

Gruß, Waldemar

[mgil]

Danke für die Infos!

Der große Traum wäre eine Parametrisierung von KNX durch Python Anwendungen zu ermöglichen, um z.B. eine moderne Web-basierte im Workflow grundlegend Überarbeitete "ETS" zu erschaffen nach dem Vorbild von NodeRed. Auch eine Integration in HomeAssistant wäre damit möglich. Ich weiß das ist sehr weit gedacht. Daher erstmal mein Wunsch einer Bestandsaufnahme.

Die XMLs aus den .knxprod's einzulesen ist im Grunde nicht zu schwer. Die Verklinkungen mit den Refs darin sind auf den ersten Blick auch recht geradlinig.
Schwierig wirds mit den Applikationsprogrammen (z.b. aus Static/Code/AbsoluteSegment/0): Darin finden sich (offenbar) base64 codierte Data Segmente. Hier bin ich eher blank. Meine Intuition wäre, dass das der SourceCode des Microcontrollers wird.

• Welche Teile des Files muss verstanden/geparsed werden um eine Parametrisierung aktueller Consumer-Devices zu ermöglichen?
• Wie verändern die Einstellungen die man in der ETS vornimmt, das Applikationsprogramm das sich in den .knxprod's befindet?
• Wie wird das fertig parametrisierte Applikationsprogramm zusammengebaut?

Ich weiß das ist alles sehr High-Level. Auch bestehender Quellcode wäre hilfreich.

[thewhobox]

Für die Parametrisierung brauchst du eig "nur" die Parameter aufgrund vom Dynamic auf ihre sichtbarkeit berechnen. Daraus erstellst du dann das Speicherabbild.
Dieser wird über die Ladeprozedur dann in das Gerät geladen.

Die Einstellungen in der ETS verändern nur die Sichtbarkeit der Parameter.
Durch die chooses und deren when wird das beeinflusst.

Siehe erstes.
Auch wenn es vll unübersichtlich ist hier mal mein Code um die Applikation zu übertragen: https://github.com/thewhobox/Kaenx/b...Application.cs


Gruß Mike

[mumpf]

mgil: Ich glaube, Du denkst noch zu kompliziert .

Die Base64-encoded-Teile verstehe ich auch nicht, keine Ahnung, was das macht.

Denke bei Applikaitonsprogramm nicht unbedingt an Binaries, das ist glaube ich die Barierre in Deinem Kopf. Bei SystemB (zumindest die Teile, die wir nutzen) sieht das so aus:

• Es gibt eine Firmware auf dem Gerät (Binary, hochgeladen über normale Flash-Verfahren des zugehörigen Microcontrollers)
• Die Firmware interpretiert einen bestimmten Speicherbereich als Parameter und liest aus diesem Werte und reagiert passend zu diesen Einstellungen.
• Die ETS beschreibt diesen Speicherbereich mit passenden Werten.
• Das xml der kxnprod beschreibt der ETS, welcher Speicherbereich mit welchen Daten beschrieben werden soll.
• Außerdem besagt das xml, wie sie diese Daten vom User erfragen soll (UI-Beschreibung).
• Das gleiche gilt für KO, nur dass diese - im Gegensatz zu normalen Parametern - im RAM liegen müssen, da sie ja der Kommunikaiton dienen.

Ist auch "High-Level", aber das beschreibt, was wir machen. Die Binärdaten, die die ETS schreibt, sind nur Parameter und Informationen zu KOs, keine Binaries im Sinne von "executable coding".

Gruß, Waldemar

[mumpf]

Noch was: Die KNX-Spec von der KNXA kennst Du, oder? Dort ist sehr viel beschrieben. Und Mike hat ja von unserer Seite mit Kaenx schon versucht, ein Parametrisierungswerkzeug á la ETS zu machen. Ist aber bei der Masse der Varianten der verschiedenen Applikationen und den verschiedenen Erweiterungen der letzen 30 Jahre ein irrer Aufwand.

[meti]

Hi mgil 👋

Ich bin gerade zufällig über den Thread hier gestolpert.

die Entwicklung eines .knxprod Parsers abzuschätzen um diese in die XKNX Lib zu integrieren (...)
eine Parametrisierung von KNX durch Python Anwendungen zu ermöglichen, um z.B. eine moderne Web-basierte im Workflow grundlegend Überarbeitete "ETS" zu erschaffen nach dem Vorbild von NodeRed. Auch eine Integration in HomeAssistant wäre damit möglich.

Das klingt ja recht interessant. Hast du dabei schon Fortschritte machen können, oder wurde die Idee wieder verworfen?
Ich hätte da auch ein paar Ideen dazu, vielleicht können wir uns ja mal austauschen.

Mfg Matthias (GitHub @farmio)