I've noticed there is not uncommonly a delay in my bathroom motion sensor turning on the bathroom light (same devices in other parts of house and not replicated there). So today when it happened, I pulled the logs for the 2 devices and found this:
Interesting, any ideas? This is in Motion lighting and nothing special in the automation:
The info log is just when the device reports back that it was turned on, likely some time after the command was sent but normally pretty fast. In your case, it seems very long, as you note. A good first step would be verifying where the problem actually is. If you go to "Events" for this device when look for "command-on" in the list (so actually the command, not the event--contrary to its name, this page shows both as of recent platform versions), what is the relative timing?
My guess is that will be fast and you nay have mesh issues to look into, but knowing more will get better ideas with less guessing. 
You are exactly right - on the device's event page, it shows the command on nearly instantaneous. However, the digital event "switch is on" occurred about 90 seconds later. Ironically, this bathroom is adjoining the room where hubitat is located. I wonder if the switch itself needs to be reconfigured or something. It's a Zooz ZEN27, and was under the "Zooz Central Scene Dimmer" and I just switched it to "Zooz ZEN Dimmer Advanced" and hit configure.
It is directly connected @ 100kbps and literally not 10 feet away. I'll monitor under the new driver and then if still seeing issues, I'll hit repair on zwave. Last case I can remove and replace, but if I do remove, can I still perform the 'Swap Apps Device' function so I don't have to reprogram the 15 apps it's tied to?!?
It seems unlikely that the driver could be doing this, but it can't hurt to try the driver you switched to if you want.
Since it's a Z-Wave device, I would start by assuming there is something off with your Z-Wave network, for example, "ghost nodes" that might be causing problems, though it could be a number of things. I would start here for troubleshooting:
Yes, that would work; there are no child devices involved, which is the most notable limitation.
Holy Ghost Nodes, Batman!
I've got 13 rows with blank route information...
On most, if not all, I can't get 'remove' to appear after like >5 'refresh' commands.
I did remove a couple of devices I uninstalled (but didn't remove bc I was planning on reinstalling but put them in another house, doh!)
Also, wouldn't virtual devices have no route information?
Are these real, functional devices? If so, they aren't ghosts (that's just one possible explanation for the above). If they aren't, you might try waiting a bit and trying the above again -- one node at a time if you weren't.
A virtual device won't show up in your Z-Wave Details table, so none of the above is applicable.
I can't tell if they're real or not. A few had the linked zwave device, but many are just displaying the 'device class'. or just the route but no 'device'?
Here they all are...
I just checked another item on the troubleshooting page for locks and noticed "SecurePairingComplete" is only on the Mud Door Deadbolt and not the Front Door Deadbolt. I swear these Schlage locks are so painful!
Mud Door:
Front Door:
If there is nothing in the "Device" column, you at least know you aren't using the device on the hub, so ghost or not (and they probably are), they should be safe to remove.
Functional devices, even without routes, like that first sensor you mentioned, are never ghosts. The route information is updated periodically, not in real-time, and it's reset when the hub (I think? Or maybe Z-Wave radio...) is rebooted, so sometimes it will be blank but normal.
That they are (or at least can be). 
If both locks are working fine, this shouldn't be a problem, though they are supposed to need at least S0 (or S2) to function. Your first lock above looks fine, but the second one looks...interesting. If it's working fine, I wouldn't worry about it. A battery-powered device is unlikely to cause mesh problems (not like it's routing), though if you get bored or desperate, I suppose you could try excluding and re-including (swap it it out with a virtual device first to make updating apps afterwards easier if you want).
Thanks so much for helping me through this @bertabcd1234
I hit 'refresh' on this one, then the status changed to 'pending' and the 'remove' and "discover' buttons appeared. I clicked remove and it just did this for a few minutes and then it times out I guess.
I'm not going to worry about the Front Door Deadbolt just yet, as it's so time consuming to repair them and if not a big concern anyway...
I mean the pretty picture of my mesh looks pretty darn great except for all this.. and the 'Garage Door" is actually pretty far away, at the end of the block and our house is in the middle. I got one of the Zooz repeaters (with power outage detection, very helpful) which it's communicating through.
Ugh, really feel like this is a pretty glaring problem and running out of levers to pull.
@bravenel I think this is what I've been running into with Scenes not completing, etc (you recommended the All Off app, which helped dramatically.)
Any other suggestions/thoughts?
"Logs" might show a reason (not all of which are easily fixable, but...it's something, at least the underling status from the Z-Wave SDK).
For troubleshooting mesh issues, I'd focus on mains-powered devices/repeaters first, as they are the most likely to cause problems.
I ran a full zwave repair yesterday, and there were probably 20 'failed nodes' but not sure how accurate that is (esp considering battery devices, etc)
I see several of the ghost nodes I was trying to remove yesterday still say "Pending" today, and when I tried to "Remove" one of them while watching logs, this was the entry that was recorded:
I hit 'Refresh' once again, no change of course, and then tried to run 'Remove' again and got these new entries:
The no longer in failed node list is normal if the node has more than just the hub as a neighbor (more than 1). Seems to be some sort of bug in the zwave firmware. The busy message is then normal if you keep trying to do things with it after the failed removal. Best thing to do once you start getting the busy message is a shut down and unplug for 30 seconds.
shut down and unplug the hub?
I have thought about killing power to the entire house (network on UPS) and using battery to boot HE. Battery devices would still be present, but quiet theoretically and the mains powered would all be silent.
Yes, just to restart the z-wave radio.
To try and remove the ghost nodes? That wont actually work, its a myth. If they have more than one neighbors listed then it is rare that the hub will let you remove it. Usually gets that same error you are getting. You will need a USB stick to remove them. How To: Remove Ghosts using hub tools or a UZB Stick
Ok, I've followed your incredibly well documented guide on doing this (THANK YOU!) and have removed all the nodes without route information. I am curious though, there are several nodes that do have route info, but don't have a link/device name. I assume this is also failed? Ok to mark these as failed and remove as well?
example:
Yes you can remove those also. Sometimes the routes get stuck in there when the pairing fails and they never go away. If there is a live device attached still the PC Controller wont be able to remove it either because it will respond to a ping. If there is a live device on there, you have no control over it because there is no device linked to it in HE.
Also, not my guide but I had contributed some content to it. Not sure who created it originally but @danabw had a big part in bringing it all together and posting it.
I put it together w/a lot of help/advice/edits from @erktrek, but of course our work on it was based on info provided by many others before us in the forum. So yes, we stole most of it.
I'm not sure what happened but many devices are able to be controlled physically, and will immediately update status to the hub, but commands outward from the hub don't seem to be going anywhere. Including exclusion and inclusion.
Did you happen to migrate from a C5? Seems to be a common denominator in many of the recent z-wave communication issues popping up.
Check this thread out: S2 Authenticated Z-Wave Devices Not Responding to Commands - #40 by jtp10181
Download the Hubitat app
