-
Notifications
You must be signed in to change notification settings - Fork 39
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
[Bug]: Zigbee sub-devices are always in an "unavailable" state. Multiple brands of human presence sensors have been used, but they all remain "unavailable." #283
Comments
Enable the debug for the device and the integration, nothing can be done without the logs... |
This issue is stale because it has been open 14 days with no activity. Remove stale label or comment or this will be closed in 5 days. |
Have same issue with Bluetooth® Irrigation computer (bf87ce6slfcq8wpv) Bluetooth® Irrigation computer (bf87ce6slfcq8wpv).json config_entry-localtuya-378ca09c5026436ca75b04db41a86eaa.json |
This issue is stale because it has been open 14 days with no activity. Remove stale label or comment or this will be closed in 5 days. |
I've had this problem, after some updates of HA it started working. But after updating to 2024.7 it became unavailable again, it happens with all the Zigbee sensors, I can add them but not use them. |
According to the log, your gateway with address 192.168.0.122 has very unreliable connection with your router. There are only a few successful attempts to connect to it, but not for a long time. Is it WiFi gateway? Check if you can move it to a better place, or change the WiFi channel in the router settings to a less crowded. Your "Ar Condicionado Gael" (192.168.0.102) has unreliable connection with your router as well, though better than the gateway. Consider to improve it.
WiFi connection problems are not related to HA versions. |
Should there be no problem with SmartLife as well? |
I have one WiFi smart plug with weak WiFi connection. It appears to work correctly with SmartLife, but does show a similar behavior in my logs: Example
The explanation is the difference between two kinds of actions:
The first task is the primary task. If a device is busy with it, and its (very small!) RAM is full of data to send, it may refuse to play the second role. E.g. when I experience problems with Internet, my wired gateway may stop working even to control local Zigbee devices, because it is busy trying to send updates to the cloud. This plug is in the kitchen. When MW oven in use (=often status updates), it refuses connections more often. When MW oven is not used, it refuses connections much less often, I presume, when refrigerator turns its engine on and, again, there is something to let the cloud know about. |
There may be some problem with WiFi, but it's still very strange, because the device is 2 meters from the router, with no hurdle. If it had never worked I would have thought that the gateway was not compatible, but since there were a few days that it worked well, with small moments of unavailability, I can say that it is compatible. |
I agree. But the matter of the fact is that the gateway either inaccessible (most of the time):
or drops the connection:
By the way, I see similar messages, related to WiFi or Internet connection, from non-Tuya devices:
I don't know whether it fails to connect to your devices or to the cloud. As I said before, even with good WiFi signal, if a Tuya device can't reach the cloud, it may refuse connections. So, if you are confident about WiFi quality, check your Internet connection in general, and connection to Tuya and Broadlink clouds. |
Can you imagine any type of adjustment to be made to the router, such as port or DNS that is hindering this communication? |
Sorry, I can't be in help. But I'd start with investigation of WiFi quality using "WiFi Analyzer" app and router's statistics. Here is what my old router can show: Note the noise level: a device should have its signal >20dB above the noise level for stable connection. Here you can see that my plug (Tuya-Plug-1G): its "connected time" is only 25 hours, while other devices have it equal to the router uptime. It means, it tends to disconnect. Note the following devices:
It proves that the distance by itself does not really matter for the signal! In fact, relative antennas orientation is the main factor. Of course, after obstacles that prevent radio waves to come through, and how noisy the WiFi channel is. Good luck! |
This issue is stale because it has been open 14 days with no activity. Remove stale label or comment or this will be closed in 5 days. |
LocalTuya Version
2024.6.0
Home Assistant Version
2024.6.3
Environment
What happened?
Zigbee sub-devices are always in an "unavailable" state. Multiple brands of human presence sensors have been used, but they all remain "unavailable."
Steps to reproduce.
Relevant log output
No response
Diagnostics information.
No response
The text was updated successfully, but these errors were encountered: