-
Notifications
You must be signed in to change notification settings - Fork 456
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Last update don't solve my problem with HA 2024.5.0 stops the integration #1871
Comments
There are reports that HA 2024.5 has broken Matter and Zigbee integrations also. At this point there is nothing further I can do, as I am away from home and unable to test for myself on the new version. Probably I will stop trying to keep up with HA's rapid churn of integration APIs and find something more productive to do with my time, as they have been quite hostile towards suggestions and even pull requests to make simple changes that reduce the load on custom integration authors. |
Ok I understand your point of view. Thank you for your job any way |
For my use I will downgrade HA to keep you addon working that is must important for me because tuya don't expect to include my device category to them ha integration |
Revert previous ineffective workaround, instead opt out of importing on executor. The original issue seems to have been caused by changes in HA 2024.4 to initialise integrations on an executor thread instead of in the event loop. So when the receive thread is created, it is not being created from the event loop, and later gets killed along with the startup cleanup (which we previously carefully avoided). Opt out of this change for now until it is clearer how to adapt to the new HA architecture changes. Issue #1871, #1872
"tuya_local", "version": "2024.5.0" tompd_63lw_breaker :-(
|
Released 2024.5.1 with another attempt at fixing this |
After updated to 2024.5.1 I got another issue as below. Please help to fix it. Thank you so much. Logger: homeassistant Error doing job: Future exception was never retrieved |
After the update, all devices (wifi, Bluetooth subdevices) became unavailable. I had to click "Reload" for each device. In the logs, there was only this:
After each reboot of the HA server, each of the devices needs to be manually restarted. |
Just installed latest HA and Tuya-Local versions. I have the same problem @almirus has. |
2024.5.1:
|
same problem:
|
Same problem here, however, I went into my back ups and reverted to the earlier version of CORE. Everything seems to be working as normal. A temp fix until code professionals are able to address... |
Hello, samedi for me, problem temporary solved by downgrade to HA to
2024.4.4
Best regards
Philippe
Le jeu. 2 mai 2024, 15:42, Anj-0110 ***@***.***> a écrit :
… Same problem here, however, I went into my back ups and reverted to the
earlier version of CORE. Everything seems to be working as normal. A temp
fix until code professionals are able to address...
—
Reply to this email directly, view it on GitHub
<#1871 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BICBUQEHHJNOD52RHTDBROTZAI7CXAVCNFSM6AAAAABHCZOWL6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJQGUZTEOJZGA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Restoring functionality for HA 2024.5.0:
|
Yes I did that but after reboot HA, integration not working, we have to
deactivate and reactivate all devices at each HA rebooting
Le jeu. 2 mai 2024, 15:46, garry0garry ***@***.***> a écrit :
… Restoring functionality for HA 2024.5.0:
1. Update the integration.
2. Reboot the HA.
3. Reload the integration.
—
Reply to this email directly, view it on GitHub
<#1871 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BICBUQEYGKNO3X2IS7A2JYLZAI7VBAVCNFSM6AAAAABHCZOWL6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJQGU2DIMZVG4>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Hey @make-all Firstly thank you for all the time you spend on this project. I have opened a pull request that resolved the issues with HA 2024.5.0 in my environment. #1874 Hopefully this will fix other issues but I'm not able to test the other devices. Any one can test these fixes using my fork and updating to the beta version 2024.5.2-1 |
Hey @craibo . I just had a look at your PR, but you still have "import_executor": false in the manifest, so it's still using the workaround from https://developers.home-assistant.io/blog/2024/03/09/import_executor_default/. Have you had a chance to test the fix without import_executor:false as I guess that's the "does it work properly with 2024.5. I'll give it a try tomorrow if no-one else is able (but I've downgraded to 2024.4 atm so can't test it) |
If someone can tell me what the fix without the manifest change is I would be happy to test. I'm on 2024.5.0 and things are working fine, aside from having to reload the integration upon boot. But I only have 1 device in there (the others are in local tuya) so it's a pretty easy and painless test for me. |
Just removing that line from manifest JSON should be enough to check. It seems I misidentified the cause of HA no longer starting the coroutines from the event loop there, as that manifest entry did not seem to make a difference. |
So do I push the changes from your repo or from @craibo and modify the manifest? |
If you want to test craibo's changes, then pull from his repo, and remove that line from the manifest. |
For the time being, a workaround is an automation like this: alias: ++ Temporary workaround - reload tuya local devices after HA restarts
description: ""
trigger:
- platform: homeassistant
event: start
condition: []
action:
- delay:
hours: 0
minutes: 0
seconds: 10
milliseconds: 0
- service: homeassistant.reload_config_entry
target:
device_id:
- xxxx1
- xxxx2
...
- xxxxn
mode: single Pick the devices to reload by switching editing of that automation from yaml to visual editor mode. |
Hey @peteS-UK I've update my PR #1876 and removed the There is an updated beta release on my fork for this 2024.5.2-2 which you can use to test with. I can confirm this is working on my instance with HA Core 2024.5.0 |
Thanks @craibo . Yes, I can confirm that your 2024.5.2 changes fix the problem on HA 2024.5.0. I just updated my extension to 2024.5.2 whilst running 2024.4, rebooted, updated HA to 2024.5.0, rebooted, restarted the VM (since 2024.5 doesn't seem to start properly otherwise) and now everything is working fine with no error messages. Not much testing yet, but all of my devices are online and seem to be working fine. |
Just tried this, it's working on 2024.5.0, no start up errors either. Thank you very much to you both! @craibo @peteS-UK |
Will this effort be merged in your repo @make-all ? It would be awesome. |
I'm sure Jason will take a look at this when he gets a chance to test it himself etc., but as he said a few comments ago, he's away at the moment so patience is a virtue ;-) If you need it now, it's only 2 mins work to change it yourself. |
The latest update appears to keep some instability for now so I've downgraded back to 2024.4, looking forward to the patch |
Hi @Krispkiwi . Which update do you mean, 2024.5.1, or the 2024.5.2 beta? What instability are you seeing? |
I've been using 2024.5.1, noticing my devices are dropping to unavailable and need to be reloaded to re-establish the connection all the time. |
Yep. Have a read back in the thread. 2024.5.1 doesn't fix the problem, but the 2024.5.2 beta seems to fix it. |
I apologize, but I didn't understand much (I'm a newbie). Even if temporarily, may I know what file needs to be modified and what change needs to be made to resolve the problem? Thank you |
I modified the manifest and device.py files with the changes from @craibo's fork. Rebooted and now my devices show up as available on a reboot. @Aironside if you're a newbie you may want to just stick with the automation idea from a few comments up to reload the integration on HA startup that @maxosprojects commented. |
@broyuken I will follow your advice, thanks. |
async_actually_start was originally written to execute in the event loop. Since HA was modified to automatically run non-decorated coroutines in the executor thread, this has been running in the wrong thread, making some of its calls non-thread safe. - Revert previous fix for #1871, #1872 (PR #1876), as it is not needed when actually_start is running in the event loop, and has a side effect of causing #1888 (a separate fix for that has been proposed on the issue, but this revert also avoids that issue). Issue #1917
Hello, HA 2024.5 stops the integration from receiving updates unless I deactivate all my devices and activate them again one by one each time HA restart.
My devices are
Best regards
Philippe
The text was updated successfully, but these errors were encountered: