localtuya
localtuya copied to clipboard
Localtuya above v4.0.0 has connectivity issues where SmartLife app doesn't. Pretty much all devices.
The problem
Environment
- Localtuya version: v4.0.0
- Last working localtuya version (if known and relevant):
- Home Assistant Core version:
- [] Are you using the Home Assistant Tuya Cloud component ?
- [] Are you using the Tuya App in parallel ?
Steps to reproduce
- Use any version above 4.0.0
Configuration configuration.yaml
or config_flow
# Loads default set of integrations. Do not remove.
default_config:
zone: # Change default radius to 50
- name: Home
latitude: 49.5755337
longitude: 7.4473159
radius: 10
icon: mdi:home
automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml
http:
ssl_certificate: /ssl/fullchain.pem
ssl_key: /ssl/privkey.pem
#Apple calendar
calendar:
- platform: caldav
url: https://caldav.icloud.com
username: fspatt@XXXXXXX
password: !secret apple_specific
calendars:
- XXXXXX
- RHS SY2022-23
- platform: worldclock
name: Seoul
time_zone: Asia/Seoul
bluetooth:
zha:
custom_quirks_path: /config/custom_zha_quirks/
logger:
default: warning
logs:
custom_components.localtuya: debug
DP dump
Provide Home Assistant taceback/logs
[ltuya.txt](https://github.com/rospogrigio/localtuya/files/9870824/ltuya.txt)
Additional information
I've already changed WiFi channels but that seems to not really make a difference. Everything had been working fine for a long time and then I updated the version.
Same here. For 2 days, downgrading to 4.0.2 seemed to work, but now I lose control of all my tuya devices randomly. Sometimes they appear as offline in HA, sometimes they don't, but I can´t control them from HA. Reloading the integration with the included service doesn't help, reloading from the UI either. Need to restart HA and then suddenly they are all functional. From SmartLife app they are always available... What is the matter with this, something on Tuya side? Something with the new HA version?
Versions above 4.0.2 are crappy and unstable as hell. I also did a downgrade for a long time ago to version 4.0.2 and everything is working good now. I wont update until al those bugs are fixed.
I have the same problem.... Version 4.1.1.
Any idea when this issue will be solved?
Idem..With 4.1.1 lots of disconnections. with 4.0.2 it works better but some disconnection occurs
Reading the documentation, I see the maintainer suggests using the Cloud API config. However, I cannot because the authentication fails for some reason.
Not sure how to get around this and what do you put in the spot where it says "localtuya"?
Even using the cloud integration API did not help me. I'm still getting lights randomly disconnected after 24 hours of uptime. I even tried ticking "Do not configure Cloud API account", but that didn't help.
The issue seems to occur after a slight disconnect when the DHCP lease gets renegotiated and renewed, even if it renews to the same IP. The lease originally expired in 12 hours, and devices went offline after 12 hours. When I tried DHCP reservation (which claims unlimited lease time), the devices stay connected for 24 hours, after which they all become unavailable.
All devices imaged here are light bulbs.
I'm getting so frustrated with this issue, and even more so with the lack of organization of the stream of these duplicate issues.
Same for me. My 26 Tuya device are online in Tuya app but unavailable in HA localtuya
I am also facing this issue with version 4.1.1...
I was facing same problem with 4.x versions. I downgraded to 3.5 version. The devices needed to be setup again but it was worth the hassle as now my devices are available. On 4.x the devices would become unavailable and reloading Integration or restarting HA didn't help.
HACS wasn't showing options below 4.0, I followed these steps:
- Download device diagnostic info for each device. The downloaded file has the device id, local key, config (colour mode values, etc)
- Run in HA terminal:
mkdir /config/backup && mv /config/custom_components/localtuya /config/backup && mkdir /config/git && cd /config/git && wget https://codeload.github.com/rospogrigio/localtuya/zip/refs/tags/v3.5.0 && unzip v3.5.0.zip && mv localtuya-3.5.0/custom_components/localtuya /config/custom_components
- Remove old local tuya entry in Integrations
- Restart HA
- Add the devices again. All the config required is in the downloaded files from step 1. Note: In 3.5, add a local tuya integration for each device; In 4.x, single local tuya integration handles multiple devices
I am really pondering that approach, really desperate right now, I must restart HA 2-3 times a day because of this. Restart solves for a while, and I can't automate restarts for a number of reasons: because not all devices become unavailable, and I can't have a measure of when to restart (situation that I shouldn't even consider, but I do), because automations are running and I stop them, because.... no :(... I really value the work put in to this, grateful to the developer in every way for almost 2 years. But I've grown so dependant on this that it is really not manageable anymore .. Has a desperate measure, I will probably try 3.x version, and if I can't manage to get the same, I will try the cloud integration '(
I'm very much a novice but I thought I'd share what I've done to make things more stable.
- Change WiFi channels (2.4 & 5Ghz) This includes the mesh antennae.
- Relocate ZHA coordinator and router
- Turn band and router steering off of the WiFi router and mesh.
Everything has been stable for me for a few days now. The odd device goes offline for a bit and then cycles back online.
I try to add information here to see if this might help to identify the problem (for the developers). In my house there're lot of interferences (many other wifi network that overlap each other), so (even if my wifi network is stable) every now and then there's an automatic channel switch if the interferences on current channel became too high.
As a result, there're "network issues" trying to reach the devices in those moments. Sometimes LocalTuya isa able to "recover" the device, but sometimes not. If it became unavailable (for LocalTuya, not for official Tuya app or integration), it doesn't go online again. The only way to recover it is to "Reload" the integration or to restart HA.
I post examples of error that occurs, but that are not directly related to the issue (I think that the problem is not logged correctly)
Questo errore ha avuto origine da un'integrazione personalizzata.
Logger: custom_components.localtuya.common
Source: custom_components/localtuya/pytuya/__init__.py:707
Integration: LocalTuya (documentation, issues)
First occurred: 2 novembre 2022 09:14:53 (164 occurrences)
Last logged: 08:56:37
[410...441] Connect to 192.168.1.91 failed
[010...1ef] Connect to 192.168.1.107 failed
[bf2...6dh] Connect to 192.168.1.210 failed
[202...99c] Connect to 192.168.1.36 failed
[bfc...thi] Connect to 192.168.1.121 failed
Traceback (most recent call last):
File "/config/custom_components/localtuya/common.py", line 186, in _make_connection
self._interface = await pytuya.connect(
File "/config/custom_components/localtuya/pytuya/__init__.py", line 707, in connect
_, protocol = await loop.create_connection(
File "/usr/local/lib/python3.10/asyncio/base_events.py", line 1064, in create_connection
raise exceptions[0]
File "/usr/local/lib/python3.10/asyncio/base_events.py", line 1049, in create_connection
sock = await self._connect_sock(
File "/usr/local/lib/python3.10/asyncio/base_events.py", line 960, in _connect_sock
await self.sock_connect(sock, address)
File "/usr/local/lib/python3.10/asyncio/selector_events.py", line 500, in sock_connect
return await fut
File "/usr/local/lib/python3.10/asyncio/selector_events.py", line 535, in _sock_connect_cb
raise OSError(err, f'Connect call failed {address}')
OSError: [Errno 113] Connect call failed ('192.168.1.61', 6668)
Questo errore ha avuto origine da un'integrazione personalizzata.
Logger: homeassistant
Source: custom_components/localtuya/discovery.py:67
Integration: LocalTuya (documentation, issues)
First occurred: 2 novembre 2022 09:31:33 (5 occurrences)
Last logged: 04:23:56
Error doing job: Exception in callback _SelectorDatagramTransport._read_ready()
Traceback (most recent call last):
File "/config/custom_components/localtuya/discovery.py", line 65, in datagram_received
data = decrypt_udp(data)
File "/config/custom_components/localtuya/discovery.py", line 30, in decrypt_udp
return _unpad(decryptor.update(message) + decryptor.finalize()).decode()
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xbb in position 0: invalid start byte
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/lib/python3.10/asyncio/events.py", line 80, in _run
self._context.run(self._callback, *self._args)
File "/usr/local/lib/python3.10/asyncio/selector_events.py", line 1027, in _read_ready
self._protocol.datagram_received(data, addr)
File "/config/custom_components/localtuya/discovery.py", line 67, in datagram_received
data = data.decode()
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xa8 in position 0: invalid start byte
I'm very much a novice but I thought I'd share what I've done to make things more stable.
- Change WiFi channels (2.4 & 5Ghz) This includes the mesh antennae.
- Relocate ZHA coordinator and router
- Turn band and router steering off of the WiFi router and mesh.
Everything has been stable for me for a few days now. The odd device goes offline for a bit and then cycles back online.
I have pretty stable WiFi and I can see the devices are connected to WiFi. I think for me it is because of the firewall rules that I have. I block internet to Tuya devices and HA. In 3.X I paused this firewall rule only when adding the device to local tuya so I wouldn’t get the error “connection succeeded but datapoints missing” but after adding the device to localtuya, I block them from internet again and everything is fine b/w reloads, restarts, etc. I think on 4.x it somehow tries to get the datapoints again but fails due to no internet.
I'm very much a novice but I thought I'd share what I've done to make things more stable.
- Change WiFi channels (2.4 & 5Ghz) This includes the mesh antennae.
- Relocate ZHA coordinator and router
- Turn band and router steering off of the WiFi router and mesh.
Everything has been stable for me for a few days now. The odd device goes offline for a bit and then cycles back online.
I have pretty stable WiFi and I can see the devices are connected to WiFi. I think for me it is because of the firewall rules that I have. I block internet to Tuya devices and HA. In 3.X I paused this firewall rule only when adding the device to local tuya so I wouldn’t get the error “connection succeeded but datapoints missing” but after adding the device to localtuya, I block them from internet again and everything is fine b/w reloads, restarts, etc. I think on 4.x it somehow tries to get the datapoints again but fails due to no internet.
Have you tried "Configure" and remove "Reconfigure Cloud API account" and then select "Do not configure Cloud API account" ? Does this work for you?
I did not use cloud config. I got the local keys from iot.tuya.com a while back
I did not use cloud config. I got the local keys from iot.tuya.com a while back
Yes, but complete the above and see if there is a difference?!
Have you tried "Configure" and remove "Reconfigure Cloud API account" and then select "Do not configure Cloud API account" ? Does this work for you?
I did not use cloud config. I got the local keys from iot.tuya.com a while back
Yes, but complete the above and see if there is a difference?!
Have you tried "Configure" and remove "Reconfigure Cloud API account" and then select "Do not configure Cloud API account" ? Does this work for you?
I am on 3.x now. I never did the configure cloud API account on 4.x. I used the local keys I had already obtained. 4.x was a big change so maybe there are few bugs that still need to be fixed. I am sorry I can’t provide the required debug info.
I did not use cloud config. I got the local keys from iot.tuya.com a while back
Yes, but complete the above and see if there is a difference?! Have you tried "Configure" and remove "Reconfigure Cloud API account" and then select "Do not configure Cloud API account" ? Does this work for you?
I am on 3.x now. I never did the configure cloud API account on 4.x. I used the local keys I had already obtained. 4.x was a big change so maybe there are few bugs that still need to be fixed. I am sorry I can’t provide the required debug info.
Just another user like you trying to help.
Turn band and router steering off of the WiFi router and mesh.
I think you are bringing up a good point. I have a Ubiquiti AP, hide my SSID, and have band steering turned on. The lights connect to WiFi successfully, but maybe that split second of disconnect during reconnection is enough to throw localtuya off while it attempts to reconnect with the light.
I will try creating a separate IoT SSID and have it work only on 2.4 GHz to see if that solves my issue.
Any help with the below error?
Logger: custom_components.localtuya.config_flow Source: custom_components/localtuya/pytuya/init.py:704 Integration: LocalTuya (documentation, issues) First occurred: 7:12:58 PM (1 occurrences) Last logged: 7:12:58 PM
Unexpected exception Traceback (most recent call last): File "/config/custom_components/localtuya/config_flow.py", line 580, in async_step_configure_device self.dps_strings = await validate_input(self.hass, user_input) File "/config/custom_components/localtuya/config_flow.py", line 245, in validate_input interface = await pytuya.connect( File "/config/custom_components/localtuya/pytuya/init.py", line 704, in connect _, protocol = await loop.create_connection( File "/usr/lib/python3.10/asyncio/base_events.py", line 1064, in create_connection raise exceptions[0] File "/usr/lib/python3.10/asyncio/base_events.py", line 1049, in create_connection sock = await self._connect_sock( File "/usr/lib/python3.10/asyncio/base_events.py", line 960, in _connect_sock await self.sock_connect(sock, address) File "/usr/lib/python3.10/asyncio/selector_events.py", line 500, in sock_connect return await fut File "/usr/lib/python3.10/asyncio/selector_events.py", line 535, in _sock_connect_cb raise OSError(err, f'Connect call failed {address}') OSError: [Errno 113] Connect call failed ('192.168.68.116', 6668)
I was facing same problem with 4.x versions. I downgraded to 3.5 version. The devices needed to be setup again but it was worth the hassle as now my devices are available. On 4.x the devices would become unavailable and reloading Integration or restarting HA didn't help.
HACS wasn't showing options below 4.0, I followed these steps:
- Download device diagnostic info for each device. The downloaded file has the device id, local key, config (colour mode values, etc)
- Run in HA terminal:
mkdir /config/backup && mv /config/custom_components/localtuya /config/backup && mkdir /config/git && cd /config/git && wget https://codeload.github.com/rospogrigio/localtuya/zip/refs/tags/v3.5.0 && unzip v3.5.0.zip && mv localtuya-3.5.0/custom_components/localtuya /config/custom_components
- Remove old local tuya entry in Integrations
- Restart HA
- Add the devices again. All the config required is in the downloaded files from step 1. Note: In 3.5, add a local tuya integration for each device; In 4.x, single local tuya integration handles multiple devices
Did this definitely solved the issues for you?
Did this definitely solved the issues for you? Yes. Very stable now like it always was
Well, I'm on a "new" experience here, on 4.1.1 but removed my cloud credentials, and it seems stable now. Suggested by @FS1961 and it is stable for now.
Well I've updated to Home-Assistant 11.1 and LocalTuya 4.1.1 and so far everything seems stable. I'm monitoring the situation and will see if I need to go back again. Removing the Cloud credentials, reconfiguring the WiFi, and turning off the router/band steering may have done the trick.
Well, removing the cloud credentials didn't solve for me after all. Worked for a while, but during the night I had a failure that could not be recovered by localtuya, and all my tuya devices stayed offline for hours:
Reloading localtuya with the included service did not work, but a HA restart brought immediately all devices online. I'm gonna backup all my system, remove everything from localtuya and downgrade to 3.x... Desperate right now...
So does this mean it's a LocalTuya issue or HA?
So does this mean it's a LocalTuya issue or HA?
Surely is LT issue, because if you reload the integration (without HA reboot), it starts to work again. Also, with versions < 4.x it works flawlessly, so it's definitively a LT problem.
I really don't know, but this is a recent behaviour. I had 4.x.x since the beginning and this did not happen right after the upgrade, only a few weeks after (can't pinpoint dates or versions). Just wanted to know if there are any clues on what causes this, and if there a solution is beeing considered... @rospogrigio, could we get some feedback, please? Any hope of a solution on this? And thanks again for all your work!
So does this mean it's a LocalTuya issue or HA?
Surely is LT issue, because if you reload the integration (without HA reboot), it starts to work again. Also, with versions < 4.x it works flawlessly, so it's definitively a LT problem.
For me nothing recovers unless I reboot HA. How do you reload the integration? Using the included service? That doens't work for me. And if I go to integrations, and reload in the "...", HA asks me to restart, so...
For me nothing recovers unless I reboot HA. How do you reload the integration? Using the included service? That doens't work for me. And if I go to integrations, and reload in the "...", HA asks me to restart, so...
I tried both via service and via web menu (the "..." menu in the Integrations page) and works well for me.