[Frage] [V4.5 IP1] ETS 6.3 - TWS wird als unregistriertes Gerät angezeigt

[MuckiLegden]

Moin,

Hatte mich bei der KNX beschwert, dass sie diese Änderung in den release-notes nicht angekündigt hatten und damit meines Erachtens mutwillig die Funktion der Software (in Zusammenhang mit bestimmten Geräten) kompromittiert haben.

Ich sehe es ehrlicherweise eher umgekehrt. Die ETS versucht einen lange gültigen und grundsätzlich sinnvollen Standard durchzusetzen. Genau wegen diesem Standard sind schließlich so viele Geräte kompatibel untereinander. Warum man dies in Release-Notes ankündigen muss, fällt mir eigentlich nicht ein. Zumal, dann hätte man ja alle möglichen nicht (vollständig) zertifizierten Geräte erst testen müssen um ihre „Probleme“ festzustellen.
Das ist wohl eher Aufgabe des Anbieters…

Ich sehe ein, das ein solcher Schritt den Mitgliedern wohl schon länger mitgeteilt sein sollte, damit Zeit zur Vorbereitung bleibt. Ob das passiert ist, kann ich nicht beurteilen…
In meinem privaten Projekt finden sich bestimmt 10 Geräte, die nicht zertifiziert sind. Darunter ein namhafter Hersteller, der bestimmt 20 Jahre lang keine Applikation veröffentlicht hat. Seit relativ kurzer Zeit sind die Applikationen aber im Onlinekatalog vorhanden. Evtl. gab es also hier entsprechende Hinweise???
Weiterhin ist das Ganze ja zumindest derzeit kein Problem, da man ja jederzeit zurück kann auf die ETS 6.2.2.

Viele Grüße,
Mucki

[Musikus]

Moin,

Ich sehe es ehrlicherweise eher umgekehrt. Die ETS versucht einen lange gültigen und grundsätzlich sinnvollen Standard durchzusetzen.

Ich bin gutgläubig und erst mal davon ausgegangen, dass der TWS den KNX-Standard einhält, wenn auch ohne den offiziellen Zertifikat-Stempel. Keine Ahnung, ob ich damit recht liege.
Ich bin mir aber auch sicher, dass die KNX den Schritt bewusst und ohne zwingende Notwendigkeit gegangen ist, derartige unzertifizierte Geräte nun von einer sinnvollen Benutzung auszusperren, um die Zertifizierung zu erzwingen.
Und mir als Nutzer ist es an sich egal, ob im Vorfeld ein Hinweis an die Hersteller der Geräte gegangen ist. Ich wurde nicht informiert, als ich das Update installiert habe und bei der KNX bin ich als ETS-Nutzer erst mal der Kunde.

Schönen Abend!
Andreas

[Sunshinemaker]

bei der KNX bin ich als ETS-Nutzer erst mal der Kunde.

Kunde einer Software die nur für Lizenzierte Geräte zugelassen ist. Nur weil es bisher Funktioniert hat, bedeutet das nicht das die KNXA dafür verantwortlich ist, wenn Unlizenzierte Produkte nicht mehr funktionieren.

Geh doch mal zum TÜV und versuche den zu erklären das deine Felgen auf der GANZEN Welt (außer Deutschland) auf deinem Auto gefahren werden und es NIRGENDWO Probleme gibt. Dann sagt der TÜV "Ja du hast Recht, aber wo ist/sind die ABE/Gutachten/was auch immer???" Keine passenden Papiere keine Eintragung. Fertig

Die Diskussion ist genauso Sinnlos.....

Die ETS ist eben nur für Lizensierte Produkte, war sie schon immer (auch wenn andere Funktioniert haben). Der TWS ist nicht Lizensiert, war er noch nie. Finde ich das in Summe Sch... (auch das mit dem TÜV), JA. Wird sich deswegen was ändern? Nein.

Ich bin mir sicher, wenn du nur lange genug bei der KNXA jammerst, wird sich auch nichts ändern.....

