-
-
Notifications
You must be signed in to change notification settings - Fork 428
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
Comments
@mherwege @andrewfg @kaikreuzer Could you share your opinion in this? |
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). |
I fully agree to everything @mherwege said. 😎 |
Then let me give it a try, I want to see this working for KNX ;-) |
@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:
|
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.
The text was updated successfully, but these errors were encountered: