Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[apollon77]

@urs VPNs leiten glaube ich nie UDP weiter ... Wireguard ist auch "nur "ein VPN ... aber ich bin kein Netzwerk-Experte

[Urs]

@neuschwansteini sagte in Tuya. 3.17.0:

mit den Portfreigaben UDP 666x hast du auch das Routing eingerichtet?

Ich denke schon. Hab in der Fritzbox folgende Einstellungen gemacht:

Damit sollten alle von aussen ankommenden Anfragen auf den 3 Ports an die Heizung geschickt werden...oder meinst du was anderes?

Aber wie bereits früher geschrieben bin ich weit weg von Netzwerk-Profi!

@neuschwansteini sagte in Tuya. 3.17.0:

Wireguard VPN funktioniert uebrigens nur mit UDP - mit TCP waere es langsam.

Ist das dann aber nicht nur die Verbindung um den Tunnel aufzubauen welche standardmässig über UDP-Port 51820 aufgebaut wird? Was dann da durch den Tunnel geschoben wird dürfte dann doch was ganz anderes sein, ich kann ja den Wireguard Tunnel so konfigurieren dass der gesammte Netzwerk-Traffic also auch die ganzen TCP-IP Geschichten darüber laufen...oder sehe ich da was falsch?

@apollon77 sagte in Tuya. 3.17.0:

VPNs leiten glaube ich nie UDP weiter ... Wireguard ist auch "nur "ein VPN ...

Keine Ahnung, konnte ich bisher keine wirklich aussagekräftigen Infos dazu finden. Darum hab ich inzwischen noch ein wenig rum experimentiert. Unter anderem hab ich mit einem Tool namens Nmap mein (fernes) Netzwerk gescannt und der findet da sowohl offene TCP als auch UDP-Ports...ob das heisst dass der UDP-Traffic auch durch den Tunnel gedrückt wird weiss ich (noch) nicht. Was da aber interessant ist, ist dass bei der Heizung genau die 2 folgende Ports offen sind (naja, eigentlich nur einer da port 9 Wake on Lan ist und der meines wissens nicht über den Tunnel funktioniert...oder wie der Scanner sachreibt: gefiltert wird):
PORT STATE SERVICE
9/tcp filtered discard
6668/tcp open irc?

Hmm...6668 TCP, nicht UDP??? Komisch...ich verstehe es noch nicht wirklich...

@apollon77 sagte in Tuya. 3.17.0:

aber ich bin kein Netzwerk-Experte

...da sind wir dann schon zu zweit... ;)

@apollon77 Sehe ich es richtig dass die 666x Ports (jetzt mal VPN aussen vor) schon nur dazu genutzt um neue Geräte zu finden und die erste Verbindung aufzubauen? Also braucht man die wenn man einmal mit der Tuya-Cloud verbindet für den Betrieb des Tuya-Adapters eigentlich gar nicht mehr?

danke und Gruss

[apollon77]

@urs Die Tuya Cloud liefert am Ende die Geräteliste und deren Crypro-keys, aber keine lokalen IPs. Die IPs erkennt der Adapter über lokale UDP Messages in denen sich die Geräte announcen, die dann mit dem Crypro-Key aus der Cloud entschlüsselt werden können. Dann kennt der Adapter die IP und Protokoll Version. Ab dann geht es per TCP und der IP

[A Former User]

@urs sagte in Tuya. 3.17.0:

@neuschwansteini sagte in Tuya. 3.17.0:

mit den Portfreigaben UDP 666x hast du auch das Routing eingerichtet?

Ich denke schon. Hab in der Fritzbox folgende Einstellungen gemacht:![4e5bd39c-4bdf-47af-a1bd-abfc3c6255be-image.png]

Portfreigaben erlauben nur den Zugriff von aussen auf deine Devices, das hat nix mit Routing zu tun.
Raus senden duerfen die ja normal schon, es sei denn, du hast das Device in der Fritzbox geblockt?

