Certain Devices goes Unavailable indefinetly with wierd reconnection issues #1804
Comments
|
Possibly related to this upstream bug: jasonacox/tinytuya#472 |
|
this happens to me every time when I turn off the power of the device (lights) and then turn it back on, and I will have to reload the entry for the device otherwise TL would not be able to reconnect to the device. |
|
Have you set the IP address and protocol version? |
|
yup, both are set manually and not auto. I will observe more to see if it’s specific to certain protocol version or device |
|
For what it's worth. In my situation it happens when the device is known/configured and worked in tuya-local but becomes unreachable. When disabeling this device in tuya-local, everything seems to return to 'nomal'' and my GUI is responsive again. |
|
hi, having the same issues with three of my heatpumps. will implement a reload fix automation, happy to test / debug a fix, thanks |
|
I think I have a similar problem with Tongou TO-Q-SY1-JWT. As long as it has an active load it doesn't seem to have a problem but when I remove the load (sometimes) the device becomes unavailable. |
just use the Call Service "Home Assistant Core Integration: Reload config entry" and choose for Device as a target and look for a tuya device that your having problem with. as for trigger, you can use any part of that tuya device that goes unavailable, in this case I used the "child lock" entity of the device as a trigger, if the state goes unavailable or unknown, execute a reload config call service action. |
|
Just to mention, when the device goes unavailable in Tuya Local:
|
|
I am currently working around this issue by using an entity template and adding redundancy (use Tuya Local if it's available, or use Tuya Cloud otherwise): cover:
- platform: template
covers:
portao:
unique_id: 210958c8-e7e8-4a44-8e52-0c393b71b990
friendly_name: Portão
device_class: garage
value_template: "{{ (not is_state('cover.portao_tuya_local', 'unavailable') and not is_state('cover.portao_tuya_local', 'closed')) or (not is_state('cover.portao_tuya_cloud', 'unavailable') and not is_state('cover.portao_tuya_cloud', 'closed')) }}"
availability_template: "{{ not is_state('cover.portao_tuya_local', 'unavailable') or not is_state('cover.portao_tuya_cloud', 'unavailable') }}"
open_cover:
if:
condition: template
value_template: "{{ not is_state('cover.portao_tuya_local', 'unavailable') }}"
then:
action: cover.toggle
data:
entity_id: cover.portao_tuya_local
else:
action: cover.toggle
data:
entity_id: cover.portao_tuya_cloud
close_cover:
if:
condition: template
value_template: "{{ this.state != 'closed' }}"
then:
if:
condition: template
value_template: "{{ not is_state('cover.portao_tuya_local', 'unavailable') }}"
then:
action: cover.toggle
data:
entity_id: cover.portao_tuya_local
else:
action: cover.toggle
data:
entity_id: cover.portao_tuya_cloud |
|
This bug appears to be more extreme for me as time goes by (or I'm just having a string of bad luck). On top of that, I just ran into an issue that's stopping me from reloading the integration? The error I get when doing the service call is |
|
The receive loop terminates when you reload the integration, it is normal, and shows that the reload is working. |
make-all
added
awaiting confirmation
|
@make-all, I'm very excited about 3fafb5f. I have reverted my workaround and I am now testing it. Let's see how the following days goes. |
|
@make-all, unfortunately, after working perfectly well for over a week, I noticed this issue again.
This makes me think if the integration itself isn't retrying the connection properly. Do you think I should open a different issue or should this one be reopened? |
|
I just realized I should have tried to capture some logs. I will try next time. |
|
Ok, I have a better story to tell now:
Weird. I captured debug logs during the Reload and Re-CONFIGURE, but I'm not sure it will help. tuya_local_bbb18cee736636978b25f07001002a50_Portão_da_garagem_de.json |
|
Just ran into either this or a similar issue. I have a large amount of lights configured through tuya-local. A power cycle of the lights + router caused some of the light IP addresses to change, I assume, and no longer connect to tuya-local. Is there a way for the device reload to re-do the IP address scanning step and keep the remaining settings, without going through the whole remove + re-add device flow? Assuming the device ID is stored, this should be able to be done automatically. Does it already happen and it just didn't work in case for some reason? |
|
@dominguesgm, in my case I add static IP leases in the router for each device to help with this issue. |
|
@make-all I was able to find a consistent case that may be actionable. chrome_C14aJVI1dJ.mp4Notes:
The debug logs indicate an issue similar to #2578: |
|
I'm running into the same issue. From Tuya Smart everything works fine after a power outage. But not through HA. My fix for now was to reload the configuration of the device and now it shows up working again. |
|
This issue is really difficult. People seem to have very different root causes and solutions. Today I was only able to work around it by rebooting my HA instance (restarting the container only multiple times did not help). Anyway, I'd suggest focusing on one actionable item at a time. @make-all, have you by any chance tried to reproduce what I described here? I wonder if you were able to. |
|
This issue seems like only affects device that uses protocol 3.4 or higher, only my newer tuya wifi devices is affected to this but majority of my wifi tuya device running the 3.3 protocol works just fine. Though as of this comment, almost all of my 3.3 tuya devices are now migrated to esphome using tuya-cloudcutter the rest of my 3.3 devices is still connected using this integration, 3.4 and higher devices is now connected using the cloud based tuya integration. |
The condition for appearing available required data to have been returned from the device since the last reconnection, but we now support devices that don't return any data such as IR controls, and some devices do not seem to return anything on reconnection until something changes. In those cases, the state should appear as Unknown rather than unavailable. May help with #1804
Describe the bug
When a device sensors and switches goes Unavailable, tuya local seems to re-connect to the device with weird reconnection issue. First the device seems to get reconnected but a few seconds later, it goes to Unavailable again, this thing happens several times per minute. Tried debugging it if its a networking related issue but no, the AP sees the device still connected and able to ping the device just fine.
The only way to fix this issue is "reload" the device by going to Settings > Device & Services > Tuya Local > Your Device, after that click the 3 dot thingy beside the problematic device and click reload. Take note, even power cycling the device doesnt fix the issue more like it actually gets worse since it no longer able to reconnect to the device, unlike before it was able to connect to the device albeit it only last for a few seconds.
Currently the device is disconnected to the internet, making the device unblocked to the internet make no difference. No other smartphone app that can directly control the device, the only way to control this device is through home assistant, I only run the tuya app if I want to add a new device to my tuya account but after that the smart app gets deleted.
To Reproduce
Unknown, The issue happens randomly.
Expected behavior
If the device gets disconnected, local tuya should be able to reconnect to device without any issue.
Additional context
Device Diagnostic
Home Assistant Log related to the issue
Workaround:
Create a new automation based on device state, if the device goes unavailable, do a call service integration reload on specific problematic device.
The text was updated successfully, but these errors were encountered: