More Meshtastic Nodes

This is a random smattering of details about the nodes I have now set up and what I’ve learned in working with them. It’s a mess, but I wanted to capture it before going to bed.

As I mentioned in a previous note I have some Heltec v1 boards. In another note I had mentioned building Meshtastic from source. You can probably see where this is going. But this was all after I bought some Heltec V3 boards. I bought one v3 for myself and two more for friends. At this point, we have all loaded up Meshtastic on our V3 boards and have stable relays by way of MQTT from the Heltec v3 clients to our t-decks. We don’t live close enough to each other to use just the mesh, so we use the internet.

On that same day I had set up the t-deck, I didn’t see a Heltec v1 image in the web-based flasher (flasher.meshtastic.org), so I had tried flashing a later image and it went poorly. Well, later on when that day arrived where I was building from source for the t-deck, I saw an entry in the platformio.ini file for the heltec-v1. I have since built that image and flashed it to both of my heltec-v1 boards. One board is in excellent shape, the other has a slightly defective screen.

previous note

another note

how that screen got damaged

Several years ago I was in the woods with my v1 boards and some battery packs. One unit I left strung up under a rain fly near the roadside border of my property. Then I took a hike with the other board towards the back of my property. Those boards were able to keep a ping going pretty consistently to about half way back on the lot. The land slopes up from the road, then down to a creek, then slowly up to a ridge of pine and hemlock trees, and then it slopes downward to a swamp, and then upwards again. The signal was able to keep a pretty decent ping to the halfway mark. Then it had intermittent connectivity towards the swamp. Did I mention the rain? The swamp floods pretty heavily and I didn’t want to chance dropping my toys in the water. The Heltec I was carrying was inside a Ziploc bag, along with the battery that was powering it. And yet, somehow, when I made it out of the poor weather and back under the relatively dry awning, some moisture had caused some pretty severe glitching of the display. I could no longer read the ping messages from the display. It sort of looks like every other row and column of pixels is dead. But the unit continued to work, otherwise.

what I have now

Fast forward to the present, I have both Heltec-v1s flashed with Meshtastic’s latest master branch (2.4.x). One is my “online” node configured to hit my MQTT server. One is configured to be my “in-car” node. Which I configured to go against the public MQTT server. My Heltec V3 is to be my “offline” node, configured to hit an MQTT server on my “home automation” network.

All the radios have a private channel with pre-shared keys with my friends (channel 0). All the radios have a public channel (the default LongFast channel, with publicly known keys) (channel 1) Some of the radios make use of an MQTT server to bridge some traffic over the internet.

“in-car” node is a Heltec v1 (public MQTT server)
“online” node is a Heltec v1 (my MQTT server)
“offline” node is the new Heltec v3 (offline MQTT server on home automation network)
“t-deck” node

the “in-car” node

This is my faulty-screen Heltec-v1. I originally configured it to go against the public MQTT server and the msh/US topic. Turns out, meshtastic devices have a fixed number of nodes they can remember. This number is smaller than all of the nodes making use of the public MQTT server. When a device has remembered all the nodes it can and then sees a new one, some fun stuff happens. It forgets the oldest node it knows about. If there are messages from the oldest node, after it is forgotten, those messages will appear to be from an unknown sender. This is not great.

So here’s some other stuff I learned as a result of running the “in-car” node

meshtastic forums claimed that an update prevents the public MQTT server from filling your local network with node entries
one node hitting the public MQTT server is enough to share nodes with the local mesh, despite the update
the local mesh can also fill up their node databases and run out of slots
despite the local mesh radios filling up their node lists, the other MQTT servers will not get all of the extra traffic, that seems limited to the local mesh
a lot of mesh activity makes it difficult to communicate with the v1 to make configuration changes
if you lose connection with the v1 while using the android app, it takes about 1 second per node to reload the app before it is possible to do anything in the app again
if you edit the source, you can only add about 255 node memories to the v1, but really that just means you get to wait longer to connect to the radio from the app
(the default) max hop value of three is too low to reach most nodes through the MQTT gateway

Ultimately I ended up disabling the MQTT publish just so I would be able to talk to the radio in the v1 again, because the node traffic made it impossible to work with. Then I subscribed to an MQTT topic that was state-specific instead of country-specific. There are very few meshes in my state that make use of the public MQTT server, but at least the device remains usable!

“online” node

The not-fault-screen heltec v1. I configured my “online” node to use my private MQTT server, but it’s having trouble staying connected to the internet. Possibly due to the traffic from the “in-car” node which I have had running in the house continuously to provide a link to the public MQTT server and nodes across the country. I only recently killed that link, so I’ll have to wait and see if it continues to suffer connection issues. I will probably replace this in the near future, I’d like my link to distant friends to be more reliable. If it proves to be too troublesome to keep it connected or connect to it for monitoring, then I’ll definitely be replacing it.

“offline” node

This is using the Heltec v3 and it has been rock solid. But what do I use an “offline” node for? How exactly is it offline? Well, it’s a node that’s on my “offline” network where all my Tasmota devices are running. I have a bunch of esp32 smart switches and plugs and some esp32-based cameras. The security on these devices was non-existent when they were running the proprietary crap they came with. I also didn’t appreciate needing a persistent internet connection to use the lights that were in the same room as me. So now they’re all running Tasmota and they use the same MQTT server that I have my offline node using.

I’ve written some code to monitor messages and I’ll be wiring up some limited input from the mesh to control devices as well as providing some status information back to the mesh about what’s going on in the house. And a few query style commands. So if I’m in the woods and someone rings the doorbell, I’ll get a message. I plan to make some of my cameras smarter too, so that if I get a package delivered or someone is in my driveway, they can notify me. This is what the offline network is for, and being in close proximity to the other mesh nodes, there shouldn’t be any problem with getting these notices no matter where I am on the property. Or if I’m not home, but I’m in the car, I will still get notices. Or if I’m somewhere near a mesh node… I would still get notices.

The goal of the offline network is to decrease the attack surface of my dumb IoT devices by keeping them off the Internet. Bridging them to my internet-connected network by way of Meshtastic pokes some holes in this, but the holes are smaller than putting it directly on my internet accessible network.

“t-deck” node

I configured the “t-deck” to route through my private MQTT server before I had reflashed the Heltec v1s. It would frequently lock up and get stuck in reboot loops. It was using a local wifi connection and going out to my private MQTT server, and even when it wasn’t stuck in a lock-up and reboot, it made it difficult to do anything useful with it. So reflashing the Heltec v1s for the connection role was great because it freed up the t-deck to be my portable device and it mostly stopped it from locking up and going into an annoying reboot. It did much better listening to the Heltec v1 “in-car” node blast my local mesh with updates from the MQTT server.

While the “in-car” node was blasting my network with messages and telemetry from other nodes I noticed some stuff about the t-deck.

The t-deck:

only displays the last line sent on a given channel
only displays the last message sent from the last four users or so
will interrupt a message being composed if a message comes in while a message is being composed
has limited ability to resume composing a message that has been interrupted
has no means of trace route and makes a terrible field diagnostic tool unless you carry a mobile phone, which defeats the utility of the extra input and large screen
reboots too much
fits pretty well in a pocket with little risk to the antenna due to its awkward size

more common stuff

In order to get the device to only publish their own locations as encrypted and shared with the trusted network, that network had to be on channel zero and set as primary. This means that getting channel 1 LongFast to match the public LongFast channel, and override frequency had to be set. I’m still foggy on why this is the case. We did this collectively so that position information would be shared over the encrypted channel.

The devices will share their position with other channels if the setting is toggled on on a per channel basis. And in doing so, will share the position un-encrypted, every 15 minutes. So do they share the position of their friends only over the encrypted channel? I’m not too sure on this.

Every device has a node list or node DB that it creates. The size of the node list is hard-coded on most devices to 100. If there are more than this maximum, the old ones get pushed out, and messages and status information for “unkown” start to crop up. These messages still have sender information in them, its just that the UI is unable to find the owner name to display who it is from, and for some reason, they will show question marks in the mobile app, or unknown, depending on where the information is used. So despite having the device id (a mac address) it becomes impossible to tell who a message is from in the UI.

Any device that is using WiFi will not be able to connect via Bluetooth. Some devices using Bluetooth disable their serial ports, seemingly at random. This isn’t just overwhelmed devices that are laggy in responding, the configuration value gets disabled. Generally connecting and disconnecting frequently to a device makes that device harder to operate. Despite a physical serial connection, maintaining a connection with the web-based client is problematic. Some devices will serve up a web-based client and others have to be connected to with client.meshtastic.org, which is tricky in a disconnected environment. Depending on what web-based client is being used, some options, like trace route, are not available.

The android client with a bluetooth serial connection seems to be the most reliable means of interacting with a device and it provides a comprehensive history of messages instead of having a limited view of the last sent or received message for a channel or user.

it’s late

It’s getting late, but I’ve managed to capture some details here about my current setup and what I’ve learned so far. I’m having a lot of fun.

Tags: index, meshtastic

Tags

#index

#meshtastic

index