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

Request : Implement HEX in JSON-API #975

Closed
DutchmanNL opened this issue Jun 8, 2020 · 11 comments
Closed

Request : Implement HEX in JSON-API #975

DutchmanNL opened this issue Jun 8, 2020 · 11 comments

Comments

@DutchmanNL
Copy link

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.

@Aircoookie
Copy link
Owner

I should have probably considered using HEX for the color format as in ["FFA000","000000","000000"] from the get go. The RGB Integer format [[255,160,0],[0,0,0],[0,0,0]] is easier to parse, but harder to read and it also has a variable length, so HEX would have been more consistent. It's also a matter of preference though and of course the conversion is not hard.

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.

@Legsmaniac
Copy link

as in ["FFA000","000000","000000"]

Forgive me if I'm not understanding this correctly but why "as in" your example and not simply as in ["AA126A"] (which equals ["R170,G18,B106"] ?
I didn't think it was possible for 16 million shades of each colour with LED strips and even if there was, would they be that discernible? @DutchmanNL s statement "I currently calculate RGB to HEX and vice versa" would suggest to me that he's obviously using the current system of 255 values (00 to FF) of each colour since that is what it is now.
Therefore, wouldn't it be easy to add a HEX entry field in the UI together with the RGB entry field? It only requires a simple calculation to convert between the two as I'm sure you realise. 🙂

@DutchmanNL
Copy link
Author

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

@Aircoookie
Copy link
Owner

@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 "FFA000". There is an array of 3 of them, because each segment currently supports a primary, secondary and tertiary color :)

@Legsmaniac
Copy link

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! 🙃

@Aircoookie Aircoookie added this to the 0.11.0 milestone Jun 10, 2020
@DutchmanNL
Copy link
Author

DutchmanNL commented Jun 10, 2020

you are correct, a single HEX color has the format "FFA000". There is an array of 3 of them, because each segment currently supports a primary, secondary and tertiary color :)

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 !!!!
Yes I understand @Aircoookie from a programming and WLED feature point of view to have it in a 3 scaled part do enable adjustment of primary, secondary and tertiary color :)

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.
Every color picker in the world only has 1 color, have a value send as 1 array for 3 colors is very bad as every one must split it up to make it readable for other systems, and combine it back together.
( think about ioBroker, Domoticz, OpenHab, Google, Alexa, Siri/Homekit etc.... I don't see any other system in the world using this principle....)

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.
The only reasoning I can understand is the argument to not make the JSON to big, fine with that.
But combining colors in 1 array is useless for every other system please keep that in mind.

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

@Aircoookie
Copy link
Owner

WLED now accepts HEX colors in json api commands in latest master :)
Example: {"seg":{"col":["FF0000","00FF00","0000FF"]}}.
Will be added to docs tomorrow.

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 Aircoookie modified the milestones: 0.11.0, 0.12.0 Nov 20, 2020
@DutchmanNL
Copy link
Author

@Aircoookie awsome need to test it how it works out and integrate

@fguchelaar
Copy link

I can't seem to get this to work for individually addressing LEDs. Is that to be expected?

For instance:

{"seg" : { "i" : [ "FF0000" , "00FF00" , "0000FF" ] } }

@Aircoookie
Copy link
Owner

@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 :)

@DutchmanNL
Copy link
Author

cool than I can remove that translation from my code :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants