[BUG] MQTT Channel Messages Not Received Unless Relayed by Nearby LoRa Node

[maxhayim]

Describe the bug

Messages sent through MQTT channels are not being received by my node/application as expected.

MQTT messages only appear to come through when another Meshtastic node is physically nearby over LoRa and that nearby node is also connected to the internet/MQTT through the default Meshtastic app.

In other words, it appears that MQTT messages are not being received directly through the configured MQTT connection. They only become available when a nearby LoRa node that is online through the official Meshtastic app acts as a bridge.

To Reproduce

1. Connect the node/application normally with MQTT enabled.
2. Configure the same Meshtastic MQTT channel/topic used by other nodes.
3. Send a message to that channel from a remote node over MQTT.
4. Confirm that there is no nearby LoRa node connected to MQTT through the official Meshtastic app.
5. Observe that the MQTT message is not received.
6. Bring another Meshtastic node nearby over LoRa.
7. Connect that nearby node to the internet/MQTT using the default Meshtastic app.
8. Send another message through the same MQTT channel.
9. Observe that the message is now received over LoRa from the nearby internet-connected node.

Expected behavior

Messages sent through the configured MQTT channel should be received directly through MQTT regardless of whether another Meshtastic node is nearby over LoRa.

A nearby node connected to the internet through the official Meshtastic app should not be required for MQTT channel messages to be received.

The expected path should be:

Remote Node -> MQTT Broker -> Application/Connected Node

Currently, the behavior appears to require:

Remote Node -> MQTT Broker -> Nearby Meshtastic Node using Official App -> LoRa -> Application/Connected Node

Screenshots

I can provide screenshots, MQTT configuration, logs, or packet examples if needed.

Environment

• Host OS: [Linux / Mac / Windows]

• Deployment type: [Docker / Mac App / Windows App / Baremetal / NPM]

  • Container version: [if applicable]
  • App host OS: [if applicable]
  • NPM commit: [if applicable]

• Networking customizations: [None / Reverse Proxy / Cloudflare Tunnel / Tailscale / Other]

• Database backend: [SQLite / PostgreSQL / MySQL]

• Node type: [Heltec V4 / Station G2 / meshtastid / Pi Hat / Other]

• Node Connection Type: [WiFi / Serial Bridge / BLE Bridge / Other]

• VirtualNode client: [iOS Meshtastic App / Android Meshtastic App / Home Assistant / Other / N/A]

Additional context

The important part of the issue is that MQTT itself does not appear to be delivering channel messages directly.

I can reproduce the issue by having no nearby internet-connected Meshtastic nodes. Messages sent through MQTT do not arrive.

As soon as another node is nearby over LoRa and that node is connected to MQTT/internet using the default Meshtastic app, messages begin coming through.

This makes it appear that the application/node is receiving the messages over LoRa from the nearby node, rather than receiving them directly from MQTT.

The MQTT configuration/channel works because the nearby node using the official Meshtastic app is able to receive the MQTT traffic and retransmit it over LoRa.

This may indicate an issue with MQTT subscription, topic/channel handling, message decoding, or forwarding of MQTT-originated packets.

[Yeraze]

Thanks for the detailed report! I checked for existing issues covering this and didn't find an exact duplicate — the closest related ones (#4115 "specific nodes produce zero data via MQTT sources", #4694 "bridge does not include own messages") are different failure modes, so this stays open as its own issue.

Classification: likely not a MeshMonitor bug — device/channel configuration

I dug into the Meshtastic firmware source to verify the mechanism you described, and your own hypothesis is almost certainly correct — but the cause sits in the Meshtastic firmware's MQTT channel settings, not in MeshMonitor:

• Firmware only subscribes to a channel's MQTT downlink topic when that channel has downlink_enabled = true (MQTT::sendSubscriptions() in src/mqtt/MQTT.cpp). With it false — which is the protobuf default — the node never receives any inbound MQTT traffic for that channel at all, regardless of mqtt.enabled or a matching topic/channel config.
• A second check in onReceiveProto() drops any stray inbound packet for a channel where downlink_enabled isn't set, as a belt-and-suspenders guard.
• Once a packet is accepted via MQTT downlink, it's queued through the router exactly like an RF-received packet and shows up over the TCP/BLE/serial API to MeshMonitor — there's no "primary node" or other special requirement gating that.
• This exactly explains the symptom: your own node's mqtt.enabled is likely on for uplink only. It publishes fine, but never subscribes, so it only ever sees channel traffic that arrives over LoRA — including messages relayed onto RF by a different, downlink-enabled node nearby. That matches "no relay node nearby → nothing arrives; relay node connected via the official app → messages appear."

How to fix

Enable Downlink Enabled on the channel in question. A couple of ways to do it:

