Feature: Store pre-defined color sequences for easy reference

[ShuzzDE]

I'd love to be able to do the following:

• POST a sequence of fade commands for storage in SPIFF under a unique name for later execution.
• POST some kind of "execute sequence" command to start the sequence of fades.
  Also, it should be possible to make the controller execute a given sequence a defined number of times or indefinitely (looping).
  This would essentially make the controller truly programmable, e.g. store a fire simulation for creating a cosy atmosphere when cuddling on the sofa with your SO or pre-program some wild color sequences for the next party.

[ShuzzDE]

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.

[ShuzzDE]

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".

[patrickjahns]

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)

[ShuzzDE]

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.)

[patrickjahns]

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

[ShuzzDE]

Sounds real good to me. 0 for "run indefinitely" is fine, just wanted to make sure that the option is/will be there. 50-100 steps should be plenty for animations imo. If not, one could still implement a more tightly packed format for transferring the animations (2-dimensional array with fixed position parameters in the inner array for example) in order to save on RAM. Regarding forking the code... yeah... I already cloned it, set up an environment and even managed to compile it after a bit of fiddling around, but... I don't really get how it is all glued together. I'm not a real C/C++ guy myself. Arduino sketches are fine (I have some experience with those), but your code is currently way beyond my skills. I mean, I understand what portions of it do (mostly), but have trouble navigating it. I wouldn't be sure how to go about extending it with new functionality without messing things up. Badly. If you ever find the time to give me an introduction, I'd be happy to try my hand at it though. Am 08.12.2016 um 07:39 schrieb Patrick Jahns:

…

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 :-) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#5 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AWpXhYVDmcO_7Pf4_gLlRhIF8ZokeBkeks5rF6YfgaJpZM4LGhwo>.