LED Stripe

[fly74]

Hi @tonhuisman. Is is possible with the actual neopixel plugins to light up every 2nd or 3rd LED of a LED stripe easily?

[fly74]

maybe a on line BMP with "NeoPixel Matrix"

[tonhuisman]

This could better have been a question for the Forum...

We don't have a loop feature in Rules, so that's a bit more difficult to achieve, but this should be doable.

on NeoEvery do // Call like: AsyncEvent,"NeoEvery=1,50,2" // (start, end, increment)
  let,12,%eventvalue2|50% // end, default 50
  let,13,%eventvalue3|2% // increment, default 2
  if %eventvalue1% > 0 // empty arguments start protection, can optionally be removed, then also remove the endif at the end
    neopixel,%eventvalue1%,30,30,0 // RGB colors can also be stored in vars like %v1%,%v2%,%v3% etc. for external control
    let,11,%eventvalue1%+%v13% // Next increment
    if %v11% <= %v12%  // Check end-pixel
      AsyncEvent,"%eventname%=%v11%,%v12%,%v13%" // Crucial to use asyncEvent!!!
    endif // end-pixel
  endif // start protection
endon

(~still editing...~ fixed 1 more typo)

[fly74]

Works great, but how can I turn off all LEDs to set another increment ?

[tonhuisman]

neopixelall,0,0,0

[fly74]

Would it be difficult to make a "plugin command" for it? maybe "commandname,first,last,divider,RGB,brightness"

[tonhuisman]

We try to avoid adding new features in the normal build plugins, to avoid breaking the build size limits for ESP8266... This rule is a nice solution, IMHO 😃

[fly74]

you're right! THX a lot

[fly74]

one last, how can I pass a parameter from event calling to set the increment in doit e.g.

On System#Wake do
   Event,doit
Endon

on NeoEvery do // Call like: AsyncEvent,"NeoEvery=1,50,2" // (start, end, increment)
  let,12,%eventvalue2|50% // end, default 50
  let,13,%eventvalue3|2% // increment, default 2
  if %eventvalue1% > 0 // empty arguments start protection, can optionally be removed, then also remove the endif at the end
    neopixel,%eventvalue1%,255,255,255 // RGB colors can also be stored in vars like %v1%,%v2%,%v3% etc. for external control
    let 11,%eventvalue1%+%v13%
    if %v11% < %v12%
      AsyncEvent,"%eventname%=%v11%,%v12%,%v13%" // Crucial to use asyncEvent!!!
    endif // end-pixel
  endif // start protection
endon

On doit Do
  neopixelall,0,0,0
  AsyncEvent,"NeoEvery=1,144,4"
Endon

On dooff Do
  neopixelall,0,0,0
Endon

[tonhuisman]

On doit do // call: event,doit        or call: event,doit=2
  let,20,%eventvalue1|4% // Default to 4
  neopixelall,0,0,0
  AsyncEvent,"NeoEvery=1,144,%v20%"
Endon

[TD-er]

On doit Do
  neopixelall,0,0,0
  AsyncEvent,"NeoEvery=1,144,%eventvalue1|4%"
Endon

So the event doit=10 will use 10 as last argument for NeoEvery

For more info on %eventvalueX% and default values, see: https://espeasy.readthedocs.io/en/latest/Rules/Rules.html#event-value-eventvalue

[fly74]

Thanks devs I'll take the short version 😎

[fly74]

@tonhuisman looks like a little bug inside. The first led ist flickering every few seconds. It's no technical other like neopixelall have not this issue.

[tonhuisman]

The first led ist flickering every few seconds.

That is most likely caused by either too low signal level (no level-converter used?) or an interference caused by the regular on/off pattern of the neopixels. I've also seen that happen on the NeoMatrix display, where it is visible sometimes when only a few pixels are lit. The signal-timing is very critical, and falls off some edge under specific conditions.

[fly74]

But it only happens with the Async Event :/

[TD-er]

Probably this is due to timing issues handling events. Neopixel LEDs are quite critical regarding timing. Typically you can consider it a shift register where data is moved to the next LED if it no longer fits in its registers. However there needs to be some kind of timeout where there is no new data so each LED can latch the new data into its operation buffers.

