Return controller default values in a metadata request

[repentsinner]

Hi @terjeio,

I'd like to propose exposing settings defaults to $ES, so senders can:

• more intelligently expose changed (non-default) settings
  • allows operators to reason on what's changed/unique to their system
  • allows saved configurations to only be unique values, rather than ~200 presumably mostly default settings
  • self documents the UI without senders needing to maintain board config sets that drift from as-built
• return individual settings to default values w/o needing a full firmware reset

Currently I believe some senders keep default maps of vendor-specific controllers to achieve some of this functionality, but it'd be great if this was just queryable from a connected system.

Before I fork and add this, do you have any preferences on:

• Extend $ES with a new field:

$ES
[SETTING:<id>|<group>|<name>|{<unit>}|<datatype>|{<format>}|{<min>}|{<max>}|{<reboot>}|{<null>}|{<default>}] 

As I understand, most existing senders should just ignore a post-fixed new field without issue, and they can roll it in as needed. <reboot_required> and <allow_null> have already been extended here, so should be good to continue this pattern? I've audited ioSender, gSender, UGS, CNCjs, and they all seem like they should handle this fine.

Alternatively, if you prefer we could use a new command to be sure that an existing controller never receives a default on the $ES metadata report on accident:

$ED
[DEFAULT:<id>|<default>]

But this adds a round-trip and separates defaults from the metadata they describe.

Do you have any preferences on how defaults.h gets wired through to setting_detail_t, or should I just have a go at matching the surrounding code as best as possible (copying how void *value is being included)?

Plugins seem a little more complicated to support, as far as I can tell default values are captured imperatively in restore(), instead of in setting_detail_t. We could either skip this for now, or stage it out (add plugin defaults to setting_detail_t to support $ES/$ED now, then in the future refactor restore() to read from setting_detail_t so each plugin doesn't need to override restore()?). Am I understanding this correctly?

Anything else I'm missing to get this to land cleanly?

Thanks!

[terjeio]

Default values has to be accessed via setting_detail_t,. add a new entry *void default_value which should either a pointer to the value, an offset into a structure containing the value (identical layout as the one stored in NVS) or a pointer to the function for getting it.

Then how to implement - duplicate code or refactor it? IMO duplicating is a no-go, it will only add maintenance costs.
Refactoring would be, at least for core settings, to change access to the settings to use a base address (into the NVS copy or setting defaults) plus offset.

Will it be worth it? The only senders I know about that are using $ES info are gSender, ncSender and ioSender.
Do you know about others? And are they willing to add the functionality you outlined above?

[repentsinner]

Thanks @terjeio! I'm working on a sender as well, and this is a gap I'd like filled. I'll do my best to match your code with the refactor and I'll open a PR when I've got something put together.