• In MeshMonitor: Dashboard → Channels → Edit Channel → Downlink Enabled (remote admin — see Admin Commands: Editing Channels).
• In the official Meshtastic app: Channel settings for that channel → enable downlink.
• Via CLI: meshtastic --ch-set downlink_enabled true --ch-index <index>.

One tradeoff to be aware of before flipping it on: enabling downlink doesn't just make messages visible to MeshMonitor — the node will also re-transmit every MQTT-downlinked packet over RF to the rest of your local mesh. On a busy/public channel (e.g. LongFast bridged to a public broker) that's genuine airtime cost for every device in range, which is presumably why your node (and the community in general) has it off by default. If you only want MeshMonitor to see MQTT traffic without your physical node re-flooding it over RF, the better fit is MeshMonitor's own Embedded MQTT Broker/Bridge feature — it can subscribe to the same upstream broker/topic directly and ingest decoded messages server-side, independent of any physical node's downlink setting.

To confirm this diagnosis, could you answer:

1. Is MeshMonitor connected to a physical Meshtastic node (TCP/serial/BLE) that itself has mqtt.enabled on, or are you using MeshMonitor's own Embedded MQTT Broker/Bridge source type?
2. On the channel you're testing with, is Downlink Enabled currently checked (Dashboard → Channels, or the official app)?
3. Could you fill in the Environment section of the issue template (deployment type, node type/connection)? It's currently blank and would help rule out anything environment-specific.

Meshtastic's own MQTT module docs: https://meshtastic.org/docs/configuration/module/mqtt/
Meshtastic channel config docs: https://meshtastic.org/docs/configuration/radio/channels/

If you confirm downlink was off and enabling it resolves this, I'll close this as expected firmware behavior (with a docs improvement to call this out more clearly in our own MQTT docs). If downlink was already on and this still reproduces, that would point at an actual MeshMonitor ingestion bug and we'll dig further.

-- Authored by Roger 🤓

---

Generated by Claude Code

[Yeraze]

@maxhayim any further information on this ?

[maxhayim]

Give me a few days as we will be putting up solar nodes and will test this more.

[coinraiser]

Having same issue with meshcore.Node own advert as well as other packets not relayed to mqtt without repeater.

[Yeraze]

@coinraiser thanks — what you're describing sounds like a MeshCore limit rather than the Meshtastic downlink problem this issue started with, so let me split the two.

Why your own advert needs a repeater

MeshMonitor's MeshCore Analyzer Observer publishes only what your radio hears. It reads the companion's receive log (LOG_RX_DATA) and relays each packet in it to MQTT, tagged direction: "rx".

A radio never hears its own transmissions, and the companion protocol has no log of what it sends. So your node's own advert, and anything else it sends, only reaches MQTT when a repeater floods it back and your radio hears that echo. With no repeater in range, it never shows up. That matches what you're seeing.

One question

Packets from other nodes that your radio hears directly (no repeater in between) should still publish. Do those reach MQTT for you?

• Yes: this is the receive-only limit above. Publishing your node's own sends is a feature we could look at, so I'd track it as its own issue.
• No: that's a real bug. Please share your source type (companion over TCP, serial or BLE), and whether the Observer status shows it connected and counting published packets.

[coinraiser]

@coinraiser thanks — what you're describing sounds like a MeshCore limit rather than the Meshtastic downlink problem this issue started with, so let me split the two.

Why your own advert needs a repeater

MeshMonitor's MeshCore Analyzer Observer publishes only what your radio hears. It reads the companion's receive log (LOG_RX_DATA) and relays each packet in it to MQTT, tagged direction: "rx".

A radio never hears its own transmissions, and the companion protocol has no log of what it sends. So your node's own advert, and anything else it sends, only reaches MQTT when a repeater floods it back and your radio hears that echo. With no repeater in range, it never shows up. That matches what you're seeing.

One question

Packets from other nodes that your radio hears directly (no repeater in between) should still publish. Do those reach MQTT for you?

* **Yes:** this is the receive-only limit above. Publishing your node's own sends is a feature we could look at, so I'd track it as its own issue.

* **No:** that's a real bug. Please share your source type (companion over TCP, serial or BLE), and whether the Observer status shows it connected and counting published packets.

As per description "Relays every packet this Companion hears to a MeshCore Analyzer MQTT broker so your node counts as an observer. MeshMonitor only publishes — it never receives from the broker or transmits on the mesh. Companion devices only."
that makes sense but requires 2 devices,companion and repeater to relay to mqtt but guessing that a question for meshcore and not meshmonitor.
Thx for ur time

[maxhayim]

I'm still having this issue @Yeraze

[maxhayim]

@Yeraze how can we take a look into this?