script.kodi.hue.ambilight
script.kodi.hue.ambilight copied to clipboard
Allow Hue to be added by IP in settings Dialog
Users who have their HUE bridges on different (V)LAN won't be discovered due to the broadcast nature of the discovery protocol. Allow manual addition by IP in config dialog. Currently it's required you set the IP in the config file manually.
This will be very helpful!
As an extended-comment from the previous issue with this specific "improvement request",
I think you don't realize how trivial and easy is this feature to implement, Kodi 17.x+ are merely 5-6 lines of code.
I would not bother reposting feat. request, I'd do it myself. A couple ifdef to know if IP was auto/manually found, a setting prop, and it's DONE.
I won't go into a long stance about Free Software, Free Work, Free Man-Hours, but this is legit the "DIY land", just being passive and asking for stuff, won't make things happen, I'm pretty sure the sole fact plugin maintainer is a bit distant/discouraged is because there's literally no backing-up from the developer-side.
I'm not blaming you for posting @aenertia but your linkedin profile shows you're a fully grown man AND engineer, be it networking, you know enough to add this feature yourself and help a brother out.
Here's a fun fact, this plugin is free and open-source so nobody cares and puts lots of expectations on "its/their" author, if it were close-sourced AND not-free; people would either crack it OR make an open-source recode because "huh, i'm not paying for a kodi add-on".
Judging at how "popular" this plugin got, a paid version would've make a good amount of $$ (since unlike many solutions, this one is fully self-embed, you don't need to run additional stuff on a home-made server) and possible motivation, but right now instead of making money, there's literally people spamming the issues about networking hazards and implying not having IoT devices on a separate VLAN is madness / stupidity, or whatever.
In the end being into "computers" is just being a lazy c00nt, is the trade-off of doing it yourself VS editing a .cfg file really worth investing time to add a setting entry, it seems like plugin author don't, I can say I don't, and the two requests for this feature should be whom are the most concerned.
/vent off, please don't smother this project 👍
!suggest - turning off issues/bug tracker if you don't want to manage them;
forking - creating a properly formatted patch off my fork and submitting it. Is less trivial a change than you make it seem. It includes a significant amount of socializing the change, ensuring it makes sense based on the original code base coding conventions and user preferences.