XKNX Editor: Open-Source KNX-Programmiertool für macOS, Linux und Windows

[henfri]

Danke für die schnelle Rückmeldung

Aber: Bei mir funktioniert's halt auch problemlos (habe eine Cloud-Lizenz): Ich gebe einfach mein Benutzername/Passwort ein, klicke auf "Log in" und danach wird der "Sign & Export"-Button aktiv. Und der Export selbst klappt dann bei mir problemlos

Ich möchte aber ungern die credentials eingeben.

Und wenn ich es richtig verstanden habe, sollte es auch über das extrahieren des schlüssels aus der dll gehen.

abtools / Andreas: Du sagtest, der xnknx-editor sei am Weitesten wenn man die ETS-Alternativen vergleicht. So einen Vergleich wollte ich auch eigentlich für mich mal machen - magst du ein wenig über deinen Vergleich teilen?

Magst du hierzu noch was sagen?

[abtools]

Hallo Hendrik,

Und wenn ich es richtig verstanden habe, sollte es auch über das extrahieren des schlüssels aus der dll gehen.

Dazu kann ich nichts sagen, vielleicht kann xknxeditor das beantworten.

abtools / Andreas: Du sagtest, der xnknx-editor sei am Weitesten wenn man die ETS-Alternativen vergleicht. So einen Vergleich wollte ich auch eigentlich für mich mal machen - magst du ein wenig über deinen Vergleich teilen?

Ich habe mir einfach ein paar (insbesondere Web-basierte) Lösungen, die es so gibt, angesehen, und bin zu dem Ergebnis gekommen, dass die zumindest aktuell noch sehr weit von dem Funktionsumfang des XKNX Editors entfernt sind.

Vielleicht ist deren UI optisch schöner/ansprechender, aber versuche einfach mal mit einer der anderen Lösungen z. B. eine "KNX Secure"-Inbetriebnahme eines Gerätes durchzuführen. Oder auch nur einen Bus-Monitor zu verwenden, meist gibt's den noch gar nicht (sondern nur einen Gruppenmonitor). Da fehlt's an vielen Stellen noch weit.

Aber das ist meine persönliche Meinung, du kannst ja die verschiedenen Projekte einfach mal selbst ausprobieren und dir eine eigene Meinung bilden.

Viele Grüße
Andreas

[henfri]

Hallo,

ja, für mich sind die Funktionen - der Kern - auch wichtiger als das hübsche UI. Man lässt sich da leicht blenden.

Gruß,
Hendrik

[Aandy]

Und wenn ich es richtig verstanden habe, sollte es auch über das extrahieren des schlüssels aus der dll gehen.

Nein. Also Jein.
Mit diesem Schlüssel den du da extrahierst kriegt du überhaupt nur eine Signatur hin, die immer benötigt wird um valide knxproj und knxprod files zu erstellen. Das ist mehr sone Tamper Protection als das Licensing.

Um diesen Key drumrum ist nochmal ein Signaturschema. Bei den knxprods wird das gemacht, sobald der conformance test durch ist und damit ist das Produkt dann zertifiziert. Die Keys dazu hat nur die KNX Association. Fehlt die äußere Signatur, ist das Produkt nur "registriert". Dann schluckt die ETS es aber trotzdem anstandslos. Das ist was OpenKNX (und ich) für eigene Gerätedefinitionen macht. Und die ETS selbst, wenn ein Gerät aus der ETS 4 oder älter importiert wird wo es noch keine Signaturen gab.

Bei Projekten kommt ne andere Signatur fürs Licensing drumrum. Mach mal ein .knxproj als ZIP auf und schau in das file mit dem Namen "P-XXXX.signature", wobei XXXX eine projektspezifische ID ist. Der Key für diese Signatur kommt aus deinem Dongle oder der Cloud. Den bekommst du nicht extrahiert. Auch der Dongle bekommt nur den Request um etwas zu signieren und signiert das dann, returnt halt nur die Signatur. Ich hab mitlerweile Code mit dem ich mit dem Dongle reden kann, auch um Projekte mit meiner Lizenz zu signieren, ist aber nicht public. Technisch hindert dich aber gar nichts daran Projekte einfach zu resignen solange du ne Lizenz irgendwo hast, egal woher die kommt.

Sollte dieses Lizenz-Signaturfile fehlen, behandelt die ETS das Projekt als mit der Demoversion erstellt. Heißt, hast du <=5 Geräte da drin, funktioniert der import. Hast du mehr drin, kommt das bekannte Popup, dass das Projekt mit einer illegal gecrackten Version erstellt worden ist.

Also du musst die Credentials da eingeben, führt kein Weg dran vorbei. Oder du crackst die ETS ordentlich und entfernst den Check auf die maximale Geräteanzahl. Wäre natürlich böse illegal. Daten imports und exports mit Signaturen und Lizenzen verdongeln anscheinend nicht...

[henfri]

Ok, danke.

Ich glaube, in dem Fall wäre es gut, das herunterladen des entsprechenden schlüssels mit den credentials in einem extra Skript machen.

So könnte man den Code einmal checken, ausführen und den Key speichern.

Ich weiß, das ist alles oss, aber man checkt ja nicht bei jedem Release alles.

Und wenn man dann noch das signieren als extra Tool macht, profitieren auch andere davon.

Vielleicht mache ich mich mal daran...


Anderes Thema:
Die Knxproj sind ja eine oder mehrere gezippte XML.

Wäre es dann vielleicht sinnvoll, die Daten intern in einem git zu speichern.

Dann könnte man jederzeit nachgucken oder auch die KI fragen, was man wann geändert hat.

[boonkerz]

gibt es einen Grund warum man die OpenKNX xml nur von einer Url laden kann?
ich bin zu 99% unter Linux unterwegs und generiere dort auch die xml mit openknxproducer aber es wird keine prod datei generiert ohne ETS.

Aber zum testen für ein hobbyproject müsste ich so erstmal nicht immer über die ets gehen.

[Dill]

cooles Projekt.

nicht boesgemeinte Frage: verstehst du den code? gibt es einen guide zum code?

kannst du einen hint geben wie und wo

1) der dynamic-part durchlaufen wird?
insb
- module
- allocators
- calculations
- assigns
- entscheidung ob berechnung stabil ist

2) load-state machines implementiert sind (stark, dass du schon 3 masken hast)

[abtools]

Hallo Thomas,

gibt es einen Grund warum man die OpenKNX xml nur von einer Url laden kann?
ich bin zu 99% unter Linux unterwegs und generiere dort auch die xml mit openknxproducer aber es wird keine prod datei generiert ohne ETS.

Aber zum testen für ein hobbyproject müsste ich so erstmal nicht immer über die ets gehen.

Stimmt, das hatte ich tatsächlich auch schon überlegt:
Für den XKNX Editor müsste eine KNXProd ja nicht zwingend signiert sein. Man könnte sogar direkt die gleiche Projektliste wie die OpenKNX Toolbox laden und die Projekte direkt im XKNX Editor anzeigen.

Müsste man nochmal drüber nachdenken, was das für Konsequenzen hat, wenn man unsignierte KNXProds zulässt (z. B. wird dann ein Export in ein ETS-Projekt sicherlich nicht mehr möglich sein bzw. die ETS wird sich weigern das zu importieren - nehme ich zumindest an) und wie/wo man den Nutzer darauf hinweist.

Aber ja, hast Recht und ich hatte bereits denselben Gedanken. :-)

Viele Grüße
Andreas

[boonkerz]

Ja es würde den Workflow für mich schneller machen allerdings habe ich jetzt erstmal den Producer um das schreiben einer nicht signierten prod datei erweitert.
Das klappt problemlos.

[abtools]

Hallo Sebastian,

nicht boesgemeinte Frage: verstehst du den code? gibt es einen guide zum code?

Also ich könnte den Code verstehen (bin Softwareentwickler), wenn ich ihn lesen würde, mache ich aber in der Regel nicht. ;-)

Wie alle Projekte dieser Art ist das hier sicherlich zu 99 % von KI entwickelt. Ist das schlecht?
Ich persönlich denke nicht, vor vielleicht einem Jahr hätte ich darüber vermutlich noch anders gedacht.

Aber inzwischen sind die LLMs derart gut geworden, dass da oft besserer Code (von der Entwicklungsgeschwindigkeit möchte ich gar nicht reden) dabei raus kommt, als wenn ich den selbst geschrieben hätte.

Einen ganz kurzen "Guide", der die sehr grobe Projektstruktur enthält, gibt's daher auch nur mit der Zielgruppe KI-Agent - du findest ihn in der "CLAUDE.md".

kannst du einen hint geben wie und wo

Auch hier hilft die KI gerne weiter. ;-)

1) der dynamic-part durchlaufen wird?
insb
- module
- allocators
- calculations
- assigns
- entscheidung ob berechnung stabil ist

Alles liegt in packages/prod/src/xknxeditor/prod/parser_v2/:

• Einstieg: dynamic.py
  • DynamicTreeBuilder baut aus dem Dynamic-Teil einmal pro Applikation einen Baum aus Knoten. Module werden dabei schon zu Teilbäumen aufgelöst.
  • DynamicUI wertet diesen Baum gegen die Parameterwerte eines Geräts aus. Die Knotentypen liegen in nodes/, z. B. choose.py für choose/when, repeat.py, channel.py, rename.py.
• Module: nodes/module.py
  • ModuleNode wertet die ModuleDef im eigenen Scope der Modulinstanz aus und löst dabei die Argumente auf.
  • Die Werte pro Instanz verwaltet state.py: Unter GlobalState hängt pro Modulinstanz ein ModuleState.
• Allocators:
  • allocator.py enthält das Allocator-Objekt (Start, Maximum, Überlauf).
  • Die Vergabe pro Instanz macht EvalContext.allocate() in context.py. Es sucht zuerst die Allocators der ModuleDef, dann die der Applikation.
  • Die Indizes dafür baut application_indexer.py auf (allocators, app_allocators, arg_alloc).
• Calculations:
  • calculation/__init__.py führt die ParameterCalculations aus (run_calculations / run_calculations_many), dazu auch die ParameterValidations (run_validations).
  • calculation_plan_many() in application_indexer.py bestimmt, welche Calculations eine Änderung auslöst. Das sind alle erreichbaren, topologisch sortiert, jede genau einmal. Die Richtung ist LR oder RL, je nachdem, auf welcher Seite der geänderte Parameter steht.
  • Aufgerufen wird das aus DynamicUI.edit_parameters() / _change() in dynamic.py.
• Assigns: nodes/assign.py
  • AssignNode schreibt beim Durchlauf einen festen Wert oder den Wert des Quellparameters in den Zielparameter und zeigt selbst nichts an.
  • Ziel und Quelle zählen dabei als aktiv.
• Entscheidung, ob die Berechnung stabil ist: DynamicUI._eval_settled() in dynamic.py
  • Vorher läuft ein Erkennungsdurchlauf für Unions (_discover_union_activity). Er legt fest, welches Union-Mitglied gilt, unabhängig von der Reihenfolge im Baum.
  • Danach wird der Baum mehrfach ausgewertet. Jeder Durchlauf lässt ein choose nur dann einen Zweig wählen, wenn sein Parameter im Durchlauf davor aktiv war.
  • Stabil ist es, sobald sich die Menge der aktiven Parameter nicht mehr ändert. Das prüft ParameterState.update_gate_active() in state.py, über alle Modul-Scopes hinweg.
  • Spätestens nach _MAX_GATE_PASSES (5) Durchläufen ist Schluss.
  • Bei den Calculations gibt es keine solche Schleife: Sie laufen einmal in Plan-Reihenfolge.

2) load-state machines implementiert sind (stark, dass du schon 3 masken hast)

Alles liegt in packages/download/src/xknxeditor/download/:

• load_state.py enthält:
  • die Zustände und Load Events (LoadState, LoadEvent);
  • die Event-Daten (start_loading, load_complete, unload, Segment- und Allocation-Records);
  • die Variante über einen Speicherbereich (memory_mapped_control).
• programmer.py treibt die State Machines auf dem Bus, jeweils mit Rücklesen:
  • über das Property PID_LOAD_STATE_CONTROL: read_load_state, send_load_event, _poll_load_state;
  • über den Load-Control-Record im Speicher (BIM M112): read_memory_load_state, send_memory_load_event.
• procedure.py
  • LoadProcedureRunner arbeitet die LoadProcedures der Applikation ab (LdCtrlWriteMem, LdCtrlWriteProp, LdCtrlCompareProp, LdCtrlAbsSegment, LdCtrlTaskSegment, ...).
  • Die Load Events setzt _emit_load_event ab.
• Einstieg für einen Download: download() in download.py.

Und es wäre ziemlich schlecht, wenn wir nur 3 Masken unterstützen würden - hier noch ein paar Details zu den unterstützten/gestesten Masken:

• Keine feste Liste:
  • Für jedes Gerät liest der Download die Ressourcen der Maske und die Art ihrer Load State Machines aus den KNX-Stammdaten (resources.py, Feature PropertyMappedLsms). Damit sollte jede Maske funktionieren, die in den Stammdaten beschrieben ist.
  • Ohne Stammdaten greift die mitgelieferte Tabelle mask_resources.json mit 28 Maskenversionen.
• Eigenen Code haben nur wenige Masken:
  • MV-07B0: mehrere Sonderfälle in procedure.py;
  • MV-0701: überspringt einen Ladeschritt, für den sie keinen Load Status hat (PEI);
  • MV-091A: die IP-Einstellungen in ip_config.py.
  • Das System-B-Tabellenformat steht in tables_systemb.py
• Die drei Masken, die du meinst, sind vermutlich:
  • MV-07B0 (System B);
  • MV-0701 (BIM M112, Load State Machines über den Speicher-Record);
  • MV-0705 (BIM M112, Load State Machines über das Property).
  • Diese drei sind am ausführlichsten getestet
• Abgedeckt durch Tests sind insgesamt aber schon 15 Maskenversionen: MV-0011, 0012, 0020, 0021, 0700, 0701, 0705, 07B0, 0900, 0910, 0912, 091A, 1011, 2705 und 5705.

Hoffe, das hilft dir weiter!

Und für die eigentliche "Core"-Buskommunikation setzt dieses Projekt eben auf dieselbe "xknx"-Library, welche auch von Home Assistant verwendet wird, und damit sicherlich ziemlich gut getestet ist. ;-) Das sehe ich als einen wesentlichen Vorteile dieses Projekts und ist auch einer der Gründe, weswegen ich es mit PRs unterstütze, wann immer mir etwas auffällt und ich es gerne geändert hätte. Der eigentliche Maintainer ist da auch super offen für.

Was den Editor selbst betrifft habe ich, um z. B. die Parameterauswertung mit den ganzen Calculations und Assigns zu testen, automatisiert die berechneten Parameter (also was tatsächlich an das Gerät gesendet werden würde) von rund 200 Geräten mit den Daten der ETS verglichen und die Ursache von allem, was nicht 100 % identisch war, gefixt.

Und damit's bei künftigen Änderungen keine Regressionen gibt, haben wir inzwischen > 4500 Test-Cases im Projekt, die bei jeder Änderung automatisiert von GitHub Actions geprüft werden.

Aus meiner Sicht ist das ein besserer/zielführender Ansatz für solch ein Projekt als zu versuchen jede KI-geschriebene Code-Zeile zu verstehen.

Viele Grüße
Andreas

[Dill]

danke.

ich muss mir damit mal ein wenig zeit nehmen schon lange her, dass ich mit der sache beschaeftig habe.
ich glaube da sind noch ein paar luecken, sollten aber leicht zu schliessen sein.

ist das mit REA entstanden aus dem ETS-binary?

[abtools]

Hallo Sebastian,

ich muss mir damit mal ein wenig zeit nehmen schon lange her, dass ich mit der sache beschaeftig habe.
ich glaube da sind noch ein paar luecken, sollten aber leicht zu schliessen sein.

Wenn dir etwas auffällt, gerne melden!

ist das mit REA entstanden aus dem ETS-binary?

