How to Control Multiple Stripes with one instance?

Hi, I`m new to WLED.

I setup an NodeMCU with the newest WLED release and configured 2 Stripes (Pin 1 → 150LEDs // Pin 2 → 150LEDs)

The plan is to equip tow garage doors with it. Stripe 1 for the left door and Stripe 2 for the right one.

But now I don’t understand how do I control the stripe individually?!

Segments.

Set segment 1 to cover the LED strip on pin 1, and segment 2 to cover LED strip on pin 2 (I do not recall if segments start at 0 or 1…)

Let’s say there are 200 LEDs on the left door. The first segment will cover LEDs 0 to 199. Let’s say 200 LEDs are on the right door. The second segment will cover LEDs 200 to 399.

Then you can control them together, or separately.

This requires a more recent firmware build to get to work.

I always do an online search for which pins are good for use as digital outputs before wiring everything up (or making decisions related to specific pins being used). This way I do not accidentally have to do stuff twice.
If you already did that and know pin 1 & 2 are both ok for LED strips, that’s great. I know GPIO0 is not good for LED strips. The rest, I look up.

One side effect of multi pin strips is that they are treated logically as one long strip.

Let’s say I have two strips of 10 LED’s that I want to indepedently signal Red /Green/Yellow.
I’ll tell WLED I have a total of 20 LED’s then put a set of 10 each on 2 different pins and I’m ready to go right?
Weeeeeelll when working with presets, you end up with 1 string of 20 LEDS, where 0-9 is the first strip, and 10-19 is the 2nd. That’s ok, I can just set up a different segment for each strip and set them from there right?

Except when you save your presets, they have a nasty habit of overwriting the settings of the strip you’re not currently working on. I set presets 1,2,3 for strip1 to be Red, Green,Yellow and 4,5,6 to be strip2 Red, Green, Yellow. If I choose Pr1 I get Str1-Red, Str2-Off. Pr4 gives Str1-Off, Str2-Red.
What I’d like is to set Str1 and Str2 independently so I don’t have to create presets of all the possibilities.

Maybe I’m going down the wrong path here, but without invoking an external mechanism to send JSON strings I can’t get the presets working as I’d like.

You mean, you want 2 WLED instances from a single µcontroller?

I have an install of mixed devices on one run that are separated into segments and have not had problems working with each independently.

After playing about with the GUI interface a fair bit I have managed to get a least a 1st set of presets that does indeed do what I’ve described.

Using the built in controls to assign colour/brightness to part of a strip works well for one section at a time, but in order to save presets that don’t overwrite the effect of an existing preset on some other portion of the strip, I have to change the presets to “JSON” mode.
That gives me control over exactly the section I want to control with a given preset.

I can see the GUI is trying to maintain “integrity” and length limits across multiple segments, but in my case I seem to be stepping on those automatic changes. It was not always clear what was being loaded “in the background” without dumping the current JSON states.

Not surprisingly, it seems to be a matter of me learning what aspects of the interface I need to better understand to get the job done…

Glad to hear you are getting closer to realizing your 2 strip “independent” control strategy.

I wanted to say “there’s a little bit of a learning curve”, which you found out without me saying it. However, I thought stating my reply the way I did might get @Aircookie thinking about ways to abstract a single WLED instance into acting and feeling like several WLED instances, essentially hiding that learning curve from us with something like “WLED - WS2811 (GRB) on Pin x” and a tab for strip selection, like (actual Pin #'s filled in at runtime after pin configuration completed)

  • WS281n (GRB) on Pin a
  • WS281n (RGB) on Pin b
  • WS281n (GBRW) on Pin c
  • xxxxxx (RBG) on Pin d
  • ALL

My initial instinct after some of the hoops I had to go through to make my scenario work was “There must be a better way…”

On the other hand, I’ve done some coding myself and I definitely appreciate the mass of code the current WLED incarnation represents. My feel is there’s a level of code built into the GUI to “protect the user” from themselves and I’m stepping on and through that in unexpected ways sometimes. Very probably I’ve created some multiple segment scenarios that are non-typical.

The error checking to make sure segment lengths and start/end points are sensible is non trivial once you get up beyond 3 segments. Add in the ability to add effects and palettes and the whole thing becomes potentially overwhelming. At this stage I’m happy enough that I’ve found a solution.

But if you’re thinking in terms of enhancment - what about preset patterns of colours?
One thing I found very effective in coding up little arduino controllers for static Xmas displays was to load my strings based on a fixed pattern that gets repeated till the string is full.
Say a GGWWRR “Peppermint” pattern or a RBYOWGV multi colour pattern.
The effect can be very pleasing for long static strings and coding can be very efficient if you save the preset patterns in codespace flash. I found I could come up with 20 common patterns that would cover 90% of my use cases.

Right now, the only way I’ve found to get these patterns is to build them using multiple segment definitions. That works, but could be fairly memory intensive in some cases.
For example I have a building perimiter string (300+ LED’s) that looks great with a BWWWBWBWBWWWB pattern. Currently I have to create 13 segments and assign colours at the proper spacing points. For my 20 patterns that means 20 presets with varying #'s of segments depending on the pattern length.

To make my pattern Paradigm work in WLED, you would need something like a “Pattern-Preset” or perhaps the ability to use a predefined pallette for loading a static string. Perhaps there’s a reasonable way to extend the use of Pallets to load static strings? How about a (paradoxical) Static Load Effect?

Just some Blue-Sky thoughts for now…

Be mindful of checkmarks on segments.