Tuya-Adapter 3.10.0/3.11.0 (Beta)
-
Hallo an alle Tuya Fans
Heute kommt die 3.10.0 (3.11.0 siehe am Ende des Posts) des Adapters ins Beta Repository und bringt einige Neuerungen mit:
- Gerätegruppen die in der App angelegt wurden sind jetzt auch im Adapter verfügbar und können (per App-Cloud) gesteuert werden. Und bevor jemand frage: Die Steuerung geht technisch auch lokal, ABER dann ist der Status der Gruppe in der Tuya App und damit in der Cloud falsch... daher geht es nur sauber wenn alles per Cloud läuft.
- Ein zweiter Typ von IR-Blaster (Danke an Jan Schlage für ein Testgerät) wird jetzt auch unterstützt. Mit dem können sogar die Gerätetasten lokal gesendet werden und nicht zwingend per Cloud
- Wenn die App-Cloud-Session während der Adapter-Laufzeit abläuft wird dies nun sauber behandelt.
- Das schonmal für Version 3.9 versprochene korrekte Handling der "bright_value" States ist jetzt wirklich drin. Also Wertebereich dort jetzt 0..100 und nicht mehr 10..1000)
- Bei Base64-kodierten States wird jetzt geprüft ob es sich zu "lesbarem Text" konvertieren lässt (zB Doorbell Bild URLs kommen so) und dann werden die konvertiert. Sonst bleibt es weiterhin base64 um keine binären Daten zu zerstören
- Es ist ein gerät aufgetaucht welches keine aktuellen Daten geliefert hat ausser es wird auf eine spezielle Weise abgefragt. Dies ist jetzt durch setzen von "useRefreshToGet:true" in native Bereich des Device Objekts einstellbar. Eine UI kommt irgendwann mal falls mehr solche Gerätr auftauchen
Und die 3.10.2 optimiert nochmals die IR-Steuerung: Es sollte jetzt alles IR technische sowohl lokal wie auch über die Cloud gehen. Bitte nochmal alle Fälle durchchecken. Danke!
Die 3.11 fügt noch Support für Zigbee-Hubs hinzu und behebt ein paar Absturzsituationen.
Viel Spass mit dem Update
Ingo
-
@apollon77 sagte in Tuya-Adapter 3.10.0 (Beta):
Ein zweiter Typ von IR-Blaster (Danke an Jan Schlage für ein Testgerät) wird jetzt auch unterstützt. Mit dem können sogar die Gerätetasten lokal gesendet werden und nicht zwingend per Cloud
@Jan-S100 um welchen geht es denn genau (würde mich brennend interessieren)?
-
@latzi den wo die state ids der datenpunkte nicht. 201/202 sind sondern 1..13. das sind die zwei Typen von Geräten die wir gerade kennen. Und von jedem Typ gibts dann einige echte geräte
-
@apollon77
Danke Ingo, ich würde gerne die Typenbezeichnung des Geräts wissen -
@latzi keine Ahnung. ;-)) wie gesagt sind es gerätetypen. Da gibts jeweils mehrere von. Und bisher wären nur diese beiden Typen bekannt. Also Kauf eins und es ist Vorauss. Eins der beiden Typen ;-))
-
@latzi Ich habe beim grossen A bestellt. Jeweils beim selben Angebot. Und habe trotzdem 2 verschiedene Geräte erhalten.
Such mal nach "Jinvoo WiFi Smart IR AC/TV Box Controller" -
Auf dem Weg ist jetzt noch die 3.10.2, die nochmals IR optimiert. Es sollte jetzt alles IR technische sowohl lokal wie auch über die Cloud gehen. Bitte nochmal alle Fälle durchchecken. Danke!
-
Danke auch von mir für deine Arbeit am Adapter. Meine bis jetzt zwei Tuya Geräte funktionieren feinstens mit Adapter-Version 3.10.2.
Einmal MiBoxer WL2-P75V24
und ein OCONA WT1.
Was ich beobachtet habe ist das bei einem Gerät bright_value mit Prozent und beim anderen ohne Prozent erstellt wird. Die temp_value ist weiterhin im Bereich von 1-1000. Das ist sicher so gewollt.
Jetzt nichts weltbewegendes, nur als Rückmeldung. -
@spacerx Ok das % kann ich fixen ... (scheint wohl in einem Schema mit % als Unit zu kommen von Tuya und beim anderen nicht).
temp_value ist genau was? In dem Fall ist der Wertebereich 0..1000 ... also ist ein kein % Wert?!
-
@apollon77
Ist es eigentlich normal, dass man die Instanz nach dem Update nochmal von Hand rebooten muss, damit alles funktioniert?
Wird die nicht eigentlich bei der Installation gestoppt und danach neu gestartet?
Sorry, für diese banale Frage.
-
@padrino nein bei regulären Updates nicht normal. Haste das mal als log? An sich wird die instanz am Ende vom Update neu gestartet. Sowas kann nur bei github updates vorkommen wenn sich die Versionsnummer nicht ändert.
-
@apollon77
Hmm, wie ich gerade sehe, hat das Update gar nicht geklappt, obwohl im Admin "erfolgreich" stand, bin immer noch auf 3.9.4... und dennoch gab es das Problem, dass es nimmer wollte, ohne Neustart.
Wo ich nun die Chance habe, wann soll ich debug aktivieren, noch bevor ich den (erneuten) Updateprozess anstoße?
-
@padrino Klar ... falls es wieder passiert haste log. Und schau auch auf die ausgaben vom update nicht das da "error 25" oder so passiert
-
Ok, das Update schlägt wohl fehl...
$ ./iobroker upgrade tuya Update tuya from @3.9.4 to @3.10.2 NPM version: 6.14.15npm install iobroker.tuya@3.10.2 --loglevel error --prefix "/opt/iobroker" (System call) npm ERR! code ENOTSUP npm ERR! notsup Unsupported engine for fs-extra@11.1.0: wanted: {"node":">=14.14"} (current: {"node":"12.22.6","npm":"6.14.15"})npm ERR! notsup Not compatible with your version of node/npm: fs-extra@11.1.0npm ERR! notsup Not compatible with your version of node/npm: fs-extra@11.1.0npm ERR! notsup Required: {"node":">=14.14"}npm ERR! notsup Actual: {"npm":"6.14.15","node":"12.22.6"} npm ERR! A complete log of this run can be found in:npm ERR! /home/iobroker/.npm/_logs/2022-12-08T12_07_05_028Z-debug.log upload [3] tuya.admin /opt/iobroker/node_modules/iobroker.tuya/admin/words.js words.js application/javascript upload [2] tuya.admin /opt/iobroker/node_modules/iobroker.tuya/admin/warning.png warning.png image/png upload [1] tuya.admin /opt/iobroker/node_modules/iobroker.tuya/admin/tuya.png tuya.png image/png upload [0] tuya.admin /opt/iobroker/node_modules/iobroker.tuya/admin/index_m.html index_m.html text/html Adapter "tuya" updated process exited with code 0```Denke, ich muss wohl Zeit finden mein System endlich mal upzudaten...
Nach dem Fehlschlag will der Adapter allerdings wirklich erst wieder nach einem Neustart...
Ich mail Dir mal das Log... -
@padrino Ok, ich mache die nächste version nmal wieder kompatibel ... aber ja Node.js 12 ist bissl EOL
-
Die 3.11 fügt noch Support für Zigbee-Hubs hinzu und behebt ein paar Absturzsituationen.
... und sollte erstmal wieder kompatibel mit Node.js 12 sein!! @padrino
-
Welche Ports muss ich unter Docker/Portainer freigeben um den Adapter voll nutzen zu können?
Ich habe bis jetzt immer nur 6666 freigegeben. Nur jetzt auf Container "Latest-v7" vom IObroker bleibt der Adapter gelb.
Im Log sehe ich folgende Einträge:tuya.0 2022-12-14 22:55:57.056 info xxx: Error on Reconnect (6): connect EHOSTUNREACH 192.168.17x.x:6668 tuya.0 2022-12-14 22:55:35.971 info xxx: Error on Reconnect (5): connect EHOSTUNREACH 192.168.17x.x:6668 tuya.0 2022-12-14 22:55:16.037 info xxx: Error on Reconnect (3): connect EHOSTUNREACH 192.168.17x.x:6668 tuya.0 2022-12-14 22:54:52.961 info xxx: Error on Reconnect (1): connect EHOSTUNREACH 192.168.17x.x:6668 tuya.0 2022-12-14 22:54:52.908 info xxx: Error on Reconnect (3): connect EHOSTUNREACH 192.168.17x.x:6668 tuya.0 2022-12-14 22:54:52.905 info xxx: Error on Reconnect (1): connect EHOSTUNREACH 192.168.17x.x:6668 tuya.0 2022-12-14 22:54:50.450 info Listen for encrypted local Tuya devices on port 6667 tuya.0 2022-12-14 22:54:50.448 info Listen for local Tuya devices on port 6666Ich sehe hier nur 3 Ports 6666,6667 und 6668. Brauche ich nun alle 3? bisher ging ich nur von 6666 aus.
Tuya Version: 3.9.4
Node.js: v16.18.1
NPM 8.19.2
js-controller: 4.0.23 -
@elektrickser-de Also 6666 und 6667 sind UDP Listening Ports ... Also die nur freizugeben reicht ggf eh nicht, aber da kenne ich mich mit Docker nicht aus. Ich erinner emich das man da MacVLan oder sowas braucht ...
6668 nutzt der Adapter nur ausgehend zu den Geräten und das sollte keine Freigabe bedürfen.
-
Hi
Nutze auch docker und hab keine Ports da freigegeben
Bin nur grad nicht am Rechner aber nutzt du im docker das selbe Netzwerk? Die Bridge ?
Ich guck später mal nach nur bei mir läuft der Adapter und hab da keine port Freigaben gemacht
Zumindest läuft alles intern nur
-
Ich hab mal alle drei Ports freigegeben und nun läuft es.
