@bcopeland - Any chance you'll be testing the 7.17.2 GA firmware in an upcoming release?
Fixed in release 7.17.2 GA
ID # Description
758250 The requested Tx output power on BRD4205B varies with respect to achieved output power.
814263 Non-responsive app due to an erroneously applied SoC errata DCDC_E204.
750117 Large network becomes unresponsive using 700.
818231 800 series OTA using External flash bootloader.
813975 Incorrect bootloader storage slot address in bootloader-slot-configuration.h
763619 Z-Wave controller not ACKing Routed Ack during OTA due to a race condition in the protocol task.
I'm rather interested in 750117 and 763619 as they appear to potentially be relevant to my situation.
Also, question: is the radio power programmable on the C-7? I saw some posts in other places talking about improving connectivity by bumping up the power numbers. Not sure if this would help or not--just curious.
He has it and is testing based on comments in the beta, and previous actions on other Z-Wave firmware releases. No idea what % of his/HE staff time is going to work on the 7.17.2 release, but I would be surprised if it wasn't of high interest to Bryan, Lord of Z-Wave.
True this...unfortunately there were likely some exisitng issues, @Equis, that the FW update process exposed. Totally frustrating right now, obviously, but in the long run you will be much better off w/the Z-Wave FW updates installed.
...and I can't seem to exclude/include anything. I'm sure these are my devices screaming into the void looking for connection (aren't we all?), but why I can't exclude and pair them has me stumped.
Start with shutting down your he from the settings menu. Unplug at the wall (not the hub) for 5 mins. Power back up. Click refresh on each line until the remove button appears. Click remove.
If they don't remove, you MUST power down the devices that made the ghosts. If the devices are powered up, they are pingable and won't remove. You will have problems pairing when ghosts are present. Instead of excluding, factory reset the device.
Any time you have a failed pairing STOP. Check for ghosts. If present, reset device, remove ghost, try to pair again.
I had some device that had a route & everything--but wasn't tied to any device name. As such, I have ZERO clue (and no ability) to know what device it was (beyond being some sort of sensor).
That was rather unexpected. I tried to remove it--and it went away (but with an error because it didn't send an include/exclude signal). Kinda hard to remove a device when you can't tell what it is.
As for devices without routes. I'm seeing that on the new release with battery operated devices that are either not talkative enough OR when their batteries die. Simply addressing those issues (making them jabber and ensuring they have enough battery to do so) makes them pop back on.
This seems like "new" behavior--and, as such, I would caution against taking drastic actions just because a route is empty. I'd first make sure it's alive & trying to talk before doing anything else.
all devices you're trying to remove need to be powered down. Though make sure you do the reboot thing I outlined above first. Once removed, factory reset the device. That said if everything is pooched, you may just want to start over and reset the z-wave radio instead and then re pair each device (factory reset them first) that way you know you have a clean z-wave db you're starting with... If you do this, work your way out from the hub when adding devices and add mains powered ones first and battery ones last.
Just a quick update on my Z-Wave issues... It appears that everything is resolved. I removed all Z-wave devices, pulled air gaps and batteries, reset the radio, then excluded and added them back one by one starting with the line powered switches. It didn't take as long as I thought it would and my topology and routes look pretty good. No more missing paths.
Since I use webCoRE, I define devices as a variable at the top of the rule, so I just had to touch each piston to redefine the device variables in the ones that needed to be replaced. It wasn't so bad.
One bit of sleuthing you can do is generally a ghost is often followed in the Z-Wave page by the same device as a successful pairing (assuming you tried again and succeeded after the first pairing attempt failed). So you can look at the next couple of devices in the Z-Wave Details page as likely suspects...
Hubitat seems to be on about a quarterly major release cycle right now, so if we got the last major update in June, it probably will be September (or late August for Beta testers) before we hear much about whether this is going to make it into production.
Z-Wave firmware updates have been released with point updates in the past for the C7. 7.17.1 was a huge improvement, however, it was only a 95% fix IME.
7.17.2 is supposed to resolve the last 5% of issues so I'd have thought it would be included as soon as it's been validated by the HE team.
...but then 7.18.1 has come out on the heels of 7.17.2, and my expectation would be that they want to reduce the cycles of Z-Wave FW qualifications. Since 7.17.1 was largely very effective (as you note, and as I've experienced) it makes sense for them to get a look at 7.18.1, and then decide if they want to go through two FW releases (7.17.2 - 7.18.x), or jump straight to 7.18.1. If it was my project I'd lean towards the latter, as long as 7.18.1 doesn't look like a hot mess and doesn't try to do too much.
For "large" networks, it sounds like they are working on significant issues >7.17.1. So, I'm excited to try any of them.
7.17.1 seems to help keep the number of hops for MOST devices down to a smaller number. But, it doesn't address all the mesh congestion issues I'm having with my rather large network. And, those are issues I'm excited to see being addressed explicitly in 7.17.2 and maybe above!!
I am really going to test this version of Z-wave. I have a house with a Homeseer hub that I want to convert. It has almost 100 Z-wave devices. I will report back the results next month.
