Problem Connecting to Tuya Device

Buckskin · 15 April 2021 18:11

I use the node-red-contrib-tuya-smart-device node to connect to my Tuya devices and up until a few days ago everything was fine. However, the node now no longer connects to the devices.

I do not think that it is either the node or Node-Red that is the direct cause of the problem because I loaded the node into another instance of Node-Red and it works OK.

The only difference in the two instances is that the one failing runs on a Pi 3 using a wireless connection to the network and the other is on a Pi 4 using ethernet. The Node-Red log of each instance is below.

Failing Log

Starting as a systemd service.
15 Apr 15:52:13 - [info]
Welcome to Node-RED
===================
15 Apr 15:52:13 - [info] Node-RED version: v1.3.2
15 Apr 15:52:13 - [info] Node.js  version: v14.16.1
15 Apr 15:52:13 - [info] Linux 5.10.17-v7+ arm LE
15 Apr 15:52:14 - [info] Loading palette nodes
15 Apr 15:52:22 - [info] +-----------------------------------------------------
15 Apr 15:52:22 - [info] | uibuilder initialised:
15 Apr 15:52:22 - [info] |   root folder: /home/pi/.node-red/uibuilder
15 Apr 15:52:22 - [info] |   version . .: 3.2.1
15 Apr 15:52:22 - [info] |   packages . : socket.io,jquery,vue,bootstrap,bootstrap-vue
15 Apr 15:52:22 - [info] +-----------------------------------------------------
15 Apr 15:52:23 - [info] Worldmap version 2.13.1
15 Apr 15:52:23 - [info] Dashboard version 2.28.2 started at /ui
15 Apr 15:52:24 - [info] Settings file  : /home/pi/.node-red/settings.js
15 Apr 15:52:24 - [info] HTTP Static    : /home/pi/.node-red/public
15 Apr 15:52:24 - [info] Context store  : 'memoryOnly' [module=memory]
15 Apr 15:52:24 - [info] Context store  : 'file' [module=localfilesystem]
15 Apr 15:52:24 - [info] User directory : /home/pi/.node-red
15 Apr 15:52:24 - [warn] Projects disabled : editorTheme.projects.enabled=false
15 Apr 15:52:24 - [info] Flows file     : /home/pi/.node-red/flows.json
15 Apr 15:52:24 - [info] Server now running at http://127.0.0.1:1880/
15 Apr 15:52:24 - [info] Starting flows
15 Apr 15:52:26 - [info] Started flows
15 Apr 15:52:26 - [info] [sqlitedb:22bc96f2.863d0a] opened /media/usbDrive/HomeAutomation.db ok
15 Apr 15:52:26 - [info] [mqtt-broker:MQTT 21] Connected to broker: mqtt://192.168.1.21:1883
15 Apr 15:52:26 - [info] [mqtt-broker:MQTT 20] Connected to broker: mqtt://192.168.1.20:1883
15 Apr 15:53:56 - [info] Stopping modified nodes
15 Apr 15:53:57 - [info] Stopped modified nodes
15 Apr 15:53:57 - [info] Starting modified nodes
15 Apr 15:53:57 - [info] [tuya-smart-device:Study Light] Recieved the config {"id":"2bb98158.7e48be","type":"tuya-smart-device","z":"2be5023b.9f1aee","deviceName":"Study Light","deviceId":"xx","deviceKey":"xx","deviceIp":"","retryTimeout":1000,"findTimeout":1000,"tuyaVersion":"3.1","x":1360,"y":860,"wires":[[]]}
15 Apr 15:53:57 - [info] [tuya-smart-device:Study Light] Connecting to Tuya with params {"id":"xx","key":"xx","ip":"","issueGetOnConnect":false,"nullPayloadOnJSONError":false,"version":"3.1"} , findTimeout :  1000 , retryTimeout:  1000
15 Apr 15:53:57 - [info] Started modified nodes
15 Apr 15:53:58 - [info] [tuya-smart-device:Study Light] initiating the find command
15 Apr 15:54:01 - [error] [tuya-smart-device:Study Light] Error: Error from socket
(node:7559) UnhandledPromiseRejectionWarning: Error: connect EHOSTUNREACH 192.168.1.153:6668
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1146:16)
(Use `node --trace-warnings ...` to show where the warning was created)
(node:7559) UnhandledPromiseRejectionWarning: 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(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:7559) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
15 Apr 15:54:01 - [info] [tuya-smart-device:Study Light] Disconnected from tuyaDevice.
15 Apr 15:54:04 - [error] [tuya-smart-device:Study Light] Error: Error from socket
(node:7559) UnhandledPromiseRejectionWarning: Error: connect EHOSTUNREACH 192.168.1.153:6668
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1146:16)
(node:7559) UnhandledPromiseRejectionWarning: 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(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 2)
15 Apr 15:54:05 - [info] [tuya-smart-device:Study Light] Disconnected from tuyaDevice.

