Siemens Home Connect Hausgeräte

[THZ_Haus]

Hallo,
gibt es schon was neues?

Nutze Solarview und FHEM auf einem Raspberry.
Überlege einen neuen Trockner (Wärmepumpen Technik) anzuschaffen.
Gibt es schon Schnittstellen die Freigegeben sind?
Miele@home? Siemens? Bosch?

MfG

[Loredo]

Hm bei anderen Anbietern generiert sich doch auch einfach jeder Fhem Anwender seine eigenen API Keys? Weshalb muss es hier anders sein, wenn generell jeder sich beim Development Portal registrieren kann? Bei mir hat das 5min gedauert (habe weiter aber auch noch nichts gemacht).

Kann im Zweifel aber auch anbieten über andere interne Kanäle zu vermitteln, wenn das notwendig werden würde.


Gruß

Julian

[swhome]

@THZ_Haus: Ich bin ziemlich zuversichtlich dass die Schnittstelle von FHEM zu Home Connect in Kürze hier verfügbar sein wird. Damit wären dann Hausgeräte der Marken Bosch und Siemens angebunden.

[FHEMAN]

Hi swhome,

Waschmaschine ist da, angeschlossen, Home connect connected, als Entwickler bin ich auch registriert. Ready for test....

Gleiches bei mir. Allerdings mit einem Dampfbackofen SIEMENS CS858GRS6
Würde mich freuen, wenn es hier weiter geht.

Gruß
Ronny

[Dersch]

Gibt es schon was neues? Bald kommt ein neuer Backofen, das Modell ist noch offen. Das Homeconnect interessiert mich aber nur wenn ich es in FHEM einbinden kann.

[swhome]

Aktuelles Update:

Am Dienstag letzter Woche war ich in der Zentrale von Bosch Siemens Hausgeräte in München zu Besuch und habe dem Projektleiter des API und einem Entwickler von Home Connect ein FHEM mit meinem Home Connect Modul vorgestellt.

Die Installation bestand aus einem plain FHEM aus dem Release-Zip mit demo.cfg und dem Modul. Zuerst habe ich kurz ein paar Screens gezeigt, dann mit define den Home Connect Account angelegt. Danach auf einen aus FHEM generierten Link geklickt und den OAuth-Login durchgeführt. Nach der Rückkehr der Login-Seite zu FHEM wurde der Status Logged In gezeigt. Mit set hcconn scanDevices das automatische Anlegen der Geräte gestartet und schon waren mein Geschirrspüler und mein Backofen als neue Devices sichtbar. Nach einer kurzen Tour durch die Readings und Attribute habe ich den Spüler per set hc_spueler Auto2 gestartet und wir konnten den Programmfortschritt und die diversen Events bewundern. Dann habe ich noch mein "Produktivsystem" gezeigt und zwei Notifys zum Starten des Spülers bei Sonne sowie eine kleine Lichtorgel bei Programmende erläutert.