Damit sollten alle von aussen ankommenden Anfragen auf den 3 Ports an die Heizung geschickt werden...oder meinst du was anderes?

ja, das kannste beruhigt wieder loeschen, es sei denn, es soll jemand oder etwas von ausserhalb der Fritzbox auf das Device per udp zugreifen.?

Aber wie bereits früher geschrieben bin ich weit weg von Netzwerk-Profi!

..ich aerger mich seit Jahren in diversen Umfeldern mit Fehlerdiagnosen in Netzwerken rum.. aber da ist auch das Environment total verschieden..

Ist das dann aber nicht nur die Verbindung um den Tunnel aufzubauen welche standardmässig über UDP-Port 51820 aufgebaut wird? Was dann da durch den Tunnel geschoben wird dürfte dann doch was ganz anderes sein, ich kann ja den Wireguard Tunnel so konfigurieren dass der gesammte Netzwerk-Traffic also auch die ganzen TCP-IP Geschichten darüber laufen...oder sehe ich da was falsch?

soviel ich weiss, transportiert die Fritzbox nie alles ueber das VPN, nur das, was angefragt wird.. ( kommt von da, geht nach da)

@apollon77 sagte in Tuya. 3.17.0:

VPNs leiten glaube ich nie UDP weiter ... Wireguard ist auch "nur "ein VPN ...

Keine Ahnung, konnte ich bisher keine wirklich aussagekräftigen Infos dazu finden. Darum hab ich inzwischen noch ein wenig rum experimentiert. Unter anderem hab ich mit einem Tool namens Nmap mein (fernes) Netzwerk gescannt und der findet da sowohl offene TCP als auch UDP-Ports...ob das heisst dass der UDP-Traffic auch durch den Tunnel gedrückt wird weiss ich (noch) nicht. Was da aber interessant ist, ist dass bei der Heizung genau die 2 folgende Ports offen sind (naja, eigentlich nur einer da port 9 Wake on Lan ist und der meines wissens nicht über den Tunnel funktioniert...oder wie der Scanner sachreibt: gefiltert wird):
PORT STATE SERVICE
9/tcp filtered discard
6668/tcp open irc?

Hmm...6668 TCP, nicht UDP??? Komisch...ich verstehe es noch nicht wirklich...

hehe, lass mich raten, du hast bei Nmap den parameter -uS nicht gesetzt, denn ohne den, scannt er nur tcp.
Das bestaetigt die Aussage von @apollon77 , dass erst per UDP und dann per TCP gehandelt wird..

Fuer den udp scan schreibst du "nmap -uSV ipdeinesdevices"

@apollon77 Sehe ich es richtig dass die 666x Ports (jetzt mal VPN aussen vor) schon nur dazu genutzt um neue Geräte zu finden und die erste Verbindung aufzubauen? Also braucht man die wenn man einmal mit der Tuya-Cloud verbindet für den Betrieb des Tuya-Adapters eigentlich gar nicht mehr?

ja, wenn der Adapter einmal den Key hat, kannste die Internetverbindung eigentlich kappen, ich hab das hier mit ein paar Devices gemacht.

[JohnnyBahama]

Habe gerade von 3.16.0 upgegradet. Im Log ist das aufgetaucht:

Cannot patch http-mitm-proxy/lib/ca.js: Error: Cannot find module 'http-mitm-proxy/lib/ca.js'Require stack:- /opt/iobroker/node_modules/iobroker.tuya/main.js

[haselchen]

@johnnybahama

Da sollten wir @apollon77 mit einbeziehen.
Die Meldung hatte ich gestern auch nachdem ich ein wenig mit dem Adapter rumgespielt habe.

[A Former User]

@johnnybahama

bitte eine komplette Ausgabe von
"iobroker diag" zeigen, dann kann man mehr zu dem Paket sagen..

[haselchen]

@neuschwansteini

Daran wird iob diag nichts ändern .
Diese Warnung tritt bei der Installation/ beim Update auf .
Müsste auf Github mal gucken , ob es ein Issue gibt .
Ansonsten ist das nen Fall für @apollon77 😉

