[RESOLVED] Best Practice in Bundle when both autodiscover and manual thing setup is used

Development
1

I am maintaining the nanoleaf binding which is both supporting auto discovery and manual setup of things in a thing file.

However what I noticed is when a thing has been defined in the thing file it is also discovered (as an additional thing) in the inbox which could result in have the same thing twice.

My question is what is best practice?

  • Should we prevent to have twice the same thing twice: one manually setup and one autodiscovered?
  • If, should I prevent auto discovering the thing if it is already available through the things file?
  • If this should be done, how can I detect within the MDNSDiscoveryParticipant that a thing is already available (through manual configuration)? Can I somehow query the system for already available things?

TIA
Stefan

2

This was discussed recently here. If your binding has a bridge, you could use a similar strategy for detecting if a thing already exists.

1 Like
3

In the meantime @delid4ve provided the code how it is done in his context.

I looked some time into the code and I noticed the main point is that we have a difference in our implementations

  • “implements MDNSDiscoveryParticipant” (Nanoleaf as it uses MDNS)
  • “extends AbstractDiscoveryService”

To be able to detect double discovery I need to access the ThingHandler and therefore I need to have getThingHandler which is available through the AbstractDiscoveryService

@Override
    public ThingHandler getThingHandler() {
        return accountHandler;
    }

As I am unsure about the “magic” behind implementing MDNSDiscoveryParticipant I wonder if it would also work if I extended my class by MDNSDiscoveryParticipant instead of just implementing it?

I found some talk about this here

I am paging @Kai as I know you were involved in writing the MDNSDiscoveryParticipant and where part of the discussion of the PR above while I am not sure if I am understanding the discussing in the PR fully.

So basically the question is

  • how can I use the MDNSDiscoveryParticipant and also suppressing rediscovery of already configured items?
  • Would be extending instead of implementing MDNSDiscoveryParticipant the right way?

I am kind of doubting that as I found no other implementation that has ever done this that way.

Thanks in advance
Stefan

4

Your discovery result should set the “representation property”. If this is set on the manually configured things (your handler can automatically add that property when initializing the thing), it will prevent a discovery result to show up. If this isn’t possible, the user can still click once on “ignore” in the inbox.

I need to access the ThingHandler

This is definitely not allowed to do.

Would be extending instead of implementing MDNSDiscoveryParticipant the right way?

No, if you’re device is discoverable through mDNS, implementing that interface and registering your class as a service is absolutely the right thing to do!

1 Like
5

Thanks for the hint, @Kai. Very much appreciated.

For all the others who read along: here is the documentation of what Kai mentioned:

Representation Property in Bindings
This and the following chapter explicitly explains the topic of suppressing double discovery of things.

I will try to implement that in my binding and when I am done and it is working I will post the full solution here for reference.

2 Likes
6

Once your done id like to know if this works as nearly every binding I use seems to rediscover things, and everything I have set up is textual based.

So the bindings I have that do it are:
Nest
Hue
ZWave
iCloud
DraytonWiser

I havnt delved into the code yet to see…

2 Likes
7

Hi @delid4ve,

I was able to finish and provide the fix. You can find the pull request here: https://github.com/openhab/openhab-addons/pull/7141

Basically what you have to do is

  • Add a new entry in the thing-description (which was missing in my case)
<representation-property>address</representation-property>

This is nameof the property that holds the unique identification of that particular device. In my case I am using the IP address that is discovered which is saved in the address-property.

Then in the createResultMethod() do the following

final Map<String, Object> properties = new HashMap<>(2);
String host = service.getHostAddresses()[0];
properties.put("address", host);
  • and then use .withRepresentationProperty(“address”) during creating the discoveryResult and return it
final DiscoveryResult result = DiscoveryResultBuilder.create(uid).withThingType(getThingType(service)).withProperties(properties).withLabel(service.getName()).withRepresentationProperty(CONFIG_ADDRESS).build();

Then in the case of providing the thing statically this specific attribute needs to be provided in the bracket [ attributes ] of the Thing file, e.g.

Bridge nanoleaf:controller:canvas1234 "Canvas 1234"
[ address="10.111.123.45", port=16021, authToken="mytoken", refreshInterval=60, deviceType="canvas" ]
{
    Thing lightpanel 54321 "Kitchen panel 1" [ id=54321 ]
}

in this case: address=“10.111.123.45”.

  • When you now run an autodiscovery, don’t be surprised if you still see a thing discovered for a glimpse of a second in paperui and it even says “New Inbox entry…” but it won’t show up and it is suppressed in the inbox.
  • If you wait until the end of the discovery it says “show ignored”. If you really want at that point, you can bring it up again and it appears in the inbox with a flag “ignored” which is pretty neat.

Hopefully the above description is clear enough. If not let me know.

cheers
Stefan

1 Like
8

:+1: Hopefully this will help those going forward.

Is there no way to check that a thing doesn’t exist with this representation property in the first instance and then not build it?
And this is for your Bridge thing, not device things yes?

Maybe I’m a little OCD, but even ignored inbox entries irritate me… :slight_smile:

9

Is there no way to check that a thing doesn’t exist with this representation property in the first instance and then not build it?

AFAIK, no

And this is for your Bridge thing, not device things yes?

This is for both: the bridge AND the devices

Maybe I’m a little OCD, but even ignored inbox entries irritate me…

I am actually fine with that as it opens the possibility to see what is ignored. I personally like that.

10

I noticed on the http binding there is actually a configuration that can be done on the binding itself, so it might be useful to have a way to set a discover flag on the binding itself, such that the user may decide to use discovery or not. The case where the user decides to both discover and add manual duplicates still needs to be handled though.

11

Where did you find that? I checked the http binding’s setting and there is nothing that at least I would relate to something like that. There is only

  • granularity
  • timeout
  • format
12

I think he was saying that the binding config would be a place to put such a config option. He wasn’t saying it actually was there…

13

Oh I see, thanks, I didn’t get that.

14

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