Neue Insider Version V 4.5 IP 4 verfügbar
Ein Dutzend Neuheiten, viele Verbesserungen und einige Bugfixes
Profilexport- und Import für HTTP-/REST-API; Visualisierung von Logik-Zellen (!); Erweitertes System-Monitoring; Admin-UI mit nun sechs Sprachen, VISU Client mit zwölf Sprachen; Aufzeichnung und Anzeige von Status-Logs (z.B. Diagnosetexte von KNX-Spannungsversorgungen und KNX-Aktoren); Vielfache Verbesserungen des VISU Editors uvm.
Alle Informationen hier: https://elabnet.atlassian.net/wiki/x/AY ... JwIjoiYyJ9
Ein Dutzend Neuheiten, viele Verbesserungen und einige Bugfixes
Profilexport- und Import für HTTP-/REST-API; Visualisierung von Logik-Zellen (!); Erweitertes System-Monitoring; Admin-UI mit nun sechs Sprachen, VISU Client mit zwölf Sprachen; Aufzeichnung und Anzeige von Status-Logs (z.B. Diagnosetexte von KNX-Spannungsversorgungen und KNX-Aktoren); Vielfache Verbesserungen des VISU Editors uvm.
Alle Informationen hier: https://elabnet.atlassian.net/wiki/x/AY ... JwIjoiYyJ9
[Frage] [V4.5 IP1] ETS 6.3 - TWS wird als unregistriertes Gerät angezeigt
Forumsregeln
- 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
-
- Reactions:
- Beiträge: 191
- Registriert: Sa Mär 02, 2024 11:04 am
- Hat sich bedankt: 116 Mal
- Danksagung erhalten: 122 Mal
Guten Morgen,
vielen Dank für die - ungeachtet der Schuld-Thematik - schöne und informative Zusammenfassung der Historie und für den Einblick hinter die Kulissen der ETS! Das fand ich sehr spannend zu lesen.
Ich finde es sehr müßig im Rückblick die Schuld für etwas zu klären. Im Rückblick sieht vieles immer sehr einfach und offensichtlich aus, aber jede Entscheidung muss ohne das zukünftige Wissen im damaligen Kontext gesehen werden. Und das ist beileibe nicht einfach und wird auch schnell unfair.
Aus Fehlern sollte man lernen und sich nicht daran aufreiben eine „Schuldigen zu finden“. (Juristische Sachverhalte natürlich außen vor. Bei Gerichtsverfahren beschäftigen sich hochqualifizierte Leute, die (idealerweise) alle Fakten kennen teils monatelang mit der Schuldfrage. - Unsere Medien „schaffen“ das leider immer in 1-2 Tagen).
Ich will und kann das geschriebene hinsichtlich der Schuldfrage daher nicht bewerten.
Wichtig finde ich,
1) dass es mit der Problemlösung konstruktiv weiter geht und
2) dass, wenn es Schlüsselpersonen gibt von denen alles abhängt, Alternativen vorbereitet werden.
Punkt 2) ist bei kleinen Unternehmen schwierig und bei sehr speziellen Themen (es geht ja nicht ums Brötchen backen) nochmals. Aber das ist kein Grund das Thema zu ignorieren. Es kann immer etwas passieren und sei es dass jemand z.B. aus gesundheitlichen Gründen ausfällt.
Bezüglich Punkt 1) hat Stefan schon zuvor geschrieben, dass dies der Fall ist, und ich überzeugt, dass das auch getan wird. Die Sachlage ist - wie sooft - komplizierter als es auf den erste Blick scheint und es braucht schlichtweg Zeit. Und diese sollten wir allen Beteiligten zugestehen.
Die ETS 6.2.2 funktioniert und es gibt keinen wichtigen Grund jetzt sofort auf die neuste Version zu aktualisieren. Was gestern gut genug war ist es auch heute noch. Die Erfahrung lehrt, dass es seltenst Vorteile hat, Updates als einer der ersten durchzuführen. (Es gab mal zu XP- Zeiten einen Wurm, da war Zeit wirklich kritisch).
VG Stefan
vielen Dank für die - ungeachtet der Schuld-Thematik - schöne und informative Zusammenfassung der Historie und für den Einblick hinter die Kulissen der ETS! Das fand ich sehr spannend zu lesen.
Ich finde es sehr müßig im Rückblick die Schuld für etwas zu klären. Im Rückblick sieht vieles immer sehr einfach und offensichtlich aus, aber jede Entscheidung muss ohne das zukünftige Wissen im damaligen Kontext gesehen werden. Und das ist beileibe nicht einfach und wird auch schnell unfair.
Aus Fehlern sollte man lernen und sich nicht daran aufreiben eine „Schuldigen zu finden“. (Juristische Sachverhalte natürlich außen vor. Bei Gerichtsverfahren beschäftigen sich hochqualifizierte Leute, die (idealerweise) alle Fakten kennen teils monatelang mit der Schuldfrage. - Unsere Medien „schaffen“ das leider immer in 1-2 Tagen).
Ich will und kann das geschriebene hinsichtlich der Schuldfrage daher nicht bewerten.
Wichtig finde ich,
1) dass es mit der Problemlösung konstruktiv weiter geht und
2) dass, wenn es Schlüsselpersonen gibt von denen alles abhängt, Alternativen vorbereitet werden.
Punkt 2) ist bei kleinen Unternehmen schwierig und bei sehr speziellen Themen (es geht ja nicht ums Brötchen backen) nochmals. Aber das ist kein Grund das Thema zu ignorieren. Es kann immer etwas passieren und sei es dass jemand z.B. aus gesundheitlichen Gründen ausfällt.
Bezüglich Punkt 1) hat Stefan schon zuvor geschrieben, dass dies der Fall ist, und ich überzeugt, dass das auch getan wird. Die Sachlage ist - wie sooft - komplizierter als es auf den erste Blick scheint und es braucht schlichtweg Zeit. Und diese sollten wir allen Beteiligten zugestehen.
Die ETS 6.2.2 funktioniert und es gibt keinen wichtigen Grund jetzt sofort auf die neuste Version zu aktualisieren. Was gestern gut genug war ist es auch heute noch. Die Erfahrung lehrt, dass es seltenst Vorteile hat, Updates als einer der ersten durchzuführen. (Es gab mal zu XP- Zeiten einen Wurm, da war Zeit wirklich kritisch).
VG Stefan
Zuletzt geändert von AndererStefan am Mo Dez 30, 2024 11:46 am, insgesamt 1-mal geändert.
TWS 3500XL ID:1486, VPN aktiv, Reboot nach Rücksprache
-
- Reactions:
- Beiträge: 191
- Registriert: Sa Mär 02, 2024 11:04 am
- Hat sich bedankt: 116 Mal
- Danksagung erhalten: 122 Mal
Andere Server haben auch Probleme mit der ETS 6.3.0. Das hilft zwar nicht, aber manchmal ist es schöner immerhin nicht allein zu sein.
https://knx-user-forum.de/forum/support ... -6-3-0-bug
https://knx-user-forum.de/forum/support ... -6-3-0-bug
Zuletzt geändert von AndererStefan am So Jan 12, 2025 2:42 pm, insgesamt 1-mal geändert.
TWS 3500XL ID:1486, VPN aktiv, Reboot nach Rücksprache
-
- Reactions:
- Beiträge: 38
- Registriert: Di Jul 05, 2022 6:51 pm
- Wohnort: Bisamberg, Österreich
- Hat sich bedankt: 10 Mal
- Danksagung erhalten: 35 Mal
Mich würde interessieren, ob es bereits Fortschritte bei den vor 3 Wochen von Stefan im Dezember angekündigten Tests mit dem MT gibt, bzw. ob es schon eine Roadmap für die Zertifizierung gibt?
Eine kurze Antwort mit einem Zeitrahmen würde mir reichen.
Eine kurze Antwort mit einem Zeitrahmen würde mir reichen.
_____________________________________________________________________________
Timberwolf TWS3500 M, ID:715 | VPN nicht aktiviert, Reboot nicht erlaubt
Timberwolf TWS3500 M, ID:715 | VPN nicht aktiviert, Reboot nicht erlaubt
-
- Reactions:
- Beiträge: 38
- Registriert: Di Jul 05, 2022 6:51 pm
- Wohnort: Bisamberg, Österreich
- Hat sich bedankt: 10 Mal
- Danksagung erhalten: 35 Mal
Gibt es zu dem Thema kein Update? ich würde gerne wissen, auf welchen Zeitrahmen ich mich einstellen muss.
_____________________________________________________________________________
Timberwolf TWS3500 M, ID:715 | VPN nicht aktiviert, Reboot nicht erlaubt
Timberwolf TWS3500 M, ID:715 | VPN nicht aktiviert, Reboot nicht erlaubt
-
- Reactions:
- Beiträge: 204
- Registriert: So Sep 09, 2018 9:16 am
- Hat sich bedankt: 314 Mal
- Danksagung erhalten: 74 Mal
Hallo, ich würde mich auch über ein Status Update freuen. Vor allem wenn die Lösung in einem offiziellen Release verfügbar sein wird.
Gruß
Thomas
Gruß
Thomas
WIREGATE V1.4.0
PBM unlimited mit 67 Slaves
TWS 2600 #174 REBOOT jederzeit möglich
TWS 2600 #572
PBM unlimited mit 67 Slaves
TWS 2600 #174 REBOOT jederzeit möglich
TWS 2600 #572
-
- Reactions:
- Beiträge: 502
- Registriert: Fr Sep 14, 2018 5:03 pm
- Hat sich bedankt: 1534 Mal
- Danksagung erhalten: 317 Mal
Wie Stefan in seinem Beitrag viewtopic.php?t=5602&start=50#p60300
vorletzter Satz geschrieben hat.
Sinngemäß es hängt nicht bei elabnet.
Solange Stefan keine Infos bekommt wird er auch keine Infos weitergeben können.
Wenn er allerdings des Öfteren gefragt wird und drauf antworten muss, hat er keine Zeit an der richtigen Stelle nachzufragen.
So wie ich Stefan kenne gibt er wenn er Infos hat früher Bescheid als ihm vermutlich lieb ist.
Ergo und meine private Einschätzung, je weniger gefragt wird um so schneller kann’s gehen.
vorletzter Satz geschrieben hat.
Sinngemäß es hängt nicht bei elabnet.
Solange Stefan keine Infos bekommt wird er auch keine Infos weitergeben können.
Wenn er allerdings des Öfteren gefragt wird und drauf antworten muss, hat er keine Zeit an der richtigen Stelle nachzufragen.
So wie ich Stefan kenne gibt er wenn er Infos hat früher Bescheid als ihm vermutlich lieb ist.
Ergo und meine private Einschätzung, je weniger gefragt wird um so schneller kann’s gehen.
TW 2600_99 seit 1.1.2018 / VPN zu
-
- Reactions:
- Beiträge: 38
- Registriert: Di Jul 05, 2022 6:51 pm
- Wohnort: Bisamberg, Österreich
- Hat sich bedankt: 10 Mal
- Danksagung erhalten: 35 Mal
@eib-eg
Wenn das innerhalb von 1-2 Monaten erledigt ist, ist das gut für mich, wenn das bis nächstes Jahr dauert oder vlt. gar nicht kommt, dann will ich das rechtzeitig für meine eigenen Entscheidungen verstehen. '
Viele Grüße
Wolfgang
Genau dort schreibt er, dass Elabnet dafür verantwortlich ist. Ich frage ja nicht ununterbrochen und will auch keine lange Antwort. Allerdings nach knapp eineinhalb Monaten nach dem Beitrag, könnte man eine indikative Antwort des Stack Entwicklers erwarten und seitens Elabnet ein Statusupdate (ohne viel Erklärungen!!). Nur kurz und knapp z.B.: Lösung lt. Entwickler machbar und in Arbeit, geplanter Zeitaufwand ca. xx Monate - Ende.eib-eg hat geschrieben: ↑Sa Feb 08, 2025 5:10 pm Wie Stefan in seinem Beitrag viewtopic.php?t=5602&start=50#p60300
vorletzter Satz geschrieben hat.
Wenn das innerhalb von 1-2 Monaten erledigt ist, ist das gut für mich, wenn das bis nächstes Jahr dauert oder vlt. gar nicht kommt, dann will ich das rechtzeitig für meine eigenen Entscheidungen verstehen. '
Viele Grüße
Wolfgang
_____________________________________________________________________________
Timberwolf TWS3500 M, ID:715 | VPN nicht aktiviert, Reboot nicht erlaubt
Timberwolf TWS3500 M, ID:715 | VPN nicht aktiviert, Reboot nicht erlaubt
-
- Reactions:
- Beiträge: 502
- Registriert: Fr Sep 14, 2018 5:03 pm
- Hat sich bedankt: 1534 Mal
- Danksagung erhalten: 317 Mal
Nicht böse sein auf die Antwort von mir für dich @wokro
Stell dir mal vor du willst eine Gans bestimmte marmorfliese mit einer genaudefinierten farbschattierung.
Der Fliesenleger hat diese nicht, und der widerum ruft beim Händler an , der widerum sagt ich muss beim Hersteller nachfragen.
Der Hersteller sagt aktuell ist diese farbschatierung „könnte“ beim nächsten blockschnitt vermutlich dabei sein.
Die gleiche Antwort bekommst du jetzt auch
Nur
Du weist nicht wie lange der blockschnicht braucht und zum zweiten ob genau deine farbschattierung dabei ist
Weil du aber nach 14 Tagen vom Fliesenleger immer noch keine Rückmeldung bekommen hast stellst den Fliesenleger wider die Frage wie ein hamsterrad.
Die gleiche Prozedur fängt also wider von vorne an
Die Arbeiter die den Block schneiden wissen aber nicht einmal das du einen gans besonderen Marmor willst
Ich lasse jetzt mal den ganzen kladaradasch weg vom Marmorbruch über den lader der es auf einen Lastwagen lät und der widerum zum Sägewerk bring um Platten herzustellen weiter zum Transport zum schleifen und polieren verpacken verschiffen ergo Transport
Dann in D einlagern Fotos machen ob da genau deiner dabei ist ist dann wider in frage gestellt.
Was will ich damit sagen
Ich kann deinen Unmut weil du keine Antwort bekommst gut verstehen.
Aber
Würde es was bringen wenn du beim Fliesenleger täglich eine Mail meldest oder anrufst
Überleg mal
Du bist mit deinem ganzen gehirnschmalz beim programmieren und das Telefon leutet
Du wirst von deinem richtigen Gedanken den du dir die letzten 2h gemacht hast und gerade am tippen warst runter gezogen wegen diesem Telefonat
Was passiert
Du darfst dich aufregen weil du die gesamte Zeit wider investieren darfst und dich wider reindenken kannst und musst ohne das du dich negative dem Telefongesprächsparter äußern darfst oder sollst.
Ergo
Es haben mehr läute was davon wenn „nicht“ (andauernd) nachgefragt wird.
Oder fragst du deine Frau wenn sie in der 4ten Woche schwanger ist ob die presswehen schon kommen.
So
Jetzt hab ich mal meinen Frust geschrieben
Bitte keine weiteren Diskussionen
Ein Kind braucht seine Zeit
Wenn es zu früh kommst muss es in die Intensivstation und aufwendig versorgt werden das es überlebt.
Genau das will keiner
Sondern ein gesundes und frisch geborenes Kind.
So lang genug geschrieben noch einen schönen sonnigen Sonntag
.
Stell dir mal vor du willst eine Gans bestimmte marmorfliese mit einer genaudefinierten farbschattierung.
Der Fliesenleger hat diese nicht, und der widerum ruft beim Händler an , der widerum sagt ich muss beim Hersteller nachfragen.
Der Hersteller sagt aktuell ist diese farbschatierung „könnte“ beim nächsten blockschnitt vermutlich dabei sein.
Die gleiche Antwort bekommst du jetzt auch
Nur
Du weist nicht wie lange der blockschnicht braucht und zum zweiten ob genau deine farbschattierung dabei ist
Weil du aber nach 14 Tagen vom Fliesenleger immer noch keine Rückmeldung bekommen hast stellst den Fliesenleger wider die Frage wie ein hamsterrad.
Die gleiche Prozedur fängt also wider von vorne an
Die Arbeiter die den Block schneiden wissen aber nicht einmal das du einen gans besonderen Marmor willst
Ich lasse jetzt mal den ganzen kladaradasch weg vom Marmorbruch über den lader der es auf einen Lastwagen lät und der widerum zum Sägewerk bring um Platten herzustellen weiter zum Transport zum schleifen und polieren verpacken verschiffen ergo Transport
Dann in D einlagern Fotos machen ob da genau deiner dabei ist ist dann wider in frage gestellt.
Was will ich damit sagen
Ich kann deinen Unmut weil du keine Antwort bekommst gut verstehen.
Aber
Würde es was bringen wenn du beim Fliesenleger täglich eine Mail meldest oder anrufst
Überleg mal
Du bist mit deinem ganzen gehirnschmalz beim programmieren und das Telefon leutet
Du wirst von deinem richtigen Gedanken den du dir die letzten 2h gemacht hast und gerade am tippen warst runter gezogen wegen diesem Telefonat
Was passiert
Du darfst dich aufregen weil du die gesamte Zeit wider investieren darfst und dich wider reindenken kannst und musst ohne das du dich negative dem Telefongesprächsparter äußern darfst oder sollst.
Ergo
Es haben mehr läute was davon wenn „nicht“ (andauernd) nachgefragt wird.
Oder fragst du deine Frau wenn sie in der 4ten Woche schwanger ist ob die presswehen schon kommen.
So
Jetzt hab ich mal meinen Frust geschrieben
Bitte keine weiteren Diskussionen
Ein Kind braucht seine Zeit
Wenn es zu früh kommst muss es in die Intensivstation und aufwendig versorgt werden das es überlebt.
Genau das will keiner
Sondern ein gesundes und frisch geborenes Kind.
So lang genug geschrieben noch einen schönen sonnigen Sonntag
.
TW 2600_99 seit 1.1.2018 / VPN zu
-
- Elaborated Networks
- Reactions:
- Beiträge: 10564
- Registriert: So Aug 12, 2018 9:27 am
- Wohnort: Frauenneuharting
- Hat sich bedankt: 5223 Mal
- Danksagung erhalten: 8521 Mal
- Kontaktdaten:
Hallo zusammen,
ich hatte am 21. Januar m Nachbarthread darüber geschrieben:
viewtopic.php?t=4076&start=20#p60599
Wir haben mehrere KNX Stack Versionen derzeit im Test bei den DEV-Testern. Eine belastbare Angabe, ob damit alles erledigt ist oder gar wann man das ausrollen könnte, kann man daraus nicht ableiten.
Das ganze ist eine Farce. Unser KNX Stack und das KNXnet/IP Tunneling ist seit 2018 von einem unabhängigen Labor zertifiziert und war seither auch ein Fels in der Brandung. Nun hat die KNXA eine neue ETS Version herausgebracht (die übriges nicht von einem unabhängigen Labor zertifiziert wurde....) die in Verbindung mit unserem KNXnet/IP Tunnelung - und auch bei mindestens einem Wettbewerber (bei dem ich davon ausgehe, dass dieser ebenfalls seinen Stack von einem unabhängigen Labor hat zertifizieren lassen) - plötzlich nicht mehr richtig funktioniert. Von einer ETS zur nächsten. Einfach so.
Und jetzt sollen wir eine angepasste Kommunikation für die aktuelle ETS finden, ohne die perfekte Kompatibilität zu Dutzenden vorhergehenden ETS-Versionen zu gefährden, die ja durchaus im Einsatz bei Kunden sein können. Zudem könnte es auch gut möglich sein, dass die KNXA demnächst eine neuere ETS Version herausbringt, bei der die Änderungen wieder zurück gedreht wurden. So etwas wäre nicht das erste mal in der Geschichte der ETS. Es weiß keiner, was die KNXA hier gerissen hat, das wichtigste Protokoll - zur Programmierung (für nichts anderes ist die ETS nützlich) - so zu ändern, das es selbst für bestehende zertifizierte KNXnet/IP Stacks nicht mehr genutzt werden kann (während weiterhin die Nutzung durch die Software "vom Rest der Welt" keine Probleme macht).
Aber der Hersteller soll Schuld sein, der nichts geändert hat und bei dem es jahrelang funktionierte.
Natürlich sind wir dran, weil wir unsere Kunden nicht im Regen stehen lassen und keiner weiß, ob die KNXA sich hier bewegt oder stur bleibt.
Aber da die neue Implementierung nicht nur zur neuen ETS Ausgabe kompatibel sein soll, sondern zu allen vorhergehenden Ausgaben der ETS und jeder Menge dritter Software (alles was ihr so in Containern benutzt) ist das eine fast unmögliche Herausforderung mit unklarer Prognose.
Die Sache ist komplex und es geht um mehr als die eine ETS Version, die aus der Reihe tanzt. Darum kann ich Euch auch keinen Fahrplan und kein belastbaren Termin geben und ich bitte von Nachfragen abzusehen. Man kann bei neuen Themen - insbesondere in Verbindung mit uns im Detail unbekannten Produkten Dritter - einfach keine seriöse Abschätzung abgeben, wann ein Kompatibilitätsproblem sicher erledigt ist. Ich melde, wenn es wirklich einen klar benennbaren Fortschritt und eine Lösung gibt.
Stefan
ich hatte am 21. Januar m Nachbarthread darüber geschrieben:
viewtopic.php?t=4076&start=20#p60599
Wir haben mehrere KNX Stack Versionen derzeit im Test bei den DEV-Testern. Eine belastbare Angabe, ob damit alles erledigt ist oder gar wann man das ausrollen könnte, kann man daraus nicht ableiten.
Das ganze ist eine Farce. Unser KNX Stack und das KNXnet/IP Tunneling ist seit 2018 von einem unabhängigen Labor zertifiziert und war seither auch ein Fels in der Brandung. Nun hat die KNXA eine neue ETS Version herausgebracht (die übriges nicht von einem unabhängigen Labor zertifiziert wurde....) die in Verbindung mit unserem KNXnet/IP Tunnelung - und auch bei mindestens einem Wettbewerber (bei dem ich davon ausgehe, dass dieser ebenfalls seinen Stack von einem unabhängigen Labor hat zertifizieren lassen) - plötzlich nicht mehr richtig funktioniert. Von einer ETS zur nächsten. Einfach so.
Und jetzt sollen wir eine angepasste Kommunikation für die aktuelle ETS finden, ohne die perfekte Kompatibilität zu Dutzenden vorhergehenden ETS-Versionen zu gefährden, die ja durchaus im Einsatz bei Kunden sein können. Zudem könnte es auch gut möglich sein, dass die KNXA demnächst eine neuere ETS Version herausbringt, bei der die Änderungen wieder zurück gedreht wurden. So etwas wäre nicht das erste mal in der Geschichte der ETS. Es weiß keiner, was die KNXA hier gerissen hat, das wichtigste Protokoll - zur Programmierung (für nichts anderes ist die ETS nützlich) - so zu ändern, das es selbst für bestehende zertifizierte KNXnet/IP Stacks nicht mehr genutzt werden kann (während weiterhin die Nutzung durch die Software "vom Rest der Welt" keine Probleme macht).
Aber der Hersteller soll Schuld sein, der nichts geändert hat und bei dem es jahrelang funktionierte.
Natürlich sind wir dran, weil wir unsere Kunden nicht im Regen stehen lassen und keiner weiß, ob die KNXA sich hier bewegt oder stur bleibt.
Aber da die neue Implementierung nicht nur zur neuen ETS Ausgabe kompatibel sein soll, sondern zu allen vorhergehenden Ausgaben der ETS und jeder Menge dritter Software (alles was ihr so in Containern benutzt) ist das eine fast unmögliche Herausforderung mit unklarer Prognose.
Die Sache ist komplex und es geht um mehr als die eine ETS Version, die aus der Reihe tanzt. Darum kann ich Euch auch keinen Fahrplan und kein belastbaren Termin geben und ich bitte von Nachfragen abzusehen. Man kann bei neuen Themen - insbesondere in Verbindung mit uns im Detail unbekannten Produkten Dritter - einfach keine seriöse Abschätzung abgeben, wann ein Kompatibilitätsproblem sicher erledigt ist. Ich melde, wenn es wirklich einen klar benennbaren Fortschritt und eine Lösung gibt.
Stefan
Zuletzt geändert von StefanW am So Feb 09, 2025 4:54 pm, insgesamt 4-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.
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.
-
- Elaborated Networks
- Reactions:
- Beiträge: 10564
- Registriert: So Aug 12, 2018 9:27 am
- Wohnort: Frauenneuharting
- Hat sich bedankt: 5223 Mal
- Danksagung erhalten: 8521 Mal
- Kontaktdaten:
Hallo zusammen,
kurzer Zwischenstatus: Noch nicht abschließend gelöst
Das Thema mit der ETS 6.3 und unserer IP-Schnittstelle im Timberwolf Server ist leider noch nicht gelöst.
Wer es genauer wissen will, bitte sehr:
1. Wir haben unseren Stack sowie die IP-Schnittstelle in 2018 vom Prüflabor zertifizieren lassen, auf Basis des damaligen Standards. Normalerweise gilt in der KNX Welt, dass die Kompatibilität erhalten bleiben muss und bei neueren Standards eine neuere ETS trotzdem früher gültige Standards unterstützen muss. Daher kann man auch einen Tastsensor von 1997 parallel zu neuen KNX Komponenten in der selben Anlage betreiben, selbst wenn dieser alter Tastsensor heute keine Zertifizierung mehr bestehen würde. Diese Unterstützungspolitik der KNXA ist eine ganz großem Stärke und schafft viel Vertrauen in diese Technik zu investieren, weil man eben nicht befürchten muss, dass eines Tages "alles raus" müsste, weil was neues dazu kommt.
2. Es gibt seither mehrere Neuerungen für KNXnet/IP, die bekannteste ist IP Security, gibt aber noch andere Details.
3. Die Prüflabore verwenden dazu eine von der KNXA bereitgestellte Testsoftware, mit der das standardkonforme Verhalten der IP Schnittstelle getestet wird. Diese Software steht auch uns KNX Herstellern zur Verfügung (sogar kostenfrei). Wir haben in den letzten Wochen die aktuellste Version heruntergeladen und damit unsere IP-Implementierung getestet (und auch nochmal mit der damaligen Version). Mit der aktuellen Version wurden Inkompatibilitäten angezeigt, weil man sich nun bestimmte Datenfelder ausgefüllt erwartet, die früher auch leer bleiben durften.
4. Um besser vergleichen zu können, haben wir drei aktuelle KNXnet/IP Schnittstellen (einer davon ist auch einer der modernsten KNX Secure Router) beschafft und haben auch diese mit dem Tool getestet um eine Baseline zu haben, zumal man ohnehin zwei IP-Schnittstellen benötigt, eine als "Device under Test" und eine zweite welche den Test unterstützt, indem diese Prüfdaten auf den TP-Bus schreibt. Das Testtool kommuniziert also mit zwei Schnittstellen und um zu vermeiden, dass wir einen Fehler bei uns haben, den wir nicht richtig sehen, weil wir über zwei TWS testen, wollten wir dafür auch zertifizierte Schnittstelle anderer Hersteller verwenden. Ihr seht, wir scheuen keine Kosten und Mühen
5. Wir haben nun unsere KNXnet/IP-Tunnel Implementierung auf den aktuellen Stand gebracht, so dass das Testtool zufrieden ist und wir eine neue Zertifizierung schaffen würden. Wie gesagt, das waren im Wesentlichen ein paar Datenfelder mit Auskunft über die eigenen Fähigkeiten beim Verbindungsaufbau, nichts dramatisch anderes im Protokollablauf.
6. Diese neue Implementierung ging gestern an die DEV-Tester, zusammen mit vielen anderen Verbesserungen, damit wir sehen, wie sich das in der Praxis schlägt.
ABER
7. Das Problem mit der ETS 6.3 in Verbindung mit unserem (neuen) Tunnel ist damit nicht gelöst worden. Wir haben natürlich traces gemacht und es fällt auf, dass wenn wir en TWS mit der neuen (auch der vormaligen) IP-Implementierung nutzen, dann wird die ETS plötzlich langsam und wartet nach jedem ACK (vom TWS) fast eine Sekunde bis das nächste Protokollelement von der ETS kommt, während das gleiche mit anderen Schnittstellen nur 3 ms dauert, d.h. die ETS wird etwa um den Faktor 300 langsamer mit dem TWS (vormalige wie aktuelle Implementierung). Eine Erklärung dafür haben wir nicht.
8. Daher haben wir nun ein Ticket bei der KNX Asssociation offen mit dem Trace. Hätten wir vorher zwar auch schon denen senden können, aber wir wollten weitestgehend sicherstellen, dass das Problem nicht auf unserer Seite liegt und haben unsere Implementierung auf den aktuellen Stand des Standards und des IP-Tunnel-Testtools gebracht. Wir haben der KNXA auch ein Testgerät angeboten.
Dazu noch
9. Es gibt eine Beta-Version der ETS 6.3.1 in der folgendes steht:

