ETS? Nein Danke!

[thengsty]

Jetzt musst du nur noch den Teil mit "bist du ein Mensch" mit "Ja" oder "Nein" beantworten.

Bist du einer?

[DiMa]

Das dürfte wohl eher eine rhetorische Frage sein - oder glaubst du, dass ich eine KI bin, die die Forums-DB so sorgfältig manipuliert hat, dass du Beiträge von mir findest, die 10 Jahre älter als GPT-3 sind?

[thengsty]

Nicht rethorischer als deine (unsinnige) Frage.
Dazu musst du keine DB manipulieren. Es reicht wenn du 9 Jahre selbst schreibst und dann die KI antworten lässt.

Lassen wir das...

[DiMa]

Der Unterschied: Ich schreib' hier seit 13 Jahren und nicht nur zu SW-Themen und falle nicht mit einer KI-erzeugten ETS und KI-erzeugten Antworten vom Himmel.

[KNXBench]

KNXBench Alpha 21 – das hat sich seit Alpha 20 getan
Neue Funktionen

• Ausstehende Programmierung im Blick: Geräte und Tabs kennzeichnen offene Änderungen. Eine neue Übersicht listet die betroffenen Geräte und führt direkt zum Editor oder zur Programmierung.
• Vergleich mit dem letzten Download: Parameterwerte, Gruppenadressverknüpfungen und Objektflags lassen sich mit dem letzten abgeschlossenen KNXBench-Download vergleichen. Teilprogrammierungen aktualisieren nur die tatsächlich übertragenen Bereiche.
• Geänderte Parameter schneller finden: Markierungen und Zähler führen durch Bereiche, Abschnitte und eingeklappte Gruppen – auch zu Änderungen, die gerade durch Suche oder Filter verborgen sind.
• Alle ausstehenden Geräte programmieren: „Alle ausstehenden programmieren …“ zeigt die geplanten Schritte vorab, verlangt eine ausdrückliche Bestätigung und stoppt beim ersten Fehler oder unklaren Zustand.
• Gruppenadressbeschreibungen bearbeiten: Beschreibungen sind direkt im Inspektor editierbar. Beim CSV-Import können sie über eine ausdrücklich bestätigte Option gelöscht werden; über MCP sind sie lesbar.
• Mehr Produktinformationen: Herstellername sowie technische Daten, Applikations- und Herkunftsinformationen sind in den Produktansichten verfügbar.
• Bessere Parameterdarstellung: Deutsche Metadatenbeschriftungen und bedingungsabhängige Abschnittstitel verbessern die Orientierung im Parametereditor.
• Mehr Varianten bei der Downloadvorbereitung: Erweiterungen für Property-Schreibzugriffe, kurze Speichersegmente, bitübergreifende Parameter und Gleitkommawerte einschließlich DPT-9-Rundung. Passende bedingte Zweige und unsichtbare zugewiesene Parameter werden berücksichtigt; die betroffenen Geräte bleiben als „ungetestet“ gekennzeichnet.
• TCP erweitert: TCP ist ausdrücklich für Linien- und Gerätescans, lesende Seriennummernabfragen und die Byte-Reihenfolge-Prüfung auswählbar. UDP bleibt Standard; TCP und USB/seriell sind klar als experimentell gekennzeichnet.
• Fortschritt und Hintergrundaktivitäten: Die Statusleiste zeigt laufende Downloads, bereits erledigte Arbeit und Hintergrundaufgaben.

Verbesserungen und Fehlerkorrekturen

• Bearbeiten während des Speicherns: Gewöhnliche Editorabfragen und Änderungen müssen nicht mehr hinter einem laufenden Projektspeichervorgang warten. Dateioperationen wurden aus der asynchronen Server-Laufzeit ausgelagert.
• Historie im Hintergrund: Änderungen werden bestätigt, bevor das Historienjournal im Hintergrund geschrieben wird. Schreibfehler werden gemeldet und führen beim Beenden nicht mehr zu einer falschen Erfolgsmeldung.
• Robusterer Geräteeditor: Veraltete Antworten überschreiben keinen neueren Editorzustand mehr; die Bereitschaftsanzeige ist gerätebezogen.
• Aufgeräumte Kommunikationsobjekte: Verknüpfungen stehen zuerst, die Werkzeugleiste ist kompakter und Senden/Empfangen lässt sich eindeutiger einstellen. Die erste neue Verknüpfung sendet, weitere empfangen; kombinierte Richtungen werden korrekt behandelt.
• Präzisere Programmierpläne: Vor dem Start wird auf ausstehende Änderungen hingewiesen, die der gewählte Programmierumfang nicht abdeckt.
• Korrekte Parameterauswahl: Auswahllisten enthalten keine erfundene „Keine“-Option mehr, wenn das Produkt diese nicht vorsieht.
• Gezieltes Stoppen: Die Stop-Aktion bei einem durch den Monitor belegten Downloadzugang beendet den tatsächlich zugehörigen Monitor.
• Weitere Alltagskorrekturen: Eindeutige Kennungen für neue Projekte, keine verdeckten Datei-Menüaktionen durch Hinweise, eine positionsstabile Beschriftung des letzten Downloads und einheitliche deutsche Begriffe fürs Programmieren.

Alpha 21 in Zahlen

• Veröffentlicht: 13. November 2026.
• Entwicklungszeit seit Alpha 20: Geschätzt 49,8 aktive Stunden in 34 Arbeitsblöcken, verteilt über rund vier Kalendertage.
• Änderungsumfang: 241 Commits, davon 203 ohne Merge-Commits; 600 geänderte Dateien mit 48.661 hinzugefügten und 2.560 entfernten Zeilen.
• Rust-Tests: 8.949 bestanden, 0 fehlgeschlagen; zusätzlich 252 ignorierte Tests, die nicht als bestanden zählen.
• Frontend-Unit-Tests: 5.737 bestanden.
• Browser-Testausführungen: 1.229 in der Fixture-Umgebung, 844 in 37 Produktionskonfigurationen, 45 zusätzliche sowie zweimal 12 native Testszenarien. Die Suiten überschneiden sich und sind deshalb keine eindeutige Gesamttestzahl.
• Korpustests: 155 von 155 bestanden; zusätzlich 15 Tests in vier Gesamtkorpus-Produktmodulen sowie Prüfungen für historische Produktnamen und die Download-Abdeckungsbasis.
• Produktdatenvergleich: Alpha 20 und Alpha 21 liefern bei 28 von 28 ausgewählten realen Produktdateien identische Importergebnisse.
• Release-Abnahme: 23 von 23 Prüfstufen erfolgreich; Upgrade-Proben für Projektdateien und Produktdatenbank ohne Fehler.

Vor dem Update sichern: Projektdateien wechseln von Schema 19 auf 21, die Produktdatenbank von Version 32 auf 33. Alpha 20 kann die konvertierten Daten nicht mehr öffnen.

Alpha 21 merkt sich jetzt, was noch programmiert werden muss. Damit ist sie meinem Gedächtnis bereits eine Version voraus.

Einen Großen Dank geht an die Unermüdlichen Tester!

[sewi]

Ein RC, der bei Stufe 29 von 30 hängen bleibt, ist kein Skandal, sondern genau der Grund, warum es RCs und 30 Prüfstufen gibt.

Dann ist das ein schönes Zeichen, dass man vielleicht mal die Pointen links liegen lässt - weil wenn in jedem Satz ein "Schmäh" ist, dann es ist sowieso nicht mehr lustig - und lieber sachlicher schreibt. Das sieht dann auch professioneller aus. Wenn ich Pointen will, dann kann ich jeden Text (und wenn jemand das braucht, kann der auch meinen Text) durch die KI lassen, und sagen "ich will in jedem Satz einen witzigen Schenkelklopfer drinnen haben". Das hat auch nichts mit einer "negativen Grundstimmung" zu tun. Wenn du schriebst "2 Release-Kandidaten: Der erste fiel bei 29 von 30 Prüfstufen durch" - dann liest sich das bei 29 Tests (also 29 mal) durchgefallen, und nur ein Test bestanden. Lieber klar, als witzig. Gerade bei Alpha, gerade bei etwas Kritischerem wie KNX. Hier geht es ja nicht um "Unterhaltung", sondern du willst, dass Leute "testen".

Und ein wackeliger Test, den man 300-mal laufen lässt, um sicher zu sein, dass er nicht mehr wackelt, ist das Gegenteil von Pfusch.

