ETS? Nein Danke!

[IPv6]

aber zeig mir eine Software, wo das nicht zutrifft…

In zwei Wochen gibt es bestimmt einen neuen Nutzer, der sein Projekt KNXtudio vorstellt

[henfri]

Was soll das schon wieder?

[KNXBench]

Next: Alpha 15 ist da! und hier Mal eine Übersicht was bis jetzt alles schon passiert ist:

Was ist neu? Von Alpha 15 bis Alpha 5

Alpha 15:
Geschätzte Entwicklungszeit bisher: ca. 25 Std. – 201 Commits

• Das Datei-Menü hat Schubladen: Verlauf, Hilfe und Import/Export klappen animiert auf. Bei 150 % Zoom fliegt das Menü nicht mehr vom Bildschirm.
• Spaltenbreiten gehören jetzt dir: Alle Tabellenspalten lassen sich ziehen und passen sich an das längste Wort an. Schluss mit DPT-Buchstabensuppe.
• Der Busmonitor findet die richtigen DPTs: Er unterscheidet jetzt „kein Projekt“ von „kein Typ“ und muss nicht mehr raten.
• Der Projektstatus kann "wiegen": Datei- und Katalog-Größen in MB, ohne Flunkern bei alten Zahlen.
• Die Topologie räumt auf: Beschriftete Kennzahlen und ein Layout, das auf Breitbild nicht ausfranst. Leere Bereiche werden ausgeblendet, ohne dass Daten verloren gehen (#25).
• Gefahr sieht wieder gefährlich aus: Jede Aktion, die Daten kosten kann, ist deutlich markiert. Dazu gibt es kompakte Buttons und sichtbare Trenner.
• Parameter-Überschriften stimmen wieder: Die Suche findet genau die Texte, die du in den Parameterbereichen siehst (#26).
• Der Gerätevergleich zeigt auf die Bytes: Er markiert jedes abweichende Byte. Filter dürfen Gleiches ausblenden, aber nie ein abweichendes Byte.
• Geräte zeigen ihre Systemfamilie: Neue Spalte „System“ (System 1, 2, 7, B, Koppler, Router …), abgeleitet aus einer belegten Tabelle mit 37 Maskenversionen.
• Diagnose-Archiv Format 2: Neu sind --profile und eine ehrliche memory.json. Der Speicher wird erst gelesen, wenn sich das Gerät ausgewiesen hat.
• Produktdatenbank v25: Parameter-Platzierungen und Aufzählungen bekommen eigene Spalten. Nichts verschwindet mehr heimlich.
• Große Dateien willkommen: Dateien bis 1 GB, Archive bis 4 GiB. Sogar das 281,8-MiB-Monster installiert sich ohne Extra-Flag.
• Alte .vd5-Dateien schreien nicht mehr ins Leere: Tabellennamen in GROSSBUCHSTABEN werden erkannt.
• Strengere .knxproj-Prüfung: Leere ZIP-Ordner müssen wirklich leer sein. Ein Zensus über 231 echte Archive ergab null Fehlalarme.
• Der Produktkatalog bleibt nicht mehr stumm leer: Ein Testlauf hatte die echte Datenbank migriert. Lesende Befehle öffnen sie jetzt nur noch lesend.
• Community-Paket komplett: CONTRIBUTING, SECURITY, PR-Checkliste und ein Code of Conduct.

Tests (letzter kompletter Gate-Lauf, Zwischenstand):

• Rust: 5.023 bestanden, 0 fehlgeschlagen, 215 ignoriert, gebündelt in 54 Testprogrammen (vorher 356 Einzelgänger)
• Vitest: 4.132 von 4.132 (aus dem Gate von WP-20)
• Browser: 855 Fälle (790 parallel, 65 exklusiv); 68 Web-Gate-Stufen
• Bindings: 59 plus Diff
• Privater Korpus: 155 von 155

Tests pro Neuerung:

• UI-Feedback-Paket (Menü, Spalten, Monitor, Status, Topologie, Buttons): kompletter Gate-Lauf mit 16 Stufen; Rust 4.925, Korpus 155/155, Web-Gate 66/66. Die Spaltenbreiten brauchten neun Korrekturrunden.
• Gerätevergleich: Vitest 4.054/4.054, 839 Browserfälle; absichtlich eingebaute Fehler (Mutanten) wurden alle erkannt.
• Modul-Bereiche und Zoom: vor dem Fix 6 rote Vitest-Fälle, danach 22/22 Vitest und 6/6 Browserfälle für die Trennbalken.
• Strengere ZIP-Prüfung: 10 neue Tests, 6 Mutanten erkannt, Korpus 155/155, Zensus über 231 Archive.
• Produktkatalog-Fix: Testläufe, die echte Nutzerdaten berühren, von 5 auf 0 (von 185 CLI-Tests).
• Gate-Wächter: 15 von 15 Mutanten erkannt, vier Review-Runden.
• System-Spalte: Vitest 4.132, 859 Browserfälle, Rust 5.009, Korpus 155/155.

Alpha 14
Geschätzte Entwicklungszeit: ca. 16,3 Std. – 99 Commits

• Alles startet zugeklappt: Navigation, Explorer und Gruppenadressen machen nicht mehr alles auf einmal auf.
• Parameter-Arbeitsplatz statt Akkordeon-Stapel: Bereichsregister, Raster-Blöcke als Matrix, Einrückungen und Objektgrößen.
• Hersteller-ZIPs installieren sich in einem Schritt.
• Diagnosedaten in fünf Schritten senden, gedacht für alle, die Fehler melden.
• Notizen reden beim Löschen mit und reisen beim selektiven Import mit.
• Produktdatenbank v24.

Tests: Rust 4.882 bestanden, 0 fehlgeschlagen, 212 ignoriert · Vitest 3.742 · Browser 978 (596 + 341 + 41) · Native 24 · Tool-Tests 223 · Korpus 153/153 · Produkt-Korpus 16.
Bonus: Sieben Gate-Anläufe mit rund 40.500 Testausführungen in 6,4 Stunden. Erst Anlauf sechs durfte raus.

Alpha 13
Geschätzte Entwicklungszeit: ca. 18,6 Std. – 77 Commits

• Navigationsbereiche lassen sich einzeln falten.
• Gruppiertes Datei-Menü.
• Echte Gerätebetriebsarten aus den Herstellerangaben.
• Parametergruppen direkt aus der Quelle.
• Keine stillen halben Quell-Images mehr: Unvollständiges wird abgelehnt statt verschluckt.

Tests: Rust 4.724 · Komponententests 3.632 · Browser 947 · Native 24 · Korpus 152/152 · Produkt-Korpus 16.

Alpha 12
Geschätzte Entwicklungszeit: ca. 32,2 Std. – 315 Commits (der Dauerläufer)

• Ausstehende Programmierung pro Teil: Adresse, Applikation, Parameter und Gruppenadressen werden einzeln markiert.
• Projekt gegen Gerät vergleichen, bewusst nur lesend.
• Support-Bericht, bevor ein Gerät programmiert wird.
• Räume bekommen Funktionen.
• Keine rohen {{0:…}}-Platzhalter mehr in Namen, und Bäume öffnen und schließen vorhersagbar.

Tests: Rust 4.597 bestanden, 0 fehlgeschlagen, 207 ignoriert · Vitest 3.626 · Browser 939 (574 + 365) · Korpus 152/152.

Alpha 11
Geschätzte Entwicklungszeit: ca. 6,8 Std. – 54 Commits (der Sprinter)

• Durchsuchbare Gruppenadress-Auswahl beim Verknüpfen (#8).
• „Gateway nicht gefunden“ sagt jetzt, warum (#10).
• Tester-Bericht nach jedem Download, damit Geräte gemeinsam verifiziert werden können.
• Flow-Schnappschüsse und Clips, Bewegung pro Kategorie abschaltbar.
• Notizen an Kommunikationsobjekten.

Tests: 44 von 44 Gate-Stufen · Rust 4.281 bestanden, 0 fehlgeschlagen, 197 ignoriert · Vitest 3.302 · Browser 732 (477 + 255) · Native 12 · Korpus 144/144.

Alpha 10
Geschätzte Entwicklungszeit: ca. 18,2 Std. – 149 Commits

• Das AppImage startet wieder auf Mesa-Desktops (#6).
• ETS-5.7-Projekte lassen sich importieren (#7).
• Projektnotizen.
• Gruppenadressen auf vier Arten: Baum, Spalten, Atlas und mehr.
• Katalog-Updates mit Generalprobe.
• MCP darf Gruppenadressen umbenennen, aber nur, wenn ein Mensch nickt.

Tests (letzter abgenommener Lauf vor dem Tag): Rust 4.213 bestanden, 0 fehlgeschlagen, 196 ignoriert · Vitest 3.164 · Browser 412 · Korpus 143/143.

Alpha 9
Geschätzte Entwicklungszeit: ca. 14,4 Std. – 101 Commits

• Große importierte Projekte bleiben bearbeitbar.
• Die DPT-Auswahl ist lesbarer.
• Unbenannte Installationen sind verständlich.
• Klarere Import- und Download-Rückmeldungen.

Tests: Rust 4.048 · Vitest 2.738 · Browser 302 (keine Ausfälle, nichts übersprungen, nichts wackelig) · Korpus 143/143.

Alpha 8
Geschätzte Entwicklungszeit: ca. 9 Std. – 78 Commits

• Ausgewählte Linien oder Geräte ins offene Projekt übernehmen.
• Robustere Imports für Schema 23.
• Gespeicherte Modulinstanz-Werte lesbar in Inspector, HTTP-API und MCP.
• Größeres Archiv-Budget mit klarer Rückmeldung.

Tests: Rust 3.912 bestanden, 0 fehlgeschlagen, 190 ignoriert · Vitest 2.611 · Browser 244 · Korpus und Spezialfälle 146 · Python-Tools 54.

Alpha 7
Geschätzte Entwicklungszeit: ca. 10,8 Std. – 67 Commits

• Persistente Projekthistorie: Rückgängig und Wiederholen überleben das Wiederöffnen, dazu benannte Versionen.
• Kommunikationsobjekt-Tabelle mit Sortieren, Suchen und Filtern.
• Umbenennen per F2, ohne dass sich die Identität ändert.
• Uploads bis 256 MiB (#1) und ein verlässlicher Weg zurück zum Editor (#2).

Tests: 18 Gate-Stufen · Rust 3.831 · Vitest 2.583 · Browser 236 · Korpus 143 plus 3 Regressionen.

Alpha 6
Geschätzte Entwicklungszeit: ca. 15,2 Std. – 104 Commits

• Docker Hub: erstes Server-Image für amd64 und arm64.
• Der Server spricht selbst HTTPS.
• Assistenten für neue Projekte und neue Geräte.
• Geräte bekommen eine eigene Navigation.
• Alte ETS3-Produktdatenbanken (.vd3 bis .vd5) lassen sich lesen.
• knx-mcp: ein MCP-Server, der nur liest.
• Die Spaßabteilung: Erfolge, LCARS-Ansicht, Boarisch und Klingonisch.

Tests (letzter integrierter Lauf vor dem Tag): Rust 3.726 bestanden, 0 fehlgeschlagen, 182 ignoriert · Vitest 2.480 · Browser 202 · Tools 42. Zum ersten Mal hat GitHub gebaut, mit Smoke-Tests für AppImage und Docker.

Alpha 5
Geschätzte Entwicklungszeit: ca. 6,3 Std.– 28 Commits (seit Alpha 4)

• Neue App-Kennung com.knxbench.knxbench-labs, dazu ein neuer Datenordner.
• Das AppImage bevorzugt natives Wayland und fällt sonst auf X11 zurück.
• Einführungswizard, DPT-Inventar, Flow-Fenster.
• Öffentlicher Start: Das Repository wurde für die Veröffentlichung bereinigt.

Tests: Rust 3.430 bestanden, 0 fehlgeschlagen, 178 ignoriert · Vitest 2.162 · Browser 155 · Korpus 143/143 · cargo deny und npm audit sauber.

Unterm Strich: Von Alpha 5 bis Alpha 15 sind es rund 173 Stunden geschätzte Entwicklungszeit in 1.273 Commits. Die Rust-Tests wuchsen von 3.430 auf 5.023, die Vitest-Tests von 2.162 auf 4.132.

Nebenbei: Kein Bus wurde bei der Entwicklung verletzt. Bis jetzt...

[KNXBench]

Inselino: ETS kann (meine ich zumindest) - wie KNXBench übrigens auch, vorhandene Geräte auslesen und rekonstruieren. Dabei geht recht wenig verloren.
Und KNXBench kannst du einfach von Anfang an nutzen - also ganz ohne ETS :-)

[willisurf]

Und KNXBench kannst du einfach von Anfang an nutzen - also ganz ohne ETS

Bei aller Euphorie, ich denke zum Gesamtbild gehört auch, das es nicht ganz so trivial ist. Die Software ist ja auch offiziell als Alpha deklariert und aktuell gibt es keinen Weg zurück zur ETS. Wenn das so bleibt, müsste man alles manuell in der ETS nachpflegen, wenn man dorthin zurückkehren möchte/muss.

Ich schreibe dies, weil hier sicherlich ganz viele Sparfüchse mitlesen und vielleicht nicht das Gesamtbild sehen.

[henfri]

Ja, das sehe ich ähnlich.
Eine Rekonstruktion ist kein guter Plan B

[Kai Burkard]

Inselino: ETS kann ... vorhandene Geräte auslesen und rekonstruieren.

Mit einer Zusatzsoftware und nur, wenn kein KNX Secure zum Einsatz kam. Auch werden nur Speicherzustände rekonstruiert, nicht aber Projektstrukturen wie Bezeichnungen.

[KNXBench]

KNXBench Alpha 16 ist veröffentlicht!


Die nächste Alpha ist da. Diesmal wurde nicht nur an der Oberfläche poliert, sondern auch dort aufgeräumt, wo Software normalerweise ihre Kabel hinter dem Schrank versteckt.

Was ist neu?

• Kataloginstallation mit mehr Durchblick: Vorschau, ausdrückliche Bestätigung, nachvollziehbare Berichte und kooperativer Abbruch. Ein geschlossenes Fenster bedeutet nicht mehr automatisch: „Der Auftrag ist bestimmt irgendwo hingegangen.“
• Gerätewerte ins Projekt übernehmen: Eindeutig zuordenbare Parameter lassen sich nach einem vollständigen Gerätevergleich gezielt übernehmen – mit Vorschau und rückgängig machbarer Änderung. Unbekannte Rohdaten bleiben Rohdaten. Kaffeesatzlesen ist weiterhin kein unterstützter Datentyp.
• Originalquellen im Projekt erhalten: Beim Speichern können benötigte Original-Katalogpakete unverändert mitgeführt werden. Weniger „Wo war noch mal diese Herstellerdatei?“, mehr nachvollziehbare Projektgrundlage.
• Experimenteller System-2-Download: Neuer Ablauf für den UP 258D12 mit exakt unterstützter Applikation M-0001_A-9205-04-9270. Mit Sicherheitsabfragen, protokollierten Schritten und explizitem Wiederherstellungsweg. Wichtig: softwaregetestet, noch nicht an physischer Hardware verifiziert – kein allgemeiner System-2-Freifahrtschein!
• Weitere Verbesserungen: Übersetzte Block- und Trennerbeschriftungen, zusätzliche ZIP-Integritätsprüfungen und ein reduzierter Monitoring-Snapshot-Export.

Zahlen statt Bauchgefühl

• Entwicklungszeit seit Alpha 15: geschätzt 52,8 Stunden aktive Entwicklungszeit. Kaffeeziehzeit wurde nicht separat zertifiziert.
• Dokumentierter großer Gesamttestlauf: 6.309 bestandene Rust-Tests; 222 weitere Tests waren in diesem Lauf ausgenommen.
• Zusätzliche Korpusprüfung: 155 von 155 ausgewählten Testfällen bestanden.
• Gezielte Folgeprüfungen: Weitere Regressionstests sowie Import-, Upgrade- und Paketprüfungen. Überlappende Läufe werden nicht zu einer beeindruckenderen Fantasiesumme zusammengeschüttet.

Vor dem Update bitte beachten

• Projekte, Produktkatalog und persistente Daten unabhängig sichern. „Ich habe doch gestern gespeichert“ ist leider kein Backup-Konzept.
• Die Produktdatenbank wird auf Version 28 migriert. Alpha 15 kann diese anschließend nicht mehr lesen; einen Downgrade-Pfad gibt es nicht.

Viel Spaß beim Ausprobieren und danke für eure Rückmeldungen!
Fehlerberichte sind willkommen. „Geht nicht“ nehme ich auch – mit Version und Schritten zum Nachstellen schmeckt es der Fehlersuche allerdings deutlich besser.

[KNXBench]

KNXBench Alpha 17 – weniger Rätselraten, mehr Klartext
Alpha 17 ist da! Diesmal mit mehr Übersicht, besseren Fehlermeldungen und einigen zusätzlichen Sicherheitsgurten beim Programmieren. Der Bus bekommt schließlich schon genug Telegramme – da muss die Software nicht auch noch in Rätseln sprechen.

Neu hinzugekommen

• Verknüpfungen aus dem Gerätevergleich übernehmen: Bei vollständig dekodierten Assoziationstabellen der Maskenversion 0701h können jetzt auch Zuordnungen zwischen Kommunikationsobjekten und Gruppenadressen ins Projekt übernommen werden. Mit Vorschau und objektweise – ohne dabei neue Objekte anzulegen oder etwas aufs Gerät zu schreiben.
• Kommunikationsobjekte nach gespeicherten Projektordnern gruppieren: Die Objekttabelle zeigt die im Projekt hinterlegte Ordnerzuordnung und bietet eine passende Gruppierungsansicht. Ordnernamen werden aus den Projektdaten gelesen, nicht beim Kaffeesatz bestellt.
• Projektversionen auf einer Zeitleiste: Gespeicherte native Projektversionen werden übersichtlicher dargestellt. Nur eine Version auszuwählen verändert noch nichts – Anschauen bleibt erfreulich ungefährlich.
• Mehr Orientierung in der Flow-Ansicht: Neben der Gruppenadresse erscheint jetzt auch der eindeutige Gruppenname aus dem Projekt. „3/2/17“ darf damit endlich wieder „Licht Küche“ heißen, sofern das Projekt diese Zuordnung eindeutig hergibt.
• Sortierbarer Produktkatalog: Produkt, Hersteller, Bestellnummer und Applikation lassen sich per Klick auf die Spaltenüberschrift sortieren. Revolutionäre Technik: Tabellen machen Tabellendinge.
• Gezielterer Download-Umfang: Im Download-Tab gibt es die zusätzliche Auswahl, nur die vom Projekt als ausstehend markierten Teile zu berücksichtigen. Die CLI kann mit „--changes“ einen entsprechenden Plan erstellen. Das ist eine Auswertung des Projektstands, kein Gedankenlesen im Gerät.
• Read-only-Prüfung nach regulären Downloads: Erreichbarkeit, Identität und Ladezustände werden nach dem Download separat geprüft und ausgewiesen. Erfolgreiche Übertragung, Neustart und anschließende Beobachtung werden nicht mehr in einen einzigen optimistischen Haken geworfen.
• Diagnose mit kürzeren Wegen: Im Diagnose-Tab eines Geräts führen „Gerät analysieren“ und „Bericht senden“ direkt zu den bestehenden Dialogen – mit vorausgewähltem Gerät. Dazu kommen ein read-only System-2-Diagnoseprofil im Webdialog und die Geräteauswahl per physikalischer Adresse in der CLI.

Gefixt und verbessert

• Fehlgeschlagene Downloads sagen jetzt genauer, warum: Reguläre Download-Fehler behalten eine strukturierte Ursache, unter anderem mit Kategorie, Code und betroffener Phase. Diese Informationen stehen in Status, Sitzungsprotokoll, Aktivitätsverlauf und Bericht zur Verfügung; Download und Wiederherstellung geben sie auch in der CLI aus. „Hat nicht geklappt“ wurde zum weiterführenden Sprachkurs geschickt.
• System-2-Auswahl verständlicher gemacht: Der Download-Modus sitzt direkt unter der Geräteauswahl. Hinweise zum noch nicht unterstützten regulären Speicherdownload werden nicht mehr so dargestellt, als würden sie automatisch auch den experimentellen System-2-Weg ausschließen.
• System-2-Status und Fehlerdiagnose präzisiert: Eigene Sperren werden nicht mehr irreführend als fremde Managementoperation dargestellt. Bestimmte abgelehnte Tabellenzeiger-Antworten liefern einen strukturierten Grund statt einer pauschalen Fehlermeldung. Rohe Speicherinhalte und andere sensible Details bleiben dabei aus dem teilbaren Bericht heraus.
• Kurze UP258-Tabellenzeiger korrekt erhalten: Der eng begrenzte experimentelle UP258-Pfad berücksichtigt jetzt zwei oder vier Byte breite Tabellenzeiger und erhält deren Breite auch in Wiederherstellungsdaten. Vier Byte sind eben nicht automatisch besser, wenn das Gerät nur zwei geliefert hat.
• Keine geschönten System-2-Backups: Unterschiedliche Vorzustände werden nachvollziehbar protokolliert. Ist der ursprüngliche Zustand nicht zuverlässig gesichert, wird eine Wiederherstellung ausdrücklich als nicht verfügbar ausgewiesen. Ein Haufen Nullen bekommt kein Backup-Etikett aufgeklebt.
• Strengere Identitäts- und Wiederherstellungsprüfungen: Reguläre Downloads prüfen die erwarteten Identitätslängen genauer. Neue Gerätebackups halten die zuvor installierte Applikationsidentität fest; unpassende oder nicht ausreichend belegte Wiederherstellungen werden abgelehnt.
• Kein Erfolg auf veralteter Grundlage: Programmierte Projektteile werden nur dann entsprechend verbucht, wenn der aktuelle Katalog noch denselben Downloadplan ergibt. Der Verlauf zeigt dazu einen laufbezogenen Beleg – einschließlich nicht übernommener Ergebnisse, wenn das Speichern scheitert.
• Speicherübertragung und Telegrammbehandlung nachgeschärft: Korrigierte Nutzdatenbudgets, passend zugeordnete Speicherantworten, geprüfte Ladezustände und korrigierte Kennzeichnung längerer Frames. Außerdem werden problematische Bildsegmente, nicht übersetzte Merge-Fragmente und unlesbare Zahlengrenzen lieber abgelehnt als stillschweigend übergangen.
• CLI-Tunnel bleiben beim Schreiben auf die Festplatte ansprechbar: Download, Wiederherstellung und Service-Control können Tunnelbestätigungen weiter verarbeiten, während Sicherungen geschrieben werden. Die Festplatte darf arbeiten, ohne dass der Tunnel beleidigt schweigt.
• Kleine Bedienungsnerven geschont: Die Objektspalten der Matrix teilen sich eine veränderbare, gemerkte Breite. Öffnen- und Speichern-Dialoge der AppImage starten im Startverzeichnis statt im eingebundenen AppImage. Niemand wollte sein Projekt zwischen den Verpackungsmaterialien ablegen.
• Importprüfung gehärtet: Widersprüchliche Verschlüsselungsangaben in Projekt- und Produkt-ZIP-Dateien werden abgelehnt. Das ergänzt keine AES-Unterstützung, sondern verhindert, dass widersprüchliche Archive durchgewunken werden.

Wichtig vor dem Update

• Sichern, bevor es spannend wird: Projekte, Produktkatalog und Server-/Docker-Daten unabhängig sichern. Das Projektdateischema bleibt gegenüber Alpha 16 unverändert; neue Backup-, Verlaufs- und System-2-Datensätze können von Alpha 16 aber abgelehnt werden. Ein Downgrade ist kein Rückwärtsgang mit Vollkasko.
• Experimentell bleibt experimentell: System-2 bleibt auf UP 258D12 mit Applikation M-0001_A-9205-04-9270 begrenzt. Die neuen Download- und Diagnoseänderungen sind mit simulierten beziehungsweise Loopback-Verbindungen getestet; daraus folgt kein bestätigter Hardwareerfolg und keine Wiederherstellungsgarantie. Issue #30 bleibt bis zur Klärung des tatsächlichen Ergebnisses offen.

Statistiken:

Alpha 17 in Zahlen – oder: Warum der Testrechner jetzt Urlaub beantragt

• Geschätzte aktive Entwicklungszeit: 40,5 Stunden zwischen Alpha 16 und Alpha 17. Parallel laufende Arbeiten werden dabei zeitlich zusammengefasst, nicht mehrfach addiert. Also keine 300-Stunden-Woche durch kreative Buchführung.
• 247 Commits inklusive Implementierung, Fehlerkorrekturen, Tests, Dokumentation und Release-Vorbereitung. Nicht jeder Commit bringt einen neuen Knopf – manche sorgen dafür, dass der vorhandene keinen Unsinn macht.
• 7.003 bestandene Rust-Tests im vollständigen Release-Paketlauf, verteilt auf 56 Testprogramme. Ergebnis: 0 fehlgeschlagen, zusätzlich 233 ignoriert. Ignorierte Tests zählen ausdrücklich nicht als bestanden.
• 4.553 bestandene Frontend-Tests mit Vitest. Damit nicht erst der Benutzer herausfindet, dass ein Dialog heute einen anderen Beruf ausüben möchte.
• 998 bestandene Browser-Testfälle: 925 im Paketlauf und 73 zusätzliche Release-Prüfungen. Der Paketlauf umfasst 856 funktionale Fälle und 69 Fälle in der exklusiven Testspur.
• Damit 12.554 erfolgreiche Testfall-Ausführungen allein aus Rust, Vitest und Browser-Prüfungen. Das sind Ausführungen der Testsuiten – nicht 12.554 neue Tests seit Alpha 16.
• Zusätzlich 155 von 155 Corpus-Testfällen bestanden, verteilt auf neun Testziele. Dazu kamen gesonderte Produktdatenprüfungen, unter anderem für Parameteransichten, Programmcode und eigenständige Produktpakete.
• Ein Release-Kandidat, ein vollständiger Gate-Versuch mit 30 Stufen. Zwei Stufen wurden zunächst rot, weil das Testwerkzeug die Matrix-Ausgabe auf dem falschen Dateisystem ablegen wollte. Nach korrigiertem Ausgabeort war der gezielte Wiederholungslauf grün. Produktfehler aus diesem Gate: 0. Auch die Qualitätssicherung braucht gelegentlich Qualitätssicherung.

Die neuen Bus- und Downloadfunktionen wurden mit Simulation beziehungsweise Loopback-Verbindungen getestet. Diese Zahlen sind kein Nachweis für physische Gerätekompatibilität oder erfolgreiche Wiederherstellung an echter Hardware. Bei diesen Release-Prüfungen wurde kein realer KNX-Bus gequält.

Code Statistiken:

KNXBench – aktuelle Größe der Codebasis
Stand: 26. Oktober 2026, 15:00 Uhr
Basis: Veröffentlichter main-Commit fb26c47c3, mit dem GitHub-Stand abgeglichen
Messwerkzeug: Tokei 15

Kurzfassung

KNXBench umfasst aktuell:

• 545.656 Codezeilen
• 55.680 Kommentar- und Dokumentationszeilen im Quellcode
• 2.032 Quelldateien

Aufteilung nach Sprache

• Rust: 399.139 Codezeilen · 42.841 Kommentarzeilen · 1.009 Dateien
• TypeScript: 58.563 Codezeilen · 6.423 Kommentarzeilen · 527 Dateien
• TSX / React: 59.808 Codezeilen · 5.098 Kommentarzeilen · 318 Dateien
• Python: 17.217 Codezeilen · 311 Kommentarzeilen · 85 Dateien
• CSS: 5.325 Codezeilen · 670 Kommentarzeilen · 33 Dateien
• JavaScript: 3.486 Codezeilen · 113 Kommentarzeilen · 29 Dateien
• HTML einschließlich eingebetteter Skripte und Styles: 1.895 Codezeilen · 172 Kommentarzeilen · 26 Dateien
• Shell: 223 Codezeilen · 52 Kommentarzeilen · 5 Dateien

Damit entfallen 73,1 % des Codes auf Rust. Auf jeweils 100 Codezeilen kommen etwa 10,2 Kommentarzeilen.

Zählweise: Enthalten sind Anwendung, Bibliotheken, Tests, Werkzeuge sowie Website und Projektstory. Nicht enthalten sind Markdown-Dokumente, JSON-Daten, Lockfiles, Konfigurationen, Abhängigkeiten und Build-Ausgaben. Die 31 generierten TypeScript-Bindings sind ebenfalls herausgerechnet.

„Kommentare“ meint hier Zeilen, nicht einzelne Kommentarblöcke. Rust-Dokumentationskommentare sind eingeschlossen.

Testcode

In 996 separat erkennbaren Testdateien stecken 236.380 Codezeilen. Das entspricht 43,3 % der gesamten gezählten Codezeilen.

Tests, die direkt in Produktionsdateien eingebettet sind, sind in diesem Testdatei-Anteil noch nicht enthalten.

Wichtig: Diese Einordnung erfolgt anhand der Dateipfade. Sie ist weder eine Testabdeckungsquote noch eine Anzahl ausgeführter Tests.

Aufteilung nach Projektbereich

• Bibliotheken unter crates/: 264.196 Codezeilen
• Anwendungen unter apps/: 255.807 Codezeilen
• Hilfswerkzeuge unter tools/: 14.752 Codezeilen
• Rust-Projektwerkzeuge unter xtask/: 3.205 Codezeilen

Innerhalb der Anwendungen:

• Weboberfläche: 123.560 Codezeilen
• Server: 99.600 Codezeilen
• CLI: 26.210 Codezeilen

Jeweils einschließlich der dort liegenden Tests.

Dokumentation und Architektur

• 824 Markdown-Dateien unter docs/ mit insgesamt 137.674 Zeilen, einschließlich Leerzeilen
• Darunter 149 nummerierte Architekturentscheidungen (ADRs)
• Im gesamten Repository: 1.269 Markdown-Dateien mit 184.828 Zeilen, einschließlich archivierter Arbeits- und Übergabenotizen

Diese Dokumentation ist nicht in den oben genannten Kommentarzeilen enthalten.

Die größten Quelldateien

• crates/knx-core/src/command.rs: 8.954 Codezeilen
• apps/knx-server/src/domain.rs: 7.352 Codezeilen
• apps/knx-cli/src/main.rs: 4.709 Codezeilen
• crates/knx-net/src/commissioning.rs: 4.492 Codezeilen
• crates/knx-core/src/dpt/codec.rs: 4.171 Codezeilen

Repository insgesamt

• 3.767 versionierte Dateien
• 81,9 MiB Dateiinhalt, ohne Git-Historie, Abhängigkeiten und Build-Artefakte
• 19 Rust-Workspace-Pakete
• 4.000 vom gemessenen Stand erreichbare Commits
• Frühester Commit: 2. September 2026