Devices that don't exist showing as selections


Many months ago when I first started toying with Hubduino by ogiewon, I added a device based on an Arduino Uno as a test. When I finished, I deleted the device and both the parent and child devices were deleted from the Device List. However, I still get these two child devices showing up as selections in RM as if they still exist. I have added and removed a few other Hubduino devices since and they have not exhibited this. I figured that maybe if I waited long enough, they would clean themselves up but that is not happening. The parent device is gone but yet these two child items are sticking around. Is there any way to get rid of them? Hoping @bravenel or someone can help with this. Thank you!

What part of RM was that screenshot taken from? Also, please show your devices page for the same portion of the alphabet, and also for Hubduino. @ogiewon Any ideas?

I can't think of any reason that HubDuino children would somehow be left behind after the parent has been removed. My understanding is that upon removal of a parent device, all child devices are automatically removed from the system. @chuck.schwer, is this correct?

@lelynch, as @bravenel mentioned, it would be nice to see if those child devices are still showing in the Devices list. If not, I would have to hypothesize that they were somehow left behind in the database, even after the parent was removed. The current HubDuino Parent Driver code does explicitly delete its child devices in the uninstalled() method. Earlier versions did not, but I thought the platform took care of that clean-up anyways.

Also, depending on how far back these child devices were created, there is a slight chance that they were created by an HubDuino App, instead of the current HubDuino Driver. When Hubitat was first released, composite device support was not available. As soon as composite device support was added, I switched from using a Parent App to using a Parent Driver. Just a hypothesis that might help to explain how these stragglers were somehow left behind. :thinking:

Yes, composite devices are removed by the hub when the parent device is deleted.

1 Like


Here is a screenshot, but as I said there is nothing showing in the device list for them. The screenshot in my original post is from a rule I started to create just to show that they are still there. They will show up in RM when selecting an appropriate capability. In the case above it was Custom Attribute so both are in the list. However, only "Arduino Uno (humidity1)" will show if the capability selected is Humidity and only "Arduino Uno (temperature1)" will show if the capability selected is Temperature. They show up as a selection where I would expect them if they actually existed in the device list. My current Hubduino devices are all ESP8266 based and I purchased the first of these boards in January 2019, so the Arduino Uno device would have been just prior to this.

Note: These two child devices don't seem to cause any harm to anything as far as I can tell. They just shouldn't be there.

Did you rename the parent device to something other than Arduino One? Because they would appear under the parent device and not necessarily in Alphabetic order with the rest of the devices, because they are components and not just children.

We had a rash of occurrences of “orphaned devices” recently with HubConnect. It does seem that child devices were being left behind when the apps were uninstalled.

1 Like

No, did not do that. The device was removed. I have a few Hubduino devices and none of them have children with those names. There is also nothing in my Devices list anywhere with those names.

I have not installed HubConnect.

But in those cases, the device was still on the device list, correct? In this case, they are not. Also, we're talking about component devices....not just children.

Of course.. However that doesn't mean there is no common underlying cause.

True...anything is possible. However, in HubConnect's case, the device wasn't deleted from the list. In this case, it was. So, yeah, they could be related. But I didn't think it was possible for an orphaned child component device to survive deleting the parent from a platform perspective. If it is, I will have to rewrite a couple drivers to make sure they get deleted before the parent is.

That’s what was happening in HubConnect, except with child devices of an app instead of parent device. Certainly not the same set of circumstances, but it is the same behavior pattern.

I found something new this morning while gathering information for a question for another category. Today when I bring up the list of devices under the Custom Attribute capability in RM I am now seeing two of the "Arduino Uno 1 (humidity1)" devices along with the single "Arduino Uno 1 (temperature1)" device. Strangely enough the second "Arduino Uno 1 (humidity1)" device appears to be showing as a temperature device. None of these devices exist anywhere in the actual Devices list. Is there any way to go in and delete these by either myself or support?
This first picture below is the list of devices after selecting the Custom Attribute capability, the second is from devices listed after selecting the Humidity Capability and the third are the devices listed after selecting the Temperature capability.



1 Like

None of these devices exist anywhere in the actual Devices list. Is there any way to go in and delete these by either myself or support?

I have the same issue. Before I start poking and probably break something else, did anybody ever figure out how to clean this up?

In my case, the devices that are hanging around are orphaned child devices of a child device of a custom driver that I wrote. Apparently something hiccuped with all of the device creations and uninstalls during testing.

OK, it wasn't as bad as I thought.

The driver for the orphaned device was still installed. It couldn't be removed since the two orphaned devices still existed.

I added a custom command to that driver, like this:

def getOrphanID()
{
    def devID = device.id
    logDebug("devID = ${devID}")
}

Then, I used RM to trigger a running of that custom command on the orphaned instance of the device. That got me the ID, and I could open the device configuration page from there (like http://<hub IP>/device/edit/<devID>). From there, the orphaned devices could be deleted.

I still don't know how they got left behind, but this method should work for anyone that gets into the same situation.

1 Like

@bravenel I just figured out a way to get rid of these orphaned devices and it worked. As @tomw said he did, I created a rule in RM that used these two orphaned devices. Once the rule was created and saved, I opened it back up as if to edit and selected the "gear" at the top right of the screen. I discovered any devices that you use in the rule are listed by name in the "value" column and are clickable links that take you to their device page. I figured "what the heck" and I clicked one of the orphaned devices and it took me to the device page for it that was not showing in the Devices list. I scrolled down, clicked "Remove Device". I did this for both of the orphans I had and voila, they are now gone finally! Then I just deleted that rule in RM.

1 Like

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.