make-all
Segmentation Faults in Home Assistant Core When Tuya Devices Go Offline (e.g., Bulbs Lose Power)
Description
Hi @make-all and contributors, I'm experiencing segmentation faults in the Home Assistant (HA) core caused by the Tuya-Local integration when Tuya devices become offline (e.g., bulbs lose power). This happens consistently in setups with multiple devices (50+ bulbs), and the system is stable only when all devices are powered on. I've tried several modifications to device.py (timeouts, exponential backoff, locks on API calls, suspension for offline devices), but the crashes persist.
Thank you!
Steps to reproduce
1 Configure Tuya-Local with multiple bulbs/sensors in configuration.yaml (protocol 3.3). 2 Run HA normally. 3 Turn off power to one or more bulbs (simulate offline). 4 Wait ~hours; HA core crashes with segfault (check logs for Fatal Python error: Segmentation fault).
Expected behaviour
No response
Additional context
Environment • Home Assistant version: 2025.7.3 (or later; tested on 2025.7.x) • Tuya-Local version: 2025.7.1 • Python version: 3.13 • HA installation: Supervised in Proxmox VM (x86_64, sufficient RAM/CPU) • Devices: 30 Tuya bulbs (multiple models RGBW), motion sensors (ZY-M201-WIFI24G, ZY-M100-WIFI, category "hps") • Protocol: 3.X Symptoms • HA core crashes with segmentation fault after a Tuya device goes offline (e.g., bulb unplugged or power lost). • Threads hang in tinytuya.core.XenonDevice.receive (line 1010), leading to race conditions or memory corruption. • Stable for days if all devices are powered; crashes occur randomly when devices change (e.g., 1-3 offline, then 4-6). • Motion sensors have 5s delays in detection when using poll_only: true to mitigate crashes.
Logs/Fault Example Here's a recent fault log showing threads stuck in tinytuya: text
Fatal Python error: Segmentation fault
Thread 0x00007f4706bc6b30 (most recent call first): File "/usr/local/lib/python3.13/site-packages/tinytuya/core/XenonDevice.py", line 418 in _recv_all File "/usr/local/lib/python3.13/site-packages/tinytuya/core/XenonDevice.py", line 444 in _receive File "/usr/local/lib/python3.13/site-packages/tinytuya/core/XenonDevice.py", line 572 in _send_receive File "/usr/local/lib/python3.13/site-packages/tinytuya/core/XenonDevice.py", line 1010 in receive File "/usr/local/lib/python3.13/concurrent/futures/thread.py", line 59 in run File "/usr/local/lib/python3.13/concurrent/futures/thread.py", line 93 in _worker File "/usr/local/lib/python3.13/threading.py", line 992 in run File "/usr/local/lib/python3.13/threading.py", line 1041 in _bootstrap_inner File "/usr/local/lib/python3.13/threading.py", line 1012 in _bootstrap
(truncated; full log attached if needed)
Confirmation
-
[x] I am sure this is a bug or improvement, that is well enough described that it can be implemented.
-
[x] This report is for tuya-local, not for localtuya.
-
[ ] If this is for a specific device, the device config filename is mentioned above, or diagnostics are included.
-
[x] Log messages or diagnostics relevant to the issue are included.
-
[x] This is not requesting addition of a new device.
This seems more likely to be a bug in Python itself, or one of the system libraries. A segfault should not be directly possible from Python code.
Thank you for your quick response, @make-all. I agree that a segmentation fault points to a low-level issue, likely in Python 3.13's native extensions (e.g., socket handling in the standard library) or in tinytuya's C-based components (e.g., cipher or socket operations in XenonDevice). Since Python code itself can't directly cause segfaults without invoking native code, this could be a race condition or memory corruption triggered by concurrent socket operations under load, especially when devices go offline and receive() hangs indefinitely.
I have been having the same issue. I did some testing,. I am currently on version 2025.7.0 it is working perfectly, as per previous versions. When you turn a device off eg a light Home Assistant is spot on, you turn the device back on and within a few seconds it registers as online in tuya local.
I tried upgrading to 2025.7.1 and started experiencing the issue if a device is turned off it throws an error in HA, when you turn the device back on again it takes a long time for it to reconnect, if it does. Some times you have to reload the device to get it to register.
I then uninstalled the integration and reinstalled the 2025.7.0 and it works as expected. So it looks as if something changed n the behaviour between versions 2025.7.0 and 2025.7.1
I am running the latest version of home assistant 2025.9.0
That is not the same as the issue you are commenting on though. The issue is about a segmentation fault, your comment is reporting a delay caused by turning the devices power off.