Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a new optional input parameter to discovery services #4389

Merged
merged 2 commits into from
Sep 29, 2024

Conversation

lolodomo
Copy link
Contributor

Related to #4388

Signed-off-by: Laurent Garnier [email protected]

@lolodomo lolodomo requested a review from a team as a code owner September 25, 2024 20:58
* @param input an input parameter to be used during discovery scan
* @param listener a listener that is notified about errors or termination of the scan
*/
void startScanWithInput(String input, @Nullable ScanListener listener);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that I added a new method rather than adding a new parameter to the existing method startScan because this method is called by few bindings.
But it is also possible to only update the existing method and prepare a fix for existing bindings.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason not to overload the startScan method ?

void startScan(@Nullable ScanListener listener);
void startScan(String input, @Nullable ScanListener listener);

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, method renamed.

There is still the method void startScanWithInput(String input), the main method that will be overriden in a binding. Before renaming it into startScan, I have to check if we have bindings declaring such method.

Copy link
Contributor Author

@lolodomo lolodomo Sep 26, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.


$ find */src -name "*.java" -exec grep -H "void startScan(" {} \; | grep -v "void startScan()"
org.openhab.binding.russound/src/main/java/org/openhab/binding/russound/internal/rio/system/RioSystemHandler.java:    private void startScan(RioSystemConfig sysConfig) {
org.openhab.binding.webthing/src/main/java/org/openhab/binding/webthing/internal/discovery/WebthingDiscoveryService.java:    private void startScan(boolean isBackground) {

Ok, there should be no risk I believe. I will rename also the last remaining startScanWithInput.

Copy link
Contributor Author

@lolodomo lolodomo Sep 26, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Every occurrence of startScanWithInput is now renamed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To come back to my initial comment, in case you would prefer to not add a new method but rather add a parameter to the existing method, I checked how many bindings should be updated. Only five: easee, gardena, homematic, hue and lutron. So not a big deal. Let me know what you prefer.

$ find */src -name "*.java" -exec grep -H "startScan(" {} \; | grep -v "startScan()"
org.openhab.binding.easee/src/main/java/org/openhab/binding/easee/internal/handler/EaseeSiteHandler.java:            discoveryService.startScan(null);
org.openhab.binding.gardena/src/main/java/org/openhab/binding/gardena/internal/handler/GardenaAccountHandler.java:                discoveryService.startScan(null);
org.openhab.binding.homematic/src/main/java/org/openhab/binding/homematic/internal/handler/HomematicBridgeHandler.java:                discoveryService.startScan(null);
org.openhab.binding.hue/src/main/java/org/openhab/binding/hue/internal/handler/Clip2BridgeHandler.java:                discoveryService.startScan(null);
org.openhab.binding.lutron/src/main/java/org/openhab/binding/lutron/internal/handler/IPBridgeHandler.java:                discoveryService.startScan(null);
org.openhab.binding.modbus/src/main/java/org/openhab/binding/modbus/discovery/internal/ModbusDiscoveryService.java:            scanStarted |= service.startScan(this);
org.openhab.binding.modbus/src/main/java/org/openhab/binding/modbus/discovery/internal/ModbusEndpointDiscoveryService.java:    public boolean startScan(ModbusDiscoveryService service) {
org.openhab.binding.modbus/src/main/java/org/openhab/binding/modbus/discovery/internal/ModbusThingHandlerDiscoveryService.java:    boolean startScan(ModbusDiscoveryService service);
org.openhab.binding.russound/src/main/java/org/openhab/binding/russound/internal/rio/system/RioSystemHandler.java:                    startScan(rioConfig);
org.openhab.binding.russound/src/main/java/org/openhab/binding/russound/internal/rio/system/RioSystemHandler.java:     * {@link #startScan(RioSystemConfig)} when a device should be scanned and 'things' discovered from it
org.openhab.binding.russound/src/main/java/org/openhab/binding/russound/internal/rio/system/RioSystemHandler.java:    private void startScan(RioSystemConfig sysConfig) {
org.openhab.binding.webthing/src/main/java/org/openhab/binding/webthing/internal/discovery/WebthingDiscoveryService.java:        startScan(true);
org.openhab.binding.webthing/src/main/java/org/openhab/binding/webthing/internal/discovery/WebthingDiscoveryService.java:    private void startScan(boolean isBackground) {
org.openhab.binding.webthing/src/main/java/org/openhab/binding/webthing/internal/discovery/WebthingDiscoveryService.java:        startScan(false);

@lolodomo
Copy link
Contributor Author

lolodomo commented Sep 25, 2024

I tested it with success with a modified version of the astro binding.

@digitaldan : what you have to do for matter binding in your discovery service is calling the constructor of AbstractDiscoveryService with 2 additional parameters, the label and description of your discovery input parameter (pairing code). You can even use @text/xxx + entries in your properties file to have translated label and description returned by the new REST API (that will be used by Main UI).
And finally you have to override and implement this method:

    void startScan(String input)

@lolodomo
Copy link
Contributor Author

This is almost finished, I have in mind to add unit tests for the discovery REST API. I will add them later this week.

@lolodomo
Copy link
Contributor Author

For your information, I was able to build the full addons repo with these core changes (my build was done without running tests).

@digitaldan
Copy link
Contributor

Thanks @lolodomo , i am going to take a look at this tomorrow!

@lolodomo lolodomo force-pushed the discovery_param branch 2 times, most recently from f3a9d02 to 390b80a Compare September 26, 2024 10:16
Copy link
Contributor

@florian-h05 florian-h05 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks!
The new API endpoint provides everything that is required I think 👍

Comment on lines +135 to +136
return JSONResponse.createResponse(Status.NOT_FOUND, null,
"No discovery service found for binding " + bindingId);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure if I should rather return Response.status(Status.NOT_FOUND).build()
I find the two approaches used in core framework without understanding which one is the most adapted.

Using JSONResponse.createResponse allows returning a JSON with an error message in addition to the simple HTTP status.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would prefer your current approach because it provides the additional info, which is more user-friendly, but TBH I don’t know if anyone really „reads“ that response.

Copy link
Member

@holgerfriedrich holgerfriedrich left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Otherwise, LGTM!

@holgerfriedrich holgerfriedrich added the enhancement An enhancement or new feature of the Core label Sep 28, 2024
Copy link
Member

@holgerfriedrich holgerfriedrich left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks!

@digitaldan shall I wait for your feedback or can I merge this?

@digitaldan
Copy link
Contributor

Thanks @lolodomo looks great, @holgerfriedrich LGTM 👍

@holgerfriedrich holgerfriedrich added rebuild Triggers the Jenkins PR build and removed rebuild Triggers the Jenkins PR build labels Sep 29, 2024
@holgerfriedrich holgerfriedrich merged commit b8b3ec9 into openhab:main Sep 29, 2024
5 checks passed
@holgerfriedrich holgerfriedrich added this to the 4.3 milestone Sep 29, 2024
@lolodomo lolodomo deleted the discovery_param branch September 29, 2024 12:51
@lolodomo
Copy link
Contributor Author

@florian-h05: you can now implement the UI part ;)

@@ -133,6 +162,21 @@ public Set<ThingTypeUID> getSupportedThingTypes() {
return supportedThingTypes;
}

@Override
public boolean isScanInputSupported() {
return scanInputLabel != null && scanInputDescription != null;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lolodomo
I think the goal of this implementation was to automatically return true if label and description are provided.
This however does not work at the moment, you rather need this:

        return getScanInputLabel() != null && getScanInputDescription() != null;

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the difference?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When using the methods instead of the classes private fields, isScanInputSupported will return true if both the label and the description methods are overwritten in a child class. With the current implementation, this is not the case, thus requiring a child class that already provides label and description trough the methods to also overwrite the isScanInputSupported method.
I will create a PR to fix that.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#4393 is merged

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For your information, the idea is absolutely not to override getScanInputLabel and getScanInputDescription in a binding, but only to provide label and description in the constructor of the binding discovery service.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense ... sorry for the chaos.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By the way, your change is not a problem ;)

florian-h05 added a commit to florian-h05/openhab-webui that referenced this pull request Sep 30, 2024
@florian-h05
Copy link
Contributor

UI part is implemented: openhab/openhab-webui#2771

florian-h05 added a commit to openhab/openhab-webui that referenced this pull request Sep 30, 2024
florian-h05 added a commit to florian-h05/openhab-core that referenced this pull request Sep 30, 2024
…covery services

Fixes an issue from openhab#4389.
For more details see openhab#4389 (comment).

Signed-off-by: Florian Hotze <[email protected]>
holgerfriedrich pushed a commit that referenced this pull request Sep 30, 2024
…covery services (#4393)

Fixes an issue from #4389.

Signed-off-by: Florian Hotze <[email protected]>
jlaur added a commit to jlaur/openhab-addons that referenced this pull request Oct 1, 2024
Regression of openhab/openhab-core#4389

Signed-off-by: Jacob Laursen <[email protected]>
lsiepel pushed a commit to openhab/openhab-addons that referenced this pull request Oct 1, 2024
Regression of openhab/openhab-core#4389

Signed-off-by: Jacob Laursen <[email protected]>
joni1993 pushed a commit to joni1993/openhab-addons that referenced this pull request Oct 15, 2024
Regression of openhab/openhab-core#4389

Signed-off-by: Jacob Laursen <[email protected]>
matchews pushed a commit to matchews/openhab-addons that referenced this pull request Oct 18, 2024
Regression of openhab/openhab-core#4389

Signed-off-by: Jacob Laursen <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement An enhancement or new feature of the Core
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants