Problem with switch

[darth-aragoth]

I have problem with one of my switches - sometimes after reload it works, but usually it's offline. In logs I found error:

Logger: custom_components.localtuya.common
Source: custom_components/localtuya/pytuya/__init__.py:546
Integration: LocalTuya integration (documentation, issues)
First occurred: 1:50:42 (8 occurrences)
Last logged: 1:52:30

[bfd...yim] Connect to xx.xx.xx.xx failed
Traceback (most recent call last):
  File "/config/custom_components/localtuya/common.py", line 156, in _make_connection
    status = await self._interface.status()
  File "/config/custom_components/localtuya/pytuya/__init__.py", line 461, in status
    status = await self.exchange(STATUS)
  File "/config/custom_components/localtuya/pytuya/__init__.py", line 446, in exchange
    payload = self._decode_payload(msg.payload)
  File "/config/custom_components/localtuya/pytuya/__init__.py", line 546, in _decode_payload
    payload = payload.decode()
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xf3 in position 7: invalid continuation byte

[smithbill17]

I get the same error (see below) logged with 4 different devices (IP addresses edited below). It's always the same 4 devices. My remaining Teckin SmartLife/Tuya compatible smart switches all work fine.

The 4 switches logged in the error message below can still be controlled using the SmartLife app.

Previously I used the 'localtuya' implementation by mileperhour and all smart plugs seemed to work fine.

Logger: custom_components.localtuya.common
Source: custom_components/localtuya/pytuya/init.py:239
Integration: LocalTuya integration (documentation, issues)
First occurred: 29 November 2020, 20:31:27 (11 occurrences)
Last logged: 4:40:52

[bfe...nem] Connect to 192.168.8.aaa failed
[683...9b1] Connect to 192.168.8.bbb failed
[bf2...4q5] Connect to 192.168.8.ccc failed
[bfd...dcr] Connect to 192.168.8.ddd failed
Traceback (most recent call last):
File "/config/custom_components/localtuya/common.py", line 156, in _make_connection
status = await self._interface.status()
File "/config/custom_components/localtuya/pytuya/init.py", line 461, in status
status = await self.exchange(STATUS)
File "/config/custom_components/localtuya/pytuya/init.py", line 440, in exchange
msg = await self.dispatcher.wait_for(seqno)
File "/config/custom_components/localtuya/pytuya/init.py", line 239, in wait_for
await asyncio.wait_for(self.listeners[seqno].acquire(), timeout=timeout)
File "/usr/local/lib/python3.8/asyncio/tasks.py", line 498, in wait_for
raise exceptions.TimeoutError()
asyncio.exceptions.TimeoutError

[smithbill17]

Observation: controlling the switch in the Home Assistant UI shows the switch going on and then about 1-2seconds later, the switch switches back to off. So presumably, the code is failing to command the switch to go on, and then 1-2seconds later it polls for a status update and that's why the switch in the UI changes back to being off. Obviously if the switch was already on, then switching it off will result in it changing back to on after 1-2seconds.

[rednep4wd]

I get the same error message using localtuya. I have 7 tuya led light strings, and seem to be consistently having problems with 2, although the others have also had problems.

One thing I have noticed is the PING time connecting to the tuya devices. Can start at over 100ms then averages 3-5ms. Is more time needed to allow the device to "wake up"

Any suggestions appreciated.

Traceback (most recent call last):
File "/config/custom_components/localtuya/common.py", line 156, in _make_connection
status = await self._interface.status()
File "/config/custom_components/localtuya/pytuya/init.py", line 461, in status
status = await self.exchange(STATUS)
File "/config/custom_components/localtuya/pytuya/init.py", line 456, in exchange
return await self.exchange(command, dps)
File "/config/custom_components/localtuya/pytuya/init.py", line 440, in exchange
msg = await self.dispatcher.wait_for(seqno)
File "/config/custom_components/localtuya/pytuya/init.py", line 239, in wait_for
await asyncio.wait_for(self.listeners[seqno].acquire(), timeout=timeout)
File "/usr/local/lib/python3.8/asyncio/tasks.py", line 498, in wait_for
raise exceptions.TimeoutError()
asyncio.exceptions.TimeoutError

ping 192.168.1.172
PING 192.168.1.172 (192.168.1.172) 56(84) bytes of data.
64 bytes from 192.168.1.172: icmp_seq=1 ttl=255 time=112 ms
64 bytes from 192.168.1.172: icmp_seq=2 ttl=255 time=3.34 ms
64 bytes from 192.168.1.172: icmp_seq=3 ttl=255 time=3.39 ms
64 bytes from 192.168.1.172: icmp_seq=4 ttl=255 time=3.19 ms

ping 192.168.1.175
PING 192.168.1.175 (192.168.1.175) 56(84) bytes of data.
64 bytes from 192.168.1.175: icmp_seq=1 ttl=255 time=98.5 ms
64 bytes from 192.168.1.175: icmp_seq=2 ttl=255 time=117 ms
64 bytes from 192.168.1.175: icmp_seq=3 ttl=255 time=3.15 ms
64 bytes from 192.168.1.175: icmp_seq=4 ttl=255 time=55.0 ms
64 bytes from 192.168.1.175: icmp_seq=5 ttl=255 time=82.2 ms
64 bytes from 192.168.1.175: icmp_seq=6 ttl=255 time=5.08 ms
64 bytes from 192.168.1.175: icmp_seq=7 ttl=255 time=3.37 ms

[matthewmmorrow]

I'm getting pretty much the same error. Happens on both master and passive branches. I can access the device with tuya-cli and I have 8 others of the same product id that work fine. It's just the one device that doesn't play nice.

[111...67f] Connect to 192.168.1.222 failed Traceback (most recent call last): File "/config/custom_components/localtuya/common.py", line 133, in _make_connection status = await self._interface.status() File "/config/custom_components/localtuya/pytuya/__init__.py", line 467, in status status = await self.exchange(STATUS) File "/config/custom_components/localtuya/pytuya/__init__.py", line 452, in exchange payload = self._decode_payload(msg.payload) File "/config/custom_components/localtuya/pytuya/__init__.py", line 552, in _decode_payload payload = payload.decode() UnicodeDecodeError: 'utf-8' codec can't decode byte 0xd0 in position 1: invalid continuation byte

[matthewmmorrow]

Ok, so I have it working for the moment. I relinked the bulb to the Tuya app by turning it on and off 3 times (or whatever your device requires) and added it with the auto scan. This gave it a new key which I had to update in my YAML but once I restarted the device was instantly available. @darth-aragoth and @smithbill17 and @rednep4wd maybe you can try that?