Devices become unavailable

[fotis3d]

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 :

1. edit one of my devices (doesn't matter which one) without changing anything and then all the unavailable devices become available again.
2. 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

[rchovan]

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"
    }
  }
}

[zavodnyuk]

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)                                                                                                                                  

[fotis3d]

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 ?

[yassineselmi]

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:

1. Install the tinytuya on your PC or a VM in the same network as your Tuya devices. Ideally, install it inside a virtual environment
2. Run python-m tinytuya scan to see the list of the available devices.
3. In the command output, find your device (based on device ID or IP address) and copy the value of Local Key.
4. Go to HA -> Settings -> Integrations -> Localtuya -> Configure
5. Select: Edit a device
6. Finally change the Local key and save.

Your device is now alive!

#1116

[rchovan]

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

[fotis3d]

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:

1. Install the tinytuya on your PC or a VM in the same network as your Tuya devices. Ideally, install it inside a virtual environment
2. Run python-m tinytuya scan to see the list of the available devices.
3. In the command output, find your device (based on device ID or IP address) and copy the value of Local Key.
4. Go to HA -> Settings -> Integrations -> Localtuya -> Configure
5. Select: Edit a device
6. Finally change the Local key and 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.

[fotis3d]

I rolled back 2 versions. It seems this happens constantly with various devices of mine but not always the same devices.

[tefracky]

@fotis3d Is it working with a prior version?

[fotis3d]

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

[tefracky]

@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!

[LuigiPapino]

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

[cloudbr34k84]

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

[fotis3d]

@tefracky as expected since yesterday the 4.0.2 version works just fine. I think I will stick to that long before I upgrade. 😉

[nzrutman]

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

[tefracky]

Maybe a stupid question, but how did you disabled the automatic update in HACS?

[cloudbr34k84]

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

[fotis3d]

@tefracky as @cloudbr34k84 said it is not automatic. I just skip Local Tuya update.

[tefracky]

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.

[kem-a]

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.

[rchovan]

Tried 4.0.2 with cloud API, right after adding device it is visible as unavialable, but commend for open/close works.

[bobloadmire]

Any movement on this? Whole setup is fucked

[fotis3d]

@bobloadmire nothing yet. Latest working version for most of us is 4.02. Roll back to that. At least until this is fixed.

[Booza1981]

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.

[bobloadmire]

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

[javellino]

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.

[bursa]

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

"

[fotis3d]

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

[orochifj]

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

"

i having same issue. 3 out of 8 switches are unavailable. edit setup in localtuya one of them then everything go back normal

[fldc]

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

"

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.

[Anj-0110]

How do you do this?
…
On Thu, Nov 9, 2023, 12:11 AM Anj-0110 @.> wrote: FYI...since I have disabled the background data in the SmartLife app on my phone I have not had any of the tuya devices cycle through unavailable then on or off randomly. It have only been 2 days but the logs have been clear since doing so. Something worth trying for those that are having the same issues. If this is the fix, hallelujah! It is so nice not to log in and NOT see random lights on!! — Reply to this email directly, view it on GitHub <#1117 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOB2WBAKDK6KVK5UOSMO3UTYDOHKFAVCNFSM6AAAAAARZ6H4BCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBRHE3DQNZYGY . You are receiving this because you were mentioned.Message ID: @.>

I went into my app setting in my andriod phone, opened SMARTLIFE settings, went into mobile data and turned off "allow background data usage"

I have to admit, I have still had some issues with lights becoming unavailable and then turning on or off but it has not been as frequent as before.

[yjamal01]

I have the same problem and it happens only with tuya devices. They are from different manufacturers so I could have maybe blame a HA server or a router, but other smart devices connected to the same wi-fi work perfectly fine. Don't know what can be the reason.

just delete official smart life app from all of your devices. this app is working on the background and query your devices. Or restrict app to not to run in background

Had the same issue, switched to tuya local instead and its been good. 2 of my USB smart switches weren't supported, but I took that over the constant available/unavailable issue

[yeowan]

So I went through the entire thread and fixed the issue after some hours of experimenting. Funny that this was mentioned before by someone, but seemingly most people ignored the comment(s).

