-
Notifications
You must be signed in to change notification settings - Fork 986
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
Add persistent message storage and message log frame #3784
Conversation
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good! Do you have any plans to implement some of the features (cycle through channel?) for devices which only have a single user-button?
Very nice. On which devices/screens has this been tested next to the T-Deck? |
This pull request has been mentioned on Meshtastic. There might be relevant details there: https://meshtastic.discourse.group/t/t-deck-2-3-6-firmware-how-to-change-channel/12378/8 |
@GUVWAF |
What I might actually suggest is: instead of modifying the That way, you can focus on implementing the new features for just T-Deck right now, and gradually expand to more devices later on. |
The issue I see with making a T-Deck-specific device is that expanding would mean making classes for other models which seems impractical in the long run as new devices come out. For maintainability, one class that can generically deal with everything would be nice. |
I'm still suggesting using one class for all devices, but use a macro to select the new class. If a variant is built with the macro USE_PERSISTENT_MSG (or whatever suits), it will build with the new class, otherwise it will build with the existing Screen class. Once it's confirmed that a new device works correctly with the new class, that generic macro can be added to its specific platformio.ini file Have a look at how the |
Oh I see. That makes sense to me. Will do! |
@caveman99 Yes, I've heard about that. When I first asked about this feature on the Discord server, I was told that it would, optimistically, take a year. Based on the progress done so far, I would guess that it's going to take decently longer than that. Given the utility of this feature, I figured it is worth it to have this not-so-fancy version for now and get the fancy version later. |
What about reserve some array in RAM for cca 10 messages ? |
Even a rolling window of 10 messages for nrf52 would be great, for now until an external storage solution is developed.
Tony Good
…________________________________
From: Peter Misenko ***@***.***>
Sent: Tuesday, May 14, 2024 06:20
To: meshtastic/firmware ***@***.***>
Cc: tropho23 ***@***.***>; Mention ***@***.***>
Subject: Re: [meshtastic/firmware] Add persistent message storage and message log frame (PR #3784)
What about reserve some array in RAM for cca 10 messages ?
—
Reply to this email directly, view it on GitHub<#3784 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AQ7GUPQQ6Q3RDRBFYNBDIP3ZCHQPHAVCNFSM6AAAAABHHFLYOCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBZHAZDOMBZGU>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
This would be a whole lot more straight-forward! (Assuming there's RAM to spare?) |
Of course more than 10 would better 🙂
My ideal is the last 30 messages if available memory allows.
Tony Good
…________________________________
From: todd-herbert ***@***.***>
Sent: Tuesday, May 14, 2024 10:03
To: meshtastic/firmware ***@***.***>
Cc: tropho23 ***@***.***>; Mention ***@***.***>
Subject: Re: [meshtastic/firmware] Add persistent message storage and message log frame (PR #3784)
Even a rolling window of 10 messages for nrf52 would be great, for now until an external storage solution is developed. Tony Good
This would be a whole lot more straight-forward!
—
Reply to this email directly, view it on GitHub<#3784 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AQ7GUPRVZX5T46LK6GXRKHTZCIKRTAVCNFSM6AAAAABHHFLYOCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMJQGMZDSMJZHA>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
We've solved the throttling problem by implementing a database file for each "category" instead of individual message files in a file structure. This allows us to save messages in batches which store in a buffer that gets saved every 30 seconds to a single file, limiting our number of writes. We also now execute saving to disk asynchronously which makes the whole process safe from packet-loss. |
I tried building this to test but it's not building. Missing "message.pb.h"
|
@HarukiToreda I was told to remove that file from the PR since it can be generated using |
Can somebody review this please? |
even if I manually add the message files missing, this still won't build, we shouldn't have to manually add these files.
|
I would told to not include them here: #3784 (comment) Those are strange errors. I have never messed with any of those functions. I also do not get them on my end, even if I build for a Heltec v3. I'll look into it |
This feature is very cool and also beneficial for some meshtastic hardware I'm developing. @ndnestor Would you mind if I fork this and send you PRs over the next couple of weeks to help get it merged? |
As far as I'm aware, the only thing that needs to be changed to get this merged is that last thing @GUVWAF commented on. I'm about to push that now. But if anything else comes up that needs to be changed, I welcome the help! Thanks! |
Added
Changed
Removed
Video Demonstration
Here is a video demonstration of changes made. It is slightly outdated.
Recommended Future Changes
ostream
for more efficient string building indrawMessageLogFrame