Leider steht diese BETA nicht mehr zum Download zur Verfügung. Sollte jemand von Euch diese haben. bitte über wetransfer an service at elabnet dot de senden. Wir fragen aber parallel bei der KNXA an, ob wir diese bekommen können, weil Inkompatibilitäten mit manchen IP-Schnittstellen hat uns aufhorchen lassen.
10. Es gibt auch eine Beta-Version der ETS 6.4 (die für Ende des Jahres vorgesehen ist). Diese war downloadbar und mit dieser haben wir heute getestet. Und - voilà - unser Tunnel funktioniert wieder, zumindest in den meisten Tests.
Also, wir sind weiter dran, die Funktion wieder zu erkämpfen und werden künftig die BETA Versionen der ETS in unsere Tests miteinbeziehen, so dass wir gefundenen Inkompatibilitäten im Vorfeld finden können, so dass die KNXA diese vor Ausgabe korrigieren kann. 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.
und dazu auch noch
11. Die Vorbereitungen zur Zertifizierung der Applikation laufen bereits. Wir haben entschieden, dass wir hier keine Zeit mehr verlieren wollen und dann eben die bisherige alte Applikation, auch wenn diese wegen der ETS Limits nur die 2.000 Objekte kann, zertifizieren lassen und danach eben die richtige. Das hängt vom Termin im Labor ab. Falls sich die Termine ziehen (damals mussten wir ein viertel Jahr warten) dann versuchen wir in der Zeit die 8.000er Applikation und die neuen DPT zu entwickeln und testen und dann diese zu zertifizieren. Wir haben dazu in dieser Woche Lizenzen für 2.500+ EUR bei der KNXA gekauft, damit wir die neuesten Tools haben.
Wir sind auf jeden Fall jetzt an allen offenen KNX Themen dran und ich halte Euch auf dem Laufenden.
lg
Stefan
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.
kurzer Zwischenstatus: Noch nicht abschließend gelöst
Das Thema mit der ETS 6.3 und unserer IP-Schnittstelle im Timberwolf Server ist leider noch nicht gelöst.
Wer es genauer wissen will, bitte sehr:
1. Wir haben unseren Stack sowie die IP-Schnittstelle in 2018 vom Prüflabor zertifizieren lassen, auf Basis des damaligen Standards. Normalerweise gilt in der KNX Welt, dass die Kompatibilität erhalten bleiben muss und bei neueren Standards eine neuere ETS trotzdem früher gültige Standards unterstützen muss. Daher kann man auch einen Tastsensor von 1997 parallel zu neuen KNX Komponenten in der selben Anlage betreiben, selbst wenn dieser alter Tastsensor heute keine Zertifizierung mehr bestehen würde. Diese Unterstützungspolitik der KNXA ist eine ganz großem Stärke und schafft viel Vertrauen in diese Technik zu investieren, weil man eben nicht befürchten muss, dass eines Tages "alles raus" müsste, weil was neues dazu kommt.
2. Es gibt seither mehrere Neuerungen für KNXnet/IP, die bekannteste ist IP Security, gibt aber noch andere Details.
3. Die Prüflabore verwenden dazu eine von der KNXA bereitgestellte Testsoftware, mit der das standardkonforme Verhalten der IP Schnittstelle getestet wird. Diese Software steht auch uns KNX Herstellern zur Verfügung (sogar kostenfrei). Wir haben in den letzten Wochen die aktuellste Version heruntergeladen und damit unsere IP-Implementierung getestet (und auch nochmal mit der damaligen Version). Mit der aktuellen Version wurden Inkompatibilitäten angezeigt, weil man sich nun bestimmte Datenfelder ausgefüllt erwartet, die früher auch leer bleiben durften.
4. Um besser vergleichen zu können, haben wir drei aktuelle KNXnet/IP Schnittstellen (einer davon ist auch einer der modernsten KNX Secure Router) beschafft und haben auch diese mit dem Tool getestet um eine Baseline zu haben, zumal man ohnehin zwei IP-Schnittstellen benötigt, eine als "Device under Test" und eine zweite welche den Test unterstützt, indem diese Prüfdaten auf den TP-Bus schreibt. Das Testtool kommuniziert also mit zwei Schnittstellen und um zu vermeiden, dass wir einen Fehler bei uns haben, den wir nicht richtig sehen, weil wir über zwei TWS testen, wollten wir dafür auch zertifizierte Schnittstelle anderer Hersteller verwenden. Ihr seht, wir scheuen keine Kosten und Mühen

