Getting Fatal Error after update to V 4.1.0 #1017
Comments
|
That error message is strange as sem is not a TuyaMessage. Have you tried restarting? |
|
the same here after upgrade |
After 3 restarts the error disappeared, after that I not did try to restart anymore 🙃 |
|
I can't restart as you can see my log |
|
@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:
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 |
|
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 Error doing job: Fatal error: protocol.data_received() call failed. |
Not the first time a specific
|
|
Looks like each listener is supposed to be used only once, but I cannot see why |
|
The only explanation I could come up with is that more than one The code doesn't seem to be prepared for such a scenario, but the question is: why is @smarthomefamilyverrips Is there anything else in the log prior to the error you posted? In particular, is there any exception which says |
sure, but in my 227 line is:
config is here since 1 yr without any modifications. After upgrade it crashes. |
|
@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. |
|
@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 |
|
"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 |
|
Still are getting same fatal error message, I will post all errors I get at restart in order of how they are logged This error originated from a custom integration. Logger: custom_components.localtuya.common [132...26f] Connect to 192.168.0.10 failed This error originated from a custom integration. Logger: homeassistant Error doing job: Fatal error: protocol.data_received() call failed. This error originated from a custom integration. Logger: custom_components.localtuya.common [482...4a3] Not connected to device Roof Light Local This error originated from a custom integration. Logger: custom_components.localtuya.common [bf5...sbd] Failed to set DP 1 to False During handling of the above exception, another exception occurred: Traceback (most recent call last): The above exception was the direct cause of the following exception: Traceback (most recent call last): |
|
And these 2 logs I got this morning after HA update. This error originated from a custom integration. Logger: homeassistant Error doing job: Fatal error: protocol.data_received() call failed. This error originated from a custom integration. Logger: custom_components.localtuya.common [482...4a3] Connect to 192.168.0.41 failed During handling of the above exception, another exception occurred: Traceback (most recent call last): |
|
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:
I've seen this occur when localtuya loses connection to the device during that connection routine. |
|
I keep getting the errors at restart This error originated from a custom integration. Logger: homeassistant Error doing job: Fatal error: protocol.data_received() call failed. AND This error originated from a custom integration. Logger: custom_components.localtuya.common [132...1c3] Connect to 192.168.0.3 failed During handling of the above exception, another exception occurred: Traceback (most recent call last): |
|
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 [482...4a3] Not connected to device Roof Light Local |
|
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 [132...231] Connect to 192.168.0.36 failed During handling of the above exception, another exception occurred: Traceback (most recent call last): The above exception was the direct cause of the following exception: Traceback (most recent call last): During handling of the above exception, another exception occurred: Traceback (most recent call last): |
|
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. |
|
Yep - it ends up being the same. That fork just captures the changes that are going into #1022. |
@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 |
|
Still getting same fatal error at restart after update to V 4.1.0 This error originated from a custom integration. Logger: homeassistant Error doing job: Fatal error: protocol.data_received() call failed. |
|
@smarthomefamilyverrips - Few questions on the above:
|
|
|
Still getting the fatal error :( This error originated from a custom integration. Logger: homeassistant Error doing job: Fatal error: protocol.data_received() call failed. |
|
Hi @s
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. |
|
@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? |
|
@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) |
@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 |
|
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 |
|
@lloydw - So something like: Or skip the whole message: ? Any ideas as to why would we get back two RESET responses? |
|
@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. |
|
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 |
|
@lloydw and @sibowler after updating to V4.1.1 I still get the fatal error message. Logger: homeassistant Error doing job: Fatal error: protocol.data_received() call failed. |
|
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 |
|
@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 |
|
@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
|
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. |
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 |
|
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. |
The problem
Environment
Steps to reproduce
Configuration
configuration.yamlorconfig_flowDP 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_ready__data_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'
The text was updated successfully, but these errors were encountered: