Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request]: Adjustable offline message queue depth on device #3637

Closed
jgspratt opened this issue Apr 15, 2024 · 1 comment
Closed
Labels
enhancement New feature or request wontfix This will not be worked on

Comments

@jgspratt
Copy link

Platform

ESP32

Description

Per the documentation:

The radio will store a small amount of packets (around 30) in its memory for when it's not connected to a client app. If it's full, it will replace the oldest packets with newly incoming text messages only.

On some devices, there is a lot more available memory, and it would be useful to be able to dedicate a large amount to storing messages while the paired device (phone) is disconnected. Consider the case of a Meshtastic device in an ideal location for receiving messages, but the phone user needing to be able to travel away from that location for hours or days. In my location, messages begin to roll off after 10-20 minutes it seems, and if there was a burst of traffic, it could be even faster. In cases like this, even a small interruption in Bluetooth could mean lost messages.

Since there is no theoretical limit to how large a message memory/storage pool could be, I recommend a numerical entry box with something like, "How much memory to use for messages?" and units of KB (and MB?). This would also be a great use of the SD card where messages could be appended to plaintext log files (one file per channel or DM) as well as logged in a structured format like JSON.

@jgspratt jgspratt added the enhancement New feature or request label Apr 15, 2024
@thebentern thebentern added the wontfix This will not be worked on label Apr 16, 2024
@thebentern
Copy link
Contributor

Controlling queue size based on user config values is very problematic at best, especially when you consider that we have a myriad of devices on different platforms with different amounts of memory available. My suggestion would be to place a custom macro in your variant and control it via that in a custom compiled firmware.

@thebentern thebentern closed this as not planned Won't fix, can't repro, duplicate, stale Apr 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

2 participants