Request - Add new color-format for color gradients

[Clon1998]

Hey guys, I am working a lot with single addressable RGB-Strips like NeoPixels. Currently, whenever I want to use a color gradient I have to pre-define them and use an enum property to set them while at the same time using another color-property if I want to set a normal RGB-color. Because of that I am kinda limited to the predefined gradients. Because of that, I would love to see an additional color-format e.g. 'gradient' to be able to set custom gradients / user-created gradients. And at the same time it would merge the normal color property into it as well.

Regarding the payload, I would suggest using a format like FastLED does with it macro to define color gradients (https://github.com/FastLED/FastLED/wiki/Gradient-color-palettes). E.g. taken from FastLEDs wiki Payload: 0,0,0,0,128,255,0,0,224,255,255,0,255,255,255,255

[piegamesde]

I'd prefer a color-gradient datatype, because gradient is not a real color space. This would also allow different kinds of gradients (equally distributed vs positional).

[krocans]

Hi! I think asking and adding all this formats to convention is a way to dead end. Looks like people sometimes forget it's convention not application and not even a particular library. As I understand everything in convention MUST be supported in any implementation (library) to be Homie compatible. That means every piece of software must be able to parse, compose and perform VALIDATION of values for all those types. That means in one moment this will not fit anymore in performance/RAM of some tiny IOT device. For example i think time and interval is integer (unixtime) and another integer (number of seconds) or you can use float if you need or treat it as years not seconds whatever you need for your purpose. For Homie layer let it remain integer or float application should take care of it. And this one - let it be string for Homie. Your application should take care how to process this string value for that particular property. Every single Homie software in the world dos not need to support and understand this format. So i guess everything that's added after "Color" to convention is unnecessary. And even color is just 3 integers and what if somebody needs more precision than 8 bit per component :).

[Clon1998]

Why should this matter? The only piece of software that needs to support and validate all types and formats would be a server/controller and those are most likely running on more powerful hardware?

A developer/client can choose to just not use those things for the specific device since it does not provide any property with these formats?

If gradient is added as a new type/format the developer of a client can be sure that any controller is able to control the device since it is a standard.

[piegamesde]

@krocans has a point there. This adds a bit of weight to the specification that centers around one pretty specialized use case. There are many similar features one could add for different purposes that would simply bloat the spec. How about creating an extension specific to LED illumination? Maybe it could include:

• More color spaces
• Different gradient types
• Color palettes

---

I've dug through old issues about this and similar topics:

• Controlling RGB LED stripes in some way or another is a relatively common use case
• Some kind of array feature would be a pretty good fit for this kind of problem. Homie once had arrays, but they were removed for now until there is a good way to implement them
• For more complex data types, a custom data format (mainly JSON, but could be other or even binary) should be used. There is no need to formalize every possible value that one could set a property to.

[krocans]

@Clon1998 every tiny device should do all this. For example again time. What's more simple to send an receive integer unixtime or convert to ISO an back? Also validating any input data is just good style :). If it's receiving let's say color what should it do on receiving RGB color "col,orc,olo"? Should it try dumb convert "col" to integer assuming that "there must be only digits" an crash?

[Clon1998]

@krocans I disagree that every client-device has to implement all data types and formats even though it is only using a fraction of them e.g. why should a homie-doorbell be bother about a color data type as long as it's not using it?

But as you mentioned if a device uses a data type it definitely should validate the incoming messages.

I think @piegamesde is right I'll think about creating an extension for addressable LEDs so even though I am not convinced by you're point @krocans by using an extension the client can actively choose to support it or not.