[BUG] https://github.com/Yeraze/meshmonitor/issues/2375 is still happening as tested in RC5

[LN4CY]

#2375 is still present in RC5

[Yeraze]

Thanks for the report. This was addressed in the original #2375 fix, but we've made significant changes to channel handling since RC5, including RC6 through RC8.

Could you test with the latest RC8 (v3.10.0-RC8, just released)? Several channel-related fixes have landed since RC5, including improvements to how channels are matched and displayed.

If the issue persists on RC8, could you provide:

1. Which channel database entry is shadowing which device channel?
2. Do the PSKs match exactly between the database entry and the device channel?
3. A screenshot of both the Channels tab and the Channel Database section showing the overlap?

This will help us pinpoint whether the priority/matching logic still has a gap.

[LN4CY]

Still present on RC8

I am testing on channel named EXP, but any channel with the overlap has the same effect.

I am testing on MQTT only messages

The PSK is the same in both.

I am able to send messages from the node channel and these are received by the remote node, when reply from the remote node all messages go to the database channel, and none to the node channel

[Yeraze]

Shouldn't that be handled internally by the node firmware? e.g. It should bypass MeshMonitor and go straight to the node, and the node process and echo it back?

If you remove/disable the Channel Database version does it work how you expect ?

[LN4CY]

If I disable the database channel the message goes to the node channel as normal

[Yeraze]

In either case, can you determine if the message gets properly rebroadcast from your node across the mesh?

[LN4CY]

in both cases I see messages in the remote node(MQTT), but i am out of town and cannot see what my node in RF range is receiving, when database channel is disabled i can see messages being rebroadcasted, but I can traceroute from the remote node so the RF link works. Remote node -MQTT->Meshmonitor node -RF-> RF node and back.

I think this issue is caused by meshmonitor intercepting and consuming the message and only publishing it to the one chat window (database channel)

[Yeraze]

well my concern is that MM shouldn't have anything to do with it, the MQTT proxy should be sending it to the Node, and the Node should be handling it. It looks like perhaps it's not making it to the node and onto the mesh, in which case what you are seeing is actually correct (the message doesn't actually exist in that channel).

I'll look at the code a bit deeper and see if I can determine any issues, but I worry about adding messages to the channel that are "fake" and not actually transmitted over the mesh properly.

[LN4CY]

in both cases the message is sent to the virtual node from the mqtt-proxy, then meshmonitor gets it from the node. not sure how meshmonitor chooses to display the message in the chat windows and how it decodes is via the channel database, seem that the channel database consumes the message event from the node subscription and is not longer seen by the regular chat window

[Yeraze]

We've identified the root cause and have a fix in PR #2415.

What was happening: When MeshMonitor's server-side decryption matched a Channel Database entry, it always assigned the message to the database channel view — even when a device channel had the exact same PSK. This caused MQTT-proxied messages to appear in the database channel instead of the device channel.

The fix: After server-side decryption, we now check if any active device channel (0-7) has the same PSK as the matched database channel. If so, the message is assigned to the device channel instead. The database channel still gets its decryption counter incremented, and the encrypted packet still flows through to the physical node as before.

This will be in the next RC build once the PR is merged. We'll tag you when it's available for testing.