Vielleicht ist das auch so eine witzige Pointe, aber da liest man eben "der Test war 300x wackelig, aber nach dem 300x mal hab ich ihn endlich so weit hingebogen, dass er ging.". Wenn's nicht so gemeint war - besser präzise schreiben. Mit ersterem schafft man kein Vertrauen, mit zweiterem schon. Bei so einem Projekt ist Vertrauen wichtig - in mehrfacher Hinsicht. Vertrauen dass man sauber gearbeitet hat, Vertrauen dass man dann auch in der Zukunft mit dem Projekt arbeiten kann - vor allem wenn man dann keine ETS mehr verwendet.

„Alpha“ heißt: nicht auf die Kundenanlage, nicht auf die eigene Hauptverteilung, sondern auf den Testaufbau. Wer eine Alpha produktiv einsetzt, hat das YOLO schon vor der Installation gewählt – dafür braucht's meinen Changelog nicht.

Wie andere geschrieben haben - so wie der Thread aufgemacht ist, und so wie geschrieben wurde, entsteht der Eindruck "ETS weg, brauchst nur mehr mein Produkt". Den Eindruck haben mehrere, deshalb auch die entsprechenden Beiträge weiter oben, wo z.B. auch willisurf - der mMn sehr offen ist - die Notwendigkeit gespürt hat mitzuteilen "passt auf - Alpha! So einfach ist es nicht."

Probier die App gern mal aus, dann reden wir über Bugs statt über Formulierungen.

Die Zeit, jedes Projekt (und gerade durch die KI sprießen die Projekte so richtig aus dem Boden) mal eben so auszuprobieren, haben wohl wenige. Ich bin auch kein kleines Kind das Achievement-Hunten muss, und auch die "goldene Bus-Probe" gibt mir nix. Mein Feedback beschränkt sich daher auf meinen Beitrag, in der Hoffnung, so zu einer Verbesserung beizutragen. Es geht dabei auch darum, zu sagen "hoppala, RC und 29x durchgefallen, ist das ernst?" oder "drei hundert Mal einen Test anzupassen ist ganz schön viel". Wenn du's anders meinst, dann ist es schon richtig, über Formulierungen zu reden, gerade bei einem Stadium (Alpha) und bei einem Bereich (Vertrauen) wo Formulierungen wichtig sind.

Und Rumstänkern hinter "Kritik" zu verstecken ist auch nicht der Richtige Weg.

Aber umgekehrt ist es auch nicht der richtige Weg, Kritik als ein "Rumstänkern" abzutun.

Bist du ein Mensch? Falls ja, schreibst du selbst? Es ließt sich alles so 🤷♂️

Also zumindest selbst bei der kurzen Antwort an mich waren bereits em-dashes drinnen, und „“, und in der Antwort auf Axel aber normale Anführungszeichen. Somit ist klar, welchen Beitrag ein Mensch geschrieben, und wieviel Zeit und Mühe man in die Antwort investiert hat (was dann relevant ist wenn man dann von mir Zeit und Mühe möchte). Insofern kann ich nachvollziehen, wieso das für thewhobox so klingt. Aber gut, mein Beitrag ist ja auch für alle anderen Leser, mit einer KI brauch ich nicht öffentlich herumzuargumentieren

[jcd]

Ich frage mich, was diese Fokussierung auf die Statistiken und Test bringen soll? - Das bezieht sich aber nicht nur auf dieses Projekt, sondern sehe ich in letzter Zeit öfter und scheint ein antrainiertes KI Verhalten zu sein.

Ist das aus der globalen Berufswelt (ich glaube in Deutschland ist das noch weniger der Fall als im
Ausland) adaptiert, wo die Leistung und Qualität eines Mitarbeiters nicht durch persönliche Beurteilung, sondern rein durch Kennzahlen und Metriken definiert wird?

Die Aussagekraft einer Metrik ist Null, sobald deren Berechnung bekannt wird.

Die KI kann zehntausende Tests einbauen und prüfen ob der Code 1+1 fehlerfrei addiert. Aussagen wie 1000 von 1000 Tests erfolgreich sind m.E. absolut wertlos.
Anzahl an Commits? - Wertlos. Die KI kann auch jedes Zeichen einzeln ändern. Anzahl an geänderten Zeilen? Anzahl an Tokens, Stunden,…? Ich halte das alles für nutzlos.

