UPGRADE IP 9 verfügbar!
Timberwolf VISU jetzt mit NEUEM Layout Editor
Freie Anordnung, Reihenfolge und Größe der Widgets - viele weitere Verbesserungen
Infos im Wiki: https://elabnet.atlassian.net/l/cp/06SeuHRJ

NEU! Insider & Leistungsmerkmale FÜR ALLE freigeschaltet
Damit kann nun jeder das Upgrade vornehmen und VISU & IFTTT testen. Alle Info hier: viewtopic.php?f=8&t=5074

[Implemented] ETS und Timberwolf - ab ETS 5.7.3 endlich flüssiger

Neue Produkte, Rollouts, Änderungen, Aktionen
Forumsregeln
  • Bitte daran denken, dass für technische Probleme mit der Firmware, die NICHT die Installation selbst betreffen, jeweils ein separater Thread zu eröffnen ist. Bei Insider Versionen dann im entsprechenden Insider-Unterforum
  • Denke bitte an aussagekräftige Titel und gebe dort auch die [Firmware] an. Wenn ETS oder CometVisu beteiligt sind, dann auch deren Version
  • Bitte mache vollständige Angaben zu Deinem Server, dessen ID und dem Online-Status in Deiner Signatur. Hilfreich ist oft auch die Beschreibung der angeschlossener Hardware sowie die verwendeten Protokolle
  • Beschreibe Dein Projekt und Dein Problem bitte vollständig. Achte bitte darauf, dass auf Screenshots die Statusleiste sichtbar ist
  • Bitte sei stets freundlich und wohlwollend, bleibe beim Thema und unterschreibe mit deinem Vornamen. Bitte lese alle Regeln, die Du hier findest: https://wiki.timberwolf.io/Forenregeln

StefanW
Elaborated Networks
Reactions:
Beiträge: 9689
Registriert: So Aug 12, 2018 9:27 am
Wohnort: Frauenneuharting
Hat sich bedankt: 4831 Mal
Danksagung erhalten: 7632 Mal
Kontaktdaten:

#41

Beitrag von StefanW »

Liebe Foristen und Kunden,

ich wollte Euch einen aktuellen "Zustandsbericht" zum Thema TWS Applikation & ETS geben:

Sachstand zur Timberwolf Server ETS Applikation

Der KNX Stack des Timberwolf Servers ist bereits zertifiziert, die Applikation aber noch nicht. Der Grund liegt darin, dass die KNX Association seit bald einundeinhalb Jahren nicht in der Lage ist, eine Toolchain zu liefern, mit der wir eine Applikation schreiben können, die es erlaubt, alle Möglichkeiten unseres KNX Stacks auch ausnutzen zu können. Avisierte Verbesserungen erweisen sich als Schlag ins Wasser.

Für alle die etwas später eingestiegen sind, hier eine (kurze) Zusammenfassung um was es hier nun eigentlich geht:


Aufgabenstellung:

Bei der Entwicklung des TWS stand steht die Aufgabenstellung "Robust" und "no Limits" und "Einfach" im Vordergrund. Hinsichtlich KNX hatten wir uns damit auch etwas vorgenommen:
  1. Der TWS muss KNX zertifiziert sein! Keiner der vielen Smarthome Server auf dem Markt ist KNX zertifiziert. Damit entgehen dem Kunden viele Möglichkeiten für eine komplette Integration in KNX-Projekte. Zum einen hat man ein unvollständiges ETS-Projekt, denn der Server ist nicht als Gerät mit aufgeführt. Dies hat dann auch ungünstige Auswirkungen auf das Berechnen der Filterlisten von Linien- und Bereichskopplern. Zudem kann die Macht der Flags nicht genutzt werden. Mit anderen Worten: Es ist eigentlich ein Unding wenn in einem KNX-Projekt ein wichtiger Server enthalten ist, der weder zertifiziert noch Bestandteil des ETS Projektes ist. Darum haben wir uns die Mühe auferlegt, einen zertifizierten KNX Stack für den Timberwolf Server zu entwickeln.
  2. 8.000 Objekte! Gemäß unserem Wunsch nach "No Limtis" wollen wir den Kunden auch etwas bieten. Also sollten 8000 Objekte möglich sein. Das macht einen KNX Stack nach dem Gerätemodell "System B" erforderlich.
  3. 64.000 Assoziationen (GA)! Diese 8000 Objekte lassen sich jeweils mit bis zu 16 GAs verknüpfen, insgesamt unterstützt unser Stack 64.000 solcher Assoziationen
  4. 32 / 64 BitUnser Stack unterstützt 32 und 64 Bit Prozessorarchitekturen.
  5. DPT der Objekte in der ETS wählbarDie 8.000 Objekt sind Universalobjekte. Diese können beliebig genutzt werden. Damit das funktioniert, kann in unserer Applikation der DPT festgelegt und mit programmiert werden.
  6. Mehrere Stacks parallel!Prinzipiell kann unser Stack in mehreren Instanzen gestartet werden - jeweils einer pro Interface - womit eine Ausweitung leicht möglich ist. D.h. die 8000 Objekte sind nicht die Grenze. Mit dem mehrfachen Loggen geht das jetzt schon.
Klingt alles ganz einfach. Trotzdem belegen wir damit ein paar Weltrekorde. Denn unser KNX Stack ist damit der weltweit leistungsfähigste KNX-Stack auf den Markt. Insbesondere bei der Anzahl der Objekte und Assoziationen, aber auch der einzige für 64 Bit und der einzige, bei dem sich die DPT bei Universalobjekten in der ETS anlegen lassen.


Die KNX Toolchain:

Wir haben nicht nur Neuland betreten, sondern sind damit an die Grenzen der ETS Toolchain geraten.
  • Manufacturer Tool: Das Manufacturer Tool, kurz "MT", ist das Gegenstück zur ETS. Hiermit legt der Hersteller die Applikation an.
  • Engineering Tool Software: Die "ETS" ist die von den Kunden / Anwendern genutzte Software, um die Einstellungen zu tätigen und diese zu "programmieren".
Wir sind also darauf angewiesen, dass wir die Applikation mit dem MT ausführen können.


Die Probleme mit der KNX Toolchain:

Leider stellte sich heraus, dass unsere Entwicklungsziele zwar innerhalb des KNX Standards "Modell B" lagen, aber, da es vor uns noch niemand gemacht hatte, die Toolchain der KNX Association das gar nicht vollständig unterstützte.

Das Hauptproblem: Das MT basiert auf einer älteren Version des Visual Studio und ist eine 32 Bit Applikation. Was nicht mehr in den damit adressierbaren Speicher passt, hat eben Pech gehabt.

Bei der Herstellung der Applikation für den Timberwolf Server kam es dann auch bei 2400 Objekten zum Absturz des MT, mehr ging nicht.

==> Daher haben wir die Applikation zunächst nur für 2000 Objekte herausgegeben können, weil mehr schafft das MT nicht.
==> Und weil die ETS4 / ETS Inside auch damit nicht zurecht kam, gibt es auch eine Applikation mit 500 Objekten.


Die avisierte Problemlösung: Die ETS 5.7:

Mit unseren Problemen konfrontiert bekamen wir von der KNX Association die Antwort, dass man an einem neuen Feature arbeitet, dass den Speicherplatzbedarf einer Applikation massiv reduzieren sollte. Davon sollten alle Strukturen profitieren, die irgendwie mehrmals auftreten.

Das kann ein achtfach Dimmer sein, bei dem es achtmal die selben Einstellungen gibt oder - vor allem bei uns - ein Projekt, bei dem mehrere tausendmal die gleiche Struktur vorkommt. Die Lösung dabei: Es wird nicht mehr 8fach (oder 2000 fach) das gleiche in der Datei der Applikation gespeichert (und geladen und gelesen) sondern nur noch EINMAL (mit der Info, dass es das 8 mal gibt, oder 2000 fach). Das soll den Speicherbedarf erheblich reduzieren.

Das ist nun über ein Jahr her. Diese Problemlösung sollte mit der Version 5.7 des MT und der ETS verfügbar sein.


Das Desaster mit der ETS 5.7.0. bis 5.7.2:

Leider war die ETS 5.7 ein ziemlicher Schlag ins Wasser, den für einige Projekte was es ein einziges Desaster. Mehr kann man hierzu hier nachlesen: https://knx-user-forum.de/forum/%C3%B6f ... ffentlicht

Wir haben dann auch mit dem neueren MT die Applikation neu erstellt, allerdings zeigten die Tests durch uns und auch der User dann keine wirkliche Verbesserung.

Wir waren allerdings ein wenig überrascht, dass die Kritik der Kunden so deutlich angestiegen war. Daher haben wir zwei Integratoren um einen neutralen Test gebeten. Bei diesen Tests bekamen wir als Antwort, dass die ETS ab 5.7 (bis 5.7.2) insgesamt sehr langsam und träge geworden war. Die umfangreiche TWS Applikation machte das zwar nicht besser, aber auch nicht signifikant schlechter. Die ETS selbst war erheblich langsamer geworden.

Hinweis: Dieses Thread wurde eröffnet ab Verfügbarkeit der ETS 5.7.2. Bei manchen Anwendern war der Update auf die ETS 5.7.x und die Installation der TWS App in etwa zeitgleich, daher entstand der - für uns ungute - Eindruck, dass unsere Applikation alleine Ursächlich wäre für die teils heftig gewordenen "Antwortzeiten" der ETS und unserer Applikation.


Die avisierte Problemlösung hat einen Namen: "Modulare Applikationsprogrammierung" ("MAP"):

Vor etwa einem Monat habe ich mich erneut an die Führungsetage bei der KNX Association gewendet, zumal am nächsten Tag die Chance auf ein persönliches Treffen anhand einer Veranstaltung (ZVEI) bestand.

Wie immer war die Reaktion schnell und professionell. Ich bekam sofort Antwort und am nächsten Tag wurde ich auch von allen Verantwortlichen bei der Veranstaltung aufgesucht und angesprochen. Man ist sich des Problems bewusst, aber es wäre lange schon gelöst, wir sollten eben einfach das MAP Feature benutzen und erstmal prüfen, ob wir das MAP-Feature überhaupt benutzen würden in unserer Applikation.

Wenn nicht, dann sollten wir dieses Feature aktivieren und dann würden wir einen Turbo erleben, man sei sich da ganz sicher und sehr entspannt.

Ok, dann gehen wir eben wieder zurück auf Los und ziehen nicht 4.000 DM ein. Äh Euro.

Zum ersten Mal haben wir damit den Namen für diese Entwicklung bekommen: "Modulare Applikationsprogrammierung" ("MAP").

Nachgeforscht und festgestellt, dass dies genau die schon länger avisierte Problemlösung sein sollte, also eine immer wieder vorkommende Struktur wird als Template angelegt und dieses kann dann mehrfach benutzt werden, wird aber nur einmal gespeichert. Hurra, endlich DER Wegweiser.

Damit bei unserer KNX Entwicklung aufgeschlagen. Das Stichwort MAP kannte man noch nicht, weil leider, entgegen wie man sich das vorstellt, gibt es zum MT keine umfassende Doku und auch keine Erklärungen oder Feature Listen. Dafür gibt es das MT schon in der Version 5.7.4.

Tja, in der Dokumentation fand sich nichts. Also alle Verzeichnisse durchgewühlt und im zigsten Unterverzeichnis fand sich dann ein Beispiel für MAP. Das wurde dann genutzt um darauf unsere Applikation mit MAP auszuführen.

Das war eine wesentliche Erleichterung, weil vormals hat es gut eine Woche an Rechenzeit gedauert, bis das alte MT das erste Objekt 2000 mal in sich kopiert hatte. Eine Woche!. Das brauchte es jetzt nicht mehr, weil das Template wird nur noch einmal erstellt und dann die Information dazu, wie das 2000 mal durch die ETS genutzt und dargestellt werden soll. Das Projekt ist dann auch sehr klein und dieser Teil ging recht schnell. Auch wenn es bis dahin wieder eine Woche dauerte, das alles zu testen und herauszufinden.

Der Unterschied in der Applikationsgröße ist brachial:
  • In der "alten" Programmierweise "Multi-Channel Architektur" war das Projekt über 6 MByte groß
  • In der neuen Version mit "Modulare Applikationsprogrammierung" dagegen nur noch 95 kB!
Wow, 95 kB anstatt 6 MByte, ein Unterschied um den Faktor 60, das sieht doch nach einer enormen Verbesserung aus. Der versprochene Vorteil des geringeren Speicherverbrauches hat sich also bewahrheitet. Juchu. Zumindest soweit.

Weil dann kam der große Test der neuen Applikation mit diesem sagenumwobenen Turbo MAP-Feature in der ETS:


Aus dem Desaster wird eine Katastrophe: Mit "MAP" dauert ein Klick nun Minuten:

Was für eine Ernüchterung. Da wartet man ein Jahr (oder ist es mehr), da wurde uns der Turbo versprochen und tatsächlich ist es eine Katastrophe. Die mit viel Aufwand unter Nutzung des MAP Features erstellte Applikation ist eine DOS-Attacke auf die ETS. Sobald man in der neuen Applikation irgendwo hin klickt, geht einer der Prozessorkerne auf 100 Prozent und bleibt dort für Minuten bis sich was bewegt.