[devilchris]

Hallo,

@StefanW hatte hier geschrieben:

Wir sind an einer Ausweitung der Applikation wegen Hinzunahme weiterer unterstützter DPT schon länger wieder am Thema und eigentlich war das für die V 5 vorgesehen.
Wir sind mit den Zertifizierungslabors um Kontakt, welche Termine wir bekommen und wissen erst nach Auswertung der Rückmeldungen, bis wann wir das Problem beheben können. Wir sind im Moment hier von Dritten abhängig.

Damit gehe ich davon aus das da in absehbarer Zeit etwas passieren wird.
Ist halt schade das die KNXA das noch zum Jahresende rausgegeben hat.
Die ETS V5.7 wird noch eine weile bei mir laufen.

[gbglace]

Ob nun Jahresende oder zu Ostern oder in den Sommerferien, ist doch komplett egal. Die ETS setzte jetzt halt das durch was in den Lizenzbestimmungen bisher nur in Worten gekleidet war.

Mit der 6.3 geht auch bei der ETS Home jetzt nur noch ein Projekt, was auch schon seit Jahren so in den Lizenzbestimmungen der ETS-Home steht. Bisher konnte die ETS nur Geräte zählen und diese Art der Lizenzbegrenzungen technisch umsetzen.

Jetzt geht das gejammert los, ohh ein Projekt ist aber zu wenig, wenn ich da nicht ein Test haben will oder wegen unlizenzierter Geräte man ein 1-Geräte Projekt wie den TWS geöffnet hat und dann das Haus Projekt daneben und dann die Applikation darüber kopiert. Funktioniert jetzt halt nicht mehr mit der ETS-Home, durfte man aber eben schon seit Erscheinen der Home-Variante nicht.

Ich wüsste da jetzt auch nicht warum man da als KNXA alle User der ETS Home nun aktiv informieren hätte müssen, dass das was bisher schon nicht sein durfte nun auch einfach technisch nicht mehr geht?

Es war mit der TWS Applikation in dem Sinn eine tickende Zeitbombe, den Timer hat man halt nicht gesehen und nun hat's bumm gemacht. Da die Rezertifizierung eben kein kostenloser Service ist, gab es daher immer ein Abwegen bei Elabnet das zu fixen oder eben nicht.

[devilchris]

@gbglace was´n los?

Ich habe nur kurz darauf hingewiesen das ElabNet dran ist dies Problem zu lösen.

[gbglace]

War nur der erste Satz, der sich mit Deiner Antwort auseinandersetzte.

Eher die allgemeine Aufregung etwas oben drüber das die KNXA da was tut was sie so nicht tun sollen dürfte führte zu dem Beitrag. Weil das Mimimi zu diesem ETS Update ist Recht verbreitet.

Die 6.2.2 war jetzt nicht so Buggy, bis auf den Überlauf bei Secure Geräten, was aber noch eine grundsätzlichere Lösung Bedarf.

Insofern hat die allgemeine Erfahrung gezeigt, Update Vorschläge der ETS besser erstmal ignorieren und ein paar Tage den Nachrichten zum Update im KNX-UF folgen.

Hier ergab sich dann für mich direkt das Bild >>> kein Update als TWS Nutzer.

Aber ja mittlerweile lässt sich ein solcher "Fehler" auch durch downgrade auf die 6.2.2. wieder beheben.

[cozmoz]

Mit der 6.3 geht auch bei der ETS Home jetzt nur noch ein Projekt, was auch schon seit Jahren so in den Lizenzbestimmungen der ETS-Home steht. Bisher konnte die ETS nur Geräte zählen und diese Art der Lizenzbegrenzungen technisch umsetzen.

Jetzt geht das gejammert los, ohh ein Projekt ist aber zu wenig, wenn ich da nicht ein Test haben will oder wegen unlizenzierter Geräte man ein 1-Geräte Projekt wie den TWS geöffnet hat und dann das Haus Projekt daneben und dann die Applikation darüber kopiert. Funktioniert jetzt halt nicht mehr mit der ETS-Home, durfte man aber eben schon seit Erscheinen der Home-Variante nicht.

Ich hab auch die 6.3.0 kurz benutzt. Finde Sie angenehmer zum Arbeiten und die visuellen Änderungen sind gut gelungen.
Ich verstehe nicht genau was du meinst, bei mir geht mit der ETS 6.3.0 noch das gleichzeite Öffnen von 2 Projekten, finde die Limiteriung auch selten dämlich, da ich ab und zu Sachen ganz gerne in einem eigenen Projekt ausprobiere ohne im Produktivprojekt erstmal ändern vornehmen zu müssen.

Dank TWS bleibt einem ja eh nur die 6.2.2.

[StefanW]

Hallo zusammen,

ich hatte zuletzt geschrieben, dass ich "keine schmutzige Wäsche" waschen will. Weil ich will das Problem lösen, nicht die Schuldfrage.

Ich hätte mir gewünscht, dass man sich anschließend mit Vermutungen darüber, wer wann was gemacht oder nicht gemacht hat, zurück hält und uns die Zeit gibt, das Problem zu lösen, zumal man mit der ETS 6.2.2. wirklich wunderbar arbeiten kann, anstatt mir nun aufzuzwingen, dass ich mich extra hinsetzen muss, um Euch Kontext zu geben, damit Ihr in Eurer Diskussion zu "wer hat Schuld" mit mehr Informationen ausgestattet seid und das auch richtig einordnen könnt. Allerdings stehen wir danach immer noch mit dem selben Problem dar.


Geschichte KNX Stack Entwicklung Timberwolf Server

Anfänge mit dem eibd.

Als wir in 2008 am WireGate Server gearbeitet hatten, brauchte es einen KNX Stack. Wir hatten hierzu Kontakt mit Stack-Herstellern aufgenommen und ein KNX Stack für Linux und dann auch noch in "free" war nicht darstellbar.

Makki entdeckte dann die Facharbeit von Herrn Kogler von der Uni Wien, der einen rudimentären KNX Stack (nicht aus der ETS programmierbaren) unter der Bezeichnung eibd entwickelt hatte. Makki hat diesen dann für das WireGate verwendet, musste diesen aber umfangreich entflöhen, da "nicht ready for prime time".

Über die Jahre hatten wir immer wieder Fehler in diesem KNX Stack gefunden, behoben und die Verbesserungen an die Community zurückgegeben.

Darauf basierte dann auch der Fork knxd, in dem auch eine Menge unserer Arbeit dort enthalten.


KNX Stack Suche für Timberwolf Server

Ab 2015 hatten wir uns entschieden, für den WireGate Server einen Nachfolger zu entwickeln, der heute Timberwolf Server heißt.

Den eibd wollten wir nicht verwenden, weil bei diesem die Liste bekannter Fehlern immer länger wurde und auch, weil der eibd / knxd nicht aus der ETS programmierbar ist. Letzteres, also die Programmierbarkeit aus der ETS ist übrigens der Hauptaufwand bei der Implementierung eines KNX Stacks.

Es gibt nur zwei Anbieter auf dem Markt, die solche Stacks anbieten und hier hatten wir keine brauchbaren Angebote bekommen. Ein Anbieter wollte "mit Linux" nichts zu tun haben und der andere war immer ein wenig unverbindlich geblieben, so dass wir kein gutes Gefühl entwickeln konnten. Probleme waren unter anderen die Lizenzvorstellungen, dass für jedes neue Modell des Timberwolf Servers jeweils eine neue Lizenz zu beziehen wäre.

Wir kamen dann in Kontakt mit einem freien Entwickler für KNX, der seitdem externer Mitarbeiter unseres Hauses ist.


Das Problem mit den Universalobjekten

Für den Timberwolf Server wollten wir nach Möglichkeit keine technische Einengung der Nutzer.

Ein üblicher KNX Stack ist hinsichtlich seiner Liste der KNX Objekte üblicherweise voreingestellt hinsichtlich Anzahl und Datenpunkttypen. Also eher unveränderlich, weil auch abgestimmt auf das KNX Gerät. Ein Lichtsensor hat die passenden Objekte und ein Windmesser eben diejenigen, die zu diesem Sensortyp passen. Wir wollten für den Timberwolf Server jedoch universell nutzbare KNX Objekte, weil wir den Kunden nicht einschränken wollten auf 100 Stück Objekte für Temperatur, und 100 für Luftfeuchte und 100 für x, y z. usw.

Hinsichtlich einer solchen universellen Einstellbarkeit hatte ich "auf Nachfrage" von einem der ETS Entwickler den Tipp bekommen, wie wir das lösen könnten und dies an unseren externen Entwickler weitergegeben.

Mit dem Wissen wurde zunächst der KNX Stack entwickelt und danach die Applikation dazu und es stellt sich erst hier heraus, dass wir mit der ETS Toolchain an eine unerwartete Grenze kommen.


Das 8000er Problem

Für die Entwicklung eines KNX Stacks gibt es verschiedene Gerätemodelle.

- In "System 7" unterstützt maximal 255 KNX-Objekte und einen - von der ETS aus beschreibbaren Speicherbereich - von 30 kB. Die meisten KNX Geräte sind in diesem "System 7" ausgeführt, da 255 Objekte meistens ausreichend sind und einfache Mikroprozessoren verwendet werden können.

- Das Gerätemodell "System B" hat fast keine Limits. Es erlaubt nicht nur das erweiterte Format von 65.000 KNX Objekte, sondern dieses Gerätemodell kann auch auf den Medien RF und IP implementiert werden.

Wir haben uns entschlossen, die Möglichkeiten dieses System B nur zu einem Teil zu nutzen, nämlich für 8.000 freie Objekte und ein paar Systemobjekte.

Auf Probleme war unser ext. Entwickler dann gestoßen, als er versuchte, die ETS Applikation mit dem Manufacturer Tool ("MT") zu erzeugen. Eine ETS Applikation ist eigentlich nur eine einfach Datenstruktur (ich glaube, xml). Im MT legt man die Menupunkte und Auswahlboxen an, die in der ETS angezeigt werden und legt darin fest, welche der KNX Objekte bei welcher Auswahl abgespeichert werden und welche DPT diese haben.

Dieses MT ist eine eher schlecht gemachte Software und für unser Projekt mit ein paar tausend Universalobjekten bei extrem übersichtlicher Menustruktur rechnet diese Software mehrere Tage auf einem Octacore (!). Mehrere Tage für eine übersichtliche Datenstruktur, das muss man sich mal vorstellen.

Was dann passierte war, dass bei ca. 2.400 der 8.000 Objekte (und nach mehreren Tagen Rechenzeit) die Software MT abstürzte. Das war wiederholbar.

Wir hatten dann die KNXA um Unterstützung gebeten und haben eine neuere Version des MT bekommen, mit dem es allerdings noch schlimmer war.

Zwischenzeitlich hatten wir unseren 8000er KNX Stack nebst KNXnet/IP Tunneling zertifiziert und wollten das Produkt ja ausrollen. Also haben wir entschieden, dass wir das MT erstmal nur eine Applikation für 2.000 Objekte berechnen lassen und damit rausgehen.


Das 500er / 2000er Problem

Allerdings zeigte sich, dass die ETS in den damaligen Versionen fast nicht in der Lage war, mit dieser Applikation zurechtzukommen. Beim Klick in der (damaligen) ETS auf die Timberwolf Applikation wurde die ETS Applikation mehrere Sekunden lang unresponsive.

Sarkastische Anmerkung: Es ist ja schon eine Herausforderung eine Datenstruktur von gerade mal 2k Länge und ein paar hundert Bit Breite auf einem modernen 32 oder 64 Bit PC mit mehreren GHz zu verwalten. Meine Güte.

Die damalig noch bei Kunden in Verwendung befindliche ETS 4.x konnte mit der 2.000er Applikation gar nicht betrieben werden, wir haben dann extra eine 500er Applikation für die ETS 4 gemacht.

Die KNXA hat dann das 2.000er Problem untersucht und wir bekamen auch Verständnis und Unterstützung von höchster Stelle dort, denn man war sehr am TWS interessiert. Wir bekamen dann auch eine neue Version des MT, die eine andere Struktur der Applikation bauen sollte, allerdings war das Ergebnis anschließend noch schlechter.


Quo Vadis Zertifizierung?

Die Zertifizierung für ein KNX Gerät besteht aus ZWEI Zertifizierungen

1. Stack Zertifizierung für die grundsätzliche Software selbst

2. Applikations Zertifizierung für die in die ETS ladbare Applikation

Die eigentliche Stack Zertifizierung wurde damals nur von vier Labors weltweit vorgenommen. Eines ist in Peking und zwei gehören der Konkurrenz, daher sind wir zum vierten Labor, das der Firma Dial und haben hier die komplette Zertifizierung für den KNX Stack mit 8.000+ Objekten und der KNXnet/IP Tunnelung Funktionen (das sind eigentlich zwei Stack Zertifizierungen in einem) durchgeführt gehabt,

Die Applikations Zertifizierung ist eher eine "Kleinigkeit" und darf von ca. 30 Labors weltweit durchgeführt werden. Hier wird nur noch getestet, ob das KNX Gerät auch zu den in der Applikation freigeschalteten Objekten passt und prinzipiell tut was es soll. Es werden aber nicht alle Iterationen an Einstellungen getestet und ob die interne Logik des Sensors alles richtig macht. Es geht darum, dass es am KNX Bus keine Probleme gibt und ein Telegramm, das mit DPX x.y eingestellt ist, auch so kodiert wird. Ob der Temperatursensor nun richtig misst, ist nicht die Aufgabe dieser zweiten Zertifizierung.

Wir waren damals - das war 2018 - der Meinung, dass die KNXA es schaffen sollte, uns zeitnah eine Lösung für die 500er, 2.000er und das 8.000er Problem zur Verfügung stellt. Schließlich bewegen wir uns im erlaubten Bereich des Gerätemodells "System B" und es ist die Aufgabe der ETS, die vom Nutzer getroffenen EInstellungen in ein "Speicherabbild" umzurechnen und diese paar kB dann in den Stack zu laden.

Leider hat es dann bald drei Jahre gedauert, bis die ETS so an "Geschwindigkeit" aufgeholt hatte, dass ein Klicken in der Timberwolf Applikation nicht mehr dazu führte, dass die ETS total unresponsiv wurde. Richtig flüssig ist es bis heute nicht. Weder in 5.7.7 noch in 6.2.2

Wir haben vor - ich schätze - zwei Jahren erneut das Gespräch mit der KNXA gesucht, zumal dort der Manager für die ETS gewechselt hatte, der auch einmal zu uns gekommen war. Er hat uns eine neue Version des MT zur Verfügung gestellt, dankenswerterweise kostenlos, weil eigentlich kostet diese Software um die 2.000 EUR (wenn ich es recht in Erinnerung habe).

Dieses MT hatte ich - zusammen mit einer Liste neu gewünschter DPT - an unseren ext. Entwickler weitergegeben mit der Bitte zu testen, ob nun - erstens - für unseren 8.000er Stack auch eine passende Applikation erzeugt werden und - zweitens - diese dann auch in der ETS verwendbar ist.

