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?
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 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.
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!
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.
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.
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.
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…
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.
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