Der vernüftiger Changelog (hier der Fall) ist, was m.E. zählt!

(sieht man heutzutage leider viel zu selten…stattdessen „Nutzererfahrung verbessert“)

[KNXBench]

sewi

Auch die 300 Testdurchläufe dienten der Überprüfung der Stabilität und Reproduzierbarkeit, nicht dazu, einen Test so lange zurechtzubiegen, bis er endlich grün wird. Wiederholte und automatisierte Tests, beispielsweise beim Fuzz-Testing, sind in der Softwareentwicklung nichts Ungewöhnliches. Das ist ein erheblicher Unterschied.

Der Titel „ETS? Nein danke!“ ist bewusst provokant gewählt. Er soll Aufmerksamkeit für eine mögliche Alternative schaffen, nicht suggerieren, dass KNXBench bereits ein vollständiger ETS-Ersatz ist.

Ja, ich nutze KI. Auch beim Programmieren und gelegentlich beim Formulieren. Daraus anhand von Gedankenstrichen und Anführungszeichen Rückschlüsse auf meine persönliche Beteiligung, den investierten Aufwand oder die Qualität meiner Arbeit zu ziehen, halte ich für ziemlich gewagt und ehrlich gesagt auch für anmaßend.

Was mich allerdings zunehmend stört: Es wird sehr viel über die Formulierungen und die vermeintliche Qualität des Projekts diskutiert, obwohl offenbar einige der Kritiker KNXBench noch nie selbst ausprobiert haben.

Natürlich kann und darf man meine Kommunikation kritisieren, ohne die Software installiert zu haben. Wenn es allerdings um die technische Qualität, Zuverlässigkeit oder Praxistauglichkeit geht, wünsche ich mir eine Diskussion auf Grundlage konkreter Erfahrungen und nachvollziehbarer Fakten. Alles andere bleibt Spekulation.

Also, sachliche Kritik ist ausdrücklich willkommen. Allerdings sollte sie genauso fair und respektvoll formuliert sein, wie du es von mir erwartest. Das gilt in beide Richtungen. Meine Formulierung „Rumstänkern“ war in diesem Zusammenhang ebenfalls nicht besonders glücklich. Dazu stehe ich.

Ich nehme deine Hinweise zur Verständlichkeit mit. Gleichzeitig wünsche ich mir, dass wir wieder stärker über das Projekt, seine Möglichkeiten und seine tatsächlichen Schwächen sprechen.

Denn am Ende entscheidet nicht die Anzahl der Gedankenstriche über die Qualität einer Software, sondern das, was sie tatsächlich leistet.

Gruß

[KNXBench]

jdc

Da bin ich sogar in einigen Punkten bei dir. :-)

Reine Zahlen ohne Kontext sagen tatsächlich wenig aus. 1.000 erfolgreiche Tests sind wertlos, wenn sie 1.000-mal das Falsche prüfen. Genauso wenig sagen Commits, geänderte Codezeilen oder verbrauchte Tokens etwas über die Qualität einer Software aus.

Allerdings würde ich daraus nicht ableiten, dass Metriken grundsätzlich wertlos sind. Entscheidend ist, was gemessen wird, wie getestet wird und welche Aussagen sich daraus tatsächlich ableiten lassen.

Gerade bei einem Projekt wie KNXBench sind automatisierte Tests wichtig. Wenn beispielsweise ein importiertes KNX-Projekt nach dem Speichern nicht mehr korrekt eingelesen werden kann oder unbekannte Daten verloren gehen, ist das ein echtes Problem. Solche Dinge lassen sich gezielt und reproduzierbar prüfen.

Die Teststatistiken veröffentliche ich übrigens nicht, um irgendwelche Qualitätsrekorde aufzustellen oder die Anzahl erfolgreicher Tests als Gütesiegel zu verkaufen.

Sie sollen auch verdeutlichen, dass KNXBench nicht einfach irgendwie zusammengeschustert wird, sondern nach etablierten Konzepten moderner Softwareentwicklung entsteht.

Dazu gehören automatisierte Tests, klar definierte Qualitätsprüfungen, kontinuierliche Integration (CI) und die Trennung zwischen Entwicklung, Test und produktiver Freigabe. Fehler sollen möglichst früh erkannt werden, bevor sie beim Anwender landen.

Damit das Ganze nicht nur eine Behauptung bleibt, gibt es einen öffentlich einsehbaren Testkatalog. Dort ist dokumentiert, welcher Test was prüft und welchen Zweck er erfüllt.

Jeder kann sich also selbst ein Bild davon machen, ob wir tatsächlich 1.000-mal "1 + 1 = 2" prüfen oder ob hinter den Tests sinnvolle Qualitätssicherung steckt. ;-)

Ein grüner Testbericht beweist nicht, dass Software fehlerfrei ist. Ein fehlgeschlagener Test zeigt aber ziemlich zuverlässig, dass noch Arbeit vor uns liegt.

Die Zahlen sind also kein Beweis für perfekte Software, sondern ein Einblick in den Entwicklungsfortschritt und den Qualitätssicherungsprozess. Sie machen sichtbar, wo Probleme gefunden, behoben und anschließend erneut überprüft wurden.

Und beim Changelog bin ich voll und ganz deiner Meinung. Deshalb versuche ich auch, nachvollziehbar zu dokumentieren, was sich tatsächlich geändert hat. Teststatistiken und Changelog ergänzen sich dabei, erfüllen jedoch unterschiedliche Aufgaben.

Gerade weil KNXBench irgendwann eine ernsthafte Alternative zur ETS werden soll oder könnte, halte ich diesen Aufwand für wichtig. Vertrauen entsteht schließlich nicht durch große Versprechen oder beeindruckende Zahlen, sondern durch nachvollziehbare Entwicklung, transparente Dokumentation und Software, die in der Praxis zuverlässig funktioniert.

Am Ende zählt nicht, wie viele Tests KNXBench besteht, sondern ob die Software zuverlässig funktioniert. Die Tests helfen dabei, genau das sicherzustellen.

Gruß

[Axel]

Nur um das klar zustellen. Wenn jemand mit einem KI schreibt, finde ich es nicht verwunderlich wenn man nachfragt ob man eine KI ist. Beziehungen sind zwischen Menschen, egal wie er schreibt oder spricht!

Es ist null abwertend von der Leistung eines Menschen. Denn auch mit KI ist es natürlich Leistung und Zeit was man da reinsteckt! Nur eben schneller. Ist ja nicht so das man sagt, mach und alles ist fertig 😉

Ich mag es lieber wenn man selbst schreibt und ggf. Über KI korrigieren lässt. Aber voll KI Texte sind doch … soll ich dann mit meiner KI antworten 😂 nee

gutes Projekt. Und wie schon gesagt. ETS Import und Export würden das Projekt enorm Vorwärts bringen.

[KNXBench]

Axel

ETS-Import geht seit Tag eins. Steht übrigens auch im Starterbeitrag :-)

Export nach ETS ist "Rechtlich" ohne Weiteres nicht möglich. Schau bitte weiter "oben" in den Beiträgen, da ist es erklärt.

Das ist natürlich aus Sicht von KNXBench gesehen :-)



Gruß

[boonkerz]

Mir gefällt die Oberfläche an sich nicht, irgendwie wird sehr viel Platz verschwendet.
Große Eingabe-boxen dicke Margins. usw. es wirkt mehr wie eine Webseite als eine Technische-Anwendung.

Auch wird wenn z.b. keine Name vergeben bei anderen Anwendungen einfach der Produktname verwendet
Keine Gruppierung beim selben Projekt.
image.png

image.png

[KNXBench]

boonkerz

Jepp, sehe ich genauso. Momentan gibt es noch andere Tasks, die Vorrang haben.

Und es sieht wie eine Webseite aus, weil es im Prinzip eine ist :-)

Ist aber auf der Kosmetik-To-Do-Liste. Da arbeite ich von Version zu Version dran. Bis zur Beta ist das deutlich "aufgeräumter".

Stell dir vor, wie das auf einem 49" Ultra Wide Monitor aussieht :-)

Was meinst du mit Keine Gruppierungen im selben Projekt?


Danke und Gruß

[henfri]

Können wir uns dann darauf einigen, dass du posts, die du mit KI Hilfe geschrieben hast eindeutig als solche markierst?
.
Das wäre für mich das mindeste.


Eigentlich möchte ich hier im Forum gar nicht mehr oder weniger mit KI kommunizieren.

[boonkerz]

Die Parameter sind nicht gruppiert.