No Z-Wave since firmware update to 14.38 on 4/21

What is meant by orphaned devices?

My z-wave radio appears to be broadcasting properly.

I updated the support ticket with log info, had not heard back from them though. I also noticed if I try to add a device, that seems to wake the antenna up. I was then able to get a repair to work, from pc though, not app. Not touching anything else, until I hear back.

I am not home to fully check things out
things look better - no wierd statuses
however, I still have this:

I assume the zwaveradiondetected and functional should be true?

Dave

I have tried remotely clearing out orphaned devices but I am having problems with them still being seen by Harmonyconnect
I have done everything I can remotely but I can’t seem to get Harmony and smartthings disconnected


Dave

Well
after going through three hub power cycle + z-wave repair routines yesterday, everything seems to be back to normal. I don’t know if support pushed out a fix or if the powercycling was the key but I’ll take it.

zwaveNodeID: 01
zwavePowerLevel: full
zwaveRadioDetected: true
zwaveRadioEnabled: true
zwaveRadioFunctional: true
zwaveRegion: US
zwaveSerialVersion: 4
zwaveSucID: 01
zwaveVersion: 3.83

I did not submit a support ticket so this was not something that support would have done specifically to my hub.

Same zwave issues here. Mine started about a week ago. Tried everything from power cycling to repairing network. When I replace a switch, it will work for approx. 10 minutes and then nothing. I did put in a ticket with support. They reset my zwave radio, but same problems after reset. I’ve only been with Smartthings for about 3 weeks. I love it when it works, but must admit I’m pretty frustrated at the moment. Customer support has been great. Sending me out a new hub. Hopefully that will fix my issues, if not, I’m running back to Vera with open arms.

Mine seems to be working properly.

outside of smart things, “Orphan” is from the child’s point of view

In network engineering, an “orphan” device is one that has lost contact with its “parent.”

The technical details are different for different protocols: sometimes it is used to mean a battery-powered device that has lost contact with a repeater, but still knows who the network Coordinator is.

Other times it means a device that tries to join a network and fails, so has no recorded parent.

And still other times it means a device that now needs to be moved from one network to another, so it has a recorded parent but you want to use a different one.

But these three situations are always from the end device’s point of view. The child device has a listed parent that it cannot find, or has no parent listed at all.

outside of smartthings, “ghost” and “zombie” are from the network controller’s point of view

In contrast, the term “ghost device” is from the controller’s point of view. it means that there is a device in the controller’s device table that is not actually connected to the network.

Sometimes a ghost is a duplicate that was created during a failed pairing. Sometimes it’s an entry that did not clear during a failed removal. Either of these is more likely to happen in a cloud architecture because there are actually multiple copies of the network device table, usually one in the hub and one or more in the cloud. It can also be caused by database corruption, when a device from one account shows up in the cloud’s device listing for another account.

A “zombie” device is a ghost that keeps coming back even though you have removed it multiple times. This is almost always a synchronization problem and means that you removed it from one table but then it got restored again from another.

But SmartThings uses its own terminology

As with several other terms, SmartThings tends to make up its own definitions to avoid having to distinguish between different protocols.

So SmartThings support staff, and consequently many community members, Will use the term “orphan” for what is more typically called “ghost” and don’t use the term orphan the way it is most typically used.

So a zigbee device which fails to secure a network ID during pairing is not called an orphan in SmartThings. It’s just called a failed pairing.

But ghosts and zombies, that is, devices which have entries in the device table even though they are not actually joined to the SmartThings network, are called “orphans” in SmartThings support terminology. (Even though in this case it’s the parent that can’t find a listed child, not the child missing a listed parent.)

SmartThings also introduced the term “child device” for a programming construct and then describes those as “orphaned devices” for situations where only the handlers were changed, not the device pairings themselves. It even uses the term “child device” for web services situations where there was no pairing at all.

http://docs.smartthings.com/en/latest/cloud-and-lan-connected-device-types-developers-guide/building-cloud-connected-device-types/building-the-service-manager.html

This can all make it pretty confusing if you try to look up the term in general resources. Especially since the solutions for ghosts and orphans are different. But there it is. (Smartthings also says zwave devices have “clusters,” which they don’t- – that’s a zigbee term.)

short answer: SmartThings uses “orphan” when there is a synchronization problem with the network address tables

But is not very consistent about how the term is used, and does not use it in the way that it is generally used in network engineering.

In the following thread, for example, a community member gives a helpful explanation of how to remove a zwave ghost device from the network device table – – but calls it an “orphan” because that’s what SmartThings support calls it. :wink:

2 Likes

Thanks much for the detailed explanation. I had a rough idea but rough ideas don’t mean a lot in technical pursuits :slight_smile:

1 Like

I am also affected my Zwave radio not being functional: zwaveRadioDetected and zwave RadioFunctional are both false when I look at the hub in the IDE. Obliviously this is why trying to rebuild the zwave network is failing and why I’m totally unable to include or excluede the hub. Have contacted support and they are looking into it but was trying to reset and remove the hub and cant even force delete the devices 
is there any way around this? Has my Zwave failed for some reason or is this a system error?

I finally heard back from support that this is a known issue and are working to resolve. No ETA.

Has your system been stable at all? I’m wondering if a power cycle will put things in place but that doesn’t inspire confidence that it will be fixed for good.

I ended up replacing my hub as the house had become really difficult to live with - rebuilt the system from scratch and now am operational again. I wondered if a severe electrical storm the night the wave radio functions failed could have anything to do with this?

A complete pain to delete all smart apps and devices, force z-wave exclusions and reconnect one by one
the use of a minimote to exclude each -zwave device made it just about manageable.

Support managed to fix my issues. It needed more than a simple restart, repair. But I can at least say that based on my experience Support does work very well!

1 Like

Please contact support if you are having any of the above issues. If you are still having these issues and have already submitted a support ticket, PM me so that I can ping the support team.

@jody.albritton, I have multiple times, get the “were aware and working it” but no idea what the issues are.