Die ETS muss weg

[escoba]

Guten Morgen, guten Tag, guten Abend, zusammen.

Ich bin heute morgen aufgewacht und habe mir vorgenommen endlich ein Thema anzusprechen das mich schon lange beschäftigt und hoffentlich eine Entwicklung loszutreten. Oder natürlich mich überzeugen zu lassen, dass ich falsch liege. Daher auch der provokante Titel, dass hoffentlich viele mal drüber lesen . Aber es geht nicht ausschließlich um die ETS.

Um jedoch einen Einstieg zu bekommen möchte ich erstmal damit beginnen, dass der KNX Bus an sich ja komplett dezentral aufgebaut ist, mit allen Vor- und Nachteilen. Wobei für mich persönlich die Vorteile überwiegen. Hier ist jedoch ein Bruch festzustellen, da die ETS ganz eindeutig eine Zentrale Instanz ist, die sich nicht dezentral umsetzen lässt. Auch ist der KNX Bus an sich ein offener Standard, nur die ETS nicht, der nächste Bruch also. Auch ist KNX im elektrotechnischen Sinne offene dokumentiert und man kann die Spezifikationen lesen, die ETS allerdings nicht, also erneut das Dilemma.

Aber nun gut, darauf möchte ich nicht herum reiten, mir geht es vielmehr um die resultierenden Einschränkungen und Probleme. Es mangelt mir also nicht an Vertrauen, dass zB. die ETS-Entwickler keine Hintertür für den BND oder die NSA eingebaut haben - zumindest nicht wissentlich.

Was ich an Problemen sehe, in Stichpunkten die teilweise zusammen hängen:
- geschlossenes System
- kein Wettbewerb
- keine Dezentralität
- Single Point of Failure
- Platformabhängig
- Donglepflicht (stimmt das für ETS5??)
- langsame Entwicklung
- "ETS as a Service" (also Cloud basiert) nicht möglich
- nicht für Endkunden gedacht und geeignet
- kostenpflichtig (veraltetes Denken 1 Stück ETS kostet X€)

Wünschenswert wäre für mich, inspiriert von Webtechnologien und Webfirmen, ein eher Protokoll basierter Ansatz. Also die KNX Dachorganisation entwickelt APIs die in mehreren Programmiersprachen quelloffen verfügbar sind. Hier denke ich als Vorbild zB an Dropbox oder auch die Google Apps und viele viele Andere. Es geht darum, dass die Kompatibilität und Stabilität durch wohldefinierte Schnittstellen erreicht wird, nicht durch Abschottung. (Aber natürlich auch durch eine kostenpflichtige Zertifizierung)

Das ganze könnte eine Entwicklung lostreten mit hoffentlich folgenden Ergebnissen (nur mal Ansatzweise):
- dezentrale Strukturen zur Inbetriebnahme von KNX Installationen
- zB Homeserver oder eibPort kann auch Inbetriebnahme anbieten oder Geräte dafür entwickeln
- web basierte Zugänge (Vorteil VPN, weltweiter Zugang, skalierbare Struktur)
- Backups können von Geräteherstellern angeboten werden (natürlich verschlüsselt und direkt in die Cloud)
- Anwendungen für Endanwender (z.B. wie schnell dimmt ein Licht, hat es soft-off/on oder auch Logikfunktionen, ...)
- standards für Visualisierungen, standards für Gruppenaddressenstrukturen

Sprich aus meiner Sicht kann der Bus im Vergleich zur Konkurrenz mittel-/langfristig nur verlieren da die Entwicklung zu langsam ist.
Warum wird immer wieder gesagt, System XYZ ist ja nur im Nachrüstmarkt, und nicht gefragt: Warum ist KNX im Nachrüstmarkt so miserabel?
Warum muss man im Jahre 2014 noch eine physische Taste drücken um eine physikalische Adresse zu programmieren?
Warum muss man erstmal einen Personal Computer kaufen, Windows installieren, Abhängigkeiten installieren, ETS installieren, ETS lizenzieren, Projekt anlegen, Projekt importieren, etc (ihr seht was ich meine) um das Verhalten einer einzigen Leuchte zu verändern - weil ein Kumpel der KNX hat sich das wünscht.

Im KNX Symposium in Frankfurt (2012 denke ich) ging es z.B. um Smart Grid, um das "Internet of Things", Machine zu Maschine Kommunikation - Aber in der Realität gibt es z.B. den ultimativen ETS4 Schnellkurs bei dem einem erklärt wird wie man einen zweiten Monitor an sein System anschließt oder wie Copy&Paste funktioniert (Achtung Übertreibung). Nach dem Motto lasst uns den Weltraum besiedeln aber ok wir brauchen dafür erstmal einen Hochofen.

(vielen Dank trotzdem eibmeier für die unvorstellbare Arbeit - ich habe darin Einiges gelernt. Für mich wäre dass jedoch möglich auf vielleicht 10 Seiten einzudampfen.)

So, ich glaube als Start sollte das ganze ausreichen

Ich habe im Übrigen leider nicht die Weisheit mit Löffeln gefressen und mit Sicherheit habe ich auch nicht auf alles eine Antwort. Ich sehe nur die immer schneller werdende Entwicklung was Smarthome betrifft und dass der Urvater des ganzen immer mehr außen vor bleibt - und das hat Ursachen, die gilt es zu finden und zu beseitigen wenn KNX in Zukunft überleben soll.

Einen schönen Tag, Morgen, Nacht, Mittag,
Marius

[GLT]

Ehrlich?

Du bist weder der Erste, noch wirst Du der Letzte sein, der so einen Käse verzapft.

[MarkusS]

Na, dann mal los.

Erlaube mir aber bitte die Frage ob Du nicht auch das Gefühl hast dass es irgendwie ambivalent ist, einerseits offen über irgendwelche Regierungsbackdoors in der Software zu spekulieren und das andererseits über eine Cloud-basierende Software besser machen zu wollen.

Dir ist auch klar dass KNX & Co. über keinerlei Sicherheitsmechanismen verfügen so dass eine Backdoor in der ETS ungefähr so sinnvoll ist wie ein Euter an einem Ochsen?

Die Problematik der Plugins hast Du verstanden und dafür eine Lösung?

[dreamy1]

Wenn ich Cloud und Google Apps lese, wird mir ehrlich gesagt schlecht.

Ich bin sehr froh, dass eine ETS gibt - denn ich kann sicher sein, dass ich damit meine Geräte 100% erfolgreich und mit der Einarbeitung in eine einzige Software programmiert bekomme.

Bedenke auch, dass es nicht nur DIY'ler gibt, sondern auch gewerbliche Anwender (und das dürfte der überwiegende Teil sein), die eine gewisse Sicherheit bei der IBN und Betreuung Ihrer Projekte benötigen.

Einen Bruch mit der dezentralen KNX-Philosophie sehe ich nicht, wie bitte soll denn eine individuell festzulegende Eigenschaft oder Logik ohne ein einzelnes Hardware- oder Softwareelement mit Funktionsgarantie in den Bus eingebracht werden?

Ich bin ja selbst begeisterter Bastler und Nutzer modernster Technik, aber es gibt auch Grenzen bei der Sinnhaftigkeit, alles im Detail jedem Endanwender zugänglich zu machen. Apps und Clouds als Add-on sind ja ok, aber KNX hat eine andere, professionellere Intention.

Für alle anderen, u.a. auch die Spielkinder, gibts Homematic, FS20 & Co. - da kann da auch an APIs etc. herumgedoktert werden. Das ist dann aber privater und nicht gewerblicher Bereich, wo andere Gesetzmäßigkeiten greifen.

[IBFS]

@escoba
Ich stimme dir zu, das mich auch die instabile Software 4.xx nervt, daher
verwende ich nach wie vor die V3.0f. Außerdem wünschte man sich,
dass es eine schlauere Preispolitik geben würde.

