search

rospogrigio / localtuya

local handling for Tuya devices
GNU General Public License v3.0
2.84k stars 546 forks source link

Getting Fatal Error after update to V 4.1.0 #1017

Open smarthomefamilyverrips opened 2 years ago

smarthomefamilyverrips commented 2 years ago

The problem

Environment

Steps to reproduce

1.

Configuration configuration.yaml or config_flow

DP dump

Provide Home Assistant taceback/logs

Additional information

After update to V 4.1.0 I get the folowing fatal error message:

This error originated from a custom integration.

Logger: homeassistant Source: custom_components/localtuya/pytuya/init.py:307 Integration: LocalTuya (documentation, issues) First occurred: 19:20:27 (1 occurrences) Last logged: 19:20:27

Error doing job: Fatal error: protocol.data_received() call failed. Traceback (most recent call last): File "/usr/local/lib/python3.10/asyncio/selector_events.py", line 868, in _read_readydata_received self._protocol.data_received(data) File "/config/custom_components/localtuya/pytuya/init.py", line 437, in data_received self.dispatcher.add_data(data) File "/config/custom_components/localtuya/pytuya/init.py", line 298, in add_data self._dispatch(TuyaMessage(seqno, cmd, retcode, payload, crc)) File "/config/custom_components/localtuya/pytuya/init__.py", line 307, in _dispatch sem.release() AttributeError: 'TuyaMessage' object has no attribute 'release'

sibowler commented 2 years ago

That error message is strange as sem is not a TuyaMessage. Have you tried restarting?

wojtulab commented 2 years ago

the same here after upgrade 

`Logger: homeassistant.components.websocket_api.http.connection
Source: components/homeassistant/__init__.py:174
Integration: Home Assistant WebSocket API (documentation, issues)
First occurred: 8:14:21 PM (3 occurrences)
Last logged: 8:14:40 PM

[140119886781824] The system cannot restart because the configuration is not valid: Invalid config for [localtuya]: extra keys not allowed @ data['localtuya'][0]['entities'][0]['current']. Got 18 extra keys not allowed @ data['localtuya'][0]['entities'][0]['current_consumption']. Got 19 extra keys not allowed @ data['localtuya'][0]['entities'][0]['voltage']. Got 20 value must be one of ['binary_sensor'] for dictionary value @ data['localtuya'][0]['entities'][0]['platform']. Got 'switch'. (See /config/configuration.yaml, line 227).
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 199, in handle_call_service
    await hass.services.async_call(
  File "/usr/src/homeassistant/homeassistant/core.py", line 1713, in async_call
    task.result()
  File "/usr/src/homeassistant/homeassistant/core.py", line 1750, in _execute_service
    await cast(Callable[[ServiceCall], Awaitable[None]], handler.job.target)(
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 746, in admin_handler
    await result
  File "/usr/src/homeassistant/homeassistant/components/homeassistant/__init__.py", line 174, in async_handle_core_service
    raise HomeAssistantError(
homeassistant.exceptions.HomeAssistantError: The system cannot restart because the configuration is not valid: Invalid config for [localtuya]: extra keys not allowed @ data['localtuya'][0]['entities'][0]['current']. Got 18
extra keys not allowed @ data['localtuya'][0]['entities'][0]['current_consumption']. Got 19
extra keys not allowed @ data['localtuya'][0]['entities'][0]['voltage']. Got 20
value must be one of ['binary_sensor'] for dictionary value @ data['localtuya'][0]['entities'][0]['platform']. Got 'switch'. (See /config/configuration.yaml, line 227). 
`
smarthomefamilyverrips commented 2 years ago

That error message is strange as sem is not a TuyaMessage. Have you tried restarting?

After 3 restarts the error disappeared, after that I not did try to restart anymore 🙃

wojtulab commented 2 years ago

I can't restart as you can see my log

sibowler commented 2 years ago

@wojtulab - Your error seems different to @smarthomefamilyverrips one. If i had to guess it could be potentially due to using yaml configuration to setup localtuya as per the error:

(See /config/configuration.yaml, line 227).

AFAIK configuring via yaml was dropped a couple of versions ago.

smarthomefamilyverrips commented 2 years ago

