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.
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.
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