MeshMonitor 4.10.3 fixes Traffic Management support and MQTT node labels

MeshMonitor got a small maintenance release with an outsized payoff for anyone watching a busy Meshtastic fleet. Version 4.10.3 stopped flagging capable firmware as unsupported, and it kept MQTT rows from turning into blank, nameless clutter just when operators needed a clean read on the mesh.

Published June 14, the update centered on Traffic Management detection, a fix that matters most as meshes get larger and more visible. Meshtastic proposed Traffic Management to ease the broadcast load in bigger networks, with goals that include position deduplication, per-node rate limiting, unknown packet filtering, and NodeInfo cache responses. MeshMonitor already exposed seven counters for the module in telemetry, but it had been deciding support by looking for a decoded module-config sub-message. That method broke down when a module had never been configured, so supported devices could still show up as if Traffic Management were missing.

Version 4.10.3 changed that gate to firmware version checks instead, which is far more stable in real use. The release notes set the thresholds at Status Message 2.7.19 and Traffic Management 2.7.22, and they also fixed explicit local module-config refreshes that were being dropped. For operators tracking newer firmware on larger meshes, that means the dashboard should finally line up with the actual node capabilities.

The other fix goes straight to the daily frustration of scanning an MQTT feed full of unlabeled boxes. Before this patch, NodeInfo could be decoded and saved, then immediately wiped by a routine last-heard refresh that overwrote the long name, short name, and hardware model with blanks. On a busy feed, that produced rows with no identity at all. MeshMonitor 4.10.3 leaves those name fields alone, so the node label survives until the next NodeInfo broadcast restores it.

That change lands in a part of the ecosystem where identity really matters. Meshtastic’s public MQTT server uses a zero-hop policy and only prioritizes certain portnums, including NodeinfoApp, so name preservation directly affects how readable the shared feed is. Meshtastic’s MQTT docs also say the public server filters location precision to 10 to 16 bits on the default PSK, and its channel configuration rules require matching channel names for devices to talk on the same channel. In other words, the broker is already selective about what it carries; keeping node names intact helps the useful packets stay understandable.

The release notes also mention a channel-attribution bug involving ambiguous channel names and shared PSKs, plus a fix for MeshCore auto-ack SNR rendering. But the clearest win is simpler: fewer false unsupported warnings, fewer blank MQTT identities, and less time spent wondering whether the mesh is noisy or the monitor is wrong.