Mit anderen Worten: Wir sind unserem Ziel, eine Applikation für alle 8000 Objekte zu erstellen, keinen Schritt näher. Mit dem "alten" Verfahren geht es nicht, weil das MT an seine Speichergrenzen kommt. Die Problemlösung funktioniert leider auch nicht, so dass wir hier nochmal eine Runde mit der KNX Assoc. drehen müssen.

Derzeit ist ein Ticket offen, wir haben alles hingemeldet und warten nun, dass man mit der nächsten Version der ETS auch dieses Problem lösen möchte.


Der Workaround: ETS 5.7.3 mit unserem 2000er Projekt

Der derzeitige - und absolut zufriedenstellende Workaround - ist die Nutzung der ETS 5.7.3 mit unserem bisherigen Projekt (als Applikation).

Mit der ETS 5.7.3 wurde die ETS offenbar massiv überarbeitet. Alles funktioniert so schnell (oder "normal") bei der ETS wie zuvor auch. Eine wichtige Verbesserung, an der man auch sieht, dass die Probleme mit der ETS nicht an unserer Applikation lagen, sondern bei der ETS selbst.

Auch wenn noch kein Kunden - soweit uns bekannt - an die Grenze der 2000 Objekte gestoßen ist, arbeiten wir daran, das volle Potential unseres KNX Stacks zu erreichen. Mit allen 8.000 Objekten. Und eines Tages, dies auch pro Instanz.

Wir sind also weiterhin dran. Das sind wohl offenbar die Schmerzen die man erleiden muss, wenn man den besten KNX Stack der Welt bauen will.


mg

Stefan
Zuletzt geändert von StefanW am So Dez 22, 2019 1:34 pm, insgesamt 1-mal geändert.
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de

Link zu Impressum und Datenschutzerklärung oben.

jockel
Reactions:
Beiträge: 424
Registriert: Mo Aug 13, 2018 6:31 pm
Hat sich bedankt: 192 Mal
Danksagung erhalten: 147 Mal

#42

Beitrag von jockel »

Danke für das Update! Das es mit der 5.7.3 jetzt besser läuft ist, nach einem ersten kurzen Test, auch mein Eindruck.

Alles in allem bin ich aber froh, mit der ETS nicht mein Geld verdienen zu müssen, ich glaube ich würde den Beruf wechseln. Die gesamte Performance der Konnex in diesem Bereich ist schlicht und ergreifend eine Unverschämtheit!
TWS 2500 ID: 145 + 1x TP-UART + 2x DS9490R, VPN geschlossen, Reboot nach Absprache / wiregate198 (im Ruhestand)

Robert_Mini
Reactions:
Beiträge: 3741
Registriert: So Aug 12, 2018 8:44 am
Hat sich bedankt: 1164 Mal
Danksagung erhalten: 2058 Mal

#43

Beitrag von Robert_Mini »

Danke Stefan für die interessanten Eindrücke.

Ich sehe das Thema auch als gelöst an, zu dem man mit 2000 Universalobjekten doch auch in großen Installationen ein Auslagen findet.
Gegebenenfalls muss man dort mit dem Verknüpfen aller GA ein wenig bremsen, aber 2000 Objekte die man im TWS auch aktiv nützt, da kommt man seeeehr weit!

lg
Robert
Timberwolf Server 2500 / #117 (VPN offen + reboot nach Rückfrage) / zusätzlich: 3500M/#935, 3500L/#1297

fsl
Reactions:
Beiträge: 120
Registriert: Do Nov 01, 2018 12:23 pm
Hat sich bedankt: 55 Mal
Danksagung erhalten: 60 Mal

#44

Beitrag von fsl »

Oh je, was für eine Leidensgeschichte! So spannend geschrieben, dass ich mich gut in die Qualen der Entwickler reinversetzen konnte.

Ich bin nicht vom Fach, finde aber doch jedesmal die allgemeine Schwerfälligkeit der ETS erstaunend. Die für die Programmierung anfallenden Datenmengen sind im Vergleich zu anderen Sachen doch eher überschaubar. Und eigentlich ist es ja nur eine (nicht mal sonderlich große) Datenbank.
TWS 950Q ID:310 + PBM ID:10072, VPN offen, Reboot erlaubt
TWS 3500L ID:1030, VPN offen, Reboot erlaubt
Antworten

Zurück zu „Bekanntmachungen“