rospogrigio / localtuya

local handling for Tuya devices
GNU General Public License v3.0
2.71k stars 530 forks source link

Device's go unavailable #726

Open ImperialForce opened 2 years ago

ImperialForce commented 2 years ago

Hi, I have this problem all the time from Localtuya. My devices continue to go unavailable and then once I change the icon for the entity, it comes back on for a little while. My devices are blocked from accessing internet via my router. Any ideas?

ChirpyTurnip commented 2 years ago

HI have the same problem now also for a few days - but I only just noticed. Previously my Lenovo smart plugs that I run under LocalTuya were 100% solid. I have never had a single issue with them - they just worked and they were lightning fast!

Unfortunately they now keep falling off HA going into an 'Unavailable' state before coming back online seconds of minutes later. The drop off pattern is (offline time, space between drops) is random, BUT, they are clustered - so it can be fine for hours (even 12 hours) then go haywire for a few hours, then back to normal....


February 3, 2022 - 10:19:36|Lounge Bookcase Light became unavailable
February 3, 2022 - 10:18:59|Lounge Bookcase Light turned off
February 3, 2022 - 10:18:02|Lounge Bookcase Light became unavailable
February 3, 2022 - 10:17:00|Lounge Bookcase Light turned off
February 3, 2022 - 10:16:19|Lounge Bookcase Light became unavailable
February 3, 2022 - 10:14:59|Lounge Bookcase Light turned off
February 3, 2022 - 10:14:36|Lounge Bookcase Light became unavailable
February 3, 2022 - 10:13:59|Lounge Bookcase Light turned off
February 3, 2022 - 10:12:59|Lounge Bookcase Light became unavailable
February 3, 2022 - 10:12:09|Lounge Bookcase Light turned off
February 3, 2022 - 10:11:41|Lounge Bookcase Light became unavailable
February 3, 2022 - 10:11:05|Lounge Bookcase Light turned off
February 3, 2022 - 10:10:39|Lounge Bookcase Light became unavailable
February 3, 2022 - 10:10:02|Lounge Bookcase Light turned off
February 3, 2022 - 10:09:36|Lounge Bookcase Light became unavailable
February 3, 2022 - 10:06:57|Lounge Bookcase Light turned off
February 3, 2022 - 10:06:50|Lounge Bookcase Light became unavailable
February 3, 2022 - 10:05:03|Lounge Bookcase Light turned off
February 3, 2022 - 10:04:38|Lounge Bookcase Light became unavailable
February 3, 2022 - 10:04:03|Lounge Bookcase Light turned off
February 3, 2022 - 10:03:57|Lounge Bookcase Light became unavailable
February 3, 2022 - 09:57:57|Lounge Bookcase Light turned off
February 3, 2022 - 09:57:01|Lounge Bookcase Light became unavailable
February 3, 2022 - 09:54:58 |Lounge Bookcase Light turned off
February 3, 2022 - 09:53:13 |Lounge Bookcase Light became unavailable
February 3, 2022 - 09:51:05 |Lounge Bookcase Light turned off
February 3, 2022 - 09:50:27 |Lounge Bookcase Light became unavailable
February 3, 2022 - 09:50:02 |Lounge Bookcase Light turned off
February 3, 2022 - 09:48:35 |Lounge Bookcase Light became unavailable
February 3, 2022 - 09:48:00 |Lounge Bookcase Light turned off
February 3, 2022 - 09:47:42 |Lounge Bookcase Light became unavailable
February 3, 2022 - 09:46:00 |Lounge Bookcase Light turned off
February 3, 2022 - 09:45:13 |Lounge Bookcase Light became unavailable
February 3, 2022 - 09:44:58 |Lounge Bookcase Light turned off
February 3, 2022 - 09:43:14 |Lounge Bookcase Light became unavailable
February 3, 2022 - 09:43:00 |Lounge Bookcase Light turned off
February 3, 2022 - 09:42:03 |Lounge Bookcase Light became unavailable
February 3, 2022 - 09:41:01 |Lounge Bookcase Light turned off
February 3, 2022 - 09:40:03 |Lounge Bookcase Light became unavailable
February 3, 2022 - 09:38:01 |Lounge Bookcase Light turned off
February 3, 2022 - 09:35:54 |Lounge Bookcase Light became unavailable
February 3, 2022 - 09:34:59 |Lounge Bookcase Light turned off
February 3, 2022 - 09:32:07 |Lounge Bookcase Light became unavailable
February 3, 2022 - 09:27:59 |Lounge Bookcase Light turned off
February 3, 2022 - 09:26:58 |Lounge Bookcase Light became unavailable
February 3, 2022 - 09:25:58 |Lounge Bookcase Light turned off
February 3, 2022 - 09:25:01 |Lounge Bookcase Light became unavailable
February 3, 2022 - 09:21:01 |Lounge Bookcase Light turned off
February 3, 2022 - 09:20:15 |Lounge Bookcase Light became unavailable
February 3, 2022 - 09:20:01 |Lounge Bookcase Light turned off
February 3, 2022 - 09:17:11 |Lounge Bookcase Light became unavailable
February 3, 2022 - 09:12:58 |Lounge Bookcase Light turned off
February 3, 2022 - 09:11:58 |Lounge Bookcase Light became unavailable
February 3, 2022 - 08:56:59 |Lounge Bookcase Light turned off
February 3, 2022 - 08:56:13 |Lounge Bookcase Light became unavailable
February 3, 2022 - 08:55:59 |Lounge Bookcase Light turned off
February 3, 2022 - 08:55:17 |Lounge Bookcase Light became unavailable
February 3, 2022 - 08:30:02 |Lounge Bookcase Light turned off
February 3, 2022 - 08:28:26 |Lounge Bookcase Light became unavailable
February 3, 2022 - 07:48:00 |Lounge Bookcase Light turned off
February 3, 2022 - 07:47:14 |Lounge Bookcase Light became unavailable
February 3, 2022 - 01:48:56 |Lounge Bookcase Light turned off
February 3, 2022 - 01:48:47 |Lounge Bookcase Light became unavailable
February 2, 2022 - 22:12:09|Lounge Bookcase Light turned off by Supervisor
February 2, 2022 - 22:09:12|Lounge Bookcase Light turned on by Supervisor
February 2, 2022 - 21:57:58|Lounge Bookcase Light turned off by Supervisor
February 2, 2022 - 20:44:00|Lounge Bookcase Light turned on
February 2, 2022 - 20:09:48|Lounge Bookcase Light turned on by Supervisor
February 2, 2022 - 18:20:04|Lounge Bookcase Light turned off
February 2, 2022 - 18:19:11|Lounge Bookcase Light became unavailable
February 2, 2022 - 13:12:03|Lounge Bookcase Light turned off
February 2, 2022 - 13:11:09|Lounge Bookcase Light became unavailable
February 2, 2022 - 08:14:05|Lounge Bookcase Light turned off
February 2, 2022 - 08:13:11|Lounge Bookcase Light became unavailable
February 2, 2022 - 08:10:05|Lounge Bookcase Light turned off
February 2, 2022 - 08:09:19|Lounge Bookcase Light became unavailable
February 2, 2022 - 08:09:05|Lounge Bookcase Light turned off
February 2, 2022 - 08:08:14|Lounge Bookcase Light became unavailable
February 2, 2022 - 07:20:03|Lounge Bookcase Light turned off
February 2, 2022 - 07:19:35|Lounge Bookcase Light became unavailable
February 2, 2022 - 07:18:03|Lounge Bookcase Light turned off

