Multi-Gang Firmware Updates

So I have somewhere around 16 Red Series dimmers with another 20 on the way and I’m finally getting around to updating the ones that are currently installed. I use the Z-wave updater in Hubitat. I’ve searched the forum for this observation, but haven’t really noticed anybody posting about my observation. It seems that the preferred solution to a failed / slow firmware update is to move the hub / controller closer to the switch being updated (which would increase signal to noise ratio between the hub and switch). However, I’ve done fine with updating through the mesh to the “far” switches. The pain point on firmware updates for me is actually the switches in the middle of 3-gang and/or 4-gang boxes. These “inner” switches seem to go painfully slow or fail the upload. I haven’t bricked any switches on a failed upload (which is good), but am not sure if there are other SNR concerns to help in this scenario (e.g. have hooks in the firmware to have non-updating switches decrease their transmit power), or if my observation is unique to my 120 year old house that is chock full of plaster and lathe.

I can’t comment on the efficiency of the built-in Hubitat updater, but there have been many posts here regarding issues via that technique. You might want to look at using SiLab’s PC Controller to flash. It’s a PC application that uses a USB Zwave stick plugged into your computer.

You remove the switch from your hub, exclude it with the PC Controller, flash it and then re-pair it with your hub. I just did one today and it took me less than 20 minutes. Of course, there is additional time (at least with SmartThings) putting the switch back into routines, rules, etc.

@AgentMethod will probably agree with me. He just used the PC Controller after killing a day with the built-in Hubitat one.

Absolutely! The hardest part is figuring out the software. Download Silicon Labs Simplicity Studio and then follow the instructions here:

I don’t think you have to install the whole Simplicity Studio, right? I think you just d/l it and just install the PC Controller. I have my install file from when it was a standalone app, so maybe someone who has recently installed can post the abbreviated steps.

I think that we’re in agreement that we’d expect the USB Stick to perform better, I think we diverge on why that is the case. You both cite the unknowns in the software that performs the update via Hubitat vs. the USB Stick. What I’m trying to point out is that bringing the piece of hardware that is updating the switch closer to the switch in question is what is actually increasing your success rate. It seems odd to me that in three separate 3-gang (or larger) boxes, it’s ALWAYS the inner switches that are giving me problems while the outer switches are performing the update in that under 20 minute metric (and I don’t have to exclude / re-program rules to boot, so for my outer switches I’m arguably faster than your exclusion & reprogram solution). Point being, the difference in distance between my hub and any of the switches within a multi-gang box is negligible.

1 Like

Does anybody know if the air gap switch turns off the Z Wave radio? Or is it just power to the load as the product manual describes?

To test out my theory, I might want to air gap the outer switches when updating the inner switches…

Air gap shuts off the device completely…I think. The whole device goes black for me so I assume the radio goes dead too.

I had great success just adding the zwave usb as a secondary controller on Hubitat. Then I use software from Si to update each switch. This avoids having to exclude, include, exclude and include back into your house zwave network.

1 Like

I don’t think it does. I just pulled the airgap on one switch and flipped the breaker on another. The one with the breaker flipped showed as offline within 2 minutes and then back online within 2 minutes of turning it back on. The one with the air gap pulled showed online still after 15 minutes. (SmartThings)

Interesting because all these folks with issues are using air gap to reset the switch to fix the switches. Maybe it only resets the brains or MCU but keeps the radio portion active? Hmmm I’m switchless at the moment so not if any help so @Bry is probably right.

That’s a good point. My test was admittedly unscientific. @shawnballs idea is worth a shot, though.

What device handler are you using for your dimmers? If you have the one Inovelli has referenced on their support pages for SmartThings (installed from GitHub), sets checkInterval to 10920 seconds (over 3 hours) but doesn’t have the Health Check capability, so it won’t go OFFLINE until ST gets no activity for 24 hours I believe.

The (recently added, I think within the last year) built in handler (named “Inovelli Dimmer” sets the checkInterval to 1920 seconds (32 minutes) before it will be marked offline.

Depending on how you added your device (if it got set to a generic Zwave, then changed) your checkInterval could be other values as well.

Check your IDE device details and see what your intervals are set to, if any. That will answer your “when would it show OFFLINE” question. :slight_smile:

I believe pulling the airgap kills power to the entire switch. Why would you leave the radio powered otherwise? How would you ever reset the radio without cycling the breaker?

Note to @EricM_Inovelli, why do the Inovelli custom DTH’s not use Health Check capability? They did at one point, Health Check is commented out…

1 Like

Doesn’t make sense to me either. I just tried excluding via the switch with the airgap pulled and it didn’t exclude, so I’m guessing the power is cut to everything.

1 Like

Interesting. I’ve been updating these things remotely so I won’t have a good data point until I can physically pop the air gap switches. I might be able to do it tomorrow, otherwise it could be almost a week. I’ll try to keep you guys posted on testing my hypothesis.

At one point, SmartThings was having system issues that would show the device offline even though it was not. It went on for weeks so we removed the capability. We were getting many support tickets where users where saying our devices kept going offline. Granted, it was a long time ago. I think it was shortly after the Health Check capability was released. As early adopters, we were one of the first to have it. So, it made us look bad when other manufacturers did not implement the feature, but SmartThings was having issues showing our devices as offline. “My Inovelli devices are the only ones that go offline” was the common quote in the tickets. We could probably add the feature back in now, but honestly I still don’t trust it LOL. Has anyone had issues with it recently on other devices?

1 Like

I jumped ship from ST after a bunch of outages. Running HA now. No turning back.

1 Like

Makes total sense, thanks for the insight! AFAIK Health Check is pretty stable at this point. It was moved to local processing for hub based devices (zwave/zigbee) away from the cloud some number of releases ago. I had this bookmarked about some of the more recent details:

I use it for all my custom DTH zigbee/zwave devices and its never shown devices in an incorrect state. Well, unless the ST mobile app is acting wonky, but that has nothing to do with Health Check.

I hear ya @stu1811, I’m using ST in 2 locations and am really hoping that the Edge infrastructure breathes new life and resources into the ecosystem. Looking forward to Inovelli’s Edge drivers as well.


It’s interesting, I never hear anyone going BACK to ST after transitioning to HA :smiley:

I did the same and have zero regrets. I still pop in every month or so in the community to assist from my past experiences, and I still get the status emails (and laugh a bit in my head each time), and wish them the best from the greener grass.