5. Wir haben nun unsere KNXnet/IP-Tunnel Implementierung auf den aktuellen Stand gebracht, so dass das Testtool zufrieden ist und wir eine neue Zertifizierung schaffen würden. Wie gesagt, das waren im Wesentlichen ein paar Datenfelder mit Auskunft über die eigenen Fähigkeiten beim Verbindungsaufbau, nichts dramatisch anderes im Protokollablauf.
6. Diese neue Implementierung ging gestern an die DEV-Tester, zusammen mit vielen anderen Verbesserungen, damit wir sehen, wie sich das in der Praxis schlägt.
ABER
7. Das Problem mit der ETS 6.3 in Verbindung mit unserem (neuen) Tunnel ist damit nicht gelöst worden. Wir haben natürlich traces gemacht und es fällt auf, dass wenn wir en TWS mit der neuen (auch der vormaligen) IP-Implementierung nutzen, dann wird die ETS plötzlich langsam und wartet nach jedem ACK (vom TWS) fast eine Sekunde bis das nächste Protokollelement von der ETS kommt, während das gleiche mit anderen Schnittstellen nur 3 ms dauert, d.h. die ETS wird etwa um den Faktor 300 langsamer mit dem TWS (vormalige wie aktuelle Implementierung). Eine Erklärung dafür haben wir nicht.
8. Daher haben wir nun ein Ticket bei der KNX Asssociation offen mit dem Trace. Hätten wir vorher zwar auch schon denen senden können, aber wir wollten weitestgehend sicherstellen, dass das Problem nicht auf unserer Seite liegt und haben unsere Implementierung auf den aktuellen Stand des Standards und des IP-Tunnel-Testtools gebracht. Wir haben der KNXA auch ein Testgerät angeboten.
Dazu noch
9. Es gibt eine Beta-Version der ETS 6.3.1 in der folgendes steht:

Leider steht diese BETA nicht mehr zum Download zur Verfügung. Sollte jemand von Euch diese haben. bitte über wetransfer an service at elabnet dot de senden. Wir fragen aber parallel bei der KNXA an, ob wir diese bekommen können, weil Inkompatibilitäten mit manchen IP-Schnittstellen hat uns aufhorchen lassen.
10. Es gibt auch eine Beta-Version der ETS 6.4 (die für Ende des Jahres vorgesehen ist). Diese war downloadbar und mit dieser haben wir heute getestet. Und - voilà - unser Tunnel funktioniert wieder, zumindest in den meisten Tests.
Also, wir sind weiter dran, die Funktion wieder zu erkämpfen und werden künftig die BETA Versionen der ETS in unsere Tests miteinbeziehen, so dass wir gefundenen Inkompatibilitäten im Vorfeld finden können, so dass die KNXA diese vor Ausgabe korrigieren kann. 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.
und dazu auch noch
11. Die Vorbereitungen zur Zertifizierung der Applikation laufen bereits. Wir haben entschieden, dass wir hier keine Zeit mehr verlieren wollen und dann eben die bisherige alte Applikation, auch wenn diese wegen der ETS Limits nur die 2.000 Objekte kann, zertifizieren lassen und danach eben die richtige. Das hängt vom Termin im Labor ab. Falls sich die Termine ziehen (damals mussten wir ein viertel Jahr warten) dann versuchen wir in der Zeit die 8.000er Applikation und die neuen DPT zu entwickeln und testen und dann diese zu zertifizieren. Wir haben dazu in dieser Woche Lizenzen für 2.500+ EUR bei der KNXA gekauft, damit wir die neuesten Tools haben.
Wir sind auf jeden Fall jetzt an allen offenen KNX Themen dran und ich halte Euch auf dem Laufenden.
lg
Stefan
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.
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.
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.