Start discovery with a parameter (like a pairing code in case of Matter)

[lolodomo]

The Matter binding being developed by @digitaldan requires to fill a pairing code when scanning for a new device. My feeling is that we need a new optional input field in Main UI to fill this parameter just before clicking the Scan button.

Main UI will then pass this parameter, if filled by user, to the REST API.

@digitaldan : please first confirm that it is THE solution.

If we go in that direction, I can do the work in core framework (enhancing REST API with a new parameter and handling this parameter in the discovery stuff), keeping a backward compatibility for all existing binding discovery (parameter will be ignored). But then we would need for your help @florian-h05 to update this screen. Are you volunteer for that?

@digitaldan : finally you will just have to override in your binding a new method void startScan(String scanParameter) in your discovery class.

WDYT ?

[florian-h05]

I'm in for the UI part. I guess Dan could do this as well but I think he is busy enough with the Matter binding itself.

By enhancing the REST API, does this include to provide the UI with the information whether a pairing code is required? Even better would be to also provide information about the pairing code format, e.g. a description and a RegEx for validation through the REST API. The binding could provide this through config descriptions to core. This would make it as flexible and user friendly as possible.

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/incorporating-matter/127907/140

[lolodomo]

By enhancing the REST API, does this include to provide the UI with the information whether a pairing code is required? Even better would be to also provide information about the pairing code format, e.g. a description and a RegEx for validation through the REST API. The binding could provide this through config descriptions to core. This would make it as flexible and user friendly as possible.

That is a good idea but that makes the stuff more complex than I imagined.

This could be a new discovery GET API for a binding returning these information: GET discovery/bindingId

[florian-h05]

Yeah it’s relatively complex on the core side, but I at least want the information whether to display such an input … I don’t want to display it always, because this would confuse the user and clutter the UI.

[digitaldan]

I have not thought too much about it, but as far as the internal framework, i guess it would be nice if a binding advertised that it supported a discovery code through org.openhab.core.config.discovery.DiscoveryService, much like we have "isBackgroundDiscoveryEnabled" maybe "isAdditionalCodeEnabled" ? Then "startScan" could pass this code in as a optional parameter.

In the UI i could see when picking the binding type and scanning this being an option. It would also be great in the UI to allow the user to enter this code OR take a picture of of a QR code for the text (very common now).

[lolodomo]

i guess it would be nice if a binding advertised that it supported a discovery code through org.openhab.core.config.discovery.DiscoveryService, much like we have "isBackgroundDiscoveryEnabled" maybe "isAdditionalCodeEnabled" ? Then "startScan" could pass this code in as a optional parameter.

Yes, good idea.

[florian-h05]

Good idea Dan.

I think we should extend the DiscoveryService interface with a requiresPairingCode method with a default implementation that returns false (to avoid having to adjust too much binding code) and add an override for the startScan method to allow passing the pairing code.

Next the DiscoveryResource should be extended:

• Add a new GET /bindings/{bindingId} endpoint that returns discovery information for the binding such as whether background discovery is enabled, whether a pairing code is required etc.
• Extend the POST /bindings/{bindingId}/scan endpoint to add a path parameter pairingCode that can be passed to startScan

Finally, it would be really nice if a binding could provide a description for the pairing code so the UI could tell the user the required format.

[florian-h05]

Please let me know what you think, especially any ideas wrt to the implementation of the description are highly welcomed! I think I can take a look at implementing the core side as well as the UI side next week when I am back from vacation!

[lolodomo]

I have almost finished the implementation in core framework. I will push something before the weekend.

[digitaldan]

interface with a requiresPairingCode method with a default

I was actually staying away from "required" so that the discovery service of a binding could support both scanning with and without a code, but i agree this should be default false and not necessary for most bindings to handle.

[digitaldan]

Just FYI this will be very nice for the matter binding. I'm working on prototyping an IOS extension that will use the built in matter/thread framework in IOS 16 to detect new matter devices via bluetooth, then allow the user to add them to the Wifi or Thread network, then commission them to the Matter fabric. I'll end up using this new discovery feature for the Matter Fabric part, so once we get them onto the Wifi or Thread network, i can call the discovery API with the pairing code from the IOS client, and openHAB will take care of the rest !

[florian-h05]

I was actually staying away from "required" so that the discovery service of a binding could support both scanning with and without a code

I wonder whether there is a binding (or better a „system“) that supports both cases …

Your iOS extension sounds super nice!

[cdjackson]

I wonder whether there is a binding (or better a „system“) that supports both cases …

If I understand the question correctly, then the answer is yes. Zigbee can either use a device specific pairing code / key, or it can use a generic key. Most devices use the generic key, but the device specific code is becoming more popular. Both will be needed though for Zigbee.

[florian-h05]

Thanks for the info, I think you understand the question right. How is the generic key provided to the binding?

[lolodomo]

My current implementation makes the input required or not. I will change it to make it optional. It is just a test to change and a method to rename. I will push my current code this evening for review as I see a lot of interest and impatience ;)

[lolodomo]

Feature is now implemented