localtuya
localtuya copied to clipboard
rospogrigio
Devices become unavailable
Suddenly devices become unavailable forever. Tuya bulbs and plugs. In Tuya they work just fine. Reloading Local Tuya does not help.
To fix it I have to :
- edit one of my devices (doesn't matter which one) without changing anything and then all the unavailable devices become available again.
- Restart Home Assistant
BUT these work only for a short time. After a while the same thing happens.
Environment
- Localtuya version: 4.1.1
- Last working localtuya version (if known and relevant): before 4.1.0
- Home Assistant Core version: 2022.11.1
- [] Are you using the Home Assistant Tuya Cloud component ? no
- [] Are you using the Tuya App in parallel ? Have this installed but not using it
I have same issue with garage door. They use cover device type.
{
"home_assistant": {
"installation_type": "Home Assistant Container",
"version": "2022.11.1",
"dev": false,
"hassio": false,
"virtualenv": false,
"python_version": "3.10.7",
"docker": true,
"arch": "x86_64",
"timezone": "Europe/Bratislava",
"os_name": "Linux",
"os_version": "6.0.1",
"run_as_root": true
},
"custom_components": {
"linkplay": {
"version": "3.1.8",
"requirements": [
"async-upnp-client>=0.27",
"validators~=0.12",
"chardet>=4.0.0"
]
},
"localtuya": {
"version": "4.1.1",
"requirements": []
},
"hacs": {
"version": "1.28.3",
"requirements": [
"aiogithubapi>=22.2.4"
]
},
"browser_mod": {
"version": "2.1.2",
"requirements": []
},
"mikrotik_router": {
"version": "0.0.0",
"requirements": [
"librouteros>=3.2.0",
"mac-vendor-lookup>=0.1.12"
]
},
"skykettle": {
"version": "2.1",
"requirements": []
},
"delete": {
"version": "1.8",
"requirements": []
}
},
"integration_manifest": {
"domain": "localtuya",
"name": "LocalTuya integration",
"version": "4.1.1",
"documentation": "https://github.com/rospogrigio/localtuya/",
"dependencies": [],
"codeowners": [
"@rospogrigio",
"@postlund"
],
"issue_tracker": "https://github.com/rospogrigio/localtuya/issues",
"requirements": [],
"config_flow": true,
"iot_class": "local_push",
"is_built_in": false
},
"data": {
"device_config": {
"friendly_name": "garage_door",
"host": "192.168.x.x",
"local_key": "redacted",
"protocol_version": "3.1",
"scan_interval": 2,
"entities": [
{
"friendly_name": "garage_door_cover",
"commands_set": "open_close_stop",
"positioning_mode": "position",
"current_position_dp": 3,
"set_position_dp": 3,
"position_inverted": true,
"span_time": 25.0,
"id": 3,
"platform": "cover"
}
],
"device_id": "00352032483fda708e5b",
"dps_strings": [
"1 (value: stop)",
"3 (value: 0)",
"7 (value: stopping)"
],
"product_key": "xjl8nbcxpmmtyzbj"
}
}
}
have the same. after enabling debug logs i get this
2022-11-08 17:16:48.489 ERROR (Thread-4) [tuya_iot] error while get mqtt config
2022-11-08 17:16:48.504 ERROR (Thread-4) [root] Uncaught thread exception
Traceback (most recent call last):
File "/usr/local/lib/python3.10/threading.py", line 1016, in _bootstrap_inner
self.run()
File "/usr/local/lib/python3.10/site-packages/tuya_iot/openmq.py", line 161, in run
time.sleep(self.mq_config.expire_time - 60)
have the same. after enabling debug logs i get this
2022-11-08 17:16:48.489 ERROR (Thread-4) [tuya_iot] error while get mqtt config 2022-11-08 17:16:48.504 ERROR (Thread-4) [root] Uncaught thread exception Traceback (most recent call last): File "/usr/local/lib/python3.10/threading.py", line 1016, in _bootstrap_inner self.run() File "/usr/local/lib/python3.10/site-packages/tuya_iot/openmq.py", line 161, in run time.sleep(self.mq_config.expire_time - 60)
where do you find this ? I enabled the logs but where is this ?
I had the same issue and (finally) I was able to fix it:
I used tinytuya to scan my local network for Tuya devices and I noticed that the local keys for the unavailable ones have been changed!. Here are the steps for the solution:
- Install the tinytuya on your PC or a VM in the same network as your Tuya devices. Ideally, install it inside a virtual environment
- Run
python-m tinytuya scanto see the list of the available devices. - In the command output, find your device (based on device ID or IP address) and copy the value of
Local Key. - Go to HA -> Settings -> Integrations -> Localtuya -> Configure
- Select: Edit a device
- Finally change the
Local keyand save.
Your device is now alive!
#1116
@yassineselmi I'm familiar with tinytuya, but I have this issue with newly added device. Anyway, I have checked my local key with tinytuya and with HA, they are same.
here are some more logs::
Logger: homeassistant.util.logging
Source: util/logging.py:168
First occurred: 07:19:03 (617 occurrences)
Last logged: 08:07:58
Exception in _update_handler when dispatching 'localtuya_00352032483fda708e5b': ({'1': 'open', '3': 0, '7': 'stopping'},) Traceback (most recent call last): File "/config/custom_components/localtuya/common.py", line 406, in _update_handler self.status_updated() File "/config/custom_components/localtuya/cover.py", line 195, in status_updated if self._state.isupper(): AttributeError: 'int' object has no attribute 'isupper'
Exception in _update_handler when dispatching 'localtuya_00352032483fda708e5b': ({'1': 'stop', '3': 0, '7': 'stopping'},) Traceback (most recent call last): File "/config/custom_components/localtuya/common.py", line 406, in _update_handler self.status_updated() File "/config/custom_components/localtuya/cover.py", line 195, in status_updated if self._state.isupper(): AttributeError: 'int' object has no attribute 'isupper'
Exception in _update_handler when dispatching 'localtuya_00352032483fda708e5b': ({'1': 'stop', '3': 100, '7': 'stopping'},) Traceback (most recent call last): File "/config/custom_components/localtuya/common.py", line 406, in _update_handler self.status_updated() File "/config/custom_components/localtuya/cover.py", line 195, in status_updated if self._state.isupper(): AttributeError: 'int' object has no attribute 'isupper'
Exception in _update_handler when dispatching 'localtuya_00352032483fda708e5b': ({'1': 'stop', '3': 100, '7': 'opening'},) Traceback (most recent call last): File "/config/custom_components/localtuya/common.py", line 406, in _update_handler self.status_updated() File "/config/custom_components/localtuya/cover.py", line 195, in status_updated if self._state.isupper(): AttributeError: 'int' object has no attribute 'isupper'
I had the same issue and (finally) I was able to fix it:
I used tinytuya to scan my local network for Tuya devices and I noticed that the local keys for the unavailable ones have been changed!. Here are the steps for the solution:
- Install the tinytuya on your PC or a VM in the same network as your Tuya devices. Ideally, install it inside a virtual environment
- Run
python-m tinytuya scanto see the list of the available devices.- In the command output, find your device (based on device ID or IP address) and copy the value of
Local Key.- Go to HA -> Settings -> Integrations -> Localtuya -> Configure
- Select: Edit a device
- Finally change the
Local keyand save.Your device is now alive!
#1116
Nope. To me is not the local key. After restart it works for a little while. Local key was the first that came to my mind and checked that, it hadn't changed. Nevertheless I setup the cloud api just for testing cause I hadn't done that yet.
I rolled back 2 versions. It seems this happens constantly with various devices of mine but not always the same devices.
@fotis3d Is it working with a prior version?
@tefracky I rolled back to 4.0.2 when I had zero problems in general. Nor availability neither DPS. It seems ok but for sure I should leave it 2-3 days to let you know for sure. 😉
@fotis3d Is it working with a prior version?
@tefracky I rolled back to 4.0.2 when I had zero problems in general. Nor availability neither DPS. It seems ok but for sure I should leave it 2-3 days to let you know for sure. 😉
Thanks a lot, I will give it a try!
I have the same issue described, and I was just able to see it as an error in the logs. Not sure if it helps. It only happens with two devices in the last few months, while the other 10 seem unaffected. They work fine from the Tuya app, and I use the app only when I see a failure on HA to check if the device is working.
2022-11-10 16:42:39.900 DEBUG (MainThread) [custom_components.localtuya.pytuya] [bf0...bzj] Dispatching message TuyaMessage(seqno=0, cmd=9, retcode=0, payload=b'', crc=2958142211)
2022-11-10 16:42:39.901 DEBUG (MainThread) [custom_components.localtuya.pytuya] [bf0...bzj] Got heartbeat response
2022-11-10 16:42:39.902 DEBUG (MainThread) [custom_components.localtuya.pytuya] [bf2...ryg] Dispatching message TuyaMessage(seqno=0, cmd=9, retcode=0, payload=b'', crc=2958142211)
2022-11-10 16:42:39.903 DEBUG (MainThread) [custom_components.localtuya.pytuya] [bf2...ryg] Got heartbeat response
2022-11-10 16:42:39.904 DEBUG (MainThread) [custom_components.localtuya.pytuya] [bf0...bzj] Decrypted payload: {}
2022-11-10 16:42:39.905 DEBUG (MainThread) [custom_components.localtuya.pytuya] [bf2...ryg] Decrypted payload: {}
2022-11-10 16:42:40.008 DEBUG (MainThread) [custom_components.localtuya.pytuya] [bf3...kzx] Dispatching message TuyaMessage(seqno=0, cmd=9, retcode=0, payload=b'', crc=2958142211)
2022-11-10 16:42:40.009 DEBUG (MainThread) [custom_components.localtuya.pytuya] [bf3...kzx] Got heartbeat response
2022-11-10 16:42:40.010 DEBUG (MainThread) [custom_components.localtuya.pytuya] [bf3...kzx] Decrypted payload: {}
2022-11-10 16:42:47.713 ERROR (MainThread) [custom_components.localtuya.common] [bfb...3ty] Connect to 192.168.0.158 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 704, 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.0.158', 6668)
2022-11-10 16:42:49.598 DEBUG (MainThread) [custom_components.localtuya.pytuya] [213...873] Sending command heartbeat (device type: type_0a)
2022-11-10 16:42:49.599 DEBUG (MainThread) [custom_components.localtuya.pytuya] [213...873] Send payload: b'{}'
2022-11-10 16:42:49.603 DEBUG (MainThread) [custom_components.localtuya.pytuya] [213...873] Waiting for sequence number -100
2022-11-10 16:42:49.608 DEBUG (MainThread) [custom_components.localtuya.pytuya] [438...21e] Sending command heartbeat (device type: type_0a)
2022-11-10 16:42:49.608 DEBUG (MainThread) [custom_components.localtuya.pytuya] [438...21e] Send payload: b'{}'
2022-11-10 16:42:49.612 DEBUG (MainThread) [custom_components.localtuya.pytuya] [438...21e] Waiting for sequence number -100
reading though this and yeah im getting some issues. I restart HA and its fine for a bit. I have added the device a few times, will try again
@tefracky as expected since yesterday the 4.0.2 version works just fine. I think I will stick to that long before I upgrade. 😉
I also rolled back to 4.0.2 and so far so good - connection to devices is much better.
FWIW, I still see errors in the HA logs, but they don't seem to matter. Disconnects actually do seem to still be happening, but they only last briefly, and then the device becomes available again.
2022-11-11 18:59:49.086 ERROR (MainThread) [custom_components.localtuya.common] [146...1f7] Connect to 192.168.86.22 failed
Traceback (most recent call last):
File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/asyncio/locks.py", line 385, in acquire
await fut
asyncio.exceptions.CancelledError
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/asyncio/tasks.py", line 456, in wait_for
return fut.result()
asyncio.exceptions.CancelledError
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/Users/nathan/.homeassistant/custom_components/localtuya/common.py", line 170, in _make_connection
status = await self._interface.status()
File "/Users/nathan/.homeassistant/custom_components/localtuya/pytuya/__init__.py", line 481, in status
status = await self.exchange(STATUS)
File "/Users/nathan/.homeassistant/custom_components/localtuya/pytuya/__init__.py", line 460, in exchange
msg = await self.dispatcher.wait_for(seqno)
File "/Users/nathan/.homeassistant/custom_components/localtuya/pytuya/__init__.py", line 247, in wait_for
await asyncio.wait_for(self.listeners[seqno].acquire(), timeout=timeout)
File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/asyncio/tasks.py", line 458, in wait_for
raise exceptions.TimeoutError() from exc
asyncio.exceptions.TimeoutError
Maybe a stupid question, but how did you disabled the automatic update in HACS?
Maybe a stupid question, but how did you disabled the automatic update in HACS?
its not automatic. When an update is available you have the option to update or skip
@tefracky as @cloudbr34k84 said it is not automatic. I just skip Local Tuya update.
Okay, I was very confuesd. I used HACS --> Localtuya --> Ddownload again --> Version 4.0.2 However, I stucked on 4.1.1, so I thought it was updated automatically. I don't know, what was going wrong, but now I am on version 4.0.2 and it works all fine.
Downgrading to version 4.0.2 didn't help for me.
Half of my devices are working fine. Other half are not accessible. What I noticed is that those that I can't add does not respond to DP test.py and drops error message:
WARNING:localtuya.pytuya:Failed to get status: [Errno 104] Connection reset by peer
Even if I get local key from cloud and add manually, DPs are still unavailable. All those devices work perfectly fine with Smart life app, default Tuya integration and cloud commands. It just seems that some local port or socket was closed for some devices so they are not accessible through LAN anymore.
Also if I go to Smart life app, device -> edit -> Check Device Network -> Check Now, it fails. All other devices that does not fail works perfectly fine.
Edit: After a lot of hassle I managed to fix. I used iot cloud to factory reset devices and then added them with Tuya app (not Smart life) and after that devices were discovered so for some I have to manually add DPs.
Tried 4.0.2 with cloud API, right after adding device it is visible as unavialable, but commend for open/close works.
@bobloadmire nothing yet. Latest working version for most of us is 4.02. Roll back to that. At least until this is fixed.
Like others here I was consistently having serious issues with devices becoming unavailable when using the latest release. Using 4.02 seems to have cured them.
I have the strangest issue. I rolled back to 4.02, things are better, but now the wall dimmers won't dim. Either by app or the physical buttons on the wall. I have 8 in my house, every single one stopped dimming. what the hell happened? my physical controls broke??
I am also having issues with my Feit lightbulbs. I turn them off via HA and then they seem to drop off the network and go unresponsive within minutes. Turning them off and on by the switch seems to resolve it.
I found this solution below from https://community.home-assistant.io/t/localtuya-entity-is-showing-as-unavailable/275438/7 evgeny.bachevsky
" I’ve resolved the issue by using automatization on homeassistant - start trigger with action homeassistant.reload_config_entry for a group of Tuya devices. Or “unavailable” state trigger for Tuya devices can be also used.
As I was losing devices only when HA restart, it was the trigger. It’s very simple:
alias: AUTO Local Tuya reconnect
description: ''
trigger:
- platform: homeassistant
event: start
condition: []
action:
- delay:
hours: 0
minutes: 0
seconds: 10
milliseconds: 0
- service: homeassistant.reload_config_entry
target:
entity_id: group.all_lights or your_entity_id
mode: single
And in ‘groups.yaml’ something like that:
all_lights:
name: All lights
icon: mdi:lightbulb-group
entities:
- switch.AAA
- light.xiaomi_gateway_light
- light.BBB
- switch.CCC
- ...
"
@bursa I do not think you need a solution. Furthermore to me happened without restarting HA. It is clearly this version's bug. With 4.0.2 everything works like a charm.
I found this solution below from https://community.home-assistant.io/t/localtuya-entity-is-showing-as-unavailable/275438/7 evgeny.bachevsky
" I’ve resolved the issue by using automatization on homeassistant - start trigger with action homeassistant.reload_config_entry for a group of Tuya devices. Or “unavailable” state trigger for Tuya devices can be also used.
As I was losing devices only when HA restart, it was the trigger. It’s very simple:
alias: AUTO Local Tuya reconnect description: '' trigger: - platform: homeassistant event: start condition: [] action: - delay: hours: 0 minutes: 0 seconds: 10 milliseconds: 0 - service: homeassistant.reload_config_entry target: entity_id: group.all_lights or your_entity_id mode: singleAnd in ‘groups.yaml’ something like that:
all_lights: name: All lights icon: mdi:lightbulb-group entities: - switch.AAA - light.xiaomi_gateway_light - light.BBB - switch.CCC - ..."
i having same issue. 3 out of 8 switches are unavailable. edit setup in localtuya one of them then everything go back normal
I found this solution below from https://community.home-assistant.io/t/localtuya-entity-is-showing-as-unavailable/275438/7 evgeny.bachevsky " I’ve resolved the issue by using automatization on homeassistant - start trigger with action homeassistant.reload_config_entry for a group of Tuya devices. Or “unavailable” state trigger for Tuya devices can be also used. As I was losing devices only when HA restart, it was the trigger. It’s very simple:
alias: AUTO Local Tuya reconnect description: '' trigger: - platform: homeassistant event: start condition: [] action: - delay: hours: 0 minutes: 0 seconds: 10 milliseconds: 0 - service: homeassistant.reload_config_entry target: entity_id: group.all_lights or your_entity_id mode: singleAnd in ‘groups.yaml’ something like that:
all_lights: name: All lights icon: mdi:lightbulb-group entities: - switch.AAA - light.xiaomi_gateway_light - light.BBB - switch.CCC - ..."
i having same issue. 3 out of 8 switches are unavailable. edit setup in localtuya one of them then everything go back normal
This is not a solution, it's a workaround, I've used something similar for a while now. I hope it gets actually fixed.
I am on version 4.1.1 and experience frequent disconnect from my device:
2022-11-27 18:38:20.358 DEBUG (MainThread) [custom_components.localtuya.pytuya] [004...592] Sending command heartbeat (device type: type_0a)
2022-11-27 18:38:20.358 DEBUG (MainThread) [custom_components.localtuya.pytuya] [004...592] Send payload: b'{}'
2022-11-27 18:38:20.359 DEBUG (MainThread) [custom_components.localtuya.pytuya] [004...592] Waiting for sequence number -100
2022-11-27 18:38:20.368 DEBUG (MainThread) [custom_components.localtuya.pytuya] [004...592] Dispatching message TuyaMessage(seqno=0, cmd=9, retcode=0, payload=b'', crc=2958142211)
2022-11-27 18:38:20.369 DEBUG (MainThread) [custom_components.localtuya.pytuya] [004...592] Got heartbeat response
2022-11-27 18:38:20.369 DEBUG (MainThread) [custom_components.localtuya.pytuya] [004...592] Decrypted payload: {}
2022-11-27 18:38:22.108 ERROR (MainThread) [custom_components.localtuya.pytuya] [004...592] Failed to get status: Traceback (most recent call last):
File "/usr/local/lib/python3.10/asyncio/locks.py", line 390, in acquire
await fut
asyncio.exceptions.CancelledError
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/lib/python3.10/asyncio/tasks.py", line 456, in wait_for
return fut.result()
asyncio.exceptions.CancelledError
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/config/custom_components/localtuya/pytuya/__init__.py", line 574, in detect_available_dps
data = await self.status()
File "/config/custom_components/localtuya/pytuya/__init__.py", line 507, in status
status = await self.exchange(STATUS)
File "/config/custom_components/localtuya/pytuya/__init__.py", line 486, in exchange
msg = await self.dispatcher.wait_for(seqno)
File "/config/custom_components/localtuya/pytuya/__init__.py", line 259, in wait_for
await asyncio.wait_for(self.listeners[seqno].acquire(), timeout=timeout)
File "/usr/local/lib/python3.10/asyncio/tasks.py", line 458, in wait_for
raise exceptions.TimeoutError() from exc
asyncio.exceptions.TimeoutError
2022-11-27 18:38:22.110 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/usr/local/lib/python3.10/asyncio/locks.py", line 390, in acquire
await fut
asyncio.exceptions.CancelledError
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/lib/python3.10/asyncio/tasks.py", line 456, in wait_for
return fut.result()
asyncio.exceptions.CancelledError
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/config/custom_components/localtuya/common.py", line 299, in _async_refresh
await self._interface.update_dps()
File "/config/custom_components/localtuya/pytuya/__init__.py", line 535, in update_dps
await self.detect_available_dps()
File "/config/custom_components/localtuya/pytuya/__init__.py", line 574, in detect_available_dps
data = await self.status()
File "/config/custom_components/localtuya/pytuya/__init__.py", line 507, in status
status = await self.exchange(STATUS)
File "/config/custom_components/localtuya/pytuya/__init__.py", line 486, in exchange
msg = await self.dispatcher.wait_for(seqno)
File "/config/custom_components/localtuya/pytuya/__init__.py", line 259, in wait_for
await asyncio.wait_for(self.listeners[seqno].acquire(), timeout=timeout)
File "/usr/local/lib/python3.10/asyncio/tasks.py", line 458, in wait_for
raise exceptions.TimeoutError() from exc
asyncio.exceptions.TimeoutError
Seems similar to https://github.com/rospogrigio/localtuya/issues/1117#issuecomment-1312521916
Once localtuya loses track of my device, it will be stuck in a rut until I manually restart localtuya.
The default scan interval is 20 seconds and I experience this error. I am going to adjust this device to 5 seconds and see if that provides any insight.
Only theorizing but maybe there is a network request concurrency issue, etc., that once it fails, it snowballs and gets stuck.