Wenn auf den Preis jedes Aktor/Sensors pauschal 5-10€ aufgeschlagen
würden, könnte man die Software für eine Schutzgebühr von 50€
verkaufen, was den Verbreitungsgrad erhöhen würde.

Dazu dann wirklich intelligente CUT und MERGE - Funktionen, sodass
man mit einem Teilprojekt schnell einzelne Teilnehmer bearbeiten kann,
bzw. der Endkunde, der aber aus Regress-gründen in der Garantiezeit
noch nicht alles können sollte, usw.

Ansonsten bin gegen jeden Cloud-Käse. Stelle dir mal vor, ein Autoupdate
auf einen Aktor läuft schief. Da ist dann kein Licht mehr etc.

KNX ist wie SPS. Wenn es einmal läuft - im EFH - dann Finger weg und Ruhe.
Man muss nicht ständig immer was verändern wollen müssen.
Manche hier haben das KNX als einzigen Lebensinhalt. Geht lieber in den
Biergarten oder Wandern

Wer basteln will kaufe sich einen Fischerbaukasten, da spielt es keine Rolle,
wenn früh morgens der Roboter streikt.

Grüße

Frank

[escoba]

@MarkusS
Nun ja ich wollte nur sagen dass ich keine Zweifel an der Integrität der ETS Entwickler habe - die Sicherheitsbedenken bzgl. Backdoors beziehen sich nicht auf die Cloud alleine. Eine Cloud kann auch sein dass eine Firme ein kleines Rechenzentrum im Keller hat oder eigene Hardware in einem richten RZ vorhält.
Und Cloud-basierte ETS würde ich nur als Option in Betracht ziehen. Ein Inbetriebnahme-Server im REG Format der webbasiert arbeitet ist ja erst einmal nur im lokalen Netzwerk erreichbar (mit Vorbehalten bzgl. Backdoors, aber die kann es überall geben).
Ja, KNX ist unverschlüsselt und ohne Authentifizierung, doch ein getrennter Bus so lange man keine Ethernetschnittstelle im Bus hat. Insofern wäre hier doch eine Backdoor sinnvoll für Angreifer. Wobei ich da mehr an die komplette Softwarestruktur des Objekts gedacht habe, also dass ein Angreifer sich Informationen zieht wie die GAs belegt sind zB.

@dreamy1
schlecht wird mir nicht, aber ich denke ich weiß was du meinst. Das ganze ist natürlich alles andere als unproblematisch. Aber auch der Nutzen vernetztes Systeme ist beachtlich.
Das Geräte bzw. Tools/Software 100% funktionieren sollte für alle professionelle Lösungen Vorraussetzung sein. Ich würde hier einhaken, dass die Einarbeitszeit in eine Software von Dir so betont wird zeigt eher das Problem.

Ich denke gewerbliche- und private Kunden oder generell Alle haben als Anforderung möglichst absolute Sicherheit (absolute Sicherheit kann es nicht geben). Aber z.B. die Betreuung wäre um einiges zuverlässiger und sicherer wenn man sich "nur" ins Firmennetz wählt per VPN und dann die Weboberfläche des lokalen System verwendet.
Klar, ohne ein Werkzeug geht es garnicht, bzw. dann wäre es ja 100% Plug-and-Play ohne individuelle Punkte. Wäre jedoch wieder das theoretische REG Gerät zwei-fach im Objekt vorhanden, dass sich selbst über eine parallele Verbindung (z.B. ethernet) permanent synchronisiert könnte jederzeit eins der beiden ausfallen - damit wäre man ein Stück näher an der erwähnten Funktionsgarantie, aber eine Garantie gibts ja momentan auch nicht und wirds da vermutlich auch nicht geben.

Ja, alles dem Endanwender möchte ich auch nicht zugänglich machen. Ich sehe keinen Widerspruch zwischen professioneller Intention und leichter Bedienung und Zugänglichkeit - im Gegenteil.
An den APIs darf ja keiner "rumdoktorn" - die dienen ja nur als Sprungbrett für Geräte und Softwarehersteller, dass man also auf einer stabilen Basis aufbauen kann - sprich als Bibliothek sozusagen. Oder um vielleicht ein hinkendes Bild zu bemühen, Nokia entwickelt ja auch nicht selbst die Hardware eines Lumia Handys komplett selbst sondern kauft entsprechend erstmal Komponenten zu (Prozessoren, Mobilfunkmodem, etc...)

@IBFS
Gefühlsmäßig hätte ich gesagt 5-10€ ist etwas zu viel, aber generell könnte man doch eine Umlage machen, dass ETS komplett kostenlos ist für Entwickler und Anwender. Die Hardware bezahlt die Software, das ist oft so und könnte hier auch super funktionieren denke ich. Wozu die Schutzgebühr, vor wem willst du denn was schützen?

Ja so ein Autoupdate Szenario darf natürlich niemals passieren. Wie gesagt, der REG Inbetriebnahme Server wäre ja lokal im Objekt und würde dann das Update machen, also wie bisher letztendlich.

Ein statisches KNX System, dass einmal eingerichtet ist und dann so bleibt, fühlt sich für mich aber wenig smart an. Ich will doch eben dann neue Geräte die angeschafft werden integrieren, aber für wenig Geld integrieren lassen. Auch mein Handy hält nicht ewig, der Fernseher, die Spülmaschine etc. Ich würde eher versuchen möglichst viel Basisfunktionalität, ich sag mal "Licht aus, Licht an" irgendwie per Autokonfiguration erledigen zu lassen. Anpassungen per Hand kann man ja anschließend machen.

@Allgemein
Ich habe das Gefühl ich habe mich mit dem Begriff Cloud unglücklich ausgedrückt. In dem Sinne ist das ganze für mich lediglich ein "sicherer Hafen" an den Software abgelegt werden kann. Ob das jetzt ein Rechenzentrum in Honolulu ist oder ein Server mit ordentlichem RAID im Keller spielt erstmal keine Rolle. Wenn das ganze ein Dienstleister wie Dropbox, Telekom, Strato, Google, ... ist, muss eben alles verschlüsselt werden bevor es das Objekt verlässt. Es gibt sehr wohl Verfahren (evtl. mit oder ohne Backdoor) die das gewährleisten insofern man einen guten Schlüssel wählt. Würde man jedoch zwei so gedankliche Server in einem Objekt haben die synchron sind, könnte man sich die Cloud auch komplett sparen. Nur den Fall eines Totalschadens durch ein Brand oder so muss man dann noch berücksichtigen.

Backdoors kann es überall geben. Überall.


Vielen Dank für die Antworten,
Marius

[dreamy1]

Eines wäre auch zu bedenken:

An vielen Orten steht zum Zeitpunkt einer Erstinbetriebnahme (und manchmal auch Wochen danach) noch gar kein Internet zur Verfügung. Und von dessen Vorhandensein, Stabilität und Datenrate würde ich keine Inbetriebnahme abhängig machen wollen.

[Axel]

Ich finde es in Ordnung ein einheitliches, herstellerübergreifendes Tool zu haben wo ich über Jahre hinweg vernünftig arbeiten kann.

Man bedenke. Anlagen aus den 90er Jahren können noch immer frei und bequem erweitert werden. Auch der Produkt Tausch ist möglich. So soll es 2020 und 2030 auch sein :-)

Zudem sollte das nerven System des Gebäude autark sein und Internet Fähigkeit ontop.

[kiwifan]

Hallo!

Ich gebe dem Treadstarter Marius (Escoba) in den meisten Punkten recht.
Ein firmenübergreifendes Produkt anzupreisen, wo die Geräte zu 90% von einem Hersteller für die anderen gebaut werden, ist meiner Meinung sogar ein Fall für das Kartellamt.
Nebenbei bemerkt benutze ich die ETS seit 9 Jahren und habe seither keine entscheidende Entwicklung mehr feststellen können.

Kritische Meinungen müssen erlaubt und sogar erwünscht sein.

Mit freundlichen Grüßen
Hans

[Axel]

