MeshMonitor v4.10.3 is a maintenance release that gets the Traffic Management module showing up correctly on supported firmware and clears out a handful of papercuts — most notably MQTT nodes that kept losing their names.

Traffic Management, now correctly detected (#3457)

The Meshtastic Traffic Management module (firmware v2.7.22+) polices mesh traffic on a node — deduplicating positions, rate-limiting, caching NodeInfo, and dropping unknown or hop-exhausted packets — and emits a TrafficManagementStats telemetry packet. Since 4.10.2, MeshMonitor surfaces its seven counters as labelled, integer-valued graphs in a node's telemetry view under a shared "Traffic Mgmt:" group: packets inspected, position-dedup drops, NodeInfo cache hits, rate-limit drops, unknown-packet drops, hop-exhausted packets, and router hops preserved.

The catch: Device Configuration was reporting Traffic Management (and Status Message) as "Unsupported by this device" even on firmware that fully supports them, such as v2.7.24. Support was being inferred from whether the device sent a decoded module-config sub-message — but Proto3 omits any sub-message whose fields are all at their defaults, so a node that had simply never configured the module (the common case) looked unsupported regardless of its firmware.

4.10.3 gates support on the firmware version instead — Status Message requires ≥ 2.7.19 and Traffic Management ≥ 2.7.22, exactly the requirement the UI already advertises. While fixing this we also found that explicit local module-config refreshes were being dropped (the response handler was remote-node-only), so those are now stored too (#3460).

MQTT nodes get their names back (#3456)

If you watch a busy MQTT feed, you've probably seen a sea of nameless nodes. NodeInfo was being decoded and saved correctly — and then clobbered moments later. Every MQTT position, text, and telemetry packet triggers a routine "last heard" refresh, and that refresh was overwriting the node's long/short name and hardware model with blanks. Because nodes broadcast NodeInfo only every few hours but send position and telemetry constantly, the names were wiped almost immediately every time.

The refresh now leaves the name and hardware-model fields untouched, so NodeInfo sticks. Existing nameless rows fill back in on each node's next NodeInfo broadcast.

More fixes

• No more scrambled message↔channel attribution (#3453): when two channels shared the same PSK and name, channel-move detection produced a phantom bidirectional "swap" on every config sync, repeatedly re-migrating messages. Ambiguous (psk, name) pairs are now skipped, leaving messages in place.
• MeshCore auto-ack {SNR} resolves again: the {SNR} macro in MeshCore auto-ack / auto-responder templates always rendered as —; the received SNR is now carried onto MeshCore message events.
• MeshCore device names keep their Unicode (#3450): editing a MeshCore device name no longer strips parentheses, emoji, and other printable Unicode on save (it's safely capped to the 32-byte field on a character boundary).

A note on TX power (#3459)

Some users asked whether negative LoRa Transmit Power values are allowed. They are — the field is signed, and MeshMonitor has always passed them straight through without clamping. The help text now spells this out: 0 uses your hardware's default maximum safe power, and negatives are only meaningful on radios that support reduced output (e.g. SX126x), with firmware applying no lower clamp.

Upgrade

docker pull ghcr.io/yeraze/meshmonitor:4.10.3

helm upgrade meshmonitor meshmonitor/meshmonitor --version 4.10.3

Desktop builds are on the Releases page. Full details in the changelog.