Hallo homee Community,
ich möchte mit euch meine Lösung für per homee steuerbare elektrische Gardinenschienen teilen.
Um in unserem Wohnzimmer zwei Fenster (einmal 1,10m Breite und einmal eine Fenster-/Türenfront mit 3,5m Breite) mit motorisierten Gardinen zu versehen, war ich schon länger auf der Suche nach entsprechenden Lösungen. Der Markt ist leider unübersichtlich und vieles wird über den Fachhandel vertrieben, der nicht mal vollständige Produktinformationen auf seine Webseiten stellen kann / will.
ABALON Vorhangschiene
Wir haben uns dann letztlich - vor allem auch aus Kostengründen - für eine Lösung des Herstellers Abalon entschieden.
Die Sets gibt es mit unterschiedlichen Längen und auch ohne WLAN Option. Die WLAN Lösung erlaubt auch die Steuerung über eine mitgelieferte Fernbedienung (es gibt auch eine Multichannel Fernbedienung), der Motor erkennt manuelles Ziehen an der Gardine und führt die Fahrt dann zu Ende und es gibt eine Tuya Cloud basierte App (OEM China Cloud, mehr dazu später). Die im Set mitgelieferten Motoren haben die Bezeichnung BCM700D-TY01, dabei handelt es sich wohl um die neuste Generation des Herstellers.
Aufbau
Das gelieferte Set besteht auf den ersten Blick aus vielen Einzelteilen. Man kann die individuell benötigte Länge der Gardinenschienen mit den Schienenmodulen zusammensetzen und muss dann das Laufband entsprechend ablängen. Im Set sind neben 1 Meter Modulen auch 50cm, 20cm und 10cm Module enthalten. Die Gardine kann entweder mittig schließend oder einseitig schließend aufgebaut werden. Die Installation ist mit den mitgelieferten Teilen an der Decke oder an der Wand möglich. Der Motor kann entweder links oder rechts eingehängt werden und verschwindet inklusive Kabel perfekt hinter der Gardine. Er verfügt über einen Schuko Stecker und kann einfach mit einer Steckdose verbunden werden. Insgesamt macht die Lösung einen sehr soliden Eindruck.
Auf der Webseite des Herstellers finden sich neben den Anleitungen auch Videos zur Installation. Die Anleitung(en) halten leider qualitativ nicht mit dem Produkt mit, da teilweise das Englisch schwer verständlich bzw. Bilduntertitel falsch sind. Der deutschsprachige Support des Herstellers ist aber super schnell (Antworten innerhalb von ein bis zwei Stunden, auch am Wochenende), sehr kompetent und letztlich war der Zusammenbau auch dank der Videos einfacher als gedacht.
Tuya-Cloud Anbindung der Motoren
Tuya bietet Herstellern eine Cloud basierte IoT Plattform für ihre Produkte an inklusive Firmware, Cloud Dienst und App (vermutlich auch mit individuellen Branding, so dass man nirgendwo mehr den Namen Tuya liest). Als Referenzkunden werden von Tuya bekannte Marken / Händler wie Hama, REWE, Toom, Medion, LIDL, Blaupunkt und viele andere genannt. Vermutlich steckt in viel mehr Produkten eine Tuya Lösung drin als wir es wissen.
Die Tuya-basierte China Cloud Connection der Motoren war allerdings nicht das, was ich wollte. In der homee Community werden sicher die meisten so denken und ich erspare mir die Erläuterung dazu. Daher habe ich mich in das Thema Tasmota und dann auch Tuya-Convert eingelesen. Letztlich steckt in dem Motor ein ESP mit der Tuya Firmware drauf. Dabei übernimmt der ESP „nur“ die Kommunikation mit der Cloud und leitet die Befehle an eine s.g. MCU des Motors („control board control chip, interworking with a Tuya module over a serial Protocol“) weiter, die die eigentliche „Fachlogik“ inkl. Funkkommunikation für Fernbedienungen übernimmt. Ein Flashen der Firmware durch Öffnen des Gerätes und unter Einsatz des Lötkolbens um an die Anschlüsse des ESPs zu kommen war aber keine Option für mich. Hier kommt Tuya-Convert ins Spiel: Die Skripte von Tuya-Convert verwandeln z.B. einen Raspberry Pi zu einem Tuya-Provisionierungs-Server, der dann dem Tuya-Gerät eine Provisionierung mit einer neuen - und quelloffenen - Firmware anbietet. Es ist dabei also kein Schraubenzieher oder Lotkölben nötig. Der Gardinenmotor muss nur durch langes Drücken des einzigen vorhandenen Tasters in den Provisionierungsmodus / „SmartConfig“ Modus versetzt werden und connected sich dann mit dem Raspberry Pi per WLAN. Nachmachen auf eigene Gefahr. Weitere Informationen findet man hier:
Konfiguration des Tasmota Devices
Nachdem die Motoren auf die quelloffene Firmware Tasmota geflashed worden waren, ging es an die Konfiguration. Hierzu verbindet man sich erstmal mit dem von Tasmota bereitgestellten Hotspot und hinterlegt seine WLAN Daten, um des Device in das eigene Netzwerk zu bringen. Hier nach habe ich für die gerätespezifische Konfiguration bei diesem Forumseintrag aus dem home assistant Forum aufgesetzt. Dies hat den Motor grundsätzlich ansteuerbar gemacht, ich musste aber gewisse Probleme mit der dort beschriebenen Konfiguration feststellen. Konkretes Problem war, dass die Position beim manuellen Fahren (also durch Ziehen an der Gardine und Vollendung durch den Motor) auf 0% (offen) im Gegensatz zur 100% Stellung nicht zurückgemeldet wurde. Problem ist, dass der Motor sich gegenüber Tasmota wie ein Dimmer-Device ausgibt und die Dimmstufe 0% wegen der für eine Lampe ausreichende Meldung Power = aus nicht zusätzlich reported wird. Hier war einige Trickserei unter Berücksichtigung der Serial Communication mit der MCU mit den Tasmota Rules notwendig, um das gewünschte Ergebnis zu erzielen. Die konkrete Tasmota Konfiguration habe ich unten angefügt. Diese Konfiguration funktioniert jetzt seit drei Monaten zuverlässig und zwar bei prozentbasierter Ansteuerung, Befehlsansteuerung (auf, zu, stop) als auch manuellem Ziehen an der Gardine und per Fernbedienung.
ioBroker, Node-RED und hih
Die eigentliche Einbindung in homee erfolgte dann über das Gespann iobroker mit Node-RED, dem fantastischen homee-in-homee Plugin sowie dem iobroker Sonoff Adapter. Den Flow stelle ich unten bereit. Die Tasmota Devices kommunizieren per MQTT mit dem ioBroker, genauer gesagt mit dem Sonoff Adapter. Hier habe ich ergänzend zur Standardkonfiguration noch die Optionen „Automatische Erstellung von Zuständen“ für SENSOR, STATE und RESULT in den Einstellungen aktiviert. Anschließend wird in den Tasmota MQTT Einstellungen der ioBroker hinterlegt. Nach erfolgter Konfiguration erscheinen im ioBroker die entsprechenden Objekte. Durch setzen des Dimmer Values wird wiederum eine Fahrt auf eine bestimmte Position ausgelöst. Der Event Value nimmt die Befehl OPEN, CLOSE und STOP entgegen. Darauf basierend habe ich dann im Node-Red (als ioBroker Adapter installiert, damit man die Integration zum ioBroker bekommt) die Flows für die neuen homee Devices erstellt (Profil Schließer mit Positionsschalter). Die Konfiguration habe ich unten angefügt.
Integration in homee
Neben der Steuerung per Befehlstasten (Öffnen, Stop, Schließen) und der prozentbasierten Steuerung werden diverse nützliche Informationen (WLAN Signalstärke, Tasmota Firmware Version, template, IP Adresse, device datetime, DNS Name, uptime) an homee übertragen. Der Fehleralarm wird ausgelöst, wenn der heartbeat des Tasmota Devices ausbleibt. Das Reporting zurück an homee erfolgt am Ende der Ausführung; es gibt also keine Zwischenmeldungen während der Fahrt (wie man sie z.B. von Rollladenaktoren kennt), sondern immer erst nach Abschluss der Ausführung - dann aber instant und zuverlässig.
Fazit
Nach einigen Monaten Betrieb kann ich ein positives Zwischenfazit ziehen. Die Motoren laufen absolut sanft und fehlerfrei, die Anbindung funktioniert trotz der vielen Komponenten sehr zuverlässig. Sollte ein Motor mal kurzzeitig die Verbindung verlieren (z.B. Neustart von Netzwerkkomponenten), verbindet er sich umgehend erneut. Durch die Einbindung der Gardinen in Szenen via homeegramm hat man ein extrem großes Spektrum an Anwendungsmöglichkeiten.
Der hauptsächliche Aufwand bei der Umsetzung der Lösung kam durch die oben beschriebene „0%-Challenge“, die mir Stunden der Analyse und des Versuchens gekostet hat - aber das Problem ist jetzt gelöst. Zudem hatte ich zu Anfang regelmäßige Restarts der ESPs. Hier stellten sich fehlerhaft in der fritzBox hinterlegte Zeitserver als Ursache heraus (Trennzeichen falsch gesetzt), die sich die Tasmota Firmware durch die DHCP Konfiguration zieht und dann mit der Situation nach ca. 20 Minuten nicht mehr „umgehen“ kann (wobei dies wohl am zugrundeliegenden Arduino Framework liegt). Wenn man die Zeitserver richtig konfiguriert, gibt es kein Probleme.
Man muss natürlich festhalten, dass die vielen Schritte gewisses technisches Verständnis benötigen. Gerade beim Flashen sollte man genau verstehen was man tut und strukturiert vorgehen. Ich würde keinem blutigem Anfänger empfehlen sich an diese Lösung heranzutrauen. Wer aber schon den ein oder anderen Raspberry Pi aufgesetzt hat, unter einem ESP etwas versteht, im Idealfall bereits erste Schritte mit ioBroker und Node-RED hinter sich hat, wird hier sicher keine zu großen Schwierigkeiten bei der Umsetzung haben. Und wenn es dann doch noch Fragen gibt, versuche ich gern zu helfen und die Beschreibung zu ergänzen.
Weitere nützliche Quellen:
Du solltest den Beinamen „WAF“ bekommen. Das kommt bestimmt bei vielen sehr gut an.