I can imagine some async events to happen in a very short succession. So maybe this can only be solved if the neopixel plugin gets some kind of DMA and we can set the values of this DMA via rules. However this may consume quite a lot of memory (3 bytes per LED, 4 on RGBW LEDs)

[fly74]

no problem, I leave the 1st off

[TD-er]

If it is a timing issue, then the first LED may still show flickering even when intended to be left dark. Or maybe the first LED is receiving noise? (inbetween updates) Such noise may have a non-zero chance to match the timing for 24 bits, but this chance may be significantly reduced for each extra LED

[tonhuisman]

What type of ESP is in use here? As for ESP8266 we're using the Adafruit library, and for all ESP32 models the NeoPixelBus library.

[fly74]

It's an ESP32 Mini "ESP32-D0WDQ5-V3"

[fly74]

@tonhuisman @TD-er Can the AsyncEvent stopped in a rule, because the AsyncEvent takes a while. When another event start "neopixelall,0,0,0" to switch off, then the already switched on leds from async were switched off, but the other were switched on while async task is running.

[TD-er]

Nope, there is only a deduplication check for events in the queue, but not to clear the queue.

Never thought one would flood the event queue like this ;)

Maybe it is better to implement the feature you like as a command. Way less overhead compared to this.

[tonhuisman]

I'll add a command neopixelfor,<from>,<to>,<increment>,<r>,<g>,<b>[,<w>]

Default enabled for ESP32 only, or explicitly in an ESP8266 Custom build.

[tonhuisman]

@fly74 I've added commands neopixelfor and neopixelforhsv as mentioned above. The hsv version uses the HSV color parameters, as expected 😉 You can test the feature from this Actions run when using an ESP32 build that has P038 included.

[fly74]

@tonhuisman that's works really great. but the new set of the command don't erase the setting before. So I used "neopixelall,0,0,0" before the new set but it flickers. Can we make an erase parameter e.g.?

[tonhuisman]

Hm, IMHO, the extra, but existing command should work just fine, the command is already quite 'complicated', so adding another argument kind of makes it worse. And I would have to duplicate code, which for obvious reasons, I'd like to avoid.

[fly74]

Or when a range is submitted to the command, can we set the color to the increment matching and set the other to off in one bunch in the matching range?

[tonhuisman]

That last option was a possible solution we (TD-er and me) already talked about shortly. While adding even more arguments, it feels more natural to add that as a feature.

[fly74]

But for now it's really great.

[tonhuisman]

@fly74 I've thought about adding an optional clear-color set of arguments, but decided to go for a single <clear> argument after the color arguments (all 3 or 4 have to be provided), that, when set to 1, will clear the in-between pixels.

If other colors are to be used instead of clearing the pixels then multiple commands, with incrementing start-pixel and an alternative color, have to be used, and some flickering will probably be visible.

A new build is cooking over here.

[fly74]

Simply that's it "neopixelfor,1,141,2,100,100,0,1" followed by "neopixelfor,1,141,3,100,100,0,1" or mixed color with "neopixelfor,41,80,2,0,100,0,1" and "neopixelfor,1,40,2,100,100,0,1" works like a charm. When it goes to official build? 🥇to @tonhuisman :)

[tonhuisman]

When it goes to official build?

I've added it to a PR that's supposed to be merged before the next official release... 😇

[fly74]

BTW so for what I need something like that. I have a 3D printer and to light up the build room I use a led stripe with a densitity of 144 led/m in 3 parts. I've combined it with a LUX sensor. The plan was to reduce the led light when the environment light rises without lowering the led brightness for a led. now can I use the LUX value to calculate the increment parameter of the new function.

[TD-er]

And couple the Lux sensor to ESPEasy so you can completely automate it :)

[TD-er]

It is now included in the 'latest' on the web flasher: https://td-er.nl/ESPEasy/latest/

[fly74]

And couple the Lux sensor to ESPEasy so you can completely automate it :)

That's what I've done - right wires to the stripe:

[fly74]

Case for it is still printing.

[fly74]

Case ready.

[TD-er]

You mean "case closed" ;) Looks nice!