[DISKUSSION] Wünsche an eine künftige ETS Applikation des Timberwolf Servers

[StefanW]

Hi Franky,

Zurück zum Thema: Warum den Restriktionen (und Kosten) der KNXA unterwerfen. Ich würde alles was geht außerhalb der ETS lösen.

Das ist, was wir mit dem Punkt 6. der mittelfristigen Vorhaben angedacht haben. Letztlich bauen wir uns eine API für die ETS, die wir dann aus dem TWS heraus ansprechen. Das Ziel ist, dass das Anlegen von Objekten, GAs, Flags usw. einfacher wird. Man mag dann darüber nachdenken, dass der TWS dann eine API nach außen bietet.

Hauptproblem ist, wie man das finanziert, weil das sind Funktionen, die danach riechen, dass uns diese niemand bezahlen wird. Allenfalls kann man einem Investor gegenüber argumentieren, dass sich der Server damit besser verkauft, was gut sein kann. Wir werden sehen.


Hallo Robert,

wobei ich die Notwendigkeit von 6) weniger sehe.
Für die Erstanlage der Objekte bietet sich aufgrund der Übersicht und Menge eine Vorbereitung in Excel inkl. Importer App einfach an.

Jep, aber so viele tun das offenbar nicht, weil es gibt schon viel Kritik, dass man die KNX Objekte des Timberwolf Servers über die ETS freischalten muss, obwohl das gleiche für jedes andere zertifizierte KNX Gerät auch gilt, aber irgendwie ist es "bäh" bei einem Server.

Liegt wohl daran, dass andere Server auf GA Basis arbeiten (denen dafür dann auch die Steuerung über Flags fehlt) und man für die korrekte Berechnung von Filtertabellen dann eine Dummy-Applikation von Hand spiegelbildlich führen muss. Obwohl letzteres total harikiri ist, wird das als normal hingenommen (weil das schon seit dem Ende des letzten Jahrtausends mit dem Homeserver so gegeben war) obwohl fehleranfällige Doppelbelastung.

Ich habe es aufgegeben, zu erklären, dass unser "Konzept" (eigentlich lediglich "Objekte KNX-konform über die ETS anzulegen") das technisch, organisatorisch und strategisch bessere Vorgehen ist, daher denken wir über einen "Reverse-Workflow mit Sync der ETS" nach. Dann haben wir beides. Im Rahmen der Möglichkeiten, weil bei neu erstellten GAs muss man die Kommunikationspartner (aka die anderen beteiligen KNX-Geräte) dann schon weiter mit der ETS einrichten.

Insgesamt geht es beim Timberwolf Server darum, dass Dinge vor allem einfacher einzurichten, leistungsfähiger, tiefer implementiert und stabiler in der Funktion ist. Das ist, was uns vom Wettbewerb unterscheidet, mithin gehört es schon zu unseren Genen, dass Bedienung einfacher ist.

Wir werden sehen, was möglich sein wird.

lg

Stefan

[AndererStefan]

Was den TWS in Punkto „Objekte anlegen“ von anderen KNX-Geräten (nicht Servern) unterscheidet, ist die schiere Menge an Objekten - natürlich abhängig von der persönlichen Nutzungsintensität.

Wenn ich bei einem Taster 10 Objekte definieren muss ist das überschaubar. Wenn ich bei TWS tausende Objekte anlegen will/muss, schlottern mir die Knie. Selbst wenn man den Visu-Aufbau in kleine Teilaufgaben zerlegt. „Mal eben“ alle Rollladen-GA verknüpfen sind leucht 100 Objekte oder mehr. Dazu muss dann auch der KO-Typ passend eingestellt werden. Ich schaff das manuell nie fehlerfrei was erneute Import/Export Runden nach sich zieht.

Natürlich ist eine Excel-Tabelle eine Lösung (ein MS unabhängiges Tool wäre noch besser). Aber nicht jeder hat seine GA-Verwaltung vorab in Excel angelegt. Und ist in der Lage sich mal eben so ein Tool zu erstelle. Ist ja auch ineffizient wenn jeder das Rad neu erfindet. Ich bastel derzeit an einem kleinen Excel-Tool, leider habe ich gerade nicht viel Zeit dafür. (viewtopic.php?f=45&p=61934#p61934)

Edit: Natürlich ist die Methode eigene KO am TWS zu haben genau die richtige. Ich habe kurz mal mit Nodered und Dummy-Devices gearbeitet, das finde ich Murks.

VG Stefan

[Franky]

Und ist in der Lage sich mal eben so ein Tool zu erstellen.

Sehe ich anders: Text des Prompts anpassen und der Code ist da. Wer das nicht schafft, bekommt die große Geasmtaufgabe imho schon gar nicht mal hin.

Ist ja auch ineffizient wenn jeder das Rad neu erfindet.

Auf den ersten Blick ja, aber ich habe die Erfahrung gemacht, dass man es erst dann richtig versteht, löst und mag, wenn man sich einarbeiten (musste) und sich auch die Hände (bildlich gesprochen) schmutzig machen musste.

Die Erstellung der Lösung (und sei es das Niederschreiben der Anforderung) ist vielleicht schon der sweet spot aus "wenig Aufwand" und "gewünschte Lösung erhalten" (?)

Franky

[gbglace]

Die Volumens Explosion entsteht beim TWS in der Applikation, durch die Tatsache, dass eben jedes KO jeden angebotenen DPT annehmen kann. In allem anderen ist die Applikation des TWS eher trivial.

Schau Dir mal die Applikation von einem OpenKNX Logikmodul + VPM an. Oder dazu noch das DALI GW oder gar der Statemaschine. Das Ding hat auch ne 4-stellige Anzahl KO und deutlichst mehr Komplexität, das XML bleibt aber halbwegs im Rahmen, weil die KOs zwar auch dynamisch verschiedene DPT annehmen können aber eben nicht alle. Die Jungs bringen die ETS da durch andere Feature in deren Applikation an die Grenzen.

Es widerspricht zwar unseren allgemeinen Ordnungssinn, weil die meisten sich wohl auch die KOs eher nach quasi virtuellem Endgerät orientiert anlegen, aber wären die KOs eher in groben Gruppen nach DPT sortiert, dann wäre die Verträglichkeit von 8000 KO oder mehr womöglich weniger ein Problem.

Ein paar Tests in diese Richtung hattet Ihr schonmal? Das man ggf KOs entweder ganz nach einzelnen DPTs oder kleineren verschiedenen DPT- Kombinationen dynamisch anbietet?

Ein klassischer Lichtkanal braucht zwar einige DPT aber eben nicht so viele.

Sollte sich das ganze irgendwie ausgehen. Sind womöglich auch mehr als 8000k drinnen und es gäbe dann immer noch genügend Platz für extreme Projekte, die den TWS in Spezialbereiche einsetzen wo ggf einfach nur 1000 T Sensoren benötigt werden.

Und wenn man solche KO Gruppen nach quasi Gewerken/Endgeräte Klassen anlegt, kommt man in den Folgejahren sicher auch besser mit dem auf ETS Seite weiteren Ausbau der "Funktionen" und Orientierung auf Semantik entgegen.

Wobei das alles jetzt kein großes Thema für Bestandsanlagen ist.
Aber in der Zukunft wird es entscheidend sein, wie schnell man eben den TWS mit seinen Funktionen am KNX Bus online haben wird. Die ImporterApp hilft da schon enorm die Zeit zu reduzieren.
Aber wenn da jemand bewusst sehr ETS zentriert arbeitet und die Innere Funktion des TWS nicht verstanden hat, der fragt sich rein vom Arbeitsschritt her warum soll man einen ETS Export machen in einen Tool kippen und dann die Importer-App benutzen, um damit die TWS KOs zu aktivieren und danach dann noch einen Export des gesamten Projektes und Import in den TWS, um eben an die nicht programmierbaren Metadaten des Projektes zu kommen und den Busmonitor sprechend zu haben.

Wenn die ETS mal das Thema Semantik sinnvoll umgesetzt haben wird, ja in der ETS6 werden wir das nicht mehr erleben, dann lassen sich solche nach Geräteklassen strukturierte dynamische KOs ggf auch damit ganz schnell integrieren.

Der Konkurrenz kann der TWS aber wahrscheinlich nur im Vorteil.bleiben wenn man diese API basierte Reverse Programmierung auf die Reihe bringt.

Denn wenn auch technologisch im Nachteil aber für den unbedarften Endkunden ist ein ETS Projekt Export und dessen Einladen in die Visu/Logik Server, die rein alle Telegramme nach GAs durchsuchen, dann viel schneller erledigt. Und wenn die dann auch noch die Semantischen Metadaten der ETS verarbeiten, dann ist es eben das was da als toll empfunden wird wenn daraus automatisch die virtuellen Endgeräte und Funktionen in den passenden Ordnern(Gebäudestruktur) angelegt werden. Bei IP-Symcom , RealKNX und auch dem OneHome ist man da derzeit auf diesem Weg. Die Jungs von HA versuchen das auch. Aber mangels Fortschritte bei der ETS klappt das bei denen allen auch alles noch nicht so gut.

Das Thema mit dem Dummyapplikationen macht einem die ETS seit KNX Secure allerdings auch etwas einfacher, weil man die GAs nicht mehr einzelnen Dummy-Applikationen Zuordnung muss, sondern es genügt sie einfach in Massen an z.B. einen Tunnel des IP-Gateways zu hängen, frei jedweder DPT Auswahl.
Und da man via IP-Secure damit auch eine ordentliche Zuordnung Softwareservice(IP-Adresse) zu PA realisiert, ist das für die Nutzer der Konkurrenz Systeme auch noch vertretbar und wird im Busmonitor auch transparent PA x.y.z = Visu auch nach teilweisen Reeboot der Komponenten.

Insofern, ja im Bestand wird es kein Feature sein womit viel Geld zu verdienen sein wird, aber am Neukundenpotenzial gemessen,, ist die Erweiterung der Applikation und deren Workflowoptimierung essentiell, um mit der Konkurrenz als Serversystem bestehen zu können, gerade da wo Zeit von zu bezahlender Handarbeit ein Faktor ist.

Gegen einen X1 und Gira-HS muss man da in der aktuellen SW da auch nicht schauen, da wird nix mehr kommen was denen da nen Vorteil bringt. Aber die dynamischen Konkurrenten werden ganz schnell alles verfügbare an zusätzlichen Metadaten der ETS zu nutzen wissen, um auch die Generierung von Datenpunkten in Ihren Systemen zu beschleunigen.

Da ich meine TWS KOs derzeit auch einfach von 1 an durch nummeriere, wie neue KOs benötigt werden, weil die Kanalstruktur und 10-er/100-er Gruppen eh nirgends passen und alle GAs sowieso in einem externen xls generiern lasse, finde ich den Gedanken Kanäle nach solchen Geräteklassen oder DPT-Kombinationsgruppen zu orientieren gar nicht verkehrt.

So lange das auch hilft das Volumen und die Performance der Applikation zu optimieren.

Eine solche Umstellung der Applikation hatte allerdings für den Bestand an TWS-Anlagen den Schmerzpunkt das dies wohl nicht wirklich updatefähig sein wird, da so manche GA Zuordnung/DPT Zuordnung dann nicht mehr passen würde.
Das würde dann also Timeseries brechen und auch viele interne KNX Objektverknüpfungen. Unbrauchbar machen bzw. Müssten geändert werden.

Dafür eine Migrationssoftware zu bauen, wäre wahrlich sehr aufwändig und schwer zu finanzieren, weil es eben nur dem Bestand treffen würde.

Sollte sich also die Reduktion der DPT Vielfallt je KO und deren entsprechende Gruppierung der entscheidende Hebel für mehr KO bzw. deutlich performantere Nutzung sein. Dann müsste man einige andere Features noch in die Alte Applikation (fehlende DPT und zukünftige Updates auf ETS Major-Versionen) vorhalten und andererseits eine Applikation 2.0 anbieten.

Hmm auch ein schwieriger Gedanke....

[gbglace]

Was Franky hier derzeit betreibt ist sicher auch nicht Jedermanns Sache, aber ja so lange man sich nicht die Hände schmutzig macht wird man den TWS und KNX nie vollständig verstehen.

Klar ist es schön wenn einem das Gerät solche Kopfarbeit abnimmt und es möglichst alles von allein funktioniert. Puuh was wird die Welt aber schlimm werden wenn da niemand mehr die grundsätzliche Mechanik unter der Haube verstanden hat. Am Ende ist trotz KI usw. Die Verdummung der Masse der Gesellschaft vorprogrammiert. Klar wird es vorerst immer noch Experten benötigen die das zu gestalten wissen aber auch hier wird es sich in der Menge konzentrieren.

Und ja KI richtig zu nutzen für Programmierung usw. Muss man sich erstmal lernen. Aber wenn man nicht den Anspruch hat die verschiedenen Programmiersprachen direkt zu lernen macht das sogar Freude und bringt schnelle positive Erfolgserlebnisse.

[Franky]

Hey, @gbglace Danke für diesen mega-Rundumschlag. Du hast auch noch einen Überblick, über den Entwicklungsstand der Mitbewerber, respekt!

Eine solche Umstellung der Applikation hatte allerdings für den Bestand an TWS-Anlagen den Schmerzpunkt das dies wohl nicht wirklich updatefähig sein wird, da so manche GA Zuordnung/DPT Zuordnung dann nicht mehr passen würde.
Das würde dann also Timeseries brechen und auch viele interne KNX Objektverknüpfungen. Unbrauchbar machen bzw. Müssten geändert werden.

Ja, das ist ein Punkt, der im Lebenszyklus (Funktionsumfang) von Software immer schlimmer wird. Die Aufgabe würde ich nachrangig betrachten.

• Die alten Anlagen laufen weiter, können zur Not händisch umgesetzt (neu aufgesetzt) werden (?)

• Ein Migrationstool könnte extern entwickelt werden(?) Auch hier hilft LLM. Und wenn man ein wenig altruistisch, zukunftsorientiert aufgestellt ist, stellt man seine Migrationslösung und Erfahrung anderen zur Verfügung.

Was Franky hier derzeit betreibt ist sicher auch nicht Jedermanns Sache, aber ja so lange man sich nicht die Hände schmutzig macht wird man den TWS und KNX nie vollständig verstehen.

Ja und imho kein Argument gegen die Technologienutzung (LLM), sondern einfach die Frage, ob man mit/in der Zukunft zurecht kommen wird oder nicht. Als Analogie sehe ich unsere ältere Gesellschaft, die nicht mit Smartphone / WEB / Comutern umgehen kann.

Wir kennen sie alle, spätestens im Weihnachtsurlaub und bei Besuch. ("Kannst Du mal eben"). Ist das ein Argument gegen den flächendeckenden Einsatz der Technik?

IMHO nein, sondern eine Warnung an alle (noch fitten) sich der Technologie zu verweigern. Wer zukünftig die "Katalysatoren" KI-Tools nicht wenigstens bedienen kann, wird entweder (einfach mangels Zeit) in seiner Nische stecken bleiben ("kein" Entwickler schreibt heute mehr in Assambler, früher ALLE) oder bestimmte Technologien einfach nicht mehr Nutzen.

Klar ist es schön wenn einem das Gerät solche Kopfarbeit abnimmt und es möglichst alles von allein funktioniert. Puuh was wird die Welt aber schlimm werden wenn da niemand mehr die grundsätzliche Mechanik unter der Haube verstanden hat.

Ja. Aber was Du in dem Satz gerade aussagst sind die beiden Extreme, die es zu vermeiden gilt und beide fatal sind. Natürlich muss man Konzepte verstehen und sauber arbeiten und sollte auch Experte in mindestens einem Feld sein und solides Grundwissen in allen Feldern. Aber Klickorgien, eine Millionen mal copy 'n paste, Prüfungen auf Konsistenz, in der Lage sein, eine Featureerweiterung in GO und RUST und C und Python und BASH und... ausführen zu können, entscheidet über fail oder survive.

Am Ende ist trotz KI usw. Die Verdummung der Masse der Gesellschaft vorprogrammiert. Klar wird es vorerst immer noch Experten benötigen die das zu gestalten wissen aber auch hier wird es sich in der Menge konzentrieren.

Yep, sehe ich genau so. Wir sind auf dem Weg zu Idiocracy

Und ja KI richtig zu nutzen für Programmierung usw. Muss man sich erstmal lernen.

Yep, man muss.

Aber wenn man nicht den Anspruch hat die verschiedenen Programmiersprachen direkt zu lernen macht das sogar Freude und bringt schnelle positive Erfolgserlebnisse.

Wer kann Experte in allen Sprachen sein? Ich will aber in der Lage sein, in allen Systemen (deshalb die Forderungen nach API/Webservices/SourceCode) Änderungen und Erweiterungen durchführen zu können. Und genau diesen Durchbruch schaffen wir mit KI-Systemen, ....dramaturgische Pause .... "übermorgen". ). Die Lage, an die wir gewöhnt sind und die uns normal vorkommt, dass wir auf Featurelösungen in Software warten müssen oder sie nicht bekommen, wird es nicht mehr geben. (.... übermorgen ....)

