Freiheit für Tuya-Geräte von der Cloud

Projekt: Heimautomatisierung

Kontakt: Boris Dirnfeldner

Link: – eigenes Projekt –

In den letzten Wochen wurden einige Geräte angeschafft, zum Teil aus Spieltrieb, zum Teil aus Notwendigkeit. Es hat sich gezeigt, dass Tuya ein wichtiger Player im Bereich der Heimautomatisierung ist. Zum einen, weil die Komponenten erstaunlich günstig sind und trotzdem funktionieren, zum anderen, weil es einfach eine unglaubliche Fülle von Gerätearten gibt und man sich so die Anzahl der Herstellerbiotope wirklich übersichtlich halten kann. Allerdings darf nie vergessen werden, dass Tuya eine maximale Bindung an seine Cloud durchsetzt. Die funktioniert zwar sehr ordentlich, aber eine Garantie ist das nicht für immer.

Ich benutze als zentrale Basis den Home Assistant (Home Assistant (home-assistant.io)), eine wirklich schon ziemlich erwachsene Lösung mit einem riesigen Park an Integrationen zu den verschiedenen Herstellerbiotopen. Zusammen mit der Community und deren zusätzlichen Beiträgen kommt man schon ziemlich weit. Bei den Geräten nutze ich vorwiegend Tasmota und Tuya als Basisplattform, bei der Kommunikation primär Wifi und ZigBee.
Die Anbindung von Tasmota kann über die Integrationen mit Hilfe von MQTT als Schnittstelle sehr einfach erfolgen und funktioniert anstandslos. Bei Tuya läuft es über deren Cloud und deren Core API. Wäre an sich auch ok, zumindest diskutabel, hat aber einen konkreten Pferdefuß.

Tuya Core API: Goodwill oder 25.000$

Diese API erlaubt es der Integration im Home Assistant auf meine Geräte zuzugreifen. Dazu muss man sich als Entwickler anmelden, die Cloud mit dem eigenen Gerätepark (gemanagt über Handy App) verknüpfen und für eine Applikation freigeben. Da kann man dazu stehen, wie man will, Alternativen gibt es offiziell keine. Ein Problem dabei ist, dass die zentralste Komponente dabei, die Core API, kostenlos nur als Trial für 30 Tage erhältlich ist (anders als bei der Handy App). Damit ist diese Anbindung auf Gedeih und Verderb von der Lizenzpolitik von Tuya abhängig. Die Lizenz läuft auch aus und kann pro Account auch nur einmal beantragt werden. Es gibt zwar eine Möglichkeit, diese Trial um bis zu 6 Monate zu verlängern (auch ganz offiziell bei Tuya beschrieben), allerdings halt ohne Anspruch, nur Goodwill. Die kommerzielle Lizenz kostet mindestens 25.000$/Jahr und steht damit völlig außen vor. Zwar wird diese Verlängerung aktuell problemfrei gewährt, aber eine gute Lösung ist das so nicht.

Ich habe gerade meinen kompletten Park an Feuermeldern auf ZigBee mit einem Produkt von Tuya umgestellt, auch weil es keine echte Alternative dazu gibt die auch bezahlbar ist (und zwar um Dimensionen). Ich wollte die Signalisierung eines Alarms und die Batterieüberwachung integriert bekommen, da wird es dann schnell dünn mit Alternativen. Da ich also am Gerät nicht vorbeikomme, aber gleichzeitig die Cloud so nicht schätze, braucht es eine Alternative. Zwar funktionieren die Dinger auch autark, aber dann hätte ich auch bei günstigeren, dummen Geräten bleiben können.

Tuya Cloudfree

Tuya wird in der Gemeinschaft sehr aktiv diskutiert und einige Freiwillige haben sich tief in die Plattform reingegraben. Wie bei Sonoff und Tasmota hat der Hersteller natürlich gar kein Interesse an einer alternativen Lösung, daher ist das wirklich Reverse-Engineering in Bestform. Im Zuge der Aktivitäten haben sich zwei Wege aus der Cloud gebildet: Local Tuya (GitHub – rospogrigio/localtuya: local handling for Tuya devices) und Zigbee2MQTT (Home | Zigbee2MQTT). Daneben gibt es noch die Option, Geräte wie mit Tasmota eine alternative Firmware zu verpassen, z.B. mit Tuya-Convert (Tuya Convert – Tasmota). Local Tuya bietet sich vor allen für Wifi-basierte Geräte an, Zigbee2MQTT (wie der Name schon sagt) für die Zigbee-basierte Variante. Beide sind gut im Home Assistant integriert.

