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

Minor extension to generic ip discovery #3943

Merged
merged 9 commits into from
Feb 14, 2024

Conversation

holgerfriedrich
Copy link
Member

@holgerfriedrich holgerfriedrich commented Dec 20, 2023

Add new replacement $uuid in request frame.
This is needed for discovery of ipcamera devices.

Add new parameter listenPort (required for govee).

Add new parameter requestPlain as alternative to request (enhance readability of request for text/xml/json based req., govee and ipcamera)

Improve resource handling:

  • autocloseable
  • restrict to 5 addresses (moved to next PR)
  • respect system.config.network.useOnlyOneAddress setting (moved to next PR)

Refs: #3936

@holgerfriedrich holgerfriedrich requested a review from a team as a code owner December 20, 2023 20:55
@holgerfriedrich
Copy link
Member Author

@Skinah FYI

@Skinah
Copy link
Contributor

Skinah commented Dec 26, 2023

Thank you for the changes.

@holgerfriedrich holgerfriedrich changed the title [WIP] Minor extension to generic ip discovery Minor extension to generic ip discovery Dec 27, 2023
@andrewfg
Copy link
Contributor

@holgerfriedrich the ZWay binding is probably a candidate to be suggested via your IP addon finder. => WDYT?

https://github.com/openhab/openhab-addons/tree/main/bundles/org.openhab.binding.zway#discovery

@holgerfriedrich
Copy link
Member Author

@holgerfriedrich the ZWay binding is probably a candidate to be suggested via your IP addon finder. => WDYT?

https://github.com/openhab/openhab-addons/tree/main/bundles/org.openhab.binding.zway#discovery

Sorry, @andrewfg, I got you wrong in my first reply. Let's discuss this #3936. I will copy your comment to the other issue.

@holgerfriedrich
Copy link
Member Author

@mherwege I think this PR is ready for review. It contains extensions needed for govee and ipcamera bindings. @stefan-hoehn just confirmed it working for govee and approved my PR openhab/openhab-addons#16109.

@andrewfg
Copy link
Contributor

andrewfg commented Dec 27, 2023

support / test if we go for zwave instead...

Just for the avoidance of doubt:

  • The Z-Wave binding is based on a Z-Wave USB stick attached to the PC which will be suggested by my USB finder.
  • The ZWay binding is based on a Z-Wave bridge server somewhere on the LAN which would be suggested by your IP finder.

@holgerfriedrich
Copy link
Member Author

holgerfriedrich commented Dec 28, 2023

@mherwege Could you please take a look at this?
The PR contains minor extensions needed for govee and ipcamera.
Additionally, it improves the resource behavior (autocloseable DatagramChannel).

@wborn wborn added the enhancement An enhancement or new feature of the Core label Dec 30, 2023
@holgerfriedrich holgerfriedrich force-pushed the pr-addonfinder-ip branch 2 times, most recently from 4079156 to 1df3889 Compare January 4, 2024 21:58
@holgerfriedrich
Copy link
Member Author

@openhab/core-maintainers could you pls have a look? Auto-detect for 2 add-ons is depending on additional functions introduced in this PR:

Thanks a lot!

@mherwege
Copy link
Contributor

In principle, this LGTM.

But I am wondering if we should not introduce use of #3981 at the same time. As we add requests being sent out to all interfaces, we should probably restrict the interfaces before getting too much into trouble.

@holgerfriedrich
Copy link
Member Author

@mherwege thanks for looking into this.

But I am wondering if we should not introduce use of #3981 at the same time. As we add requests being sent out to all interfaces, we should probably restrict the interfaces before getting too much into trouble.

I had implemented a fallback to the main interface in case too many interfaces were found, but removed it for now to keep the PR cleaner.
I am in doubt that we would see an issue here because the requests are strictly sequential: we sent only one frame every few seconds (timeout is currently set to 5sec).

What we will need to think about - but for me it is not yet scope of this PR - is either shortening the timeouts or doing requests more or less in parallel. Otherwise we will not finish the scan before the wizard suggests plugins during when OH is installed.

@mherwege
Copy link
Contributor

mherwege commented Jan 14, 2024

I had implemented a fallback to the main interface in case too many interfaces were found, but removed it for now to keep the PR cleaner.

Agree to keep it out of here, but that’s where it should probably be in sync with the work on #3981, so for a follow-up PR.

What we will need to think about - but for me it is not yet scope of this PR - is either shortening the timeouts or doing requests more or less in parallel. Otherwise we will not finish the scan before the wizard suggests plugins during when OH is installed.

Maybe define CompletableFutures with timeout for each request and start them in parallel. Agree we will need more throughput on this. We can delay initial configuration in the UI a bit, showing a preparing screen, within reason.

@holgerfriedrich
Copy link
Member Author

@mherwege @andrewfg should we go forward merging this PR as it is?
Obviously, there is more work to do as described in #3936. This is just a first step.

@andrewfg
Copy link
Contributor

I would suggest to use CompletableFuture as @mherwege suggests. Then the scans can all be executed in parallel on separate threads.

@mherwege
Copy link
Contributor

I would suggest to use CompletableFuture as @mherwege suggests. Then the scans can all be executed in parallel on separate threads.

I tend to agree here. It now becomes easy to add discovery info to add-ons. If a number of them are added in the addon repo, suddenly we have code running a sequence of scans potentially each timing out. We should avoid having to come back to this quickly when discovery info gets added to the addon.xml files.

@andrewfg
Copy link
Contributor

suddenly we have code running a sequence of scans potentially each timing out

In particular in OH core, there should be no long running processes on main threads.

@andrewfg
Copy link
Contributor

I am thinking that the approach below would perhaps be appropriate..

openhab/openhab-addons#16315

@mherwege
Copy link
Contributor

mherwege commented Feb 2, 2024

I think there even is a bigger theme for OH and networking to look at. I created an issue for it, but have had little response so far: #4047
Anyway, whatever direction that issue goes, already working on concurrency would be a big improvement.

@openhab-bot
Copy link
Collaborator

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

https://community.openhab.org/t/oh-4-1-1-startup-takes-more-than-an-hour/153310/33

Copy link
Contributor

@andrewfg andrewfg left a comment

Choose a reason for hiding this comment

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

@holgerfriedrich apropos threading .. to be a bit more helpful I would suggest refactoring your code lines 265..395 into a separate method, and at line #264 call that method via something like List<Future> myFutures .. add(scheduler.submit(() -> thatMethod())).

And on shutdown you should also do myFutures.forEach(f -> cancel());

Signed-off-by: Holger Friedrich <mail@holger-friedrich.de>
Signed-off-by: Holger Friedrich <mail@holger-friedrich.de>
Signed-off-by: Holger Friedrich <mail@holger-friedrich.de>
Signed-off-by: Holger Friedrich <mail@holger-friedrich.de>
Signed-off-by: Holger Friedrich <mail@holger-friedrich.de>
Signed-off-by: Holger Friedrich <mail@holger-friedrich.de>
Signed-off-by: Holger Friedrich <mail@holger-friedrich.de>
Signed-off-by: Holger Friedrich <mail@holger-friedrich.de>
Signed-off-by: Holger Friedrich <mail@holger-friedrich.de>
@holgerfriedrich
Copy link
Member Author

I agree that better handling of multiple addresses and interfaces is desired for IP discovery. Which solution to implement is not yet clear, maybe there will be a result out of #4047.

Parallelization is required as well when more add-ons start using this. Thanks, @mherwege and @andrewfg for pointing at CompletableFuture and implementations. There are some technical questions not yet clarified, e.g. how to make sure that discovery of different add-ons at the same time does not cause problems. Just imagine two add-ons using the same server port, etc...

I still think that both is out of scope of this PR and tracked #3936.

The PR adds new config options and has already been validated with the corresponding add-on.

@andrewfg
Copy link
Contributor

andrewfg commented Feb 14, 2024

@holgerfriedrich HERE is some code to do the scans asynchronously (not tested).

Copy link
Member

@wborn wborn left a comment

Choose a reason for hiding this comment

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

Thanks for the extension!

@wborn wborn merged commit 40e6202 into openhab:main Feb 14, 2024
3 checks passed
@wborn wborn added this to the 4.2 milestone Feb 14, 2024
@andrewfg
Copy link
Contributor

@holgerfriedrich shall I convert my code to a new PR?

@holgerfriedrich
Copy link
Member Author

@holgerfriedrich shall I convert my code to a new PR?

Thanks, @andrewfg. I have created #4094 based on your example above. Hope you are fine with that.

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.

6 participants