[Projektvorstellung] KoNfiX – Visueller KNX-Konfigurator

[ugc]

Moin Leute,

ich hab die letzten Monate an einem Tool gebastelt: KoNfiX. Ist ein visueller Open-Source KNX-Konfigurator (AGPLv3).

Wichtig vorab:
Das Ding ist eine sehr frühe Alpha (v2026.9.1) und längst nicht fertig!
Gerade die Programmier-Engine (Flashen von PA, GAs etc.) ist frisch drin und braucht dringend Tests. Bitte testet das NUR auf Testbrettern oder DIY-Geräten und zerschießt euch damit nicht aus Versehen eure produktive Anlage.

Was das Tool macht / Warum ich das gebaut hab:
Ich wollte was Visuelles und Node-basiertes, aber ohne Cloud-Zwang und keiner teuren ETS Lizenz.

• Läuft komplett lokal auf Linux, Mac, Windows (Standalone).
• Kann ETS 5/6 Projekte laden und speichern (.knxproj).
• Visuelle Canvas – Geräte platzieren, Linien ziehen = GA wird im Hintergrund automatisch angelegt.
• Logikbausteine sind auch direkt mit drin.
• Automatische Filtertabellen, Live-Busmonitor und KNX Secure Support.
• .knxprod Import klappt nativ.
• KNXSniffer der sich als Gateway ausgibt und das originale Gateway brückt.

Wie ihr das Flashen testen könnt (ohne Risiko):
1. Nur gucken: Linien-Scan oder Programmiermodus-Detektor nutzen (liest nur, schreibt nichts).
2. OpenKNX DIY-Module: Perfekt zum Flashen, im Zweifel flasht man per USB neu.
3. Testbrett: Altes Gerät + IP-Schnittstelle nehmen.
4. Echte Hardware: Wenn was hakt, einfach per ETS "Vollständig programmieren" und alles ist wieder gut (Geräte gehen nicht kaputt).

KoNfiX flasht übrigens recht fix, weil es nur die geänderten Bytes überträgt.

Was ich von euch brauche:

• Klappt das Flashen bei euren MDT, Gira, Theben etc. Geräten?
• Kriegt ihr irgendwo Fehler oder Timeouts?
• Funktioniert KNX Secure mit euren Geräten?

Hier gibts das Tool:
GitHub: https://github.com/Sduniii/KoNfiX/releases
Einfach entpacken und ./start.sh ausführen. Web-UI ist dann auf localhost:8080.
Oder Docker nutzen.

Freue mich über Feedback und Bug-Reports.

Um das vielleicht für die Diskussion noch etwas einzuordnen: Ich habe KoNfiX ursprünglich wirklich nur für mich selbst gebaut. Für mein eigenes Setup im Haus wollte ich einfach eine unabhängige Lösung haben, die sauber unter Linux läuft. Eigentlich hatte ich gar nicht vor, das Projekt groß zu veröffentlichen. Den Zwang, dass am Ende eine 100% perfekte ETS-Dokumentation für einen gewerblichen Elektriker rausfallen muss, habe ich bei mir zu Hause schlicht nicht. Ich teile das Ganze jetzt einfach, weil ich den technischen Austausch auf Code-Ebene spannend finde – wer mag, kann es testen und mitbasteln.

Grüße

[r4id]

Und der nächste bitte....

[henfri]

Hallo,

ich traue mich nicht, damit meine Geräte zu programmieren, aber ich finde das UI-Konzept interessant. Eine solche Ansicht (bei der man direkt die Verknüpfungen sieht) würde der ETS auch nicht schaden - dann könnte man sogar ganz auf GAs verzichten (klar, im Hintergrund braucht man sie, aber der User braucht sie nicht) und man wäre die elendige Suche nach der idealen GA-Struktur (die dann nacher doch organisch wächst und alle Regeln verletzt) los.

Gruß,
Hendrik

[ugc]

Und der nächste bitte....

Ich verstehe den Kommentar nicht ganz. Ich suche lediglich nach einer Möglichkeit, mit diesem offenen Format zu arbeiten, ohne einen Haufen Geld in die Hand nehmen zu müssen. Wenn du weißt, wie es geht, teil dein Wissen doch einfach, anstatt zynisch zu werden. Ich beschäftige mich nicht erst seit gestern mit Software- und Hardwareentwicklung und habe schon genug eigene Geräte gebaut, um zu wissen: konstruktiver, offener Austausch bringt alle weiter, elitäres Gatekeeping niemanden.

[r4id]

Du kannst ja mal hier lesen:
https://knx-user-forum.de/forum/%C3%...-knx-projekten
Da werden einige Punkte angesprochen, die du wahrscheinlich noch gar nicht bedacht hast.

Oder hier: https://knx-user-forum.de/forum/%C3%...ive-von-knx-ai
Oder hier: https://github.com/jgrahamc/koolenex

[ugc]

Hallo,

ich traue mich nicht, damit meine Geräte zu programmieren, aber ich finde das UI-Konzept interessant. Eine solche Ansicht (bei der man direkt die Verknüpfungen sieht) würde der ETS auch nicht schaden - dann könnte man sogar ganz auf GAs verzichten (klar, im Hintergrund braucht man sie, aber der User braucht sie nicht) und man wäre die elendige Suche nach der idealen GA-Struktur (die dann nacher doch organisch wächst und alle Regeln verletzt) los.

Gruß,
Hendrik

Wenn du die ETS eh hast, kannst du doch testweise einfach mal ein Gerät mit dem Programm ausprobieren. Falls was schiefgeht, kannst du es ja jederzeit mit der ETS wieder fixen.

[Noschvie]

Diese GUI gibt schon was her… Danke fürs teilen! Bin jedoch nicht mutig genug, um das Tool mit dem Bus zu verbinden.

[ugc]

Du kannst ja mal hier lesen:
https://knx-user-forum.de/forum/%C3%...-knx-projekten
Da werden einige Punkte angesprochen, die du wahrscheinlich noch gar nicht bedacht hast.

Oder hier: https://knx-user-forum.de/forum/%C3%...ive-von-knx-ai
Oder hier: https://github.com/jgrahamc/koolenex

Danke für die Links, jetzt verstehe ich, worauf du hinauswillst! Ich hatte die Entwicklungen im letzten halben Jahr nicht komplett auf dem Schirm, aber es war absehbar, dass KI hier einiges ins Rollen bringt. Das ist per se eine super Entwicklung. Je mehr Open-Source- oder Drittanbieter-Software entsteht, desto schwerer wird es für die KNX Association, das System komplett abzuriegeln. Hoffen wir mal, dass die Hersteller ihre .knxprod-Dateien weiterhin unkompliziert zur Verfügung stellen. Konsequenterweise bräuchte man eigentlich als Nächstes ein offenes, zentrales Repository für die ganzen Projekt- und Produktdaten – oder existiert so etwas schon?

[r4id]

Hoffen wir mal, dass die Hersteller ihre .knxprod-Dateien weiterhin unkompliziert zur Verfügung stellen

https://knx-user-forum.de/forum/öffe...84#post2105084

[ugc]

https://knx-user-forum.de/forum/öffe...84#post2105084

Dass der externe Import komplett stirbt, sehe ich noch nicht in Stein gemeißelt. Ich vermute, dass durch mehr Open Source und Sichtbarkeit eher der gegenteilige Effekt eintritt. Solche Projekte senken die Hürden, bringen mehr User ins KNX-Ökosystem und erzeugen Druck, Daten zugänglich zu halten. Deshalb sollte man das unterstützen.

[minnten]

Hallo,

ich hätte es tatsächlich mal am Testbrett getestet, aber unter docker läuft es erstmal in einen Fail:

3.645 error: can't find bin `knx_sniffer` at path `/app/crates/knx-core/src/bin/knx_sniffer.rs`
3.645  --> /app/crates/knx-core/Cargo.toml
[+] up 0/1r: could not compile due to 1 previous target resolution error
 ⠸ Image konfix:latest Building                                                                                                                                                                                                          6.4s
Dockerfile:23

--------------------

  22 |    

  23 | >>> RUN mkdir -p crates/knx-core/src && \

  24 | >>>     echo "pub fn dummy() {}" > crates/knx-core/src/lib.rs && \

  25 | >>>     echo "fn main() {}" > crates/knx-core/src/main.rs && \

  26 | >>>     cargo build --release -p knx-core && \

  27 | >>>     rm -rf crates/knx-core/src target/release/deps/knx* target/release/deps/konfix* target/release/.fingerprint/knx* target/release/.fingerprint/konfix*

  28 |    

--------------------

failed to solve: process "/bin/sh -c mkdir -p crates/knx-core/src &&     echo \"pub fn dummy() {}\" > crates/knx-core/src/lib.rs &&     echo \"fn main() {}\" > crates/knx-core/src/main.rs &&     cargo build --release -p knx-core &&     rm -rf crates/knx-core/src target/release/deps/knx* target/release/deps/konfix* target/release/.fingerprint/knx* target/release/.fingerprint/konfix*" did not complete successfully: exit code: 101



​

[ugc]

Hallo,

ich hätte es tatsächlich mal am Testbrett getestet, aber unter docker läuft es erstmal in einen Fail:

Sollte gefixt sein. Bei mir lief es lokal.

[MatthiasS]

Bitte Fullquote vermeiden. Ganz besonders Fullquote des unmittelbar vorangehenden Beitrages!!