radio and tempradio should have an apply_at parameter that takes unix time

[mikecarper]

https://github.com/meshcore-dev/MeshCore/blob/main/examples/simple_repeater/MyMesh.cpp#L749C1-L758C1

void MyMesh::applyTempRadioParams(float freq, float bw, uint8_t sf, uint8_t cr, int timeout_mins) {
  set_radio_at = futureMillis(2000); // give CLI reply some time to be sent back, before applying temp radio params
  pending_freq = freq;
  pending_bw = bw;
  pending_sf = sf;
  pending_cr = cr;

  revert_radio_at = futureMillis(2000 + timeout_mins * 60 * 1000); // schedule when to revert radio params
}

Do something like this so the radio change can be done at a given time in the future.

void MyMesh::applyTempRadioParams(float freq, float bw, uint8_t sf, uint8_t cr, int timeout_mins, int apply_delay_sec) {
    uint64_t apply_delay_ms = 2000
    if (apply_delay_sec > 2) {
        apply_delay_ms = static_cast<uint64_t>(apply_delay_sec) * 1000u;
    }

  set_radio_at = futureMillis(apply_delay_ms ); // give CLI reply some time to be sent back, before applying temp radio params
  pending_freq = freq;
  pending_bw = bw;
  pending_sf = sf;
  pending_cr = cr;

  revert_radio_at = futureMillis(apply_delay_ms + timeout_mins * 60 * 1000); // schedule when to revert radio params
}

Setting it to a unix timestamp is a better way to do this so a single command can be copied and the radio figures out the offset. Will also need to be done for radio; don't see an easy way to do this in the future though. Above is a simple proof of concept.

MeshCore/src/helpers/CommonCLI.cpp

Line 416 in 6d32193

} else if (memcmp(config, "radio ", 6) == 0) {

[mepholic]

I think this is a really good idea to help with social coordination of mesh preset changes!

[mikecarper]

Been thinking about this after talking with @mepholic and these 2 new calls (with get, set, and del) might make more sense

set radioat(freq, bw, sf, cr, starttime)
set tempradioat(freq, bw, sf, cr, starttime, endtime) // both time parameters take unix time

on return it will output how long it will be until the radio switches; "Setting [n] will take effect in 3 days, 8 hours, and 21 minutes". If the clock is stuck in 2024 then this will make it easy to tell as days will be large. If set in the past this will output an error. If the endtime is in the past then this will output an error. If endtime is before start time it will output an error.

get radioat [n]
get tempradioat [n]

No param given then this will return how many future radio settings are in place. With the param [n] in place it will then output that settings parameters.

del radioat [n]
del tempradioat [n] 

No param given then this will remove all future radio settings. With the param [n] in place it will then remove just that one scheduled future radio setting.

Having a radio that can switch settings given a schedule will make mesh wide tests of bandwidth and scaling factors a lot easier to coordinate.

[github-actions]

This issue is stale because it has been open for 60 days with no activity. Remove the stale label or add a comment if this issue is still relevant, otherwise this issue will automatically close in 7 days.

[mepholic]

assign it to me!

[mikecarper]

I got the code. I'll do a pull request in a little bit

[mepholic]

im working on cleaning up another one actually, lol.