What do you do with a ghost node?

Nothing looks all that awful on a quick look at your table. Maybe someone else can spot something?

That ghost on 62 has to be one of the Front Bedroom devices?

Did you try doing a shutdown, pull the cord, reboot, and don't touch anything (repairs or adding devices or anything like that) for at least a couple hours? Mine really got better after the overnight maintenance, maybe that will do something to help yours too?

Oxymoron of the year! If you can dig up a copy of PC Controller, I like it a lot better.

It "repairs" a bad routing table, say if you move a working device from one room to another, but is no magic button to repair a bad node, for example. Unlike Zigbee, Z-wave is not very forgiving when it comes to missing nodes. Running repair on an unhealthy mesh could be a lot worse than not running repair at all.

1 Like

Actually, it's one of the Inovelli's for the Basement Stairs. I went from the front bedroom down to the basement when I was building out my mesh. I wound up removing them and re-pairing which is why they are at the end of the list now. At least I think that's what it is. From what I can tell there is no way to get any device info to learn what it is?

Hmm, well that's interesting, I'm curious if that's considered "safe"?
According to bcopeland this is safe method.

1 Like

It's a free download from the Silicon Labs website. With SimplicityStudio v 4, PC Controller was a part of the download. With SimplicityStudio v 5, PC Controller has to be added from the menus as a tool, which downloads it. PC Controller does not run on the Mac except in a virtual box. There's a thread on the forum here about how to install it in a Mac virtual box.

The native Simplicity Studio v5 for the Mac does not have PC Controller.

Yep, it's the Oxymoron of the Year.

1 Like

Interesting. A thought -- seems like a great opportunity for a warning dialogue box then to inform the user when it should be used and when it will make things worse. Why? Well it avoids user frustration when it makes things worse and it prevents support situations (like this one) where someone does something they shouldn't have because there was no indication in the UI when it should be used.

2 Likes

There is only one thing worse than adding a secure HEM to a C7... adding 2 secure HEMs encrypted with S0. Looks like both of your HEM are S0. Those are known to be very chatty. If you had them on C5, they were likely non-secure.

1 Like

Ok. I can remove and re-pair. Do I just uncheck the boxes? I thought the suggestion was you should use the default checkboxes when pairing?

I carefully unchecked all of the boxes when I migrated to C7. I went out of my way to have no secure devices. The only encrypted device I have is the garage door. Everything else is none. Call me old school but I think the mesh responds a lot faster.

Honestly, our engineers didn't test the gen 5 and we don't have a built-in driver for them. You might need to keep those on the C5 if you cannot include them unsecure. They tend to be very chatty and have seen hubs running into troubles using these on C7 hubs. And while you're at it. Please be sure that any other power reporting devices are not sending frequent events and that they are not included secure. Overloading C7 radio with power reports is the leading cause of bad Z-wave experience. The next release should resolve some of these issues.

S0 removed. Unfortunately that has now left me with one of those devices as another ghost node. Sigh. At least with a lot of repeated clicking of Remove it eventually went away

Whew! I've also found sometimes waiting overnight helps. I think there's some sort of ZWave cleanup activity that happens overnight that seems to help. Sometimes.

I'm nota n RF or software engineer but I suspect a lot of this is more a result of the SDK than anything HE can do...

If you are 100% sure that the ghost node is the switch you think it is, disconnect power to it. Shut down the hub from the settings menu. Unplug the HE from the wall (not the HE itself) Wait 5 mins then power back up. Now go to your z-wave table and click remove (repeatedly) After about 6 or 7 tries wait a minute or two. You may get another popup about removal. Repeat this for each difficult ghost. If when re pairing a device it fails, stop everything and check for the ghost. You can try to hit discover and that will sometimes find it, if not remove ghost before proceeding.

4 Likes

I think you have enough advice here.

This is a shameless plea for you to stay in the community. You contribute some really good stuff and it would be a sad loss/big void to see you go. I can send snacks and drinks if that hel;ps... :smiley:

2 Likes

Unfortunately it's the opposite for me. After the overnight maintenance, every device has stopped working again, even those that slowly came to life yesterday.Back to just getting these logs over and over and 100% unresponsiveness:

I don't disagree with you, however, it's irrelevant. Hubitat is the one we're paying. If they purchased a shoddy SDK, they should be suing whoever made it. The fact of the matter is, using this new SDK is a decision HE made and it has caused my hub to become completely unresponsive. If your car had faulty brakes, and you crashed as a result, Ford saying "well in fairness, we bought those brakes from a 3rd party" wouldn't make you feel any better nor would it matter. It's the same situation here.

My zwave logs are flooded every 10th of a second with this message "seqNo: XXX, routeChanged: false, transmissionTime: 0ms, repeaters: None, speed: Unknown, rssi: [0 dBm, 0 dBm, 0 dBm, 0 dBm, 0 dBm], Ack channel: 0, Transmit channel: 0" from any device that tries to communicate with the hub.

I thought I was, but I tried this multiple times and it didn't work.

What I just need is a functional hub. Right now it doesn't have a single functional z-wave device. Pretty much this overnight maintenance that is supposed to fix my mesh destroys it every night. It slowly starts working during the day (no idea why), then the overnight maintenance runs and breaks everything again. I don't want to give up, but I'm not even convinced that the ghost node is the cause of 100% of zwave devices failing every morning. I think there's a bug here and I don't think there is anything I'm capable of doing about it. If I can't get my hub working, I mean seriously, what option do I have?

2 Likes

Just for tracking purposes, no, this did not resolve my issue. Both are now included with no security and 1 of them has energy reporting disabled. I'm back to everything logging the same message. I don't know if it's relevant, but the majority are these 4 devices repeating over and over:

I left the zwave logs open overnight. Everything looks good until 7:06am, then those logs started. Not sure if that time is significant for any jobs that run. There were some "Unknown"s prior to that, but starting at 10:06 it was

@bcopeland I know it's the weekend so not exactly expecting a response, but any insight would be helpful. I'm totally stuck here.

For anyone wondering, how do you get an S0 device to pair without security, it doesn't appear Hubitat gives you an option to do this. It pairs automatically as S0. I followed this advice from darthandroid on the Inovelli forum:

If it’s S0-capable, Hubitat won’t prompt about security and just add as S0; You’ll read about people struggling to use insecure devices with S0 devices because you can’t force hubitat to pair an S0 device as insecure currently. (A workaround is to kill power to the S0 device during pairing, causing the security setup to fail and fall back to insecure)

I don't know if there is a better way? I mean if the recommendation is to not use S0, seems like there should be an easier way? But this is what I did.

2 Likes

What shows up in the log when you try to remove that ghost node?

Presently just "Failed node 3E remove status: 0"

sometimes it says no reply, other times zwave network is busy, other times status is 2

Last several hundred attempts have all been 0 though.

Just to double check, when zwave gets into a bad state, are you doing the classic shutdown the hub, pull power for 30 seconds, and power it back up dance? I think on occasion that can help the zwave radio recover.

Truthfully I didn’t read through every message carefully to see if you mentioned doing this already, so apologies if this is a repeat.