Tuya-Adapter 3.10.0/3.11.0 (Beta)

[apollon77]

@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.

[padrino]

@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?

[apollon77]

@padrino Klar ... falls es wieder passiert haste log. Und schau auch auf die ausgaben vom update nicht das da "error 25" oder so passiert

[padrino]

@apollon77

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...

[apollon77]

@padrino Ok, ich mache die nächste version nmal wieder kompatibel ... aber ja Node.js 12 ist bissl EOL

[apollon77]

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

[elektrickser.de]

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 6666

Ich 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

[apollon77]

@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.

[Olli_M]

@elektrickser-de

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

[elektrickser.de]

@olli_m

Ich hab mal alle drei Ports freigegeben und nun läuft es.

[Olli_M]

@elektrickser-de
Im Docker dann ?

Komisch zwar aber gut läuft ja jetzt bei dir auch

[elektrickser.de]

@olli_m

Ja im Docker.

[Olli_M]

@elektrickser-de

Echt interssant habe echt nichts drin

[padrino]

Mal eine Frage zu den tuya IR Blastern, können die IR nur senden oder auch empfangen?
Würde nämlich gerne auf bestimmte IR Befehle reagieren können.

[apollon77]

@padrino Meines Wissens nach (!) geht das nicht. Ja Sie können Codes empfangen aber eher zum "wieder ausstrahlen"

[elektrickser.de]

@olli_m

Wie hast du den Docker-Container eingerichtet? Ich habs in Portainer mit der Vorlage/Container von Buanet eingerichet.
Alleine die Standard-Ports für den Zugriff (8081/8082) sollten doch deklariert sein.

[padrino]

@apollon77
Also, der Code wird nicht in einem Datenpunkt gespeichert/angezeigt?

[apollon77]

@padrino ja doch aber man muss das Ding zuerst in den lern Modus versetzen und dann kommt da ein Code raus. Wie „gleich“ der für das gleiche ir Kommando ist Weiss ich nicht. Tippe aber das da nicht immer 100% das gleiche rauskommt.

[padrino]

@apollon77
Ok, das ist dann natürlich keine Lösung.
Danke für die Info.

[A Former User]

@olli_m

du brauchst auch keine Ports freigeben, da du den Host verwendest und nicht die Bridge, wie @elektrickser-de , im Bridge-Mode muss 8081 fuer Admin, einen fuer Web, und alle, die sonstige Adapter ( Tuya 6668 TCP, 6666 und 6667 UDP) freigegeben werden.