Smarthome: Trigger a discovery for all installed bindings at once

[afuechsel]

Currently it is only possible, to trigger a discovery for a single bindig id:

POST /rest/discovery/bindings/{bindingId}/scan

It would be useful to have a chance to trigger the discovery for all available bindings (those that are listed with GET /discovery). For example:

POST /rest/discovery/scan

[sjsf]

What problem are you trying to address with this? Or rather: what is the use-case?

Do you really think it is a good idea to start the active discovery always for _all_ existing bindings _at the same time_? Think of bindings which cause lots of network traffic/broadcasts and others which put their controllers into inclusion mode for scanning.

I'd assume that bindings which support scanning for new devices which can do that without causing much harm already support background discovery. And others intentionally don't implement it, because it is "expensive" in some way to run the discovery.

Of course you can argue that it's simply not wise to hit such a "search all" button - but I'm not convinced that it is even most of the time a good idea, having my neighbors joining my zigbee networks just because I wanted to add e.g. a new homematic device.

[afuechsel]

I would agree to "it's simply not wise to hit such a 'search all' button". The basic idea is that sometimes one is not willing to wait for the background discovery to kick in and hopefully find all things and it would be better to actively trigger a "search all" tomake sure everything available is really in the inbox.

The use case behind is a search for all bridges of several bindings at once.

[sjsf]

What about e.g. https://github.com/eclipse/smarthome/issues/3605#issuecomment-312574411? You answer simply ignored my concern about this not being a good idea even most of the time.

it would be better

I'm simply not convinced this actually _is_ "better".

[afuechsel]

I did not ignore your concern. I simply see no other way to implement a full refresh of the inbox with all installed bindings. Currently I have installed 16 bindings supporting discovery and my PR just triggers all 16 discovery services that are all gracefully executed and refresh the inbox. I don't see any reason why we should not implement such a feature, only because it might be "expensive".

[rodneyrehm]

What problem are you trying to address with this? Or rather: what is the use-case?

basically a forced refresh of the inbox triggered by qivicon UI. We've been doing this since the inbox was introduced (via internal APIs) and are simply migrating that to the REST world. We also allow the user to trigger this refresh, should they not have found what they were hoping to pair.

Do you really think it is a good idea to start the active discovery always for all existing bindings at the same time?

Not necessarily. We've often hit the case where a device connected to the network did not show up quickly enough. At the point where we provide the inbox we don't know the device a user want's to pair - that's why it's called discovery.

Think of bindings which cause lots of network traffic/broadcasts and others which put their controllers into inclusion mode for scanning.

This shouldn't be much of a problem since this is a low-frequency, manually initiated action.

I'd assume that bindings which support scanning for new devices which can do that without causing much harm already support background discovery.

In practice we've seen devices being added to the inbox with a delay. This manual triggering of discovery has been introduced (ages ago) to counter that.

And others intentionally don't implement it, because it is "expensive" in some way to run the discovery.

That's exactly the point of this. We want to provide the user with what we have before the user made a choice to pair something specific - at the exact time the user needs to know. We don't rely on the background scan. We consider it a performance improvement, but not more.

but I'm not convinced that it is even most of the time a good idea, having my neighbors joining my zigbee networks just because I wanted to add e.g. a new homematic device.

I agree completely, but I'd argue that's a problem with how the discovery/inbox is (ab)used for these sort of bindings.

[cdjackson]

but I'm not convinced that it is even most of the time a good idea, having my neighbors joining my zigbee networks just because I wanted to add e.g. a new homematic device.
I agree completely, but I'd argue that's a problem with how the discovery/inbox is (ab)used for these sort of bindings.

I'm not sure I understand this point? What is abusing the inbox - or how is it meant to be used if it's being abused?

Also, given that this issue and the related PR is not related to the inbox, but is only related to the discovery function, I'm also not sure of the link?

Another issue with this is some bindings might block or delay "normal" traffic (ie turning the lights on and off) which a discovery is active so people might inadvertently, and unknowingly, end up causing some impact on their system. If it's only a "once in a while" thing, then I can see it probably doesn't impact too much, but my concern would be that this gets abused and this causes performance issues.

[afuechsel]

@cdjackson Many features could be abused but would still be useful. I am still thinking about this feature in a way you described it best as "once in while" feature.

[rodneyrehm]

I'm not sure I understand this point? What is abusing the inbox - or how is it meant to be used if it's being abused?

maybe "abusing" is a bit harsh, sorry. My point is that the inbox was conceived to contain a list of devices that we could connect, but haven't yet. Not being connected does not only mean that it's not registered as a Thing in ESH, but also that the device itself has not been connected to us or otherwise altered in any way.

With IP based devices this never posed much of a problem as they could be found through UPnP, mDNS or similar. Discovery and pairing are disconnected from each other.

Protocols like ZigBee, Z-Wave, BidCos have a slightly different world view. Devices cannot necessarily/easily be discovered outside of the pairing process. To get these devices into the inbox they are paired to the controller (e.g. USB dongle), but not added as a Thing. At this point the device's state has been changed in such a way that it might not be able to connect to another controller. A state we have to undo on the device by unpairing it after a certain timeout. This is where the current TTL handling of simply removing a DiscoveryResult does not suffice, and which you described as hacky in #3605. Maybe the inbox/discovery just needs to be extended by the awareness of "stateful discovery". But that discussion, if desired, should happen in #3605.

I'm not sure this distinction has ever been written down anywhere. Also it's possible that my memory of this is just wrong, it has been a few years after all.

Another issue with this is some bindings might block or delay "normal" traffic (ie turning the lights on and off) which a discovery is active so people might inadvertently, and unknowingly, end up causing some impact on their system. If it's only a "once in a while" thing, then I can see it probably doesn't impact too much, […]

We're talking about an infrequent user initiated administrative action here.

[…] but my concern would be that this gets abused and this causes performance issues.

This endpoint is not introducing any DoS capability that has not been present since day one, considering nothing is keeping me from calling GET /rest/discovery and running POST /rest/discovery/{bindingId}/scan for each result. This PR is only making it easier to do that.

[afuechsel]

Closed this as it is no longer relevant