I have started to get involved in Meshtastic. My first idea was to extend the features with a standalone operation. (Thus device can send text message without the phone app.)
I have already designed a 3D printed case with an integrated rotary encoder. You can find the design here:
I can imagine a new screen where the user can select from predefined (canned) texts to be sent. I can also imagine some sentence forming methods, like adding parts of the sentence from another set of predefined words. E.g.:
āI need help with @{subject} at @{location}ā and subject can be: saw, water, shed, fire, ambulance; location can be: my GPS location, home, the forest, the river side, the landing zone; etc.
I might be able to do the coding myself, but some help might be useful because this a quite complex project. My question will follows.
Very cool idea, there have been discussions about pre canned messages before, I imagine much of the code involved is pretty similar to that required by the I2C keyboard.
Garmin inReach Mini is a satellite messenger that also uses a ālimited inputā mode for selecting pre-canned messages. You might take some interface inspiration from them! That case and rotary encoder looks great!
Garmin just released a new version of inReach Mini - Mini 2 with a bit better menu, mesaging options, navigation, digital compass,ā¦ - this would be an ideal form factor for meshtastic device.
@garth Iām fairly excited about this. I just ordered some encoders and hope to try this out soon.
Any chance you will do some more updates within the 1.2.x branch?
For the 1.3.x / 2.0 branch I wonder if it would be a good idea to use āshort codesā so canned messages can be sent and received without sending the actual message.
Maybe something along the lines of 'If message starts with ^ lookup the part following ^ from an internal table and display that message. ^1 could be āIāve reached my destinationā, ^01 āHeading back nowā, ^11 āIām Okā and so onā¦ if the data after ^ isnāt a message in the table it would just display whatever the payload was as a normal message.
The more I think about this the more Iām liking it. With this short code idea people without encoders can still use the short codes as manual entries or from a selection from the various apps and the transmission times would be very quick.
I donāt actually write any firmware but I think generally stuff that will go back in 1.2 will be things that are same in both, probably not the case here as it needs some work to finish up and we probably need to clean up some of the storage of the canned messages.
What you can see in the actual documentation is actually works now out of the box. the only issue we are facing with is how to configure (transfer) message templates, as currently we are topping out a limit here. So, if you have a hardware you can already try canned messages, but you will be limited to about 200 bytes of message template size in configuration.
I was working on a solution but stuck. I might want to continue in 1.2 as this was the base of this solution already.
About the short codesā¦ I do not see the benefit of that. You meant to have a built in lookup table by the sort codes, or this should be a configurable thing?
Looking forward to seeing this function to test too. I also ordered some encoders
It looks like itās possible to setup custom messages:
Up to 50 messages with a total length 200 bytes.
Example from the documentation using the Python-CLI:
meshtastic --set canned_message_plugin_allow_input_source ā_anyā
meshtastic --set canned_message_plugin_messages āIām fine|Iām out|Iām back|Need helping hand|Help me with saw|I need an alpinist|I need ambulance|Keep Calm|On my way|I will be late|Iām already waiting|We have company|Beer is cold|Rogerā
I think some devices have an additional spi flash storage, is that already being used by the project?
My other idea was to include default canned messages in the firmware. Since the messages have to be stored on device somewhere instead of transmitting the message itself, just send a reference
This is very stupid. But it turns out that every configuration setting is actually handled as a mesh packet (e.g. you want to remotely set some configuration). Now, a mesh packet is about 250 bytes long at maximum, containing here all other configuration as well.
A new approach is developed meanwhile, and waiting to be part of the next release. This will not be part of 1.2 any more.
I also tested on two tbeams. When pressing the push button on the encoder the canned messages plugin shows up on the screen however the rotary controls do not work and Iām only able to select the first message. Is anyone else encountering this on tbeams?
Expected Behaviour:
User presses push button on the rotary encoder
Device displays list of messages configured in canned messages plugin
User rotates the rotary encoder clockwise or counter clockwise to select one of the messages
Device responds to the rotary encoder movements and scrolls up or down the list of messages
User selects message to send and presses push button on the rotary encoder
Device sends message and displays āSending Messageā¦ā on screen
Message is successfully sent
Current Behaviour:
User presses push button on the rotary encoder
Device displays list of messages configured in canned messages plugin
User rotates the rotary encoder clockwise or counter clockwise to select one of the messages
Device does not scroll through messages. Only first message is selectable.
Looking at other tutorials online it looks like the rotary encoder might need some resistors and capacitors added.
You do not need any resistors or capacitors as I do the debouncing in software. However the rotary encoder must be set up correctly. Iām not sure what pins you can use on Heltec v2 LoRa or TBeam, but those pins must be suitable for proper digital input and not used by any other onboard parts.
Also check the setup of the rotary in the documentation: Canned messages | Meshtastic
That case and rotary encoder looks great!
