Orphaned nodes

So over the years, due to devices failing, and my stupidity at excluding devices, I have a handful of "orphaned z-wave nodes". These are listed as devices that have long since not been a part of my setup. I'm ok with them staying there.... but thinking it would be nice to somehow delete them. I'm guessing they are listed in my Z-Wave stick, but is there an (easy) way to delete them and get them out of my way ?

https://forums.indigodomo.com/viewtopic.php?f=58&t=21586#p169350

Do the following for each node you want to remove. You may only need to run the Remove Failed Nodes From Controller tool (see below), but sometimes dead nodes are stubborn and you may have to:

1. Create a new device and select the failed node from the drop down list.
2. Try to sync the new device (sync will fail).
3. Exit the device configuration dialog.
4. Repeat for each failed node.

When you're done, select Interfaces -> Z-Wave - > Remove Failed Nodes From Controller and follow the instructions.

https://wiki.indigodomo.com/doku.php?id=indigo_7_documentation:managing_z-wave_devices#remove_failed_device_from_controller

Ahhhhh
I did see this command, and did try it, but of course, none of the nods showed up as "failed" because they are not in Indigo! This makes perfect sense. THANKS!

don't mean to hijack the thread, but i have some questions about Indigo's concept of "failed nodes" - possibly also relevant to the original post as well.

i was thinking that "Removed failed nodes from controller" might be useful for me to do as a "cleanup" since i have a multi-year history of failed inclusions, failed devices, etc. this isn't breaking anything, but is "cluttering up" my z-wave stuff a bit .

i was getting ready to do that, when i noticed "Interfaces>Z-Wave>Report Failed Modules to Event Log". i decided to try that first. what i saw surprised me a bit. first, most of the old cruft from failed inclusion attempts did NOT show up in the list (for reasons explained in DaveL17's post below). but also, a number of existing, working modules do show up on the list. some for reasons i really don't understand.

there are a few zooz zen25 double-outlet modules. i use these regularly. i tried controlling a few of them and they seem to work fine.
likewise, i see one of my Bali (Somfy) autoview shades on the failed list. (one of a group of several installed at the same time). it is also working fine.
i see some other battery powered devices on list such as one of several remote controls i have for Bali shades.
there are monoprice multisensors (aka zooz ZSE40) in this list. three of the four of these that i own are in the list, in fact.

for the non-battery powered devices, i try define-and-sync with them just as an attempt to verify everything is ok. for the most part, doing define-and-sync, then hitting "sync" button (without changing existing z-wave node assignments or anything else) takes a 5-20 setons and seems to complete successfully.

at least for the non-battery devices, after successful define-and-sync "reset" (?) of the device, if i repeat the Report Failed Modules to Event Log command again, those modules seem to disappear from the failed list. strangely, as i have repeated the command a few times in the last day or so, different other devices now appear on list.

for the (battery-powered) multi sensors that are on the failed list, i can't easily define/sync them (at least without getting up and walking around the house to manually "wake" the devices). i can however see that i am receiving signals and updates from them. so again, it's rather puzzling to me why Indigo would characterize these as "failed".

so my questions:
what does "failed module" really mean to Indigo? why are devices (including ones that seem to be working ok) seem to pop onto the list of what Indigo considers to be "failed"?

am i accomplishing anything by doing a "define and sync" operation? i assume, in at least a few cases, the module may be old and Indigo may have updated its device definition since it was added to my system. i thought initially i was "fixing" the failed state by forcing it do a define/sync but now it's starting to seem a bit arbitrary as to what devices come and go from this list over time and i'm not sure define/sync is doing anything at all.

also (slightly separate topic) in attempting to do some z-wave hygiene, i have noticed a few stubborn devices for which the device got added to Indigo, but now i am not subsequently able to get it to do a "define and sync" operation. in most of those cases, i can see that Indigo is communicating with the device, but the define and sync operation never completes and eventually times out with an error. is that a bad sign - perhaps of a hardware failure? or perhaps just of an older badly-behaved z-wave device? should i a) let sleeping dogs lie or b) take the brute-force approach by excluding the device, perhaps factory resetting, and try re-including it?

Will definitely need to defer Matt & Jay on all things related to how Indigo treats such things, but I can say that I have seen similar behavior over the years. I have found it sometimes necessary to go through the process of syncing a working device multiple times to have it eliminated from the list.

That said, from what I know of it -- the list of failed nodes is actually provided by the Z-Stick. Indigo can only deal with the information received. My (extremely quick) research into the matter suggests that "not everything is known" about the entire inventory of reasons that the Z-Stick firmware chooses to add a node to its internal list. This may have changed with "recent" changes in how SiLabs treats Z-Wave development information.

[matt (support)]

Dave is correct. Indigo doesn't get much insight into what is going on with failed nodes. They are tracked by the Z-Wave controller when it believes a module is no longer reachable. Doing a sync is a good way to send enough commands to the module that it should get flagged as failed. The only controller API commands Indigo has access to are "what modules are failed?" and "remove failed node with address X." The latter command will only succeed if the controller internally has the module flagged as failed.

thanks for the clarification, matt and DaveL17.

Dave is correct.

I never get tired of hearing that!