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.
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!
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?
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.
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.
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.
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.
Thank you for that. Do you know if it would make a difference in the direction the logo is pointing? (That is the face that used to be to top)? I’m asking as most of my switches will be roughly on a line north and south of the hub. I live in a one floor condo so I don’t have to worry about it going up or down to another story.
It seems as though 7.17.1 as dramatically improved the Zwave network , especially on group lighting scenes where 5+ lights are turned on/off at once.
Has anyone played with the metering in larger Group Scenes yet? I know metering was added to Group Scenes some time ago to try to give the Zwave network time to pass the commands and acknowledgments back and forth but wondering if anyone has found if it is necessary any longer after 7.17.1?
I have a client with a large house and many large groups to turn lights on/off that has always had problems. I cant just go there and check easily but I can remote in and makes changes so that is the reason for my question. @bcopeland ?
Another thing that can help after major mesh changes (like moving the hub) is going to each sleepy device and waking it up as well as activating any device with a physical switch/button so that the devices can discover if they have bad routes.
Music to my ears. 10's of hours spent over the last 2 years on C7 deployments with ghost nodes and ack issues. Cant believe it took silicon graphics that long to fix the issue but happy they did.
I tried hitting things pretty hard with a scene and no metering after the upgrade.
Most of the time, things seem to work far better (even with no metering). In testing just now, however, I was doing some "all off" and "all on" scenes--and on one ouf of maybe 4-5 tries, it only got about 1/2 of the devices set. Trying again after maybe 20-30 seconds, it really didn't do much better. I did a "refresh" on all the devices and tried again--and it seemed to behave that time.
So, at the moment, about the only outstanding issue I regularly have is my "Dual Controlled Dual Dimmer" Jasco outlet, where the FIRST (-1) device is not reporting updated status properly. It takes an explicit refresh of that device to trigger that to report back (it appears that a "refresh" of the parent device also works--but I can't find a way to call the parent's refresh from an RM rule). I suspect this could be a "race" condition in the driver.
@bcopeland
My business partner has a good question. What would the results have been pre- 7.17.1? There is no context to the numbers until we understand the rough numbers before the new firmware. This would give us a better idea of what the improvement actually is.
