Enhancement: WS2812 address leds by range

[ptrooms]

Description: Enhances ws2812 addressing to facilitate colouring ledranges using the existing led command

Related issue (if applicable): individual addressing leds is painfully slow

Checklist:

• [x] The pull request is done against the latest development branch
• [x] Only relevant files were touched
• [x] Only one feature/fix was added per PR and the code change compiles without warnings
• [x] The code change is tested and works with Tasmota core ESP8266 V.2.7.8
• [x] The code change is tested and works with Tasmota core ESP32 V.3.1.3.250504
• [x] I accept the CLA.

NOTE: The code change must pass CI tests. Your PR cannot be merged unless tests pass

This PR facilitaties to address leds in ranges. For example one canb control by the led command the ranges via the following parameters:

• ledX - led 1 to/included X%Pixels ( X % Pixels e.g. remainder after integer division by Pixels)
• led1xxxyyy - where xy is number to control led start (xxx / Pixels : inger division) until/including end (yyy % Pixels : remainder). If xxx < yyy then the addressing is reversed using Pixels as offset. Note: 000<number<999 is to be fixed with leading zeroes.

Example: assume Pixels = 10 ; then the follwoing command:

• led5 100000 - normal addresses led5 to Red
• led14 001000 - led 1 thru 4 are coloured Green
• led1005007 000010 - led 5 thru 7 is coloured blue
• led1009008 101010 - led 9 backward thru 8 is made white

By this one can quickly color a range of leds, specially handy to create VU-bars starting at 1, last led of a range inside the string of leds. Note: In case the command is used without color-paramter, the color value of the first led addressed is returned.

Hope this enhancement helps and inspires. In case of questions or improvements, let me know.

[sfromis]

That syntax breaks existing use cases for the Led command, as Led14 001000 currently means to set pixel number 14 to green.

Common Tasmota command formats will separate values by blank or comma, instead of stipulating fixed width and leading zeros for formats. JSON arguments are also used for "less simple" argument use cases.

[ptrooms]

That syntax breaks existing use cases for the Led command, as Led14 001000 currently means to set pixel number 14 to green.

Common Tasmota command formats will separate values by blank or comma, instead of stipulating fixed width and leading zeros for formats. JSON arguments are also used for "less simple" argument use cases.

No.

To explain: my routine uses the (number of Tasmota defined) Pixels to (s)elect if and when the number exceeds this value and thus must transition to bar-addressing. F.e. suppose number of Pixels is set to 10, then led14 000010 (exceeding Pixels) will color led 1 thru 4 to blue. If Pixels was not set (hence, default 512) then led14 on a ws2814 strip with 10 leds, would try to colour unexisted led14.

Technically, the number in command led1035056 001000 exceeds technically any WS2814 strip of f.e. 40-leds (Pixels =40) but in this case, it will color the leds 35 thru 56 into Green which would only light-up physical led 35 to 40. The remaining order (41-56) will simply not operate on WS2812 as there's no bubbling to a 41th led.

Of course one could introduce a new commmand/parameter structure (like ledbar x y rgbw), format etc.etc. which will give (me) more work and imo is in addition to maintenance also not necessary when one understand the operational syntax(is) of the number-formatting in relation to Pixels.

[s-hadinger]

Thanks for the PR, but I find the syntax very cryptic, especially if the decoding of the command depends on value of Pixels. Please provide a more explicit and non-ambiguous syntax: either separate with commas, or use JSON

[ptrooms]

Thanks for the PR, but I find the syntax very cryptic, especially if the decoding of the command depends on value of Pixels. Please provide a more explicit and non-ambiguous syntax: either separate with commas, or use JSON

I understand. I've thought of creating a new command/structure which took away the potential simplicity of integrating an enhancement into an existing routine, by using existing validation and only adding a few lines of code. In other words; a tradeoff between simplicity in coding at cost of some complexity when (as choice) exercising it.

Note: the ws2812-routine itself is already dependent on the number of Pixels as part of the led command. I merely make use when an passed value exceeds the (number of) Pixels, the led-operation is changed from single to bar'ring.

The idea to (mis)use values to change command behavior, is as done in other parts of Tasmota-commands. F.e. Pulsetime command in its integer value; hides 3 functions: 0-1 on/off, 1-100 offset in 0.1 seconds and above 100 increments of seconds. Using commas to separate command values, is (afaik) also not really part the Tasmota command (interpretation & validation) standard.

