Thank you for the driver. However I do have one issue with the new code.
Boy you software guys don't seem to like version control.......
Shouldn't the //v1.00 be updated OR change the name of the new one so folks don't over write the old one then decide to keep the "safer" old one?
Sure.. I was in a rush to provide this update as there was an immediate community need..
Does anyone know if I can use the new tool to "downgrade" both components of the switch? I updated both components on my Inovelli Red Series dimmer (updated to 1.47) and now I have the fixture flickering rapidly every time I turn on the switch. I need to revert back to 1.44 or 1.45 to see if it goes back to normal 
UPDATE: Well... I flashed the .bin file one more time and looks like this time it worked. No more flickering 
I don't think I did anything differently than what I did the first time, so not sure what happened.
Has anyone ever successfully updated the Aeotec Z-Wave Extender 6? Mine refuses to show a newer version, regardless of anything I've tried. I asked a month or so ago, curious if anyone has tried since.
I've got a couple of those.
Where do you see firmware data ?
I see this data but nothing is listed as Firmware or Version etc.
Did you update the driver?
If you use the basic z-wave tool you can get the firmware version and it prints it out to the device logs. Mine stays on 1.3 no matter what.
Is there somewhere a cross reference between Name and mfg number?
And between device number and name?
I'm at a loss and looking for suggestions.
I updated one Inovelli LZW31-SN a month or two ago. It worked fine.
I tried a couple of times in the past few weeks, and every time I attempt either LZW31-SN or LZW30-SN updates, I get "Update failed to find a valid target".
Today I decided to try it in earnest instead of just fooling around.
Try 1 - LZW30-SN firmware to 1.11, tried using Hubitat's file storage, but that just doesn't work using either the IP of the device, localhost, 127.0.0.1, or any other connection string I can through at it (though, http://ip/blah/blah/blah.otz of whatever works fine from my PC).
Try 2 - and here's where I get stuck every time. Used files direct off inovelli's site, and now past that.
But every attempt just gets the "Update failed to find a valid target"
I'm probably doing something stupid, like really dumb like ... how can I tell it's a LZW30-SN? It's Inovelli, it's a switch, I bought the red switches (and dimmers too) and they claim in the box to be those, it has scenes (and the delay upon pressing up/down before it does anything because it's waiting for potential double-taps - that the 1.19 firmware just released should fix!) - I mean, it should be the right firmware.... 
I tried going to 1.19, I tried going to 1.16 (thinking maybe it can't jump it too many versions, though I didn't see anywhere int he driver code where that seemed to matter). Neither worked.
I tried air-gapping it and running the attempt again (several times), no difference, still failing to find a valid target.
I tried the "airgap it and run the update right away" trick someone mentioned, but it doesn't matter.
I tried a random other switch, but same problem there too.
What am I missing? I really need to get 1.19 on these 34 switches, and all that starts with getting 1.19 to apply to any of these switches.
I'm a bit at a loss, are there any other hints?
I just sent a message requesting the firmware for the LZW30-SN Double Switch. Would you mind sending the latest one my way, and I can try it on mine? Seems odd that you're not able to get it to work.
I had no problem updating to the 1.19 firmware for the LZW30-SN by excluding from HE and following the process to update from the Z-Wave PC Controller from Silicon Labs. Doing it this way would be a herculean effort for the 33 additional switches I need to do it to.
My terrible coding skills have led me to believe that the culprit is, somehow, that firmwareTargets[firmwareDescriptor['firmwareId']] is null and so this section of code inside function "firmwareStore" isn't being run:
if (firmwareTargets[firmwareDescriptor['firmwareId']] != null) {
Everywhere else I look, there is a firmwareId (one in FirmwareMDReport, and one is set in another function which I debug-logged as "firmwareMdInfo['firmwareId'] was set to 1025" so I know it's there, it's just not making it across into firmwareTargets for some reason.
I also know that inside parseFirmwareDescriptor(List descriptorBytes),
firmwareDescriptor['firmwareId'] was found to be 513.
I have no idea at this point if 513 vs. 1025 is important. Interesting that with integer math, it's possible one is the other divided by two or they're at least really close, or bitshifted once.
Anyway. After excluding the one and confirming that the firmware was indeed correct for this, I am tempted to just remove the conditional check and let it rip, but I'd rather not - it feels like it might be smarter to just set it to what I think it should be, but I'm not yet sure what the target should be.
Still, if anyone has thoughts on what to do, or has a bit more groovy skill to help me figure out how to interpret what I'm seeing, or what I should log/check instead, I'd love to hear them!
Did you upgrade to the latest version of the binary updater? A fix released shortly after the initial release corrected a problem that sounds a lot like this.
It's not as commonly documented of a method, but you actually don't need to remove the switch from Hubitat, pair it to the stick, and then pair it back to Hubitat (re-doing all of your automations along with it). You can just join the stick as a secondary controller to Hubitat. Doing so will give the stick and therefore Z-Wave PC Controller a list of all your Hubitat Z-Wave devices, and you can figure out which is which by matching up the device IDs (use the decimal and not hexadecimal values from Settings > Z-Wave Details in Hubitat). The process is otherwise identical, with no need to re-pair when done. Some devices seem to forget their Z-Wave network pairing on update (meaning you'll need to re-pair anyway), but I haven't seen that with any of the Inovelli devices I've done.
The process for joining as a secondary controller is actually documented in the new C-7 Z-Wave docs but is basically the same for any generation of Hubitat as far as this goes (spoiler alert: it's just regular pairing mode on the Hubitat side). For the other controller, that's your stick, and "Learn Mode" is either "NWI" (network-wide inclusion) or "Learn" on the PC Controller Software (I forget which works or if both do...) unless you're using a stick like the Aeon Z-Stick that can do this on its own.
Use http://files.inovelli.com/firmware/LZW30-SN/LZW30-SN_1.19.otz as the firmware url, with the LZW30-SN you may need to pull the air gap switch between it parsing the firmware and the requesting device to start if you get a please wake sleepy device message. I've updated all of mine this way without issue.
Thanks, @bertabcd1234
I double checked and I am using the latest, assuming
has the latest (I'm not linking directly to that code because I don't know how to tell the markup here I don't want the huge 30-of-the-first-lines blurb put in here.)
There's one set of additional code farther in this post, but it's for a specific problem that I'm not having about segment size, so I haven't tried it.
Just in case, I deleted my existing updater and re-imported from github's raw version, but that made no difference to how it's [not] working.
BUT THE REST!
That's great news, I think I can make that work fine then. In fact, there could be advantages, or at least nerdy stuff, available this way. I think I saw some options to view the topology map and things like that. I'm positive it won't be as thrilling as I'm envisioning, but hey one can hope, can't we? In any case, that'd just be gravy, since the meat was getting these updated.
Off I go on yet another adventure!
Mixed success. Puzzling.
I can update some this way, and not others. I cannot find a particular pattern.
And rather than belaboring a long winded list of what sometimes works, sometimes does, let me ask a few questions that I'll continue researching, but also maybe one of you folks knows the answers to.
Does the update process require direct connectivity between the system running the updating software and the device? Or can it use the mesh to transfer (even if more slowly).
I moved my hub and repaired the network but according to the Z-wave PC Controller software the topology barely changed, and I can find zero correlation between proximity to my Hubitat and if it's red or blue on the topology map.
More on #2 -
The hub was at the corner of the living space, but due to the shape of the house that probably wasn't too much of a problem. What WAS a problem was that when I put the hub where it was, no ductwork was in place. When they added the ductwork, it was a huge swatch of metal between the hub and most of the house. So I moved the hub to the other side of the room in a large gap on that wall so that it should easily have direct contact to an extra dozen or so devices, and ran a repair which took 3 or 4 hours to finish, and yet not a single of those close switches are directly connected to it. So is this normal? To me, this is bad.
11 is in the same room with it, if it wasn't directly connected to the hub I'd be ... flabberghasted.
12 and 13 are 4-in-1 sensors on battery power, both were joined when they were super-close to the hub, one is now completely on the other side of the house and even after a repair still shows it talks directly to the hub. Weird.
38-41 are 4 switches in a gang 10 feet and two walls away from the hub, makes sense it's "directly communicating with the hub"
58 is way the heck on the other side of the house through like 5 walls so I have NO idea why it's directly talking to the hub.
Between (or in) those two latter spots (the group of 4 at 38-41 and #58) there are about a dozen other switches, and there's at least another half dozen that, with respect to interference/occlusion by walls, should be closer even than that group of 4, like literally on the opposite wall of the bedroom wall the Hubitat is mounted on the back side of (slightly farther away than the gang of four above that do associate directly, but through only one wall instead of two and only 3 extra feet. Feels like 1/2 the amount of wall in the way more than makes up for 3 extra feet distance.
But maybe it's mostly normal?
I think I'm going to do some fiddling to make this into a map, or tree, of what talks to what to find out how many hops I have through the network to get to devices that arguably should be directly hanging off my hub.
Anyway, thanks for the answers so far, I really need to get these updated, but ... y'know, this is so far equal parts of aggravating and fun!
Just my personal experience, but I've found that some of my devices, Zooz for example, really seem to flash better when close to the hub. My Inovelli fan/switches and Red Series Dimmers, are all single hops to the hub anyway, so I can't say whether they work worse in a multihop or not.
I think if I had a really finicky device, I'd probably put it in a temporary harness and place it near my hub and then flash it.
In your case with 34 devices, this may not be practical. Perhaps a 100ft ethernet cable, and a USB battery pack could be in your future. Move the hub, do a zwave repair....flash, rinse, repeat. If you were lucky, perhaps multiple devices could be flashed from each temporary location.
S.
That's just the start. 34 that I need to update now, I hope Inovelli will be adding the feature the switches just got to the dimmers soon too, since they've got it working on the switches. Which means another round of 28 more for the dimmers in another month...
Questions on updating and re-pairing Zen27s:
I've upgraded 3 of my installed Zen27s so far. They all lost the z-wave network after being upgraded. The first one I was able to re-pair (as a new device).
But for the next 2 I haven't been able to get them to reconnect to the hub. Any ideas on how to get them reattached?
Also, for future devices, what should the sequence be? I've been told that even though they left the network I should still do an exclude somehow before re-adding them? (for Hubitat's benefit) how would that process work?
Is there a good/recommended way to not have to swap each device in every app/automation that uses them? Perhaps a virtual device? Is it reasonable/possible to have a virtual device in all apps, and then some pairing that maps the real device into the virtual?
The Zooz devices do this by design.
To get them to re-attach, you must exclude them, and then include them again.
The little Zooz instruction book and their website has instructions on making them go into exclude. I can't remember the combination of presses to make that happen sorry.
@aaiyar has a "how to" linked somewhere further up in this thread on the best process for inserting dummy devices into your rules, and then updating the device. It might save you a headache or two.
Good Luck
S
Download the Hubitat app