Die Nutzung von Tuya-Convert ist eingeschränkt überschaubar einfach und ergibt am Ende ein Tasmota-Gerät. Wenn es klappt mit Sicherheit die beste Option, geht aber mit nur wenigen Geräteklassen und da auch nur, wenn ein ESP-Chip eingebaut ist. Ansonsten fällt die Lösung flach.

Local Tuya ist hier an sich flexibler und übernimmt die Geräteverwaltung aus der Cloud lokal. An sich eine elegante Lösung. Allerdings ist das Übernehmen der Geräte nicht trivial, da es keine echte Produktdatenbank gibt und man so manuell die einzelnen Sensoren/Aktoren konfigurieren und zuweisen muss. Das ist nicht immer einfach, manchmal eine eigene Forschungsaufgabe. Obgleich ich die Lösung als einen echten Kandidaten ansehe, tue ich mir diese Bastelei vorerst noch nicht an.

Ganz anders gibt sich hier Zigbee2MQTT. In der Lösung integriert ist eine ziemlich umfangreiche Produktdatenbank, die es erlaubt (für die unterstützten Geräte) ein eigenes Netz aufzubauen und lokal zu verwalten. Da hier auch eine stattliche Anzahl von Tuya-Geräten unterstützt werden, z.B. auch mein Feuermelder (PA-44Z), ist das wahrlich ein Befreiungsschlag.
Die Software lässt sich einfach in einem Docker-Container starten und erleichtert mir damit die Administration erheblich. Zwingend erforderlich ist auch ein Koordinator. Ich habe mich für einen ConBee-II entschieden. Ursprünglich wollte ich damit direkt im Home Assistent mit einer ZigBee Integration arbeiten, aber da bin ich an den Tuya-Eigenheiten gescheitert. Mit der Herstellerdatenbank von Zigbee2MQTT geht das nun ziemlich einfach und sehr gut. An sich reduziert sich alles auf ein neues Pairing mit dem eigenen Coordinator und schon sind die unterstützen Geräte verfügbar und Cloudfrei betreibbar.
In der Praxis funktioniert das nicht immer (ein Umweltsensor zeigte danach falsche Zeit/Datum an), und das Einbinden des Coordinator-Sticks in Docker auf einer Synology DS220+ ist auch ein eigenes Kapitel. Bei den Feuermeldern und meinen beiden Dosen von Tuya klappte aber alles super und schnell.

Obgleich nicht kriegsentscheidend, sollte man noch anmerken, dass auch Zigbee2MQTT eine Oberfläche anbietet, die bei Problemen sehr hilfreich sein kann. ZigBee ist eigentlich ein toller Kommunikationsweg, aber im Detail dann doch wieder mit vielen Ecken, Kanten und Ösen versehen. Da hilft es dann doch, etwas näher und tiefer ranzukommen im Fehlerfall.
Konkret war bei mir die Abtrennung vom 2.4 Ghz Wifi nicht ganz so gut gelaufen wie erforderlich. Daher musste ZigBee auf einen anderen Kanal ausweichen. Auch sind die Repeater erheblich weniger leistungsstark als der Coordinator-Stick, was beim Aufbau zu Kommunikationsverlusten und verlorenen Geräten geführt hat. Ohne die Oberfläche wäre das Eingrenzen und Prüfen eine sehr mühsame Geschichte geworden.

Zusammenfassend kann man also durchaus auch herstellergebundene Geräte aus den jeweiligen Clouds lösen, falls gewünscht oder sogar erforderlich. Zwar wird das nicht immer gelingen, auch nicht immer gleich gut, aber wie im richtigen Leben gilt auch hier: „Ein bisschen Schwund ist immer.“ Und dafür, dass die Lösungen primär durch Freiwillige aufgebaut wurden mit viel Arbeit und Herzblut, ist das ganze inzwischen schon toll ineinander verzahnt.

Vielen Dank dafür von meiner Seite!