Silicon Labs Multiprotocol: Problem controlling multiple devices at once since updating to 2.2.0

[MichaelMaex]

Describe the issue you are experiencing

Hi I'm running home assistant os on a rp4 with a sonoff zbdongle-E flashed with the firmware by darkxst.

Since updating to 2.2.0 I have trouble changing the states of all lights at once, eg. turn them all on/off, scene change.
There are 4 Nanoleaf essentials connected through homekit over thread, 3 Zigbee devices to be controlled (2 switches, one light) and 4 Zigbee dimmers (but they seem unrelated to the issue), all connected over ZHA.

When turning them all on/off usually they are not all responsive and only 5-6 out of 7 devices respond (the unresponsive devices are not always the same).
If one of the unresponsive devices is one of the Nanoleafs they will respond after a few seconds. The Zigbee devices don't seem to correct themselves later.

I've tried this with both the 230400 and 460800 baudrate firmwares, and both have the exact same issue.

I can't be entirely sure this a problem with the add-on and not the firmware, because at the same time as updating the add-on I changed from ksjh's rpc firmware version 4.2.2 to darkxst rpc firmware version 4.3.0. But I don't know how to determine which is at fault.

What type of installation are you running?

Home Assistant OS

Which operating system are you running on?

Home Assistant Operating System

Which add-on are you reporting an issue with?

Silicon Labs Multiprotocol

What is the version of the add-on?

2.2.0

Steps to reproduce the issue

Connect 2 Zigbee switches, 1 Zigbee light and 4 Nanoleaf essentials (homekit over thread) to add-on over a sonoff zbdongle 3 with firmware by darkxst and change the state of all lights at the same time by turning them all on or off.

System Health information

System Information

version	core-2023.6.3
installation_type	Home Assistant OS
dev	false
hassio	true
docker	true
user	root
virtualenv	false
python_version	3.11.4
os_name	Linux
os_version	6.1.21-v8
arch	aarch64
timezone	Europe/Brussels
config_dir	/config

Home Assistant Community Store

GitHub API	ok
GitHub Content	ok
GitHub Web	ok
GitHub API Calls Remaining	5000
Installed Version	1.32.1
Stage	running
Available Repositories	1278
Downloaded Repositories	14

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	Home Assistant OS 10.3
update_channel	stable
supervisor_version	supervisor-2023.06.2
agent_version	1.5.1
docker_version	23.0.6
disk_total	28.5 GB
disk_used	11.2 GB
healthy	true
supported	true
board	rpi4-64
supervisor_api	ok
version_api	ok
installed_addons	File editor (5.6.0), Studio Code Server (5.8.0), Samba NAS (10.0.2-nas2), Advanced SSH & Web Terminal (15.0.2), Glances (0.19.2), ZeroTier One (0.16.3), Hello world (1.0.18), Silicon Labs Multiprotocol (2.2.0), diyHue (2.0.9), Mosquitto broker (6.2.1), Piper (0.1.3), ESPHome (2023.6.0), Silicon Labs Flasher (0.1.1)

Dashboards

dashboards	1
resources	5
views	4
mode	storage

Recorder

oldest_recorder_run	18 June 2023 at 10:07
current_recorder_run	24 June 2023 at 13:10
estimated_db_size	378.13 MiB
database_engine	sqlite
database_version	3.41.2

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

2023-06-28 15:54:33.289 ERROR (MainThread) [async_upnp_client.ssdp] Received error: [Errno 101] Network unreachable, transport: <_SelectorDatagramTransport fd=23 read=polling write=<idle, bufsize=0>>, socket: <asyncio.TransportSocket fd=23, family=2, type=2, proto=0, laddr=('0.0.0.0', 39628)>
2023-06-28 15:55:03.294 ERROR (MainThread) [async_upnp_client.ssdp] Received error: [Errno 101] Network unreachable, transport: <_SelectorDatagramTransport fd=23 read=polling write=<idle, bufsize=0>>, socket: <asyncio.TransportSocket fd=23, family=2, type=2, proto=0, laddr=('0.0.0.0', 39628)>
2023-06-28 15:55:03.701 ERROR (MainThread) [async_upnp_client.ssdp] Received error: [Errno 101] Network unreachable, transport: <_SelectorDatagramTransport fd=22 read=polling write=<idle, bufsize=0>>, socket: <asyncio.TransportSocket fd=22, family=2, type=2, proto=0, laddr=('0.0.0.0', 46387)>
2023-06-28 15:55:33.298 ERROR (MainThread) [async_upnp_client.ssdp] Received error: [Errno 101] Network unreachable, transport: <_SelectorDatagramTransport fd=23 read=polling write=<idle, bufsize=0>>, socket: <asyncio.TransportSocket fd=23, family=2, type=2, proto=0, laddr=('0.0.0.0', 39628)>
2023-06-28 15:56:03.304 ERROR (MainThread) [async_upnp_client.ssdp] Received error: [Errno 101] Network unreachable, transport: <_SelectorDatagramTransport fd=23 read=polling write=<idle, bufsize=0>>, socket: <asyncio.TransportSocket fd=23, family=2, type=2, proto=0, laddr=('0.0.0.0', 39628)>

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

No response

Additional information

No response

[agners]

@darkxst do you have any thoughts on this issue?

From my side, I did not notice any degradation in performance when controlling multiple lights. I have a lamp consisting of 6 Ikea bulbs, and control them with a single button. This has been working with 4.2.x as well as with the current 4.3.0 based firmware/add-on releases.

[agners]

You can also try to downgrade by restoring the backup which was created when you updated the add-on. You can then try kshjh/darkxst's 4.2.2 firmware and see if that makes a difference.

[darkxst]

I dont have enough devices that implement the OnOff cluster to reproduce this scenario (most of my devices are sensors). But havent seen any issues with the 1-2 devices I usually have on my Multipan network.

I changed from ksjh's rpc firmware version 4.2.2 to darkxst rpc firmware version 4.3.0.

My builds are identical to ksjh's apart from the underlying SDK changes with the version bump. However I did disable hardware flow control as the Sonoff dongle does not support this.

Nanoleaf essentials (homekit over thread)

Do you see the same issue if you eliminate the homekit devices from the scenes and just control the Zigbee devices?

[MichaelMaex]

I had some time to experiment yesterday but didn't feel like writing up everything at 1am, cause things ended up taking much longer than expected.

Do you see the same issue if you eliminate the homekit devices from the scenes and just control the Zigbee devices?

Only controlling Zigbee devices, or only controlling thread devices worked fine on 2.2.0. But those are 4 and 3 devices each. Maybe that's just too little. But maybe there is something weird about using thread and Zigbee at the same time, and I think someone should test that with more devices, if possible.

You can also try to downgrade by restoring the backup which was created when you updated the add-on. You can then try kshjh/darkxst's 4.2.2 firmware and see if that makes a difference.

I tried this and somehow that completely screwed up ZHA. Everything stil seemed fine in integration panel but none of the Zigbee switches, lights, remotes worked. I tried going back to further backups, different firmwares. But in the end I had to form the Zigbee network again and re-pair all the devices. Then I noticed too late that the channel of the new Zigbee network was not the same as the thread network so I had to remake the thread rework and re-pair all the nanoleafs. After all that everything seems to work fine with the 2.1.0 version of the add-on and dakrxst's 4.2.2 firmware. All the lights, scene changes happen pretty much instantly again without problems.

I could try to upgrade again to 2.2.0 and see if re-pairing everything fixed the issue, but tbh I'm kinda hesitant to touch my working setup. Especially after how difficult it was to roll back.

[github-actions]

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.

[darkxst]

Maybe not your issue since a downgrade seem to fix it, but a channel mismatch between Zigbee and Thread could cause issues simlar to what you describe.

[github-actions]

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.

[MichaelMaex]

I recently tried to upgrade again to the latest version of the addon (2.3.2) and firmware (rpc 4.3.2) and the issue is back. It seems to only occur when I try to simultaneously control a Zigbee and (HAP over) thread device. Controlling one Zigbee and one thread one in a group, it seems to fail about once every 8 times. Controlling all my devices at the same time never works perfectly. Are there any relevant logs I can share? This time I'm sure both thread and Zigbee are on the same channel

[github-actions]

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.