search

home-assistant / addons

:heavy_plus_sign: Docker add-ons for Home Assistant
https://home-assistant.io/hassio/
Apache License 2.0
1.51k stars 1.47k forks source link

Silicon Labs Multiprotocol + ZHA + Sonoff ZB Dongle E = Aqara door sensor not reporting correctly #3417

Closed GitWally closed 6 months ago

GitWally commented 7 months ago

Describe the issue you are experiencing

Hello, the full history, to depict all details.

I decided to implement ZigBee in my HA environment, so I bought:

  1. Sonoff Zigbee USB 3.0 Dongle Plus
  2. USB extension cable, to keep antenna far away from HA (which is wired) and Router
  3. Aqara Door & Window Sensor

Since I was starting from scratch I decided to go for Multiprotocol approach to benefit from Matter / Thread in the next future.

Before any other intervention I have fixed WiFi 2.4 GHz channels 1 (router) and 6 (Access Point), in order to use Channel 25 with Zigbee.

Then I flashed Sonoff with web flasher from darkxst using RCP Remote Co-Processor firmware (see zbdonglee/rcp-uart-802154-v4.3.2-zbdonglee-460800 > https://github.com/darkxst/silabs-firmware-builder/blob/main/firmware_builds/zbdonglee/). Flashing was pretty straight forward

Then I installed Silicon Labs Multiprotocol 2.4.3 with given parameters (baudrate 460800, no hardware flow control, no automatically update firmware)

Initially I tried to install Zigbee2MQTT v 1.35.1 but was not able to start, so gave up and went for ZHA

In ZHA i was able to pair Aqara sensor, but in a short it started to report wrongly almost randomly.

In the end I gave up the Multiprotocol approach (I don't need Matter as of today), flashed Sonoff with NCP Network Co-Processor firmware (7.3.1.0 build 176) and Aqara started working preciselly and very accurate! This last point confirms hardware is ok, no problem with interference or whatsoever

Questions are:

a. has anybow reported this misbehaviour? b. may be, when Silicon Labs Multiprocol will exit "experimental" phase, this be fixed?

Many thanks for attention!

What type of installation are you running?

Home Assistant Supervised

Which operating system are you running on?

Debian

Which add-on are you reporting an issue with?

Silicon Labs Multiprotocol

What is the version of the add-on?

2.4.3

Steps to reproduce the issue

  1. Flashed Sonoff with web flasher from darkxst using RCP Remote Co-Processor firmware (see zbdonglee/rcp-uart-802154-v4.3.2-zbdonglee-460800 > https://github.com/darkxst/silabs-firmware-builder/blob/main/firmware_builds/zbdonglee/)

  2. Installed Silicon Labs Multiprotocol 2.4.3 with given parameters (baudrate 460800, no hardware flow control, no automatically update firmware)

  3. Using ZHA pair Aqara Door & Window Sensor

  4. Check sensor reliability ...

System Health information

System Information

version core-2024.1.3
installation_type Home Assistant Supervised
dev false
hassio true
docker true
user root
virtualenv false
python_version 3.11.6
os_name Linux
os_version 5.10.0-27-amd64
arch x86_64
timezone Europe/Berlin
config_dir /config
Home Assistant Community Store GitHub API | ok -- | -- GitHub Content | ok GitHub Web | ok GitHub API Calls Remaining | 5000 Installed Version | 1.33.0 Stage | running Available Repositories | 1450 Downloaded Repositories | 8 HACS Data | ok
Home Assistant Cloud logged_in | false -- | -- can_reach_cert_server | ok can_reach_cloud_auth | ok can_reach_cloud | ok
Home Assistant Supervisor host_os | Debian GNU/Linux 11 (bullseye) -- | -- update_channel | stable supervisor_version | supervisor-2023.12.1 agent_version | 1.5.1 docker_version | 24.0.7 disk_total | 232.2 GB disk_used | 191.5 GB healthy | true supported | true supervisor_api | ok version_api | ok installed_addons | Duck DNS (1.15.0), File editor (5.7.0), Home Assistant Google Drive Backup (0.112.1), Mosquitto broker (6.4.0), Glances (0.21.0), Frigate (Full Access) Beta (0.13.0) (0.13.0-rc1), Piper (1.4.0), Whisper (1.0.2), Google Assistant SDK (2.5.0), openWakeWord (1.8.2), Hikvision Doorbell (3.0.13), Silicon Labs Multiprotocol (2.4.3)
Dashboards dashboards | 1 -- | -- resources | 3 views | 11 mode | storage
Recorder oldest_recorder_run | 7 January 2024 at 07:30 -- | -- current_recorder_run | 15 January 2024 at 22:10 estimated_db_size | 180.90 MiB database_engine | sqlite database_version | 3.41.2

Anything in the Supervisor logs that might be useful for us?

No response

Anything in the add-on logs that might be useful for us?

No response

Additional information

No response

puddly commented 7 months ago

Are you using identical network settings in each test (i.e. channel 25)?

GitWally commented 7 months ago

Are you using identical network settings in each test (i.e. channel 25)?

Yes, in both cases channel 25

samoz83 commented 7 months ago

I had the same experience with Aqara door sensors and Hue motion sensors. Pretty much the same setup except using zigbee2mqtt.

Seems messages from a number of end devices were not being picked up or processed when using the multiprotocol setup.

Switched back to just NCP firmware and everything is working as expected. Device states updating immediately when changes happen.

GitWally commented 7 months ago

Switched back to just NCP firmware and everything is working as expected. Device states updating immediately when changes happen.

I hope that's because Multiprotocol is experimental

hensjl commented 7 months ago

Same problem here. Devices that only push messages, like switches and motion sensors, have unstable connection. Before returning back to NCP firmware, this week I will test some of them with Tuya cloud.

MattWestb commented 7 months ago

Be sure having some good routers and adding end devices to roues and not to the coordinator (then its also one router but its not 24/7 online then restarting the system and all problem devices you have need 24/7 parent or they is getting problems). Also after have adding one router (or more) disabling the coordinator having direct child's is recommended by adding it in the HA config and is getting more stable end devices in the network.

GitWally commented 7 months ago

Be sure having some good routers and adding end devices to roues and not to the coordinator (then its also one router but its not 24/7 online then restarting the system and all problem devices you have need 24/7 parent or they is getting problems).

Also after have adding one router (or more) disabling the coordinator having direct child's is recommended by adding it in the HA config and is getting more stable end devices in the network.

In my case Aqara sensors are 3 mt away from the coordinator, less than 1,5 in straight line. Do you say also in this simple case I should put a router in the middle? Thought it was needed in a larger mesh. For the moment I will stay just with zigbee, since I heard a lot of issues with Silicon Lab Multiprocol versions. Thanks

hensjl commented 7 months ago

Same problem here. Devices that only push messages, like switches and motion sensors, have unstable connection. Before returning back to NCP firmware, this week I will test some of them with Tuya cloud.

GOOD NEWS

I have 5 motion sensors (2 tuya and 3 ikea), all had problem with RCP. I never used NCP and had the problem from the beginig, 2 or 3 months ago. Flashed with darkxst web falsher from the begining. /dev/serial/by-id/usb-ITEAD_SONOFF_Zigbee_3.0_USB_Dongle_Plus_V2_20231007154236-if00

I Disconnected the 2 tuya, to connect them to a little tuya hub. no more problem for them. The 3 ikea sensors are set side by side to be activated together. About once in ten, the 3 sensors do not see me, always together.

Then, I decided to to fash back to NCP with the same tool from darkxst. But I can't. Devide detected but not firmware and the flasher stop. Having no time to investigate, I put the dongle back to my Pi4.

NOW IT WORK LIKE EXPECTED

What is changed ?

If this can help someone...

github-actions[bot] commented 6 months ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.