Just tried updating a ZSE44 to firmware 2.4 on a Hubitat C8-Pro. I just earlier this morning updated the same device from 2.0 to 2.3 and it worked fine. Then saw you were just out with 2.4 so tried that. Gets stuck at starting update and never advances. Since it worked minutes earlier with 2.0->2.3 I conclude there must be something wrong with the 2.4 file. I had a second ZSE44 already at 2.3 and it wouldn’t work to go to 2.4 either, same error profile…
@CuriousB I just want to let you know that all of our firmware files are thoroughly tested before they are published online and made available to customers. That being said, I personally updated one of the ZSE44 sensors in my home to firmware version 2.40 through our Z-Box hub without any issues.
OK thanks for checking. Must be some sort of issue with Hubitat’s firmware updating software. I think it might be some timing issue with battery powered devices.
When you 4x click the button on the ZSE44 how long does it stay awake?
Battery-operated devices only wake up for a few seconds at a time, as required by the Z-Wave specification. However, if the firmware update command was already queued, that short wake-up window when the ZSE44 is manually awakened should still be enough for the hub to begin sending the update and initiate the firmware process.
As a first troubleshooting step, I would recommend rebooting the Hubitat hub. This may help clear or refresh the Z-Wave radio and allow the queued firmware update command to be sent properly.
Just closing out here. My two ZSE44s eventually did migrate to v2.4.
There is something fussy about the interrogation from the firmware tool and the sleep awake mode of the ZSE44 (and battery devices in general) that is going amiss. All my line powered Zooz devices migrated without drama. Battery powered ones seem to be a hit or miss experimentation every time. Unfortunately that lack of certainty tarnishes perception of the products (hub and device).
Zooz appears to wash its hands of this (see above) and the hub guys have as well. Us users will have to muddle along until someone shows some interest in actually getting to the root cause issue.
Thanks for circling back and letting us know the update eventually completed, we really appreciate you taking the time to share the outcome.
What you’re describing with battery devices is definitely a real-world pain point, but it isn’t specific to the ZSE44 or unique to Zooz devices. It comes directly from how the Z-Wave protocol handles battery-powered nodes. These devices spend the vast majority of their time asleep to preserve battery life and only open very short communication windows when they wake. That makes any large data transfer like a firmware update inherently less predictable compared to line-powered devices that are always listening.
In practice, the firmware tool on the hub side has to “catch” that wake window. That’s why you’ll often see the exact behavior you described: line-powered devices update quickly and consistently, while battery devices can feel hit or miss depending on timing and queue handling, which is very hub dependent and network specific. If your hub’s Z-Wave radio is busy with other tasks, the window can easily be missed.
To be clear, we’re not trying to pass the buck. There are a few layers involved in OTA updates, including the device firmware, the Z-Wave radio, and the hub’s update implementation. We actively test and validate our firmware on supported platforms, but the actual delivery mechanism and how it handles queued updates and retries is controlled by the hub.
That said, feedback like yours is exactly what helps move things forward. We’ll continue to share these experiences with hub partners and push for improvements where possible, because we agree that the process should be more consistent and transparent.
In the meantime, the most reliable approach for battery devices is to manually wake the device repeatedly during the update process to keep it in communication with the hub. Not elegant, but it does tend to stabilize transfers given the protocol constraints.
If you run into this again or want us to take a closer look at a specific case, we’re always happy to dig in further with you.
I was under the impression pressing the PCB button x4 quickly woke up the device for 60 seconds, not just a single FliRS beam window.
If it only awakes the device for a single short listening event that would seem an obvious problem. Prone to unlikely timing alignment with the host. I thought for the 60 seconds the device would listen similar to a line powered device, then after 60 seconds it would revert to its sleep awake power saving pattern.
Good question! There’s a lot of confusion around Z-Wave battery powered devices and the wake process.
Bartek created a short video using Z-Wave JS UI, as it’s the best for showing real-time behavior and what happens with the sensor when it is woken and an update is started. Not all platforms expose all of the details in the same way JS UI does. Let us know if you have any questions
OK that was interesting. It seems the wake up does not wake the sensor up for 60 seconds. Not sure where I got that line of thinking. It seems the device just stays awake long enough check in with the hub then right back to sleep.
In this case it would seem essential to start the firmware upgrade then wake up the snsor and not vice versa. If you wake up the device first it will have reverted back to sleep before you press the start button on the firmware download… at the very least a note about this or maybe a help paper on you web site might help folks avoid this problem???
Anyway anyone reading this and using a Hubitat hub it seems the order is important on the wake up vs firmware upgrade launch…
That video from Bartek does a good job showing the process in JS UI.
Just to provide some added color here - I have a bunch of ZSE44’s and have never had challenges with firmware upgrades. However I’m usually doing the upgrades from Home Assistant (JS UI), Simplicity Studio or the z-box.
I have a Hubitat C8Pro here on the bench and tried to push firmware to a ZSE44 from that and it is proving to be a challenge. @hydro311 is more of a Hubitat person than me, so he may be able to shed light on Hubitat ideosynchracies.
I’ve tried multiple firmware update methods in Hubitat to no avail. Even tried joining with no S2, using each of the multiple firmware update methods available, and other things… still no go.
The Hubitat seems to probe the ZSE44 for its current version and sometimes (not always) does it get a complete response. From there the update seems to die, even if waking the device. I’m still looking into it, but I think this is a Hubitat issue. I may break out the Zniffer to dig further if I get time. (Note that I also updated other items like a ZEN04 and that eventually worked but was not smooth, for me at least.)
There also have been some recent changes in the Hubitat world for firmware updates. The latest version now does the firmware update in the Settings, Zwave Details, Device list; whereas previous versions used the updater App or an updater driver. Which version are you on, and which firmware update method are you using? Also are you on ZIP or JS ? (My testing was all on ZIP so far)
Edit to add: Is this ZSE44 in LR mode or mesh? [All my testing has been mesh, and I see there were discussions of issues with doing any firmware updates on LR devices on the Hubitat for a while but that may be fixed now in the JS latest version? ]
Also, just for background, I believe the ZSE44 is a Sleeping End Device, not FLiRS (like a lock might be), so if the hub isn’t keeping the device entertained with a steady flow of packets from the firmware update it may see a pause and go back to sleep. afaik.
I am using the latest beta update from Hubitat for my C8-Pro. As you state the firmware utility is relocated to the /Settings/ZWave_Details page and it has been redesigned and improved.
I am using ZWJS which seems the better supported option on Hubitat now given the EOL nature of ZIP.
I had one ZSE44 paired as mesh and the other as LR. I had troubles firmware updating with each.
I wasn’t aware of the sleeping end device vs FLiRS distinction. I thought all battery devices were FLiRS. As such your comment …“so if the hub isn’t keeping the device entertained with a steady flow of packets from the firmware update it may see a pause and go back to sleep.”… seems pretty important to the design of the firmware update system. Maybe even a simple change to engage the sensor repeatedly once it wakes up would make a huge improvement. Some sort of heartbeat message stream to the sensor.
Exactly. I’m trying to ascertain why this is so different on the Hubitat from other controllers. There must be something it is doing differently. I’ll switch my C8Pro into JS mode before I break out the Zniffer.
I just found a whole thread on firmware update issues on the Hubitat forum (and saw you there). This sounds like a bigger issue than just one device, and seems to span ZIP and JS. Traditionally in Hubitat environments I’ve used Simplicity Studio for updates and had ignored Hubitat’s built in methods, so I am starting from zero on this topic… but I’m a curious guy (as you are by your username LOL)
Yeah, the ZW f/w updater tool in Hubitat has forever historically swung back-&-forth between “Working great!!” to “WTF is wrong with this thing?!?!”, and all that has now been further complicated by an yet-ongoing rocky rollout of JS.
I’m still using ZIP due to some device-level reporting bugs in JS, but I hop over to JS every now & then to check things out, and I go to JS when I need to do a f/w update since the tool tends to consistently work better on JS.
But the latest f/ws for the Zooz battery devices aren’t interesting enough for me to wrestle with update song-&-dance attempt (which is inevitably always hairier with battery devices vs mains-powered ones).
I could not get any firmware update (to a ZSE44) to complete under ZIP. At one point (after a fresh Hubitat reboot) I got it to start and it stopped mid way through the transfer. I could see that the ZSE44 get into a state where it was asking for the same next segment repeatedly and eventually stopped trying. (parse:zw device: 21, command: 7A05, payload: 00 06 FD , isMulticast: false) Not sure why the Hubitat stopped delivering the file to the ZSE44 at the 0006FD segment. I gave up and moved to JS.
Once on JS, The upgrade of the ZSE44 from 2.1 to 2.3 went flawlessly. (I had to wake the device twice - once as I selected it from the drop-down so it could populate the current version number, and again after I started the firmware update itself.)
Then I ran the upgrade from 2.3 to 2.4. This also went without issue. Only one wake was required.
I’m out of ZSE44s to upgrade, but I may try another battery device in the future.
[I’m on: C8Pro, Hubitat version 2.5.0.126, and Zwave JS Firmware version: 7.18.1]
FWIW, on Z-Box, I’ve successfully updated firmware in a ZSE42 800LR Water Leak Sensor–which, even though it’s a different model, is (I believe!) a sibling of the ZSE44. It was configured as an LR device at the time.
Yes, that’s right. Otherwise, it would chew through batteries faster than you would imagine.
There’s nothing wrong with the firmware file, that’s for sure. The upgrade process on Hubitat with ZIP is outright broken in recent releases and your best bet is to use ZwaveJS on that platform to do an upgrade. There’s been little interest in fixing it and as others on this thread may note, the community is happy to repeat unsubstantiated blather about busy networks, distance to hub etc when scientific experiments and outcomes clearly indicate it’s something about the ZIP upgrade implementation. I gave up and run ZwaveJS now and haven’t looked back. (The team was super helpful on fixing it for JS though – that process is getting love and seems solid with the improved UI now)
I run Hubitat with ZW JS. Firmware upgrades for Mains powered devices work very reliably. Battery devices are not so good. There is far too much trial and error getting the device to wake up at the moment the firmware tool needs it awake. So ZW JS may be much better than ZIP (on Hubitat) it still has serious gaps related to battery devices and firmware updates.