FIX FOR LOCALTUYA DEVICES BECOMING UNAVAILABLE follows:

You need to be sure that nothing else tries to connect to your registered device but LocalTuya. Otherwise it (either immediately or after a few occasions) corrupts LocalTuya's connection to the device until the whole HA is restarted.
Close and disable Tuya app in your phone, in your wife's and children's phone. Disable Tuya built-in integration in HA. Close and do not use "Tuya IOT platform". You can even disable localtuya's own cloud integration if you completed the configuration (and restarted HA).

I am pretty sure if LocalTuya device becoming unavailable or starts to "act funny" like providing the sensor data , but your commands are not recognized, then something tried to connect to it through Tuya Cloud or locally.

[fotis3d]

What if we also use Official Tuya along with Local Tuya ?
I cannot stop official Tuya since I also use infrared devices that require internet.

Why is this happening ? I use quite some time Local Tuya and I did not have disconnections before. Now they are constant.

[yjamal01]

What if we also use Official Tuya along with Local Tuya ? I cannot stop official Tuya since I also use infrared devices that require internet.

Why is this happening ? I use quite some time Local Tuya and I did not have disconnections before. Now they are constant.

switch to tuya local instead. I am using that and no offline issue so far. I use the tuya integration and tuya app too, no problem

[kdober]

Honestly I don't know what else to do here.
My roller shade (zemismart ZM25RW01) lose connection, some times after a minute, sometimes after a few hours. Some times it comes back when I edit the settings, sometimes I have to delete it (and even after re-adding it is shows up as unavailable).
A few times I was able to bring it back by chaging the "Show as" of the device, for example to Shade or Blind.

Other smart plugs I have, same issue. After few hours they become unavailable. Reload of localtuya might bring one back to life, but not all. I need to take out the plug from the wall, wait a few hours and restart HA and the work again for some minutes or hours.

When this happens, it was still possible to control those devices from the Tuya/Smart life apps.
As suggested above in the thread, I removed those apps from the phone, also Tuya cloud integration in HA, close session on Tuya dev. Nothing seems to work :(

I'm not blocking any connections on my router (tp link deco) and I neither have any other software for DNS, routing, etc.

Getting out of ideas here :(

Cheers
Cristian

[Pouackito]

So I went through the entire thread and fixed the issue after some hours of experimenting. Funny that this was mentioned before by someone, but seemingly most people ignored the comment(s).

FIX FOR LOCALTUYA DEVICES BECOMING UNAVAILABLE follows:

You need to be sure that nothing else tries to connect to your registered device but LocalTuya. Otherwise it (either immediately or after a few occasions) corrupts LocalTuya's connection to the device until the whole HA is restarted. Close and disable Tuya app in your phone, in your wife's and children's phone. Disable Tuya built-in integration in HA. Close and do not use "Tuya IOT platform". You can even disable localtuya's own cloud integration if you completed the configuration (and restarted HA).

I am pretty sure if LocalTuya device becoming unavailable or starts to "act funny" like providing the sensor data , but your commands are not recognized, then something tried to connect to it through Tuya Cloud or locally.

This solved my problem, tks !

[Loeffelmaster]

My devices even have no access to the internet or DNS and with all these changes, they still get unavailable and a restart of HA and making the device powerless doesn't solve the problem.
In an old version (not available anymore this problem never came up on my system and nothing changed except an update of LocalTuya. By now I have also 4 devices via bluetooth I couldn't get connected to LocalTuya so even if it would work, what isn't the case for me, I couldn't use it anymore.

[kdober]

Is there any way to get back to version 4.0.2? The list of previous versions only shows last 5 of them and I have no clue how to get back to an older one.

[yeowan]

Honestly I don't know what else to do here. My roller shade (zemismart ZM25RW01) lose connection, some times after a minute, sometimes after a few hours. Some times it comes back when I edit the settings, sometimes I have to delete it (and even after re-adding it is shows up as unavailable). A few times I was able to bring it back by chaging the "Show as" of the device, for example to Shade or Blind.

Other smart plugs I have, same issue. After few hours they become unavailable. Reload of localtuya might bring one back to life, but not all. I need to take out the plug from the wall, wait a few hours and restart HA and the work again for some minutes or hours.

When this happens, it was still possible to control those devices from the Tuya/Smart life apps. As suggested above in the thread, I removed those apps from the phone, also Tuya cloud integration in HA, close session on Tuya dev. Nothing seems to work :(

I'm not blocking any connections on my router (tp link deco) and I neither have any other software for DNS, routing, etc.

Getting out of ideas here :(

Cheers Cristian

I am sure that there is still something trying to connect. Think what apps / solutions did you use in the past to connect. Do you have other family members who might use Tuya/Smart life? Do you have any polling set up anywhere by anything? Do you have schedules set up in Tuya cloud or anywhere?
Try re-set up one of your plugs in localtuya, then remove it from Tuya and Smartlife Apps entirely. Restart HA, and let's see if the issue persist.

[tefracky]

I am using this fork and all my devices work without any error: https://github.com/xZetsubou/hass-localtuya

[kdober]

Honestly I don't know what else to do here. My roller shade (zemismart ZM25RW01) lose connection, some times after a minute, sometimes after a few hours. Some times it comes back when I edit the settings, sometimes I have to delete it (and even after re-adding it is shows up as unavailable). A few times I was able to bring it back by chaging the "Show as" of the device, for example to Shade or Blind.
Other smart plugs I have, same issue. After few hours they become unavailable. Reload of localtuya might bring one back to life, but not all. I need to take out the plug from the wall, wait a few hours and restart HA and the work again for some minutes or hours.
When this happens, it was still possible to control those devices from the Tuya/Smart life apps. As suggested above in the thread, I removed those apps from the phone, also Tuya cloud integration in HA, close session on Tuya dev. Nothing seems to work :(
I'm not blocking any connections on my router (tp link deco) and I neither have any other software for DNS, routing, etc.
Getting out of ideas here :(
Cheers Cristian

I am sure that there is still something trying to connect. Think what apps / solutions did you use in the past to connect. Do you have other family members who might use Tuya/Smart life? Do you have any polling set up anywhere by anything? Do you have schedules set up in Tuya cloud or anywhere? Try re-set up one of your plugs in localtuya, then remove it from Tuya and Smartlife Apps entirely. Restart HA, and let's see if the issue persist.

Two devices came back to life for 1, almost 2 days but then they went back to unavailable.
I'm quite sure nothing is open. The Smartlife and Tuya apps, when open on the phone are asking for my credentials (since I deleted all data for the apps). API pages are closed.
No familly members or invited emails. Will try next weekend with other versions or the fork suggested on previous post and comment how it goes.
Cheers

[JohnMcLear]

@yeowan

So I went through the entire thread and fixed the issue after some hours of experimenting. Funny that this was mentioned before by someone, but seemingly most people ignored the comment(s).

FIX FOR LOCALTUYA DEVICES BECOMING UNAVAILABLE follows:

You need to be sure that nothing else tries to connect to your registered device but LocalTuya. Otherwise it (either immediately or after a few occasions) corrupts LocalTuya's connection to the device until the whole HA is restarted. Close and disable Tuya app in your phone, in your wife's and children's phone. Disable Tuya built-in integration in HA. Close and do not use "Tuya IOT platform". You can even disable localtuya's own cloud integration if you completed the configuration (and restarted HA).

I am pretty sure if LocalTuya device becoming unavailable or starts to "act funny" like providing the sensor data , but your commands are not recognized, then something tried to connect to it through Tuya Cloud or locally.

1. Is it possible to add new devices without the app?
2. Is disabling the cloud integration required to achieve stability?
3. What about if I need both online and offline access? Is that no longer viable if I want stability?

The README docs state in bold "NOTE: The Cloud API account configuration is not mandatory (LocalTuya can work also without it) but is strongly suggested" - is this erroneous?

[yeowan]

1, the easiest way is to do a "config round": add devices to the cloud/TuyaApp, then configure in localtuya/HA , then close TuyaApp, restart HA, and all will be ok. If I recall correctly someone posted the procedure how to add devices without app, search for it if you really want.
2, No. However in some cases (for some devices?) it actually breaks the connection. Test it first leaving it on and if you experience strange behavior then disable it.
3, If you mean the TuyaApp under "online access" then you can't do that. However you can reach your HA "online", which controls all your devices locally via localtuya. (btw this should be the generic design concept for everything you use in your smarthome ;) )
Note that if you are persistent enough you can implement all the functions in localtuya for almost every device via the info extracted from "tuya iot platform"

Regarding README - see answer 1, (not required, but makes your life significantly easier)

Note: if anything "wakes up" Tuya Cloud (like opening the TuyaApp or triggering a schedule or anything. literally anything), then it will break localtuya for sure. best is not letting the devices communicate outside once configured completely.

[JohnMcLear]

@yeowan I think we can all agree that is an awful user experience and detrimental to the uptake of HA/LocalTuya to expect users to go through this journey. LocalTuya is fundamentally broken if we think this is an acceptable UX. I appreciate your effort though, you clarified a lot and presented an option for people who are okay with a shoddy UX.

[kernowkoi]

Been stumbling over this issue for last couple of weeks. Gave up and used official Tuya HA integration. Which as a Newbie to HA is good enough for now. But will look at this again sometime

[guyoliver]

Hi, I'm new to the HA and the localTuya. I thought that the HA would resolve the issues with the Tuya App (cloud), but I saw that after the device got "reset" (long press or such), the localTuya not recognize it.
I've played with the python and I think I managed to fix a workaround (I think the solution shall come from the state machine).
You can find the changes here (link). please try it and share your feedback. if it works I will suggest it to the maintainer after I do some "code cleanup".
thanks

[jdukat]

I've found this thread and went through all the hints on checking keys etc, but ultimately what worked was shutting down the Tuya smartphone app + disabling the background data usage + closing the Tuya cloud website + restart HA. Unavailable devices suddenly all worked. I had no need to downgrade the LocalTuya integration in HACS.

[JohnMcLear]

My solution was to flash all of my Tuya devices using tuya-cloudcutter and move everything over to ESPHome.

https://github.com/tuya-cloudcutter/tuya-cloudcutter

[jdukat]

Yep, looks like the right direction. After my above post last week, I already lost connection to my Tuya wifi device from HA and the only solution that helped was a full reboot of HA + manual refresh of LocalTuya settings. Completely unreliable.

[guyoliver]

You can see my changes in this link (I will update a few more changes I've made for stability).
Those are working for me: #1117 (comment)

[jdukat]

How to download the LocalTuya extension with your changes into HA?

[guyoliver]

I need to check, no idea, maybe someone knows.

[codyrally]

Thank you! I closed the Tuya smart app on my phone (swiped back twice to exit) and all my Tuya devices came back to life within a minute on homeassistant!
Otherwise I would have been chasing my tail reinstalling cr@p all over the place, saved me hours!

[nzrutman]

I just tried the 5.2.1 update after sticking with 4.0.2 for almost 2 years, and it seems to be working fine. Time to close this ticket?

[RayLation]

Everything has been very stable for a long while here. I used to have lots of problems of devices going unavailable intermittengly, but I can't remember the last time it happened now. Thanks !

[jdukat]

It's happening randomly. My setup has been stable for months, and just last week suddenly lost access to devices. They stopped reporting any properties. Needed to re-register the devices and do several reboots. Finally, I'm not really sure what has helped. It's crazy. In my new house, I'm going to stay away from Tuya's Wifi devices for good.

[Coss0475]

I have latest HA and latest local tuya and it is happening randomly for me. I restart and the devices are back online.

[tunix]

I have Piranha lightbulbs attached to my desktop lamp. I just integrated it with HA and although it works fine and fast for some time, it becomes unavailable within a few hours of no use. I have to restart things to make it available back again. This is kind of the same with both Tuya and Local Tuya integrations. Honestly not sure about using other tuya integrations. Maybe I should not use tuya devices at all? 😞

[cataseven]

I have the same problem and it happens only with tuya devices. They are from different manufacturers so I could have maybe blame a HA server or a router, but other smart devices connected to the same wi-fi work perfectly fine. Don't know what can be the reason.

just delete official smart life app from all of your devices. this app is working on the background and query your devices. Or restrict app to not to run in background

Just do this guys