So one thing I’ve done to help me find more things to self host or do is think like a prepper. Like…what if my ISP goes out? How can I remotely control my homelab or even trigger Home Assistant events if my ISP is out? I had no idea how to solve this until about 6 months ago when I discovered Meshtastic.
For anyone who doesn’t know: Meshtastic is basically an open-source, public mesh-network. You just buy a cheap ESP32 device, flash it with Meshtastic (They have a SUPER easy web-flasher so you don’t need to be super technical to do it), and connect to it via Bluetooth with your phone and you’re good to go! Then you can send messages to other nodes around you and have fully off-grid communications!
Well, while Meshtastic supports MQTT, that does require at least one end of the connection to have internet access. I wanted a way to SSH into my servers and diagnose or fix things without needing to rely on my ISP at all. Or even trigger things in Home Assistant without having access to any ISP. So, that naturally gave way to the idea of MeshExec.
MeshExec is a little binary that attaches to your serially-connected Meshtastic node, and looks for messages in a specified private channel for aliases to execute. Then it will execute whatever commands you specify and automatically chunk them and send them back through the mesh in a staggered fashion. This chunking is done to both fit inside the max message size that Meshtastic supports, and so that the mesh is not overwhelmed with messages and drops them.
You define the aliases, the shell used to execute the commands, etc. So you can basically use it to do whatever you want over the mesh! I’ve set up a handful of aliases to do simple diagnostics on my homelab servers. Things like restarting docker containers, checking the top 3 processes consuming the most memory, etc.
I decided to use aliases because I figured direct shell access to a server is SUPER dangerous, especially if you accidentally attach the daemon to a public channel.
No idea if this will be useful to anyone else, but I made it as easy to use as possible if anyone does want to use it. Here’s the link to the repo if anyone wants to give it a go.
I just wanted to share how I’ve managed to find a way to further reduce my reliance on big corporations and my love for open-source software!
If anyone decides to give this a try, I’d love to know your thoughts or answer any questions you have!
Admittedly, I haven’t finished reflashing my formerly-Meshtastic LoRA radios with MeshCore yet, so I haven’t been able to play around with it yet. Although both mesh technologies are decent sized near me, I was swayed to MeshCore because I started looking into how the mesh algorithm works for both. No extra license, since MeshCore supports roughly the same hardware as Meshtastic.
And what I learned – esp from following the #meshtastic and #meshcore hashtags on Mastodon – is that Meshtastic has some awful flooding behavior to send messages. Having worked in computer networks, this is a recipe for limiting the max size and performance of the mesh. Whereas MeshCore has a more sensible routing protocol for passing messages along.
My opinion is that mesh networking’s most important use-case should be reliability, since when everything else (eg fibre, cellular, landlines) stops working, people should be able to self organize and build a working communications system. This includes scenarios where people are sparsely spaced (eg hurricane disaster with people on rooftops awaiting rescue) but also extremely dense scenarios (eg a protest where the authorities intentionally shut off phone towers, or a Taylor Swift concert where data networks are completely congested). Meshtastic’s flooding would struggle in the latter scenario, to send a distress message away from the immediate vicinity. Whereas MeshCore would at least try to intelligently route through nodes that didn’t already receive the initial message.