Bug Description

When a user disables "Downlink Enabled" on a secondary channel, the change appears to save successfully (success toast shown, channel list updates, JSON export confirms "downlinkEnabled": false). However, after restarting the MeshMonitor container, the setting reverts to true.

Root Cause

This is a proto3 boolean elision issue in processChannelProtobuf() in meshtasticManager.ts (around line 5085):

downlinkEnabled: channel.settings.downlinkEnabled ?? true,

Proto3 omits boolean false on the wire because it is the default/zero value. So when the device streams its channel config on reconnect, downlinkEnabled: false arrives as undefined. The ?? true fallback then incorrectly stores true, overwriting the user's saved setting.

Steps to Reproduce

1. Open a secondary channel (index 1–7) in MeshMonitor
2. Uncheck "Downlink Enabled"
3. Save — confirm success toast and "downlinkEnabled": false in JSON export
4. Restart the MeshMonitor container
5. Observe: Downlink Enabled is back to true

Expected Behavior

downlinkEnabled: false should persist across container restarts.

Suggested Fix

Change the fallback in processChannelProtobuf() from ?? true to ?? false to match proto3's actual default for booleans:

downlinkEnabled: channel.settings.downlinkEnabled ?? false,

Reported By

Jeremy KQ4OOB via Discord

Authored by NodeZero 0️⃣