I don't quite know how to describe this - I got a brand new hub today because my last C-8 Pro failed. I restored a backup for my Zigbee devices and configs, then re-paired all of my Z-wave devices from scratch, so this is a brand new mesh. I used the instructions provided by @jtp10181 to change the DNI on all the Z-wave devices first, factory reset them, reinclude them, and use the Swap Apps capability to move them over.
But, in my Apps (examples: WebCoRE, Hubitatv2, MakerAPI) I see a bunch of "devices" that don't actually exist. They aren't ghosts on the z-wave mesh, they're like Inovelli child devices for LEDs, etc. And I don't see anyway to remove them.
Is there a database rebuild that I can do, or something which can get rid of these so I can create new, correct ones and finish my config?
Thanks so much!
If they were child devices, there is no way you used Swap Aapps Device to move anything around. They will not show up in that tool. So, I guess the first question should be: are you sure this is what happened? Do they show up in your "Devices" list? That's the authoritative source.
Assuming they don't, you might just be dealing with a display/cache issue. If you open the device selection input like you were going to chose different devices, do they still appear then? Even just opening and closing it may be enough. (I think I've seen this before, though not recently....)
Also, when you remove a device, there is a warning to remove it from any apps that are using it first. That's a better way to avoid this problem (some some might not react well to a device being removed from under their feet), though it's too late for that here, of course. 
Hey - thanks for the reply. I actually removed all of the child devices first, before using Swap Apps because I anticipated this. They still show up 
I also did try doing the reload/reselect/etc in all the apps to see if it cleared any kind of a cache, it does not seem to have.
And no, the devices don't show up in the Devices list, nor in either the Z-Wave or Zigbee network views
Removed them from what? The devices list or the rules?
Can’t you just go into your rules and change the selection to the correct device and save?
This is what I'm seeing - none of these devices actually exist, and I can't find any way to remove them. I've got no way of knowing what's real and what's not (nothing is real, currently, these are all phantoms)
I took a hard look at every one of these "stuck" devices and confirmed they were all child devices of parents that were removed during the replacement of every z-wave component.
I was able to find two which were exported to one of these apps at one point - the Inovelli LZW36 creates a Fan and a Light child device of the main device. This Fan and Light are also duplicated in the native Hubitat HomeKit integration.
By following those breadcrumbs I found this: two devices named "Office Fan"
Clicking on one of them gives me a device details page about Device ID 230. Clicking on the "Parent Device" link for Device 230 tells me that Device 228 (ostensibly the former parent) does not exist and I should update my links.
So there's some kind of database somewhere that still has these devices recorded in it, but they're dead links
I think I found a super hack way to address this, but it seems to be working...
I searched the Device Stats logs for the names of the bad devices. I verified I was on the right one by trying the Parent Device link for each. If I got a "Parent device does not exist" error, I went and deleted the child device. Now they all seem to be gone, after a huge amount of manual effort 
1 Like
Ah, so when you force removed the parent devices after using swap apps the child devices got left behind in the database but were not visible in the device list (because the parent was gone)?
Seems like a bug to me if thats the case @bertabcd1234 @gopher.ny
Yeah that sure seems to be the case. For what it’s worth this was all on 2.3.9.193.
Also the hidden/phantom child devices were preventing creation of new, valid children. I posted a stub issue about that on the Inovelli forum because I incorrectly thought it was a driver issue due to the error message I was seeing.
Reference: "Generic Component RGBW" with a namespace of hubitat? - General Discussion - Inovelli Community
Probably a DNI conflict, when the child is made the driver generates a DNI, usually from the parent DNI + something else. Must have been conflicting with one of the old child devices.
Your suffering may prevent someone else suffering in the future, hopefully they can fix that bug that left the orphaned child device. There should be no way for that to happen.
Yup I did note that the child device IDs had a string concatenated on the end of the parents DNI. I had changed the DNIs before adding the devices back though, so the newly added zwave parent devices were unique and therefore the child DNIs should have been too. Or so it seems anyway.
And yeah I hope my experience makes things better for others, that’s a great result if true.
OK, parent devices aren't supposed to show up in Swap Apps Device for the same reason as child devices above. That is probably the root of this problem, though it appears all that may happen is that the "old" child devices get stranded, and depending on how the parent driver sets the DNI for the child devices, you might have some conflict there that prevents the new ones from being added, as also guessed above (this is one reason I prefer making child DNIs one based on the parent ID, not the parent DNI, if there is nothing else to base it on; but I don't know for sure what your driver is doing).
A fix to prevent this is being looked at for a future platform release. In the meantime: don't do it, just like you shouldn't have been able to. 
(Deleting the child devices first and then doing it should work. As always, make sure none are in use by any apps before removing.)
Yeah I saw the system drivers make this switch and I followed suite for the same reason.
@bertabcd1234 To clarify, are you saying that if you want to swap apps on a parent device which has a child you need to delete the child devices first, then you can swap the parent devices? Would this apply to both old and new devices? Sort of a PITA but might be worth it if you have tons of stuff linked to the parent device.
Yes, then the "parent" device isn't a parent device at all anymore. They aren't supposed to show up in this tool in the first place (for the same reason as child devices), so this will eventually be the only way you can do something like this.
Keep in mind, of course, that the old-fashioned option of swapping the old device out with the new one yourself in any app works fine, too -- and works with any kind of device.
1 Like
FWIW this is exactly what I did - I read the link you provided me in another thread and someone had questioned what to do with child devices there too. Here was my order of operations:
- Rename the DNI for every z-wave device
- Any device with a child, I deleted the child
- Factory reset the physical hardware device
- Reinclude it to the hub, using the “swap/replace devices” option on discovery
- Force remove the invalid, old device
In many cases, I noticed that the child devices were created under the original, old, invalid device instead of the new one. So I still think something hinky is going on with that process.
1 Like
Thats what did it @bertabcd1234
Using that new swap on discovery feature. I forgot that even existed, its brand new.
The child must have been created first then the swap executed.
If there was a way HE could have it swap first before the driver is initialized, it would probably work ok.
2 Likes
It’s super convenient too. If this is an opportunity to improve that I’m all for it, I was surprised as heck to see it and went “hell yeah, do that” 
1 Like
But if I flip into solution mode for a second, I’d also kinda love to see a database maintenance view, maybe even buried in the diagnostic tool, something that just dumps the raw table of:
- Device name
- Device ID (number)
- Direct link to device
- Any apps, etc using the device
- Multi-select and delete capabilities
I’m not sure how frequently something like that would come up, and if I knew how to access the underlying DB in HE I could probably materialize my own view to do it - but it seems like a useful if infrequently used tool to have available
This works the same as Swap Apps Device under the hood, aside from doing it all in one step and automatically renaming the "old" device for you. Parent and child devices were also never supposed to show up in this list, as the limitations for both tools are the same. I thought this was fixed in beta, but it might have slipped through and was also noted as something to be fixed with this (I tested both).
So, basically: the same processes I mentioned above are the only way to do this (or should/will be).
But what if the user deleted the child device on the old device first, making it no longer a parent. Then when they include the new device they select it for swap. This would be allowed since at this time the hub has no idea the new device being included is about to have a child created automatically.
So then my theory is the new device got included and the child got created FIRST, then the swap still happened automatically without checking if it was a parent/child again, wreaking all sorts of havoc.
If the swap happened before the new child was created by the driver, I think then it might work OK.
1 Like