wo die Geräte zu 90% von einem Hersteller für die anderen gebaut werden, ist meiner Meinung sogar ein Fall für das Kartellamt.

Das ist schon sehr lange nicht mehr so! Applikationen und Hardware unterscheiden sich mittlerweile sehr stark. Ausnahmen sind Gruppierungen wie Insta, Hager oder ABB Group. Da hat jeder seine eigene Entwicklung und Fertigung.

Neuentwicklungen die praktisch sind:
- Jeder kann für die ETS eigene APPs entwickeln. Das SDK ist zugänglich.
- Produkt ersetzen erleichtert den Austausch enorm. Sogar wenn eine falsche Applikation projektiert wurde lassen sich Geräte massenweise austauschen
- Anbindung an CAD Software
- Produktkatalog Online (fehlen aber noch viele Hersteller)
- Datenzustandsanzeige der Gruppenadressen
- Erweitertes kopieren lassen sich Abbilder von Räumen effizient erstellen
- Parameter von identischen Geräten auf einmal änderbar
- Funktions- und Produktvorlagen
- Objektbeschreibung direkt aus der Gruppenadresse
- Springen direkt durch rechtsklick auf Gerät/Gruppe/etc.
- und so vieles mehr


Meiner Meinung nach hat sich ziemlich viel im Bereich der Arbeitserleichterung und Effizienzsteigerung im Gegensatz zur ETS2/3 getan.

[MatthiasS]

wo die Geräte zu 90% von einem Hersteller für die anderen gebaut werden, ist meiner Meinung sogar ein Fall für das Kartellamt.

Selten so einen Unfug gelesen.

Jeder kann Geräte für KNX entwickeln. Und es gibt sogar "ETS-Alternativen", auch da ist jeder frei, das zu tun. Der Standard ist verfügbar (ISO-Standard!).

Beispiele:

BASys 2003 - Softwaresystem für Gebäudeautomation
http://www.tetra-software.de/tess/d_automation.htm

[kiwifan]

Nur ein Frage.

Wo ist zB. der Unterschied zwischen Berker IOS und Hager DOMOVEA?

Beides (Server) wird von Hager hergestellt. Berker hat nur veraltete Software-Versionen. Vielleicht sollte Berker zumindest die Herstellerangaben richtigstellen und versuchen Software zu aktualisieren.

Lasse mich gerne eines Besseren belehren.

MfG
Hans

[SnowMaKeR]

Kein Unterschied.
Berker gehört zu Haager, und?

Ein Gerät von sagen wir mal 40.000.

[Gaston]

Ehrlich jetzt ?

Wir brauchen also 2 Internet Router an 2 verschiedenen ISPs über verschiedene Leitungsstrecken. All dies von zwei verschiedenen, kabeltechnisch getrennte, Stromlieferanten gepowerd (Upps! SPOF auch für den Bus) , usw. Nur um mit der ETS, die man nur zur Inbetriebnahme benötigt, über die Cloud kein single Point of failure zu haben ? Und da diskutieren wir noch dass die ETS zu teuer wäre ?

Die Cloud eliminiert doch alleine keine SPOF, verlagert diese nur.

Was richtig ist, ist dass die ETS mit dem Druck aus dem Markt zu kämpfen hat das System so geschlossen wie möglich zu halten. Die EIBA (damals) hat (im Nachhinein) einen cleveren Schachzug (für die EIBA/KNX nicht für uns) gemacht in dem sie die ETS nicht Teil des Standards gemacht hat.

Als Nebeneffekt hiervon ist das SDK, das die ETS "öffnet", nicht öffentlich (naja, SDK gibt es schon aber man kann ohne spezielle Lizenz nix damit tun). Die KNX unterschätzt immer noch die Stärke einer Community. Aber würde man das öffentlich machen, wer würde dann noch eine kleine simple App für 90€ kaufen ?

Eine Finanzierung über eine Abgabe bei den Geräten ist somit aber auch ausgeschlossen.

Gruss,
Gaston

[Gamma]

Tut mir wirklich leid,
aber der SINN dieses Threads erschliesst sich mir leider nicht.