widget options: add useable defaults

[offer-shmuely]

Is there an existing issue for this feature request?

• I have searched the existing issues

Is your feature request related to a problem?

I am aways frustrated when I need to define default values to options in lua widgets
you need to supply the id of the switch, but it is not well documented, and it is changing from version to version
so I need to define and maintain tables for each version

-- for backward compatibility
local function getSwitchIds(key)
    local OS_SWITCH_ID = {
        ["2.7"]  = {SA=112, SB=113, SC=114, SD=115, SE=116, SF=117, STICK3 = 89, INPUT3 = 3, CH3 = 204},
        ["2.8"]  = {SA=120, SB=121, SC=122, SD=123, SE=124, SF=125, STICK3 = 89, INPUT3 = 3, CH3 = 212},
        ["2.9"]  = {SA=120, SB=121, SC=122, SD=123, SE=124, SF=125, STICK3 = 89, INPUT3 = 3, CH3 = 212},
        ["2.10"] = {SA=126, SB=127, SC=128, SD=129, SE=130, SF=131, STICK3 = 89, INPUT3 = 3, CH3 = 228},
    }
    local ver, radio, maj, minor, rev, osname = getVersion()
    local os1 = string.format("%d.%d", maj, minor)
    return OS_SWITCH_ID[os1][key]
end

Describe the solution you'd like

suggestion

for SWITCH, allow to define name of the switch and direction
"SF"..CHAR_UP | "SF"..CHAR_DOWN | "SF-"
or better
"SFu" | "SF-" | "SFd"

for SOURCE, that may not be available, I would like it to have array of options, and to choose the first one that exist
e.g.
cell | VFAS | RxBt | A1 | A2
or
RQly | VFR | RSSI | 1Rss

so it will look like this

local options_new = {
    { "arm_switch_id" , SWITCH, "SF"..CHAR_UP },
    { "motor_channel" , SOURCE, "CH3" },
    { "volt_sensor"   , SOURCE, {"cell","VFAS","RxBt","A1", "A2"} }, -- default is cell, if not found the VFAS, is not found then RxBt....
}

Describe alternatives you've considered

No response

Additional context

requested from @philmoz and he may look at this.

[philmoz]

There are Lua API functions getSwitchIndex and getSourceIndex that will return the index for a named switch or source.

I can use similar code when parsing the option defaults for SWITCH and SOURCE options if the supplied value is a string.

However in the current implementation getSwitchIndex and getSourceIndex will compare against the user names if the user has renamed the switches or sources.

So getSwitchIndex("SF"..CHAR_UP) will fail if the SF switch has been given a custom name.

I would suggest that getSwitchIndex and getSourceIndex should probably check both the default names and custom user names (if present).

Thoughts?

[offer-shmuely]

for the switch,
I see now, that after your enhancements (the addition of "SWITCH" type)
I can do the following :-)

local options = {
    { "switch1", SWITCH, getSwitchIndex("SA" .. CHAR_UP) },
    { "switch2", SWITCH, getSwitchIndex("SA-") },
    { "switch3", SWITCH, getSwitchIndex("SA".. CHAR_DOWN) },
}

and although personally I do not care about switch name changes (I do not do that, nor i know someone who does)
I can see the the code does find the switch

regarding the source, can you show what you are talking about?

[philmoz]

Currently this:

    { "switch1", SWITCH, getSwitchIndex("SA" .. CHAR_UP) },

will not work if the switch has been renamed before you add the widget to the radio.
You can see this if you remove the widget from all the views, then reboot. When you try and add the widget again the default will be '---' instead of SA up.

For source something like this:

    { "source1", SOURCE, getSourceIndex("CH3") },

However at the moment this will not work because the widget options are processed at startup before any model is loaded, so most of the sources (e.g. channels) are unavailable.

[offer-shmuely]

So what can be done?

[philmoz]

I would suggest that getSwitchIndex() and getSourceIndex() be changed to:

• always return the index regardless of whether the switch or source is actually available
• check against both the default name and the user specified name (if present)

If necessary we could add new functions isSwitchAvailable() and isSourceAvailable() to check whether the switch/source is actually present.

There is one other complication to do with telemetry sensors. Since the index of a sensor can't be determined unless the sensor is actually discovered it will not be possible to use them in the options default value.

[offer-shmuely]

In case the telemetry sensor is not exist, i do not need it, since he can not produce data.
This is why i need a list, to find the first one that can produce data.

[philmoz]

In case the telemetry sensor is not exist, i do not need it, since he can not produce data. This is why i need a list, to find the first one that can produce data.

In the current code this can't be done.

All of the widget files on the SD card are loaded at radio startup, (compiled if needed), and the 'options' table is processed to build the default options data in memory.

This all happens before any model is loaded so no telemetry sensors can exist.

The 'options' table is never re-examined.

So trying to use getSourceIndex() for a telemetry sensor in the options table will always fail.

[offer-shmuely]

Can the options calculation run once again before each presentation of options-window?

[philmoz]

See PR #5926