Since upgrading to the C-8, I'm seeing this occur several times a day: [sys:1]2023-03-15 23:28:44.731 [warn] Z-Wave Network responded with Busy message.
My C-7 did not experience this, and if it was just a log entry, I'd ignore it... but there are messages that aren't being sent as a result. For instance, my dehumidifier was supposed to turn off at 17:30 yesterday, but was running until I noticed it at 23:30... the logs show where the command to go "off" was sent, but it didn't get to the device.
Is there an issue because more devices are connecting directly to the hub that it has a buffer filling up too quickly?
I've turned off as much monitoring as I can -- again, this all worked fine on the C-7 last week -- but it doesn't seem to have helped.
Troubleshooting Z-Wave on the C-8 is similar to C-7. With either model and your particular problem, the best starting point is probably trying to identify and remove "ghost nodes" if you have any. I'd suggest starting with this document, particularly the "'Ghost nodes' or failed inclusions" section: How to Troubleshoot Z-Wave | Hubitat Documentation. (The rest could be helpful, too, but it sounds like you've tried at least some of those suggestions like toning down power meter reports, etc.)
You could also try shutting down the hub from Settings > Shut Down, unplugging the hub from power for about 30 seconds (after the LED turns red), the reconnecting it to power to reboot the hub. This will completely restart the Z-Wave radio, which a normal reboot or shutdown won't do. It's normally only necessary if the Z-Wave radio crashed and any software attempts and getting it back failed (likely addressed with previous updates), but it can't hurt to try once.
Thanks - yes, already checked for ghosts... nothing showing there.
Also, I've power-cycled the unit and this still pops up.
It isn't all the time -- which suggests the radio hasn't crashed -- it's just a few times a day that this shows up, with the result being that the command doesn't make it to the device and no retry attempts occur. When it's a light, no big deal, you just ask for it to turn on again. But when it's an infrastructure automation, it doesn't get noticed as quickly.
Mar 20 11:31:53 timothy hubitat-logsocket[1998898]: warn sys[1] Hub: Z-Wave Network responded with Busy message.
Mar 20 11:31:57 timothy hubitat-logsocket[1998898]: warn sys[1] Hub: Z-Wave Network responded with Busy message.
Mar 20 13:03:10 timothy hubitat-logsocket[2010341]: warn sys[1] Hub: Z-Wave Network responded with Busy message.
Mar 20 13:03:20 timothy hubitat-logsocket[2010341]: warn sys[1] Hub: Z-Wave Network responded with Busy message.
Mar 20 23:32:08 timothy hubitat-logsocket[2039460]: warn sys[1] Hub: Z-Wave Network responded with Busy message.
Mar 20 23:32:13 timothy hubitat-logsocket[2039460]: warn sys[1] Hub: Z-Wave Network responded with Busy message.
and seventeen times the day before:
Mar 19 00:49:56 timothy hubitat-logsocket[1904580]: warn sys[1] Hub: Z-Wave Network responded with Busy message.
Mar 19 00:49:56 timothy hubitat-logsocket[1904580]: warn sys[1] Hub: Z-Wave Network responded with Busy message.
Mar 19 00:50:06 timothy hubitat-logsocket[1904580]: warn sys[1] Hub: Z-Wave Network responded with Busy message.
Mar 19 00:50:07 timothy hubitat-logsocket[1904580]: warn sys[1] Hub: Z-Wave Network responded with Busy message.
Mar 19 00:50:07 timothy hubitat-logsocket[1904580]: warn sys[1] Hub: Z-Wave Network responded with Busy message.
Mar 19 11:31:04 timothy hubitat-logsocket[1928378]: warn sys[1] Hub: Z-Wave Network responded with Busy message.
Mar 19 11:31:04 timothy hubitat-logsocket[1928378]: warn sys[1] Hub: Z-Wave Network responded with Busy message.
Mar 19 11:31:16 timothy hubitat-logsocket[1928378]: warn sys[1] Hub: Z-Wave Network responded with Busy message.
Mar 19 11:31:16 timothy hubitat-logsocket[1928378]: warn sys[1] Hub: Z-Wave Network responded with Busy message.
Mar 19 11:31:16 timothy hubitat-logsocket[1928378]: warn sys[1] Hub: Z-Wave Network responded with Busy message.
Mar 19 12:56:58 timothy hubitat-logsocket[1939917]: warn sys[1] Hub: Z-Wave Network responded with Busy message.
Mar 19 12:57:08 timothy hubitat-logsocket[1939917]: warn sys[1] Hub: Z-Wave Network responded with Busy message.
Mar 19 23:31:42 timothy hubitat-logsocket[1963415]: warn sys[1] Hub: Z-Wave Network responded with Busy message.
Mar 19 23:31:42 timothy hubitat-logsocket[1963415]: warn sys[1] Hub: Z-Wave Network responded with Busy message.
Mar 19 23:31:47 timothy hubitat-logsocket[1963415]: warn sys[1] Hub: Z-Wave Network responded with Busy message.
Mar 19 23:48:19 timothy hubitat-logsocket[1963415]: warn sys[1] Hub: Z-Wave Network responded with Busy message.
Mar 19 23:48:29 timothy hubitat-logsocket[1963415]: warn sys[1] Hub: Z-Wave Network responded with Busy message.
This also occurs when I try to remove two ghosts that got created over the weekend when I added a Zooz ZEN15 switch. I've tried multiple hard boots -- no improvement.
Yes, hard boot refers to a complete shutdown and power removal, as opposed to a soft boot which is just using the software-based restart functionality. I left it powered down for fifteen minutes on at least one occasion, to no improvement.
The device has been unplugged when I try to remove the ghost. Still doesn't remove it.
This is with the item disconnected, just tried it fresh for you: Mar 21 12:35:49 timothy hubitat-logsocket[2087483]: info sys[1] Hub: Failed node 9E remove status: 2 Failed node responded or controller busy
Subsequent attempts show:
Mar 21 12:40:23 timothy hubitat-logsocket[2087483]: info sys[1] Hub: Failed node 9E remove status: 0 SDK failure node is no longer in failed node list
At this point, I'm kicking myself for upgrading from the C-7 so quickly. It seems there are some fundamental issues with the Z-wave side.
Also, I've tried to add my Aeotech Z-Stick (500) to the mesh to do the hard way of removing ghosts. It'll only load half the mesh and Hubitat fails to acknowledge it as a device.
These same exact issues existed on the C7 as well, was reported all the time.
Adding the USB stick takes a lot of messages going back and forth, the info for every node has to be transferred to the USB stick. I think you can still remove ghost nodes without security, have you tried pairing it with no security? That will allow it transfer messages quicker. Also have the USB stick as close to the hub as possible for pairing. If it does not complete and you end up with a node with a discover button, pressing discover and putting it back into pairing mode may allow it to finish.
I never once had the busy error -- at least not to the point of being noticed in how the system worked. This seemed to start once nearly everything was connecting directly to the C-8.
The Hubitat side never gets far enough to ask me about security when pairing the z-stick (like it shows in the PDF that has circulated), and I've also disabled security in the PC Controller. In fact, it was finding more devices when security was enabled than after it was disabled (35 vs 23).
I've also tried extending the timeouts on the Z-Wave PC Controller, but it doesn't seem to do anything -- it seems to finish around the 60 second mark.
In inclusion mode, it just counts down and hits zero. The z-stick is never added to the z-wave device list in Hubitat for the "discover" button, and the inclusion on the HE side just runs down to zero with a message about having trouble including.
The z-stick is usually about 6' away, in the same room as the HE. I tried moving the HE closer (to 18") but that didn't improve anything.
Interestingly, the z-stick ID goes up by one on each attempt... so something's happening on the HE side, but not far enough to get the thing created.
I've had similar issues with the stick on the C8... and not on the C7. I did occasionally get busy errors on the C7 but not like what you're seeing on the C8. I eventually got it to work by shutting down the C8 and removing power for a minute, then restarting. It has still not been consistent though. It's as if it starts communicating and then poof - something goes wrong. I can then turn around and connect to a C7 without a problem, albeit with nothing else running on it. I've had similar problems including other devices. I've even set up a brand new C8 with three z-wave devices on it, and sure enough one of them experiences issues almost every day. The same device on a C7 is solid. So I concur... there is something different about the C8 that seems to be causing issues like the ones you and I experienced. But not for most people, which makes it hard to diagnose.
Guess I got lucky, everything here works great, and better.
I did do some clean up after migrating and was fighting with some zwave removals. Some ghosts I
also created trying to get the USB stick paired up again as well. I usually do a zwave replace to join my stick back into the same node but it was refusing to work right, very similar to what you are getting where it would time out. Eventually I gave up and paired it on a new node. I remember having some issues and forget what I did to get it working again. Once I got it paired up, cleaned up all the nodes I needed to remove and that was that.
Are you resetting the stick from PC Controller? Or also running an exclusion would probably reset it as well. I usually use the reset button right on PC Controller.
I've tried both. Exclusion times out (on both sides). Typically, I'm resetting it to try again. I've tried doing the NWI again (without resetting), but it ends up doing the reset.
if its saying its no longer in the remove list its because the main device is powered and on again. You need to keep it off until its cleared sometimes a reboot between refresh is needed.
The device you have the discover on you can try and hit it to get it to join correctly to then remove. You can also try and fully remove that device get rid of the ghosts and then start again.
Not necessarily, there are multiple cases of this happening when the device is ripped from the wall, broken, smashed, in a different zip code, etc...
Someone needs to zniffer the traffic to see wth is going on. If I can reproduce it on my dev hub one of these days I am going to see if I can get anything.
Ok I should have said if that node ID is responding, because your right sometimes that does happen. Even though it really shouldn't, I suspect it's when there is more than one device joined around the same time.
This is why when joining you must take it slow and cross check each one.
It's also why when a ghost happens if you lucky and you haven't joined the same type of device at the same time sometimes the 'type' can help to identify the bad node. The key thing is though there is always something that has responded, it's just not always clear what it was that did.
The same thing happens on a DALI system (again it's not supposed to) and the arguments we have on site with electricians saying "no there is nothing else it doesn't exist". In 10+ years I have always proved them wrong. Either a apprentice has wired a random device on that network when they shouldn't have, they have a fitting that has more devices than they thought or they have a random driver that they have set it up wrong so it makes more address than it should. All the same, it exists its just a ball acke until it's found.
There is an old guide on here that is possibly slightly outdated now. Do you have an extra USB stick to sacrifice? You have to a flash a special firmware on it.
Very. Has anyone tried running Zniffer on Mac silicon using Parallels? I started down that route, hit a bunch of dead ends, and gave up - but that might have been the issue.