Successful Log.

15 Apr 18:37:48 - [info]
Welcome to Node-RED
===================
15 Apr 18:37:48 - [info] Node-RED version: v1.3.1
15 Apr 18:37:48 - [info] Node.js  version: v14.16.1
15 Apr 18:37:48 - [info] Linux 5.10.17-v7l+ arm LE
15 Apr 18:37:48 - [info] Loading palette nodes
15 Apr 18:37:54 - [info] +-----------------------------------------------------
15 Apr 18:37:54 - [info] | uibuilder initialised:
15 Apr 18:37:54 - [info] |   root folder: /home/pi/.node-red/uibuilder
15 Apr 18:37:54 - [info] |   version . .: 3.2.1
15 Apr 18:37:54 - [info] |   packages . : jquery,socket.io,vue,bootstrap,bootstrap-vue
15 Apr 18:37:54 - [info] +-----------------------------------------------------
15 Apr 18:37:54 - [info] Worldmap version 2.13.0
15 Apr 18:37:54 - [info] Dashboard version 2.28.2 started at /ui
15 Apr 18:37:55 - [info] Settings file  : /home/pi/.node-red/settings.js
15 Apr 18:37:55 - [info] HTTP Static    : /home/pi/.node-red/public
15 Apr 18:37:55 - [info] Context store  : 'memoryOnly' [module=memory]
15 Apr 18:37:55 - [info] Context store  : 'file' [module=localfilesystem]
15 Apr 18:37:55 - [info] User directory : /home/pi/.node-red
15 Apr 18:37:55 - [warn] Projects disabled : editorTheme.projects.enabled=false
15 Apr 18:37:55 - [info] Flows file     : /home/pi/.node-red/flows.json
15 Apr 18:37:55 - [info] Server now running at http://127.0.0.1:1880/
15 Apr 18:37:55 - [info] Starting flows
15 Apr 18:37:56 - [info] [tuya-smart-device:Study Light] Recieved the config {"id":"d14f0d82.934d1","type":"tuya-smart-device","z":"4f112ad7.fccf94","deviceName":"Study Light","deviceId":"xx","deviceKey":"xx","deviceIp":"","retryTimeout":1000,"findTimeout":1000,"tuyaVersion":"3.1","x":780,"y":1300,"wires":[[]]}
15 Apr 18:37:56 - [info] [tuya-smart-device:Study Light] Connecting to Tuya with params {"id":"xx","key":"xx","ip":"","issueGetOnConnect":false,"nullPayloadOnJSONError":false,"version":"3.1"} , findTimeout :  1000 , retryTimeout:  1000
15 Apr 18:37:56 - [info] Started flows
15 Apr 18:37:56 - [info] [sqlitedb:7ef7e7da.8bc2b8] opened /media/usbDrive/HomeAutomation.db ok
15 Apr 18:37:56 - [info] [zigbee2mqtt-server:83162ab9.755208] MQTT Connected
15 Apr 18:37:56 - [info] [zigbee2mqtt-server:83162ab9.755208] Refreshing devices
15 Apr 18:37:56 - [info] [mqtt-broker:MQTT 20] Connected to broker: mqtt://192.168.1.20:1883
15 Apr 18:37:56 - [info] [mqtt-broker:MQTT 21] Connected to broker: mqtt://192.168.1.21:1883
15 Apr 18:37:56 - [error] zigbee2mqtt: bridge status: offline
15 Apr 18:37:56 - [info] [zigbee2mqtt-server:83162ab9.755208] MQTT Subscribed to: "zigbee2mqtt/#
15 Apr 18:37:57 - [info] [tuya-smart-device:Study Light] initiating the find command
15 Apr 18:38:01 - [info] [tuya-smart-device:Study Light] Connected to device! xx

I have tried upgrading the node-red-contrib-tuya-smart-device from v3.10 to 4.06 but it did not make any difference. Both logs above are using v3.10. v4.06 generates the same error message.

If anyone has any ideas as to what might be causing the problem I would love to hear from you.

(If of interest the Tuya devices work with both Google Home and Smartlife app both before and after the problem occurred)

Colin · 15 April 2021 21:07

It is nothing to do with node red or the node, it is the fact the Pi running node red cannot reach that ip address. That could be because there is no such device, or because you have a misconfiguration of the pi or the router or something else in the network which means that the pi cannot get to that address.

Buckskin · 16 April 2021 08:51

Unfortunately the device is at that address and is reached using the same configuration so your comment on THAT Pi not being able to reach it is undoubtedly correct. I was hoping that you might have an idea as to why?

As you can see the Pi can talk to the network as it is communicating with the MQTT broker. There is also the weird fact that ONE of the Tuya devices connects OK, plus all the devices were connecting. The only change as far as I can remember is running apt update & upgrade.

I am guessing that I will have to reinstall everything. Not the end of the world

Colin · 16 April 2021 09:54

What do you see if, on that pi, and on the other machine, you run
ping 192.168.1.153
also try
traceroute 192.168.1.153

What does
ip addr
show. Please copy/paste the text here.

That is unlikely to make a difference. This is not Windows.

Buckskin · 16 April 2021 18:38

From Pi 192.168.1.20

pi@PiHome:~ $ ping 192.168.1.153
PING 192.168.1.153 (192.168.1.153) 56(84) bytes of data.
From 192.168.1.20 icmp_seq=1 Destination Host Unreachable
From 192.168.1.20 icmp_seq=2 Destination Host Unreachable
From 192.168.1.20 icmp_seq=3 Destination Host Unreachable
From 192.168.1.20 icmp_seq=4 Destination Host Unreachable
From 192.168.1.20 icmp_seq=5 Destination Host Unreachable
From 192.168.1.20 icmp_seq=6 Destination Host Unreachable
^C
--- 192.168.1.153 ping statistics ---
15 packets transmitted, 0 received, +12 errors, 100% packet loss, time 558ms
pipe 4
pi@PiHome:~ $ traceroute 192.168.1.153
traceroute to 192.168.1.153 (192.168.1.153), 30 hops max, 60 byte packets
 1  192.168.1.20 (192.168.1.20)  3090.666 ms !H  3090.466 ms !H  3090.405 ms !H
pi@PiHome:~ $ ping 192.168.1.235
PING 192.168.1.235 (192.168.1.235) 56(84) bytes of data.
64 bytes from 192.168.1.235: icmp_seq=1 ttl=255 time=59.6 ms
64 bytes from 192.168.1.235: icmp_seq=2 ttl=255 time=79.7 ms
64 bytes from 192.168.1.235: icmp_seq=3 ttl=255 time=102 ms
64 bytes from 192.168.1.235: icmp_seq=4 ttl=255 time=22.2 ms
64 bytes from 192.168.1.235: icmp_seq=5 ttl=255 time=44.5 ms
^C
--- 192.168.1.235 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 11ms
rtt min/avg/max/mdev = 22.200/61.672/102.382/27.706 ms
pi@PiHome:~ $ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether b8:27:eb:f1:96:27 brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether b8:27:eb:a4:c3:72 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.20/24 brd 192.168.1.255 scope global dynamic noprefixroute wlan0
       valid_lft 85605sec preferred_lft 71562sec
    inet6 2a00:23c6:290d:f601:6ef:71ef:16a7:3e5b/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 285sec preferred_lft 105sec
    inet6 fe80::fedf:1618:2fd3:cb03/64 scope link
       valid_lft forever preferred_lft forever

From Pi 192.168.1.21

pi@RaspberryUSB:~ $ ping 192.168.1.153
PING 192.168.1.153 (192.168.1.153) 56(84) bytes of data.
64 bytes from 192.168.1.153: icmp_seq=1 ttl=255 time=27.0 ms
64 bytes from 192.168.1.153: icmp_seq=2 ttl=255 time=52.3 ms
64 bytes from 192.168.1.153: icmp_seq=3 ttl=255 time=72.1 ms
64 bytes from 192.168.1.153: icmp_seq=4 ttl=255 time=94.2 ms
64 bytes from 192.168.1.153: icmp_seq=5 ttl=255 time=120 ms
^C
--- 192.168.1.153 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 9ms
rtt min/avg/max/mdev = 26.969/73.137/120.122/32.296 ms
pi@RaspberryUSB:~ $ traceroute 192.168.1.153
traceroute to 192.168.1.153 (192.168.1.153), 30 hops max, 60 byte packets
 1  192.168.1.153 (192.168.1.153)  72.675 ms  153.084 ms  154.340 ms

pi@RaspberryUSB:~ $ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether dc:a6:32:66:6f:d2 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.21/24 brd 192.168.1.255 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether dc:a6:32:66:6f:d3 brd ff:ff:ff:ff:ff:ff

I hope you can make something of this, because apart from confirming that PiHome cannot contact the device and that my other Pi can (both on the same network and MQTT works between the two Pis) I am stumped.

I also included the ping to the only Tuya device that works on PiHome at 192.168.1.235.

My comment about reinstalling was because both Pis WERE talking to the Tuya devices so somehow I have messed up a setting on PiHome.

Colin · 17 April 2021 08:23

Yes it is very odd. What is in the file /etc/dhcpcd.conf?

You have presumably tried a reboot to check it is not just the pi confused about something, and also a reboot of your router.

Edit: Also what does the command
route
show?

Buckskin · 17 April 2021 22:41

Result of route;

pi@PiHome:~ $ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.1.254   0.0.0.0         UG    303    0        0 wlan0
192.168.1.0     0.0.0.0         255.255.255.0   U     303    0        0 wlan0

/etc/dhcpcd.conf

# A sample configuration for dhcpcd.
# See dhcpcd.conf(5) for details.

# Allow users of this group to interact with dhcpcd via the control socket.
#controlgroup wheel

# Inform the DHCP server of our hostname for DDNS.
hostname

# Use the hardware address of the interface for the Client ID.
clientid
# or
# Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361.
# Some non-RFC compliant DHCP servers do not reply with this set.
# In this case, comment out duid and enable clientid above.
#duid

# Persist interface configuration when dhcpcd exits.
persistent

# Rapid commit support.
# Safe to enable by default because it requires the equivalent option set
# on the server to actually work.
option rapid_commit

# A list of options to request from the DHCP server.
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
# Respect the network MTU. This is applied to DHCP routes.
option interface_mtu

# Most distributions have NTP support.
#option ntp_servers

# A ServerID is required by RFC2131.
require dhcp_server_identifier

# Generate SLAAC address using the Hardware Address of the interface
#slaac hwaddr
# OR generate Stable Private IPv6 Addresses based from the DUID
slaac private

# Example static IP configuration:
#interface eth0
#static ip_address=192.168.0.10/24
#static ip6_address=fd51:42f8:caae:d92e::ff/64
#static routers=192.168.0.1
#static domain_name_servers=192.168.0.1 8.8.8.8 fd51:42f8:caae:d92e::1

# define static profile
interface wlan0
static ip_address=192.168.1.20/24
static routers=192.168.1.254
static domain_name_servers=192.168.1.254


# It is possible to fall back to a static IP if DHCP fails:
# define static profile

# fallback to static profile on eth0
#interface eth0
#fallback static_eth0

I would like to thank you for your interest even if we cannot solve the problem. I have rebooted the Pi, but not the router. I will try that later when there is no-one else using the network.

Edit: I reset the router and that does seem to have fixed the problem. I am going to have to contact my provider as the router is allocating addresses outside of the DHCP allocation zone

system · 16 June 2021 22:42

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.

Topic		Replies	Views
Problem with connect to Tuya devices General	1	132	13 September 2023
Random nodered crashes with node-red-contrib-tuya-local General	3	134	12 March 2024
Start node red without loading any flows General	50	355	21 April 2024
Node-red-node-arduino not connecting to the configured Arduinos after update Hardware	32	3347	27 January 2021
Node-Red instance suddenly not starting on boot General	24	279	20 December 2022

Problem Connecting to Tuya Device

Related Topics