@wojtulab - Your error seems different to @smarthomefamilyverrips one. If i had to guess it could be potentially due to using yaml configuration to setup localtuya as per the error:

(See /config/configuration.yaml, line 227).

AFAIK configuring via yaml was dropped a couple of versions ago.

I not have anything in my configuration.yaml regarding localtuya and my configuration.yaml ends at line 154, so line 227 not even exists.... so I not think the problem lies there

smarthomefamilyverrips commented 2 years ago

I just did restart the system after 2022.9 update and I get the same fatal error again

This error originated from a custom integration.

Logger: homeassistant Source: custom_components/localtuya/pytuya/init.py:307 Integration: LocalTuya (documentation, issues) First occurred: 22:58:16 (1 occurrences) Last logged: 22:58:16

Error doing job: Fatal error: protocol.data_received() call failed. Traceback (most recent call last): File "/usr/local/lib/python3.10/asyncio/selector_events.py", line 868, in _read_readydata_received self._protocol.data_received(data) File "/config/custom_components/localtuya/pytuya/init.py", line 437, in data_received self.dispatcher.add_data(data) File "/config/custom_components/localtuya/pytuya/init.py", line 298, in add_data self._dispatch(TuyaMessage(seqno, cmd, retcode, payload, crc)) File "/config/custom_components/localtuya/pytuya/init__.py", line 307, in _dispatch sem.release() AttributeError: 'TuyaMessage' object has no attribute 'release'

swiergot commented 2 years ago

That error message is strange as sem is not a TuyaMessage.

Not the first time a specific seqno is received, but the second time?

sem = self.listeners[msg.seqno]
self.listeners[msg.seqno] = msg
sem.release()

TuyaMessage replaces the listener so the next time the same seqno comes, it actually seems to be TuyaMessage.

swiergot commented 2 years ago

Looks like each listener is supposed to be used only once, but I cannot see why wait_for() would not remove it from self.listeners after use.

swiergot commented 2 years ago

The only explanation I could come up with is that more than one MessageDispatcher._dispatch() is executed for a particular seqno at the same time. The first call has already replaced the semaphore with TuyaMessage and while the seqno is still in self.listeners, the second call kicks in and calls release() on TuyaMessage.

The code doesn't seem to be prepared for such a scenario, but the question is: why is _dispatch() executed twice? Either the reply for a request comes twice or another request of the same kind takes place at the same time.

@smarthomefamilyverrips Is there anything else in the log prior to the error you posted? In particular, is there any exception which says listener exists for?

wojtulab commented 2 years ago

@wojtulab - Your error seems different to @smarthomefamilyverrips one. If i had to guess it could be potentially due to using yaml configuration to setup localtuya as per the error:

(See /config/configuration.yaml, line 227).

AFAIK configuring via yaml was dropped a couple of versions ago.

I not have anything in my configuration.yaml regarding localtuya and my configuration.yaml ends at line 154, so line 227 not even exists.... so I not think the problem lies there

sure, but in my 227 line is: localtuya:

config is here since 1 yr without any modifications. After upgrade it crashes.

#TUYA
localtuya:
   - host: 192.168.1.28
     device_id: XXXXXXXXXXXXXX
     local_key: XXXXXXXXXXXX
     friendly_name: klima sypialnia
     protocol_version: "3.3"
     entities:
       - platform: switch
         friendly_name: klima_sypialnia
         id: 1
         current: 18 # Optional
         current_consumption: 19 # Optional
         voltage: 20 # Optional
       - platform: binary_sensor
         friendly_name: klima_sypialnia
         id: 1
         device_class: power
         state_on: "true" # Optional
         state_off: "false" # Optional
       - platform: sensor
         friendly_name: Plug Voltage
         id: 20
         scaling: 0.1 # Optional
         device_class: voltage # Optional
         unit_of_measurement: "V" # Optional
       - platform: sensor
         friendly_name: Current
         id: 18
         scaling: 0.1 # Optional
         device_class: current # Optional
         unit_of_measurement: "mA" # Optional
       - platform: sensor
         friendly_name: Power
         id: 19
         scaling: 0.1 # Optional
         device_class: power # Optional
         unit_of_measurement: "W"

