feat: include radio stats in MQTT status messages

[Kpa-clawbot]

Summary

Adds periodic MQTT status messages that include radio and device statistics, enabling downstream monitoring tools to track repeater health in real time.

What

• MQTT status publishing: The repeater now publishes a retained status message to <base_topic>/<node_name>/status every 5 minutes (configurable via mqtt.status_interval).
• Last Will and Testament: Sets an MQTT LWT so the broker automatically publishes an "offline" status when the repeater disconnects unexpectedly.
• Radio stats collection: Gathers uptime, noise floor, TX airtime, and placeholder fields for RX airtime and receive errors.

Message Format

{
  "status": "online",
  "origin": "<node_name>",
  "origin_id": "<node_id>",
  "stats": {
    "uptime_secs": 3600,
    "noise_floor": -95,
    "tx_air_secs": 42,
    "rx_air_secs": 0,
    "recv_errors": 0
  }
}

The format is compatible with meshcoretomqtt status messages, so tools like CoreScope can consume pyMC_Repeater status alongside other MeshCore nodes without any changes.

Configuration

mqtt:
  status_interval: 300  # seconds, set to 0 to disable

Notes

• rx_air_secs and recv_errors are currently hardcoded to 0 since pyMC_Repeater doesn't track those metrics yet. They're included so consumers can distinguish "not tracked" from "field missing".
• battery_mv is omitted (only relevant on embedded boards).

[yellowcooln]

@Kpa-clawbot if you can target this on the dev branch, i can work on this.

[rightup]

@Kpa-clawbot if you can target this on the dev branch, i can work on this.

@Kpa-clawbot if you can target this on the dev branch, i can work on this.

@yellowcooln have I not already done this in dev?

[Rigear]

Commenting because this is something I was looking at as well.

The letsmesh_handler does include a publish status call.

I wonder if it makes sense to continue having two separate MQTT implementations with the minor drift between the two. The packet schema is the same between the two.

The issue with the current letsmesh implementation is that it is hardcoded to only allow JWT auth. If that was updated to allow basic auth credentials it could take over as the default mqtt implementation. Probably with a rename?

The issues with the current mqtt implementation is that it doesn't include the status publish and only supports 1 client instance.

The configuration could be expanded:

• Enabled boolean on each configuration. Instead of using the current broker index
• Boolean flag to enable/disable JWT auth (default true?)
• User/pass (default None) passed into the mqtt client. If they are excluded, use anonymous auth.

Example: https://github.com/Rigear/pyMC_Repeater/tree/feat/mqtt_merge I can make an official PR once I fix up the API endpoint

[Kpa-clawbot]

@rightup @Rigear — chiming in on Rigear's note above.

Agree the duplication between this mqtt_handler and letsmesh_handler.publish_status is a real maintenance smell, and Rigear's proposed unification (single MQTT impl with enabled flags, optional JWT, optional basic auth) is the right long-term direction.

Happy to defer to whichever order makes the owner's life easier:

• Land this one first (small, scoped — radio stats in status messages, immediately unblocks downstream consumers like CoreScope), and Rigear's bigger refactor moves the status-publish logic trivially when it lands.
• Hold this until Rigear's merge PR lands, then I'll rebase whatever's left on top.

Either way works for us — owner's call. Just rebased on dev, CI green.