Devices becoming unavailable

[c0m3r]

Been using the localtuya integration and it worked excellently. Managed to add all of my devices including bulbs, switches etc. and response was instant. However, I have noticed that over the course of the day the vast majority of the devices will become unavailable. Some will still show as 'on' or 'off' but cannot be toggled. All still work in the tuya app when this happens.

Have tried a few things such as removing the default tuya integration and have noticed that a restart of HA resolves the issue temporarily. Have checked wifi but all have excellent signal and can see them connected to my network when they appear unavailable.

Any suggestions as is driving me mad and really dont want to revert to the slow performance of the normal integration. Have a number of different brands of each item and happening on all of them. Happy to provide logs if someone tells me what they need. Thanks in advance.

[smithbill17]

I think you're describing the issue that many are experiencing. Hopefully a resolution will be along soon.

I'm not aware that there is any workaround, save to return to your slow 'normal integration' or to use the original localtuya custom component from 'mileperhour' which I think is no longer supported (and you'll have to configure your configuration.yaml manually).

[ultratoto14]

@c0m3r Many of the tuya devices cannot handle two connections at the same time, please ensure that you do not use the tuya app at the same time as this integration.

[c0m3r]

@c0m3r Many of the tuya devices cannot handle two connections at the same time, please ensure that you do not use the tuya app at the same time as this integration.

Yes have seen that. Not using the app at the same time though.

[jsbrich]

I am seeing this same issue, though it seems to just be one of my devices having the issue.

I get this in the main log:

`Logger: custom_components.localtuya.pytuya
Source: custom_components/localtuya/pytuya/init.py:239
Integration: LocalTuya (documentation, issues)
First occurred: 5:30:32 PM (1 occurrences)
Last logged: 5:30:32 PM

[616...04b] Heartbeat failed (), disconnecting
Traceback (most recent call last):
File "/config/custom_components/localtuya/pytuya/init.py", line 379, in heartbeat_loop
await self.heartbeat()
File "/config/custom_components/localtuya/pytuya/init.py", line 468, in heartbeat
return await self.exchange(HEARTBEAT)
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`

And this would be a segment of the debug log:

2020-12-07 17:30:32 ERROR (MainThread) [custom_components.localtuya.pytuya] [616...04b] Heartbeat failed (), disconnecting Traceback (most recent call last): File "/config/custom_components/localtuya/pytuya/__init__.py", line 379, in heartbeat_loop await self.heartbeat() File "/config/custom_components/localtuya/pytuya/__init__.py", line 468, in heartbeat return await self.exchange(HEARTBEAT) 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 2020-12-07 17:30:32 DEBUG (MainThread) [custom_components.localtuya.pytuya] [616...04b] Stopped heartbeat loop 2020-12-07 17:30:32 DEBUG (MainThread) [custom_components.localtuya.pytuya] [616...04b] Closing connection 2020-12-07 17:30:32 DEBUG (MainThread) [custom_components.localtuya.pytuya] [616...04b] Connection lost: None 2020-12-07 17:30:32 DEBUG (MainThread) [custom_components.localtuya.pytuya] [616...04b] Closing connection 2020-12-07 17:30:32 DEBUG (MainThread) [custom_components.localtuya.common] [616...04b] Disconnected: None 2020-12-07 17:30:32 DEBUG (MainThread) [custom_components.localtuya.common] [616...04b] Already connecting to 192.168.68.100 (61652340600194d9804b) - False, <Task finished name='Task-943' coro=<TuyaDevice._make_connection() done, defined at /config/custom_components/localtuya/common.py:136> result=None>, None 2020-12-07 17:30:32 DEBUG (MainThread) [custom_components.localtuya.pytuya] [616...04b] Wait was aborted for seqno 1 2020-12-07 17:30:32 WARNING (SyncWorker_12) [custom_components.localtuya.switch] [616...04b] Entity switch.cl_front is requesting unknown DPS index 1

[Matssa56]

