Andrew_Rowe
September 16, 2023, 1:35am
200
It seems auto discovery of bindings/things is one of the major differences with the other popular home automation system. The idea of automatic discovery has already been considered. Is this something that is a breaking change that would require waiting for a major release? Would individual binding developers need to do anything for their bindings to work? I realize it can’t work with all bindings. Could this at least be used for some of the more popular bindings?
Here is a link to the github (still open) issue started in 2021 (by Kai) discussing the idea (that Rich already linked)
opened 12:24AM - 26 Dec 21 UTC
closed 04:32PM - 07 Dec 23 UTC
I'm creating this issue as [I mentioned an idea](https://github.com/openhab/open… hab-addons/pull/11834#issuecomment-1000441090) over in another discussion. I haven't detailed it out in any way, but we could use this issue to discuss whether it makes any sense to pursue it at all.
The rough outline is: Many "Things" can be discovered nowadays through mDNS+UPnP. openHAB currently only adds them to the Inbox, if the user has already installed the according add-on(s). Especially for new users, it would be very nice if this wouldn't be possible: openHAB could identify supported devices and suggest the user to install certain add-ons instead (e.g. as a step in the setup wizard that @ghys created with the main UI).
There might be different ways to realize this:
1. The bindings currently implement a `DiscoveryParticipant` service. These are usually in a separate package and pretty independent of the other binding code. We could create a single new bundle in openhab-core that contains all these `DiscoveryParticipant`s and which is part of the default installation. The problem with this approach would be that add-on specific code would have to be added to openhab-core as well. This is imho neither from an architectural point of view nor from a contribution process a desired setup.
2. We could come up with some new concept, like additional metadata within the openhab-addons repo, which only contains the discriminators that are required to identify a supported device from a mDNS/UPnP info object. This metadata could be made available as a file (or files in a folder) to the distro and some generic core feature, which evaluates this data and that is capable to provide a list of add-ons to the UI that the user might want to install. While this approach won't be able to directly add Things to the Inbox, it might be a suitable way to also bridge the gap between discovery and still requiring the user to install the add-on before a discovery result can anyhow be accepted.
Let me know what you think!
Edit: I like the idea of a Addon Suggestion Service
2 Likes
