Deleting a previously Discovered Thing?

Setup, Configuration and Use Runtime
1

Is there a way to achieve the inverse of Discovery? That is, a complete removal of a Thing that was previously Discovered?

DiscoveryListener has the thingRemoved() function, but how to trigger it to run?

Reason asking: would like to handle repeated discovery by first removing old instance.

2

You can do this through Paper UI. Were you looking for an alternative?

3

I need to do it programmatically. Like this:

  1. Device joins network, discovery happens
  2. Connection lost with device for a little while for whatever reason
  3. Device rejoins network, not aware of previous discovery, attempts to get discovered again. Or this is a newly reflashed device coming back with some parameters changed.
  4. Remove previous version of device and any associated settings (ascii name, etc).
  5. Present device for acceptance in PaperUI as a new device.
4

The following thread on the ESH forums has some discussion on the topic:
https://www.eclipse.org/forums/index.php/t/893397/

You can however update a Thing to change it’s parameters/name etc so that you don’t have to delete the discovered Thing.

As far as I’m aware (but hopefully @Kai can clarify) if you called thingDiscovered() with a new Thing that has the same ThingID as the old thing it will overwrite it.

5

Thank you Daniel, that is a very useful discussion. I think it answered my question for now…

6

In my experience, the first time the thing is discovered these values (label, etc) are set. After that, the Thing is cached in some storage (in case of Discovery anyhow) and is loaded from there on start, even if the physical device is not present. As such, discovery does not happen again, only the status is switched online/offline. Without going through the discvoery routine, new values aren’t available.

To summarize - yes, one can update “label”, but one does not know what the new value should be.

But perhaps, I am doing something wrong…

7

I’m not saying not to go through the discovery routine again, but assuming the Thing created on first discovery has the same Thing ID as the Thing created on second discovery (with updated configuration) then you shouldn’t need to manually delete them.

My binding does something similar. It sends out discovery packets which are responded too, but due to the communication protocol being UDP I receive multiple copies of the response (as a way to guard against lost packets). I create DiscoveryResults for each response but yet I don’t end up with multiple identical Things.

8

Just finished some experiments. Seems it is the PaperUI that is the culprit. The label changes if observed through /rest/things, but not through the interface.

Although, I am not sure if it is fair to blame it. I see several json members named “label”. Perhaps, I just need to find the right one.

9

Aha!

I’ve been trying to set parameters with
getThing().setProperty()

but instead, I should have been using
getThing().getLinkedItem().setLabel()

10 
getThing().getLinkedItem().setLabel()

is what I have been using to process a change in label but last night I updated my working copy of the OH2 and noticed getLinkedItem() is deprecated so that seems like it’s not the way to do it.

11

Ouch. Just can’t win.

But I’ve been having a hell of a time trying to update, so I’m not in deprecation danger yet, hehe.

12

Things actually currently do not even have a label, so you cannot easily update it either. See https://github.com/eclipse/smarthome/issues/710.

I’d suggest to move such discussions over to the Eclipse forum as these concern the ESH APIs and not openHAB specifically.