Feature: Store pre-defined color sequences for easy reference about esp_rgbww_firmware HOT 6 OPEN

Oh, when a sequence is running it would be interrupted by the next command received - either a direct POST to /color with a valid command or the exec command for the next pre-programmed sequence.

from esp_rgbww_firmware.

Rough ideas for a possible interface:

/sequence
GET returns a list of stored sequence names by name as a JSON array:
{"stored":["fireplace","party","strobe_fast","rainbow_slow"]}
POST stores a new sequence. Sequence is stored in SPIFF which should allow for plenty of space for user-defined sequences/animations.
Body:
{"name":"[A-Za-z0-9._]*",
"sequence": [
{"hsv":{"h":(HUE),"s":(SAT),"v":(VAL),"ct":(COLORTEMP,},"cmd":"(fade|solid)","t":(TIME),"d": (0|1)},
{"hsv":{"h":(HUE),"s":(SAT),"v":(VAL),"ct":(COLORTEMP,},"cmd":"(fade|solid)","t":(TIME),"d": (0|1)},
{"hsv":{"h":(HUE),"s":(SAT),"v":(VAL),"ct":(COLORTEMP,},"cmd":"(fade|solid)","t":(TIME),"d": (0|1)},
{"hsv":{"h":(HUE),"s":(SAT),"v":(VAL),"ct":(COLORTEMP,},"cmd":"(fade|solid)","t":(TIME),"d": (0|1)}
]
}
Note: the "sequence" array would basically contain the same objects as in the normal requests to /color, just without the "queue" parameter as it doesn't make sense in this context. It could be present, but would be ignored (and also not stored).
RAW support would be equally possible, as long as only one type of transition is used (RAW or HSV, but never both in a single sequence).

/sequence/{id}
GET return the contents of the sequence with name {id} as a JSON object, format see above.
DELETE removes the sequence with name {id} from SPIFF. It will no longer be callable.
PUT store another version of this sequence with name {id}. If using PUT, the "name" field in the JSON may be ommited but MUST match the {id} if present. New sequences may also be created this way.

/sequence/{id}/run
POST runs the sequence. POST-Body: {"repetitions":}
"repetitions" defines how often the sequence should loop, 0 meaning "infinite".

from esp_rgbww_firmware.

Currently I was planning a different approach for creating scenes/animationSets but haven't got to finalizing the implementation.

The idea was, to send an animationSet (a List/array of consecutive steps) including a parameter 'count'.
Count represents the amount of times this set will be grone through (where as 0 defines infinity).
Example payload:
POST /animationSet

{ 
  "set": [ 
    { "hsv": { "h": 100.0,  "s": 100.0,  "v": 100.0, "ct": 2700 },  cmd: "solid",  "t": 0},
    { "hsv": { "h": 200.0,  "s": 100.0,  "v": 100.0, "ct": 2700 },  cmd: "fade",  "t": 5000,  "d": 1},
    { "hsv": { "h": 200.0,  "s": 100.0,  "v": 100.0, "ct": 2700 },  cmd: "solid",  "t": 10000},
    { "hsv": { "h": 100.0,  "s": 100.0,  "v": 100.0, "ct": 2700 },  cmd: "fade",  "t": 5000,  "d": 1}
  ],
  "q": false,
  "count" : 10
}

It will fade from h=100 to h=200 in 5s, stay at h=200 for 10s, fade to h=100 in 5s
It will do this 10 times

There are already some skeletons for this implementation:
https://github.com/patrickjahns/RGBWWLed/blob/master/RGBWWLedAnimation.h#L295
https://github.com/patrickjahns/esp_rgbww_firmware/blob/master/app/webserver.cpp#L859

I'd prefer to go this route and keep any information besides the configuration outside of the controller.
With your approach we need to maintain synchronization between server/controllers to ensure that a controller actually has the sequence you require to be executed. (Adding new controllers then requires a "sequence installation" to be order to run a specific sequence.)

I find it easier to have a central configuration for a sequence which will be send as command to the controller when needed. (no need for keeping sequences in sync, no need for extra installation, simply put controller into the system and use it)

from esp_rgbww_firmware.

Hmmm, I see your point, especially when thinking about multiple controllers in an environment.
What's your stance on "endless" repetitions of an animation?
Not simply passing a really high number of repeats, but really making the controller run the animation until the next command comes along?
(Possible scenario e.g. simulating a fireplace or flashy lights for a party.)

from esp_rgbww_firmware.

For now the idea was, to use "count": 0 as indicator if the loop should run indefinitely.
Stop the animation should be as simple as sending either a new command (fade/color) or a new animationSet.
Even turning off is just sending "v":0 as color/fade - so that should not be a problem at all.

In regards to complex animations: the current idea will be limited to roughly 50-100 steps due to ram limitations for parsing large requests. (But needs to be further tested how large the actual request package can be before the esp is at it's ram limit).

For more complex animations (once that require randomization, or more fine grained timing/control) I would also propose to extend the RGBWWLed Library with these animations. But let's see first if this is required?

Either way, I happily accept pull requests for the project - so feel free to fork and implement it :-)

from esp_rgbww_firmware.

from esp_rgbww_firmware.