Maybe it becomes an issue based on its frequency. Mine is not too bad, but maybe if it was much more frequent it becomes an issue?
1 Like
Iris contact sensors, Iris motion sensors, almost all of my Samsung devices (buttons, contact sensors, plugs, leak sensors), GE dimmers and switches. Is this the fix for “Zigbee firmware update stuck at 80%”?
No, for sure there is no relationship to that fix.
Any ideas? I’m just wondering what could be causing this and how it will impact battery life. I’m assuming negatively long term.
Btw, logging pages can be filtered by the device (by clicking on its name at the top of the page),.. makes the periodic nature very clear for what would be normally quiet devices.
I don't see any performance impacts, but I'm not measuring anything. Battery life has to get worse and the extra RF congestion won't help either. Minimal impacts, but enough to make me back off to the 2.3.2 (I just put in a fresh set of batteries on most of my sensors, and my OCD made me do it). Missing all the really neat UI logging enhancements of 2.3.3 though!!
I have restored my Zniffer setup, let me know if WireShark CAP files can be of any help...
What I see is that the devices are sending Command: Query Next Image Request (0x01), then HE just acknowledges the command, then the device sends the next ZCL OTA: Query Next Image Request , increasing the sequence number, again only acknowledge from HE, repeated 5 times until the next cycle of Match descriptor request broadcast from the device and next 5 OTA requests.
Seems like this is the difference compared to 2.3.3.xxx :
5 Likes
FWIW, on 2.3.2 that I just fired up (I've had Zigbee logging running on it for over 10 minutes) the only OTA related thing I see is a single instance of clusterID 0x19 message, and only from a couple of my Iris V2 plugs. Not seeing any ZDO Match descriptor requests (profile 0x00/ clusterID 0x6's) at all, and not a 0x19 peep out of any other of my Zigbee device types. No device (other than the Iris V2 plugs) has generated any OTA traffic at all.
Also on 2.3.2, the frequency of the clusterID 0x19s for the V2 plugs is evidently greater than 10 minutes, otherwise all my Iris V2 plugs would have logged an instance by now (so I guess it follows that other device types may yet generate some OTA traffic, if I wait long enough).
1 Like
If you're worried about network congestion or battery life please revert to 2.3.2 for the time being until we sort this out.
9 Likes
Just checked Zigbee logging again; on 2.3.2.141, the Iris V2 plugs are ticking off a single OTA clusterID 0x19 message at 30 minute intervals (or so it appears thus far). Nothing else, and no other Zigbee device type appears to have generated anything OTA related yet.
1 Like
I think the problem and the possible solution are clear - see the last screenshot here. 2.3.3. is missing the OTA query response from HE w/ Status: Ota No Image Available (0x98).
10 Likes
Bingo!
3 Likes
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.
4 Likes
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.
4 Likes
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.
6 Likes
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
4 Likes
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
