21-03-2015, 12:03:59
(Dieser Beitrag wurde zuletzt bearbeitet: 21-03-2015, 19:34:32 von THellweg.)
Ja, der Weg ist schon beschritten aber wie holprig war er denn bis jetzt?
Nehmen wir die Beispiele von Hans, also Miele, Bosch-Buderus, Samsung und Philips-HUE, bezogen auf RWE-SH.
Miele:
Man braucht in jedem Fall ein "Miele-Gateway". Das wäre noch OK, wenn man für verschiedene Miele Haushaltsgeräte mit einem Gateway auskommen würde. Da man aber anscheinend bei Miele noch in der Findungsphase ist, gibt es jetzt schon mehrere Gateway-Varianten (powerline, Ethernet, etc), die jeweils nur zu bestimmten Maschinentypen/Generationen kompatibel sind. Wer also den teuren Wäschetrockner ein halbes Jahr nach der teuren Waschmaschine kauft, bekommt u.U. keine Wäschetrockner, der mit dem gleichen Gateway wie die vorher gekaufte smarte Waschmaschine betrieben werden kann.
Ein herstellerübergreifender Betrieb von "weisse Ware" Geräten anderer Firmen ist momentan bei keinem Anbieter solcher Geräte vorgesehen, denn jeder Hersteller kocht hier vorerst sein eigenes Süppchen.
Meine Note dafür: 5+
Bosch-Buderus:
Man braucht sich nur hier im Forum umzusehen. Kompatibel sind nur bestimmte Kessel und auch diese nur in Kombination mit einer bestimmten Steuereinheit und einer bestimmten Bedieneinheit. Darauf wird zum Glück deutlich hingewiesen und auch viele Heizungsfachbetriebe haben inzwischen entsprechendes Know-How aufgebaut. Die Integration in RWE-SH, insbesondere das "pairing", ist ein bischen "fummelig" aber danach funktioniert eigentlich alles ganz gut. Ein kleiner Wermutstropfen ist allerdings, dass Bosch-Buderus nur einen Pairingpartner erlaubt, d.h. die hauseigene Bosch-Buderus-App ist nach dem "pairing" mit dem RWE-SH Addin nicht mehr nutzbar. Der Highlander lässt grüßen - Es kann nur einen geben!
Bei Problemen mit der Steuerung über das Addin wird angeblich, so war es zumindest hier im Forum zu lesen, der schwarze Peter zwischen RWE und Bosch-Buderus hin und her geschoben.
Ich kann das allerdings nicht bestätigen, denn die Kooperation mit Bosch-Buderus ist gut und man ist auf beiden Seiten an Verbesserungen (z.B. das Bugfixing der Anzeige von "?") interessiert, auch wenn deren Umsetzung manchmal eine Weile dauert.
Meine Note dafür: 2-
Samsung-Kamera:
Nach der Beseitigung einiger kleiner Startschwierigkeiten mit der Aufzeichnung/Speicherung, gibt es hier aktuell keine Probleme. Da die Kameras ohne irgendwelche Gateways auskommen und hier das standardisierte IP-Protokoll verwendet wird, sind keine besonderen Probleme in der Zukunft zu erwarten. Neue Kameramodelle werden entweder kompatibel zu dem RWE-SH Addin sein oder nicht und dass Addin wird sicherlich entsprechend weiterentwickelt um zukünftige Kameras zu unterstützen. Vielleicht wird es auch irgendwann eine Premiumversion davon geben, mit welcher z.B. die Kamerasensoren (Geräusch/Bewegung) genutzt werden können. Dank IP-Protokoll wäre das nur eine Frage des Entwicklungsaufwands (kosten/nutzen).
Meine Note dafür: 2+
Philips-HUE:
Das beste Beispiel kommt zum Schluss, denn die HUE Integration hat gezeigt wo die Stolpersteine sind und sie tut es immer noch.
Die sogenannte HUE-Bridge "spricht" zwar auch IP, verwendet zur Steuerung der Lampen aber das Zigbee Funkprotokoll. So weit so gut - warum auch nicht? Kritiker haben öfters angemerkt, dass es toll wäre, wenn der SHC selber Zigbee "sprechen" würde, denn dann würde man die HUE-Bridge ja nicht brauchen. Das ist aber zu kurz gedacht, denn damit würde die parallele Nutzung diverser anderer Apps für HUE nicht mehr funktionieren. Die Art und Weise wie man HUE in RWE-SH integriert hat ist der beste Weg, denn man lässt die "Philips-Welt" unangetastet und ohne deren Funktionen in SH nachzubauen und nutzt statt dessen deren API zur Ansteuerung.
Das funktioniert gut aber nur solange wie die API, seitens Philips, nicht unangekündigt modifiziert wird. Genau dieser Fall ist aber vor einiger Zeit einmal eingetreten und die Steuerung der HUE Lampen war mit RWE-SH dann plötzlich nicht mehr möglich. Nachdem das Problem dann gefunden war, musste das RWE-SH HUE-Addin kurzfristig und schnellstmöglich angepasst werden.
Ärgerlich für die Anwender des RWE-SH HUE-Addins und besonders ärgerlich für RWE, denn RWE musste nicht nur die, für das ungeplante und kurzfristige Fixing anfallenden, Entwicklungsarbeiten/kosten stemmen, RWE bekam zum Dank auch noch den gesamten "Shitstorm" der verärgerten HUE-Anwender zu spüren. So etwas sollte nicht passieren.
Des Weiteren sind in der "Philips-HUE-Welt" ein paar Tücken vorhanden, die den Nutzern des RWE-SH-Addins das Leben schwer machen. Soweit ich weiss gibt es z.B. bis dato keine Möglichkeit eine einzelne Lampe aus der Konfiguration der Bridge zu entfernen. Philips möchte dazu einen Factory-Reset haben und anschliessend müssen alle Lampen neu eingebunden werden. Dadurch stimmt die Zuordnung (Nummern) der in RWE-SH eingebundenen "virtuellen Lampenaktoren" zu den physikalischen Lampen nicht mehr und man muss auch in RWE-SH alle Lampenaktoren löschen. Danach diese neu einbinden und folglich auch alle Profile für HUE neu erstellen.
Das ist total unbefriedigend und wäre nur dadurch zu lösen, dass RWE-SH eindeutige IDs der Lampen an die virtuellen SH-Aktoren bindet. Warum das nicht geht weiss ich leider nicht genau aber wenn es einfach wäre hätte man es bestimmt bereits umgesetzt.
Meine Note dafür: 4+
Soweit also meine Anmerkungen zu "der Weg ist längst beschritten".
Ist er ja auch aber eines ist klar geworden:
Wir stehen noch am Anfang des Weges und ohne Standards wird es zwangsläufig ein Chaos geben.
Ich denke, dass meinte SGK1 auch mit seinem Beispiel (XYZ).
Noch eines ist mir ebenso klar, nämlich dass ein "geschlossenes" System wie RWE-SH sich niemals, auf Kosten der Sicherheit, für jeden x-beliebigen Standard öffnen wird. Die Integration fremder Protokolle wird hier immer über das Modell "TCP/IP<>Hersteller-API (bridge/gateway)" oder über eine zusätzliche Funkantenne, wie z.B. für WirelessMBus, am SHC (oder im SHC) stattfinden.
Ich gebe Hans gerne recht, dass dies nach einer halbherzigen Umsetzung aussehen mag aber es gehören ja auch immer zwei dazu um etwas Ganzes abzuliefern. Solange die Hersteller ihre eigenen Wege gehen, um sich von der Konkurenz abzuheben und jeder seine Gateways verkaufen will, fährt der Zug der Zeit am Kunden vorbei, denn der wünscht sich eine einheitliche Lösung. Philips hat gezeigt wie man es machen kann und auf TCP/IP gesetzt und eine API veröffentlicht. Aber auch hier wurde halbherzig und nicht zuende gedacht, wie meine obigen Bemerkungen zeigen.
Viele Grüße,
Thomas
Nehmen wir die Beispiele von Hans, also Miele, Bosch-Buderus, Samsung und Philips-HUE, bezogen auf RWE-SH.
Miele:
Man braucht in jedem Fall ein "Miele-Gateway". Das wäre noch OK, wenn man für verschiedene Miele Haushaltsgeräte mit einem Gateway auskommen würde. Da man aber anscheinend bei Miele noch in der Findungsphase ist, gibt es jetzt schon mehrere Gateway-Varianten (powerline, Ethernet, etc), die jeweils nur zu bestimmten Maschinentypen/Generationen kompatibel sind. Wer also den teuren Wäschetrockner ein halbes Jahr nach der teuren Waschmaschine kauft, bekommt u.U. keine Wäschetrockner, der mit dem gleichen Gateway wie die vorher gekaufte smarte Waschmaschine betrieben werden kann.
Ein herstellerübergreifender Betrieb von "weisse Ware" Geräten anderer Firmen ist momentan bei keinem Anbieter solcher Geräte vorgesehen, denn jeder Hersteller kocht hier vorerst sein eigenes Süppchen.
Meine Note dafür: 5+
Bosch-Buderus:
Man braucht sich nur hier im Forum umzusehen. Kompatibel sind nur bestimmte Kessel und auch diese nur in Kombination mit einer bestimmten Steuereinheit und einer bestimmten Bedieneinheit. Darauf wird zum Glück deutlich hingewiesen und auch viele Heizungsfachbetriebe haben inzwischen entsprechendes Know-How aufgebaut. Die Integration in RWE-SH, insbesondere das "pairing", ist ein bischen "fummelig" aber danach funktioniert eigentlich alles ganz gut. Ein kleiner Wermutstropfen ist allerdings, dass Bosch-Buderus nur einen Pairingpartner erlaubt, d.h. die hauseigene Bosch-Buderus-App ist nach dem "pairing" mit dem RWE-SH Addin nicht mehr nutzbar. Der Highlander lässt grüßen - Es kann nur einen geben!
Bei Problemen mit der Steuerung über das Addin wird angeblich, so war es zumindest hier im Forum zu lesen, der schwarze Peter zwischen RWE und Bosch-Buderus hin und her geschoben.
Ich kann das allerdings nicht bestätigen, denn die Kooperation mit Bosch-Buderus ist gut und man ist auf beiden Seiten an Verbesserungen (z.B. das Bugfixing der Anzeige von "?") interessiert, auch wenn deren Umsetzung manchmal eine Weile dauert.
Meine Note dafür: 2-
Samsung-Kamera:
Nach der Beseitigung einiger kleiner Startschwierigkeiten mit der Aufzeichnung/Speicherung, gibt es hier aktuell keine Probleme. Da die Kameras ohne irgendwelche Gateways auskommen und hier das standardisierte IP-Protokoll verwendet wird, sind keine besonderen Probleme in der Zukunft zu erwarten. Neue Kameramodelle werden entweder kompatibel zu dem RWE-SH Addin sein oder nicht und dass Addin wird sicherlich entsprechend weiterentwickelt um zukünftige Kameras zu unterstützen. Vielleicht wird es auch irgendwann eine Premiumversion davon geben, mit welcher z.B. die Kamerasensoren (Geräusch/Bewegung) genutzt werden können. Dank IP-Protokoll wäre das nur eine Frage des Entwicklungsaufwands (kosten/nutzen).
Meine Note dafür: 2+
Philips-HUE:
Das beste Beispiel kommt zum Schluss, denn die HUE Integration hat gezeigt wo die Stolpersteine sind und sie tut es immer noch.
Die sogenannte HUE-Bridge "spricht" zwar auch IP, verwendet zur Steuerung der Lampen aber das Zigbee Funkprotokoll. So weit so gut - warum auch nicht? Kritiker haben öfters angemerkt, dass es toll wäre, wenn der SHC selber Zigbee "sprechen" würde, denn dann würde man die HUE-Bridge ja nicht brauchen. Das ist aber zu kurz gedacht, denn damit würde die parallele Nutzung diverser anderer Apps für HUE nicht mehr funktionieren. Die Art und Weise wie man HUE in RWE-SH integriert hat ist der beste Weg, denn man lässt die "Philips-Welt" unangetastet und ohne deren Funktionen in SH nachzubauen und nutzt statt dessen deren API zur Ansteuerung.
Das funktioniert gut aber nur solange wie die API, seitens Philips, nicht unangekündigt modifiziert wird. Genau dieser Fall ist aber vor einiger Zeit einmal eingetreten und die Steuerung der HUE Lampen war mit RWE-SH dann plötzlich nicht mehr möglich. Nachdem das Problem dann gefunden war, musste das RWE-SH HUE-Addin kurzfristig und schnellstmöglich angepasst werden.
Ärgerlich für die Anwender des RWE-SH HUE-Addins und besonders ärgerlich für RWE, denn RWE musste nicht nur die, für das ungeplante und kurzfristige Fixing anfallenden, Entwicklungsarbeiten/kosten stemmen, RWE bekam zum Dank auch noch den gesamten "Shitstorm" der verärgerten HUE-Anwender zu spüren. So etwas sollte nicht passieren.
Des Weiteren sind in der "Philips-HUE-Welt" ein paar Tücken vorhanden, die den Nutzern des RWE-SH-Addins das Leben schwer machen. Soweit ich weiss gibt es z.B. bis dato keine Möglichkeit eine einzelne Lampe aus der Konfiguration der Bridge zu entfernen. Philips möchte dazu einen Factory-Reset haben und anschliessend müssen alle Lampen neu eingebunden werden. Dadurch stimmt die Zuordnung (Nummern) der in RWE-SH eingebundenen "virtuellen Lampenaktoren" zu den physikalischen Lampen nicht mehr und man muss auch in RWE-SH alle Lampenaktoren löschen. Danach diese neu einbinden und folglich auch alle Profile für HUE neu erstellen.
Das ist total unbefriedigend und wäre nur dadurch zu lösen, dass RWE-SH eindeutige IDs der Lampen an die virtuellen SH-Aktoren bindet. Warum das nicht geht weiss ich leider nicht genau aber wenn es einfach wäre hätte man es bestimmt bereits umgesetzt.
Meine Note dafür: 4+
Soweit also meine Anmerkungen zu "der Weg ist längst beschritten".
Ist er ja auch aber eines ist klar geworden:
Wir stehen noch am Anfang des Weges und ohne Standards wird es zwangsläufig ein Chaos geben.
Ich denke, dass meinte SGK1 auch mit seinem Beispiel (XYZ).
Noch eines ist mir ebenso klar, nämlich dass ein "geschlossenes" System wie RWE-SH sich niemals, auf Kosten der Sicherheit, für jeden x-beliebigen Standard öffnen wird. Die Integration fremder Protokolle wird hier immer über das Modell "TCP/IP<>Hersteller-API (bridge/gateway)" oder über eine zusätzliche Funkantenne, wie z.B. für WirelessMBus, am SHC (oder im SHC) stattfinden.
Ich gebe Hans gerne recht, dass dies nach einer halbherzigen Umsetzung aussehen mag aber es gehören ja auch immer zwei dazu um etwas Ganzes abzuliefern. Solange die Hersteller ihre eigenen Wege gehen, um sich von der Konkurenz abzuheben und jeder seine Gateways verkaufen will, fährt der Zug der Zeit am Kunden vorbei, denn der wünscht sich eine einheitliche Lösung. Philips hat gezeigt wie man es machen kann und auf TCP/IP gesetzt und eine API veröffentlicht. Aber auch hier wurde halbherzig und nicht zuende gedacht, wie meine obigen Bemerkungen zeigen.
Viele Grüße,
Thomas