`

sibowler commented 2 years ago

@wojtulab - unfortunately i think that is the problem in your situation. V4.0.0 removed support (14 Jun) for configuring localtuya by YAML. So if you've not upgraded to a 4.x version until now, that is probably the cause for that error.

sibowler commented 2 years ago

@swiergot - Good investigation. I've not yet seen this error in my own setup. When I've got some time later I'll setup some debug points and see if I can replicate

smarthomefamilyverrips commented 2 years ago

"Is there anything else in the log prior to the error you posted? In particular, is there any exception which says listener exists for?"

@swiergot, no I did not see that there is any error of that kind

smarthomefamilyverrips commented 2 years ago

Still are getting same fatal error message, I will post all errors I get at restart in order of how they are logged

1. This error originated from a custom integration.

Logger: custom_components.localtuya.common Source: custom_components/localtuya/pytuya/init.py:704 Integration: LocalTuya (documentation, issues) First occurred: 03:49:24 (17 occurrences) Last logged: 03:49:26

[132...26f] Connect to 192.168.0.10 failed [132...173] Connect to 192.168.0.192 failed [132...04b] Connect to 192.168.0.12 failed [132...096] Connect to 192.168.0.2 failed [482...4a3] Connect to 192.168.0.41 failed Traceback (most recent call last): File "/config/custom_components/localtuya/common.py", line 185, in _make_connection self._interface = await pytuya.connect( File "/config/customcomponents/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}') ConnectionResetError: [Errno 104] Connect call failed ('192.168.0.13', 6668)

2. This error originated from a custom integration.

Logger: homeassistant Source: custom_components/localtuya/pytuya/init.py:307 Integration: LocalTuya (documentation, issues) First occurred: 03:49:27 (1 occurrences) Last logged: 03:49:27

Error doing job: Fatal error: protocol.data_received() call failed. Traceback (most recent call last): File "/usr/local/lib/python3.10/asyncio/selector_events.py", line 868, in _read_readydata_received self._protocol.data_received(data) File "/config/custom_components/localtuya/pytuya/init.py", line 437, in data_received self.dispatcher.add_data(data) File "/config/custom_components/localtuya/pytuya/init.py", line 298, in add_data self._dispatch(TuyaMessage(seqno, cmd, retcode, payload, crc)) File "/config/custom_components/localtuya/pytuya/init__.py", line 307, in _dispatch sem.release() AttributeError: 'TuyaMessage' object has no attribute 'release'

3. This error originated from a custom integration.

Logger: custom_components.localtuya.common Source: custom_components/localtuya/pytuya/init.py:154 Integration: LocalTuya (documentation, issues) First occurred: 03:49:27 (4 occurrences) Last logged: 03:49:28

[482...4a3] Not connected to device Roof Light Local [132...98d] Not connected to device Light Bathroom Ceiling Local [132...a65] Not connected to device Light Bedroom Kids One Local [132...ccb] Not connected to device Light Porch Local

4. This error originated from a custom integration.

Logger: custom_components.localtuya.common Source: custom_components/localtuya/pytuya/init.py:259 Integration: LocalTuya (documentation, issues) First occurred: 03:49:32 (3 occurrences) Last logged: 03:49:35

[bf5...sbd] Failed to set DP 1 to False [513...ca1] Failed to set DP 20 to False [513...ca1] Connect to 192.168.0.175 failed 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 316, in set_dp await self._interface.set_dp(state, dp_index) File "/config/custom_components/localtuya/pytuya/init.py", line 553, in set_dp return await self.exchange(SET, {str(dp_index): value}) 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

smarthomefamilyverrips commented 2 years ago

And these 2 logs I got this morning after HA update.

1. This error originated from a custom integration.

Logger: homeassistant Source: custom_components/localtuya/pytuya/init.py:307 Integration: LocalTuya (documentation, issues) First occurred: 09:25:11 (1 occurrences) Last logged: 09:25:11

Error doing job: Fatal error: protocol.data_received() call failed. Traceback (most recent call last): File "/usr/local/lib/python3.10/asyncio/selector_events.py", line 868, in _read_readydata_received self._protocol.data_received(data) File "/config/custom_components/localtuya/pytuya/init.py", line 437, in data_received self.dispatcher.add_data(data) File "/config/custom_components/localtuya/pytuya/init.py", line 298, in add_data self._dispatch(TuyaMessage(seqno, cmd, retcode, payload, crc)) File "/config/custom_components/localtuya/pytuya/init__.py", line 307, in _dispatch sem.release() AttributeError: 'TuyaMessage' object has no attribute 'release'

2. This error originated from a custom integration.

Logger: custom_components.localtuya.common Source: custom_components/localtuya/common.py:216 Integration: LocalTuya (documentation, issues) First occurred: 09:25:11 (1 occurrences) Last logged: 09:25:11

[482...4a3] Connect to 192.168.0.41 failed Traceback (most recent call last): File "/config/custom_components/localtuya/common.py", line 206, in _make_connection self._interface.start_heartbeat() AttributeError: 'NoneType' object has no attribute 'start_heartbeat'

During handling of the above exception, another exception occurred:

Traceback (most recent call last): File "/config/custom_components/localtuya/common.py", line 216, in _make_connection await self._interface.reset(self._default_reset_dpids) AttributeError: 'NoneType' object has no attribute 'reset'

sibowler commented 2 years ago

I ran the update, and also ran a search on my logs for the "AttributeError: 'TuyaMessage' object has no attribute 'release'" error and I've not observed it over the last 14 days of logs...

I've seen this error before though:

AttributeError: 'NoneType' object has no attribute 'start_heartbeat'

I've seen this occur when localtuya loses connection to the device during that connection routine.

smarthomefamilyverrips commented 2 years ago

I keep getting the errors at restart

This error originated from a custom integration.

Logger: homeassistant Source: custom_components/localtuya/pytuya/init.py:307 Integration: LocalTuya (documentation, issues) First occurred: 13:08:28 (1 occurrences) Last logged: 13:08:28

Error doing job: Fatal error: protocol.data_received() call failed. Traceback (most recent call last): File "/usr/local/lib/python3.10/asyncio/selector_events.py", line 868, in _read_readydata_received self._protocol.data_received(data) File "/config/custom_components/localtuya/pytuya/init.py", line 437, in data_received self.dispatcher.add_data(data) File "/config/custom_components/localtuya/pytuya/init.py", line 298, in add_data self._dispatch(TuyaMessage(seqno, cmd, retcode, payload, crc)) File "/config/custom_components/localtuya/pytuya/init__.py", line 307, in _dispatch sem.release() AttributeError: 'TuyaMessage' object has no attribute 'release'

AND

This error originated from a custom integration.

Logger: custom_components.localtuya.common Source: custom_components/localtuya/common.py:216 Integration: LocalTuya (documentation, issues) First occurred: 13:08:28 (1 occurrences) Last logged: 13:08:28

[132...1c3] Connect to 192.168.0.3 failed Traceback (most recent call last): File "/config/custom_components/localtuya/common.py", line 206, in _make_connection self._interface.start_heartbeat() AttributeError: 'NoneType' object has no attribute 'start_heartbeat'

During handling of the above exception, another exception occurred:

Traceback (most recent call last): File "/config/custom_components/localtuya/common.py", line 216, in _make_connection await self._interface.reset(self._default_reset_dpids) AttributeError: 'NoneType' object has no attribute 'reset'

smarthomefamilyverrips commented 2 years ago

And it seems to not be able to connect to my switches while these are available in the app

This error originated from a custom integration.

Logger: custom_components.localtuya.common Source: custom_components/localtuya/pytuya/init.py:154 Integration: LocalTuya (documentation, issues) First occurred: 13:08:25 (3 occurrences) Last logged: 13:08:25

[482...4a3] Not connected to device Roof Light Local [bf5...sbd] Not connected to device Garden Light Local [482...5c6] Not connected to device Doorbell Switch Local

smarthomefamilyverrips commented 2 years ago

A other thing I notice is since the last update 4.1.0 I get a lot of connection errors in my log while I not have this problems in the tuya app

This error originated from a custom integration.

Logger: custom_components.localtuya.common Source: custom_components/localtuya/common.py:216 Integration: LocalTuya (documentation, issues) First occurred: 18:08:36 (1 occurrences) Last logged: 18:08:36

[132...231] Connect to 192.168.0.36 failed 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 202, in _make_connection status = await self._interface.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

During handling of the above exception, another exception occurred:

Traceback (most recent call last): File "/config/custom_components/localtuya/common.py", line 216, in _make_connection await self._interface.reset(self._default_reset_dpids) AttributeError: 'NoneType' object has no attribute 'reset'

sibowler commented 2 years ago

I suspect that all these errors are caused by the way that localtuya currently handles a lost connection... IF you're seeing an increase of these errors since 4.1.0, then it could be caused by the reset functionality. It seems that this causes some devices to drop/reset themselves, which could potentially be leading to a dropped connection. Can you test the fix in PR #1022 and see if that has an impact on these errors?

In terms of making localtuya handle the dropping of connections more gracefully (at least from an error message point of view), that will need to be covered by a separate change as none of the changes in 4.1.0 impacted this logic.

smarthomefamilyverrips commented 2 years ago

@sibowler can I just use your forked version of localtuya, or you not implemented the changes of PR #1022 there?

sibowler commented 2 years ago

Yep - it ends up being the same. That fork just captures the changes that are going into #1022.

smarthomefamilyverrips commented 2 years ago

I suspect that all these errors are caused by the way that localtuya currently handles a lost connection... IF you're seeing an increase of these errors since 4.1.0, then it could be caused by the reset functionality. It seems that this causes some devices to drop/reset themselves, which could potentially be leading to a dropped connection. Can you test the fix in PR #1022 and see if that has an impact on these errors?

In terms of making localtuya handle the dropping of connections more gracefully (at least from an error message point of view), that will need to be covered by a separate change as none of the changes in 4.1.0 impacted this logic.

@sibowler for the moment your PR seems to have fixed my issues 👍

smarthomefamilyverrips commented 2 years ago

I suspect that all these errors are caused by the way that localtuya currently handles a lost connection... IF you're seeing an increase of these errors since 4.1.0, then it could be caused by the reset functionality. It seems that this causes some devices to drop/reset themselves, which could potentially be leading to a dropped connection. Can you test the fix in PR #1022 and see if that has an impact on these errors? In terms of making localtuya handle the dropping of connections more gracefully (at least from an error message point of view), that will need to be covered by a separate change as none of the changes in 4.1.0 impacted this logic.

@sibowler for the moment your PR seems to have fixed my issues 👍

@sibowler I did restore to the original localtuya, when I did use your PR fixes after a few hours several lights got unresponsive and I was not able to control them anymore in HA, it was like HA did think they where offline but I not got any error..... In the tuya app all lights worked fine and I was able to control them there

smarthomefamilyverrips commented 2 years ago

Still getting same fatal error at restart after update to V 4.1.0

This error originated from a custom integration.

Logger: homeassistant Source: custom_components/localtuya/pytuya/init.py:307 Integration: LocalTuya (documentation, issues) First occurred: 22:53:53 (1 occurrences) Last logged: 22:53:53

Error doing job: Fatal error: protocol.data_received() call failed. Traceback (most recent call last): File "/usr/local/lib/python3.10/asyncio/selector_events.py", line 868, in _read_readydata_received self._protocol.data_received(data) File "/config/custom_components/localtuya/pytuya/init.py", line 437, in data_received self.dispatcher.add_data(data) File "/config/custom_components/localtuya/pytuya/init.py", line 298, in add_data self._dispatch(TuyaMessage(seqno, cmd, retcode, payload, crc)) File "/config/custom_components/localtuya/pytuya/init__.py", line 307, in _dispatch sem.release() AttributeError: 'TuyaMessage' object has no attribute 'release'

sibowler commented 2 years ago

@smarthomefamilyverrips - Few questions on the above:

  1. When you installed my PR, did you take all the files in that fork as you were discussing doing?
  2. Were the lights working before the 4.1.0 release?
  3. Did you have the tuya app open at the same time as HA, or only opened the app when the lights went offline in HA?
smarthomefamilyverrips commented 2 years ago

@smarthomefamilyverrips - Few questions on the above:

  1. When you installed my PR, did you take all the files in that fork as you were discussing doing?
  2. Were the lights working before the 4.1.0 release?
  3. Did you have the tuya app open at the same time as HA, or only opened the app when the lights went offline in HA?

@sibowler

  1. Yes I did download your fork and copied all 6 files that you adjusted to my localtuya folder
  2. The lights did work also before v4.1.0 and now also work again after I did restore your adjusted files with the original files again
  3. I did only open the tuya app after I did observe that the lights were not working anymore in HA
smarthomefamilyverrips commented 1 year ago

Still getting the fatal error :(

This error originated from a custom integration.

Logger: homeassistant Source: custom_components/localtuya/pytuya/init.py:307 Integration: LocalTuya (documentation, issues) First occurred: 20:54:21 (1 occurrences) Last logged: 20:54:21

Error doing job: Fatal error: protocol.data_received() call failed. Traceback (most recent call last): File "/usr/local/lib/python3.10/asyncio/selector_events.py", line 868, in _read_readydata_received self._protocol.data_received(data) File "/config/custom_components/localtuya/pytuya/init.py", line 437, in data_received self.dispatcher.add_data(data) File "/config/custom_components/localtuya/pytuya/init.py", line 298, in add_data self._dispatch(TuyaMessage(seqno, cmd, retcode, payload, crc)) File "/config/custom_components/localtuya/pytuya/init__.py", line 307, in _dispatch sem.release() AttributeError: 'TuyaMessage' object has no attribute 'release'

sibowler commented 1 year ago

Hi @s

  • Yes I did download your fork and copied all 6 files that you adjusted to my localtuya folder

  • The lights did work also before v4.1.0 and now also work again after I did restore your adjusted files with the original files again

Hi @smarthomefamilyverrips - just to double confirm, you copied the modified files over a 4.1.0 installation? Apologies if it sounds like i'm asking the same question, but given you were talking about restoring original files, i wanted to check.

sibowler commented 1 year ago

@lloydw @elendilon - This could be related to the RESET code that was updated in 4.1.0 in the pytuya library... As the original authors, any ideas?

lloydw commented 1 year ago

@sibowler I guess this could happen if the message is a RESET_SEQNO, as the sem is released and the message just put back in the listeners at this point: https://github.com/rospogrigio/localtuya/pull/956/files#diff-c58efc005eae5c0b592c0038239d205f611a0433360112a6318e7c9343c047d0R317

If a second reset came back from the device, it would trigger this. It would likely be safe to put a guard in that _dispatch method to ignore the message if it has already been processed (no semaphore present in the listeners, just a msg)

smarthomefamilyverrips commented 1 year ago

Hi @s

  • Yes I did download your fork and copied all 6 files that you adjusted to my localtuya folder
  • The lights did work also before v4.1.0 and now also work again after I did restore your adjusted files with the original files again

Hi @smarthomefamilyverrips - just to double confirm, you copied the modified files over a 4.1.0 installation? Apologies if it sounds like i'm asking the same question, but given you were talking about restoring original files, i wanted to check.

@sibowler yes I copied and replaced the files to the localtuya folder of my already existing 4.1.0 version of localtuya that I am running

smarthomefamilyverrips commented 1 year ago

For the moment I did roll-back to V 4.0.2 as the fatal error message and the big increase in connection errors of devices with update V4.1.0 really started to bother me..... I not had/have any of these issues with V4.0.2 .... Hope this get solved so i can use future updates also again

sibowler commented 1 year ago

@lloydw - So something like: 

if isinstance(sem, asyncio.Semaphore):
                 sem.release()

Or skip the whole message:

if isinstance(sem, asyncio.Semaphore):
                self.listeners[msg.seqno] = msg
                sem.release()

?

Any ideas as to why would we get back two RESET responses?

sibowler commented 1 year ago

@lloydw - thinking about this more, I believe this error is still occurring after the path has been applied to disable the RESET functionality. So there shouldn't be any RESET messages being fired.

lloydw commented 1 year ago

If the path is disabled, then there shouldn’t be any listeners, which is odd. However getting two responses could be possible, the devices might incorrectly send two. This is a new message type we’re handling

smarthomefamilyverrips commented 1 year ago

@lloydw and @sibowler any news on this? I am still using the old version 4.0.2 as not want to get errors, but I would like to update to 4 1.0

besiktas97 commented 1 year ago

@lloydw and @sibowler any news on this? I am still using the old version 4.0.2 as not want to get errors, but I would like to update to 4 1.0

Same here, see lot of people having problems with the latest release of local tuya

smarthomefamilyverrips commented 1 year ago

@lloydw and @sibowler after updating to V4.1.1 I still get the fatal error message. This error originated from a custom integration.

Logger: homeassistant Source: custom_components/localtuya/pytuya/init.py:307 Integration: LocalTuya (documentation, issues) First occurred: 22:51:36 (1 occurrences) Last logged: 22:51:36

Error doing job: Fatal error: protocol.data_received() call failed. Traceback (most recent call last): File "/usr/local/lib/python3.10/asyncio/selector_events.py", line 868, in _read_readydata_received self._protocol.data_received(data) File "/config/custom_components/localtuya/pytuya/init.py", line 437, in data_received self.dispatcher.add_data(data) File "/config/custom_components/localtuya/pytuya/init.py", line 298, in add_data self._dispatch(TuyaMessage(seqno, cmd, retcode, payload, crc)) File "/config/custom_components/localtuya/pytuya/init__.py", line 307, in _dispatch sem.release() AttributeError: 'TuyaMessage' object has no attribute 'release'

lloydw commented 1 year ago

My advice is still to put a check for the semaphore type in the dict and ignore the e message if it’s not a semaphore. Unfortunately I don’t have a device that is exhibiting this behavior to test the fix.

smarthomefamilyverrips commented 1 year ago

My advice is still to put a check for the semaphore type in the dict and ignore the e message if it’s not a semaphore. Unfortunately I don’t have a device that is exhibiting this behavior to test the fix.

I have no problem with testing fixes, I only not know how to write them myself

smarthomefamilyverrips commented 1 year ago

@sibowler and @rospogrigio I did update to V4.1.1 that did include the PR fixes from @sibowler but again I have same as when I did apply the PR myself, like I told then also now my lights not react or react very slow on HA commands/controlls as well with manual actions as with automations

smarthomefamilyverrips commented 1 year ago

@sibowler and @rospogrigio I again did rollback to version 4.0.2, by looking a little further I did discover that many of my added devices became unavailable in HA for for a few seconds for about every 1-3 minutes. This is probably also the reason of slow or not reacting on HA commands/controls

Screenshot_20221014-082513_Home Assistant Screenshot_20221014-082553_Home Assistant

sibowler commented 1 year ago

My advice is still to put a check for the semaphore type in the dict and ignore the e message if it’s not a semaphore. Unfortunately I don’t have a device that is exhibiting this behavior to test the fix.

Yep, I was thinking the same thing, but including a logging line so that there's something to assist with debugging why it might be occurring. But like you, i've not observed this error on my system, so I'll be coding somewhat blind.

Will try and get a PR spun up to test this.

sibowler commented 1 year ago

@sibowler and @rospogrigio I again did rollback to version 4.0.2, by looking a little further I did discover that many of my added devices became unavailable in HA for for a few seconds for about every 1-3 minutes. This is probably also the reason of slow or not reacting on HA commands/controls

So, just to make sure I've understood it right - the above errors are on 4.0.2?

It might be unrelated, but i saw similar behaviour (i.e. going unavailable frequently) from one of my devices when it was at the limit of my Wifi network... I added a repeater and that fixed the issue.

smarthomefamilyverrips commented 1 year ago

@sibowler and @rospogrigio I again did rollback to version 4.0.2, by looking a little further I did discover that many of my added devices became unavailable in HA for for a few seconds for about every 1-3 minutes. This is probably also the reason of slow or not reacting on HA commands/controls

So, just to make sure I've understood it right - the above errors are on 4.0.2?

It might be unrelated, but i saw similar behaviour (i.e. going unavailable frequently) from one of my devices when it was at the limit of my Wifi network... I added a repeater and that fixed the issue.

I am now back on 4.0.2 and not have any issues now with slow or no response on commands and also not so often devices showing unavailable that frequently

sibowler commented 1 year ago

I've pushed a change to PR #1087 which should hopefully help handle this situation when it occurs. Anyone who is observing this error and would like to test is more than welcome to.