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

AddonSuggestionFinder component for KNX #3912

Closed
holgerfriedrich opened this issue Dec 11, 2023 · 6 comments
Closed

AddonSuggestionFinder component for KNX #3912

holgerfriedrich opened this issue Dec 11, 2023 · 6 comments
Labels
enhancement An enhancement or new feature of the Core

Comments

@holgerfriedrich
Copy link
Member

holgerfriedrich commented Dec 11, 2023

KNXnet/IP devices can be discovered using multicast traffic to IP 224.0.23.12, port 3671.

A draft implementation of a finder has already been mentioned in #3806 (comment).
It is quite simple, opening a socket, preparing a frame, send it out, and wait a while for responses.

The question is if we want an AddonSuggestionFinder which is very specific to a single binding.

A generalization would be possible, but more complicated. For a more generic "IP" finder, more information like target IP, content of search frame, and expected response could be stored in the match properties of addon.xml. However, it already starts getting complicated already when port or IP address needs to be placed dynamically into the frame.

Not sure if this is worth the effort, as I cannot judge for which addons this could be useful.

@holgerfriedrich holgerfriedrich added the enhancement An enhancement or new feature of the Core label Dec 11, 2023
@holgerfriedrich
Copy link
Member Author

@mherwege @andrewfg @kaikreuzer Could you share your opinion in this?
@kaikreuzer What is the deadline for the implementation / merge to make it for 4.1 release?

@mherwege
Copy link
Contributor

I don't think introducing binding specific finders in core is the way to go. Therefore, if we ever want to do it this way (creating binding specific logic), I would argue we would need a special class of add-on in the add-on repository for a finder and install and run them all by default (otherwise it does not make sense, if you first have to manually install a finder to find something you can install the add-on just as well).
In my view, we should do it if it can be generalized. And I do think there may be other bindings that would benefit from it (sending an IP broadcast frame and expecting a response). I myself coded such logic in the nikohomecontrol binding. Version 1 of the system was only discoverable in this way. Version 2 can also be discovered using mDNS. The binding however uses the IP (UDP) broadcast for discovery and does some packet analysis on it.
I think the best way forward here is to go and look for all bindings that do this kind of discovery and analyse what is being sent and how the result is interpreted analysed. If there is commonality in at least some of them, we could define additional discovery criteria parameters in the xml and implement a general finder that uses these.
If you ask me, I think this will be after a 4.1 release. While I see value, I believe it needs more analysis to decide on what to do.
This, of course, is just my view and I want to hear the opinion of others.

@kaikreuzer
Copy link
Member

I fully agree to everything @mherwege said. 😎

@holgerfriedrich
Copy link
Member Author

Then let me give it a try, I want to see this working for KNX ;-)

@andrewfg
Copy link
Contributor

@mherwege I guess the other next big task is to handle the marketplace addons. I really have no experience of that, but I assume there is also an AddonInfoProvider that parses the marketplace jars resp. kars which are located somewhere in the cloud, presumably normally on GitHub??

@mherwege
Copy link
Contributor

@mherwege I guess the other next big task is to handle the marketplace addons. I really have no experience of that, but I assume there is also an AddonInfoProvider that parses the marketplace jars resp. kars which are located somewhere in the cloud, presumably normally on GitHub??

@andrewfg We should probably take this discussion to the general issue and not discuss it on this PR. Already some comments:

  • I think it is quite easy to extend the 3rd-party add-on provider to be discoverable through the mechanism. If I am not mistaken, it relies on a JSON structure with add-on info. I think including that makes sense (and would only show in the add-on store as you need to configure a 3rd-party add-on provider first).
  • Marketplace add-ons would be more of a challenge. All info is automatically collected from the post in the forum. It scans the post. You would probably need to prescribe some formatting or tagging to make this work. At the same time, I am not entirely convinced we should do it. Marketplace add-ons are less vetted and may have lower quality. Do we want to suggest all of these automatically? At the moment, I would still leave that decision to the end user. I don't see Marketplace add-ons as the first thing to use for a totally new user.

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

No branches or pull requests

4 participants