Messages from BBS are dropped due to new meshtastic firmware outgoing text message rate limit #62

New Issue

2026-10-05T01:18:54+02:00

adam commented

2026-10-05 01:18:54 +02:00

Newer meshtastic firmwares (starting with 2.7.0) implement a rate limit to outgoing messages (see https://github.com/meshtastic/firmware/pull/7139 ). There is a message in newer Android client builds that refers to a 2 second rate limit, and the linked PR title agrees, but the code appears to actually implement a 1.5 second rate limit. This limit results in outgoing messages from the BBS script being dropped in some cases when the attached node is updated to 2.7.0 or later.

This dropping of messages is most easily seen in messages which use the chunker, such as weather reports. But I think it could also affect instances where different users need short single-message responses within the same 1.5 second period.

It seems to me like we'll need to implement a message queue, appending new messages in send_message() and processing the queue on a background timer.

It might also be helpful to add some support for tracking and reporting on message queue length, to help operators understand how long messages might be delayed in their situations.

Newer meshtastic firmwares (starting with 2.7.0) implement a rate limit to outgoing messages (see https://github.com/meshtastic/firmware/pull/7139 ). There is a message in newer Android client builds that refers to a 2 second rate limit, and the linked PR title agrees, but the code appears to actually implement a 1.5 second rate limit. This limit results in outgoing messages from the BBS script being dropped in some cases when the attached node is updated to 2.7.0 or later. This dropping of messages is most easily seen in messages which use the chunker, such as weather reports. But I think it could also affect instances where different users need short single-message responses within the same 1.5 second period. It seems to me like we'll need to implement a message queue, appending new messages in send_message() and processing the queue on a background timer. It might also be helpful to add some support for tracking and reporting on message queue length, to help operators understand how long messages might be delayed in their situations.

adam closed this issue

2026-10-05 01:18:54 +02:00

adam commented

2026-10-05 01:18:55 +02:00

I wonder if the existing rate limiting in send_message() might be close to solving this with some adjustments (it may need some global state to track when the last message was sent).

On a related note, when the chunker comes into play it can currently produce a lot more messages than it would need to, which would mean more messages to enforce delays between. See PR #163 for a fix that uses chunked messages more efficiently.

I wonder if the existing [rate limiting](https://github.com/SpudGunMan/meshing-around/blob/0a260b28b62b5b2b936689b2afc7749c4402decd/modules/system.py#L602-L610) in send_message() might be close to solving this with some adjustments (it may need some global state to track when the last message was sent). On a related note, when the chunker comes into play it can currently produce a lot more messages than it would need to, which would mean more messages to enforce delays between. See PR #163 for a fix that uses chunked messages more efficiently.

adam commented

2026-10-05 01:18:56 +02:00

set the chunker split (in config.ini) to 2.5 seconds ~~and I opened a query on it https://github.com/meshtastic/firmware/issues/7347~~

Also need to set response delay to >2

[messagingSettings]
# delay in seconds for response to avoid message collision
responseDelay = 2.2
# delay in seconds for splits in messages to avoid message collision
splitDelay = 2.5

set the chunker split (in config.ini) to 2.5 seconds ~~and I opened a query on it https://github.com/meshtastic/firmware/issues/7347~~ Also need to set response delay to >2 ```ini [messagingSettings] # delay in seconds for response to avoid message collision responseDelay = 2.2 # delay in seconds for splits in messages to avoid message collision splitDelay = 2.5 ```

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/meshing-around#62