Configuration UI v2

[KeiranHines]

I have started to design an updated configuration UI for configuring effects. The below screenshot shows the progress so far. the essence will be a dialog built from the data from /settings/effect and /settings/effect/spec. Any and all feedback is welcome on this idea.

@rbergen for API endpoints. I noticed an /effectsConfig endpoint which looks to have more configuration than the current endpoints I am using. Should I look at using this endpoint for anything. Or for the /settings/effect/spec endpoint. Do you know of any effects that leverage those settings outside of the default name and time? Particularly any I can use to validate Palette or Color data types, or that make use of the validation property?

Thanks as always,
Keiran.

[rbergen]

@KeiranHines First off, I'm so happy you're asking these questions! The endpoints we're now discussing have been there for ages by now (well, that's what it feels like to me :) ), so it's great someone is finally picking these up!

I'm a bit short on time right now, so I'll focus on the API questions first.

I can't deduce from your questions if you've read REST_API.md, but in addition to what's there:

• /effectsConfig is more of a debugging tool, that I may pull out again later. It's the "internal JSON-persisted bookkeeping" of the total effects set, which includes everything like effect constructor parameters, effect order, default effect interval etc. etc. In principle, everything the UI needs (or, can use) should also be available through other endpoints.
• An example of an effect that currently allows itself to be configured beyond the standard properties is PatternSubscribers. I don't actually remember if others currently exist; additional configurability of effects is a (possible) future development. I didn't spend much time on it yet because there was no UI to do the configuration with - which is the catch 22 you may now start solving.
• The settings specs are specifically intended to "guide" a UI that is somewhat dynamic. So yes, the data type indicates what type of editor should be used for the setting in question, what lower and/or upper limits apply, etc.
• There are currently no effects actually publishing CRGBPalette16 (Palette) or CRGB (Color) settings. There's quite a few persisting properties of those types to JSON, which thus end up in /effectsConfig. So, you could look at those (and the code in jsonserializer.h) to see the JSON format such settings would have, and/or expose a couple of such settings yourself. You'd be the first seeing the color composition of the effect(s) in question change at runtime while you test your configuration UI. :)

It's good to know that quite a few effects get some of their configuration from the device settings (like 12HR/24HR time, time zone, location, etc.) So, offering a UI for the device settings will also contribute to the configurability of such effects.

I hope this helps. I'll take a look at the actual UI design later today.

[KeiranHines]

Thankyou for all the info. I'll look to add device level settings as well for time etc. Hopefully once I have some config ui up that will encourage other contributions for exposing settings.

[rbergen]

I did a quick check: the only setting that current has validation is the openWeatherApiKey device-level setting. That's also the only one that's "secret"; its value can be written but not retrieved via /settings. Actual validation requires writing via /settings/validated, as I'd guess you already know.

[robertlipe]

Lots of "my" effects had places marked for settings. (18/57) I've not updated my own trees yet with what actually landed, but LOTS of them had hardcoded "Settings" at the top for Speed and Scale. These came from a place where there are a couple of "knobs" that could be externally turned, presumably while they were running, from 0-100. We didn't have the UI, so they were just hardcoded. Actually looking at the web tree: PatternSMPicasso3in1 <https://github.com/PlummersSoftwareLLC/NightDriverStrip/blob/d2ed96286510df3d415ea356233ec5f4884792f3/include/effects/matrix/PatternSMPicasso3in1.h#L11> has some pretty gnarly code that overrides even that so Scale is taken from 0-33, 34-65, 66-100 (ish) to implement three different effects and "scale" (which is never actually used for "scale" at all in any of the *SM* effects, I think, could be a slider within them. PatternSMFire2021 overloads palette (which I may have gotten wrong) and something else inside of Speed and Scale. PatternSMStrobeDiffusion has some knobs They probably need some kind of "onSettingChanged" watcher to pick up changes, but the basic wiring of "numbers that should change how an effect draws" are present in many of those. Like in PatternSMHolidayLights.h, I probably wouldn't have made "speed" const if I'd had a UI (or had a connection from the JSON down to the effect that I'd known about) so some of them may need the wire nuts removed before hooking a real UI back up to them, but the wiring is there. So I'd tried to get my head around how runtime changed settings were supposed to work. We'd all kind of snipped at each other about how we needed or didn't need change observers or notifiers or signals or {/waves hand} something but never really had a UI to chase it. Maybe if the ojects were torn down and destroyed every time you clicked + or - in the UI (yikes!) and we pulled those out of the JSON that would work and we could pull them from the effects constructors, but that seems like putting the car in park to turn the steering wheel. There were a lot more in https://github.com/PlummersSoftwareLLC/NightDriverStrip/tree/all-robertlipe-effects/include/effects/matrix but, well, here we are. If you're just looking for ONE to start with, I'd poke at PatternSMPicasso3in1.h.. Implied by the name, there are three distinctly different Draw() functions in that one and they each have a pretty wild range. I remember recompiling and messing with that one dozens of times with different Speed values. (And finding some that just worked badly...) Now that I think about it, some of those that use bands (0-32, 33-65, etc...) stand a chance of flipping out if those effects roll over from band to band while running. Those just represent, uh, "opportunities." :-) I think I had the other half of Rutger's described "catch 22". As for seeing the first color changes, I think the color buttons on our remote trigger them on some of the older effects. I think there are visually interesting things that can be done in the *SM* effects. Let's figure out together how to get those from a key on a remote or a slider on the web down into the effects and changing our blinkage.

…

On Fri, Sep 22, 2023 at 2:00 AM Keiran Hines ***@***.***> wrote: Thankyou for all the info. I'll look to add device level settings as well for time etc. Hopefully once I have some config ui up that will encourage other contributions for exposing settings. — Reply to this email directly, view it on GitHub <#436 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSD36AG3ZY5LKLGKR2IITX3UZPVANCNFSM6AAAAAA5CMT2IY> . You are receiving this because you are subscribed to this thread.Message ID: <PlummersSoftwareLLC/NightDriverStrip/repo-discussions/436/comments/7078315 @github.com>

[KeiranHines]

PR is up: #442
@rbergen two things I came across that could be nice backend additions:

• A flag for read-only and possibly write-only. Currently, I am checking for read-only to exist in the description to disable a field.
• A reboot endpoint so the device can be restarted after settings applied if needed for some settings changes.

[rbergen]

Thanks! I'll look at it when I have a chance.

In response to your points:

• Yeah, if I'm honest these had crossed my mind already. I'm happy to extend the setting specs with a property for this. How would you prefer either scenario (read-only or write-only) to reflect in the JSON you get from the .../spec endpoints?
• The reboot endpoint already exists. If you POST board=1 (or board=true) to /reset, the board will reboot after it had the chance to persist some things. Via the same endpoint you can also clear the persisted effect list JSON (which should always be combined with a reboot), and restore the device settings to their defaults. The /reset endpoint is documented in its section in REST_API.md.

[KeiranHines]

readOnly: true would probably be the easiest. I noticed that write only already appears to show as a point without a value. I.e. the weather API key entry.

As for the reset endpoint. I must have glossed over that endpoint thinking it was a factory reset style endpoint, not including reboot. I'll add that into the pr in the spot I wanted it.

[rbergen]

I've just added this to the codebase, including a writeOnly flag - you can ignore it if you don't need it. I took the liberty of pushing it to the PR (i.e. your branch), so you can use and test it straight away.