Tuya-Geräte lokal im Smarthome nutzen

Wer sich bei der Steuerung seiner Geräte nicht auf die Zuverlässigkeit und Datensicherheit von Cloud-APIs verlassen möchte kann z.B. bei Tuya-Wifi-Geräten auf die lokale Steuerung zurückgreifen. Hierbei gibt es jedoch ein paar Sachen zu beachten.
Zur Kommunikation mit dem Geräte benötigt man die GeräteID, einen localKey und die IP-Adresse – idealerweise eine statische IP- des Gerätes.
Um das Gerät anzusteuern benötigt man noch einen Adapter in seinem Smart-Home-System. Für Homeassistant gibt es viele dokumentierte Tutorials. Ich verwende node-red. Hierfür existieren Adapter, aber die Dokumentation war teilweise widersprüchlich.

GeräteID, localKey und IP-Adresse

Wie man an dese Daten gelangt, ist in einigen Homeassistant-Tutorials bereits gut erklärt. Daher hier nur einmal in Kurzform.

Sobald man das Tuya-Wifi-Gerät über die Tuya App mit dem eigenem WLAN verbunden hat, kann man die GeräteID in den Geräteinformationen einsehen. Ebenso ist dort die MAC-Adresse zu sehen, mit der man leichter an die lokale IP-Adresse kommt. In meiner FritzBox habe ich die Option zur dauerhaften Vergabe eingestellt.

Als nächstes benötigt man einen Account in der Tuya IoT-Plattform und muss diesen mit dem App-Account verknüpfen.

In der IoT-Plattform kann über den API-Explorer die Geräteinformation abgefragt werden, in dessen Daten der localKey zu finden ist.

Tuya-lcal-Adapter

In node-red habe ich nach ein paar Versuchen mit dem Adapter node-red-contrib-tuya-device Erfolge verzeichnen können. Hier genügt der Device-Node mit den zuvor erfassten Details.

Payload

Als nächstes wird es kniffelig, weil der Payload vom Status und Steuerbefehlen nicht „sprechend“ kodiert ist. Tuya-Geräte werden mit DPS – Datapoints im Key-Value Format angesprochen. Die Datapoints werden über IDs (ein-, zwei- oder dreistellige Nummern) adressiert. Die Values können boolean, Integer für Werte und Strings für gewisse Stati sein, Leider findet man dazu wenig bis keine Dokumentation.

Es gibt glücklicherweise ein Python-Tool names Tinytuya, mit dem man diese Key-Value Paare herausfinden kann. Den ersten Anhaltspunkt erhält man wieder in der Tuya-IoT-Plattform -> API-Explorer: Device Management. Hier erhält man eine Übersicht aller Optionen und Wertebereiche.. Mit diesem Wissen kann man mit den Daten des Gerätes in diesem Python-Script den Status abfragen:

import tinytuya

device = tinytuya.Device('<ID>', '<IP>', '<key>')
device.set_version(3.4)
status = device.status()
dps = device.detect_available_dps() 
print('Device status: %r\n' % status)
print('DPS Availible: %r\n' % dps)

Durch gezielte Änderungen eines Parameters in der App auf, einen definierten Wert, erneuter Abfrage über das Script mit Tinytiuya, kann man sehen, welche ID zu dem geänderten Wert gehört und wie der Wert repräsentiert wird.

Mit diesem Wissen habe ich im ersten Schritt den Payload für ein IR-Heizpanel mit Licht wie folgt in eine Funktion geschrieben.

Funktion mit Beispiel-Payload:

msg.payload = {"1":true,"2":39,"3":0,"6":false,"11":"heating","19":"1h","20":0,"101":"8","102":"2"}

return msg;

So kann man ganz einfach für bestimmte Betriebszustände feste Payloads vorsehen, oder Werte innerhalb der Funktion berechnen und als Gesamtergebnis bzw. auch nur einzelne DPS die man verändern möchte an den Node senden, um Einfluss auf das Gerät zu nehmen.

Für mein Heizpanel sehen die DPS wie folgt aus:

DPS - Funktion - Werte
1 - Switch - true/false
2 - Temperatur - int 5 - 50
3 - unknown - bisher immer 0
6 - eco - true/false
11 - Status Modus - heating/standby
19 - Tiemout - cancel/1h/2h...24h
20 - Status Countdown - xx (min)
101 - Helligkeit Licht - 0-8
102 - LED-Mode - 0=aus 1=kaltweiß 2=warmweiß

Sollte das Gerät per WLAN nicht erreichbar sein, kann es mit dem Node zu Fehlern führen, die u.U. node-red zum Absturz bringen können, Daher habe ich vorsichtshalber eine eigene node-red-Instanz für Tuya gestartet und zusätzlich einen Catch-Node auf den Tuya Node konfiguriert. Seit dem ist node-red nicht mehr abgestürzt, wenn das Gerät nicht erreichbar war.

Um das Gerät für das Smart-Home erreichbar zu machen, habe ich MQTT-Topics definiert, womit die Steuerung gelingt und der Status des Geräts am Broker verfügbar ist,

Der Flow sieht dann wie folgt aus: