Some number of weeks ago I started having serious issues with a small subset of devices (a couple of battery-powered button devices, and one wall scene controller). My setup hasn't changed, other than Hubitat updates (it’s up-to-date, as is the firmware).
But now, nothing I do seems to improve things. Sometimes these device will seem to work reliably, but they'll quickly return to not working at all, or having long delays from button press to lights changing.
The lights all work because I can ask Siri to turn them on or off, and it responds almost immediately.
The troublesome devices are:
• Aeotec NanoMote ("Bedroom Remote," "LR Remote")
• Zooz Zen32 Scene Controller ("Master BR Door Scene Controller")
• Aeon Multisensor 6 ("Office Sensor")
I've tried moving my hub, and even with line-of-site, the remotes are unreliable. The hub is only about 6' away from the door scene controller. I've also tried powering it with different sources (one of the tested PoE injectors and a couple different USB AC adapters).
I let it fully repair the network earlier today, but it has made no difference.
Can you confirm the Z-protocol these devices use? If they are in fact Z-type devices (I'm expecting yes). It my also be of benefit to some if you could confirm the drivers you are using.
If they are Zigbee, have you looked at the Zigbee channel in use on HE compared to any other Zigbee or 2.4GHz Wi-Fi channels in use around the HE hub?
When you say....
Can you describe the steps you went through?
Also, what repeaters / routers are you using? Again others are likely to take something from this, if anything.
I would also suggest zeroing in on the devices themselves, assessing the timeliness of the communications from the physical device to HE, looking at HE logs whilst triggering the devices to assess the speed of HE receiving messages from the devices to see if it is communications from the devices over the relevant mesh network, or something to do with responding to these events within the related automation apps on HE.
Beyond debugging device-level comm's, the next logical step is to look at automation (HE app) level performance. This would involce turning on any logging in the associated apps and reviewing this in conjunction with the device-level logs likely produced as a result of any logging turned on above.
The more knowledgeable z-wave folks (not I) will want to see your z-wave details page in its entirety (use windows snip), and what hub you are using (C4, 5, 7, or 8/8 pro).
@rmann - before making any other changes, put the C8 back on it's original power supply, the one that came with it, to remove any variables from that. Then post your Z-Wave Details page as requested.
I've updated the original post with the Z-Wave details (sorry I forgot to be more specific, it was very late and I was frustrated again by not being able to turn on the light in my bedroom, and have kept putting off asking for help).
The advice to look at the logs was good, and I had actually meant to do that. It's showing much more complex failures than I had gleaned from observing behaviors alone. It seems those few devices are not to blame, entirely.
For example, the button remotes seem to be sending events just fine, but the command to the switch is getting lost (maybe).
I see in my node list there are nodes with no corresponding device. I decided to remove those (by clicking Refresh until Remove appears), but only one successfully removed. The others all spin a bit but remain after clicking Remove.
Following the advice here doesn’t seem to help, at least for node 0x25, for example, as the previous and following GENERIC_TYPE_SWITCH_BINARY are all powered off.
One of my devices (0x14) refuses to show the Remove button no matter how many times I refresh.
Yeah, you have a a bunch of ghosts...see this topic and begin w/the section on the hub's built-in ghost removal tools. Until you remove them your mesh/devices will not function properly.
During the pairing process "something goes wrong" and the device does not complete pairing properly. Looks like a fail, so you try again and the next time (hopefully) pairing completes normally.
What you don't know if you don't look at the Z-Wave Details page when the pairing fails, is that the pairing has not completed (= ghost created). If you catch it and remove it right away it usually will be removed easily using the Refresh/Remove process.
As for what "something goes wrong" means I can't cover the technical details, but something in the Z-Wave communication during pairing fails, presumably due to mesh weakness. Hence the support docs that cover how to build a strong mesh.
Sorry - I'm not the guy for a deep explanation of the techincal details behind my mumbo-jumbo. Maybe @jtp10181 can provide more deets.
Absolutely - confirm on the Z-Wave details page that the entry is complete, and by controlling the device from the device's page after paring it. If it's a bad pair, remove immediately. I also find it can be helpful to shut down/pull power/wait 30s/restore power in the middle of adding Z-Wave devices if you're adding a lot at one time.
Only exception is some battery devices may not show routing in the final column which is usually indicative of a ghost, but not so w/battery powered devices.
Yes that would be best to remove before it gets out of hand.
Also they can be created if you force remove a device from the hub devices list, without excluding it. Then you can be left with a node that is still connected but no device entry. Not really a ghost but would look like it. Also happens if you factory reset the device (or it breaks) leaving the node dead.
Seems like I may not getting more of them .. then ! LOL
I will stick with ZigBee if that's the case ! ( Wipes Brow ) really lucky they paired the first try ! LOL
IMO its not really as big of a deal as people make it out to be.
I always have 2-3 unplugged devices on my mesh, basically same a ghost node. Never causes any problems.
