PhoneAPI: add missing tak_tag case + skip reserved gap in module-config iteration#10256
Merged
thebentern merged 2 commits intoApr 23, 2026
Merged
Conversation
…ig iteration
The STATE_SEND_MODULECONFIG state machine iterates config_state through
ModuleConfigType enum values (1..MAX+1 = 16) and switches on
meshtastic_ModuleConfig_*_tag values. Two of the resulting tag values
land in the default / LOG_ERROR path:
1. `tak_tag` (16) — the meshtastic_ModuleConfig_TAKConfig struct exists
in the protobuf and has a `.tak` member in payload_variant, but no
PhoneAPI case ever sends it to the phone. As a result, Android
clients can't read the persisted TAK (Team Awareness Kit) module
config at all. Added case that sends moduleConfig.tak, matching the
pattern used for all other module-config tags (paxcounter,
traffic_management, etc.). NodeDB already persists the struct via
the moduleConfig protobuf save; this just wires the read path to
the phone.
2. Tag 14 — reserved gap in the oneof numbering. No payload_variant
member exists at tag 14. Without this patch, every phone reconnect
walks through config_state=14 and hits
`LOG_ERROR("Unknown module config type %d", config_state)`. On an
active deployment that's ~1,400 LOG_ERROR lines per day per node —
burying real errors. Added explicit `case 14: break;` so the gap
is silently skipped.
Also: lowered the `default:` log level from LOG_ERROR to LOG_DEBUG. A
truly-new unknown type number would indicate firmware lagging the
protobuf — annoying but not an error event worth LOG_ERROR, especially
since this path runs on every phone handshake. If a new ModuleConfig
tag appears, devs will notice via the phone UI missing it, not via log.
Observed on a Station G2 fleet: 1403 "Unknown module config type 16"
and 1427 "Unknown module config type 14" LOG_ERROR lines in 24 hours
from routine phone reconnects.
nightjoker7
added a commit
to nightjoker7/firmware
that referenced
this pull request
Apr 23, 2026
…ig iteration (meshtastic#10256) * PhoneAPI: add missing tak_tag case + skip reserved gap in module-config iteration The STATE_SEND_MODULECONFIG state machine iterates config_state through ModuleConfigType enum values (1..MAX+1 = 16) and switches on meshtastic_ModuleConfig_*_tag values. Two of the resulting tag values land in the default / LOG_ERROR path: 1. `tak_tag` (16) — the meshtastic_ModuleConfig_TAKConfig struct exists in the protobuf and has a `.tak` member in payload_variant, but no PhoneAPI case ever sends it to the phone. As a result, Android clients can't read the persisted TAK (Team Awareness Kit) module config at all. Added case that sends moduleConfig.tak, matching the pattern used for all other module-config tags (paxcounter, traffic_management, etc.). NodeDB already persists the struct via the moduleConfig protobuf save; this just wires the read path to the phone. 2. Tag 14 — reserved gap in the oneof numbering. No payload_variant member exists at tag 14. Without this patch, every phone reconnect walks through config_state=14 and hits `LOG_ERROR("Unknown module config type %d", config_state)`. On an active deployment that's ~1,400 LOG_ERROR lines per day per node — burying real errors. Added explicit `case 14: break;` so the gap is silently skipped. Also: lowered the `default:` log level from LOG_ERROR to LOG_DEBUG. A truly-new unknown type number would indicate firmware lagging the protobuf — annoying but not an error event worth LOG_ERROR, especially since this path runs on every phone handshake. If a new ModuleConfig tag appears, devs will notice via the phone UI missing it, not via log. Observed on a Station G2 fleet: 1403 "Unknown module config type 16" and 1427 "Unknown module config type 14" LOG_ERROR lines in 24 hours from routine phone reconnects. * Get rid of the placeholder --------- Co-authored-by: Ben Meadors <benmmeadors@gmail.com>
mariotti
pushed a commit
to mariotti/firmware
that referenced
this pull request
May 6, 2026
…ig iteration (meshtastic#10256) * PhoneAPI: add missing tak_tag case + skip reserved gap in module-config iteration The STATE_SEND_MODULECONFIG state machine iterates config_state through ModuleConfigType enum values (1..MAX+1 = 16) and switches on meshtastic_ModuleConfig_*_tag values. Two of the resulting tag values land in the default / LOG_ERROR path: 1. `tak_tag` (16) — the meshtastic_ModuleConfig_TAKConfig struct exists in the protobuf and has a `.tak` member in payload_variant, but no PhoneAPI case ever sends it to the phone. As a result, Android clients can't read the persisted TAK (Team Awareness Kit) module config at all. Added case that sends moduleConfig.tak, matching the pattern used for all other module-config tags (paxcounter, traffic_management, etc.). NodeDB already persists the struct via the moduleConfig protobuf save; this just wires the read path to the phone. 2. Tag 14 — reserved gap in the oneof numbering. No payload_variant member exists at tag 14. Without this patch, every phone reconnect walks through config_state=14 and hits `LOG_ERROR("Unknown module config type %d", config_state)`. On an active deployment that's ~1,400 LOG_ERROR lines per day per node — burying real errors. Added explicit `case 14: break;` so the gap is silently skipped. Also: lowered the `default:` log level from LOG_ERROR to LOG_DEBUG. A truly-new unknown type number would indicate firmware lagging the protobuf — annoying but not an error event worth LOG_ERROR, especially since this path runs on every phone handshake. If a new ModuleConfig tag appears, devs will notice via the phone UI missing it, not via log. Observed on a Station G2 fleet: 1403 "Unknown module config type 16" and 1427 "Unknown module config type 14" LOG_ERROR lines in 24 hours from routine phone reconnects. * Get rid of the placeholder --------- Co-authored-by: Ben Meadors <benmmeadors@gmail.com>
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
2 participants
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
Two related fixes in
PhoneAPI::handleToRadio/STATE_SEND_MODULECONFIG:case meshtastic_ModuleConfig_tak_tag:—moduleConfig.takexists in the firmware struct and is persisted by NodeDB, but PhoneAPI never sends it to the phone. Android ATAK plugin clients can't round-trip TAK (Team Awareness Kit) settings as a result.case 14: break;for the reserved gap in theModuleConfigoneof tag numbering. Without this case, every phone reconnect walks throughconfig_state=14and hitsLOG_ERROR("Unknown module config type %d", config_state).Also: dropped the
default:fromLOG_ERRORtoLOG_DEBUG. This path is routine (fires on every phone reconnect). A truly new unknown tag would be caught via the phone UI, not via an error log.Root cause
STATE_SEND_MODULECONFIGiteratesconfig_statefrom_MODULECONFIG_MIN + 1 = 1through_MAX + 1 = 16inclusive. The switch inside checks againstmeshtastic_ModuleConfig_*_tagvalues frommodule_config.pb.h:Before this patch the switch handled 1..13 and 15, but silently fell through to the LOG_ERROR default at 14 and 16.
Impact (observed)
On a Station G2 fleet running develop over a 24-hour window:
Together ~2800 ERROR-level lines per device per day, entirely from routine phone reconnects. That's the majority of the ERROR-level log traffic on the node.
And the functional half: Android ATAK plugin users have no way to read TAK module config from the firmware — the phone has no idea what
team/roleis persisted on the device.Risk
moduleConfig.takis already a real, persisted struct (seemodule_config.pb.hline 453+). The added case mirrors exactly how every other module-config case works (paxcounter, traffic_management, etc.) — copiesmoduleConfig.takintofromRadioScratch.moduleConfig.payload_variant.tak. No new memory paths, no new allocations.break;that replaces a benignLOG_ERRORwith silence.Testing
Phone-side config-dump on a patched node shows one additional ModuleConfig message sent (the
takvariant). Log volume on phone-reconnect drops by ~2800 lines/day.Follow-up not in this PR
AdminModule.cpphandlesSET_MODULE_CONFIGfor TAK via the enum valueTAK_CONFIG— but there's no matching GET path visible. Worth a follow-up PR to confirm the set path is wired and the AdminModule similarly has tak handling where needed. Not blocking this PR.