Niemand von uns ist Regisseur oder Schauspieler oder unterhält ein Filmstudio. Dennoch wird "jeder" (....morgen....) in der Lage sein, jeden Film, den er abends sehen möchte "on the fly" zu kreieren. Ein Film, den es vorher nicht gab und den es ein zweites mal nicht geben wird (wenn man ihn nicht aufzeichnet).

Das ist der Technologiesprung, der die Welt (für unsere Generation) umkrempeln wird. Ob es zum Besseren sein wird, dass darf die Generation von morgen beantworten

Können oder werden wir es aufhalten? ich denke nein.
Sollten wir es versuchen? Ich will mich mal zurückhalten (Rokos Basilisk)
Aber ich habe eine Höllenangst vor der Technologischen Singularität

Franky

EDIT @StefanW sorry das ist ein bisschen off topic (oder auch nicht? )

[blaubaerli]

Hallo zusammen,

für mich sind die Punkte 2 und 4 aus dem Eingangspost die relevantesten Punkt.

Der Rest zielt ja eher nicht in Richtung der Bestandskunden und mag daher dort natürlich von extremer Relevanz sein. Dadurch das die KNXA den Warnhinweis da in der ETS 6 eingebaut hat, ist das sich keine tolle Werbeaussage.

Für mich als Bestandskunden ist halt wichtig, dass ein potentieller Austausch der Applikation gegen eine zertifizierte und mit zusätzlichen DPTs angereicherte Version möglichst simpel von der Hand geht.

Beste Grüße
Jens

[Franky]

Hi,

Für mich als Bestandskunden ist halt wichtig, dass ein potentieller Austausch der Applikation gegen eine zertifizierte und mit zusätzlichen DPTs angereicherte Version möglichst simpel von der Hand geht.

auch unter den "Kosten" verzögerter oder nicht erfolgender neuer Features? (Da das Geld für "simpel" investiert wird)?

Nicht sarkastisch gemeint, das ist eine Grundsatzentscheidung und ich bin mir nicht sicher, was die richtige Entscheidung ist, insbesondere falls der Fokus auf Neukunden steht. Mit Export/Import-Schnittstellen kann (wenn es dem Kunden wichtig ist) der Migrationspfad (Schreiben eines Konverters) erstmal nach außen verlagert werden. Wenn Features MICH betreffen, würde ich den Konverter schreiben und der Community (kostenfrei) zur Verfügung stellen.

Gruß

Franky

[blaubaerli]

Hallo Franky,

nach der neuen Applikation ist vor der neuen Applikation. Da Stefan ja ggf. schon auf eine Mehrschrittigkeit der einzelnen Punkte verwiesen hat, wird das Thema wohl künftig "ab und an" mal anstehen.

Ob das mit der Unterstützung beim Wechsel dann aktuell einen Entwicklungsaufwand bei ElabNET bedeutet, kann ich gar nicht beurteilen. Du?
Ggf. ist das ja mit dem existierenden Export einem Import und einer passenden Doku schon erledigt.