Wie gesagt, ich bin hier nur "Contributor", nicht der Haupt-Maintainer des Projekts, kann daher nur für mich besprechen und für meine Änderungen war Reverse Engineering aus irgendwelchen Binaries nicht erforderlich - Spezifikation und vor allem Beispiele/Geräte zum Testen, wo Unterschiede herkommen, haben ausgereicht.

Viele Grüße
Andreas

[Aandy]

Ich glaube, in dem Fall wäre es gut, das herunterladen des entsprechenden schlüssels mit den credentials in einem extra Skript machen.
So könnte man den Code einmal checken, ausführen und den Key speichern.
Ich weiß, das ist alles oss, aber man checkt ja nicht bei jedem Release alles.

So funktioniert das nicht. Du bekommst keinen Key von dieser API. Du hashst den Content über den du die Signatur haben willst, gehst an die API oder den Dongle und sagst "Signier mir das hier mal" und bekommst eine Signatur über diesen Hash zurück, den du mit dem zugehörigen Public Key dann überprüfen kannst. Der Private Key, den du zum signieren brauchst, verlässt nie die Cloud oder den Dongle. Das ist Absicht, damit genau das eben offline nicht geht. Jeder Signiervorgang braucht den Dongle oder die API.

Ich hab mir die Crypto vom Dongle auch schon angesehen. Nichts gefunden was offensichtlich kaputt war. Ich bin der Meinung, dass die das selbst gebaut oder dediziert eingekauft haben, weil ich keine Hinweise auf nen bekannten Lieferanten gefunden hab. Da hat auch schonmal jemand anders mit Ahnung drübergeguckt. Der Dongle verhindert durch ein Session-Management zum Beispiel, dass du den Traffic zu ihm Man-In-The-Middlen kannst um zwischen mehreren Clients zu multiplexen. So wie man das beim Pay-TV-Card-Sharing mit der Schlüsselkarte macht (oder gemacht hat), um aktuelle Session Keys für die nächsten paar Minuten des verschlüsselten Videostreams zu bekommen. Eine Session mit dem Dongle, eine laufende ETS die auf die Lizenzen zugreift.

Der Mikrocontroller von dem Ding allerdings riecht nach einem Atmel ATSAMD21 oder sowas. Das ist ein stinknormaler Wald- und Wiesencontroller, nichts worin man secrets sicher ablegen kann. Mit genug Dongles zum massakrieren krieg ich da auch die Firmware trotz Readout-Protection raus. Kommt dann drauf an wo die Secrets liegen. Evtl. sind die noch in einem speziellen Chip dafür der daneben liegt und das wird schwieriger. Aber um das zu wissen müsste man mal einen knacken und dann iser halt vermutlich kaputt. Oder röntgen, dann sieht man wie viele Dies da drin sind.

edit: Falscher Mikrocontroller. Es war nichtmal ein ARM, sondern ein 32-Bit (weird!) AVR: AT32UC3A3
Die Dongle-Library sucht nach verschiedenen Devices anhand der USB VID/PID und eine in der Liste ist 0x03EB:0x2FF1. 3EB ist Atmel und 2FF1 ist die Product ID, die sie dem USB-ROM-Bootloader des Chips gegeben haben. Wenn man dem also glauben will, wäre das der passende Chip.

[henfri]

Hi Aandy,

verstehe, danke für die Erklärung. Verstanden.
Zum Dongle: Ich finde es bedauerlich, dass die ETS derart abgeschottet ist.
Aber ich denke, das sollte nicht dazu führen, Gedanken in Richtung der Umgehung des Dongles zu richten.


Gruß,
Hendrik

[Aandy]

Kannst du nicht damit. Das Einzige was du extrahieren könntest wäre dein eigener Private Key um damit deine eigenen Projekte offline und ohne Dongle zu signieren. Mehr ist schlicht nicht drin was irgendwie geheim wäre.
Die Lizenzen selbst sind alle einfach so auslesbar, aber nochmal mit einem anderen Key signiert den nur die KNX-Association hat. Um die zu umgehen hilft nur das klassische wegpatchen der Checks in den Binaries, weil du selbst keine erstellen und signieren kannst ohne Key.

Aber ich will den Thread hier nicht dafür weiter karpern.