Durch das modulare Konzept von OpenKNX-Applikationen haben wir den Vorteil, dass wir gewisse Neuerungen auch so einführen können, dass sie für alle unsere Applikationen gelten, indem wir sie in unserem Basis-Modul (Common) implementieren, dass alle Applikationen nutzen.
Im vergangenen Jahr haben wir uns nicht nur bemüht, neue Features in unsere Module zu implementieren, sondern auch große Anstrengungen unternommen, applikationsübergreifende Funktionen zu verbessern und zu erweitern. Im Folgenden möchte ich euch einige dieser Punkte vorstellen. Ihr werdet sie nach und nach in den nächsten Releases unserer Applikationen finden.
Update - April 2026:
Neue Info-LED behandlung
Wir haben viele Geräte mit unterschiedlichen LEDs, die bisher Hardware-Spezifisch einige Zustände angezeigt haben. Bedingt durch die hohe Modularisierung gibt es immer mehr Zustände, die man dem User nahebringen will - aber eine begrenzte Zahl an LEDs, die zur Verfügung stehen. Und immer komplexere Blink-Codes (die alle notwendigerweise erklärt werden müssen) helfen irgendwann auch nicht weiter.
In Zukunft können bei parametrisierten Geräten die Zustände, die auf den LEDs angezeigt werden sollen, vom Benutzer gewählt und mit einem Kommentar versehen werden.
image.png
Das neue Verhalten ist in unserem Wiki beschrieben.
Neues Verhalten von Geräten ohne PA oder ohne Programmierung
Wir haben festgestellt, dass vielen Leuten nicht klar ist (oder sie vergessen es immer wieder), dass man nach einem Firmware-Update, der sich in den ersten beiden Stellen der Version unterscheidet (z.B. von 4.2.x auf 5.1.x) auch die ETS-Applikation aktualisieren und das Gerät neu programmieren muss. Manchmal (selten) ist nach einem Firmware-Update auch das erneute Setzen der PA notwendig.
Als Konsequenz versuchen wir, über die LEDs darauf aufmerksam zu machen. Der erste Versuch (in den aktuellen Releases) war leider uneinheitlich (teilweise blitzt die Prog-LED, teilweise blinkt die Info1-LED).
Jetzt haben wir darüber gesprochen und uns für ein einheitliches Vorgehen entschieden. Wir haben auch berücksichtigt, dass nicht alle Geräte eine Info-LED haben.
Ab der nächsten Version werden alle OpenKNX-Geräte:
Schnellere Programmierung mit der ETS
Wir haben noch ein paar ETS-Einstellungen (intern) gefunden, mit der man die Programmierung unserer Geräte (mit modernen Schnittstellen) schneller machen kann. Das wird in die nächste Firmware-Generation aller Geräte einfließen. Damit sind wir bei partieller Programmierung um bis zu 40% schneller, bei vollständiger Programmierung um bis zu 10%.
Direktkommunikation vom Gerät mit der ETS über JavaScript
Einige unserer ETS-Applikationen haben bereits Funktionen eingebaut, die direkt mit dem Gerät kommunizieren, um bestimmte Sachen abzugleichen. Zum Beispiel die Prüfung von Benutzerformeln im Logikmodul, die Kalibrierung den HF-Sensors im Präsenzmelder oder das Anlernen der Finger im Fingerprint vom AccessControl.
Diese Funktionen haben alle mit älteren Schnittstellen oder Linienkopplern nicht funktioniert, weil keine ausreichend langen Telegramme unterstützt haben (Stichwort APDU, kann im Forum nachgelesen werden). Wir haben alle Funktionen so umgeschrieben, dass sie jetzt auch mit der früher üblichen maximalen APDU von 15 klarkommen. Und wir werten auch die Neuerung (ab der ETS 6.3) aus, die uns die APDU bereitstellt, so dass wir für die Kommunikation die APDU nutzen können, die zur Verfügung steht.
Update - Oktober 2025:
ESP32 - KNX-IP Applikationen
Wir unterstützen jetzt neben dem RP2040 Microcontroller auch den RP2350 und den ESP32. Während der RP2350 "nur" ein schnellerer Microcontroller mit mehr Ressourcen ist (und natürlich auch teurer), bietet der ESP32 große Vorteile bei der Anbindung von IP-Services. Damit können wir LAN- und WLAN-Basierte KNX-IP Geräte bauen, die an Stellen eingesetzt werden können, an denen keine KNX-Leitung verfügbar ist.
Als Konsequenz dieser Hardware-Entwicklung versuchen wir alle Applikationen, bei denen es irgendwie Sinn macht, sowohl für TP wie auch für IP verfügbar zu machen. Für einige wenige Applikationen hatten wir auch bisher eine TP- und eine IP-Variante, was immer doppelpflege bedeutete. Die große Neuerung ist, dass wir es geschafft haben, TP und IP mit nur einer ETS-Applikation zu realisieren. Man kann also in der ETS eine Applikation von der TP-Linie auf die IP-Linie ziehen, das passende IP-Gerät damit programmieren und es läuft, dann über KNX-IP. Ihr erkennt solche Applikationen in Produktkatalog an dem Medientyp TP, IP:
image.png
Wesentlich robustere KNX-TP Kommunikation - neue TPUART-Library
Auch eher im Hintergrund - genauer gesagt als Unterbau - arbeitet eine komplett neu geschriebene Bibliothek für die KNX-TP-Kommunikation. Wir hatten in der Vergangenheit festgestellt, dass bei hoher momentaner Buslast und gleichzeitig hoher Auslastung des Microcontrollers einzelne KNX-Telegramme verloren gehen konnten. Im Allgemeinen nicht schlimm, das passiert bei jedem KNX-Gerät und dafür gibt es auch Wiederholtelegramme, aber wir wollten hier einfach so gut werden wie nur möglich, damit solche Module wie das Logikmodul oder der Zustandsautomat, bei denen ein Telegrammverlust potentiell zu einer falschen Auswertung führt, auch zuverlässig funktionieren können. Man kann bei KNX keine 100% erreichen, aber wir waren vorher geschätzt bei 99.9% (1 Telegrammverlust von 1000 Telegrammen) und sind jetzt eher bei 99,999% (1 Telegrammverlust von 100000 Telegrammen). Das hört sich nach wenig an, hat aber zu einer wesentlich höheren Robustheit geführt, wie sich gleich im nächsten Punkt zeigt.
Firmware-Update über den KNX-Bus - verbesserter FileTransferClient
Wir bieten schon länger die Möglichkeit, unsere Geräte auch über den KNX-Bus zu aktualisieren. Der Feldtest hat gezeigt, dass das bisherige Verfahren nicht robust genug war und es bei der Übertragung der (für den KNX-Bus riesigen) Firmware-Dateien vermehrt zu Abbrüchen kam. Durch die neue TPUART-Library, einen verbesserten FileTransferClient und besserem Timing in dessen Gegenstück, dass auf dem Gerät läuft, erreichen wir jetzt fast immer eine unterbrechungsfreie Übertragung. 2 Testbeispiele:
Test Einzelgerät (immer das selbe Gerät mit gleicher Programmierung):
Kleiner Wermutstropfen: Da ihr auf den Geräten derzeit noch eine alte Firmware habt, müsst ihr noch einmal mit der weniger robusten (alten) Übertragung klarkommen (um die neue Firmware aufzuspielen), bevor die neue dann greifen kann.
Dafür dann aber ein weiteres Highlight: In der neuen Firmware steckt auch eine Fortsetzungsoption (Resume) einer abgebrochenen Übertragung: Wenn man nach einem Abbruch (der ja kaum noch passiert) die Übertragung erneut startet, macht er an der Stelle weiter, an der abgebrochen wurde.
Die Modulliste in der ETS - Nutze nur die Module, die Du brauchst
Die Modularisierung in OpenKNX erlaubt es uns, auch generische Applikationen zu bauen, die auf verschiedenen Hardwarevarianten laufen. Wenn eine Hardware 2 Binäreingänge hat und eine andere 4, machen wir keine 2 ETS-Applikationen dafür, sondern eine, bei der man einstellen kann, wie viele Binäreingänge diese Hardware hat.
Für Module war das bisher anders: Wenn ähnlich funktionierende Hardware mal mit 1-Wire-Support und mal ohne angeboten wird, dann gibt es nur eine ETS-Applikation mit 1-Wire-Modul und der User durfte das Modul einfach nicht verwenden. Ab sofort kann man auch ganze Module in der ETS ausblenden und so nur die Module eingeblendet lassen, die man verwenden möchte. Das erhöht die Übersichtlichkeit der Applikation und reduziert die Komplexität für den Benutzer.
Man kann erreichen, dass aus der Liste links die Liste in der Mitte wird, indem man Module deaktiviert:
image.pngimage.pngimage.png
Ergänzend dazu kann eine Applikation auch anbieten, einen Geräteabgleich zu machen. Damit werden die Module, die von der Hardware des Gerätes nicht unterstützt werden, automatisch deaktiviert. Dies hilft vor allem Benutzern, die nicht exakt wissen, welche Hardware was unterstützt und bewahrt sie davor, was zu konfigurieren, was sowieso nicht funktionieren kann. So wir z.B. das Netzwerkmodul (dass bei TP+IP Geräten immer dabei ist) auf einem reinen TP-Gerät deaktiviert.
image.png
UI-Konsistenz der Module in der ETS
Auch wenn man den Teil der Arbeit kaum sieht: Wir arbeiten stetig daran, dass die einzelnen Module - vereinigt in einer Applikation - eine möglichst einheitliche Benutzung und Interaktion mit dem Benutzer erlauben. Das ist sicherlich nicht perfekt gelungen, aber wenn man bedenkt, dass einzelne Module von individuellen Personen entwickelt wurden und die auch ihre kreativen Ideen verwirklichen wollen, sind wir schon nicht schlecht.
Das ist sicherlich ein Punkt, an dem wir stetig arbeiten und weiter arbeiten werden, ich wollte das hier nur erwähnen, um den Leuten im Team gerecht zu werden, die sich für solche Sachen einsetzen.
OpenKNX-Toolbox - der neue Weg, Firmware zu installieren und ETS-Applikationen zu erzeugen
Es gibt von OpenKNX Powershell-Skripte, die es erlauben, eine Firmware auf einem Gerät zu installieren, eine passende knxprod für die ETS zu bauen und so unsere Geräte in Betrieb zu nehmen. Da Powershell für Enduser einige Herausforderungen bietet, haben wir uns entschlossen, diesen Teil des Inbetriebnahme-Prozesses alternativ mit einem neuen Werkzeug - der OpenKNX-Toolbox - anzubieten.
Die OpenKNX-Toolbox ist ein Erfolg, sie wird von vielen Benutzern eingesetzt, aber der Feldtest hat gezeigt, dass es auf einigen Rechnern Probleme mit der Toolbox gibt. Aber noch schlimmer: Wir wissen nicht den Grund. Es sieht fast so aus, als ob wir bei der Toolbox auf eine falsche Technologie gesetzt haben - wir wollten sie plattformunabhängig entwickeln.
Die OpenKNX-Toolbox wird neu geschrieben - diesmal als reine Windows-Anwendung. Da man für die ETS auch Windows braucht, halten wir das für eine vertretbare Einschränkung. Vor allem, weil wir es bereits anders versucht haben und es einfach nicht funktioniert.
Das waren die Punkte, die mir am Herzen lagen. Danke an das ganze OpenKNX-Team, dass diese Verbesserungen - die ja alle unsere Applikationen betreffen - entwickelt und getestet hat. Bedenkt bitte immer, wir machen das in unserer Freizeit.
Gruß, Waldemar
Im vergangenen Jahr haben wir uns nicht nur bemüht, neue Features in unsere Module zu implementieren, sondern auch große Anstrengungen unternommen, applikationsübergreifende Funktionen zu verbessern und zu erweitern. Im Folgenden möchte ich euch einige dieser Punkte vorstellen. Ihr werdet sie nach und nach in den nächsten Releases unserer Applikationen finden.
Update - April 2026:
Neue Info-LED behandlung
Wir haben viele Geräte mit unterschiedlichen LEDs, die bisher Hardware-Spezifisch einige Zustände angezeigt haben. Bedingt durch die hohe Modularisierung gibt es immer mehr Zustände, die man dem User nahebringen will - aber eine begrenzte Zahl an LEDs, die zur Verfügung stehen. Und immer komplexere Blink-Codes (die alle notwendigerweise erklärt werden müssen) helfen irgendwann auch nicht weiter.
In Zukunft können bei parametrisierten Geräten die Zustände, die auf den LEDs angezeigt werden sollen, vom Benutzer gewählt und mit einem Kommentar versehen werden.
image.png
Das neue Verhalten ist in unserem Wiki beschrieben.
Neues Verhalten von Geräten ohne PA oder ohne Programmierung
Wir haben festgestellt, dass vielen Leuten nicht klar ist (oder sie vergessen es immer wieder), dass man nach einem Firmware-Update, der sich in den ersten beiden Stellen der Version unterscheidet (z.B. von 4.2.x auf 5.1.x) auch die ETS-Applikation aktualisieren und das Gerät neu programmieren muss. Manchmal (selten) ist nach einem Firmware-Update auch das erneute Setzen der PA notwendig.
Als Konsequenz versuchen wir, über die LEDs darauf aufmerksam zu machen. Der erste Versuch (in den aktuellen Releases) war leider uneinheitlich (teilweise blitzt die Prog-LED, teilweise blinkt die Info1-LED).
Jetzt haben wir darüber gesprochen und uns für ein einheitliches Vorgehen entschieden. Wir haben auch berücksichtigt, dass nicht alle Geräte eine Info-LED haben.
Ab der nächsten Version werden alle OpenKNX-Geräte:
- Wenn nur Firmware drauf ist, ohne PA: Prog- und Info1-LED blitzen 2x kurz auf. Das wiederholen sie alle drei Sekunden, bis eine PA programmiert worden ist. Nach einem Firmware-Update sieht man sofort, dass man sowohl die PA wie auch die ETS-Programmierung erneuern muss.
- Wenn Firmware und PA drauf sind, aber das Gerät durch die ETS noch nicht programmiert wurde (Status "Unconfigured"): Prog- und Info1-LED blitzen einmal kurz auf. Das wird auch alle 3 Sekunden wiederholt. Nach einem Firmware-Update sieht man sofort, dass man mit der ETS das Applikationsprogramm neu programmieren muss.
Schnellere Programmierung mit der ETS
Wir haben noch ein paar ETS-Einstellungen (intern) gefunden, mit der man die Programmierung unserer Geräte (mit modernen Schnittstellen) schneller machen kann. Das wird in die nächste Firmware-Generation aller Geräte einfließen. Damit sind wir bei partieller Programmierung um bis zu 40% schneller, bei vollständiger Programmierung um bis zu 10%.
Direktkommunikation vom Gerät mit der ETS über JavaScript
Einige unserer ETS-Applikationen haben bereits Funktionen eingebaut, die direkt mit dem Gerät kommunizieren, um bestimmte Sachen abzugleichen. Zum Beispiel die Prüfung von Benutzerformeln im Logikmodul, die Kalibrierung den HF-Sensors im Präsenzmelder oder das Anlernen der Finger im Fingerprint vom AccessControl.
Diese Funktionen haben alle mit älteren Schnittstellen oder Linienkopplern nicht funktioniert, weil keine ausreichend langen Telegramme unterstützt haben (Stichwort APDU, kann im Forum nachgelesen werden). Wir haben alle Funktionen so umgeschrieben, dass sie jetzt auch mit der früher üblichen maximalen APDU von 15 klarkommen. Und wir werten auch die Neuerung (ab der ETS 6.3) aus, die uns die APDU bereitstellt, so dass wir für die Kommunikation die APDU nutzen können, die zur Verfügung steht.
Update - Oktober 2025:
ESP32 - KNX-IP Applikationen
Wir unterstützen jetzt neben dem RP2040 Microcontroller auch den RP2350 und den ESP32. Während der RP2350 "nur" ein schnellerer Microcontroller mit mehr Ressourcen ist (und natürlich auch teurer), bietet der ESP32 große Vorteile bei der Anbindung von IP-Services. Damit können wir LAN- und WLAN-Basierte KNX-IP Geräte bauen, die an Stellen eingesetzt werden können, an denen keine KNX-Leitung verfügbar ist.
Als Konsequenz dieser Hardware-Entwicklung versuchen wir alle Applikationen, bei denen es irgendwie Sinn macht, sowohl für TP wie auch für IP verfügbar zu machen. Für einige wenige Applikationen hatten wir auch bisher eine TP- und eine IP-Variante, was immer doppelpflege bedeutete. Die große Neuerung ist, dass wir es geschafft haben, TP und IP mit nur einer ETS-Applikation zu realisieren. Man kann also in der ETS eine Applikation von der TP-Linie auf die IP-Linie ziehen, das passende IP-Gerät damit programmieren und es läuft, dann über KNX-IP. Ihr erkennt solche Applikationen in Produktkatalog an dem Medientyp TP, IP:
image.png
Wesentlich robustere KNX-TP Kommunikation - neue TPUART-Library
Auch eher im Hintergrund - genauer gesagt als Unterbau - arbeitet eine komplett neu geschriebene Bibliothek für die KNX-TP-Kommunikation. Wir hatten in der Vergangenheit festgestellt, dass bei hoher momentaner Buslast und gleichzeitig hoher Auslastung des Microcontrollers einzelne KNX-Telegramme verloren gehen konnten. Im Allgemeinen nicht schlimm, das passiert bei jedem KNX-Gerät und dafür gibt es auch Wiederholtelegramme, aber wir wollten hier einfach so gut werden wie nur möglich, damit solche Module wie das Logikmodul oder der Zustandsautomat, bei denen ein Telegrammverlust potentiell zu einer falschen Auswertung führt, auch zuverlässig funktionieren können. Man kann bei KNX keine 100% erreichen, aber wir waren vorher geschätzt bei 99.9% (1 Telegrammverlust von 1000 Telegrammen) und sind jetzt eher bei 99,999% (1 Telegrammverlust von 100000 Telegrammen). Das hört sich nach wenig an, hat aber zu einer wesentlich höheren Robustheit geführt, wie sich gleich im nächsten Punkt zeigt.
Firmware-Update über den KNX-Bus - verbesserter FileTransferClient
Wir bieten schon länger die Möglichkeit, unsere Geräte auch über den KNX-Bus zu aktualisieren. Der Feldtest hat gezeigt, dass das bisherige Verfahren nicht robust genug war und es bei der Übertragung der (für den KNX-Bus riesigen) Firmware-Dateien vermehrt zu Abbrüchen kam. Durch die neue TPUART-Library, einen verbesserten FileTransferClient und besserem Timing in dessen Gegenstück, dass auf dem Gerät läuft, erreichen wir jetzt fast immer eine unterbrechungsfreie Übertragung. 2 Testbeispiele:
Test Einzelgerät (immer das selbe Gerät mit gleicher Programmierung):
- ALT: 5 Versuche, erst beim 5. Versuch gelang die Übertragung, alle vorherigen sind abgebrochen
- NEU: 5 Versuche, alle waren erfolgreich und keine Übertragung ist abgebrochen
- ALT: Im Schnitt brauchte man bei jedem Gerät 2 Versuche, nur 3 Geräte gingen beim ersten Mal, 1 Gerät nach 5 Versuchen.
- NEU: Bei 20 Geräten musste man nur bei Gerät 15 einen 2. Versuch machen.
Kleiner Wermutstropfen: Da ihr auf den Geräten derzeit noch eine alte Firmware habt, müsst ihr noch einmal mit der weniger robusten (alten) Übertragung klarkommen (um die neue Firmware aufzuspielen), bevor die neue dann greifen kann.
Dafür dann aber ein weiteres Highlight: In der neuen Firmware steckt auch eine Fortsetzungsoption (Resume) einer abgebrochenen Übertragung: Wenn man nach einem Abbruch (der ja kaum noch passiert) die Übertragung erneut startet, macht er an der Stelle weiter, an der abgebrochen wurde.
Die Modulliste in der ETS - Nutze nur die Module, die Du brauchst
Die Modularisierung in OpenKNX erlaubt es uns, auch generische Applikationen zu bauen, die auf verschiedenen Hardwarevarianten laufen. Wenn eine Hardware 2 Binäreingänge hat und eine andere 4, machen wir keine 2 ETS-Applikationen dafür, sondern eine, bei der man einstellen kann, wie viele Binäreingänge diese Hardware hat.
Für Module war das bisher anders: Wenn ähnlich funktionierende Hardware mal mit 1-Wire-Support und mal ohne angeboten wird, dann gibt es nur eine ETS-Applikation mit 1-Wire-Modul und der User durfte das Modul einfach nicht verwenden. Ab sofort kann man auch ganze Module in der ETS ausblenden und so nur die Module eingeblendet lassen, die man verwenden möchte. Das erhöht die Übersichtlichkeit der Applikation und reduziert die Komplexität für den Benutzer.
Man kann erreichen, dass aus der Liste links die Liste in der Mitte wird, indem man Module deaktiviert:
image.pngimage.pngimage.png
Ergänzend dazu kann eine Applikation auch anbieten, einen Geräteabgleich zu machen. Damit werden die Module, die von der Hardware des Gerätes nicht unterstützt werden, automatisch deaktiviert. Dies hilft vor allem Benutzern, die nicht exakt wissen, welche Hardware was unterstützt und bewahrt sie davor, was zu konfigurieren, was sowieso nicht funktionieren kann. So wir z.B. das Netzwerkmodul (dass bei TP+IP Geräten immer dabei ist) auf einem reinen TP-Gerät deaktiviert.
image.png
UI-Konsistenz der Module in der ETS
Auch wenn man den Teil der Arbeit kaum sieht: Wir arbeiten stetig daran, dass die einzelnen Module - vereinigt in einer Applikation - eine möglichst einheitliche Benutzung und Interaktion mit dem Benutzer erlauben. Das ist sicherlich nicht perfekt gelungen, aber wenn man bedenkt, dass einzelne Module von individuellen Personen entwickelt wurden und die auch ihre kreativen Ideen verwirklichen wollen, sind wir schon nicht schlecht.
Das ist sicherlich ein Punkt, an dem wir stetig arbeiten und weiter arbeiten werden, ich wollte das hier nur erwähnen, um den Leuten im Team gerecht zu werden, die sich für solche Sachen einsetzen.
OpenKNX-Toolbox - der neue Weg, Firmware zu installieren und ETS-Applikationen zu erzeugen
Es gibt von OpenKNX Powershell-Skripte, die es erlauben, eine Firmware auf einem Gerät zu installieren, eine passende knxprod für die ETS zu bauen und so unsere Geräte in Betrieb zu nehmen. Da Powershell für Enduser einige Herausforderungen bietet, haben wir uns entschlossen, diesen Teil des Inbetriebnahme-Prozesses alternativ mit einem neuen Werkzeug - der OpenKNX-Toolbox - anzubieten.
Die OpenKNX-Toolbox ist ein Erfolg, sie wird von vielen Benutzern eingesetzt, aber der Feldtest hat gezeigt, dass es auf einigen Rechnern Probleme mit der Toolbox gibt. Aber noch schlimmer: Wir wissen nicht den Grund. Es sieht fast so aus, als ob wir bei der Toolbox auf eine falsche Technologie gesetzt haben - wir wollten sie plattformunabhängig entwickeln.
Die OpenKNX-Toolbox wird neu geschrieben - diesmal als reine Windows-Anwendung. Da man für die ETS auch Windows braucht, halten wir das für eine vertretbare Einschränkung. Vor allem, weil wir es bereits anders versucht haben und es einfach nicht funktioniert.
Das waren die Punkte, die mir am Herzen lagen. Danke an das ganze OpenKNX-Team, dass diese Verbesserungen - die ja alle unsere Applikationen betreffen - entwickelt und getestet hat. Bedenkt bitte immer, wir machen das in unserer Freizeit.
Gruß, Waldemar
Kommentar