Is there any way to hope for a future update implementing at least a simpler removal procedure of those ghost devices or is it beyond what the technology will allow?
Is the system showing something that was hidden before thus explaining faulty zwave networks or is this entirely due to the new architecture of Z-wave 700?
Most likely this. As I understand it (I'm not an expert in this area) the hub can only ask the SDK to do the removal - after that it is all up to the SDK, and we have basically zero control over that part.
The SDK could be improved in the future, but I don't think future SDK features are published by the zwave alliance - so who knows?
"Failed node 09 remove status: 2" this makes sense when the device is powered.
"Failed node 09 remove status: no reply": this makes sense when the device is powered down.
"Failed node 09 remove status: 2": this makes NO sense when the device is powered down.
What am I missing? Just trying to understand. the "no reply" one is not listed in the SDK doc, although seems quite self explanatory.
This means the SDK didn’t even respond to the request.. Usually happens if another management task is underway.. In 2.2.8 thus process will be a little better as it will react and re-attempt when this happens.. It will also translate these codes..
**peer review needed**
There's definitely an issue with current SDK anyway and I think I have started identifying it: ALL 1st Generation Z-wave have issues pairing and ALL Z-Wave plus pair without issue. It really looks like it is a backward compatibility issue.
All non-Zwave-plus devices will SYSTEMATICALLY take too long to associate, thus generating a ghost device and making it EXTREMELY DIFFICULT to migrate from C4 or C5 to C7.
I just ran the test: excluded one of my CT thermsotats, 1 of my old Aeon Energy Switch from one of my C5's, reset them, re-included them on my other C5 hub and then exluded them again and then tried to include them on my C7... C7 will simply NOT FINISH the initialization EVERY TIME it's with a non-Zwave-plus device, purely and simply... It took some serious time to run that test because everytime I had to delete the ghost devices. Then, I did the same with zwave plus devices, everything went smoothly.
Can someone attest to the same results? I think we need some serious peer review on that one for Hubitat's staff to finally acknowledge the problem. I have spent one week already on this device and still no go...
It would be really awesome if a couple of our community members could attest to the same results or refute them: please, don't refute from a theoretical stand point, try it before you tell me that this product works properly under the condition that every consumer be a wealthy geek with a lot of free time and willing to spend days on this before it works.
**NB: This does not happen [at least not as systematically] when the device is closer to the hub or after a fresh reboot. If you are to run the test please make sure you did not just rebooted your hub and that the device is in the place where it is supposed to be.**
Here are the steps:
1) First take one of your non-plus devices and exclude it (whether it is from your current C7 or from a C5 device shoudln't matter. However, make sure it is a device that is not in the immediate vicinity of your hub and keep it there, don't move it.
2) Do the same with one of your z-wave PLUS devices.
3) Reinclude the non-plus z-wave device. You might have to run several attempts but the important thing is to not, ever, trigger its association more than once. Press its association button only once while the hub is in inclusion mode. Let everytime the hub finish the whole 60 seconds association process, whatever the result.
4) If after 3 attempts you still don't see your device, reset your device or re-exclude it (preferably from a z stick or another hub) and then start over.
5) At some point you should see that your C7 hub saw the device and started the initialization, without being able to finish. Then, congrats, you have generated a new ghost device.
6) Get rid of the ghost device:
a) cold-reboot your hub (shutdown, unplug, wait 30 seconds, power it back up) then :
b) Unplug / power down your z-wave device so it doesn't attempt to communicate with the hub
c) standard exclusion, refresh the ghost device, hit remove*.
*see the stupid message in the logs stating that an obviously failed device is still not failed (status 2) thus not removed (that one makes no sense... this hub creates a ghost device but returns that device is not failed when you try to remove it... wonder who coded for this policy but must be another Dunning Kruger...).
d) Hit refresh as many times it takes until the device is detected as failed and removed by the system. If this doesn't work, start over from step 6a (and if is still doesn't work, like me, just build a rocket and send you C7 into orbit...)
7) Now, wait for several hours and let your hub work as usual. After a couple hours, reinclude your Z-wave PLUS device and see the magic happening.
If you get the same results as me - meaning you have to go through steps 3-6 with a non-plus device while have no such issue with a zwave PLUS device, then this will demonstrate that there is a serious backward compatibility issue with this new C7. Hubitat will then have to attend the matter because, for now, I only hear that I am bad at doing things the proper way (which still is true sometimes) when it obviously doesn't work as it should (beyond the mistakes one might make and WILL MAKE).
**For those who want to answer that association should always happen near the hub**, please remember that A z-wave device, contrary to a zigbee device and from what I understood and read, should be associated from the place where it will be and, anyway, this can't be reasonably asked for some devices such as in-wall devices or wired thermostats
This is true for Zigbee, too. But many classic (non-plus) Z-Wave devices don't support network-wide inclusion (NWI) so may need to be paired near the hub. Perhaps you have this backwards? It would explain some of what you see. I've had occasional pairing problems with Plus devices, which most of mine are, no matter where they're paired--so my success with Plus isn't 100%, though pairing problems were rare (still not saying they weren't frustrating). I'm not sure I have enough non-Plus devices to comment either way, and FWIW all of my remaining ones are battery-powered. I don't remember any stark contrasts between the two beyond the above characteristics.
The contrast is very clear to me. It's just systematic. I Can encounter some issues with plus devices, but not the kind that creates a ghost device that requires an hour or so of work per device in order to be resolved. That's a lot of hours spent when you have several dozens to reinclude. I have updated my messages with some steps to take if you want to run the test on your end, the only ture way to test my theory.
update: I'm having the same issue with all sorts of Z-wave devices, plus and non-plus now.
For every device I want to associate, I have to reboot the hub and that's because the z-wave network gets stuck a little while after booting.
A repair right after reboot will work for most nodes. A repair something like 10 minutes after a reboot will show all nodes as failed. All of them, no exception. After a successful repair for all nodes (providing several reboots), all nodes will still become unreachable after 10 minutes or so. This is very frustrating.
I am in as well on the beta. I have one ghost that I have tried ererything that I can think of to get rid of it and no luck. I get either a no reply or a status 0. The refresh gives the status 0 and the remove gives the z-wave busy then status no reply. Maybe 2.2.8 could remove the ghost. Thanks.
Just wanting to add my 2 cents to this discussion. I have recently migrated from my C4 to a C7, When re-including some of my Z-Wave devices I got some ghost nodes. When these occurred, my system was really unstable and laggy, filling up the database quickly. By following the exclusion guide with the UZB stick seemed to work for most, and my DB stabilized and the HE has been working well.
Then this evening I wanted to add a Danalock V3 and upon initial include, it only came in as a Ghost node and did not prompt for the S2 information. After several attempts, I was able to exclude it again and I then fully reset the lock and tried including again. This seems to have done the trick as the lock is now correctly included and seems to work with the Generic Z-Wave lock driver. The HE is also stable (at least for now).
Not sure what to conclude from this, but maybe this gives some information to HE to work with ?