What's up with all the extra Zigbee OTA traffic on 2.3.3?

Cool...appears I have the same issue as others w/these reports, haven't noticed any clear impacts on Zigbee performance, though I did have one Iris v3 motion sensor that stopped reporting last night, I had to pull battery and restart and then it was fine. Everything else seems OK.

I feel validated that I wasn’t going crazy when I saw this in my zigbee logs, and that’s it’s reproducing for people far smarter than me. I’m confident this will get fixed soon.


My system came to a halt everyday. Sometimes nothing worked when I got up in morning, others part way through the day. It always started with my Zigbee devices stopped working. My system ran fine before 2.3.3 and is now working fine on 2.3.2. My logs matched those provide in this thread.

1 Like

Same here.. hopefully a fix soon so.i dont have to revert.

1 Like

Also what is the procedure for reverting as there was that db update.

You will need to restore a backup from 2.3.2 (or earlier), as a 2.3.3 backup will not be compatible with pre-2.3.3 firmware. The release notes have some more information, and it actually sounds like one will be automatically restored for you, likely the latest. However, you may want to do it yourself for more control over which backup:

Keep in mind that you will lose any app, device, settings, etc. changes you have made since then--anything stored in the main database.


In my opinion, the issue with the OTA update requests in 2.3.3 could affect negatively only some zigbee sensors battery life. A healthy Zigbee network can not be congested by such a minor traffic increase.


Agreed, a half dozen messages every 10 minutes won't harm Zigbee performance, though the periodic flood of broadcasts from multiple devices (the match descriptor traffic) might impact a mesh that's on the hairy edge of functionality.

But the impact on battery life is another story... these devices aren't designed to support their target battery life (criteria for certification of a Zigbee device is actually two years) unless they remain in sleep mode practically all of the time, or constrained to transmitting simple sensor events. Even for devices like IR sensors in high traffic areas, impact on power consumption of continual periodic broadcast messages (which in turn involves subsequent polling cycles for replies) is much more drastic than signaling motion events (there's no subsquent required polling for message retrieval).

Interesting to note the differences in power consumption of sleep, awake, and 'radio on' states for a typical ARM Cortex Zigbee SoC. Using a 2016-era SiLabs Ember device as an example, while not part of a network the device's current consumption is around 7.5mA fully awake with just the controller running. While scanning for PANs or trying to join a network with radio fully on, it consumes 30-35mA; as it does during transmissions and listening for replies, along with processing intervals during which it consumes around 10mA. Yet while asleep the device consumes only 1uA, at least 30,000 times less power. Even with radio off, while just processing the stack and deciding what to do next, device power consumption can be 10,000 times higher than sleep state.

And the devices with the smallest capacity-- the wafer cell types like 2032 and CR2450-- suffer the most impact to battery life, not just by increased average power consumption but by patterns that involve periodic current spikes in the 30mA range. Thanks to Nordic Semiconductor for this informative article that explains it much better than I can: High Pulse Drain Impact on Coin Cell Battery Capacity


I decided to roll my zigbee hub back to 2.3.2 because if this issue and more importantly my doorbell notification stopped working:

1 Like

Yeah, that would do it, thanks for posting this.
Found the issue on our end, should be fixed in the next update.


Please try, just released.


see post about broken time in logging on .126 probably should be pulled?

Just applied .126 (before getting wind that a new release is imminent, as is my custom :neutral_face:). The good news is that Zigbee logging (re: OTA clusterID 19 frequency) looks much the same as it did on


Just upgraded to and all is well. Problem solved including the Sage doorbell issue I linked above.


@gopher.ny, just a data point: my Iris motion sensors all quit working after I upgraded to on my C5 (zigbee only) hub. They seemed to be hit and miss after the last 2.3.3 upgrade, but I don't remember when I did that upgrade. I brought up the logs before downgrading and didn't see anything odd. I rolled back to and they are now back online and working fine.

What version are they? I have 10 of the Iris V2 motion sensors that haven’t missed a beat.


Not sure, here's a screen print:

Maybe an issue with whatever device they route through...which I don't know!

Your devices are Iris V2 motion sensors. How many do you have? And how many routers?

I have 10 of the Iris motion sensors, and I don't know what they route through...