Von daher ging es mir "nur" um das inhaltliche Thema der "Applikationsmigration". Je mehr Kunden der TWS bekommt, wird schließlich auch der potentielle Kreis derer die sich ggf. mal mit einem Applikationswechsel beschäftigen müssen größer.

Wobei hier die Henne/Ei-Frage schon eindeutig beantwortet ist.

Beste Grüße
Jens

[StefanW]

Hallo,

bevor Befürchtungen wegen Gedankenspielen von Göran & Franky aufkommen:

Die jetzt in Entwicklung befindliche neue - bald auch registrierte und zertifizierte - ETS Applikation wird relativ einfach ausgetauscht werden können.

Dies ist auch nichts neues, die "Nutzer der ersten Stunde" kennen das schon, weil wir die APP vor mehreren Jahren schonmal ausgetaucht haben. Dafür gibt es den Stack-Einstellungen-Export im TWS und den Timberwolf Importer, sollten es nicht die Boardmittel der ETS alleine schaffen. Lediglich die Einstellungen für eine Handvoll Parameter (Lebensbit, Zeitserver usw.) waran damals von Hand zu machen, was echt kein Umstand ist.



Grundsätzliche Gedanken zum Thema "neue Features" vs. "Rückwärtskompatibilität"

auch unter den "Kosten" verzögerter oder nicht erfolgender neuer Features? (Da das Geld für "simpel" investiert wird)?

