Zigbee Acting Like It's Capped on Devices

Well, I’m far worse off than before, lol. I updated the firmware on both of my adapters and it went with no errors, but now ZFA cannot connect to the Zigbee controller and if I reconfigure and tell it to either reconfigure the current radio or migrate (to the spare adapter) it cannot open the port:

Looking at others that have had similar issues, there’s nothing specific to HAOS that is viable, as trying to change permissions (as several recommended and said fixed their issue) is not possible.

Did you try /dev/serial/by-id/… ?

I tried both, they both come up with the same message

Which exact dongle do you have? And which exact firmware are you on?

If I look at that table it has it’s limits.

Did you use the router-only firmware or the coordinator firmware?

I have the Sonoff Dongle 3.0 USB Plus, the firmware I posted above is what it was, then I upgraded it to 20240710 according to the instructions posted here and elsewhere (that were all mostly the same) (ITead's "Sonoff Zigbee 3.0 USB Dongle Plus" (model "ZBDongle-P") based on Texas Instruments CC2652P radio SoC/MCU).

I’ve turned on debug logging and am wondering if it’s stuck in bootloader, the errors are odd - it seems to recognize it and even sees that there was a firmware change, but it errors out:

2024-08-26 11:50:49.636 DEBUG (MainThread) [homeassistant.components.zha] Failed to set up ZHA
Traceback (most recent call last):
  File "/usr/local/lib/python3.12/site-packages/zigpy_znp/api.py", line 694, in _skip_bootloader
    result = await responses.get()
             ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/asyncio/queues.py", line 158, in get
    await getter
asyncio.exceptions.CancelledError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/zha/__init__.py", line 152, in async_setup_entry
    zha_gateway = await ZHAGateway.async_from_config(
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/zha/core/gateway.py", line 197, in async_from_config
    await instance.async_initialize()
  File "/usr/src/homeassistant/homeassistant/components/zha/core/gateway.py", line 215, in async_initialize
    await app.startup(auto_form=True)
  File "/usr/local/lib/python3.12/site-packages/zigpy/application.py", line 233, in startup
    await self.connect()
  File "/usr/local/lib/python3.12/site-packages/zigpy_znp/zigbee/application.py", line 103, in connect
    await znp.connect()
  File "/usr/local/lib/python3.12/site-packages/zigpy_znp/api.py", line 736, in connect
    self.capabilities = (await self._skip_bootloader()).Capabilities
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/zigpy_znp/api.py", line 693, in _skip_bootloader
    async with async_timeout.timeout(CONNECT_PROBE_TIMEOUT):
  File "/usr/local/lib/python3.12/site-packages/async_timeout/__init__.py", line 141, in __aexit__
    self._do_exit(exc_type)
  File "/usr/local/lib/python3.12/site-packages/async_timeout/__init__.py", line 228, in _do_exit
    raise asyncio.TimeoutError
TimeoutError
2024-08-26 11:51:16.979 DEBUG (bellows.thread_0) [zigpy.serial] Opening a serial connection to '/dev/ttyUSB0' (115200 baudrate)
2024-08-26 11:51:16.986 DEBUG (MainThread) [bellows.ezsp] Resetting EZSP
2024-08-26 11:51:21.993 DEBUG (MainThread) [zigpy.application] Failed to probe with config {'path': '/dev/ttyUSB0', 'baudrate': 115200, 'flow_control': None}
Traceback (most recent call last):
  File "/usr/local/lib/python3.12/site-packages/zigpy/application.py", line 631, in probe
    await app.connect()
  File "/usr/local/lib/python3.12/site-packages/bellows/zigbee/application.py", line 149, in connect
    await ezsp.startup_reset()
  File "/usr/local/lib/python3.12/site-packages/bellows/ezsp/__init__.py", line 125, in startup_reset
    await self.reset()
  File "/usr/local/lib/python3.12/site-packages/bellows/ezsp/__init__.py", line 151, in reset
    await self._gw.reset()
TimeoutError
2024-08-26 11:51:22.000 DEBUG (bellows.thread_0) [zigpy.serial] Opening a serial connection to '/dev/ttyUSB0' (57600 baudrate)
2024-08-26 11:51:22.004 DEBUG (MainThread) [bellows.ezsp] Resetting EZSP
2024-08-26 11:51:27.012 DEBUG (MainThread) [zigpy.application] Failed to probe with config {'path': '/dev/ttyUSB0', 'baudrate': 57600, 'flow_control': None}
Traceback (most recent call last):
  File "/usr/local/lib/python3.12/site-packages/zigpy/application.py", line 631, in probe
    await app.connect()
  File "/usr/local/lib/python3.12/site-packages/bellows/zigbee/application.py", line 149, in connect
    await ezsp.startup_reset()
  File "/usr/local/lib/python3.12/site-packages/bellows/ezsp/__init__.py", line 125, in startup_reset
    await self.reset()
  File "/usr/local/lib/python3.12/site-packages/bellows/ezsp/__init__.py", line 151, in reset
    await self._gw.reset()
TimeoutError
2024-08-26 11:51:33.822 DEBUG (MainThread) [zigpy.application] Failed to probe with config {'path': '/dev/ttyUSB0', 'baudrate': 115200, 'flow_control': None}
Traceback (most recent call last):
  File "/usr/local/lib/python3.12/site-packages/zigpy_deconz/api.py", line 589, in _command
    return await fut
           ^^^^^^^^^
asyncio.exceptions.CancelledError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/local/lib/python3.12/site-packages/zigpy/application.py", line 631, in probe
    await app.connect()
  File "/usr/local/lib/python3.12/site-packages/zigpy_deconz/zigbee/application.py", line 97, in connect
    await api.connect()
  File "/usr/local/lib/python3.12/site-packages/zigpy_deconz/api.py", line 466, in connect
    await self.version()
  File "/usr/local/lib/python3.12/site-packages/zigpy_deconz/api.py", line 813, in version
    self._protocol_version = await self.read_parameter(
                             ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/zigpy_deconz/api.py", line 832, in read_parameter
    rsp = await self.send_command(
          ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/zigpy_deconz/api.py", line 508, in send_command
    return await self._command(cmd, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/zigpy_deconz/api.py", line 588, in _command
    async with asyncio_timeout(COMMAND_TIMEOUT):
  File "/usr/local/lib/python3.12/asyncio/timeouts.py", line 115, in __aexit__
    raise TimeoutError from exc_val
TimeoutError
2024-08-26 11:51:36.827 DEBUG (MainThread) [zigpy_zigate.api] Unsuccessful radio probe of '/dev/ttyUSB0' port
Traceback (most recent call last):
  File "/usr/local/lib/python3.12/asyncio/tasks.py", line 520, in wait_for
    return await fut
           ^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/zigpy_zigate/api.py", line 606, in _probe
    await self.set_raw_mode()
  File "/usr/local/lib/python3.12/site-packages/zigpy_zigate/api.py", line 431, in set_raw_mode
    await self.command(CommandId.SET_RAWMODE, data)
  File "/usr/local/lib/python3.12/site-packages/zigpy_zigate/api.py", line 388, in command
    done, pending = await asyncio.wait(tasks, timeout=timeout)
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/asyncio/tasks.py", line 464, in wait
    return await _wait(fs, timeout, return_when, loop)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/asyncio/tasks.py", line 550, in _wait
    await waiter
asyncio.exceptions.CancelledError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/local/lib/python3.12/site-packages/zigpy_zigate/api.py", line 576, in probe
    await asyncio.wait_for(api._probe(), timeout=PROBE_TIMEOUT)
  File "/usr/local/lib/python3.12/asyncio/tasks.py", line 519, in wait_for
    async with timeouts.timeout(timeout):
  File "/usr/local/lib/python3.12/asyncio/timeouts.py", line 115, in __aexit__
    raise TimeoutError from exc_val
TimeoutError


2024-08-26 11:52:01.151 DEBUG (MainThread) [homeassistant.components.zha.repairs.wrong_silabs_firmware] Failed to probe application type
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/zha/repairs/wrong_silabs_firmware.py", line 87, in probe_silabs_firmware_type
    await flasher.probe_app_type()
  File "/usr/local/lib/python3.12/site-packages/universal_silabs_flasher/flasher.py", line 235, in probe_app_type
    raise RuntimeError("Failed to probe running application type")
RuntimeError: Failed to probe running application type

50 direct children, but 200 Zigbee 3.0 devices if using routers. Op hardly reaches those limits.

20240710 is released already ( as in out of beta) ?

2 days ago apparently:

Fortunately my un-needed (now needed) 3rd dongle should arrive today, it will be interesting to see if that can connect without any issues.

BTW, this is why I split my network across protocols, I can live without Zigbee for a while - it’ll suck, but 2/3rds of my automation is still fine.

So, something definitely is going on with ZHA/HA and the 20240710 firmware. Now I read a couple of posts on that release where people claimed to be able to get it working but it had some issues, apparently as well. Regardless, two of my dongles flashed with that firmware would not recognize, but a brand new dongle that has the 20210708 firmware worked immediately.

I’ve learned a couple things from this somewhat frustrating experience:

  • The ZHA auto backups are fantastic, takes all the thought out of the mix for getting back up again
  • The ZHA option to “reconfigure radio” is somewhat confusing as you would assume you need to migrate to a new radio with a new dongle but you do not - you migrate to a new radio if the old dongle is still there and operational, otherwise you reconfigure
  • Updating firmware is risky business (yes, I knew this already) but just because it’s a major company doesn’t exclude it from potentially ruining your day

Now, will/does it fix the problem that I originally posted about? That remains to be seen - my gut says no but there’s part of me that also says “well, it is a factory device and the only similarity is the NVRAM was restore so maybe.”

Of course, the original concept of forcing Zigbee into panic mode may still pan out, hopefully the next 24 hours will tell. In the meantime I’m back to where I started at least and have Zigbee back to where it was before.

2 Likes

Check out my related comment regarding new firmware for Sonoff’s ZBDongle-P CC2652/CC2652P adapter here → ITead's "Sonoff Zigbee 3.0 USB Dongle Plus" (model "ZBDongle-P") based on Texas Instruments CC2652P radio SoC/MCU - #590 by Hedda

Recommend test the previous firmware release version to test if work with that (you will of course then have to restore Zigbee network from backup).

With updates of Z-Stack firmware it is best practice to do a full Zigbee network backup before and then restore that backup after the firmware flashed it (as flashing Texas Instruments often reset it to factory defaults).

Also, not sure now but of the top of my head I believe that you should enable software flow control?

Anyway, while not specific for ZHA be aware that the general Alpha/Beta firmware discussion for Z-Stack_3.x.0 coordinator 20240710 firmware feedback can be found here → Z-Stack_3.x.0 coordinator 20240710 feedback

However, if using ZHA however then best is probably to aubmit to start a new issue discussion for ZHA debugging and diagnos in Home Assistant’s core repository → Issues · home-assistant/core · GitHub

But first read and follow this → https://www.home-assistant.io/integrations/zha#debug-logging as well as this → https://www.home-assistant.io/integrations/zha#reporting-issues

ZHA developers then have the option to analyze your debug logs if you attatch them to the issue there.

That is what I have done too for Zigbee and Z-Wave (but only because I already had a large Z-Wave network before I started buying Zigbee devices), though you need to note that with mesh networking protocols it is best to have a large network, so I strongly advise against splitting your Zigbee network into more than one Zigbee network. You should really keep all your Zigbee devices on a single Zigbee network and make sure that have loads of Zigbee Router devices on that network. Spread out “known good” Zigbee Router devices evenly in your home and especially make sure that each battery-powered device has at least two Zigbee Router devices between it and the Zigbee Coordinator for redundancy if one of those Zigbee Router devices goes down. Again, the reason why that is and more is covered in my guide → Zigbee networks: how to guide for avoiding interference + optimize using Zigbee Router devices (repeaters/extenders) to get a stable mesh network with best possible range and coverage

As did I and why I started adding Zigbee.

I agree.

I wouldn’t do that, you may have confused my meaning to mean that I would, but I was talking about spreading my devices across multiple protocols entirely.

@Hedda where is the 20210708 firmware? I see the latest and I see one from 20190523 but not the one that is shipping on the devices currently that I overwrote.

Later releases can be found here:

For older releases you need need to dig in the “history” for correct directory in the repo on GiHub:

I however meant that you should just try the previous release from 20230507.

More info and discussion about firmware here:

I just took one of my spares and loaded the previous version on there, 20230507, and had the exact same result: failed to connect. As soon as I put my factory version on it worked again.

It makes me wonder if perhaps I’m flashing incorrectly:

  • Disassemble the stick
  • Press and hold the boot button as I plug it into my Mac
  • Start ZigStar 0.4.2 (downloaded yesterday)
  • Select my device
  • Select the firmware
  • Select “Write” checkbox
  • Click “Write” button

I can see it uploading to the device and it seems to work fine, but this is two firmware versions on two different sticks that cause the stick to not be able to be read by ZHA.

Never mind for now, I need to also “Erase”, I just tried that and the 2023 version is at least restoring, I’ll test how well it works before attempting the latest one.

UPDATE: Restored fine and allowed me to add another device that wouldn’t add under the factory firmware - this looks very promising!

So my original problem is mostly unchanged. I was able to get the 2024 firmware to work on the dongle after some trial and error but still cannot add a mains device (Inovelli Blue), so there is still something causing the network to cap at, now, 46 devices.

This might be one of those issues that could be better handled on discord, the experts are there and respond pretty quickly.

That said, and I’m not an expert, this really seems like an interference issue. I’d look at the energy scan, compare that to what you see for current WiFi channel usage, make sure you have your mesh on the best channel you can.

I’d also turn debug logging on during the join and see if you even see the new device announce itself and if so what happens next. As far as mesh size, I’m at 65, others are over a 100, you aren’t hitting a hard device limit here.