[bluetooth] Increase discovery duration and fix labels

[kaikreuzer]

15 seconds appears far too short - upon every discovery, I have a different set of BT devices in the inbox as all results are cleaned with the next discovery and many devices do not broadcast themselves within the 15 seconds range.

Also, discovery result labels must not contain labels of the bridges, but should only describe the discovered thing itself.
I see the point of hinting the user about what bridge was involved here, but we have this information in the ThingUID already.
@ghys How hard would it be for the inbox to render the id of the bridge (if any) next to the representation property? Have you already thought about such a feature?

Signed-off-by: Kai Kreuzer [email protected]

[cpmeister]

While it might appear that discovery starts a bluetooth scan it actually doesn't. The bluetooth adapters are constantly performing device scanning in order to catch beacon advertisement packets so bluetooth scanning never stops. The only thing that happens when you start a scan for bluetooth devices is that the adapters will publish their known devices to the bluetooth discovery service. The reason that it takes some time for the discovery results to trickle in is that the discovery service has to attempt connections to each of the reported devices to give the bluetooth discovery participants the information they need to create a discovery result. Connections take time and only so many connections can be done at once, so that is why the results trickle in rather than show up all at once.

That said, I have no problem extending the scan time if you think it would help. But I don't want to remove the bridge info from the label until the UI can display the bridge information in some other way.

[kaikreuzer]

The reason that it takes some time for the discovery results to trickle in is that the discovery service has to attempt connections to each of the reported devices

Could this information be cached in the discovery service so that devices that are still in reach can be added as a discovery result right away (again)?
At the moment, I am usually getting only a small list of results in the 15 secs timeframe and the list looks differently on every scan.

I don't want to remove the bridge info from the label

This really messes up the inbox result and we do not do it for other devices. I'd want to avoid that people think that's the way to do it and copy that behavior. In 95% of the cases, users will have only a single bridge anyhow.
I assume your main use case here is the roaming adapter - could we maybe at least agree on the compromise to only show this additional info for the roaming adapter, while removing it for all others?

[ghys]

@ghys How hard would it be for the inbox to render the id of the bridge (if any) next to the representation property? Have you already thought about such a feature?

Since I see the bridge UID is part of the /rest/inbox response, not hard at all. If you want the label though, or a grouping by bridge, or even the thing type label instead of the UID: a little bit harder but not rocket science either :) But I feel a lot of these may also be considered a backend responsibility to present the inbox to the UI with the "human-friendly" information to display in the list.

[kaikreuzer]

@ghys I don't see any necessity to display a label - I rather prefer the "real truth" by seeing the bridge id, just like we also show the thing type id (instead of its label). A very easy solution might hence even be to merely replace the thing type id by the discovery result UID - then we would have everything relevant visible immediately.

[kaikreuzer]

Ok, the discovery change is not required since #10187 is the proper fix.
For the discovery entry, I have created openhab/openhab-webui#920.
So closing this PR for now.