Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
Hmm, nee darüber reden wir lieber nicht, ich war glaub ich auch da sowas wie Beta-Tester.. Aber ehrlich, die ETS5 sprengt den erträglichen Rahmen hier nochmal deutlich..
Darf ich mal nachfragen: Bist Du offiziell an der Entwicklung der ETS5 beteiligt oder wie ist Dein Engagement hier zu verstehen?
OK, erst einmal zu meiner Person: Ich heiße Jan Kessler, arbeite seit 1996 im EIB Umfeld, habe 2003 für die EIBA die eFCP Spezifikation (aus der KNX-USB und KNX-IP hervorgegangen sind) geschrieben, arbeite seitdem in den Arbeitskreisen der EIB/KNX Systemgruppe mit (zuletzt maßgeblich IP und Secure) und bin seit ETS3 Starter, später ETS4 und ETS5 Entwicklungsleiter der ETS Software.
Zu diesem Thread hier bin ich auf Hinweis von Klaus Gütter gekommen und habe seither diverseste Problemfälle im Zusammenhang mit KNX/IP Verbindungen in der ETS5 analysiert (über den KNX Support, Herstelleranfragen bei der KNX Association sowie von Mitgliedern dieses Forums). Ich möchte (und darf) nicht alles im Detail hier öffentlich ausbreiten oder mich im Einzelnen zu den definitiv FALSCHEN, immer wieder geposteten Pauschalverurteilungen der ETS5 äußern. Allerdings möchte ich als Resümee dieses Threads (zumindest meiner Mitarbeit in diesem Thread) folgende Klarstellung zu dem Thema posten:
Für die ETS5 wurde die Komponente, die den Buszugang herstellt (genannt Falcon), komplett neu geschrieben. Das war notwendig, um die gestiegenen Anforderungen an die Buskommunikation für die Unterstützung von KNX-RF sowie das kommende KNX-Secure umsetzen zu können. Die alte Version des Falcons aus der ETS3 und ETS4 basierte auf sehr alten, mittlerweile kaum noch wartbaren, geschweige denn erweiterbaren Code Architekturen (teilweise noch aus der ETS2 v1.3 32Bit Update).
Der neue Falcon wurde von vorne herein modularer und für die Zukunft wartbarer und besser erweiterbar konzipiert. Dies bedeutet im Bereich von KNX/IP Schnittstellen zum Beispiel, dass der neue Falcon die KNX/IP Spezifikation wesentlich „breiter“ (besser) nutzt, als der alte Falcon, der architekturell bedingt hier sehr viele Vereinfachungen und hypothetische Annahmen machen musste, die spätestens mit Einführung von KNX-Secure nicht mehr haltbar gewesen wären. Letztendlich resultiert dies in einem leicht abweichenden Verhalten des neuen ETS5 Falcons gegenüber dem alten ETS3/ETS4 Falcon – selbstverständlich voll innerhalb der KNX/IP Spezifikation (mehr Funktionen und Freiheiten aus ihr nutzend), aber eben anders. Die KNX Hersteller wurden frühzeitig über diesen Umstand informiert und hatten sehr lange schon (teilweise seit Dezember 2012) die Möglichkeit, ihre Geräte gegen den neuen Falcon zu testen. Spätestens seit der ETS5 Beta im Sommer diesen Jahres auch unter Einbeziehung der KNX Installateure.
Leider kristallisieren sich nun erst nach dem öffentlichen Release der ETS5 gewisse neue Fehlerbilder heraus, die mit allen KNX-IP Geräten, die im ETS Testlabor verfügbar sind (diverse Siemens, ABB, Gira, WAGO und Weinzierl), in der Form so nicht auftreten:
a) Offenbar gibt es im Feld PCs bzw. PC Konfigurationen, bei denen die Nachfrage nach der Erlaubnis der ETS5 durch die Firewall kommunizieren zu dürfen, nicht erscheint. Ebenso kann es Netzwerkinfrastruktur (real und virtuell) oder Sicherheitssoftware mit Firewall Verhalten geben, die sich nicht über automatische Ausnahmeregelungen steuern lassen.
b) Die Nutzung von dedizierten UDP Ports für jede Datenverbindung (statt alle Verbindungen und alle Kommunikation über einen einzigen, gemeinsamen UDP Port laufen zu lassen), wird von manchen KNX-IP Geräten nicht fehlerfrei unterstützt.
c) KNX-IP Geräte liefern eine inkorrekt kodierte Seriennummer zurück und erscheinen dadurch nicht in der Liste der automatisch gefundenen KNX-IP Schnittstellen.
d) Es werden verschiedenste, nach Geräteprofil verpflichtende KNX Geräteeigenschaften nicht unterstützt, bzw. deren Fehlen beim Versuch sie auszulesen nicht korrekt gemeldet.
e) Es wird der eigentlich verpflichtende DeviceManagement Verbindungstyp zur Abfrage und Konfiguration von Geräteeigenschaften von der KNX-IP Schnittstelle nicht oder nicht fehlerfrei unterstützt.
Kurzfristig kann (ohne Erfolgsgarantie) es bei Problemen der Kategorie a) oder b) helfen, den NAT Modus für KNX-IP Verbindungen zu aktivieren, da die Kommunikation im NAT Modus prinzipbedingt über einen einzigen UDP Port pro Verbindung läuft und so weniger anfällig für Firewall Probleme ist und im NAT Modus die Kommunikation der ETS5 „ähnlicher“ der der ETS3/ETS4 ist.
Das Firewall Problem unter a) wird hoffentlich mit einem kommenden ETS5 Update gänzlich behoben werden können, da der Falcon sehr wahrscheinlich durch ein spezielles, zusätzliches Telegramm beim Verbindungsaufbau die Datenkommunikation in den üblichen Firewalls freischalten können wird.
Gegen falsch kodierte Seriennummern ist bereits das ETS 5.0.2 Update immun (für KNX-IP Schnittstellen auf TP), wobei für KNX-RF und KNX-Secure Kommunikation die korrekte Handhabung von KNX Seriennummern in der Schnittstelle zwingende Voraussetzung ist/sein wird. Für Fehler der Kategorie b), d) und e) wird ein Firmware Update der Geräte durch den Hersteller kaum vermeidbar sein.
Zur Unterstützung derjenigen Mitglieder, die sich hilfesuchend an dieses Forum wenden, kann ich daher dem Forum nur raten, eine „Kompatibilitätsliste“ zu pflegen, in der KNX-IP Geräte (bei Problemen mit Firmware Version) gelistet werden, die (bei problemloser Netzwerkinfrastruktur) nachweislich mit der ETS5 funktionieren, bzw. bekanntermaßen (noch?) nicht funktionieren.
Bitte haben Sie Verständnis dafür, dass ich als „Vertreter“ der KNX Association aus Rücksicht auf die Hersteller (KNX Mitglieder) hier ohne Rücksprache KEINEN initialen Input für diese Liste liefern (Hersteller anschwärzen) kann.
vielen lieben Dank für die Offenheit über die eigene Person und Funktion sowie über den sachlichen Bericht. Software in dieser Größenordnung ist sehr komplex, insbesondere wenn Geräte aus einem Spektrum über 20 Jahre unterstützt werden müssen.
Eine Frage an die Konnex:
Wenn hier - so wie ich es verstanden habe - einige Hersteller nicht gänzlich konforme Produkte im Feld haben, fragen sich sicher mehrere Leser hier, wie dieses eigentlich vorkommen kann, da doch diese Geräte sicherlich zertifiziert wurden.
In manchen Punkten kann ich allerdings nicht folgen:
- Firewall taugt nicht als Ausrede, wenns schlicht keine gibt
-> Da müssen bzgl. KNXnet/IP echt noch Hausaufgaben gemacht werden!
Weil mit ETS3/4 gings halt..
Einen Re-Write kann ich iSv KNXnetIP Secure, RF durchaus nachvollziehen, aber das "alte Zeug" muss trotzdem gehen. Auch wenn der Falke bisher keine 4h Busmonitor geschafft hat..
Vielleicht auch durchaus beim eibd - dafür erkläre ich mich dann erstmal für zuständig! - aber dafür muss man wissen, was der ETS5 daran nicht passt, wo es früher ok war..
Nicht umgekehrt, oder ?
wie dieses eigentlich vorkommen kann, da doch diese Geräte sicherlich zertifiziert wurden.
1) Nicht alle betroffenen Geräte sind zertifiziert oder sie haben sich den KNX-IP Teil nicht mitzertifizieren lassen.
2) Nur, weil es mit einer bestimmten ETS Version funktioniert, muss deshalb die Spezifikation nicht komplett korrekt umgesetzt sein.
3) Probleme, die nur in speziellen Konstellationen auftreten, kann auch eine Zertifizierung nicht im Vorfeld prüfen. Ganz vorsichtig gesagt: Zertifizierung ersetzt keine Qualitätssicherung.
Zur Unterstützung derjenigen Mitglieder, die sich hilfesuchend an dieses Forum wenden, kann ich daher dem Forum nur raten, eine „Kompatibilitätsliste“ zu pflegen, in der KNX-IP Geräte (bei Problemen mit Firmware Version) gelistet werden, die (bei problemloser Netzwerkinfrastruktur) nachweislich mit der ETS5 funktionieren, bzw. bekanntermaßen (noch?) nicht funktionieren.
Bitte haben Sie Verständnis dafür, dass ich als „Vertreter“ der KNX Association aus Rücksicht auf die Hersteller (KNX Mitglieder) hier ohne Rücksprache KEINEN initialen Input für diese Liste liefern (Hersteller anschwärzen) kann.
Sollte es wirklich die Aufgabe eines Forums sein, Kompatibilitätslisten führen zu müssen?
Wäre es nicht richtiger, dass die KNX.org zumindest eine Positivliste aus dem Entwicklungslabor bereitstellt (ala bislang laborgetestet), da offizielle Anlaufstelle?
Sollte es wirklich die Aufgabe eines Forums sein, Kompatibilitätslisten führen zu müssen?
Nö, kann es nicht sein!
Wenn es mit einer neuen ETS und einem davor zertifizierten Produkt schlicht nicht geht, hat entweder der Zertifizierungsprozess versagt oder die Tests der neuen Software auf zwingend notwendige Abwärtskompatibilität.
Sage ich als reiner Anwender, ich will nach wie vor KNX mit seinen Hauptvorteilen promoten: ein wesentlicher davon ist, das man keine "Kompatibilitätsliste" verschiedener Hersteller braucht!!
Edit/PS: Ja, ich gebe zu, ich teste primär mit "nicht-08/15-Konstellationen" also z.B. unterschiedlichen Subnetzen zwischen ETS und KNXnet/IP Schnittstelle (hier noch alles ohne FW!) -aber sorry, das ist normales, tägliches Business bei TCP/IP seit 1973/1983..
Schade, ich kenne andere Foren, deren Selbstverständnis es sehr wohl ist, hilfesuchende Mitglieder zu unterstützen. Und eine solche Liste mit Erfahrungen aus Praxis wäre so eine Unterstützung und in einem Anwenderforum durchaus gut aufgehoben. Wenn man sich hier allerdings eher als Trollplattform sieht und der Meinung ist, es sei angebrachter, statt jemandem mit einem Problem zu helfen, lieber sofort OT "Die ETS5 ist kaputt!", "Die KNX hat das noch nie hinbekommen!" und "Hängt sie höher!" hinterherzurufen, ist das nur ein weiteres Indiz dafür, dass dieses Forum vielleicht nicht der richtige Platz ist, konstruktiv den Kontakt zwischen der KNX und Endanwendern zu intensivieren.
ein wesentlicher davon ist, das man keine "Kompatibilitätsliste" verschiedener Hersteller braucht!!
Damit haben Sie absolut Recht und Sie wären erstaunt, wie viel Code der ETS aus Workarounds für bestimmte Probleme einzelner Hersteller besteht, um eben genau diesem Anspruch gerecht zu werden. Wir alle machen Fehler! Aber es gibt trotz aller Bereitschaft zu Abwärtskompatibilität immer wieder Punkte, an denen diese nicht uneingeschränkt für alle problematischen Geräte der Vergangenheit gewährleistet werden kann, um eine notwendige und richtige Weiterentwicklung des KNX nicht zu blockieren (ich erinnere hier z.B. mal an die Unkenrufe 2004 gegen die ETS3 und den Aufschrei, weil diese bestimmte Produkte mit 16Bit ETS2 Plug-Ins nicht mehr unterstützte). Ein kleinster gemeinsamer Nenner aller, auch fehlerhafter Geräte aus den letzten 25 Jahren von mehr als 200 Herstellern wäre irgendwo bei null. Und ohne in Software-Theorie abzuschweifen, kann ich nur noch einmal wiederholen: eine Zertifizierung (Blackbox Test) alleine KANN nicht alle Fehler finden!
Aber nach 12 Seiten Diskussion dreht sich das Thema jetzt nur noch im Kreis. Deshalb werde ich mich an dieser Stelle verabschieden. Fakt ist: Es gibt Geräte da draußen, die kommen mit der anderen Kommunikationsweise der ETS5 nicht zurecht. Und das ist kein Problem der ETS, sondern eines der Hersteller. Hier wird es in Bälde Firmware Updates geben und dann wird diese aufgeregte Diskussion ganz schnell wieder vergessen sein...
Schade, ich kenne andere Foren, deren Selbstverständnis es sehr wohl ist, hilfesuchende Mitglieder zu unterstützen. [......], dass dieses Forum vielleicht nicht der richtige Platz ist, konstruktiv den Kontakt zwischen der KNX und Endanwendern zu intensivieren.
Ich denke (ne, bin überzeugt!) dass hier sehr wohl das Selbstverständnis herrscht, dass wir anderen helfen wollen. Und natürlich wäre so ein Liste dafür nicht schlecht. Die "verhaltene" Resonanz kommt m. E. einzig und allein auf Grund der Tatsache, dass es zum einen einfach noch sehr viel Probleme mit der ETS5 gibt (egal wer oder was dran Schuld ist, aber das erzeugt einfach Frust der mental mit der ETS5 gekoppelt ist) und zum anderen weil Du (Sie) als "KNX-Verantwortlicher" wahrgenommen wirst. Und wenn von offizieller Seite dieser Rat kommt, dann provoziert das natürlich die Reaktion "ist doch aber eure Aufgabe", auch wenn Du es glaube ich hier nicht so gemeint hast.
Grundsätzlich fände ich es daher richtig und wichtig und gut, wenn wir so eine Liste pflegen, aber ich würde es andererseits auch als erbärmliches Armutszeugnis werten, wenn sich eine Konnex hin stellt und sagen würde "Wir wissen nicht, welche Schnittstellen mit der ETS5 funktionieren, versucht es einfach mal".
Ich denke in diesem Sinn wird Dein Vorschlag teilweise verstanden und daher die Reaktionen. Ich hab verstanden, dass Du da gern was von offizieller Seite beisteuern würdest, es aber nicht so ohne weiteres darfst, weil damit die Konnex auch den ein oder anderen Hersteller in schlechtes Licht rücken würde. Ein Dilemma!
Und ohne in Software-Theorie abzuschweifen, kann ich nur noch einmal wiederholen: eine Zertifizierung (Blackbox Test) alleine KANN nicht alle Fehler finden!
Das ist wohl leider wahr, wenngleich man auch akzeptieren muss, das man als Anweder erwartet, dass zertifizierte Produkte auch erwartungsgemäß funktionieren.
Ich würde mich sehr freuen, wenn es trotz der teilweise nicht ganz sachlichen Diskussion hier weiter ein reger Kontakt besteht. Ich bin mir sicher, dass hier im Forum ein ganz erhebliches KNX-Know-how und ganz viel tägliches Praxis vertreten ist und jeder Hersteller in diesem Sektor von einem Feedback hier nur profitieren kann!
....und versuchen Sie nicht erst anhand der Farbe der Stichflamme zu erkennen, was Sie falsch gemacht haben!
Und eine solche Liste mit Erfahrungen aus Praxis wäre so eine Unterstützung und in einem Anwenderforum durchaus gut aufgehoben.
Wir sind hier nicht im ich-bastel-mir-ein-Wurschtelselbstbaubussystem-Forum, sondern ein Forum, das zur Basis einen weltweit zertifizierten Standard hat, mit zertifizierter HW u. einer zentral verwalteten, weltweit gleichen Standard-IB-SW.
Wird für so eine "Profi"-SW ca. 1000,-- Euro aufgerufen, dann wird sie auch aus entsprechendem Blickwinkel betrachtet.
Fakt ist: Es gibt Geräte da draußen, die kommen mit der anderen Kommunikationsweise der ETS5 nicht zurecht. Und das ist kein Problem der ETS, sondern eines der Hersteller.
Mag aus techn. Sicht vlt. richtig sein, aber
Was soll man seinen Kunden erzählen, wenn diese sich eine ETS neu beschaffen u. die Anlage nach KNX-Standard mit seiner neuen ETS dann nicht bedienbar ist?
Wer steht für den finanziellen Aufwand der SI gerade (Fehlersuche, Updates, Fahrkosten,Kundengespräche,...)?
Wer muß die Kunden besänftigten, versuchen Aufklärung zu treiben?
Wer muß seinem AG darlegen, warum eine Forderung im LV (neueste ETS) bislang nicht erfüllbar wäre und man derzeit besser Abstand davon nimmt u. das ohne offizielles Statement seitens KNX.org?
Derzeitiger Fakt ist, daß man grosse Gefahr läuft, bei Einsatz der ETS5 beim Kunden auf die Nase zu fallen u. sich als zahlender Betatester betrachtet sehen kann.
3) Probleme, die nur in speziellen Konstellationen auftreten, kann auch eine Zertifizierung nicht im Vorfeld prüfen. Ganz vorsichtig gesagt: Zertifizierung ersetzt keine Qualitätssicherung.
Das ist aber durchaus meine Erwartunghaltung das Zertifizierte Devices auch nach einem Update der ETS Funktionieren. Ich wüste nicht für was sonst eine Zertifizierung gut sein sollte.
Ich melde mich als einer der Betroffenen. Ich baue zur Zeit ein kleines Mehrfamilienhaus und ich habe mich entschlossen KNX-Technik einzusetzen (im Übrigen zusammen mit DALI und 1-WIRE). Viele KNX-Produkte sind schon gekauft (diverse Aktoren, Schalter, Heizungsaktoren, Jalousieaktoren, Displays, Gateways...
Nun habe ich mich Anfang letzte Woche einmal hingesetz und wollte die ersten Anfänge mit einer gerade nagelneuen Lite-Lizenz starten. Ich habe drei lange Nächte damit verbracht alles Mögliche auszuprobieren. Ich habe in der Regel keine zwei Linken Hände bei technischen Themen, bin aber auch kein Experte und habe die ganze Zeit gedacht ich hätte eine Kleinigkeit übersehen. In der dritten Nacht habe ich dann angefangen im Netz nach Unterstützung zu suchen und bin recht schnell auf dieses Forum gestoßen.
DANKE an alle, die hier mit gepostet haben, somit weiß ich zumindest schon einmal, dass ich nichts falsch gemacht habe.
ABER: Was soll ich jetzt machen. Wie nehme ich mein Projekt in Betrieb? Bis vor kurzen gab es noch Angebote der Konnex für die ETS4 (wer die kauft, bekommt kostenlos die Version 5 ausgeliefert...oder so ähnlich). Jetzt habe ich soetwas nicht mehr gefunden. an eine ETS3-Version komme ich noch ran, aber ich habe Produkte (wie z.B. Inzennio Z41) die laut Hersteller erst ab ETS4 nutzbar sind.
Ich habe eigentlich beabsichtigt mein Wiregate als IP - KNX Gateway für die ETS-Programmierung zu nutzen. So wie ich diesen Thread verstanden habe, ist es eher unwahrscheinlich, dass diese Konstellation in absehbarer Zeit zum sicheren Betrieb mit der ETS5 führt. Mir würde es daher sehr helfen, wenn ich wüsste welche Hardwarekonstellation heute zum Erfolg führen würde. Ohne NAT-Spielerein und so weiter, ich möchte meine Zeit nicht in Workarrounds stecken müssen.
Mein Windows hat mich bei der Installation von ETS5 auch nicht nach einer Freigabe für die Firewall gefragt...
Von der Konnex würde ich mir aktuell Folgendes wünschen:
Solange der Konnex bekannt ist, dass (viele) Hersteller noch Probleme mit der ETS 5 haben, liefert den Kunden doch jeweils Version 4 und 5 aus. Das kostet Euch nicht viel (Cent bis wenige €) und wird Euch sehr gedankt bzw. verringert den Ärger. Das gilt für alle Produkte: die Demo, Lite und Vollversion. Ich zum Beispiel wollte mit Lite erst einmal testen und spielen und mir dann später die Vollversion kaufen (da ich Privatperson bin und diese nicht absetzen kann habe ich stark auf eine Sammelbestellung in der nächsten Zeit gehofft).
Eine Liste von Geräten, mit der in Laborumgebung alles geklappt hat. Damit schwärzt man keineswegs Jemanden an, da ja nicht geschrieben wird, wer es nicht kann. Aber die Motivation der Hersteller, die noch nachziehen müssten, steigt ganz sicher. Wir hier im Forum können sicherlich noch zusätzlich eine Liste führen, mit wem es nicht geht. Elwedritsche hat ja selber dargestellt wie groß der Aufwand wegen der schwarzen Schafe im Feld auch für die Konnex ist.
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Kommentar