NEWS
Tuya. 3.17.0
-
@thomas-braun sagte in Tuya. 3.17.0:
In den Paket-Quellen fehlt das security-Repo. Und der cache ist auch krumm:
E: The package cache file is corrupted
Wie kann ich das fixen?
Haste noch n Raspi zuhause? Dann zieh dir n Backup vom iobroker aus der Gartenhuette, setz zuhause n neuen mit Bookworm auf, restore deine Daten und mit der fertigen SD Karte gehste dann in die Gartenhuette und tauschst die aus.
Ich wuerd an dem alten Bullseye nicht mehr rumdoktern. Solange der noch laeuft ist ja gut, aber ich wuerde die Zeit nutzen und die Konfig (ich denke, du hast da mehr als iobroker drauf?) neu aufsetzen. -
@ilovegym Aktuell habe ich keine Probleme, der IOB steht in meinem Ferienhaus, wenn ich Freitag dorthin fahre, werden über GEOFANCY einige Aktionen von TUYA Geräten erwartet. Letzten Freitag war es auch so, IOB hat meine Anreise erkannt, Tuya-Thermostat sollte hochregeln, Auf dem Parkplatz angekommen, sollte die Gartenbeleuchtung und Flurbeleuchtung angehen. IOB hat auch die entsprechenden Tuya Geräte angesprochen, aber es erfolgte keine Auslösung weil das Cloud-Passwort verschwunden war. Anbei ein Bild so wie es gerade aussieht.
```bash Script v.2025-02-02 *** BASE SYSTEM *** Static hostname: iobroker-pi Icon name: computer Operating System: Raspbian GNU/Linux 11 (bullseye) Kernel: Linux 6.1.21-v8+ Architecture: arm64 OS is similar to: debian Model : Raspberry Pi 4 Model B Rev 1.5 Docker : false Virtualization : none Kernel : aarch64 Userland : 32 bit Systemuptime and Load: 13:02:09 up 16 days, 15:31, 1 user, load average: 0.59, 0.45, 0.45 CPU threads: 4 *** LIFE CYCLE STATUS *** Debian 'bullseye' is the current oldstable version. Please upgrade to the latest stable release 'bookworm' in due time! *** RASPBERRY THROTTLING *** Current issues: No throttling issues detected. Previously detected issues: ~ Under-voltage has occurred ~ Arm frequency capping has occurred *** TIME AND TIMEZONES *** Local time: Mon 2025-02-10 13:02:09 CET Universal time: Mon 2025-02-10 12:02:09 UTC RTC time: n/a Time zone: Europe/Amsterdam (CET, +0100) System clock synchronized: yes NTP service: active RTC in local TZ: no *** Users and Groups *** User that called 'iob diag': gthrn HOME=/home/gthrn GROUPS=gthrn adm dialout cdrom sudo audio video plugdev games users input render netdev gpio i2c spi iobroker User that is running 'js-controller': iobroker HOME=/home/iobroker GROUPS=iobroker tty dialout audio video plugdev bluetooth gpio i2c *** DISPLAY-SERVER SETUP *** Display-Server: false Desktop: Terminal: tty *** MEMORY *** total used free shared buff/cache available Mem: 7.9G 1.6G 4.5G 1.0M 1.8G 6.2G Swap: 99M 0B 99M Total: 8.0G 1.6G 4.6G Active iob-Instances: 21 7862 M total memory 1566 M used memory 1658 M active memory 1521 M inactive memory 4482 M free memory 147 M buffer memory 1665 M swap cache 99 M total swap 0 M used swap 99 M free swap *** top - Table Of Processes *** top - 13:02:10 up 16 days, 15:31, 1 user, load average: 0.59, 0.45, 0.45 Tasks: 166 total, 1 running, 165 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.0 us, 4.3 sy, 0.0 ni, 95.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st MiB Mem : 7862.2 total, 4482.4 free, 1566.7 used, 1813.1 buff/cache MiB Swap: 100.0 total, 100.0 free, 0.0 used. 6164.5 avail Mem *** FAILED SERVICES *** UNIT LOAD ACTIVE SUB DESCRIPTION 0 loaded units listed. *** DMESG CRITICAL ERRORS *** 140 CRITICAL ERRORS DETECTED! Check 'sudo dmesg --level=emerg,alert,crit -T' for details *** FILESYSTEM *** Filesystem Type Size Used Avail Use% Mounted on /dev/root ext4 59G 11G 46G 19% / devtmpfs devtmpfs 3.6G 0 3.6G 0% /dev tmpfs tmpfs 3.9G 0 3.9G 0% /dev/shm tmpfs tmpfs 1.6G 1.1M 1.6G 1% /run tmpfs tmpfs 5.0M 4.0K 5.0M 1% /run/lock /dev/sda1 vfat 255M 51M 205M 20% /boot tmpfs tmpfs 787M 0 787M 0% /run/user/1000 Messages concerning ext4 filesystem in dmesg: [Fri Jan 24 21:30:22 2025] Kernel command line: coherent_pool=1M 8250.nr_uarts=0 snd_bcm2835.enable_headphones=0 snd_bcm2835.enable_headphones=1 snd_bcm2835.enable_hdmi=1 snd_bcm2835.enable_hdmi=0 smsc95xx.macaddr=E4:5F:01:DE:B0:AA vc_mem.mem_base=0x3f000000 vc_mem.mem_size=0x3f600000 console=ttyS0,115200 console=tty1 root=PARTUUID=c7239adf-02 rootfstype=ext4 fsck.repair=yes rootwait [Fri Jan 24 21:30:25 2025] EXT4-fs (sda2): INFO: recovery required on readonly filesystem [Fri Jan 24 21:30:25 2025] EXT4-fs (sda2): write access will be enabled during recovery [Fri Jan 24 21:30:26 2025] EXT4-fs (sda2): orphan cleanup on readonly fs [Fri Jan 24 21:30:26 2025] EXT4-fs (sda2): 3 orphan inodes deleted [Fri Jan 24 21:30:26 2025] EXT4-fs (sda2): recovery complete [Fri Jan 24 21:30:26 2025] EXT4-fs (sda2): mounted filesystem with ordered data mode. Quota mode: none. [Fri Jan 24 21:30:26 2025] VFS: Mounted root (ext4 filesystem) readonly on device 8:2. [Fri Jan 24 21:30:30 2025] EXT4-fs (sda2): re-mounted. Quota mode: none. Show mounted filesystems: TARGET SOURCE FSTYPE OPTIONS / /dev/sda2 ext4 rw,noatime `-/boot /dev/sda1 vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro Files in neuralgic directories: /var: 1.4G /var/ 763M /var/log 761M /var/log/journal/3f7e426fbacf414fbfbc4f1541fa25b4 761M /var/log/journal 451M /var/cache Archived and active journals take up 760.2M in the file system. /opt/iobroker/backups: 1.3G /opt/iobroker/backups/ 4.0K /opt/iobroker/backups/zigbee_0 /opt/iobroker/iobroker-data: 588M /opt/iobroker/iobroker-data/ 424M /opt/iobroker/iobroker-data/files 158M /opt/iobroker/iobroker-data/files/admin.admin 157M /opt/iobroker/iobroker-data/files/admin.admin/custom/static/js 157M /opt/iobroker/iobroker-data/files/admin.admin/custom/static The five largest files in iobroker-data are: 19M /opt/iobroker/iobroker-data/files/web.admin/static/js/main.6964fae2.js.map 15M /opt/iobroker/iobroker-data/objects.jsonl 14M /opt/iobroker/iobroker-data/states.jsonl 7.5M /opt/iobroker/iobroker-data/files/web.admin/static/js/main.6964fae2.js 7.4M /opt/iobroker/iobroker-data/files/javascript.admin/custom/static/js/vendors-node_modules_iobroker_adapter-react-v5_node_modules_mui_icons-material_esm_index_js.3514cab0.chunk.js.map USB-Devices by-id: USB-Sticks - Avoid direct links to /dev/tty* in your adapter setups, please always prefer the links 'by-id': No Devices found 'by-id' HINT: Your zigbee.0 COM-Port is NOT matching 'by-id'. Please check your setting: tcp *** NodeJS-Installation *** /usr/bin/nodejs v20.18.1 /usr/bin/node v20.18.1 /usr/bin/npm 10.8.2 /usr/bin/npx 10.8.2 /usr/bin/corepack 0.29.4 nodejs: Installed: 20.18.1-1nodesource1 Candidate: 20.18.1-1nodesource1 Version table: *** 20.18.1-1nodesource1 600 500 https://deb.nodesource.com/node_20.x nodistro/main armhf Packages 100 /var/lib/dpkg/status 20.18.0-1nodesource1 600 500 https://deb.nodesource.com/node_20.x nodistro/main armhf Packages 20.17.0-1nodesource1 600 500 https://deb.nodesource.com/node_20.x nodistro/main armhf Packages 20.16.0-1nodesource1 600 500 https://deb.nodesource.com/node_20.x nodistro/main armhf Packages 20.15.1-1nodesource1 600 500 https://deb.nodesource.com/node_20.x nodistro/main armhf Packages 20.15.0-1nodesource1 600 500 https://deb.nodesource.com/node_20.x nodistro/main armhf Packages 20.14.0-1nodesource1 600 500 https://deb.nodesource.com/node_20.x nodistro/main armhf Packages 20.13.1-1nodesource1 600 500 https://deb.nodesource.com/node_20.x nodistro/main armhf Packages 20.13.0-1nodesource1 600 500 https://deb.nodesource.com/node_20.x nodistro/main armhf Packages 20.12.2-1nodesource1 600 500 https://deb.nodesource.com/node_20.x nodistro/main armhf Packages 20.12.1-1nodesource1 600 500 https://deb.nodesource.com/node_20.x nodistro/main armhf Packages 20.12.0-1nodesource1 600 500 https://deb.nodesource.com/node_20.x nodistro/main armhf Packages 20.11.1-1nodesource1 600 500 https://deb.nodesource.com/node_20.x nodistro/main armhf Packages 20.11.0-1nodesource1 600 500 https://deb.nodesource.com/node_20.x nodistro/main armhf Packages 20.10.0-1nodesource1 600 500 https://deb.nodesource.com/node_20.x nodistro/main armhf Packages 20.9.0-1nodesource1 600 500 https://deb.nodesource.com/node_20.x nodistro/main armhf Packages 20.8.1-1nodesource1 600 500 https://deb.nodesource.com/node_20.x nodistro/main armhf Packages 20.8.0-1nodesource1 600 500 https://deb.nodesource.com/node_20.x nodistro/main armhf Packages 20.7.0-1nodesource1 600 500 https://deb.nodesource.com/node_20.x nodistro/main armhf Packages 20.6.1-1nodesource1 600 500 https://deb.nodesource.com/node_20.x nodistro/main armhf Packages 20.6.0-1nodesource1 600 500 https://deb.nodesource.com/node_20.x nodistro/main armhf Packages 20.5.1-1nodesource1 600 500 https://deb.nodesource.com/node_20.x nodistro/main armhf Packages 20.5.0-1nodesource1 600 500 https://deb.nodesource.com/node_20.x nodistro/main armhf Packages 20.4.0-1nodesource1 600 500 https://deb.nodesource.com/node_20.x nodistro/main armhf Packages 20.3.1-1nodesource1 600 500 https://deb.nodesource.com/node_20.x nodistro/main armhf Packages 20.3.0-1nodesource1 600 500 https://deb.nodesource.com/node_20.x nodistro/main armhf Packages 20.2.0-1nodesource1 600 500 https://deb.nodesource.com/node_20.x nodistro/main armhf Packages 20.1.0-1nodesource1 600 500 https://deb.nodesource.com/node_20.x nodistro/main armhf Packages 20.0.0-1nodesource1 600 500 https://deb.nodesource.com/node_20.x nodistro/main armhf Packages 12.22.12~dfsg-1~deb11u5 500 500 http://raspbian.raspberrypi.org/raspbian bullseye/main armhf Packages Temp directories causing deletion problem: 0 No problems detected Errors in npm tree: 0 No problems detected *** ioBroker-Installation *** ioBroker Status iobroker is running on this host. Objects type: jsonl States type: jsonl Hosts: GTHRN-pi GTHRN-pi (version: 7.0.6, hostname: GTHRN-pi , alive, uptime: 1438305) Core adapters versions js-controller: 7.0.6 admin: 7.4.21 javascript: 8.9.1 nodejs modules from github: 4 +-- iobroker.device-watcher@2.12.1 (git+ssh://git@github.com/iobroker-community-adapters/ioBroker.device-watcher.git#fb49d0b7d1af160318904a143bcea7cab85764c4) +-- iobroker.telegram@4.0.0 (git+ssh://git@github.com/iobroker-community-adapters/ioBroker.telegram.git#b4cfff1fa1dadc8a33905f86208d3b5319c1e585) +-- iobroker.tuya@3.17.0 (git+ssh://git@github.com/Apollon77/ioBroker.tuya.git#007d61f5c03c1150dcf67d40f5967e651caf776c) +-- iobroker.vis-materialdesign@0.5.94 (git+ssh://git@github.com/Scrounger/ioBroker.vis-materialdesign.git#8b7529d493f223dfc4f1d1f632553fcb35bbcc92) Adapter State + system.adapter.admin.0 : admin : GTHRN-pi - enabled, compact disabled, port: 8081, bind: 0.0.0.0 (SSL), run as: admin + system.adapter.backitup.0 : backitup : GTHRN-pi - enabled, compact disabled system.adapter.daikin.0 : daikin : GTHRN-pi - disabled, compact disabled system.adapter.daswetter.0 : daswetter : GTHRN-pi - enabled, compact disabled + system.adapter.device-watcher.0 : device-watcher : GTHRN-pi - enabled, compact disabled + system.adapter.espresense.0 : espresense : GTHRN-pi - enabled, compact disabled system.adapter.feiertage.0 : feiertage : GTHRN-pi - enabled, compact disabled + system.adapter.fullybrowser.0 : fullybrowser : GTHRN-pi - enabled, compact disabled + system.adapter.history.0 : history : GTHRN-pi - enabled, compact disabled + system.adapter.hue.0 : hue : GTHRN-pi - enabled, compact disabled, port: 443 system.adapter.icons-material-png.0 : icons-material-png : GTHRN-pi - disabled system.adapter.icons-material-svg.0 : icons-material-svg : GTHRN-pi - disabled system.adapter.icons-mfd-png.0 : icons-mfd-png : GTHRN-pi - disabled system.adapter.icons-mfd-svg.0 : icons-mfd-svg : GTHRN-pi - disabled + system.adapter.iot.0 : iot : GTHRN-pi - enabled, compact disabled + system.adapter.iot.1 : iot : GTHRN-pi - enabled, compact disabled + system.adapter.iot.2 : iot : GTHRN-pi - enabled, compact disabled + system.adapter.javascript.0 : javascript : GTHRN-pi - enabled, compact disabled + system.adapter.mqtt-client.2 : mqtt-client : GTHRN-pi - enabled, compact disabled, port: 3075 + system.adapter.mqtt.2 : mqtt : GTHRN-pi - enabled, compact disabled, port: 3075, bind: 0.0.0.0 + system.adapter.ping.0 : ping : GTHRN-pi - enabled, compact disabled + system.adapter.ring.0 : ring : GTHRN-pi - enabled, compact disabled + system.adapter.telegram.0 : telegram : GTHRN-pi - enabled, compact disabled, port: 8443, bind: 0.0.0.0 + system.adapter.tuya.0 : tuya : GTHRN-pi - enabled, compact disabled system.adapter.vis-fancyswitch.0 : vis-fancyswitch : GTHRN-pi - disabled system.adapter.vis-google-fonts.0 : vis-google-fonts : GTHRN-pi - enabled, compact disabled system.adapter.vis-hqwidgets.0 : vis-hqwidgets : GTHRN-pi - disabled system.adapter.vis-icontwo.0 : vis-icontwo : GTHRN-pi - disabled, compact disabled + system.adapter.vis-inventwo.0 : vis-inventwo : GTHRN-pi - enabled, compact disabled system.adapter.vis-keyboard.0 : vis-keyboard : GTHRN-pi - disabled system.adapter.vis-metro.0 : vis-metro : GTHRN-pi - disabled system.adapter.vis-timeandweather.0 : vis-timeandweather : GTHRN-pi - disabled system.adapter.vis.0 : vis : GTHRN-pi - enabled, compact disabled + system.adapter.web.0 : web : GTHRN-pi - enabled, compact disabled, port: 8082, bind: 0.0.0.0, run as: admin + system.adapter.zigbee.0 : zigbee : GTHRN-pi - enabled, compact disabled, port: tcp://192.168.188.120:6638 + instance is alive Enabled adapters with bindings + system.adapter.admin.0 : admin : GTHRN-pi - enabled, compact disabled, port: 8081, bind: 0.0.0.0 (SSL), run as: admin + system.adapter.hue.0 : hue : GTHRN-pi - enabled, compact disabled, port: 443 + system.adapter.mqtt-client.2 : mqtt-client : GTHRN-pi - enabled, compact disabled, port: 3075 + system.adapter.mqtt.2 : mqtt : GTHRN-pi - enabled, compact disabled, port: 3075, bind: 0.0.0.0 + system.adapter.telegram.0 : telegram : GTHRN-pi - enabled, compact disabled, port: 8443, bind: 0.0.0.0 + system.adapter.web.0 : web : GTHRN-pi - enabled, compact disabled, port: 8082, bind: 0.0.0.0, run as: admin + system.adapter.zigbee.0 : zigbee : GTHRN-pi - enabled, compact disabled, port: tcp://192.168.188.120:6638 ioBroker-Repositories ┌─────────┬──────────┬─────────────────────────────────────────────────────────┬──────────────┐ │ (index) │ name │ url │ auto upgrade │ ├─────────┼──────────┼─────────────────────────────────────────────────────────┼──────────────┤ │ 0 │ 'stable' │ 'http://download.iobroker.net/sources-dist.json' │ false │ │ 1 │ 'beta' │ 'http://download.iobroker.net/sources-dist-latest.json' │ false │ └─────────┴──────────┴─────────────────────────────────────────────────────────┴──────────────┘ Active repo(s): beta Upgrade policy: none Installed ioBroker-Instances Used repository: beta Adapter "admin" : 7.4.21 , installed 7.4.21 Adapter "backitup" : 3.0.31 , installed 3.0.31 Adapter "daikin" : 1.4.2 , installed 1.4.2 Adapter "daswetter" : 3.2.2 , installed 3.2.2 Adapter "device-watcher": 2.12.1 , installed 2.12.1 Adapter "espresense" : 0.6.3 , installed 0.6.3 Adapter "feiertage" : 1.2.1 , installed 1.2.1 Adapter "fullybrowser" : 3.0.13 , installed 3.0.13 Adapter "history" : 3.0.1 , installed 3.0.1 Adapter "hue" : 3.14.1 , installed 3.14.1 Adapter "icons-material-png": 0.1.0, installed 0.1.0 Adapter "icons-material-svg": 0.1.0, installed 0.1.0 Adapter "icons-mfd-png": 1.2.1 , installed 1.2.1 Adapter "icons-mfd-svg": 1.2.0 , installed 1.2.0 Adapter "iot" : 3.4.5 , installed 3.4.5 Adapter "javascript" : 8.9.1 , installed 8.9.1 Controller "js-controller": 7.0.6 , installed 7.0.6 Adapter "mqtt" : 6.1.2 , installed 6.1.2 Adapter "mqtt-client" : 3.0.0 , installed 2.1.0 [Updatable] Adapter "ping" : 1.7.9 , installed 1.7.9 Adapter "ring" : 6.3.0 , installed 6.3.0 Adapter "simple-api" : 2.8.0 , installed 2.8.0 Adapter "socketio" : 7.0.0 , installed 6.7.1 [Updatable] Adapter "telegram" : 4.0.0 , installed 4.0.0 Adapter "tuya" : 3.17.0 , installed 3.17.0 Adapter "vis" : 1.5.6 , installed 1.5.6 Adapter "vis-fancyswitch": 1.1.0 , installed 1.1.0 Adapter "vis-google-fonts": 1.0.4 , installed 1.0.4 Adapter "vis-hqwidgets": 1.5.1 , installed 1.5.1 Adapter "vis-icontwo" : 1.11.0 , installed 1.11.0 Adapter "vis-inventwo" : 3.3.4 , installed 3.3.4 Adapter "vis-keyboard" : 0.0.2 , installed 0.0.2 Adapter "vis-materialdesign": 0.5.9, installed 0.5.94 Adapter "vis-metro" : 1.2.0 , installed 1.2.0 Adapter "vis-timeandweather": 1.2.2, installed 1.2.2 Adapter "web" : 6.3.1 , installed 6.3.1 Adapter "ws" : 3.0.1 , installed 2.6.2 [Updatable] Adapter "zigbee" : 1.10.14 , installed 1.10.14 Objects and States Please stand by - This may take a while Objects: 6671 States: 5793 *** OS-Repositories and Updates *** Hit:1 http://raspbian.raspberrypi.org/raspbian bullseye InRelease Hit:2 http://archive.raspberrypi.org/debian bullseye InRelease Hit:3 https://deb.nodesource.com/node_20.x nodistro InRelease Reading package lists... Pending Updates: 25 *** Listening Ports *** Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name tcp 0 0 0.0.0.0:3075 0.0.0.0:* LISTEN 1001 15868 1189/io.mqtt.2 tcp 0 0 127.0.0.1:9001 0.0.0.0:* LISTEN 1001 14125 489/iobroker.js-con tcp 0 0 127.0.0.1:9000 0.0.0.0:* LISTEN 1001 12785 489/iobroker.js-con tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 0 1889 517/sshd: /usr/sbin tcp6 0 0 :::3001 :::* LISTEN 1001 16749 1222/io.fullybrowse tcp6 0 0 :::3030 :::* LISTEN 1001 2653440 9688/io.espresense. tcp6 0 0 :::8082 :::* LISTEN 1001 18441 1239/io.web.0 tcp6 0 0 :::8081 :::* LISTEN 1001 2652026 9576/io.admin.0 tcp6 0 0 :::22 :::* LISTEN 0 1891 517/sshd: /usr/sbin udp 0 0 0.0.0.0:68 0.0.0.0:* 0 1906 695/dhcpcd udp 0 0 0.0.0.0:5353 0.0.0.0:* 108 13907 373/avahi-daemon: r udp 0 0 0.0.0.0:50523 0.0.0.0:* 108 13909 373/avahi-daemon: r udp 0 0 0.0.0.0:6666 0.0.0.0:* 1001 2659021 10456/io.tuya.0 udp 0 0 0.0.0.0:6667 0.0.0.0:* 1001 2659022 10456/io.tuya.0 udp6 0 0 :::546 :::* 0 115745 695/dhcpcd udp6 0 0 :::5353 :::* 108 13908 373/avahi-daemon: r udp6 0 0 :::39322 :::* 108 13910 373/avahi-daemon: r *** Log File - Last 25 Lines *** 2025-02-10 13:00:53.082 - info: daswetter.0 (18166) starting. Version 3.2.2 in /opt/iobroker/node_modules/iobroker.daswetter, node: v20.18.1, js-controller: 7.0.6 2025-02-10 13:01:07.031 - info: javascript.0 (28533) script.js.SYSTEM.Devicewatcher_status_an_loggger: true 2025-02-10 13:01:11.150 - info: daswetter.0 (18166) Terminated (ADAPTER_REQUESTED_TERMINATION): All data handled, adapter stopped until next scheduled moment 2025-02-10 13:01:11.670 - info: daswetter.0 (18166) cleaned everything up... 2025-02-10 13:01:11.689 - info: host.GTHRN-pi instance system.adapter.daswetter.0 having pid 18166 terminated with code 11 (ADAPTER_REQUESTED_TERMINATION) 2025-02-10 13:01:22.032 - info: javascript.0 (28533) script.js.SYSTEM.Devicewatcher_status_an_loggger: true 2025-02-10 13:01:37.031 - info: javascript.0 (28533) script.js.SYSTEM.Devicewatcher_status_an_loggger: true 2025-02-10 13:01:52.034 - info: javascript.0 (28533) script.js.SYSTEM.Devicewatcher_status_an_loggger: true 2025-02-10 13:02:00.052 - info: javascript.0 (28533) script.js.SYSTEM.Temp_CPU: 38.4°C 2025-02-10 13:02:07.035 - info: javascript.0 (28533) script.js.SYSTEM.Devicewatcher_status_an_loggger: true 2025-02-10 13:02:22.037 - info: javascript.0 (28533) script.js.SYSTEM.Devicewatcher_status_an_loggger: true 2025-02-10 13:02:37.042 - info: javascript.0 (28533) script.js.SYSTEM.Devicewatcher_status_an_loggger: true 2025-02-10 13:02:56.454 - info: javascript.0 (28533) script.js.SYSTEM.Devicewatcher_status_an_loggger: true 2025-02-10 13:03:07.041 - info: javascript.0 (28533) script.js.SYSTEM.Devicewatcher_status_an_loggger: true 2025-02-10 13:03:07.163 - info: admin.0 (9576) <== Disconnect system.user.admin from ::ffff:192.168.178.196 admin 2025-02-10 13:03:16.659 - info: admin.0 (9576) ==> Connected system.user.admin from ::ffff:192.168.178.196 2025-02-10 13:03:22.044 - info: javascript.0 (28533) script.js.SYSTEM.Devicewatcher_status_an_loggger: true 2025-02-10 13:03:24.803 - warn: host.GTHRN-pi Could not check for new OS updates: Command failed: sudo apt list --upgradeable WARNING: apt does not have a stable CLI interface. Use with caution in scripts. E: Problem renaming the file /var/cache/apt/pkgcache.bin.2vsJAl to /var/cache/apt/pkgcache.bin - rename (2: No such file or directory) W: You may want to run apt-get update to correct these problems E: The package cache file is corruptedHab mir den Tuya Adapter installiert und funktioniert soweit auch, das obwohl der Adapter anzeigt dass er nicht verbunden sei:
Ich vermute mal dass das damit zusammen hängt dass das Tuya Gerät (Heizofen zum Frostschutz) in einem entfernten Netzwerk liegt und somit die Daten nur über die Cloud kommen.Irgendwie hat die Vergangenheit gezeigt dass es eine sehr schlechte Idee ist auf Cloud Lösungen in welcher Form auch immer zu setzen das letzte mal letzte Woche) darum die Frage: Wie wahrscheinlich ist es dass der Tuya Adapter in Zukunft Geräte ansprechen kann welche in einem anderen Netzwerk leben und über eine VPN-Verbindung (Wireguard) mit dem Netzwerk in dem Iobroker lebt verbunden ist? Mein Iobroker ist z. B. in 192.168.1.x und das Tuya Gerät in 10.10.100.x wo noch weitere Geräte Daten an Iobroker senden (z. B. KNX, MQTT...)
Vielen Dank
-
Hab mir den Tuya Adapter installiert und funktioniert soweit auch, das obwohl der Adapter anzeigt dass er nicht verbunden sei:
Ich vermute mal dass das damit zusammen hängt dass das Tuya Gerät (Heizofen zum Frostschutz) in einem entfernten Netzwerk liegt und somit die Daten nur über die Cloud kommen.Irgendwie hat die Vergangenheit gezeigt dass es eine sehr schlechte Idee ist auf Cloud Lösungen in welcher Form auch immer zu setzen das letzte mal letzte Woche) darum die Frage: Wie wahrscheinlich ist es dass der Tuya Adapter in Zukunft Geräte ansprechen kann welche in einem anderen Netzwerk leben und über eine VPN-Verbindung (Wireguard) mit dem Netzwerk in dem Iobroker lebt verbunden ist? Mein Iobroker ist z. B. in 192.168.1.x und das Tuya Gerät in 10.10.100.x wo noch weitere Geräte Daten an Iobroker senden (z. B. KNX, MQTT...)
Vielen Dank
Tuya Devices arbeiten mit UDP Ports 6666, 6668 und ab und zu mal mit 6667, also duerfen die nicht geblockt sein in deinem Netzwerk.
Cloud hat immer den Nachteil, dass die Verbindung oder der Server mal nicht da ist, das ist auch beim VPN so.
-
Tuya Devices arbeiten mit UDP Ports 6666, 6668 und ab und zu mal mit 6667, also duerfen die nicht geblockt sein in deinem Netzwerk.
Cloud hat immer den Nachteil, dass die Verbindung oder der Server mal nicht da ist, das ist auch beim VPN so.
@ilovegym Du meinst, wenn ich die Ports öffne müsste eine direkte kommunikation ohne TuyaCloud dazwischen möglich sein? Werde es mal probieren...mal schauen ob ich das hin bekomme, Netzwerk einrichten ist nicht gerade mein Lieblingshobby... ;)
Vielen Dank
-
@ilovegym Du meinst, wenn ich die Ports öffne müsste eine direkte kommunikation ohne TuyaCloud dazwischen möglich sein? Werde es mal probieren...mal schauen ob ich das hin bekomme, Netzwerk einrichten ist nicht gerade mein Lieblingshobby... ;)
Vielen Dank
Genau 👍
-
Tuya Devices arbeiten mit UDP Ports 6666, 6668 und ab und zu mal mit 6667, also duerfen die nicht geblockt sein in deinem Netzwerk.
Cloud hat immer den Nachteil, dass die Verbindung oder der Server mal nicht da ist, das ist auch beim VPN so.
@ilovegym sagte in Tuya. 3.17.0:
Cloud hat immer den Nachteil, dass die Verbindung oder der Server mal nicht da ist, das ist auch beim VPN so.
Mit Verbindungsunterbrüchen kann ich leben, nicht aber mit dem Fakt dass bei Cloud-Diensten irgend ein Geldgeiler Manager weit weg entscheidet ob ich den Dienst morgen noch nutzen kann oder nicht.
-
Genau 👍
-
@ilovegym sagte in Tuya. 3.17.0:
Cloud hat immer den Nachteil, dass die Verbindung oder der Server mal nicht da ist, das ist auch beim VPN so.
Mit Verbindungsunterbrüchen kann ich leben, nicht aber mit dem Fakt dass bei Cloud-Diensten irgend ein Geldgeiler Manager weit weg entscheidet ob ich den Dienst morgen noch nutzen kann oder nicht.
Naja Tuya wird man nicht einfach abschalten, aber es ist ja teilweise schon kostenpflichtig…
-
Naja Tuya wird man nicht einfach abschalten, aber es ist ja teilweise schon kostenpflichtig…
@ilovegym Wahrscheinlich hast du recht dass Tuya nicht einfach so abgeschalten wird, zumindest hoffe ich dass du recht behältst. Wenn ich die Geschichte so Verfolge würde ich dafür allerdings nicht die Hand ins Feuer legen.
Vor einer Woche kam ich nach Hause, rief Alexa zu sie solle mein Lieblings-Stream abspielen. Es kam was ganz anderes. Die Recherche zeigte dass Amazon die Bedingungen geändert haben, der Programmierer des Skills (verständlicherweise) darum keine Lust mehr hat auf die daraus resultierenden Kosten sitzen zu bleiben und überhaupt weiter zu programmieren...
Oder eine CAD-App welche ich sogar gekauft hatte, dann ein Jahr oder so nicht gebraucht habe. Anschliessend hätte ich bezahlen sollen um wieder an meine Daten zu kommen weil nur noch 2 oder 3 Dateien in der Cloud frei zugänglich wären...
Oder die ganze Logitech-Harmony-Geschichte wo es auch nur eine Frage der Zeit ist bis die Server abgeschalten werden...
Oder eben erst die Abschaltung von UKW in CH wo tausende Privatpersonen genötigt wurden ihre voll funktionsfähige Hardware zu entsorgen und neue zu kaufen (natürlich auf eigene Kosten) weil der UKW-Unterhalt angeblich zu teuer sei...
Da traue ich den Grosskonzernen und auch den nicht so grossen Konzerne und deren Manager noch einiges zu und versuche alles mir mögliche in die Wege zu leiten um da so unabhängig wie möglich unterwegs in die Zukunft zu sein. Gelingt mir nicht überall, ich geb mir aber immer mehr mühe... ;)
Sorry für das abschweifen.
-
@ilovegym Wahrscheinlich hast du recht dass Tuya nicht einfach so abgeschalten wird, zumindest hoffe ich dass du recht behältst. Wenn ich die Geschichte so Verfolge würde ich dafür allerdings nicht die Hand ins Feuer legen.
Vor einer Woche kam ich nach Hause, rief Alexa zu sie solle mein Lieblings-Stream abspielen. Es kam was ganz anderes. Die Recherche zeigte dass Amazon die Bedingungen geändert haben, der Programmierer des Skills (verständlicherweise) darum keine Lust mehr hat auf die daraus resultierenden Kosten sitzen zu bleiben und überhaupt weiter zu programmieren...
Oder eine CAD-App welche ich sogar gekauft hatte, dann ein Jahr oder so nicht gebraucht habe. Anschliessend hätte ich bezahlen sollen um wieder an meine Daten zu kommen weil nur noch 2 oder 3 Dateien in der Cloud frei zugänglich wären...
Oder die ganze Logitech-Harmony-Geschichte wo es auch nur eine Frage der Zeit ist bis die Server abgeschalten werden...
Oder eben erst die Abschaltung von UKW in CH wo tausende Privatpersonen genötigt wurden ihre voll funktionsfähige Hardware zu entsorgen und neue zu kaufen (natürlich auf eigene Kosten) weil der UKW-Unterhalt angeblich zu teuer sei...
Da traue ich den Grosskonzernen und auch den nicht so grossen Konzerne und deren Manager noch einiges zu und versuche alles mir mögliche in die Wege zu leiten um da so unabhängig wie möglich unterwegs in die Zukunft zu sein. Gelingt mir nicht überall, ich geb mir aber immer mehr mühe... ;)
Sorry für das abschweifen.
@urs sagte in Tuya. 3.17.0:
Vor einer Woche kam ich nach Hause, rief Alexa zu sie solle mein Lieblings-Stream abspielen. Es kam was ganz anderes. Die Recherche zeigte dass Amazon die Bedingungen geändert haben, der Programmierer des Skills (verständlicherweise) darum keine Lust mehr hat auf die daraus resultierenden Kosten sitzen zu bleiben
Lass mich raten "Mein Radio" Skill?
Nutze ich so selten, dass ich die erste gar nicht und dann finale Änderung erst spät mitbekommen habe. :relieved: -
@urs sagte in Tuya. 3.17.0:
Vor einer Woche kam ich nach Hause, rief Alexa zu sie solle mein Lieblings-Stream abspielen. Es kam was ganz anderes. Die Recherche zeigte dass Amazon die Bedingungen geändert haben, der Programmierer des Skills (verständlicherweise) darum keine Lust mehr hat auf die daraus resultierenden Kosten sitzen zu bleiben
Lass mich raten "Mein Radio" Skill?
Nutze ich so selten, dass ich die erste gar nicht und dann finale Änderung erst spät mitbekommen habe. :relieved: -
Tuya Devices arbeiten mit UDP Ports 6666, 6668 und ab und zu mal mit 6667, also duerfen die nicht geblockt sein in deinem Netzwerk.
Cloud hat immer den Nachteil, dass die Verbindung oder der Server mal nicht da ist, das ist auch beim VPN so.
@ilovegym sagte in Tuya. 3.17.0:
Tuya Devices arbeiten mit UDP Ports 6666, 6668 und ab und zu mal mit 6667, also duerfen die nicht geblockt sein in deinem Netzwerk.
Vielen Dank. Hab die Ports geöffnet und der Adapter wird jetzt auch bei "Verbunden mit Gerät oder Dienst" grün. Allerdings musste ich noch die IP-Adresse in den Datenpunkten manuell ändern. Da war immer noch die 192.168.1.219 drin welche die Heizung vom DHCP-Server bekommen hatte als ich es Daheim getestet habe. Nachdem ich die manuell auf die neue welche sie jetzt hat (10.10.100.11) gesetzt habe läuft es.
Danke nochmal für die Hilfe und Gruss
Urs -
Hab mir den Tuya Adapter installiert und funktioniert soweit auch, das obwohl der Adapter anzeigt dass er nicht verbunden sei:
Ich vermute mal dass das damit zusammen hängt dass das Tuya Gerät (Heizofen zum Frostschutz) in einem entfernten Netzwerk liegt und somit die Daten nur über die Cloud kommen.Irgendwie hat die Vergangenheit gezeigt dass es eine sehr schlechte Idee ist auf Cloud Lösungen in welcher Form auch immer zu setzen das letzte mal letzte Woche) darum die Frage: Wie wahrscheinlich ist es dass der Tuya Adapter in Zukunft Geräte ansprechen kann welche in einem anderen Netzwerk leben und über eine VPN-Verbindung (Wireguard) mit dem Netzwerk in dem Iobroker lebt verbunden ist? Mein Iobroker ist z. B. in 192.168.1.x und das Tuya Gerät in 10.10.100.x wo noch weitere Geräte Daten an Iobroker senden (z. B. KNX, MQTT...)
Vielen Dank
@urs Also generell funktioniert Tuya was Discovery angeht und so via UDP. Damit ist VPN raus.
AM Ende wenn Du die Geräte per Cloud Sync einmalig reingeholt hast kannst Du die Objekte editieren und die IP adden, dann sollte er versuchen zu der IP zu verbinden. Das geht dann ohne Cloud.Edit: Ahh ok haste auch selbst gefunden. Super
-
@urs Also generell funktioniert Tuya was Discovery angeht und so via UDP. Damit ist VPN raus.
AM Ende wenn Du die Geräte per Cloud Sync einmalig reingeholt hast kannst Du die Objekte editieren und die IP adden, dann sollte er versuchen zu der IP zu verbinden. Das geht dann ohne Cloud.Edit: Ahh ok haste auch selbst gefunden. Super
@apollon77 Verstehe ich es richtig dass Wireguard UDP-Ports gar nicht weiter leitet und es somit in meinem Fall gar keine Rolle spielt ob ich die UDP 666x frei gebe oder nicht?
Würde zumindest meine bisherigen Beobachtungen halbwegs erklären, denn wenn ich die Option vom Adapter "einmalig mit der Cloud verbinden" nutze (und die Interne IP der Heizung richtig eingestellt habe) dann wird verbunden, egal ob ich die Ports offen oder geschlossen habe.
Was ich noch nicht ganz verstehe:
Ab und zu geht der Adapter auf rot (nur das "verbunden mit Gerät oder Dienst"), der Adapter zeigt mir dann "
Status: 1 Geräte im Netzwerk gefunden, 0 Geräte lokal verbunden, 1 mit bekanntem Schema, 1 für lokale Echtzeitaktualisierungen und Steuerung initialisiert." aber empfängt trotzdem Daten von der Heizung, auch wenn ich im Adapter unter "Geräte über Tuya Cloud abfragen wenn nicht lokal vorhanden" den Haken nicht gesetzt habe.
Soweit könnte ich damit leben da es die Funktion nicht wirklich tangiert. Ist nur etwas verwirrend und unschön wenn der Adapter rot ist...Starte ich den Adapter kurz neu wird er wieder für mehrere Tage grün und er zeigt auch wieder "1 Gerät lokal verbunden".
Wieso die Verbindung mit Gerät oder Dienst ab und zu rot wird weiss ich noch nicht sicher, eine Vermutung ist dass das VPN kurz die Verbindung verliert (steht zumindest ab und zu mal so im Logbuch vom Router) aber nach wenigen Sekunden wieder da ist.Wie geschrieben, soweit könnte ich damit leben, letztes Wochenende passierte aber was anderes: Ein Netzteil der einen Fritzbox (da wo auch der Iobroker dran hängt) hat sich in die ewigen Jagdgründe verabschiedet. Die VPN-Verbindung war dementsprechend auch mehrere Stunden unterbrochen. Und ich hab anschliessend eine neue öffentliche IP-Adresse erhalten. Über Dyndns wurde nach Tausch des Netzteils die VPN-Verbindung auch wieder aufgebaut und alles lief wieder..ausser der Tuya-Adapter, der war rot und hat auch keine Daten empfangen. Erst nachdem ich ihn (mehrere Stunden später) neu gestartet habe lief er wieder und ist seit 2 Tagen grün...
Irgendwie verstehe ich noch nicht ganz wieso er einmal Daten bekommt obwohl rot und einmal nicht...
Danke und Gruss -
@apollon77 Verstehe ich es richtig dass Wireguard UDP-Ports gar nicht weiter leitet und es somit in meinem Fall gar keine Rolle spielt ob ich die UDP 666x frei gebe oder nicht?
Würde zumindest meine bisherigen Beobachtungen halbwegs erklären, denn wenn ich die Option vom Adapter "einmalig mit der Cloud verbinden" nutze (und die Interne IP der Heizung richtig eingestellt habe) dann wird verbunden, egal ob ich die Ports offen oder geschlossen habe.
Was ich noch nicht ganz verstehe:
Ab und zu geht der Adapter auf rot (nur das "verbunden mit Gerät oder Dienst"), der Adapter zeigt mir dann "
Status: 1 Geräte im Netzwerk gefunden, 0 Geräte lokal verbunden, 1 mit bekanntem Schema, 1 für lokale Echtzeitaktualisierungen und Steuerung initialisiert." aber empfängt trotzdem Daten von der Heizung, auch wenn ich im Adapter unter "Geräte über Tuya Cloud abfragen wenn nicht lokal vorhanden" den Haken nicht gesetzt habe.
Soweit könnte ich damit leben da es die Funktion nicht wirklich tangiert. Ist nur etwas verwirrend und unschön wenn der Adapter rot ist...Starte ich den Adapter kurz neu wird er wieder für mehrere Tage grün und er zeigt auch wieder "1 Gerät lokal verbunden".
Wieso die Verbindung mit Gerät oder Dienst ab und zu rot wird weiss ich noch nicht sicher, eine Vermutung ist dass das VPN kurz die Verbindung verliert (steht zumindest ab und zu mal so im Logbuch vom Router) aber nach wenigen Sekunden wieder da ist.Wie geschrieben, soweit könnte ich damit leben, letztes Wochenende passierte aber was anderes: Ein Netzteil der einen Fritzbox (da wo auch der Iobroker dran hängt) hat sich in die ewigen Jagdgründe verabschiedet. Die VPN-Verbindung war dementsprechend auch mehrere Stunden unterbrochen. Und ich hab anschliessend eine neue öffentliche IP-Adresse erhalten. Über Dyndns wurde nach Tausch des Netzteils die VPN-Verbindung auch wieder aufgebaut und alles lief wieder..ausser der Tuya-Adapter, der war rot und hat auch keine Daten empfangen. Erst nachdem ich ihn (mehrere Stunden später) neu gestartet habe lief er wieder und ist seit 2 Tagen grün...
Irgendwie verstehe ich noch nicht ganz wieso er einmal Daten bekommt obwohl rot und einmal nicht...
Danke und Grussalsooo ... mit den Portfreigaben UDP 666x hast du auch das Routing eingerichtet?
Wenn deine Heizung ins Internet zu den Tuya Servern sendet, dann gehts ja ueber die Cloud.. da ist dann local udp wurscht.Das kann alles sein, da alles, was UDP nutzt, keinen Check macht, UDP Packets werden hingeworfen, ob die ankommen oder nicht, ist wurscht.(bei TCP werden die Packets geprueft, und wenn defekt, neue angefordert)
Dafuer isses schnell.Wireguard VPN funktioniert uebrigens nur mit UDP - mit TCP waere es langsam.
Devices mit UDP Protokoll sind nur lokal sinnvoll, wenn alles in einem Netzwerksegment stattfindet, und es auf schnelligkeit ankommt.
Link zum Erklaerbaer fuer TCP
-
@apollon77 Verstehe ich es richtig dass Wireguard UDP-Ports gar nicht weiter leitet und es somit in meinem Fall gar keine Rolle spielt ob ich die UDP 666x frei gebe oder nicht?
Würde zumindest meine bisherigen Beobachtungen halbwegs erklären, denn wenn ich die Option vom Adapter "einmalig mit der Cloud verbinden" nutze (und die Interne IP der Heizung richtig eingestellt habe) dann wird verbunden, egal ob ich die Ports offen oder geschlossen habe.
Was ich noch nicht ganz verstehe:
Ab und zu geht der Adapter auf rot (nur das "verbunden mit Gerät oder Dienst"), der Adapter zeigt mir dann "
Status: 1 Geräte im Netzwerk gefunden, 0 Geräte lokal verbunden, 1 mit bekanntem Schema, 1 für lokale Echtzeitaktualisierungen und Steuerung initialisiert." aber empfängt trotzdem Daten von der Heizung, auch wenn ich im Adapter unter "Geräte über Tuya Cloud abfragen wenn nicht lokal vorhanden" den Haken nicht gesetzt habe.
Soweit könnte ich damit leben da es die Funktion nicht wirklich tangiert. Ist nur etwas verwirrend und unschön wenn der Adapter rot ist...Starte ich den Adapter kurz neu wird er wieder für mehrere Tage grün und er zeigt auch wieder "1 Gerät lokal verbunden".
Wieso die Verbindung mit Gerät oder Dienst ab und zu rot wird weiss ich noch nicht sicher, eine Vermutung ist dass das VPN kurz die Verbindung verliert (steht zumindest ab und zu mal so im Logbuch vom Router) aber nach wenigen Sekunden wieder da ist.Wie geschrieben, soweit könnte ich damit leben, letztes Wochenende passierte aber was anderes: Ein Netzteil der einen Fritzbox (da wo auch der Iobroker dran hängt) hat sich in die ewigen Jagdgründe verabschiedet. Die VPN-Verbindung war dementsprechend auch mehrere Stunden unterbrochen. Und ich hab anschliessend eine neue öffentliche IP-Adresse erhalten. Über Dyndns wurde nach Tausch des Netzteils die VPN-Verbindung auch wieder aufgebaut und alles lief wieder..ausser der Tuya-Adapter, der war rot und hat auch keine Daten empfangen. Erst nachdem ich ihn (mehrere Stunden später) neu gestartet habe lief er wieder und ist seit 2 Tagen grün...
Irgendwie verstehe ich noch nicht ganz wieso er einmal Daten bekommt obwohl rot und einmal nicht...
Danke und Gruss -
alsooo ... mit den Portfreigaben UDP 666x hast du auch das Routing eingerichtet?
Wenn deine Heizung ins Internet zu den Tuya Servern sendet, dann gehts ja ueber die Cloud.. da ist dann local udp wurscht.Das kann alles sein, da alles, was UDP nutzt, keinen Check macht, UDP Packets werden hingeworfen, ob die ankommen oder nicht, ist wurscht.(bei TCP werden die Packets geprueft, und wenn defekt, neue angefordert)
Dafuer isses schnell.Wireguard VPN funktioniert uebrigens nur mit UDP - mit TCP waere es langsam.
Devices mit UDP Protokoll sind nur lokal sinnvoll, wenn alles in einem Netzwerksegment stattfindet, und es auf schnelligkeit ankommt.
Link zum Erklaerbaer fuer TCP
@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
-
@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
@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
-
@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
@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.
-
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
Support us
755
Online32.5k
Benutzer81.6k
Themen1.3m
Beiträge