[apollon77]

Ist im ersten schritt kein riesen issue weil den Proxy Modus eh keiner mehr nutzen sollte. Also fällt unter "ignore"... komisch dennoch weil das nur passieren kann wenn das modul im npm baum verschwindet

[A Former User]

@haselchen

iob diag aendert nix, zeigt aber, was fuer ein System (wenn jetzt erst auf die aktuelle Version geupdatet wurde) es ist..
denke eher, da ist was nicht ganz so up-to-date.. :) und ok..

Der Fehler waere doch aufgefallen..

[haselchen]

@apollon77

Hab die Proxyeinstellung nie benutzt.
Nun war ich neugierig und hab das mal ausgeführt auf der Registerkarte.
Das ist das Ergebnis:

tuya.0	2025-06-17 13:30:37.254	warn	Terminated (UNCAUGHT_EXCEPTION): Without reason
tuya.0	2025-06-17 13:30:36.244	error	mitm is not a function
tuya.0	2025-06-17 13:30:36.244	error	TypeError: mitm is not a function at startProxy (/opt/iobroker/node_modules/iobroker.tuya/main.js:1608:23) at processMessage (/opt/iobroker/node_modules/iobroker.tuya/main.js:1524:13) at AdapterClass.<anonymous> (/opt/iobroker/node_modules/iobroker.tuya/main.js:114:9) at AdapterClass.emit (node:events:524:28) at change (/opt/iobroker/node_modules/@iobroker/js-controller-adapter/build/cjs/lib/adapter/adapter.js:7309:20) at Immediate.<anonymous> (file:///opt/iobroker/node_modules/@iobroker/db-states-redis/build/esm/lib/states/statesInRedisClient.js:286:37) at process.processImmediate (node:internal/timers:483:21)
tuya.0	2025-06-17 13:30:36.241	error	unhandled promise rejection: mitm is not a function
tuya.0	2025-06-17 13:30:36.240	error	Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch().
tuya.0	2025-06-17 13:30:42.543	warn	Cannot patch http-mitm-proxy/lib/ca.js: Error: Cannot find module 'http-mitm-proxy/lib/ca.js' Require stack: - /opt/iobroker/node_modules/iobroker.tuya/main.js
tuya.0	2025-06-17 13:30:42.395	info	starting. Version 3.17.0 (non-npm: Apollon77/ioBroker.tuya) in /opt/iobroker/node_modules/iobroker.tuya, node: v20.19.2, js-controller: 7.0.7

[apollon77]

@haselchen Ja scheinbar hat npm das Paket gekillt ... wenn du adapter neu installierst müsste es wieder da sein. Why ... no clue

[ATARI]

@apollon77
Moin, moin.
Habe schon in einem anderen Beitrag bzgl. Tuya Adapter gepostet. Deshalb bin ich zu v3.17.0 gewechselt. Das Problem besteht aber auch mit dieser Version. Habe zur Sicherheit auch alles mögliche vorher auf den aktuellen Stand gebracht.

Ich habe das Problem, das mein Tuya IR Gateway alle IR-Kommandos 2 mal sendet, solange der Tuya Adapter mit der Tuya-Cloud verbunden ist.
Wenn ich in den Tuya-Cloud Einstellungen eine ungültige Email-Adresse eingebe, und somit quasi die Verbindung zur Cloud trenne, wird jedes IR-Kommando nur 1 mal gesendet.

Zur Zeit kann ich damit leben…, wäre aber geschmeidiger wenn es diesen "Bug" nicht mehr gäbe.

Ich vermute, das das 1 Kommando vom Adapter kommt und das 2 Kommando kommt dann über die Cloud?

[ATARI]

Aaaaahhhhhh..., jetzt ja.
Habe in den Adapter-Einstellungen:

• Lokale Verbindungen
  • Geräte über die Tuya Cloud abfragen, wenn sie nicht lokal verbunden sind?

deaktiviert.