CLI: gps interval to set and persist the GPS read interval - #9
Open
mmmorks wants to merge 1 commit into
Open
Conversation
NodePrefs::gps_interval has been persisted in the prefs blob (and the "gps.int" key) since it was added, but nothing outside companion_radio's CMD_SET_CUSTOM_VAR path could write it: CommonCLI's get/set commands are a hand-written chain that never reaches the ConfigSerializer tree, and simple_repeater's applyGpsPrefs() pushed only "gps" to the sensor manager and never the interval. The stored value was loaded, saved, and ignored, leaving EnvironmentSensorManager on its 1 s default -- which on a node with a fix prints two lat/lon debug lines per second. Add "gps interval [seconds]" in the shape of "gps advert": the bare form reports, the argument form applies and persists, capped at 24 hours, with zero keeping the firmware default of 1 s at both ends. The argument must be all digits, since _atoi() reads a typo like "abc" as 0 and would silently reset the pref while answering "ok". The prefix match requires a delimiter after "interval": memcmp(command, "gps interval", 12) matches "gps intervalX" too, which would then read its argument from past the 'X' -- an empty string, so 0 -- instead of falling through to the generic "gps" handler and being rejected. Trailing spaces read as the bare query. Teach applyGpsPrefs() to re-apply a non-zero stored interval at boot in every firmware that compiles the command -- simple_repeater, simple_room_server and simple_sensor -- matching what companion_radio already does. Without that the setting is accepted and persisted but silently lost on the next boot, which is exactly what the command is for. Out-of-range and overlong arguments are rejected rather than clamped: _atoi() accumulates into a uint32_t with no overflow check, so "gps interval 4294967300" would otherwise wrap to 4 and be stored as a 4-second interval while answering "ok". gps_interval stays settable-but-not-enumerated in EnvironmentSensorManager, and the comment there records why: the enumeration calls also build RESP_CODE_CUSTOM_VARS's wire payload on every companion build, so listing it would change what every embedded companion node sends. It is also deliberately not gated on gps_detected, because every example's applyGpsPrefs() calls it at boot regardless. Documented in docs/cli_commands.md.
mmmorks
force-pushed
the
pr/10-gps-interval-cli
branch
from
September 12, 2026 21:21
e488035 to
3aff318
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds a
gps interval [seconds]command toCommonCLI, and makes the repeater re-apply the persisted interval at boot.NodePrefs::gps_intervalalready existed and was serialised (gps.int), andEnvironmentSensorManageralready honoured agps_intervalsetting, but nothing outside the companion app'sCMD_SET_CUSTOM_VARpath could set it, andsimple_repeater'sapplyGpsPrefs()never pushed the stored value back to the sensor manager after a reboot.What changed
src/helpers/CommonCLI.cpp:gps intervalreports the stored value;gps interval <n>sets it (0–86400 s, 0 = firmware default of 1 s), forwards it to the sensor manager and saves prefs. The argument must be all digits —_atoi()reads a typo likeabcas 0, which would silently reset the pref instead of reporting the mistake. The prefix match checks for a delimiter afterinterval, otherwisegps intervalXwould parse past theXas its argument instead of falling through to the genericgpshandler and being rejected.examples/simple_repeater/MyMesh.h:applyGpsPrefs()applies a non-zero stored interval at boot, matchingcompanion_radio.src/helpers/sensors/EnvironmentSensorManager.cpp: comment recording whygps_intervalis deliberately settable-but-not-enumerated (enumerating it would changeCMD_GET_CUSTOM_VARS's wire payload on every companion build) and not gated ongps_detected(every example'sapplyGpsPrefs()calls it at boot regardless).docs/cli_commands.md: documents the command.At the 1 s default the two
lat …debug lines printed on every read dominate a debug log on a node with a fix; this is the knob for that too.How it was tested
pio test -e nativepasses (on macOS this needs the<stdlib.h>include from the small-fixes PR to compile at all; the suite is otherwise unaffected by this change).WioTrackerL1_repeater(nRF52) andheltec_tracker_v2_repeater(ESP32-S3).Dependencies
Independent. Applies to
dev. (Touches thegpshandler region ofCommonCLI.cppa few lines away from the NULL-check fix in the small-fixes PR; both apply cleanly in either order.)