Inovelli Blue Zigbee switches going offline constantly

Over the last few days, my zigbee network seems to crash after a few hours resetting (power off/on/airgap) all zigbee devices.

C7
Platform version
2.3.7.145

I noticed the past few days that some of my sunset/sunrise rules were not functioning (turning on exterior lights etc...). The switches work locally (Inovelli 2-1s), but do not respond from the device page. This is happening to every single zigbee end point on one of my C7 hubs; the other C7 hub only has a few devices and is working fine.

After resetting each zigbee device, the switches respond to commands from the device page or remote commands (Alexa). It seems to work for about 6 hours, but after that, the switches no longer function from on the zigbee side of things.

I've tried rebooting the hub, shutting down the hub, disabling/enabling the zigbee radio, restore the database; all with little to zero success.

When I try to look at the zigbee device graph, I see zero clients.


Also, I noticed the radio on/off events; similar to the C8 thread: C8 Zigbee Radio Turning Off/On Multiple Times a Day - #626 by harold.min

Any tips/tricks to get this hub fully functional again? I've had the 2-1s working flawlessly for the past 1+ year. Zwave side seems to be operational with the few Zwave components I have included into the network.

Tagging @bobbyD

Whats the PAN ID and Channel of your other Hub?

Have you tried shutting the hub down with power removed for 20+ mins so the devices all go into panic mode? Then supposedly they should find the hub again once it is online, may take a few hours I guess.

My other hub is on channel 20;

I unplugged my hub earlier this evening and will plug it in tomorrow. Giving it a good 12+ hours of no power. Prior to this, the hubs and devices have worked great.

I will say, and could be pure coincidence, it started happening right after performing an OTA of a zigbee device.

12 hours of no power is going to heavily wear the batteries in the zigbee end devices as they hunt for a new coordinator coincell$ :laughing:

1 Like

Luckily all the ones connected to this hub are all 120v!

Edit: connected being a loose term as 0 of the devices have reconnected after 24 hours.

What kinds of devices are these, brand / model?
Have you tried just joining a couple of the closer ones back first and let it settle to see if those will stay on the mesh or not?

Usually the only devices people have issues with dropping off on their own are Xiaomi / Aqara, and there is no fix for those except for getting repeaters that make them happy.

They’re all Inovelli Blue series devices (switches and other).

If I power cycle the switches, they immediately are controlled to the hub. The problem is they only survive for a few hours then the hub stops controlling them.

Is firmware up to date on them? Are you using the Inovelli drivers?
I would open a support request with Inovelli, the device is dropping from the hub.

Man, that is weird to see on a C7 especially (usually the C8s are problem children with zigbee).

So this just started happening recently on a setup that had been otherwise running well?

If true, the culprit has to be a change around the time things took a nosedive- did you happen to update anything on the Blues lately (e.g. I know a new Blue 2-1 driver dropped somewhat recently)? Or a HE platform update?

If you have an idea or two for that, consider backing that update out and seeing if things restabilize? I know that's a PITA, but I'm not sure what else to put on the table...

1 Like

Yes. Most 2-1s are on latest. Fan switches (1 of 5) are updated to newly dropped firmware and a couple other beta devices.

Using Inovelli official drivers for all devices. As mentioned before I’ve had zero issues with the setup until the last week. I can’t pin it down to either a hub or device issue. Just seems crazy it’s a switch issue as they’ve been running on 2.15 for months.

I may just blow out the devices and start from scratch. It did happen right after updating a beta device but it’s hard to identify the issue as the firmware is working solid on other platforms.

Any chance the beta device or any of the Blues are (unintentionally or erroneously) spamming / overwhelming the mesh with overactive reporting?

The only other left-field idea I had was to sprinkle in a couple known-to-be-good ZB repeater devices and see if they could help stabilize that mesh's backbone a bit.

It could. I don’t have a sniffer to check. I would expect other platforms having similar broadcast issues if it was spamming; however, I can’t rule it out.

The hub is centrally located and always seem to have great coverage with the internal antennas. Just mainly wanted to see if there was anything to grab on the Hubitat side before I blow it out and start building the mesh again.

1 Like

I also started having this same issue about a 1-2 weeks ago. It’s like all the bliss just fall off the network (15-20 devices between dimmers and fans). Air gap them and then they instantly work again for a few hours/1 day. I do have lintech pretense sensors as repeaters also. And I’ve also rebuilt the network as swell as powered down for 2 hours. No improvement. As OP said also wave switches are working fine. And I’ve updated the drivers to latest inovelli release with no improvement

Are these the mmWave sensors? Aren't those know to be very spammy?

Check your Zigbee details for total Messages count (since last reboot).


These are my highest

Would help to know how long hub has been running since last reboot (uptime?)
Could calculate a msgs per second number.

But, dang... yes those sensors are probably crushing the mesh.

I would say it’s been 5-7 days sense the last reboot. I’ll reboot it now and post update after 4 hours

I crunched some numbers and I think combined with all 4 sensors it would come out to around 1 message being sent every 10-20 seconds. Thats assuming uptime is 5-7 days, and assuming they are evenly spread out. If they are quiet for a while (like at night) but then spew stuff out in rapid succession at time it could be causing an issue.