Havinng the same thing in #207

[Matssa56]

Btw guys, are you blocking the devices on your network? I mean blocking them through your routers or another way to avoid them sending info on the internet?

[jsbrich]

Not that I'm aware of. I'm able to use the Tuya Smart app (I close it and restart my phone after to make sure it isn't still running) and if I go to the Tuya developer website, it shows the device as Online. In my case, it is always the same one, so I'm trying to move the router around to make sure it is not an issue, but that doesn't seem to be helping.

[jsbrich]

The issue in #207 is a little different as I'm not able to click on the LED icon (lightning bolt since it's an outlet in my case) to change the status and get it working. That just brings up the Entity screen, which tells me that the device is unavailable. On a rare occasion, if I go to the Integration and select the Reload option, the device will come back. But I would say that works maybe 10% of the time.

One thing I've noticed in the logs is that once it gets marked as unavailable, nothing seems to try again. For example, the divce went unavailable at 8am yesterday, and there were no messages for the past 24 hours of even an attempt to try again. I have the debug level turned on, so I see the heartbeat request and response for the other devices, but nothing for the one that isn't working. Is this normal? Wouldn't it make sense to at least attempt to talk to it again?

[ultratoto14]

@jsbrich can you check your logs, what are the latest logs before it became unavailable?

[jsbrich]

The log I posted 6 comments up was the last messages I got that included anything about that device.
[custom_components.localtuya.switch] [616...04b] Entity switch.cl_front is requesting unknown DPS index 1

[c0m3r]

I have installed the 'passive' branch which has atleast partially resolved the issue. Disconnections still happen but reconnects pretty much immediately. Can cause an issue if your automations run whilst disconnected but much better than before.

[Fraklapince]

i've got the same issue. I've switch to localtuya a couple of week ago and i found this issue very anoying.
I previously use an old plugin (https://github.com/stast1/localtuya) for my switches NEO COOLCAM (working fine but doesn't support renaming throw lovelaceUI).
I've notice that even disconnection were not detected. I unplugged the switch from outlet and localtuya component doesn't detect it's disconnexion, even after few minutes. the interface let me try to change the switch status which return to the previous state after 3 or 4 seconds.
does this unavailibility concern only switches ?

[JonGilmore]

I too am seeing this issue with my Sylvania bulbs. I havent found any difference if I block outbound internet or not.

[smithbill17]

Why does the older 'localtuya' integration from @mileperhour not exhibit these same disconnect issues? I'm not experienced enough to know the differences between how they worked, but with my same SmartPlugs connected on exactly the same wall outlets and WiFi signals, the older integration worked without any issues, whereas with the newer one loses connection to one or two devices and the number losing connection increases over time. Just doing a device update on the integration seems to fix the problem for a short while, but soon afterwards it loses the connection again.

[ultratoto14]

@smithbill17 the integration on which this one is based was using a non persistent connection, in this one the connection should be persistent, for the moment, it seems that we have issues with this connection but we are working on it.

[rutgerkee]

same problem. LSC bulb works perfectly and then...unavailable. "Disable" and "Enable" fixes the problem. HA restart seems to do the trick as well. Not a durable solution.

[andrus2049]

Found the same problem.
Initially all is working, but after some time my Tuya devices become unavailable, and for me this is a problem, particularly since I use a wifi DIN switch to control my central house heater system, and if the boiler doesn't automatically start early in the morning the house is cold upon awakening.
Tested a few times, reloading the localtuya integration generally solves the problem for some time.
The Smartlife android app is not running, but the Smart Life Alexa skill is enabled (and Alexa commands can turn on/off the devices)
Eventually I had to revert to the official Tuya integration.:(

[DavidFFerreira]

this is still a probleme.....a big probleme =/

[wileu]

Yes it is big problem for me, too. I must back to the official Tuya integration :/

[ultratoto14]

Hello, can you check the PR #171 , some new changes may fix the unavailability problem.

[ultratoto14]

Hello all, can you check latest master version, PR has been merged.

[c0m3r]

Hello all, can you check latest master version, PR has been merged.

Been testing this for the last week or so. Devices still become unavailable regularly but quickly come back and for the most part, it resolves the issues I was experiencing. Occasionally if a script or automation runs at the exact second the device is unavailable then can be annoying but this is very rare now.

[lishan89uc]

i have been using master for a few days and i have now had the disconnected device issue at all. i have not seen the heart issues in logs. Will update when i got more info

[c0m3r]

Have continued to monitor but noticed devices are becoming unavailable very regularly. They do usually come back quickly but monitored my devices in developer tools and must have seen 20-30 appear unavailable in 30 seconds or so, sometimes the same device appeared multiple times

[lishan89uc]

Have continued to monitor but noticed devices are becoming unavailable very regularly. They do usually come back quickly but monitored my devices in developer tools and must have seen 20-30 appear unavailable in 30 seconds or so, sometimes the same device appeared multiple times

That’s interesting i have not had any issues at all for the last few days since i have been using masters (updated last week) what version of ha are you using also are there any logs from when they become unavailable?

[ShaneSpina]

are we saying the fix for this is to sever the connection for each device(endpoint) to the internet will fix this issue? I am losing 3 devices at least a day and not always the same device. If I remove them from the localtuya integration, restart HA I get them back, sometimes for a day, sometimes 2, but never for too long. I have 8, 3.1 firmware devices this happens with. I never lose connection to the 3.3 FW devices, just the 3.1 FW ones. I like the products and I like the integration (after a LONG time playing with them to get them to work) but I am almost over this and going to go to Zigbee lights. Restarting my HA also screws with my Zigbee mesh as I'm taking the coordinator offline every time I restart...

[lishan89uc]

Have to tried the master? Not the November release

[ShaneSpina]

I'm still pretty new to HA and GitHub in general.. how does one do that? (assuming that comment was directed at me?)

[lishan89uc]

@ShaneSpina Welcome, it is great to have new blood.
To get the "master" you just go to the home page of this project.Localtuya and the download the code. extract it if you use the zip option and copy the folder custom_components/localtuya.

As for HA side. you go into \\192.168.x.xxx\config\custom_components and paste/replace the localtuya folder in there. not sure if this is the "correct" way of installing the master but this way works. Also I am assuming you are using samba share on your HA. If not, you will have to find the config folder of your HA install.

Side note: I have been using HA for 2 years or so and I don't have a background in cs. so take everything i say with a grain of salt. i am still trying to figure out how to contribute to the wiki page for known devices.

PS. Do you guys know why there has not been a new release since the November one? I am pretty sure the patches from 10days ago are significant enough to warrant a release or at least a beta.

[ShaneSpina]

Thanks for the Welcome! copied and restarting HA now.

[smithbill17]

Can the 'master' version not be released so people using this integration via HACS can pick it up?

Given the issues with the constant disconnects, is it not possible to revert the code back to the original 'mileperhour' version (which didn't seem to have any issues) but make it HACS compatible? I'm not a coder, so no idea on just how difficult or time consuming that could be.

[ShaneSpina]

seems stable to me now.. I just copied the master code over the code in the localtuya folder in the custom components and rebooted HA

[postlund]

A release is coming any day now, @rospogrigio is preparing for it.

[vinhdizzo]

Any news on this update so we could install it via HACS? @postlund @rospogrigio

Thank you.

[smithbill17]

Any news on this update so we could install it via HACS? @postlund @rospogrigio

Thank you.

v3.2.0 was released 6days ago and it's a vast improvement in terms of reliability. You can update the integration in HACS.

[andrus2049]

Tested localtuya v. 3.2.0 (zip download) and devices now appear as unavailable a few times a day, but only for few second or a minute.

So I reworked all my automations to add a waiting for device state != unavailable before issueing a turn-on or turn-off command, just to be sure not to miss the device activation/deactivation if at the automation's scheduled running time the device is temporarily unavailable.

Thanks!

[vinhdizzo]

I just installed v 3.2.0 via HACS. I removed all of my tuya devices in HA so the slate is clear. I also removed all the devices in the Tuya App. I have DNS blocked via AdGuard on my tuya devices.

When I try to add one of my devices with the local tuya integration, I get the the following error after the name/local key/host submission:

An unknown error occurred. See log for details.

The log shows:

2021-01-06 12:23:34 ERROR (MainThread) [custom_components.localtuya.pytuya] [473...b6f] Failed to get status:
Traceback (most recent call last):
File "/config/custom_components/localtuya/pytuya/__init__.py", line 510, in detect_available_dps
data = await self.status()
File "/config/custom_components/localtuya/pytuya/__init__.py", line 472, in status
status = await self.exchange(STATUS)
File "/config/custom_components/localtuya/pytuya/__init__.py", line 467, in exchange
return await self.exchange(command, dps)
File "/config/custom_components/localtuya/pytuya/__init__.py", line 451, in exchange
msg = await self.dispatcher.wait_for(seqno)
File "/config/custom_components/localtuya/pytuya/__init__.py", line 240, 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
2021-01-06 12:23:34 ERROR (MainThread) [custom_components.localtuya.config_flow] Unexpected exception
Traceback (most recent call last):
File "/config/custom_components/localtuya/config_flow.py", line 279, in async_step_basic_info
self.dps_strings = await validate_input(self.hass, user_input)
File "/config/custom_components/localtuya/config_flow.py", line 192, in validate_input
detected_dps = await interface.detect_available_dps()
File "/config/custom_components/localtuya/pytuya/__init__.py", line 510, in detect_available_dps
data = await self.status()
File "/config/custom_components/localtuya/pytuya/__init__.py", line 472, in status
status = await self.exchange(STATUS)
File "/config/custom_components/localtuya/pytuya/__init__.py", line 467, in exchange
return await self.exchange(command, dps)
File "/config/custom_components/localtuya/pytuya/__init__.py", line 451, in exchange
msg = await self.dispatcher.wait_for(seqno)
File "/config/custom_components/localtuya/pytuya/__init__.py", line 240, 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

Any thoughts on how to resolve this?

[ShaneSpina]

I had 2 devices become unresponsive a few days ago, but I didn't have a chance to do anything about it and then magically they started working again.. weird right? or not?

[andrus2049]

I have DNS blocked via AdGuard on my tuya devices.

See if this can be the case:
#194

Edit: I see that you already know that issue! :)

[lishan89uc]

I have been getting a similar issue the worse happen last night a plug was unavailable for 7 hours. It only started working after i turned it on from the tuya app.
Edit: I think i found an oddball device. No other devices does this. This one Feit switch from costco. Will be unavailable after a restart 100% of the time until i turn it on and off with the app. product id: ezrzkbpajujvaoa4
edit2: I reset it by pressing the button down and holding it for 7-15 secs. after reset i re-added to my tuya account with the app. After editing my config.yaml again to put in the new key. its working now even after restart...

[beatmag]

I have been getting a similar issue the worse happen last night a plug was unavailable for 7 hours. It only started working after i turned it on from the tuya app.
Edit: I think i found an oddball device. No other devices does this. This one Feit switch from costco. Will be unavailable after a restart 100% of the time until i turn it on and off with the app. product id: ezrzkbpajujvaoa4
edit2: I reset it by pressing the button down and holding it for 7-15 secs. after reset i re-added to my tuya account with the app. After editing my config.yaml again to put in the new key. its working now even after restart...

For some reason, i've found the same thing, the tuya app is able to make the switch work again...even with no internet.
The other thing i've found is that Tuya to MQTT, is able to access DPS 1 (ie on or off), even when the device fails in localtuya.
This is interesting, what is Tuya to MQTT doing differently. But the energy values are all not present until.......starting tuya app, and allowing it to find the devices. (with no internet connected).