C7 on 2.5.0.143 trying to update the firmware on a Third Reality Multi-Function Night Light with the stock/system DTH. It finds an updated firmware for it, but the device doesn’t support OTA? Am i missing something?
|Application|48|
| --- | --- |
|Endpoint Id|01|
|Firmware MT|130D-0000-00000048|
|Manufacturer|Third Reality, Inc|
|Model|3RSNL02043Z|
|Software Build|v0.00.72|
sys:16/04/2026 4:40:06.479 pmwarnFirmware update for [name:Kitchen Motion 1, manufacturer:Third Reality, Inc, imageFileName:130D-0000-00000056, fileVersion:00000056] failed, the device doesn't support OTA.
sys:16/04/2026 4:40:06.018 pmtraceStarting firmware update for Kitchen Motion 1, Third Reality, Inc from 00000048 to 00000056.
I had a similar issue just 2 weeks ago- I took the unit out of my network (using Replace function with virtual RGBW to save the In Use By) then added it to a Home Assistant environment. Did the update there and it worked. There seemed to be an interim firmware as I went from …0025 to 0042 then the 0056. So it does update OTA just didn’t in the HE world.
I reversed the process using Replace again and bob was my uncle.
All my other 3rd Reality devices did update OTA from HE (I have 21 of their excellent products).
I was really trying not to put a zigbee or zwave adapter into my HA instance, but that sounds like it could work and provide another data point. Prime to save the day. 
I’ve seen the Zigbee firmware update process get twisted into a pretzel on occasion. Try the shutdown-pull power-wait-startup dance.
I have four of these on C7s and they all updated to the latest firmware.
Solid advice, but i already tried that troubleshooting the return of zigbee radio resets. This popped up dotting my “T’s” and crossing my “I’s” on that issue. You know how the rabbit hole goes. I have a solid idea which device is causing the resets, i just want to be wrong before the return window closes.
1 Like
I’ve had my share of those. In my own experience, never managed to trace that back to any Zigbee device. The finger seems to always point to a LAN driver or app overwhelming the hub just enough and for long enough for it to miss its date with the NCP, which gets very upset when that happens. I even have an app that basically triggers a Zigbee radio reboot upon request.
Good luck and let us know.
My experience has been different, but i’m still checking everything. Last time is was several zigbee power metering outlets spamming the hub with power metering data. Once i figured out how to turn it off and get the settings to stick the issue went away.
This time it started with in 24hrs of adding a new zigbee switch. It’s even a sonoff so it’s reputable. I’m 75% sure the issue will go away by removing the device, but i really dont want to send it back. There are not a lot controllable usb switches that do usb data passthrough.
Typically my busiest device is hubstats and my busiest app is a RM rule. Hub cpu tracks around 20%. ram free is a bit lower than i’d like it ~100-150 mb free, though i dont see any correlation with memory usage and the zigbee radio going offline.
I don’t doubt it. My guess has been that a busy Zigbee NCP is a necessary condition for the issue to surface but not sufficient - it’s unlikely that Zigbee, with its limited protocol throughput, is capable of saturating the host CPU on its own. More likely the host is ALSO busy enough doing other things and the combination leads to failure to service the NCP in time, which causes the timeout, consequent error state and ultimately reboot.
Have you considered adding a second hub to your setup, meshed in, keeping the C7 focused on Zigbee and light on everything else? I’ve not had to go that route myself (yet), but I have considered it.
I never saw any correlation between those stats and zigbee offline/online events, either. I believe those aggregate, cumulative metrics are generally far too coarse to expose the transient issue that leads to these reboots. For example, I found hammering one of my hubs with http requests in a 10-20 second burst is typically enough to cause radio reboots, yet that flies under the hub stats “radar”. I don’t have a good alternative to suggest, unfortunately.
@jshimota I moved the Third Reality Multi-Function Night Light over to HA... the firmware failed over there too.
Well, all i know right now is this device not supporting OTA is not a Hubitat issue
You got me… I’ve no idea why yours acts differently! I checked your model, same as mine, your version (48) - which is exactly what HA brought me forward from.
This isn’t related, but I note ‘doesn’t support OTA’ - in my experience that just means HA has no available firmware for that device - again, my experience. Your directly connected via zigbee, not through any gateway or bridge of any type? using the Third Reality Multi-Function Night Light driver on HE? shrugs… firmware. so hit or miss.
@hubitrep I’m 2 for 2 on “it’s not the hub it’s the device”. Once i powered off the sonoff zbmicro i’ve gone over 24hrs with out zigbee radio reboots. I even moved it to HA to see if it had any FW updates… nope.
I have ~40 zigbee devices. i don’t think i’m pushing any zigbee limits on the C-7, but if this is its way of nudging me towards zwave and thread… I’ll be ok with that.
Glad you found a way to resolve your reboot issue.
I have 113 on one C7. You’re not likely to be pushing any zigbee limits…
… which is why I’d say “it’s both”. There is no denying that some devices point a firehose at the hub.