Is there any way to calculate directly, or at least guestimate, power consumption from software?
I’m thinking of a feature whereby you could say “cap my power output at 2A”, and then FastLED would “clip” its output brightness so as not to exceed that, and somehow notify your software that that was what it was doing.
Or is this something that would be best modelled external to FastLED?
I love this idea. We’ve prototyped this to explore what the interesting issues are, and AS USUAL the full complicated reality is a big tangled mess (and AS USUAL, a simple approximation gives you 80% of the value anyway).
E.g.: hook up a 5m strip with 150 pixels. Did you know that lighting pixels 0…9 draws more power than lighting pixels 140…149? And if you add in ten lit pixels in the middle of the strip, the difference between the current draw of the near ten and the far ten becomes greater? It’s because the voltage drop at the ‘far’ end of the strip affects how much current the LEDs draw.
BUT! If you decide to ignore that, and treat all pixels as an average current draw, it works pretty well! The prototype hasn’t been updated for v2.1 (yet), but I’m hoping to update it and get it out there for everyone to use before ‘festival season’ is in full swing. Whatever that means.
Two other interesting things that came up that I’ve been thinking about are:
(1) It’s relatively easy to clamp power usage to a hard limit. But one can imagine cases where it might be desirable to let power burst up to a higher ‘surge’ level for a short time. (“Going to 105% on the reactor.”)
(2) Suppose requested power draw spikes up to 4A and is immediately clamped to the hard ceiling at 2A, by kicking in a 50% brightness adjustment. A moment later, the animation shifts and now requested power draw drops back down to the limit, say to 2A. How should the brightness control react? Immediately go back to 100%? Slowly go back to 100%? Stay at 50%? (Something else?) Each as a different effect on power usage and visual appearance.
And of course I want a trivially simple API for all this that always does the right thing automatically in all cases for all users all the time. (The API I have already isn’t bad, but you can see how there might be a tension between simplicity and tweakability.)
Anyway, YES it’s possible, and super useful, and it can be done and it’s already on my to-do list to get this capability into people’s hands!
Would you guys stop being geniuses for a just a couple of minutes so the rest of us have time to catch up? 
I was thinking that it could only ever be an approximation by taking the datasheet-stated maximum power consumption for a controller/LED type, adding some “slop” for wiring losses and multiplying by the number of pixels—the slop could vary greatly depending on esoteric stuff like what type of connectors you’re using.
You could allow the user to specify a “continuous” and “peak” limit, where you were allowed to exceed the “continuous” limit up to the “peak” for some predefined period of time in the order of low single-digit seconds—I think you guys should select this timing, given your expertise on how much you can push a LiPo before it enters “vent with flame” mode.
I would say it should go immediately back to 100%. I have in my mind the behaviour of audio “clipping”. The idea is that you should test your patterns so they stay under your hard peak; the software ceiling is a backstop to save your batteries (and allow you to calculate a minimum runtime.)
For calibration, I ignored the data sheet and just hooked up an ammeter. I know how up-to-date and accurate documentation can be. ahem
Yeah, the “continuous X mA, with peak of Y mA for Z ms” thing might be the right API. Or it might be “no more than X mAH in Z ms”. Or “my battery holds 20Amp-hours, and I want this animation to run for ten hours and my wires will burst into flame if they dissipate more than X watts for Y seconds.” We’ll start simple, but it’s good to think about where it might be going, too.
As for the “immediate snap back to 100%” and your comment that it’s like audio clipping is one of the things I’ve been thinking about. But ears are not eyes, and perception is tricky. I sometimes think about this as a sample (worst case) animation: whole strip is medium white (128,128,128), and once per second it strobes to full brightness (255,255,255) for 10ms. Say that the power/brightness control clamps the strobe to 50%. What will the visual effect be? I think it’d be that the strobe flashes completely disappear, and all that’s left is a smooth, unchanging (128,128,128) all the time!
“Immediate snap back” was the first thing I tested, and believe it or not, I think overall I got better results with a “NEVER snap back” strategy – it didn’t hide any of the animation’s features the way the immediate snap up and down did.
I suspect that the best overall will be a “drift back” strategy with a developer-specified recovery time; if you specify “0 ms”, you get the “snap back” behavior.
All hypothetical at this point, but as noted before, it’s good to talk about it and think it through a bit before committing.
It’s interesting, but I just can’t visualise it In my head. It’s like a sound system with limiting pushed to the max, you hear the kick drum and the bass, but then it pauses and some gutair is heard and then back to kick and bass… Visually, and unless your pushing it to the max (as I would guess it would only be used as a minimising problem as opposed to trying to run 20m from a 1amp) then it would look fine for the most, and then white (being the highest ampage) would be 240,240,240 as opposed to 255,255,255, and then I doubt your eyes would notice too much.
How do different types of strips draw current?
Would there be a way to implement a “test your own led” and input the results to alter the settings?