Seriously, it took me almost 30 minutes, but I didn’t have to start over. It may be because I’ve got a fairly small Z-Wave mesh, about 30 devices, and 8 are repeaters (6 Ring Extenders Gen 2, 2 Aeotec RE7).
From the thread that Bobby pointed to, the key step as recommended by HE was to sit on the Z-Wave page for several minutes (some waited as long as 10) before starting the update. Launching the Z-Wave Details page results in a lot of background actions, and you want those done before you try to start the update. Of course, YMMV.
2 Likes
Not my experience at all...
I have two C-7, both got the ZWave firmware update as soon as I could get it and it went smoothly. Both finished rapidly... probably less than a minute.
Obviously 50% is the download. The actual write to the SOC (Zwave radio) was completely missed the first time since I had never seen the process before and the 2nd time was equally unremarkable and so there was nothing to memorize 
2 Likes
My kept locking the page up when i clicked on firmware update. I waited as long as 5 minutes before deciding to refresh the browser.
I need to sit on page longer?
1 Like
Using latest Chrome browser
Try keeping a log window open.
It could take over 5 min.
How long did you wait on the Z-Wave details page doing nothing before you tried to start the firmware update.
I didn't wait at all. I went to the page and clicked update. Took around 10 minutes to update. Did both my hubs in the same way. Both my hubs have vastly improved zwave performance now.
1 Like
Like me, you're one of the lucky majority that is able to update without issue.
2 Likes
I did update the Hubitat Z-Wave firmware a couple of days ago.
it is interesting that I got an email from Inovelli telling me "There have been many problems with the 700 series controller chips that are in several Z-Wave products, but Silicon Labs may have figured it out" and suggested I was sure to have updated the Z-Wave Firmware for the Hub. As mentioned above, I did that. However, the update had the opposite result as many of my Inovelli Red Dimmers got faster, and some much faster, from 9.6 to 100, but 2 of my Fan + Lights, which have 700 chips vs the 500 chips in the Red Dimmers, got much slower going from 100 to 9.6. This seems particularly disturbing to me as one is in the same room as the Hub so I have no idea why it not only slowed down, but also no longer is connecting directly. Here are before and after screen shots:
This is the one in the same room as the hub:
Before:
After:
Here is another Fan + Light that got slower:
Before:
After:
This is a Fan + Light that was, and still is, slow:
Before:
After:
This is not a 700 chip, but is an Inovelli Black with scene control.
Before:
After:
Slow connections are only a problem if you see an actual problem w/device performance - significant delays, etc., that affect your devices/automations. I had a device (light switch) that was a 9.6 for months and months, probably years, never had a single problem w/it not performing normally in automations. Unless you see an actual issue best to ignore what you see on the Z-Wave Details page. Being patient now and waiting several more days would be what I'd do right now.
Options if you are having performance issues w/automations/devices after the update:
- Wait longer...z-wave mesh updates may take a while to settle in further
- Shut down the hub and then pull power (at the plug, not the hub) and wait five minutes. Then reconnect power and fall back into the several-day waiting game.
- If you want to you can run individual Z-Wave repairs on devices w/slow connections. Then wait several days to see if things change.
- You could als do a whole-meshZ-Wave Repair (Z-Wave Repair button at the top of the Z-Wave Details page). This used to be a dicey approach but seems to work w/out messing things up now after the update.
If it was me, I'd wait several more days. If then I'm sure I have an actual problem that needs addressing, try 2-4 above.
2 Likes
So 7.17.7 fixed another problem for me today - I had an Aeotec Recessed Door Sensor Gen 5 that refused to report battery percentage. I was going to send it back under warranty as it's just never worked 100%.
Anyway, I replaced it with an Aeotec Recessed Door Sensor 7 today and was just having a play around with the old gen 5. I thought I'd try updating the FW but couldn't flash it with my z-stick. So I re-paired it with my C7 and I was shocked to find it works 100% now! Battery reporting and all! 
WTF, I'd removed and re-paired it several times previously, however, under 7.17.7 now it works perfectly! Bizarre!
2 Likes
That's great. A device saved from the scrap heap is always a nice thing. And now you get to choose another door you want to drill holes into. 
3 Likes
Yep, the external laundry door just got an upgrade! 
4 Likes
I will give it a few more days to see if the situation improves, but it does seem strange that it is primarily those switches, which are 700 series, that went down.
In any event, I was thinking of moving my hub to a different room. In my den I have one of my TP Link satellite units of my wi-fi mesh routers. It has an extra RJ-45 internet plug on it, so I could plug it in there. I could also then mount the hub high up on top of a credenza unit I have in that room. While I do have a fairly large picture in that room with glass on it, there is no big mirror in my den like there is in the room with the hub, So my questions are:
-
Is there any harm in moving the hub (assuming I gracefully shut it down and unplug it from the plug, not the hub)?
-
Is there any reason I couldn't/shouldn't plug it into the wi-fi satellite unit? (In fact, could that be better as it would be further away from the modem and other devices plugged into the router?)
-
If I do that, should I run a Z-Wave repair or just give the hub a few days to sort itself out?
Thanks,
No harm to move the hub physically if you do as noted, shut down, unplug from wall, move to new location.
As long as the wi-fi sat is a reliable connection that you are OK trusting your home automation to, you can move it. Wi-Fi is inherently less reliable than ethernet, so I always prefer to keep my hub connected via eth.
Any potentical "harm" related to mesh/devices will be them needing/wanting to re-route after the move, both Z-Wave and Zigbee.
Zigbee you can force by shutting off the hub for 20m when you do the move. That causes "panic mode" and forces the Zigbee devices to find routes to the hub again.
Z-Wave Plus devices should re-route on their own over a few days or so as needed. You can try to 'nudge them' by doing individual device or full mesh repairs.
Depending on how the move affects existing device routes you could create issues where devices (esp repeaters) that had good routes could end up less favorably connected, and repeaters that handled some devices might be in positions that made those routes/repeating less favorable. So you could have some issues w/Z-Wave performance for a bit as things settle.
As long as you're moving the hub, you should think about mounting it vertically vs. horizontally, as the hub position can affect performance overall. See this post:
As noted previously, wait a few days and see how things settle before you make any other big changes like moving the hub. 
1 Like
I think you can speed this up so you don't have to wait.
Here's what I did to speed up the process . . .
I set up a group in the Groups and Scenes application consisting of pretty much everything (about 75 devices). I set this up with On/Off Optimization turned off and without using the "metering" function. The goal was to flood the Z-wave network with as many commands at once as I could to force the devices to figure out new "optimal" routes that would work even in high activity scenarios. I then did several On / Off actions on that group and found that, for the first attempt or two, a few devices were "missed", but after doing this several times, everything seemed to respond. I had also checked / compared the z-wave routes on the "z-Wave Details" page and noted that there were route changes.
1 Like
Thanks for the reply. While the various satellites of the wi-fi mesh do talk to each other via wi-fi, I would be plugging the hub into the satellite via an RJ-45 lan cable. I'm getting about 100 MBs from the one I would be using.
When you say to place it vertically should the cables be facing the ceiling or downwards? Also does it matter which direction the "face" (where the Hubitat symbol is) is pointing (what would be the top normally)? If most of my devices would be north or south of the hub should the face be facing north or south, or turned 90 degrees so the face is facing east or west?
BTW, I saw the article you referred to but I couldn't really tell the difference in the pattern. (And, BTW, the image didn't appear in your reply above, but that's fine).
Hopefully the link I provided took you to this post, which includes images showing the patterns depending on the position. I have mine hanging w/wires going upward from it - that change resulted in more 100 connection speeds for my devices.
@csteele may have more comments on the effects of different orientations...
It's worth keeping in mind that Z-Wave doesn't try to improve a route that hasn't failed to work (even if it only works eventually after several agonizingly slow retries). So if your Z-Wave devices are working reliably on a route thats at 9600 bps, you can wait forever and nothing will change,
As SiLabs has points out in their routing tutorials, Z-Wave doesn't learn or self-optimize (that's a Zigbee thing). It will stick with even the most unoptimal, slowest route forever as long as it keeps working, even if it takes multiple retries to succeed.
But it does try to recover from outright failures. So in the absence of multiple message delivery failures on the current LWR (which then results in trying another direct, pre-calculated, or explorer frame derived route) you need to do something like single or multiple node repair (or the nuclear option, exclusion/inclusion) to get anything to change.
5 Likes
