Allow applying an existing preset to a specific segment via JSON API

[d3nn3s08]

Is your feature request related to a problem? Please describe
I'm integrating WLED into an external application that uses a single LED strip with multiple segments to display the status of multiple devices (for example, multiple 3D printers).
Each device has the same set of states:

• Idle
• Preparing
• Printing
• Paused
• Finished
• Failed
• Filament Error
• HMS Error
• Waiting
• Offline
  Currently, presets are tied to the segment information stored inside the preset.
  This means that if I have 20 devices with the same 10 states, I need to create 200 presets (20 × 10), even though the only difference between those presets is the target segment.
  During testing with WLED 16.0.0 I tried using the JSON API like this:
  {
  "seg": [
  {
  "id": 0,
  "ps": 11
  }
  ]
  }
  The request is accepted (HTTP 200), but the preset is not applied.
  I also tested storing multiple segments inside one preset and setting the non-target segment to "on": false, hoping WLED would ignore those segments.
  Instead, WLED actively applies the stored "on": false state and turns the other segment off, also restoring its stored colour and brightness.
  The only reliable solution I found is creating partial presets using "Checked segments only", which means creating one preset for every state and every segment.
  This works reliably, but requires a large number of nearly identical presets.
  The solution you'd like
  It would be useful if the JSON API supported applying an existing preset to a specific segment without requiring the preset itself to contain segment-specific information.
  For example:
  {
  "ps": 3,
  "segment": 5
  }
  or any other officially supported mechanism that allows reusing the same preset across different segments.
  The preset would define only the visual appearance:
• colors
• effects
• palettes
• brightness
• transitions
  while the API request would specify which segment should receive those settings.
  This would significantly reduce the number of required presets for installations with many segments while remaining fully backwards compatible.
  Alternatives you've considered
  I tested several alternatives:

1. One preset per state and per segment
   Works reliably.
   Example:
   20 segments × 10 states = 200 presets.
   This is currently the only reliable solution I found.
2. Segment-specific preset activation
   {
   "seg": [
   {
   "id": 5,
   "ps": 3
   }
   ]
   }
   Accepted by WLED 16.0.0, but had no observable effect.
3. Store multiple segments in one preset
   I tried storing all segments inside the preset while setting the non-target segments to:
   "on": false
   Unfortunately this does not behave as an "ignore this segment" flag.
   Instead, WLED actively applies the stored state and turns those segments off.
   Additional Context
   The behaviour described above was verified on a real WLED 16.0.0 installation using two persistent segments and repeated live testing.
   I'm not requesting a specific implementation.
   If there is already an officially supported way to reuse presets across multiple segments, I'd be very happy to learn about it.
   Otherwise, I think such a capability could be useful not only for my project but also for any application that uses WLED as a multi-device status indicator.
   Thanks for creating and maintaining WLED!

[DedeHai]

you may have a misunderstanding on presets. it is nothing more than json commands, it can contain all or partial information. It is impossible to "apply a preset to a segment" but what is possible is apply a property to a segment - if that is what you want then you just need to create the right presets.

[willmmiles]

you may have a misunderstanding on presets. it is nothing more than json commands, it can contain all or partial information. It is impossible to "apply a preset to a segment" but what is possible is apply a property to a segment - if that is what you want then you just need to create the right presets.

I think @d3nn3s08 understands that's the current behaviour. The challenge is that for his use case there's a combinatoric explosion - that'd be 20x10 = 200 presets, and he'd have to come up with some scheme to regenerate them if the "template preset" changes. A complicating factor is that WLED comes with a very nice UI for setting up and saving presets that's difficult to replicate elsewhere.

@d3nn3s08 : For an immediate practical implementation, if you've got the ability to make HTTP requests from the integration side, you could put the smarts in your application:

• fetch presets.json
• pick out the appropriate template by name or by id
• validate that it meets your template requirements (ie. has exactly one segment defined)
• change the segment id
• send the preset text directly to the JSON api endpoint