Skip to content
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]random Zigbee sensors and switches become unavailable when localtuya integration reloads #497

Open
2 of 3 tasks
mmxxmm opened this issue Jan 19, 2025 · 9 comments
Open
2 of 3 tasks
Labels
bug Something isn't working

Comments

@mmxxmm
Copy link

mmxxmm commented Jan 19, 2025

LocalTuya Version

2025.1.1

Home Assistant Version

2025.1.2

Environment

  • Does the device work using the Home Assistant Tuya Cloud component?
  • Is this device connected to another local integration, including Home Assistant and any other tools?
  • The devices are within the same HA subnet, and they get discovered automatically when I add them

What happened?

Some random Zigbee sensors and switches become unavailable when localtuya integration reloads. The devices are working on Tuya mobile app. If I change the status of the entities related (turn on/off switches on Tuya App) or sensor status updated, the entity become back online on HA. No abnormal logs related to the entity were found. Just successful connect logs.

Steps to reproduce.

  1. Reload localtuya integration or restart HA core.

Relevant log output

2025-01-19 12:07:49.846 DEBUG (MainThread) [custom_components.localtuya.coordinator] [6c9...dpg - L Switch] Trying to connect to: 192.168.0.5...
2025-01-19 12:07:51.660 DEBUG (MainThread) [custom_components.localtuya.coordinator] [6c9...dpg - L Switch] Success: connected to: 192.168.0.5

Diagnostics information.

No response

@mmxxmm mmxxmm added the bug Something isn't working label Jan 19, 2025
@mmxxmm mmxxmm changed the title [Bug]: [Bug]random Zigbee sensors and switches become unavailable when localtuya integration reloads Jan 19, 2025
@xZetsubou
Copy link
Owner

xZetsubou commented Jan 19, 2025

The logs show in the device that being used as a gateway, you can check the gateway device from the device page in HA,
Post the device diagnostics of one of the sensor and switch.

@mmxxmm
Copy link
Author

mmxxmm commented Jan 19, 2025

I don't add the gateway itself to the HA. just the individual Zigbee devices.

{
"home_assistant": {
"installation_type": "Home Assistant OS",
"version": "2025.1.2",
"dev": false,
"hassio": true,
"virtualenv": false,
"python_version": "3.13.1",
"docker": true,
"arch": "x86_64",
"timezone": "Asia/Singapore",
"os_name": "Linux",
"os_version": "6.6.66-haos",
"supervisor": "2024.12.3",
"host_os": "Home Assistant OS 14.1",
"docker_version": "27.2.0",
"chassis": "vm",
"run_as_root": true
},
"custom_components": {
"localtuya": {
"documentation": "https://github.com/xZetsubou/hass-localtuya/",
"version": "2025.1.1",
"requirements": []
},
"scheduler": {
"documentation": "https://github.com/nielsfaber/scheduler-component",
"version": "v0.0.0",
"requirements": []
},
"retry": {
"documentation": "https://github.com/amitfin/retry",
"version": "v3.3.1",
"requirements": []
},
"hacs": {
"documentation": "https://hacs.xyz/docs/use/",
"version": "2.0.3",
"requirements": [
"aiogithubapi>=22.10.1"
]
},
"xiaomi_miot": {
"documentation": "https://github.com/al-one/hass-xiaomi-miot",
"version": "1.0.8",
"requirements": [
"construct>=2.10.68",
"python-miio>=0.5.12",
"micloud>=0.5"
]
}
},
"integration_manifest": {
"domain": "localtuya",
"name": "Local Tuya",
"codeowners": [],
"config_flow": true,
"dependencies": [],
"documentation": "https://github.com/xZetsubou/hass-localtuya/",
"integration_type": "hub",
"iot_class": "local_push",
"issue_tracker": "https://github.com/xZetsubou/hass-localtuya/issues",
"requirements": [],
"version": "2025.1.1",
"is_built_in": false,
"overwrites_built_in": false
},
"setup_times": {
"null": {
"setup": 0.0009722840040922165
},
"c5a4302abc0a4e6379ef379dd3746874": {
"wait_import_platforms": -0.2016013148240745,
"wait_base_component": -0.0006312476471066475,
"config_entry_setup": 0.2537206932902336
}
},
"data": {
"device_config": {
"device_id": "6cab...vju",
"entities": [
{
"friendly_name": "Ventilation Switch",
"id": "1",
"platform": "switch"
}
],
"friendly_name": "entilation Switch",
"host": "192.168.1.2",
"local_key": "48.....71",
"node_id": "a4c....a8",
"protocol_version": "3.3"
}
}
}

@xZetsubou
Copy link
Owner

I think logs is required to understand what's happening here. Enable the debug for device and copy everything related to localtuya logs not the device name because the device that would reports the debug is the gateway not sub-device.

@mmxxmm
Copy link
Author

mmxxmm commented Jan 20, 2025

Do I need to just to reconfigure the affected sub device and tick "Enable debug (must be manually enabled in configuration.yaml too)"?

@xZetsubou
Copy link
Owner

Just enable the sub-device and localtuya will enable the debug for both sub-device and the gateway automatically, but the logs will be named after gateway not the sub-device that why you should copy all related localtuya logs instead of filtering sub-device. or filter the gateway name in logs. so enabling debug for either sub-device or gateway would works.

@mmxxmm
Copy link
Author

mmxxmm commented Jan 20, 2025

Please look into the relevant logs,
Thanks.

logs2201.log

@xZetsubou
Copy link
Owner

Something is off, Can you post entry diagnostics

@mmxxmm
Copy link
Author

mmxxmm commented Jan 23, 2025

Please look into the entry diagnostics. I included only the device which localtuya integration recognizes as the gateway and the light device that becomes unavailable when integration reloads, until turn on/off manually via Tuya App. Thanks.
config_entry-localtuya.json

@xZetsubou
Copy link
Owner

The entry diagnostics is missing some devices so what I want to check is the from the logs the device sending a false payload not sure why but it does this why I wanted to check other sub-devices it maybe one configured wrongly or differently?

Also even tho I haven't seen one before but there might be a chance the this gateway running on 3.2 protocol version or not however I do still think that your GW is 3.3 tho something wrong happen leading it to send 3.2 payloads.

Also all the sensitive data on entry diagnostics would be censored automatically.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants