-
-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
Request : Implement HEX in JSON-API #975
Comments
I should have probably considered using HEX for the color format as in While I could add the API accepting HEX values as the input, outputting them is likely not practical at this point (for backwards compatibility, we can't just switch over since it would break compatibility with existing sofware) and I also don't want to add both, because that would be redundant information and we can't afford the JSON API response becoming longer (it would mean we have to reduce the number of max. segments). Right now I don't have a good solution, but I'll think some more if there is something that can be done. |
Forgive me if I'm not understanding this correctly but why "as in" your example and not simply as in |
Hmm ok clear to bad, in basic I can use the http api to send hex and convert RGB from JSON back to hex for iobroker. Native would be better but also understand the need to keep the JSON light |
@DutchmanNL well I can at least add the capability to WLED to accept HEX colors via JSON, so that you and others don't have to use the HTTP API just for that. Just outputting them is an issue as it bloats the state object up a bit. @Legsmaniac you are correct, a single HEX color has the format |
Ahhhhhh! Thank you for the clarification. I knew I must have been missing something! Doh! In that case, I'd say stick with the current RGB system and avoid bloat. There are plenty online RGB/HEX conversion calculators and colour pickers we can use. There's even apps for them! 🙃 |
Guys, Sorry but don't get me wrong the reason behind this makes totally NO sense at all !!!! But please keep in mind, every iOT system / programmer etc how wants to adopt your software and API will struggle with this behavior as its not an common practice at all. A propper way would have been to follow the REST-API principles and have separated values (which these are !) also separate in REST-JSON api format. In addition, if you send RGB or HEX doesn't matter, would be happy to have it accepted by the JSON but even here the current HTTP-API ist much more efficient. Please consider all the work needed in local code... i will just use the HTTP-Hex for now, in iOT systems very simple I have a Hex value and fire the HEX value to you... function done. But please keep al the other arguments mentioned both in mind, this structure makes it difficult for every programmer who wants to integrate this solution |
WLED now accepts HEX colors in json api commands in latest master :) Still holding back on breaking changes (state object will continue to send out the RGB array format for now), but maybe that could be changed in 0.12. If I absolutely have to make breaking changes, I want to consolidate them so that clients don't have to adapt too often :) |
@Aircoookie awsome need to test it how it works out and integrate |
I can't seem to get this to work for individually addressing LEDs. Is that to be expected? For instance:
|
@fguchelaar thank you for the suggestion! Hex format for individual LED control is now supported in version 0.13.0-b2 :) Closing this issue, as no breaking changes to the data sent by WLED are intended for the time being. I managed to resolve the memory issue internally without changing the API. Further discussion is however encouraged :) |
cool than I can remove that translation from my code :) |
For ioBroker integration I currently calculate RGB to HEX and vice versa as most color pickers and iOT systems are using HEX values.
Can you please integrate the HEX values also into the JSON-API, as far I see the set command in HTTP is already working but I would like to get also the data in HEX values by API instead of calculating it afterwords.
The text was updated successfully, but these errors were encountered: