[Bug]: MQTT Data Packets appear to only send below LoRa threshold of ChU.

[Coopersmith-24601]

Category

Other

Hardware

Rak4631

Firmware Version

2.5.22

Description

Here's my observations based on what I see in the APP vs what I see being reported via MQTT.

As you can see, the Channel Utilization in my area is pretty darned high and as a result a lot of the node's data is suppressed going out to LoRa. I'm fine with that and it's a great way to pull back a bit of the ChU.

However, on MQTT this appears to be also suppressed and therefore there's no real way to monitor the ChU if it goes over the suppression level.

Further, it appears as if there can be gaps in other data which should be available via MQTT.

Yes, I understand the sampling rates are different between the BLE connected node and MQTT, but it's pretty easy to see there are gaps in the MQTT data if the threshold was over the suppression level for LoRa data.

Relevant log output

[madeofstown]

This is something I have been wondering about lately! Tend to get more messages on my personal node than what shows up on my local MQTT server. And that gateway node is on my roof so it should be getting better reception than the node clipped to my shirt.

[Coopersmith-24601]

This is something I have been wondering about lately! Tend to get more messages on my personal node than what shows up on my local MQTT server. And that gateway node is on my roof so it should be getting better reception than the node clipped to my shirt.

Meshtastic TEXT should not be suppressed by the high ChU. That said, very high ChU may cause packet collisions which hurt propagation.

What I'm specifically observing and commenting about here are nodes which are uplinking Device Metrics and other telemetry. Even though the node may be connected to a client app via BLE to Proxy to MQTT the packets appear to be suppressed if ChU is over the suppression limits.

[cdanis]

I'd like to see similar functionality, although I'm a little worried about the competing use case where people want MQTT traffic from nodes to represent exactly what went in or out via RF. Maybe high-rate client telemetry packets could go to a different channel topic instead, and also ofc never to public MQTT?

[Coopersmith-24601]

I'd like to see similar functionality, although I'm a little worried about the competing use case where people want MQTT traffic from nodes to represent exactly what went in or out via RF. Maybe high-rate client telemetry packets could go to a different channel topic instead, and also ofc never to public MQTT?

My concern here is for remote node monitoring.

If MQTT data is ONLY ever sent when high ChU doesn't suppress it for LoRa, then even if the node is hard wired to the internet the operator has no real idea of the ChU above the suppression level for LoRa.

I'm not too concerned with high rates of MQTT data because those are already constrained by time with the default at 30 minutes and the only setting below that being 15. What I am very concerned about is data being dropped entirely for possibly hours at a time.

[garthvh]

Without packet zero hoping like the public server this could easily DDOS any mesh with a private broker