Die Frage, bricht man mit altem für Innovationen ist bei komplexeren technischen Systemen eine Entscheidung, die zu den sog. technischen Schulden zählt bzw. hohe Kosten verursachen kann. Wir kennen das alle, aus VHS wurde die DVD und aus dieser die Blu-Ray. Von VHS zu DVD war es ein harter Bruch. Ein Blu-Ray-Player konnte aber auch eine DVD abspielen, weil mechanisch der Datenträger das gleiche Format hatte.

Bei KNX entscheidet sich die KNXA fortgesetzt für eine immerwährende Kompatibilität. Auch ein Tastsensor von 1998 kann mit dem neuesten Secure Tasatsensor in einem Projekt programmiert werden (alte USB- und IP-Schnittstellen sowie Linienkoppler wären aber auszutauschen, falls die damals noch keine Extended Frames konnten). Viele der steinalten KNX Geräte würden heute keine Zertifizierung schaffen, weil technisch damals anders ausgeführt. Die ETS muss das alles berücksichtigen und spezielle getunte Routinen für Altgeräte laufen lassen. Das dürfte die Entwicklung hin zu innovativeren Funktionen oder einer Reprogrammierung massiv behindern. Diese Rückwärtskompatibilität ist ein Garant für Kunden, die sich für KNX entscheiden und das ist toll. Aber es kostet richtig Ressourcen das zu ermöglichen und behindert Fortschritt an anderer Stelle.

Nicht sarkastisch gemeint, das ist eine Grundsatzentscheidung und ich bin mir nicht sicher, was die richtige Entscheidung ist, insbesondere falls der Fokus auf Neukunden steht.

ElabNET hat seit der Gründung 1999 die Strategie verfolgt, dass "der wichtigste Kunde der Bestandskunde" ist. Im Ergebnis hat dies zu sehr zufriedenen Kunden und langen Partnerschaften geführt, die meisten Kunden im damaligen Beratungsgeschäft waren ein bis zwei Dekaden bei uns, also über zig Vertragslaufzeiten hinweg. Das hat den Vorteil, dass es Vertriebskosten reduziert, weil man nicht vorne ständig neue Kunden gewinnen muss, die man hinten durch Unzufriedenheit verliert.

Auch Timberwolf Server ist auf eine lebenslange Partnerschaft mit den Kunden zugeschnitten, um laufend Wünsche zu berücksichtigen und Neuerungen ausrollen zu können. Deshalb sind die Server auch so leistungsfähig ausgelegt (im Rahmen der technischen Möglichkeiten), damit neue Software auch viele viele Jahre später noch ausreichend Ressoucen zur Verfügung hat.

Dementsprechend berücksichtigen wir die Wünsche der Bestandskunden in hohem Maße. Deshalb gibt es dieses Forum, deshalb sind wir dermaßen Transparent und deshalb achten wir auch darauf, dass bestehende Konfigurationen nicht gebrochen werden. Darum unterstützt Backup & Restore ebenfalls das Umsetzen von Daten und Konfiguration von fast allen alten Servermodellen auf das neueste (was über mehrere CPU Architekturen und unterschiedlichen Adressierungen der Interfaces gar nicht einfach zu realisieren war).

Da werden wir jetzt nicht anfangen und eine neue KNX Applikation herausbringen, für die es keinen einfachen Migrationsweg geben würde. Also bitte keine Sorge.


Beispiel:
Diejenigen die bei der Timberwolf VISU von Anfang an dabei waren, werden das kennen. Es wurden, gerade für Insider, knapp ein Dutzend neuer Versionen ausgerollt, bei dem bestehende Widgets - zum Teil drastisch - erweiterte Funktionen bekommen haben, ohne dass man dazu "das alte" Widget löschen musste, sondern man konnte in den meisten Fällen diese neuen Funktionen einfach magisch zu einem "alten" Widget dazu konfigurieren. Technisch ist das tatsächlich ein beträchtlicher "Handstand", aka, es ist gar nicht einfach und kostete ca. 1/4 des Aufwandes für den Editor alleine dafür, dass er alte zu neuen Konfigurationen automatisch "on the Fly" konvertieren kann.

Diese Automatik gilt auch bei allen anderen Subsystemen. Es musste noch nie ein Kunden irgendwie "von Vorne" anfangen mit dem Server, selbst die DEV-Tester nicht.

Das wird nicht überall so gehandhabt. Im KNXUF kann man bzgl. eines Gerätes eines anderen Herstellers lesen, dass Nutzer dort Bedenken haben, ein Upgrade durchzuführen, weil sie Angst vor den Folgen für Konfig und Funktion des Gerätes haben.

Beim TImberwolf Server musste noch nie ein Nutzer Befürchtungen haben. Einfach Update drücken und fertig, den Rest erledigt das System automatisch. Dieser immense Vorteil und Komfortgewinn ist das, was ElabNET und den Timberwolf Server ausmacht. Leider ist das nur wenig bekannt, bzw. berücksichtigen viele solche strategisch immens wichtigen Merkmale nicht bei der Kaufentscheidung (sagt ihnen auch keiner....).

Daher, bitte keine Sorge, dass eine neue KNX Applikation was brechen würde (von einigen Parametern womöglich abgesehen).

lg

Stefan