Mesh-Plug 1.3.2: Current Meshtastic MQTT Support, Protobuf Decoding, and Better Coarse Location Handling

Mesh-Plug 1.3.2 is now live on WordPress.org

This update is mostly about keeping Mesh-Plug aligned with current Meshtastic MQTT behavior. Recent Meshtastic firmware and app documentation have moved the practical center of MQTT traffic away from legacy JSON topics and toward protobuf packets. Mesh-Plug now understands that modern traffic path directly in the browser, while still preserving support for older JSON-producing gateways.

If your dashboard previously connected successfully but did not populate Nodes, Chat, Map, or Charts, this is the update that should make the behavior much more predictable.

What Changed

1. Mesh-Plug Now Decodes Current Meshtastic Protobuf MQTT Packets

Earlier Mesh-Plug versions worked best with JSON MQTT traffic such as:

msh/2/json/#

That was convenient because browsers could parse the packet payloads directly.

Current Meshtastic MQTT deployments are increasingly protobuf-first. Mesh-Plug 1.3.2 adds browser-side decoding for the core packet types the dashboard needs:

• Text messages
• Node info
• Position packets
• Telemetry packets
• Map reports

That means binary protobuf messages are no longer just shown as “binary payload” in the log when Mesh-Plug can decode them. They can now feed the same dashboard views as JSON messages.

Encrypted packets are still shown as encrypted binary payloads. That is expected. Mesh-Plug cannot decode channel-encrypted packet contents from the broker without the relevant channel keys, and it should not pretend otherwise.

2. New Default Topic for New Installs

New Mesh-Plug installs now default to:

msh/2/e/#

That better matches current Meshtastic MQTT traffic.

Depending on your broker, gateway, and Meshtastic setup, you may also want to use one of these:

msh/2/e/#
msh/2/c/#
msh/2/map/#
msh/2/json/#
msh/#

Use msh/2/e/# or msh/2/c/# for current protobuf traffic.

Use msh/2/map/# if you only care about public map-report style packets.

Use msh/2/json/# only if your setup still produces legacy JSON MQTT packets.

Use msh/# when troubleshooting mixed traffic, but narrow it down once you know which topics your broker is actually receiving. Busy public or regional MQTT topics can create a lot of browser and dashboard work.

3. Better Handling for Privacy-Preserving Coarse Positions

Meshtastic has been improving location privacy. In newer deployments, precise location may be restricted or intentionally reduced, especially on public or known-key channels.

Older Mesh-Plug behavior treated low precision as suspicious and could drop those positions from the server-side cache.

Mesh-Plug 1.3.2 keeps valid coarse positions and displays an approximate radius instead.

For example, instead of refusing a low-precision point entirely, Mesh-Plug can show it as:

47.61000, -122.33000 (~1.2 km)

This is a better match for how Meshtastic now treats location sharing:

• Precise location is useful on private channels.
• Coarse location is often the correct behavior on public/shared channels.
• A dashboard should make the difference visible instead of silently dropping the point.

4. Map Reports Are Supported

Mesh-Plug can now decode Meshtastic map-report protobuf payloads.

Map reports are useful because they are intentionally designed for map-style consumers. They can include:

• Long name
• Short name
• Node position
• Altitude
• Firmware version
• Modem preset / region metadata
• Position precision

If you want a public-facing dashboard, map reports plus observer mode are usually a better fit than exposing a direct live MQTT client to every visitor.

Recommended Setup

Public Dashboard

Use observer mode:

[mesh_plug mode="observer" height="600px" map_tiles="voyager" fit="1"]

This keeps public visitors on the server snapshot API instead of connecting their browsers directly to your MQTT broker.

Admin / Operator Dashboard

Use live mode on a restricted page:

[mesh_plug mode="live" height="700px" map_tiles="dark" fit="once"]

Live mode connects directly from the browser to your MQTT broker over WebSockets, so keep it behind appropriate WordPress access controls.

Broker Reminder

Browsers need MQTT over WebSockets.

That usually means your Mesh-Plug broker URL looks like:

wss://mqtt.example.com:9001/mqtt

Meshtastic devices and mobile apps usually use native MQTT over TLS instead:

mqtt.example.com:8883

Same broker. Same root topic. Different transport.

That distinction matters. mosquitto_sub is great for testing port 8883, but it is not a browser WebSocket client and should not be used to test your Mesh-Plug wss:// URL directly.

Upgrade Checklist

After updating to Mesh-Plug 1.3.2:

1. Go to Settings → Mesh-Plug.
2. Check your broker WebSocket URL.
3. Review your topic filter.
4. If you are on current Meshtastic firmware, try:

msh/2/e/#

5. If you are troubleshooting, temporarily try:

msh/#

6. Once you see traffic, narrow the topic again.
7. Use observer mode for public pages.
8. Use live mode only for admin/operator pages.

What This Fixes

This release should help with several common “connected but empty” situations:

• The WebSocket connection succeeds, but Nodes never populate.
• The log only shows binary payloads.
• Chat does not render from current protobuf MQTT traffic.
• Position updates are present upstream but never appear on the map.
• Coarse/public Meshtastic locations are filtered too aggressively.

It does not bypass Meshtastic encryption. If a packet is encrypted, Mesh-Plug will show that it saw encrypted traffic, but it will not decode the protected contents.