Danach kamen wir darauf zu sprechen, was nun noch alles geschehen muss bis diese Anbindung für alle FHEM User zur Verfügung stehen kann. Das Home Connect API ist grundsätzlich schon betriebsbereit und erste andere Partner sind produktiv (für eine Liste siehe hier: http://www.home-connect.com/de/de/index.html#partner ). Wir müssen also nur in diese Liste kommen...

Und hier beginnt es etwas komplizierter zu werden. Wenn man sich so einen Home Connect Backofen anschaut könnte man sagen: nichts weiter als ein Hausgerät wie man es schon seit einem Jahrhundert in der Küche hat. Man könnte ihn aber auch als potentiell gefährliche Maschine mit komplexer Steuerungssoftware sehen, die bei Fehlern schnell zu einer Gefahr für Leib und Leben wird. Ein simpler Fehler im FHEM Modul oder in einem Notify könnte etwa aus dem geplanten harmlosen Auftauen des Huhns in einer Plastikschüssel eine ziemlich brenzlige Situation entstehen lassen.

Spätestens der Versicherer dürfte dann versuchen, die Verantwortung für den Fehler im API oder in FHEM (also bei dessen Entwicklern) oder zumindest beim Hersteller des Hausgeräts zu finden. Die Sorgen sind hier so groß, dass insbesondere das Starten des Backofens über das API möglicherweise nie möglich sein wird (oder zumindest nicht für FHEM).

So kommen wir nun zur Freischaltung des API für FHEM, hierzu ist der sogenannte API Key erforderlich. Man hat mir signalisiert dass eine individuelle Registrierung aller Nutzer der Schnittstelle als "Entwickler" wegen des damit verbundenen Aufwands nicht erwünscht ist. Für die Zukunft habe ich daher in Aussicht gestellt, dass ein Key zusammen mit einer Signatur des Moduls so verschlüsselt werden könnte, dass er nur mit der dafür releasten Version genutzt werden kann. Sobald der Source verändert wird, funktioniert der Schlüssel nicht mehr und der dann faktisch "Entwickler" zu nennende Anwender braucht eine eigene Registrierung.

Mir wurde zugesagt dass der neue Partner "FHEM" diese Woche im Home Connect steering committee zur Sprache kommt und wir damit Aufmerksamkeit von höchster Stelle erhalten. Wer die Abläufe in Grossunternehmen kennt wird wissen, dass das Resultat dieser Besprechung vollkommen unvorhersagbar ist.

Ich bin weiterhin optimistisch und halt Euch auf dem Laufenden.


TL;DR: Ein Backofen ist keine Wetterstation, die Sicherheitsanforderungen machen die Freigabe der Schnittstelle kompliziert.

[Jojo11]

Respekt. Vielen Dank für Deinen Einsatz und den ausführlichen Bericht!

schöne Grüße
Jo

[justme1968]

hast du denn den eindruck das das sicherheitsargument vielleicht auch etwas vorgeschoben sein ist? man könnte ja auch der meinung sein das ein api so sicher sein muss das es kein risiko gibt.

unabhängig davon: gibt es das api her (erst mal) nur einen read only zugriff zu reagieren? ich vermute das es für eine vielzahl von anwendungen schon reicht betriebzustand und verbrauchsmittel zu überwachen und au fhem heraus darauf zu reagieren. für das echte steuern gibt es vielleicht garnicht so viele anwendungsfälle.

gruss
  andre

[Dr. Boris Neubert]

Danke für das Update und Dein Engagement (ich oute mich mal: ich habe einen Trockner von Bosch).

Für die Zukunft habe ich daher in Aussicht gestellt, dass ein Key zusammen mit einer Signatur des Moduls so verschlüsselt werden könnte, dass er nur mit der dafür releasten Version genutzt werden kann. Sobald der Source verändert wird, funktioniert der Schlüssel nicht mehr und der dann faktisch "Entwickler" zu nennende Anwender braucht eine eigene Registrierung.

Ich kann nicht ohne weiteres erkennen, ob diese Vorgehensweise konform zur GPLv2 ist oder nicht. Sofern ich den Vorschlag richtig verstehe, würde es auch die Entwicklung des Moduls beschränken. Diesen Punkt solltest Du beachten.

M.E. liegt jetzt die Entscheidung beim Steering Committee. Wenn dessen Mitgliedr der Meinung sind, dass sie nicht mehr an FHEM vorbeikommen, ist das zum einen gut für die Anwender von FHEM mit solchen Hausgeräten. Zum anderen würde ich dann aber auch erwarten, dass der Hersteller einen praktikablen Vorschlag macht, der konform mit dem OSS-Gedanken von FHEM ist.

Viele Grüße
Boris

[visionsurfer]

Hallo,

als Nutzer (ich hab nicht wirklich Ahnung von Programmierung) und Mensch mit sehr vielen Ideen und Visionen, lese ich das hier aufmerksam mit.
Als ich vor 2 Jahren Eigentum erworben habe und eine neue Küche, neue Waschmaschine, Trockner usw. her musste, hab ich gleich drauf geachtet, das alle Geräte für Miele@Home geeignet sind.

Ob meine Geräte heute noch dem neusten Stand entsprechen, bzw. das können was ich gerne können würde, weiß ich nicht. Mir würde es in erster Linie auch um "Status" gehen. Geschirrspüler fertig. Herd noch an usw. usw. Wobei man das sogar wahrscheinlich durch Strommessung jetzt schon hinbekommen würde.

Was ich aus meiner Sicht total quatsch finde, sind diese "Sicherheitsbedenken". Meine Miele Geräte haben alle eine Startzeitplanung. Das heißt ich kann schon jetzt das Essen vom Vortag in den Backofen stellen und dem Gerät programmieren das mein Essen um 18 Uhr fertig sein soll. Weil ich halt weiß das ich ca. 18 Uhr zu Hause bin. Wie von Geisterhand schaltet sich dann mein Backofen ein und macht alles was ich vorher eingestellt habe. Grundsätzliche eine sehr praktische Funktion für den Sonntagsbraten oder andere Dinge, die etwas länger brauchen.

Auch hier gibt es ein "Sicherheitsrisiko", weil ich bin ja nicht zu Hause. Miele bietet aber diese Funktion. Wo ist da der Unterschied ob ich eine Startzeit plane oder von der Ferne per App etwas starte ?
Wenn ich dann noch auf die App ein Feedback zurück bekomme, ist es doch sogar noch sicherer und besser als nur eine blöde Startzeitplanung. Weil ich einfach sehen kann, ob vielleicht irgendwas falsch läuft.

Falls ich mit meinen Gedanken total falsch liege, ok. Aber irgendwie finde ich es komisch.

Grüße,
Visionsurfer

[kossmann]

Ich stimme dir da zu. Wer Plastikschüsseln (z.B. Zwecks Auftauen) in den Backofen stellt und diesen nicht unter Beobachtung hat, handelt in meinen Augen grob Fahrlässig - das Thermostat im Ofen kann immer mal klemmen oder defekt sein. Da ist es völlig egal, ob ich zu Hause bin und den Ofen nicht beaufsichtige oder ob ich den Ofen aus 50km Entfernung starte.
Ein geschlossener Ofen ohne Inhalt kann hingegen gestartet werden wie er möchte, da darf grundsätzlich nichts passieren, auch nicht, wenn er innen 250°C erreicht.

[herrmannj]

Halt ich auch für Quatsch aber schlussendlich zählt da ja die Meinung von BSH.
Ein Modul sehe ich damit in weiter Ferne, allein wegen der praktischen Hürden die Anforderungen umzusetzen.

Hat mal jemand untersucht wie man an der API vorbei mit den Geräten kommuniziert ?

vg
joerg

[swhome]

Hallo, vielen Dank für das viele Feedback, das hilft mir sehr.

@visionsurfer: Sehr gutes Gegenargument für mein angeführtes Beispiel. Eine andere konkrete Sorge von Home Connect ist, dass FHEM ja quasi die Rolle des User Interface übernimmt und ein Fehler in FHEM dem Anwender einen falschen Status (z.B. Temperatur) des Geräts vorspiegeln könnte. Diese Gefahr besteht im Timer-Beispiel nicht.

Den Vorschlag, sich auf den Status zu beschränken finde ich beim Backofen noch erträglich, bei Trockner, Waschmaschine, Spülmaschine etc allerdings nicht mehr akzeptabel weil häusliches Energiemanagement zu meinen eigenen use cases gehört. Generell wäre ich eher dagegen.

@Boris: Das Lizenzthema ist in der Tat zu beachten. Allerdings wird ja niemand daran gehindert, den Source Code zu benutzen oder zu ändern. Er müsste dann lediglich einen eigenen API Key benutzen. Ich könnte aber auch prima damit leben dass sich jeder FHEM Benutzer generell einen eigenen API Key registriert, das erspart mir die Extra-Arbeit.

@herrmannj: Ich bin da nicht so pessimistisch, wir sind ja nicht die einzigen die eine Schnittstelle bauen. Wenn BSH sowieso nie Dritt-Applikationen zulassen wollte, hätten sie gar kein API entwickeln und veröffentlichen müssen.

[visionsurfer]

Hi,

genau. Ich hab hier quasi eigentlich in meinem KNX Bus noch einen EibPort Server laufen, von der Firma Babtec. Die sind angeblich auch an einer Schnittstelle dran, oder sogar schon fertig.

GIRA Homeserver ? Kann der das nicht auch schon ? Keine Ahnung. Wenn ich FHEM richtig laufen habe, lege ich meinen EibPort Server wahrscheinlich sowieso still. FHEM ist viel geiler

Wenn man das ganze schon andocken kann, dann richtig. Auf nur "Status" würde ich mich auch nicht beschränken wollen. Das ist zwar nett, aber könnte man quasi teilweise mit Strommessung jetzt schon. Oder sogar einen Tempfühler in den Ofen basteln.

Weil für mich stellt sich in letzter Zeit immer mehr die Frage, was brauche ich wirklich ? Als ich alles gekauft habe, hab ich sehr, sehr viel Geld für die Elektroeinrichtung ausgegeben. Und halt z.B. auch für die Küchengeräte. Da frage ich mich, muss ich alles steuern können ? Meine Geräte gehen bei inaktiv automatisch aus. Kann quasi nie "vergessen" werden.

Was interessant ist, wenn aber z.B. der Ofen schon auf 200 Grad vorheizt, wenn ich Sonntags die Brötchen aufpacken will und in der morgen Szene Bewegung erkannt wird. Das wäre dann SMART

Grüße,
VIsionsurfer

[swhome]

Genau! Der schlaue Kühlschrank weiss das noch Aufbackbrötchen da sind, FHEM weiss daß Du zuhause bist und voila... jetzt fehlt nur noch einer der die Dinger aus dem Eis in die Hitze bringt...

P.S. Temperatur-Logging im Backofen funktioniert bei mir schon prima. Wird Zeit dass ich endlich einen API Key ausliefern darf...
P.P.S Schau Dir die Anheizzeit an... vorheizen des Backofens ist eigentlich out.