ZHA Zigbee Network Hell since Updates

And I assume you had to re-pair and set up every device from scratch?

I’ll just chime in that all my zigbee issues went away when I moved from the HUSBZB-1 to the Sonoff ZIgbee Dongle-P.

But… I NEVER had a stable net with the HUSBZB-1, so don’t know if my experience would be applicable.

I have since moved from ZHA to zigbee2mqtt for other reasons, but the initial swap was all under ZHA.

I did a backup/restore from the HUSBZB-1 stick to the Sonoff without needing to re-pair, However, I was not using the zwave side of the stick.

On a release party video, there was mention that migrating the HUSBZB-1 was an issue because the zigbee side remained powered even if all you needed was the zwave side. Migration clones the MAC address of the source stick, and two sticks powered up with the same MAC causes issues.

I don’t know if that was ever resolved. My guess is all they need to do is re-write a random MAC to the HUSBZB-1 zigbee chip, but things are rarely as simple as they seem.

Yup, I had to repair 54 devices but it was worth it. I also was originally using a HUSBZB-1 and ZHA. I switched to the new stick and from ZHA to zigbee2mqtt at the same time so not sure which one made the biggest difference.

Did you also switch out to a new zwave stick or continue using HUSBZB-1 for that?

I never used z-wave

How do we find out what this message really means? There’s no source, no destination and no message contents. It’s a useless error message, really.

I have the same scenario - updated recently, use the same stick, and same devices (hue bulbs and aqara sensors). Don’t use z-wave, but the wifi stuff is unafected so i assume it’s not an HA issue inserting latency/message drop/failure. And it also started about 20 days ago.

1 Like

+1 here

Been going nuts trying to ‘fix’ this when I never had a single issue prior to the recent updates with my ConBee II. Everything was snappy and reliable. Now lights take 3-5 seconds to turn on. Some randomly turn themselves on, some don’t always turn off. I’ve upgraded firmware, replaced off-brand devices, moved the USB stick to different locations to minimize interference. But now it is just as unreliable as Hubitat and SmartThings were back in the day.

1 Like

Yeah, same here. Super frustrating. From what I have gathered, the only solution is to switch to ZigbeeMQTT away from ZHA. I’m adding another Zigbee dongle and then slowly starting the migration.

I figured out my issue. In my house the wall switches are mostly Hue Wall Switch Modules or Shelly switches (that are powered but don’t cut power to the bulb), and what’s happening is that i used “trigger IDs” to have one automation for multiple buttons. What was happening was that my automations was set to “single”. Changed it to parallel (queued would probably make mroe sense for a single button, but i didn’t try it) and the problem is gone!

I suspect somewhere in the update from 2022.9 to 2022.10 there was a change in the logic for triggerIDs and that’s what crapped it out (or it really was zigbee that’s now slower and running multiple buttons close together was giving me issues - now that i think about it i may have solved the symptom).

I bit the bullet and started moving everything over to Zigbee2MQTT. I bought a new Zigbee stick and transferred the devices one by one to ensure I named them all the same. All previous automations are intact. I also set up the new mesh on a different channel (25) not to interfere with the old ZHA network. So far, I’m very impressed with Zigbee2MQTT. WAY more information and customizability with NO errors in the logs. Lighting fast.

Highly recommend taking the plunge and moving over. I’m happy to assist anybody with the switch.

I’ve made the same move from Conbee II + ZHA to Sonoff + Z2M and its been mostly smooth except a few of my Samsung SmartThings buttons keep joining and leaving the network which interferes with any additional pairing.

The annoying part is 3 of the SmartTHings buttons are fine and 3 have issues.

otherwise smooth sailing.

also having lots of errors now and issues as you all… i’m thinking of taking the plunge over to Z2M but i have 119 devices :weary:

and suggestions on making this move smoothly?

also i see a lot of you switched USB adapters AND moved to Z2M at the same time, how sure are you its the Z2M move vs the new adapter fixing the issue? i’m already using the SONOFF V2 USB 3.0

Does this mean re-pairing all devices? It does, right? I”m just thinking about all the furniture dragging (fishing water sensors from under the washer/dishwasher/freezer) and all the in-wall modules that i’ll have to screw open to click on the reset :frowning:.

To get the house back under control I’ve moved all my Hue stuff back to the hue Bridge. Now wall switches work at least and the the house doesn’t feel possessed anymore.

My plan was to keep a smaller zigbee network for all the sensors, but you’re not the first to say z2m is the way to go. I wonder if I should bring my bulbs back to z2m (the bigger the mesh the more reliable, right? Right?)

The one huge advantage of keeping the hue bridge is that i can mess with HA without impacting basic home lighting.

I bought another zigbee stick and ran two networks with different channels while moving it over. I repaired over 50 devices, and it actually when pretty quickly. Z2M renames the devices well, which meant I didn’t have to do any renaming of the entities in HA.

I have very similar issues. My network is a hot mess.

My config backup:

{
    "backup_time": "2022-11-15T15:33:34.207674+00:00",
    "network_info": {
        "extended_pan_id": "23:a5:2f:1b:20:e5:6a:d8",
        "pan_id": "CEED",
        "nwk_update_id": 0,
        "nwk_manager_id": "0000",
        "channel": 15,
        "channel_mask": [
            15
        ],
        "security_level": 5,
        "network_key": {
            "key": "ae:d7:b3:05:da:99:50:30:00:f3:50:c0:8c:13:ea:47",
            "tx_counter": 543141,
            "rx_counter": 0,
            "seq": 0,
            "partner_ieee": "ff:ff:ff:ff:ff:ff:ff:ff"
        },
        "tc_link_key": {
            "key": "5a:69:67:42:65:65:41:6c:6c:69:61:6e:63:65:30:39",
            "tx_counter": 0,
            "rx_counter": 0,
            "seq": 0,
            "partner_ieee": "00:21:2e:ff:ff:04:88:c7"
        },
        "key_table": [],
        "children": [],
        "nwk_addresses": {},
        "stack_specific": {},
        "metadata": {
            "deconz": {
                "version": 644220672
            }
        },
        "source": "[email protected]"
    },
    "node_info": {
        "nwk": "0000",
        "ieee": "00:21:2e:ff:ff:04:88:c7",
        "logical_type": "coordinator"
    }
}

I get A LOT logs(debug enabled) about updates all the time:

2022-11-15 16:40:48.769 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0xD48F](TRADFRI bulb E27 WS opal 1000lm): Device seen - marking the device available and resetting counter
2022-11-15 16:40:48.770 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0xD48F](TRADFRI bulb E27 WS opal 1000lm): Update device availability - device available: True - new availability: True - changed: False
2022-11-15 16:40:49.020 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0xAA80](TRADFRI control outlet): Device seen - marking the device available and resetting counter
2022-11-15 16:40:49.020 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0xAA80](TRADFRI control outlet): Update device availability - device available: True - new availability: True - changed: False
2022-11-15 16:40:49.023 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0x889C](TRADFRI bulb GU10 WS 400lm): Device seen - marking the device available and resetting counter
2022-11-15 16:40:49.023 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0x889C](TRADFRI bulb GU10 WS 400lm): Update device availability - device available: True - new availability: True - changed: False
2022-11-15 16:40:49.227 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0x5A1A](TRADFRI remote control): last_seen is 73265.55393505096 seconds ago and ping attempts have been exhausted, marking the device unavailable
2022-11-15 16:40:49.227 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0x5A1A](TRADFRI remote control): Update device availability - device available: False - new availability: False - changed: False
2022-11-15 16:40:49.577 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0x3788](TRADFRI bulb GU10 WW 400lm): last_seen is 69737.83611106873 seconds ago and ping attempts have been exhausted, marking the device unavailable
2022-11-15 16:40:49.578 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0x3788](TRADFRI bulb GU10 WW 400lm): Update device availability - device available: False - new availability: False - changed: False
......

And A LOT of messages like this:

2022-11-15 17:00:22.103 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0x0842](TRADFRI remote control): last_seen is 1864.078851222992 seconds ago and ping attempts have been exhausted, marking the device unavailable                                                                                             

The most concerning clue is the Visualization because I see many connections and it does not look right at all. Since there’s no legend, I am not sure what those lines and colours means:

I imagine I will have to go back to using deConz since there does not seem to be any clarity on these issues anywhere.

In any case, my thanks to the devs for all the work :+1:

Z2M’s map…

1 Like

My map after moving to zigbee2mqtt

Beautiful!

I’m finding Z2M SO much better than ZHA.

What light bulbs are you using that is also a Router? They seem to work really well with your mesh and signal strength.

It’s all Ikea stuff.

I recently dealt with this on a fresh install of Home Assistant, ZHA, and a Nortek stick on latest firmware.

In my case, I was seeing NETWORK_BUSY notifications with about 50 total devices, mostly Hue Bulbs of varying form factors.

I ended up tracing this down to two issues:

  1. the Adaptive Lighting integration - I was targeting ZHA groups for lights, which apparently don’t support some of the features Adaptive Light looks to use. Targeting individual bulbs seems to be the fix here (see open Github issue: Controlling one bulb in a ZHA light group affects all the bulbs in the group · Issue #345 · basnijholt/adaptive-lighting · GitHub)
  2. Automations - I had two types of automations I was using to turn on and off ZHA groups using various Pico remotes around my home. I had one of these automations I was developing spamming the ZHA groups causing NETWORK_BUSY.

So in the end, end user error, although I did consider moving to Z2MQTT initially.