Obviously while unavailable everything stops working...then it comes back (reported as 'Turned Off').

CP.

purplephoenix76 commented 2 years ago

I'm also experiencing this. I'm switching from tuya to localtuya due to their intermittent device state notification (lack of) rendering my devices state out of sync. However, it does not result in devices being unavailable. From the logs, after 2 days, I can see this. (4000 occurances 😅). Hope the log below helps.

This error originated from a custom integration.

Logger: custom_components.localtuya.common Source: custom_components/localtuya/pytuya/init.py:669 Integration: LocalTuya integration (documentation, issues) First occurred: 5 February 2022, 12:24:50 (4000 occurrences) Last logged: 04:53:02

[706...3a1] Connect to 192.168.50.153 failed [bf0...kq4] Connect to 192.168.50.65 failed [102...b57] Connect to 192.168.50.129 failed [102...e68] Connect to 192.168.50.81 failed [bff...mn4] Connect to 192.168.50.78 failed Traceback (most recent call last): File "/config/custom_components/localtuya/common.py", line 145, in _make_connection self._interface = await pytuya.connect( File "/config/customcomponents/localtuya/pytuya/init.py", line 669, in connect , protocol = await loop.create_connection( File "/usr/local/lib/python3.9/asyncio/base_events.py", line 1056, in create_connection raise exceptions[0] File "/usr/local/lib/python3.9/asyncio/base_events.py", line 1041, in create_connection sock = await self._connect_sock( File "/usr/local/lib/python3.9/asyncio/base_events.py", line 955, in _connect_sock await self.sock_connect(sock, address) File "/usr/local/lib/python3.9/asyncio/selector_events.py", line 502, in sock_connect return await fut File "/usr/local/lib/python3.9/asyncio/selector_events.py", line 537, in _sock_connect_cb raise OSError(err, f'Connect call failed {address}') OSError: [Errno 113] Connect call failed ('192.168.50.106', 6668)

jeffborg commented 2 years ago

I've also got something similar going on with a bunch of smart sockets

I also have a bunch of smart bulbs which still seem ok.

This only just happened recently with an update via hacs

Still running Home assistant 2021.12.10 at the moment

carryonrewardless commented 2 years ago

My smart switches are all unavailable but it seems like localtuya has been dropped from core-2022.2. I deleted one switch to try and add it back but localtuya does not appear in the Integrations list. This core update has broken localtuya.

Saramidek commented 2 years ago

I too have this problem with my devices. Light bulbs in my case. It also come in clusters where some devices gets unavailable over and over again and after a while some other devices become unavailable instead. My log gets overflown with errors and I can't reach the unavailable bulbs, drives me crazy.

minasolution commented 2 years ago

Updated: I've found the cause. In my case, I use YAML config and when the IP of the device changes, it stops working. Did a ping to confirm it is no longer reachable.

So I manually set my router to static IP for each device and it seems working great now.

Saramidek commented 2 years ago

Not in My case

Updated: I've found the cause. In my case, I use YAML config and when the IP of the device changes, it stops working. Did a ping to confirm it is no longer reachable.

So I manually set my router to static IP for each device and it seems working great now.

This is not the cause in My case since they have not changed their IP, I can ser them in My routers Interface Still connected with the same IP.

ChirpyTurnip commented 2 years ago

Mine have always been on static IPs so I know that's not my cause.... :-(

On Tue, 8 Feb 2022 at 13:21, Saramidek @.***> wrote:

Not in My case

Updated: I've found the cause. In my case, I use YAML config and when the IP of the device changes, it stops working. Did a ping to confirm it is no longer reachable.

So I manually set my router to static IP for each device and it seems working great now.

This is not the cause in My case since they have not changed their IP, I can ser them in My routers Interface Still connected with the same IP.

— Reply to this email directly, view it on GitHub https://github.com/rospogrigio/localtuya/issues/726#issuecomment-1032078885, or unsubscribe https://github.com/notifications/unsubscribe-auth/AUIP7ZQRZXEHFLP6RXAJLL3U2BOW3ANCNFSM5NHDPFDA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

carryonrewardless commented 2 years ago

Does anyone else see this: localtuya does not appear in the Integrations list. ?? image

Thinking about restoring a backup and then trying again with 2022.2

larry-glz commented 2 years ago

I have similar issue once i updated to core 2022.2.3. hope this is addressed

carryonrewardless commented 2 years ago

I had to download the repo again and do a HA re-start. Then the Integration was visible in the Add Integration wizard and I could add devices again. Hope this helps others but no idea how the Integration disappeared with the core update.

Andrewpaps commented 2 years ago

For some extra insight, I have both 3.1 and 3.3 protocol localtuya devices and this dropout behaviour only occurs on the 3.1 devices.

purplephoenix76 commented 2 years ago

For some extra insight, I have both 3.1 and 3.3 protocol localtuya devices and this dropout behaviour only occurs on the 3.1 devices.

Mine is all running 3.3 protocol and is experiencing the intermittent unavailability. So it should occurring regardless of which protocol we are using.

Seems this issue has yet to be assigned to work on?

Andrewpaps commented 2 years ago

For some extra insight, I have both 3.1 and 3.3 protocol localtuya devices and this dropout behaviour only occurs on the 3.1 devices.

Mine is all running 3.3 protocol and is experiencing the intermittent unavailability. So it should occurring regardless of which protocol we are using.

Seems this issue has yet to be assigned to work on?

Fair enough, logic would dictate it be model-bsaed then.

minasolution commented 2 years ago

Hi guys

Try to disable SYN-flood protection on your router, or at least increase its number to higher (especially if you are using OpenWRT on your router because its number is way too low ).

One possibility is that the router detects TCP SYN-flood from HA and make it unreachable to local devices (while these devices themself still work)

So ping the devices from HA, and your PC, to make sure this is the case first.

purplephoenix76 commented 2 years ago

My DoS protection is set to off (to disable syn-flood protection) but the issue still persist.

diagdave1 commented 2 years ago

Hi,

I am also having this issue. All using 3.3. Random which device goes offline. 2 different models. Static reservation in DHCP and I can still ping the devices.

Happy to try anthing if someone wants to test something.

Thanks

fullhack2 commented 2 years ago

Hi all,

I too have been seeing the intermittent disconnects from HA. I have just under 30 devices configured with a YAML file. All are static IP's. I have setup up monitoring of all these devices using my monitoring instance (Zabbix) and notice that my LocalTuya devices are seeing rather high ping response times, which seems to correlate with the disconnects/unavailable from HA. Seeing pings in the range of 20 - 100 ms (which is high on my network for sure).

I thought I would do some testing, so I completely disabled localtuya on HA to test. Low and behold, my response times all dropped to between 5-10 ms as soon as localtuya was disabled. I'm running a Unifi system at home here.

Not sure why localtuya seems to be causing the extremely high latency when enabled. I have been battling this for quite some time. Also wanted to note that I'm not blocking any outgoing connectivity to Tuya services (firewall or DNS blocking) as I'm not overly concerned about the cloud component at this time. My initial reason for trying localtuya was just to improve response time.

If anyone has any further thoughts, I would love to hear them. Willing to try a few things to see if we can figure out what is causing the network latency.

Thanks!

fullhack2 commented 2 years ago

Just for reference:

image

The first part of the graph is latency with localtuya devices enabled in HA. After the noticeable drop in latency would be when localtuya is disabled and I have the tuya addon configured for cloud control.

x2fzhl commented 2 years ago

That's the same problem isn't it? https://github.com/rospogrigio/localtuya/issues/716

Saramidek commented 2 years ago

No, not the same for me.

fullhack2 commented 2 years ago

In my particular case the localtuya add-on is creating excessive network latency on my lan when it is configured, this in turn causes the devices to drop off (become unavailable) for a few seconds/minutes. Does not appear to be the same behaviour as #716 . The other issue appears to just be an API issue where the status does not update, but in my case it is actually something at the network layer that localtuya seems to introduce.

btagli commented 2 years ago

I have this exact same thing happening. My logs show: Traceback (most recent call last): File "/usr/local/lib/python3.9/asyncio/locks.py", line 413, in acquire await fut asyncio.exceptions.CancelledError

Due to timeouts: Traceback (most recent call last): File "/config/custom_components/localtuya/common.py", line 155, in _make_connection status = await self._interface.status() File "/config/custom_components/localtuya/pytuya/init.py", line 481, in status status = await self.exchange(STATUS) File "/config/custom_components/localtuya/pytuya/init.py", line 476, in exchange return await self.exchange(command, dps) File "/config/custom_components/localtuya/pytuya/init.py", line 460, in exchange msg = await self.dispatcher.wait_for(seqno) File "/config/custom_components/localtuya/pytuya/init.py", line 247, in wait_for await asyncio.wait_for(self.listeners[seqno].acquire(), timeout=timeout) File "/usr/local/lib/python3.9/asyncio/tasks.py", line 494, in wait_for raise exceptions.TimeoutError() from exc asyncio.exceptions.TimeoutError

This is the same as #753

btagli commented 2 years ago

I concur with fullhack2 here. I am watching my devices on the iot tuya site. Device shows offline in HA and in iot. As soon as I disable my localtuya device in HA, bam, the device shows online in iot.

ImperialForce commented 2 years ago

For me however, my devices are blocked from the router side. They cannot access the cloud at all, so I shouldn’t be having these problems.

Literally they go offline I change the icon and it’s back. Very strange

minasolution commented 2 years ago

Hi guys. Give pr #491 a try as that fix has not been merged to master yet.

btagli commented 2 years ago

The Zombie fix #491 seems to have fixed the issue with my devices dropping off and not coming back. Those devices would just ping and nothing else. but, my other devices still drop off what looks to be every 15 minutes.

Pirateguybrush commented 2 years ago

How do I install fix 491? I'm running Localtuya installed via HACS.

btagli commented 2 years ago

Fix is in this comment. https://github.com/rospogrigio/localtuya/pull/491#issuecomment-860149716

Pirateguybrush commented 2 years ago

Thanks for the link! Will this cause any conflicts within HACS, and will it be overwritten if localtuya updates via HACS?

btagli commented 2 years ago

This does not conflict with HAVS. You are swapping over the localtuya files only.

fullhack2 commented 1 year ago

Hello all,

I took a break with localtuya for a while because of the network latency issues introduced as soon as it was enabled. I was hoping that perhaps the issue may have been resolved by now, but I am still seeing the same extreme latency uptick (devices would sit at 3-5ms and then skyrocket to 50-60ms when localtuya is enabled).

My devices drop to unavailable occasionally and sometimes my automations fail to execute properly as something like 1 bulb timesout when the automation runs.

As soon as I disable localtuya, the latency to those devices drops back to the 3-5ms range.

Just wondering if anyone has further insight or can assist me in finding the latency ghost to make localtuya a more reliable option for me.

Thanks!