fotis3d commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 scan to 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 key and save.

Your device is now alive!

1116

rchovan commented 1 year ago

@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 commented 1 year ago

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 scan to 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 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 commented 1 year ago

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

tefracky commented 1 year ago

@fotis3d Is it working with a prior version?

fotis3d commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

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

cloudbr34k84 commented 1 year ago

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 commented 1 year ago

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

tefracky commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

bobloadmire commented 1 year ago

Any movement on this? Whole setup is fucked

fotis3d commented 1 year ago

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

Booza1981 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

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.

reidcooper commented 1 year ago

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

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.

reidcooper commented 1 year ago

Here is a different error I am now seeing:

2022-11-27 18:46:37.131 ERROR (MainThread) [custom_components.localtuya.pytuya] [004...592] Failed to get status: 'NoneType' object has no attribute 'write'
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 485, in exchange
    self.transport.write(payload)
AttributeError: 'NoneType' object has no attribute 'write'
2022-11-27 18:46:37.133 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved
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 485, in exchange
    self.transport.write(payload)
AttributeError: 'NoneType' object has no attribute 'write'

schumissimo63 commented 1 year ago

Hello everyone, I also have this problem of disconnection, I am under version 4.1 and I would like to upgrade to 4.0.2, I copy the localtuya folder, version 4.0.2 in custom_component, I restart and I am still in 4.1. Do you have a procedure to share with me, please? Thanking you in advance ;)

My config: Home Assistant 2022.11.4 Supervisor 2022.11.2 Interface utilisateur : 20221108.0 - latest

javellino commented 1 year ago

I use HACS and was able to ‘upgrade’ from 4.1.1 back down to 4.0.2. Suffice it to say it did not solve my issues. I bet it’s just a configuration issue with the bulbs that is locking them up causing them to go off network.

On Mon, Nov 28, 2022 at 8:39 AM schumissimo63 @.***> wrote:

Hello everyone, I also have this problem of disconnection, I am under version 4.1 and I would like to upgrade to 4.0.2, I copy the localtuya folder, version 4.0.2 in custom_component, I restart and I am still in 4.1. Do you have a procedure to share with me, please? Thanking you in advance ;)

My config: Home Assistant 2022.11.4 Supervisor 2022.11.2 Interface utilisateur : 20221108.0 - latest

— Reply to this email directly, view it on GitHub https://github.com/rospogrigio/localtuya/issues/1117#issuecomment-1329108490, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHDACVS5CV3U2W63URM7K4TWKSY2NANCNFSM6AAAAAARZ6H4BA . You are receiving this because you commented.Message ID: @.***>

fotis3d commented 1 year ago

@schumissimo63 use HACS --> Localtuya --> Download again --> Version 4.0.2

Fannangir commented 1 year ago

Exactly the same here, since 4.1.0, devices become unavailable until HA or the integration is reloaded. Downgrade to 4.0.2 solves the issue.

rnodern commented 1 year ago

Noob question sorry, is the only way to downgrade to 4.0.2 -> pulling it out of github and pushing it to the install directory?

reidcooper commented 1 year ago

Noob question sorry, is the only way to downgrade to 4.0.2 -> pulling it out of github and pushing it to the install directory?

@rnodern you can select which version you want to install by navigating to the integration in HACS and select "Redownload". Chose which version you want.

fotis3d commented 1 year ago

Noob question sorry, is the only way to downgrade to 4.0.2 -> pulling it out of github and pushing it to the install directory?

This is easier for you? As @reidcooper said just click download again select version and you are done

Anycubic commented 1 year ago

I'm using @leeyuentuen fork with Zigbee support. His latest 3.6.1 has got same issue (only restarting HA is working for me), downgraded to 3.5.1 and so far so good. It would be nice to understand where the problem is because it seems this issue pop up and disappear time to time and with different releases.

leeyuentuen commented 1 year ago

@Anycubic it would be nice if there is an issue opened on the branch with some logs, maybe I can check out how it comes that the device becomes unavailable. Maybe there was somewhere a crash due to incorrect data parsing The changes from 3.5.1 and 3.6.1 are not really big changes. https://github.com/leeyuentuen/localtuya/compare/v3.5.1...leeyuentuen:localtuya:v3.6.1

Anycubic commented 1 year ago

@Anycubic it would be nice if there is an issue opened on the branch with some logs, maybe I can check out how it comes that the device becomes unavailable. Maybe there was somewhere a crash due to incorrect data parsing The changes from 3.5.1 and 3.6.1 are not really big changes. leeyuentuen/localtuya@v3.5.1...leeyuentuen:localtuya:v3.6.1

@leeyuentuen I wanted to open an issue in your fork but the "issue" tab seems missing. Maybe I'm doing something wrong but I'm not able to see it. I'm more than happy to help you in sorting this out, thanks!

leeyuentuen commented 1 year ago

@Anycubic it would be nice if there is an issue opened on the branch with some logs, maybe I can check out how it comes that the device becomes unavailable. Maybe there was somewhere a crash due to incorrect data parsing The changes from 3.5.1 and 3.6.1 are not really big changes. leeyuentuen/localtuya@v3.5.1...leeyuentuen:localtuya:v3.6.1

@leeyuentuen I wanted to open an issue in your fork but the "issue" tab seems missing. Maybe I'm doing something wrong but I'm not able to see it. I'm more than happy to help you in sorting this out, thanks!

I've add the issue tab.

Anycubic commented 1 year ago

@leeyuentuen ok, I downloaded again 3.6.1 and now waiting for the bug. Actually 3.5.3 was the version working fine

Anycubic commented 1 year ago

@leeyuentuen I opened the issue in your branch and added a log, hope this can help you in solving this problem.

carlosCastro99 commented 1 year ago

Hi all,

I has this issue before but with the rollback to 4.0.2 it was solved, however now, since a few days back, it's also happening in that version.

Strangely it happens every day around 7pm. Somehow I feel this may be related with internet issues, is there a way to monitor Internet connection breaks? Yes it's localtuya but it breaks if o lose internet.

LuigiPapino commented 1 year ago

I did solve moving the wifi router closer. I did notice the connection wasn't great, and if it drops even for one second, it seems to never recover, while the official app does recover.

With a better connection, it's solid, no unavailability anymore for me.

On Fri, 30 Dec 2022 at 02:13, carlosCastro99 @.***> wrote:

Hi all,

I has this issue before but with the rollback to 4.0.2 it was solved, however now, since a few days back, it's also happening in that version.

Strangely it happens every day around 7pm. Somehow I feel this may be related with internet issues, is there a way to monitor Internet connection breaks? Yes it's localtuya but it breaks if o lose internet.

— Reply to this email directly, view it on GitHub https://github.com/rospogrigio/localtuya/issues/1117#issuecomment-1367686425, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADCGPCSBMF2J4CNBB3OK6TWPZANPANCNFSM6AAAAAARZ6H4BA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

leeyuentuen commented 1 year ago

if it is related to the Zigbee gateway, When the gateway is offline and they are trying to fetch the DPS, It will crash and it will never get up anymore. It same as what happened here: https://github.com/leeyuentuen/localtuya/issues/23 but it should be solved for the lights (in beta release). If there is still an issue, you can open an issue with logs files, I can check if I can catch the issue without crashing localtuya

LuigiPapino commented 1 year ago

For me, all wifi 2.4ghz.

On Sat, 31 Dec 2022 at 23:21, Tuen Lee @.***> wrote:

if it is related to the Zigbee gateway, When the gateway is offline and they are trying to fetch the DPS, It will crash and it will never get up anymore. Same what happened here: leeyuentuen#23 https://github.com/leeyuentuen/localtuya/issues/23 but it should be solved for the lights. If there is still issue, you can open an issue with logs files, I can check if I can catch the issue without crash localtuya

— Reply to this email directly, view it on GitHub https://github.com/rospogrigio/localtuya/issues/1117#issuecomment-1368293018, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADCGPDGFVBDJBZQO53VIWDWQC5WJANCNFSM6AAAAAARZ6H4BA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

CodyJon commented 1 year ago

Any progress on this? I have automations setup to reload on entity state going "unavailable" but this is merely a band aid. Does there need to be more logging and troubleshooting? All my devices are on 2.4ghz and are receiving strong signals. I am thinking it might have something to do with internet dropout temporarily? as I have scheduled reboots on my network, but these do not coincide with the frequent dropouts when network is stable.

bobloadmire commented 1 year ago

Any progress on this? I have automations setup to reload on entity state going "unavailable" but this is merely a band aid. Does there need to be more logging and troubleshooting? All my devices are on 2.4ghz and are receiving strong signals. I am thinking it might have something to do with internet dropout temporarily? as I have scheduled reboots on my network, but these do not coincide with the frequent dropouts when network is stable.

I think this integration may have been abandoned, this has been a major issue for a couple of months and I don't think I've seen anyone trying to fix it.

rospogrigio / localtuya

Devices become unavailable #1117

Environment

1116

1116