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

[Franky]

Stefan,

vielen Dank für dieses ausführliche Update. Gute Kommunikation.

Zudem sehen wir zu, dass die einen TWS im Labor haben und selbst die Tests vornehmen. Dies hätten wir in der Vergangenheit schon tun sollen, da haben wir echt geschlafen - oder zu viel vertraut, je nachdem wie man das sehen möchte.

Den Gedanken hatte ich auch schon ... Wenn einer der Produktmanager bei der KNXA den TWS selbst produktiv einsetzen würde (mal annehmend, dass irgendwer von denen auch privat KNX betreibt ) wäre das incentive das schnell wieder ans laufen zu bekommen ein ganz anderes.

PS: in der 6.4 Beta rennt unsere 2.000er Applikation fast ohne Verzögerung. Die KNXA hat sich hier wohl ziemlich angestrengt, die Bremsen zu lösen. Hurra.

[StefanW]

Hi,

Wenn einer der Produktmanager bei der KNXA den TWS selbst produktiv einsetzen würde (mal annehmend, dass irgendwer von denen auch privat KNX betreibt ) wäre das incentive das schnell wieder ans laufen zu bekommen ein ganz anderes.

Der Produktmanager ETS auf der Seite der KNXA hat bereits einen Timberwolf Server, seit bald drei Jahren, als Leihstellung für sein privates Haus. Aber er wird auch was anderes zu tun haben, als jede Beta der ETS in allen Aspekten mit dem TWS zu testen.

Was ich meinte, ist, dass wir einen TWS AUCH ins das Labor der beiden Unternehmen bekommen, welche die ETS tatsächlich programmieren, damit der Timberwolf Server in deren Standardtests aufgenommen wird. Ich hatte da mal den Projektmanager ETS auf der Seite der Herstellerfirma darüber gesprochen und das hätte ihn schon interessiert. Das werden wir im Rahmen der neuen Zertifizierung der Applikation machen, ich denke, vorher nehmen die das Gerät womöglich nicht an, aber wir werden zeitnah fragen.


lg

STefan

[StefanW]

Hallo zusammen,

kurzer Zwischenstatus: Fehlerursache gefunden

Das Thema mit der ETS 6.3 und unserer IP-Schnittstelle im Timberwolf Server scheint nun gelöst

Nur ganz kurz, weil ich auf Dienstreise muss, wir haben - in sehr guter Zusammenarbeit mit der KNXA und den Entwicklern der ETS - einen Fehler in unserer KNXnet/IP Tunneling Implementierung gefunden, den unser externer Spezialist heute behoben hat. Bei uns funktioniert nun das Programmieren aus der ETS 6.3 wieder.

==> Wir haben den korrigierten KNX-Stack heute Abend unseren DEV-Testern zur Verfügung gestellt und um einen schnellen Test gebeten. Sofern das erfolgreich ist, gibt es eine "Sonderausgabe" einer Insider Version und dann recht zügig auch einen Fix für die letzte Hauptversion.

Mehr Details, wenn ich Zeit habe dafür.

Danke an die KNXA und an Herrn Dr. Klaus Güter, der den entscheidenden Punkt gefunden hat.

lg

Stefan

[StefanW]

Hallo zusammen,

Zwischenstatus: FIX für Tunnel-Probleme mit der ETS 6.3 für Insider AUSGEROLLT

Das Thema mit der ETS 6.3 und unserer IP-Schnittstelle im Timberwolf Server ist nun für alle Insider gefixed

Wir haben heute die neueste Implementierung unseres KNXnet/IP Tunneling Server mit IP 5 zur V4.5 ausgerollt. Einen Fix für die aktuelle Hauptversion 4.1 rollen wir alsbald aus, wir wollen noch ein paar Tage den Test durch die Insider abwarten. Darum bitten wir alle Insider um eine zügige Installation und Test.


Ein paar Infos dazu (als Ergänzung zum oben bereits beschriebenen).

1. Nach vielen eigenen Versuchen, die ich oben bereits beschrieben hatte, haben wir uns an die KNX Association per Ticket gewandt und haben die Probleme beschrieben-

