The main focus here is how to get the firmware updated and the device back on your network with minimal hassle AND without breaking any existing setups or integrations! I am assuming you are already familiar with how to update the firmware itself (or find the instructions for that process elsewhere).
I have a Hubitat C7 and keep updated to the current firmware. Firmware as of this writing is 2.2.8.156. After trying various things on the first device, I then just performed these steps on 4 devices without any issues.
If your device is paired with S2 Authenticated security, you will need the 5 digit DSK from the box or it is also on the device itself under the cover plate.
Updating the device
Get the firmware - you will need to request firmware updates from Zooz via a support ticket
Install the update - This can be done from the hub itself (using the built in App, or custom driver). Optionally you can use a USB Stick and update from a PC which is what I use because it seems to be more reliable.
Getting it back on your network
I have had a few Zooz devices come right back after an update and a power cycle. Most newer devices you can just try running a Configure to set the Lifeline up again. This will probably bring it back online! However much of the time on older devices the firmware update performs a factory reset so you have to join it back again.
Open a log window on a separate browser tab / screen.
OPTIONAL Power Cycle the device - either pull the air gap or reset the breaker. This step seems to help but I also tested without and was able to get the device to pair again.
On Hubitat go to Settings > ZWave Details - then click refresh on the updated device. The page should refresh you should now have a replace button for that device (if not try to refresh again).
Be ready to get to your device within 30 seconds and CLICK Replace ONCE. It should show you a Replace is running message.
Wait about 10 seconds before the next step (trust me it helps)
Put the device into pairing mode (typically tap up x3) - led should flash continuously
Return to the Hubitat interface, if you have it paired with S2 you will get a prompt for the security code. For S2 Auth devices you need the 5 digit DSK. For S2 Unauth I just put in 00000 and that worked to get past the screen.
After that it took me back to the "Replace is running" not sure why, so I just backed out back to the device list.
BE PATIENT - it takes up to around 30 seconds and then I would see the configure stuff run in the logs. After that was complete the device was operational again.
Check your settings, this seems to reset some of the settings back to the defaults (especially the toggles at the bottom such as info logging).
That's it, should be fully operational again and continue to work with any rules or integrations.
Troubleshooting: This is just a general list of things that might help if you have problems
If the device does not want to pair again, you may need to manually do a factory reset. Check the manual as it is not the same for all of the devices.
If the Replace fails multiple times you may need to put the Zwave and device into Exclusion mode to clear the device out and then try the replace again. DO NOT remove the old node.
Powering down the hub and unplugging it for about 10 seconds will restart the ZWave radio and can resolve pairing issues.
Swap Apps Device:
If all else fails and you cannot get the device to pair up with a replace (or you have an older hub). Pair the device as a new device then use the Swap Apps Device feature found in the Settings page. Once you do the swap, the old device can be forcefully deleted.
Detail questions about this, since I've been using the tried-and-true technique of pairing the updated switch as a new device and finding all the apps/dashboards that were looking to the old entry and updating as needed.
I find the factory reset must be performed manually... are you saying that simply pulling the airgap will do the same?
Does the re-paired switch have the old z-wave node ID?
Do you notice anything funky in the z-wave routing tables, or does everything resume right where you left it? (I ask because when I update too many switches in too short a time my z-wave mesh gets cranky for a while)
On the ones I have done thus far, a ZEN26 and x4 ZEN21 I only did a factory reset on the first ZEN26, and that one gave me the most trouble afterwards. Three others I did a power cycle since they were all on the same breaker. The last ZEN21 I didn't feel like figuring out the breaker so I skipped that step and it still worked! I believe after the firmware flashes it automatically does a factory reset, but it might not hurt to do it again if its not working. EDIT: Just did a ZEN27 also, did the flash, let it sit for a few minutes and then did the replace. Worked first try. No power cycle, no reset.
Yes, thats what the "Replace" feature does.
So far so good besides that supervision seemed to be working but now it acting up again so I shut that back off on my driver settings.
Thanks for the guide, it helped me a lot when I was updating the firmware on my zooz devices. I updated my ZEN26 to 3.41 which seems to have fixed supervision support. However my ZEN21 running the latest 4.04 is still experiencing the same supervision issues (switch status does not update when toggling using command). Are you seeing the same on your ZEN21 devices?
What is Supervision support? I have Zooz Zen 73 switches that I am having terrible latency issues with. Like if more than one device is acted upon (turning multiple devices on or off with an app), the Zooz devices can take up to ta minute to respond (if at all).
Yeah I updated all of mine and I thought it was working, but after a few hours I noticed the same problem so I turned it back off. I am going to take a deeper look at my code also, and then report back to Zooz or you can start a ticket with them as well if you want.
Supervision is a way to confirm the device got the command that was sent to it and also if the action requested was carried out or not. Your issue is most likely from issues within the Zwave mesh/network. I would post a brand new thread with the symptoms and some screenshots from your Zwave details page. There are a lot of members on here who love troubleshooting that stuff and will jump in with ideas.
Thanks for the tip on the Replace method! I'll use this method the next time a device factory reset messes up the linkage.
I've updated a number of my Zooz switches via the built in hub app, and one thing I've found is that firmware updates are incredibly slow if the device was included with security. I tried a few times, but I estimate it would have taken over 20 hours to complete, and this is with a good direct route to the device.
I now include all Zooz devices with no security, and the firmware updates are about 20 minutes max.
For what it's worth my ZEN26 w/ S2 took 30 minutes to update while my ZEN21 w/ S2 took like 16 hours. Both are direct connection. The ZEN21 is a little bit further from the hub than the ZEN26 so that's probably why. I think the biggest factor is distance.
If it has a direct connection then I don't think distance would come into play, assuming you have more than just a few devices. But if the connection speed (on the zwave details page) is low then certainly that would cause the long time. I haven't been able to update any of my ZEN72 or ZEN34 devices when they're using S2, it's just way too slow, like that 16 hour one you mentioned. You could try it with no security to see if the speed is better.
After several much-slower-than-expected experiences using the built-in updater app I've concluded that it's not ready for prime time. I've gone back to using my z-stick and the PC Controller software. The z-stick is in a laptop, so I always have it right next to the switch I'm updating. Time to completion is in the 5 minute range for Zen 26/27 devices (I've done a couple of dozen this way).
It is accepted (unfortunately) standard to not send a report when using supervision.. They figure supervision report should be sufficient and you should assume that it worked.. I have seen this behavior in many devices now, but not all.. I’ve resorted to sending a get command after the set to insure that I get a report.
I never noticed this until I started using supervision widely.. And it is actually an accepted practice in the standard.. I think it’s crazy to trust a supervision report as there are other factors that can affect a difference in the set from the actual state..
Good to know, I was sort of hinting at that with Zooz support if that's why it was doing that since I am not an expert on the rules of ZWave. The issue I had was SOME of their devices send the supervision reply AND the status report, and others were just sending the supervision reply. That makes it really messy trying to make drivers. So, they caved and said they would fix the ZEN21 and 22 to match the other devices which send the status report back.
Meanwhile I was contemplating if I should just trust the supervision reply as verification, but it would be a huge PITA because the supervision reply doesn't tell you what command it was, just the session number, so you would have to dig in the saved packet before clearing it out to see what command was sent and then post the appropriate event to the hub from there.
FWIW I still cannot get this supervision stuff to work all that reliably, not sure if its the implementation or misbehaving devices or just my zwave mesh that works good only when it feels like it.
Maddening .. Isn't it? .. It's not just Zooz.. It a LOT of devices..
From SDS13783:
It is OPTIONAL for a receiving node to return an answer to a Set type Command which requires a response to be returned if received with Supervision encapsulation.
Your welcome I have been working with them about it and send them multiple log files showing the issues to help fix it, and they just sent me the update yesterday as well.
There is one small issue still that effects I think most of the 2x models, if you send multiple on/off commands less than around 1s apart it gets all confused and does not send back the replies correctly which then confuses the driver. Same scenario works fine on the 7x switches. I think the only time this would happen though if is you have a rule to flash the light at a quick interval.
UPDATE: Still having supervision cause inconsistent results in my ZEN21 that I upgraded to 4.05, so at this time I can only recommend using it on the 7x models. Working with Zooz to see if they can fix it.
I have been working with them about it and send them multiple log files showing the issues to help fix it, and they just sent me the update yesterday as well.