An dieser Stelle hakt es nun bei uns. Genauer: Der externe KNX Entwickler hat den Auftrag bislang nicht umgesetzt, trotz gegenteiligem Avis. Ich habe mehrmals nachgehakt und habe dann auch eine Tagesreise für einen Besuch unternommen, um zu klären was denn nun Sache ist. Ich kann hier nicht ins Detail gehen, weil das sehr persönlich ist. Es gibt im Leben manchmal Probleme, die lassen sich weder vorhersehen, noch in Auswirkung und Dauer abschätzen. Mir wurde stets versichert, dass es sehr bald losgehen wird mit unseren Themen damit und wir bald ein Ergebnis haben. Rückblickend betrachtet stellt sich die Sache jetzt anders dar, als damals, als Ausblick in die Zukunft.

Wir warten ja schon lange nicht nur auf die neue Applikation mit mehr Objekten, sondern auch auf die Erweiterung um neue DPT und es gibt auch im IP-Bereich zwei kleine Fehler, die eine Handvoll Kunden betreffen. Hier ist nun leider lange nichts vorwärts gegangen, letztlich wegen der Auswirkungen eines klassischen Schlüsselpersonenrisikos. Ich will das nicht verharmlosen, aber solches gibt es in technischen Projekten immer mal wieder, dass man von einem Spezialisten abhängig ist, was durchaus Auswirkungen haben kann und sich dem Management ein wenig entzieht.


Wer hat nun Schuld?

Für diejenigen, die gerne die Schuldfrage geklärt haben wollen:

1. Zuallererst ist es die Schuld von ElabNET. Wir hätten bei der Auslegung des Timberwolf Servers vorab prüfen müssen, ob der angedachte KNX Stack überhaupt so realisierbar ist unter Einbeziehung aller Limitationen, die externe Tools (MT und ETS) so haben können. Wie wir heute wissen, hat das in diesen Details allerdings auch niemand vorher gewusst, weil wir mit den vielen Universalobjekten "Neuland" betreten haben. War trotzdem unsere Entscheidung, etwas zu planen, das es bislang nicht gab.

2. Die KNX Association als der "Herr über Regeln, Tools und Zertifizierung" sollte keine Regelwerke (hier Gerätemodell System B) veröffentlichen, wenn die Toolchain aus MT und ETS bei Nutzung der Möglichkeiten gar nicht die Applikation "kompilieren" und nutzen kann, um das für die Programmierung nötige Speicherabbild eines nur zu einem Achtel ausgenutzten Umfanges an KNX Objekten zu berechnen. Wir reden hier von einer Datenstruktur von 8k Länge bei (geschätzt) 32 Bit (eigentlich muss zu jedem Objekt ein DPT und ein paar Flags via Speicherabbild programmiert werden) die von der ETS zu erzeugen und in den Stack des TWS zu schreiben wären, geschätzt sind das maximal um die 32 kByte.

Man muss der Mannschaft um die ETS zugute halten, dass die ETS extrem komplex ist, weil auch der erste eib-Taster aus dem letzten Jahrtausend (der heute keine KNX Zertifizierung überstehen würde) sich auch heute noch programmieren lassen sollte in einer Anlage, die auch den neusten Aktor enthält, letztlich alles aus einer Bandbreite von 10.000 Geräten über 30 Jahre. Und das über etwa ein Dutzend verschiedener Protokolle. Das ist gar nicht einfach und bei dem Budget auch schwierig, weil eigentlich ist die Software recht günstig (auch wenn jetzt alle aufschreien, aber der Markt ist klein und hinsichtlich für die gesamte Komplexität und den Supportumfang ist das von der KNXA und den beiden an der ETS arbeitenden Herstellern geleistete enorm).

Wir haben mit den Universalobjekten etwas gemacht, was zwar erlaubt ist, aber bislang nicht genutzt wurde und daher war diese Nutzung in der ETS eben nicht gut gerüstet. Als kleiner Hersteller können wir hier auch nicht den größten Druck machen.

