localtuya icon indicating copy to clipboard operation
localtuya copied to clipboard

Localtuya above v4.0.0 has connectivity issues where SmartLife app doesn't. Pretty much all devices.

Open FS1961 opened this issue 2 years ago • 8 comments

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

  1. 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.

FS1961 avatar Oct 26 '22 15:10 FS1961

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?

FragMenthor avatar Oct 28 '22 08:10 FragMenthor

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.

besiktas97 avatar Oct 28 '22 23:10 besiktas97

I have the same problem.... Version 4.1.1.

Any idea when this issue will be solved?

kuchara18 avatar Oct 29 '22 17:10 kuchara18

Idem..With 4.1.1 lots of disconnections. with 4.0.2 it works better but some disconnection occurs

SalazarPellicer avatar Oct 30 '22 10:10 SalazarPellicer

Reading the documentation, I see the maintainer suggests using the Cloud API config. However, I cannot because the authentication fails for some reason. Screenshot 2022-10-30 at 11 55 10 AM

Not sure how to get around this and what do you put in the spot where it says "localtuya"? Screenshot 2022-10-30 at 11 58 11 AM

FS1961 avatar Oct 30 '22 11:10 FS1961

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. image

I'm getting so frustrated with this issue, and even more so with the lack of organization of the stream of these duplicate issues.

chuushi avatar Oct 31 '22 02:10 chuushi

Same for me. My 26 Tuya device are online in Tuya app but unavailable in HA localtuya

Pico1965 avatar Oct 31 '22 04:10 Pico1965

I am also facing this issue with version 4.1.1...

null-unknown avatar Oct 31 '22 15:10 null-unknown

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:

  1. Download device diagnostic info for each device. The downloaded file has the device id, local key, config (colour mode values, etc)
  2. 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
  3. Remove old local tuya entry in Integrations
  4. Restart HA
  5. 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

smarthome-abc avatar Nov 02 '22 18:11 smarthome-abc

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 '(

FragMenthor avatar Nov 02 '22 23:11 FragMenthor

I'm very much a novice but I thought I'd share what I've done to make things more stable.

  1. Change WiFi channels (2.4 & 5Ghz) This includes the mesh antennae.
  2. Relocate ZHA coordinator and router
  3. 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.

FS1961 avatar Nov 03 '22 07:11 FS1961

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

AFumi39 avatar Nov 03 '22 10:11 AFumi39

I'm very much a novice but I thought I'd share what I've done to make things more stable.

  1. Change WiFi channels (2.4 & 5Ghz) This includes the mesh antennae.
  2. Relocate ZHA coordinator and router
  3. 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.

smarthome-abc avatar Nov 03 '22 10:11 smarthome-abc

I'm very much a novice but I thought I'd share what I've done to make things more stable.

  1. Change WiFi channels (2.4 & 5Ghz) This includes the mesh antennae.
  2. Relocate ZHA coordinator and router
  3. 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?

FS1961 avatar Nov 03 '22 11:11 FS1961

I did not use cloud config. I got the local keys from iot.tuya.com a while back

smarthome-abc avatar Nov 03 '22 11:11 smarthome-abc

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?

FS1961 avatar Nov 03 '22 11:11 FS1961

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.

smarthome-abc avatar Nov 03 '22 11:11 smarthome-abc

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.

FS1961 avatar Nov 03 '22 11:11 FS1961

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.

chuushi avatar Nov 04 '22 12:11 chuushi

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)

ManivannanBA avatar Nov 04 '22 13:11 ManivannanBA

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:

  1. Download device diagnostic info for each device. The downloaded file has the device id, local key, config (colour mode values, etc)
  2. 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
  3. Remove old local tuya entry in Integrations
  4. Restart HA
  5. 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?

FragMenthor avatar Nov 06 '22 11:11 FragMenthor

Did this definitely solved the issues for you? Yes. Very stable now like it always was

smarthome-abc avatar Nov 06 '22 14:11 smarthome-abc

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.

FragMenthor avatar Nov 06 '22 20:11 FragMenthor

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.

FS1961 avatar Nov 07 '22 07:11 FS1961

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:

image

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...

FragMenthor avatar Nov 07 '22 09:11 FragMenthor

So does this mean it's a LocalTuya issue or HA?

FS1961 avatar Nov 07 '22 09:11 FS1961

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.

AFumi39 avatar Nov 07 '22 09:11 AFumi39

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!

FragMenthor avatar Nov 07 '22 09:11 FragMenthor

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...

FragMenthor avatar Nov 07 '22 09:11 FragMenthor

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.

AFumi39 avatar Nov 07 '22 10:11 AFumi39