Anyway I'm not planning to introduce different commandline/validation/parameter structure(s) into XGLT and so on. I leave it up to the board to cancel, integrate the PR as shared or (someone else, may) change it into a more suitable presentation.

[sfromis]

The PulseTime example is very different, as the command syntax does not vary depending on factors not part of the command itself. Hence command parsing will always be the same, before starting to apply the command to current configuration. Anyway, what makes it "less understandable" is to just have more digits without any indication of multiple fields.

And using comma or blank as delimiters in commands is used in parsing of quite a few standard Tasmota commands, specifically including the Led command which already now supports multiple color values for consecutive pixels - did you verify that this still works? Also commands like Buzzer, DevGroupShare, Interlock, TimedPower, DspLine, PWMFrequency, TimeDST, UFSRename, etc.

[ptrooms]

The PulseTime example is very different, as the command syntax does not vary depending on factors not part of the command itself. Hence command parsing will always be the same, before starting to apply the command to current configuration. Anyway, what makes it "less understandable" is to just have more digits without any indication of multiple fields.

And using comma or blank as delimiters in commands is used in parsing of quite a few standard Tasmota commands, specifically including the Led command which already now supports multiple color values for consecutive pixels - did you verify that this still works? Also commands like Buzzer, DevGroupShare, Interlock, TimedPower, DspLine, PWMFrequency, TimeDST, UFSRename, etc.

tldr; tasmota uses multiple conventions to address numbered/items. Adding understandable "parameter" separation for a command may break other things. The enhancement (as tested) works for successive leds.

We can agree that Tasmota is using multiple conventions for specifying command-addresses or item-locations and/or to control effective behavior. The enhancement does not change that way of doing.

Technically. The issue for the led-command that this currently does not support separation. It would of course nice to have a structure like "led10,20..." and/or "led10-20,..." to operate on series of addressable leds. The XLTG command routine to color leds, is currently only active when the passed (internally XdrvMailbox.index as uint32_t) number > 0. Changing that XDRVMAILBOX structure inside tasmota.ino:

struct XDRVMAILBOX {
  bool          grpflg;
  bool          usridx;
  uint16_t      command_code;
  uint32_t      index;       // <----- led-adress value
  uint32_t      data_len;
  int32_t       payload;
  char         *topic;
  char         *data;
  char         *command;
} XdrvMailbox;

solely for sake of human understanding for a command, may break other parts of tasmota.

The enhancement, using number to specify series, is backward compatible. One utilizing, would only have to know; in case a lednumber value exceeds the number of defined Pixels, the behavior changes to color series for one or more consecutive leds. Of course there's a risk that one has set a low number 'Pixels' just to avoid/ignore/stop led-coloring beyond that value. (Note: "Pixels" to define number of leds, is not dynamic and will restart tasmota).

The 'successive ledcolor' option, was also partially reason to incorporate start&end (for a series) within the 'lednumber'. Simply by dividing that number by Pixels as start and use the remainder to end the series. In case one uses led-bar'ring with consecutive led-coloring (as is tested), the led-bar takes precedence.

The enhancement routine is kept simple. All other things remain working as used & defined. The difference starts when using number exceeding Pixels. If consecutive colors are used in commands, then barring, shifts that towards the bar of leds.

F.e. suppose a ws2812 strip activated with 10 Pixels' with command led1_004007_ 100000 001000 (e.g. 2 consecutive colors), one get 4 led's (4 thru 7) colored to red as the successive option for next led(5) to green is effectively ignored. If one would use more consecutives then the series; like led1_004005_ 100000 001000 000010 (color led4 thru led5 with 3 consecutive colors), one get a led-bar red for pixel 4 & 5 and the 3rd consecutive would color led6 to blue.

[github-actions[bot]]

This PR has been automatically marked as stale because it hasn't any activity in last few weeks. It will be closed if no further activity occurs. Thank you for your contributions.

[ptrooms]

Bump. Let me know if and how to proceed of progress things .... able to adress leds in strings, works great.

[arendst]

Glad it works for you. I'll take a look in July how to move this forward.

[github-actions[bot]]

This PR has been automatically marked as stale because it hasn't any activity in last few weeks. It will be closed if no further activity occurs. Thank you for your contributions.

[arendst]

kick

[github-actions[bot]]

This PR has been automatically marked as stale because it hasn't any activity in last few weeks. It will be closed if no further activity occurs. Thank you for your contributions.

[github-actions[bot]]

This PR was automatically closed because of being stale.