3. Unser externer Entwickler hat mir immer wieder versichert, dass er demnächst die Dinge angeht. Das hatte bislang prächtig geklappt und der Mann ist uns sehr gewogen und wir haben eine sehr positive und angenehme und auch fruchtbare Zusammenarbeit. Die Qualität der Software ist hervorragend. Die Größenordnung seiner persönlichen Themen und die Dauer waren auch ihm nicht bekannt und manches stellte sich auch erst vor kurzem heraus, was auch für ihn in der Rückbetrachtung einiges besser erklären lässt. Wie gesagt, das ist persönlich und ich habe hier schon zuviel gesagt. Womöglich hätte ich hier früher nach einer Alternative suchen können, sieht man im Nachhinein immer anders, wäre aber eine sehr große Herausforderung geworden. Ich hatte hier eben auf die Zusagen vertraut, zumal die Zusammenarbeit immer gut war und ich nicht der Typ bin, der bei jedem Problem gleich die Pferde neu sattelt, weil es auch Anstand und Vertrauen geben muss.


Wir ihr seht, ist das mit den 8.000 KNX Objekten ein Stück einfach "dumm gelaufen". Wir haben eine technische Ausführung des KNX Stacks designed, die Euch alle Vorteile einer ordentlichen und - über die Universalobjekte - praktisch unlimitierten Lösung bietet, aber hierüber übersehen, dass wir hier der Schneepflug sind für diese Technologie der Universalobjekte und die Steine drum herum viel viel langsamer malen, als wir das vermutet hatten. Sicher hätten wir uns hier mehr anstrengen können, das wir das anders oder mit mehr Nachdruck schneller auf andere Beine stellen, zumindest die letzten beiden Jahre betreffend, was direkt so auch heute erst klar ist.


Lösung?

Unser externer Entwickler hat versprochen, sich umgehend daran zu setzen, die vor zwei Jahren übergebene MT zu testen, um zu sehen, ob das jetzt überhaupt klappt mit den 8.000 Objekten. Falls nicht, wollen wir wenigstens eine 2.000er mit den neuen DPT machen und arbeiten währenddessen im Hintergrund mit der KNXA daran, wie wir dann vorgehen sollen, falls wir die 8.000er erneut nicht unterstützt bekommen sollten und wer dann die Kosten einer Zwischen-Zertifizierung der 2.000er trägt, die ja nun notwendig wird, wenn die die 8.000er erneut nicht funktioniert. Wobei man uns vorhalten könnte, dass wir mit dem neuen MT hätten früher testen können und die KNXA dann darauf hätte reagieren können.

Wir versuchen das Problem zu lösen, aber es hängt nicht so direkt bei uns selbst, wir sind jedoch dafür verantwortlich.

Ich entschuldige mich für die Unannehmlichkeiten und meine falschen Entscheidungen der letzten Jahre diesbezüglich.

lg

Stefan

[gbglace]

Hi Stefan.
Wenn es mit dem MT absolut nicht klappen sollte, melde Dich mal. Applikationen mit Universalobjekten in vierstelliger Anzahl geht auch ohne MT und ohne das die ETS da ins Stocken gerät. Ich vermute eher, dass das was das MT da an XML produziert schlimmstes Copy/Paste ist und nicht alle möglichen Strukturoptimierungen berücksichtigt.

Universalobjekte findet man zwar häufiger in diversen Applikationen aber das endet da auch meist bei niedrigen dreistelligen Anzahl KO, bei eher bis zu drei möglichen Datentypen die dann an einem KO je gesetzter Parameter wirksam werden.

Insofern ja die 8000 KO mit freie DPT Auswahl sind sicher eine Herausforderung aber es sollte möglich sein.



Die Verbesserungen der ETS 6.3 im Workflow und der Darstellung sind nur Reparaturen dessen was man beim Umstieg von ETS5 auf 6 kaputt bzw. verschlimmbessert hatte. Und auch da fehlen immernoch Funktionen die früher schonmal funktionierten und einem das Leben leichter machten. Der Start der ETS6 war technisch inhaltlicher eine stabilere Software als der Start der ETS5 aber im UI war und ist der Start der ETS6 eher der schlimmste Releasewechsel den die KNXA da hingelegt hat bisher.