2. Bereits am nächsten Tag haben wir die aktuelle Beta der ETS 6.3.1 zum Test erhalten, da darin bereits Kompatibilitätsprobleme der V 6.3 mit IP Schnittstellen behoben worden waren. Diese Version zeigte zwar im Detail ein etwas anderes Bild, es blieben jedoch Fehlermeldungen und vor allem eine extrem langsame Programmierung, die man auch am Mitschnitt des Netzwerk-Verkehrs erkennen konnte, weil nach jedem Antwortpaket des TWS die ETS eine Pause von einer Sekunde eingelegt hat.

3. Wir haben dann unsere Traces an die KNXA geschickt und wieder erhielten wir sehr schnell - 2 Stunden (!) - eine Antwort von Dr. Klaus Gütter, der im Mitschnitt einen Fehler bei der Behandlung des Routingzählers erkannt hatte. Zur Info für Euch, Klaus ist GF der IT Gmbh, die im Auftrag der KNXA für die ETS unter anderem den Falcon-Treiber (das ist der KNXnet/IP Treiber unter Windows) entwickeln und damit der Top-Fachmann in der Sache ist.

4. Unsere bisherige Implementierung - seit 2018 - des KNXnet/IP Tunneling Servers im KNX Stack des Timberwolf Servers hat beim Übergang von KNXnet/IP Tunneling auf KNX-TP (bzw. umgekehrt) den Routing-Zähler im KNX-Telegramm dekrementiert. Dies war bislang ok so und wurde damals nicht nur so von dem Testlabor zertifiziert, sondern wird auch vom aktuellen IP-Test-Tool der KNXA (die u.a. für derzeitige Zertifizierungen verwendet wird) NICHT beanstandet.

5. Die ETS in der Version 6.3 prüft nun jetzt den Routingzähler des Acknowlege-Pakets und da die ETS hier keine (durch den Tunnel zusätzliche) Dekrementierung erwartet, wurden diese "Ack" Antwortpakete während der Programmierung jeweils nicht angenommen und deshalb jeweils ein Timeout von 1 Sekunde abgewartet. Danach setzte die ETS die Programmierung zwar fort, nur eben wegen des Timeouts nach jedem einzelnen Programmierpaket im Ergebnis sehr langsam und schloss mit der Fehlermeldung "über eine schlechte Verbindung" ab, was ein wenig knapp an den tatsächlichen Gegebenheiten vorbei ist. Ein Hinweis wie z.B. "Unerwarteter Routingzähler, evt. liegt ein Fehler in der Topologie" vor, wäre sehr viel mehr hilfreich gewesen. Ebenso wäre es zielführend gewesen, wenn das IP-Tunnel-Testtool der KNXA den Routingzähler mit prüfen würde (wir haben dies gestern der KNXA für die nächste Version vorgeschlagen).

6. Es gab verschiedene Ansichten darüber, wie der Standard auszulegen ist und ob die Dekrementierung des Routing Zählers ("Hop Count") bei Übergang von einem KNXnet/IP Tunnel vorgenommen werden soll oder nicht. Im KNX Standard ist das ein wenig unklar definiert, weil es dort heißt, dass dies immer dann zu tun ist, "wenn es einen Wechsel der Linie oder des Mediums gibt, sofern der Hop-Count für das jeweilige Medium gilt." Als Beispiel ist dann angegeben "TP-TP oder TP-IP". Hmm. Hier ist mit "IP" offenbar nur KNXnet/IP Routing gemeint, aber nicht KNXnet/IP Tunnel. Diese Feinheit, die bisher keine Rolle gespielt hat, ist eben nun zu beachten und mit der aktuellen Implementierung haben wir uns nun an diese Lesart der Vorschrift angepasst.

Das soll bitte nicht so verstanden werden, als wenn hier die KNXA in irgendeiner Weise "schuld" wäre. Die Haltung, dass der Hop Count hier nicht zu dekrementieren ist, ist für einen Tunnel absolut nachvollziehbar und wir haben auf Nachfrage auch eine - für dieses Forum etwas zu komplexe - Begründung erhalten.

Digitale Kompatibilität ist einfach eine Bitch. Es muss jedes Bit in der richtigen Reihenfolge, richtigen Kodierung und richtigen Geschwindigkeit und Abstand kommen. Hier waren letztlich zwei Bit falsch (Routing Zähler Dezimal-Fünf anstatt Dezimal-Sechs).

Warum dies erst in der ETS 6.3 so streng gehandhabt wird, warum die Fehlermeldung hier nicht klarer ist, warum die IP-Testtools der KNXA den falschen Routingzähler nicht prüfen und warum unser KNXnet/IP Tunneling Server damals zertifiziert wurde und was man eigentlich bei der KNXA gemacht hätte, wenn wir jetzt nicht so einfach ein Firmware-Update hätten ausrollen können, wäre wohl eine Diskussion wert. Womöglich habe ich hierzu mal die Gelegenheit.

Wir haben das Verhalten unseres KNXnet/IP Tunneling Server nun entsprechend angepasst und dabei auch alle neueren Prüfpunkte des aktuellen Testtools berücksichtigt (und bestehen dort nun alle Prüfungen), diese Firmware letzte Woche an die DEV-Tester ausgerollt und vor wenigen Stunden auch an alle Insider mit IP 5 zur V 4.5.

Wir haben zuvor bereits ausgiebige Tests mit der Beta der ETS 6.3.1 vorgenommen und werden noch umfangreich mit der ebenfalls vorliegenden Beta der ETS 6.4 testen. Zudem haben wir unseren Testaufbau im Labor massiv erweitert und auch jede Menge Wettbewerbsprodukte (insbesondere Secure Koppler, Secure Router usw) dafür angeschafft. Damit wollen wir unseren nächsten KNX Stack einem umfangreicheren Test in komplexeren Szenarien unterziehen.


Es tut mir sehr leid, dass Kunden hier betroffen waren. Von unserer Seite hätten wir das früher erkennen können, wenn wir mit der Beta der V 6.3 getestet hätten. Hatten wir nicht gemacht, weil es in der Vergangenheit auch keine Probleme mit der ETS und dem Timberwolf Server hatten und 6.3 klang nicht nach potentiell gefährlicher Änderung (bei einer 7.0 hätten wir das anders gesehen). Das war ein Fehler von uns, wir werden künftig alle
erreichbaren Beta Versionen der ETS künftig vorab testen, so dass wir die Probleme dann lösen können, bevor eine neue Version heraus kommt.

Ich bitte Euch daher um Entschuldigung für unseren Fehler.

Das Thema mit der Zertifizierung der Applikation läuft noch parallel, hier habe ich gerade keine belastbaren Informationen, ich halte Euch diesbezüglich auf dem Laufenden.

lg

Stefan

[Elkomaster91]

Bei mir geht es jetzt ohne Probleme.

Dankeschön

Gruß Hardi

[minjor]

Nur zur Info:
Bin wieder zurück zur ETS 6.3.0 und mit der IP5 der V4.5 funktioniert die Programmierung wieder sauber und gefühlt schneller als vorher. Letzteres mag aber subjektiv sein.

Vielen Dank ans Team!

[wokro]

Wie seht es mit der bugfix Release für die "Nicht Insider" aus?

VG

[eib-eg]

@wokro

Willst du ein halbfertiges oder komplett getestetes

Wenn fertig dann fertig

In der Software liegt ein Fehler oft an einen Bit, nur wenn der beseitigt ist heißt es noch lange nicht das sich nicht noch ein zweiter versteckt hat

Und bekanntlich auf den Menschen bezogen ist ein Kind nicht am nächsten Tag nach der Produktion auf der Welt

Je öfters nachgefragt wird und Stefan sozusagen zu eine Antwort quasi gezwungen wird eine Antwort zu schreiben, hälst du ihn somit auf Infos von den Insidern zu sammeln um zu entscheiden ob es freigegeben wird oder nicht.

Ergo
Wenn elabnet es freigibt steht es zur Verfügung.

PUNKT.

[wokro]

@eib-eg

Nur ein Wort: wer bist Du, um mir so zu antworten?
Ich weiß sehr wohl wie S/W Entwicklung funktioniert und habe selbst ein Unternehmen geführt.
Auch in Hinblick auf die Kommunikation mit dem Kunden.

Lassen wir es dabei! Es wäre müßig.

[Franky]

ruhig Blut, wir sitzen im selben Bot. Die Frage war insofern etwas ungeschickt, da ElebNET bestimmt nicht vergessen wird, gerade dieses Feature auszurollen und @wokro mit Deiner Erfahrung weißt du, wie schwierig Terminaussagen sind. Gerade wenn dieses Feature ausgerollt wird und Seiteneffekte hätte, wäre die Häme wieder groß. Das Thema Auslieferungsplanung ist hier im Forum so oft schon besprochen worden, bitte nicht nochmal

Laßt uns hier nicht unnötig zoffen please.

Fanky