by ·0 Comments

A few months ago I started a pro subscription to Claude in an effort to learn how to use generative AI. I wanted to understand what it could and couldn’t do well. In this post I will cover a few of the ways I have found to use Claude and generative AI in general. The vast majority of the time I interact with Claude.ai using the desktop app and I leverage plain Chat, Cowork and Code. These are quick and simple examples and not an exhaustive description of how I am using it. My use of AI is centered mostly around “technology” rather than spreadsheets, email or other use cases you routinely see advertised. Being honest, I find AI to be less ideal for those use cases as of today but I also don’t try, your mileage may vary.

If your understanding of what AI can do is based solely what “Apple Intelligence” or from the abundant horror stories you find on the web, I encourage you to consider more full feature solutions like OpenAI’s ChatGPT and related systems or Anthropic’s Claude. These are far more capable AI solutions that, while they may not tie into your data the way Apple Intelligence [poorly] does, are capable of a lot more.

Chat

Claude has nearly completely replaced my use of search engines for most operations that might require reading multiple pages to get an answer. Claude’s ability to take in information, dedupe and summarize it based on what I’m really looking for in a matter of seconds removes a lot of friction and helps answer questions quicker. A recent example of how to utilize Claude was to find parts for my mower. I know that while it is branded “Craftsman” it is actually sold under multiple names and tracing this back can be difficult. Giving Claude the make and model number and asking it to find the correct replacement rear wheels gave me the exact part numbers for various makes as well as the fact the part number mentioned in the owners manual has been superseded with an improved design. Doing this myself would have taken significantly longer.

Through various connectors, capabilities and MCP servers, Claude also helps me to:

  • manage my music collection as well as find new music based on my purchases and listening habits
  • help get unstuck in a game I am playing while avoiding spoilers
  • find and resolve banking discrepancies
  • manage my home lab inventory
  • much more

All of this is done using plain language to tell Claude what I want and it takes care of it. When it is unsure of how to proceed it asks.

Chat is also where I typically work with Claude to help debug issues I run into which can range from simply asking it questions about the best way to get a stain out of something to pasting in large log files to pin point a root cause.

Cowork

To be honest, the distinction between Chat and Cowork in Claude is a bit loose to me as there is a lot of overlap between what each can do. The difference in Cowork is it shows you a plan and you can schedule the tasks to be run periodically. That said, I have largely handed management of my entire home lab over to Cowork. My home lab consists of multiple Proxmox instances running various VMs and a k3s based Kubernetes cluster. I described to Claude Cowork how to access all resources, the location of my FluxCD repository and put it in charge of managing software versions, resolving issues and so on. Claude examines the software that is installed, checks for updated versions, validates the configuration has changed and ensures software upgrades cleanly. If there is an issue where it can rollback it does, if it can’t it alerts me through email of any potential or current issues it can’t cleanly resolve. Claude also has access to my Cloudflare account for Zero Trust and DNS management meaning I can add software using plain language. I describe to Claude what new software I want to add, it adds it to the FluxCD project and configures ingress through Cloudflare.

Code

Code behaves differently from the other two parts in a meaningful way. It has more direct file and remote system access meaning it doesn’t have as strict of requirements for accessing files on the local system or accessing remote systems through ssh. I have used Code extensively to update plugins/themes on this site, resolve font loading issues and more.

I have also used Claude Code to create a few projects including:

  • Raspberry Pi based streaming music player that can stream my music from Plex but give me physical controls like an old CD player.
  • Port my old ControlPlane app from Objective-C to Swift and modernize it.
  • Various small utility apps like a daemon for Linux that sets the RGB lights on my otherwise unsupported keyboard to white and a tone generator for testing audio equipment.

In General

Overall, Claude has proven to be well worth the monthly subscription cost and is not something I want to give up. While I can do a lot of what it can, it can do it more quickly and a lot of the times more accurately than me. It makes mistakes the same way I could and I can guide or redirect it as required. Allowing Claude to manage my home lab frees me from doing more tedious work and gives me time back.

Claude and AI in general can certainly make mistakes. You do still need to validate information it gives you and be aware that, like people, it can get confused and be confidently incorrect. While doing some vehicle research I found that Claude would repeatedly bring in details from a previous model of a vehicle I was looking at. I had to be very specific about the exact year and model name I was looking for and ask it to find sources. This has happened less as models improve but I have also learned how to better prompt the AI for what I am looking for.

In a future post I will dig a bit deeper into how I prompt Claude and ensure it is doing what I want with guardrails in place to stay as safe as I can while still getting real work done.

by ·0 Comments

Today I’ll look at how I recovered from a failed Proxmox 8 to 9 upgrade on a small form factor Dell that I use. This system is one of two in the cluster, and it failed during the upgrade process. This failure was not caught by the pve8to9 utility, which gave me a clean report prior to the upgrade. However, during the last few steps of the upgrade, I got the message below, which made me think I would be doing some extra work on reboot.

Installing for x86_64-efi platform.
grub-install.real: error: cannot find EFI directory.
Failed: grub-install --target=x86_64-efi
WARNING: Bootloader is not properly installed, system may not be bootable

I could have investigated the situation right there but decided to send it and reboot the system anyway. The system failed to boot, instead showing the Welcome to GRUB message for a moment before restarting the system which then went to the BIOS setup screen. My issue matches one reported on the Proxmox forums quite well so I followed what OP did. You can find the post at https://forum.proxmox.com/threads/pve-9-grub-stops-the-machine-immediately.169366/.

Using balenaEtcher on macOS, and the systemrescue image at https://www.system-rescue.org/Download/, I copied the image to a USB drive and then booted the Dell system from it. From there, I mounted the disks as described in the forum post and ran the necessary commands as well as some others that I found were necessary for my situation. Here is the list of commands I ran on my system after ensuring /dev/sda was my root/boot device:

mount /dev/mapper/pve-root /mnt
mount /dev/sda2 /mnt/boot/efi
mount --bind /dev /mnt/dev
mount --bind /sys /mnt/sys
mount --bind /proc /mnt/proc
mount --bind /dev/pts /mnt/dev/pts
chroot /mnt
mount -t efivarfs efivarfs /sys/firmware/efi/efivars
grub-install --target x86_64-efi --no-floppy --bootloader-id proxmox /dev/sda
grub-install --target x86_64-efi --no-floppy --bootloader-id proxmox --removable /dev/sda
echo 'grub-efi-amd64 grub2/force_efi_extra_removable boolean true' | debconf-set-selections -v -u
apt install --reinstall grub-efi-amd64
update-initramfs -u -k all

Once this finished I did the following

umount /mnt/dev/pts
umount /mnt/proc
umount /mnt/dev
umount /mnt/sys/firmware/efi/efivars
umount /mnt/sys
umount /mnt/boot/efi
umount /mnt/
reboot

As it rebooted I removed the USB stick from the system. My system was now able to boot without issue and I went back to ensuring the upgrade was successful and I could migrate my VMs back to it.

I am not certain what step I might have missed that could have prevented this, so if anyone knows I would love to hear about it.

UPDATE: On my second machine of the cluster I noticed an informational message that mentioned running the following commands to resolve an issue:

echo 'grub-efi-amd64 grub2/force_efi_extra_removable boolean true' | debconf-set-selections -v -u
apt install --reinstall grub-efi-amd64

Since this is part of what I did to recover the first system, I am going to assume it is likely this is what prevented the second system from failing in the same way. While pve8to9 mentioned the issue, it wasn’t listed as a warning, only informational and a lot easier to miss.

by ·0 Comments

This post describes how to set a “favorite node” using the PKI or remote admin functionality built into the Meshtastic firmware. It assumes that you have already setup a working remote admin system using official documentation. If you haven’t do that first and then return here for how to use the Meshtastic CLI tool to set favorite nodes.

Additionally, you may want to look at my post on how to get Linux to connect to a node using Bluetooth as well as setting up a Python virtual environment. This post is located at https://dustinrue.com/2025/12/connecting-to-a-meshtastic-node-using-bluetooth-from-linux/. This post assumes you are using Bluetooth to set favorite nodes on a remote target.

Setting favorite nodes remotely is surprisingly easy. You will need to activate your virtual environment (. ./venv/bin/activate) or whatever name you used to create your venv. Next, you will need to know the node IDs of the remote host you want configure AND the node IDs of the nodes you wish to favorite. In my example, I know that the node ID of my remote node is a5592387 and the ID of the node I want to mark as a favorite is 0c3a3de4. With this information on hand, I can use the command below to target a5592387 with a set-favorite command to set 0c3a3de4 as a favorite using bluetooth.

meshtastic -b D0:9D:0C:3A:3D:E4 --dest '!a5592387' --set-favorite-node '!0c3a3de4'

You may have noticed that I have marked the Bluetooth node as a favorite node on my remote node. That is correct! In an effort to use the 0-hop feature of the 2.7.x firmware series, it is necessary to add next hop nodes as favorites so that the hop count is not reduced. This feature is detailed in a blog post over on meshtastic.org.

You can use this method to perform a number of admin tasks using the Meshtastic CLI and some options, like setting favorite nodes, can only be done using the Meshtastic CLI if you are using the iOS client. For a complete list of commands for the Meshtastic CLI, issue meshtastic and press enter.

by ·2 Comments

Quick post describing the steps necessary to connect to a Meshtastic node from a Linux system, such as a Raspberry Pi, using Bluetooth. Connecting to a Meshtastic device using Bluetooth is something I struggled with initially and I am writing this both for my own reference but also in the hopes it proves helpful for someone else.

This post is from the point of view that you are using a Raspberry Pi. On my Pi, I am running Ubuntu 24.04 (64 bit). To get this working I have created a Python virtual environment (python3 -m venv meshtastic && . ./meshtastic/bin/activate) as well as the package bluez. Next, follow the steps below:

  • enter the Bluetooth CLI with bluetoothctl.
  • Issue
    • agent on
    • discoverable on
    • scan on
  • Allow the scan to run long enough for your node to appear by name
  • Issue scan off to stop scanning. The device should now show up if you issue devices
  • Copy the hardware or MAC address of the device you want to connect to. In this example, the MAC address I am connecting to is D0:9D:0C:3A:3D:E4.
  • Issue pair D0:9D:0C:3A:3D:E4 to pair with the device. You will be prompted for the passkey for the device. Enter either what is on the screen, pre-configured or what you already set it to if you have already performed initial setup using another app. If bluetoothctl says the device is not available, run the scan again and attempt to pair again. If you wait too long the device will be removed. Once paired, it will stay.
  • Issue trust D0:9D:0C:3A:3D:E4 to trust the device.
  • Issue disconnect D0:9D:0C:3A:3D:E4 to disconnect so that other apps can connect instead.
  • You are done using bluetoothctl and you can type exit or press ctrl+d to exit it.
  • reboot your device. I had issues with bluetoothctl staying connected to the node when it shouldn’t have.

You will now be able to use the Meshtastic CLI tool to interact with the node. To do so, ensure you have activated your virtual environment with . ./meshtastic/bin/activate and have installed the Meshtastic cli tool using pip install meshtastic. If you have issues with the CLI tool connecting, make sure any other client applications have disconnected from the device AND you have closed the app. Nodes will only allow a single connection at a time.

At this point you will be free to run client applications such as the Meshtastic CLI tool or contact, a text UI based tool.

by ·0 Comments

This post is going to be a lot less of a full “how-to” on how to use Minio as a build cache for Gitlab and a lot more of a post discussing the general process and the tools I used. How I set up Minio to be a build cache for my Gitlab runner is a lot more complex than I care to get fully into in a blog post, but I am posting this in the hopes that it at least inspires others.

A Lot of Context

In my setup, my Gitlab runner lives in Kubernetes. As jobs are queued, the runner spawns new pods to perform the required work. Since the pods are temporary and do not have any kind of persistent storage by default, any work they do that is not pushed back to the Gitlab instance is lost the next time a similar job is run. Having a shared build cache allows you to, in some cases, reduce the total amount of time it takes to perform tasks by keeping local copies of Node modules or other heavy assets. Additionally, if you configure your cache key properly, you can pass temporary artifacts between jobs in a pipeline. In my setup, passing temporary data is what I need.

I use Gitlab for a number of my own personal projects, including maintaining this site’s codebase. While my “production” site is a Digital Ocean virtual machine, my staging site runs on Kubernetes. This means, along with other containers I build, that I need to containerize the code of my site, which also means I need to push the container images into a registry. This is done by authenticating against the container registry as part of the build pipeline.

Additionally, I am using Gitlab CI Catalog or CI/CD components. The Gitlab CI catalog is most similar to GitHub Actions, where you create reusable components that you can tie together to build a solution. I am using components that can sign into various container registries as well as build container images for different architectures. In an effort to create reusable and modular components, I split up the process of authenticating with different registries and the build process. For this to work, I must pass the cached credentials between the jobs in the pipeline. Using the shared build cache to pass the information along ensures that I can keep the credentials available for downstream jobs while keeping them out of artifacts that a regular user can access.

My Solution

For my solution, I am leveraging a number of components I already have in place. This includes k3s as my Kubernetes solution, TrueNAS Scale as my storage solution, and various other pieces to tie it together, like democratic CSI to provide persistent storage for k3s.

The new components for my solution is the Minio operator, located at https://github.com/minio/operator/tree/master/helm/operator as well as a tenant definition based on their documentation. The tenant I created is as minimal as possible using a single server without any encryption. Large scale production environments will at least want to use on-the-wire encryption.

Configuring for my runner looks like this:

config.template.toml: |
  [[runners]]
    request_concurrency = 2
    [runners.cache]
      Type = "s3"
      [runners.cache.s3]
        ServerAddress = "minio:80"
        AccessKey = "[redacted]"
        SecretKey = "[redacted]"
        BucketName = "gitlab-cache"
        Insecure = true
      Shared = true
    [runners.kubernetes]
      image = "alpine:latest"
      privileged = true
      pull_policy = "always"
      service_account = "gitlab-runner"
    [runners.kubernetes.node_selector]
      "kubernetes.io/arch" = "amd64"
    [[runners.kubernetes.volumes.empty_dir]]
      name = "docker-certs"
      mount_path = "/certs/client"
      medium = "Memory"

From this, you can see that my Minio tenant was installed with a service named minio running on port 80. I used a port forward to access the tenant and then create my access credentials and a bucket which was plugged into the runner configuration and deployed using a Helm chart for Gitlab Runner. If you are using Amazon S3 in AWS, then you can leverage AWS IAM Roles for Service Accounts and assign the correct service account to the runners to achieve the same behavior more securely.

With this configuration in place, I am able to cache Docker authentication between jobs in a pipeline. In a future post, I will more fully detail how I am doing this in the CI Catalog, but for now, here is the YAML to define the cache key:

cache:
  - key: docker-cache-$CI_PIPELINE_ID
    paths:
      - $CI_PROJECT_DIR/.docker

By setting the cache key in this way, I ensure that Docker credentials are passed between jobs for an entire pipeline. Care needs to be taken to ensure cached the information is not included in artifacts particularly if they are sensitive in nature.

by ·0 Comments
Photo of some capacitors removed from the Super Nintendo motherboard. Credit to https://www.reddit.com/r/snes/comments/1gw7zyb/snes_shvc_cpu_01_full_recap_and_audio_balance_fix/

Having grown up in the 80s/90s and experiencing what we now call “retro game consoles” firsthand when they were new, I have fond memories of playing old games and, even more so, the hardware itself. While not everyone agrees with me, the original US, NTSC Super Nintendo is among my favorite-looking consoles Nintendo ever put out. I still have my original SNES from the early 90s and will occasionally play games using an old CRT television set and the original controllers.

Originally released in 1991, the SNES is now well over 30 years old as of 2025, and as you can imagine, some of the components are beginning to show their age. Notably, the capacitors themselves are filled with a liquid that, over time, can begin to leak out and cause damage to the board. The first revision SNES consoles, which I have, are prone to this common issue, and it is better to replace them before they leak rather than after. This failure mode is not something I was aware of when I put my console back into service, so I decided to try replacing the capacitors using a kit. This is not a sponsored post at all; I am only relaying what I used to ensure my console stays running as long as possible.

The kit I got was from console5 at https://console5.com/store/nintendo-snes-smd-type-cap-kit-shvc-models.html. This kit includes all of the surface mount capacitors as well as capacitors for inside the sound module, which is separate from the motherboard on the first revision motherboard, as well as an additional capacitor for the power regulator. I replaced all of the surface mount capacitors on my system but skipped the capacitors for the sound module as those are a lot less likely to leak and cause issues. I also did not attach the included capacitor to the power regulator. This didn’t seem necessary to me.

I am obviously not the first person to do this and there are a lot of examples on the web with far more knowledgeable people than me. The featured image for this post came from https://www.reddit.com/r/snes/comments/1gw7zyb/snes_shvc_cpu_01_full_recap_and_audio_balance_fix/ and that user discusses some additional modifications he made to the system.

My system had more damage than I realized. Two capacitors had begun to leak under them and caused some damage to the pads, which lifted off the board. In both cases, I had to repair this using additional bits of wire to the leg of the capacitor to the next closest component. In addition to this, the leaked fluid can make it much more difficult to remove old solder or get solder to “stick” to the component. Getting the old solder pad cleaned up was a difficult task on one of the two capacitor pads. Amazingly, despite my lack of real experience doing any of this, I ended up with a working console in the end!

If you are looking for replacement parts for your console, definitely check out console5. They have a lot more than just SNES parts. Shipping about doubled my cost, but it was fast, and everything I needed was included.

by ·0 Comments

Between Safari 26.x or changes Cloudflare has made to their Automatic Platform Optimization (APO) system, something went wrong with Google based fonts on my site when viewed in Safari. Attempting to access the fonts under Safari results in 400 errors, or invalid requests. Resolving this was not immediately obvious but a snippet in the APO helped me find a path forward that restored the intended look of my site.

This FAQ answer held the secret – https://developers.cloudflare.com/automatic-platform-optimization/troubleshooting/faq/#why-are-my-font-urls-not-being-transformed. While the “question” pondered why the fonts were not being transformed, it helped me understand how I could override the default behavior of APO when it sees Google fonts being referenced. By modifying my Content Security Policy header so that fonts were not allowed from my domain I was able to restore the intended look. When APO sees the CSP won’t allow fonts to be served from the same domain, it will avoid rewriting the URL for the font. Since I don’t serve any fonts off my domain, this is a quick and easy fix to avoid the issue.

by ·0 Comments

If you are in the market for a solar powered mesh radio device, maybe for Meshtastic, and like me you just want to get up and running with something that is assured to work, then you may want to consider a base station kit from https://mesh-lab.com/products/solar-base-station-kit. Made by same person behind Yeti Wurks, this base station kit has almost everything you need to get a solar powered mesh radio node up and running quickly. I say “almost everything” because, while the solar charger half of the kit includes 6 18650 cells, ideally you would insert at least one 18650 battery into the case as well. The kit was recommended to me by a local mesh group (mspmesh.org). I paid full price for the kit and this is not a sponsored post in any way. What follows is an overview of what you receive in the kit and how to use it.

What is included

The box I received contained everything described on the product listing. This includes:

  • RAK4631 radio in a weather resistant case.
  • Solar charger with 6 18650 cells preinstalled.
  • Antenna.
  • Mounting bracket that you selected at order time.
  • Mounting hardware for the solar panel and more.
  • Directions.
  • Stickers!

Below is a look inside the weather resistant case.

In the case is of course the RAK4631 radio and an additional 18650 cell holder capable of holding up to four additional cells. Pay special attention to the note about battery orientation as the holder is designed for parallel connections rather than serial! Additionally, when inserting the cells pay special attention that the positive side of the cell makes a connection with the contact. In my sample, the cells fit very tightly and it may not make a connection if you don’t slide it against the positive terminal.

Along the edge of the case starting from the top and working clockwise is an N-type antenna connector, a switch to connect/disconnect the four cell battery back from the RAK4631 charge controller, a power connection and USB-C port. Difficult to see in the photo on the left side of the case is a weather resistant vent to allow for pressure equalization.

Also included in the kit is this solar charger, which I’m linking to directly as it provides better photos and description – https://mesh-lab.com/products/off-grid-solar-charger-5-5-watt-5vdc-2-5a. This unit is available separately and includes 6 18650 cells. Also included in the kit is all of the mounting hardware which works perfectly with the 3d printed mount that you selected at order time. The solar panel seems surprisingly efficient and will charge the cells, albeit slowly, even in overcast conditions. Combined with a power efficient RAK4631, this solar panel and battery pack will keep it going for many days. While the panel and battery pack are great, the mounting post included with the panel seems a bit on the flimsy side and I don’t know how it will hold up to the elements over time. For the price, however, I can’t expect much more.

At order time I selected the larger 2″ PVC pipe mounting option. This integrated mount, also available in the store separately, is a 3d printed piece designed to be attached a 2″ PVC pipe using the included worm gear clamps. This all worked very well for me and I had no issues. Again, all screws, clamps and such were included with the kit. The solar panel attaches to the mount as does the weather resistant case. Then the whole unit is attached to whatever pole you have.

Mini Review

I have had the kit for all of a few days as of this writing but I am able to say that everything that is included with the kit works very well together. The RAK4631 radio included in the kit is known for being reliable and power efficient, perfect for solar applications.

If you are looking for an easy to assemble and ready to go device for joining a mesh network, I highly recommend you consider this kit by mesh-lab.com. If you don’t need a solar powered kit there are other options available as well. My thanks to the folks on the mspmesh.org Discord for helping me find a ready made kit. Now that I have something working and in the wild I will likely build additional nodes on my own and I’ll post about my experience here.

Earlier I mentioned that the kit recommends you insert up to four additional 18650 cells into the weather resistant case. This helps ensure proper operation of the RAK4631. I didn’t have any additional cells so, from the recommendation of others, I simply stole one cell from the solar panel. Doing so as easy as opening the back of the solar panel case by removing the rubber covers over the screws, undoing the screws and removing one cell. Be sure to understand how to orient 18650 cells when inserting them into the weather resistant case!

by ·0 Comments

This is a quick guide to performing an over-the-air update of a RAK4631 device using iOS and the DFU application by Nordic Semiconductor. Based on known and personal experience, performing an over-the-air update of this device carries some amount of risk as the device does not have a fall back in the event of an error. If the update fails your device will be left in a state where you need physical, wired access in order to recover. If you have any other method available to you I recommend using that method rather than an over-air-update.

This guide specifically covers using the DFU app on iOS to flash the latest Meshtastic firmware to a RAK4631. Many of these steps may be the same on Android and may work for other, similar devices, but I don’t have these to test with. You will need three things to perform an over-the-air update of a RAK4631 or similar device:

  • iOS device with DFU software installed.
  • The DFU app is properly configured prior to attempting the update.
  • A copy of the correct firmware file you wish to apply to the device. You can find the latest release on the Meshtastic website at https://meshtastic.org/downloads/. I recommend using a “stable” release.

Optionally, if you are using iCloud drive you can download and work with the files on a Mac and place the file on your iCloud drive for easier access on the iOS side.

Configuring DFU

It is very important that you confirm DFU is configured properly prior to applying any update. Failure to do so on iOS will almost certainly result in a “bricked” device that you will need to take down and connect to using USB in order to recover. Configuration is simple. Open the app and tap on settings. Ensure you enable the first option and set the number of packets to 10. Your settings page should look similar to this screenshot:

Note that all options are at their default values, or disabled.

Getting the proper firmware

It is important that you download the correct firmware from the download page. If you do not, you will be unable to perform the update as the DFU app will complain there is no manifest.json file available. To find the correct firmware, use the following steps:

  • Go to the downloads page at https://meshtastic.org/downloads/.
  • Scroll down to the assets section.
  • Find the firmware with “nrf52840” in the name such as firmware-nrf52840-2.6.4.b89355f.zip and download it.
  • Extract the zip file and find the firmware specific to your device with “ota” in the name, for a 4631 it might named firmware-rak4631-2.6.4.b89355f-ota.zip. You are If using a Mac + iCloud drive, copy this file to a location you can find on the iOS device or if already on iOS select this file in the DFU app when told to.

Applying the update

Now to apply the update to the device. Start by opening the DFU application, confirming the configuration is set properly and then tap on select file. Here you should browse to the location of your iCloud drive or the downloads section of iOS and select the firmware file with “ota” in the name.

Next in the Device section, tap on select and find your device. You can also tap on “nearby” to filter on items that are close.

Once you have selected your device, the last step is to tap upload. Be sure to ensure your screen or device does not turn off during the process!. Remember, if for any reason the update fails, you will need to connect the device directly to a computer in order to recover. After some time the update will complete and the device will restart using the new firmware. Adjust any settings that you need to adjust and enjoy your updated device.

by ·0 Comments

As of this writing I have two Heltec V3 Meshtastic nodes that I use to gain access to the greater Meshtastic network in my area. One is installed at a static location, the attic of my house, while the other one is either in my office or I take it with me. I interact with it using the Meshtastic software on my phone or on my desktop computer. One of the features of Meshtastic is to advertise some node metadata including location. My more mobile node gets my current coordinates from the Meshtastic client connected to the node over Bluetooth, but the static node has no way to know its location so I must tell it. In this post, I will walk through how I advertise a static location for the node installed in my attic as it wasn’t as straightforward as I initially thought it would be.

While it isn’t necessary to advertise the location of your node, it is useful because it helps provide some indication as to how your messages are traveling. You also don’t need to advertise a perfectly precise location though you shouldn’t advertise it as being somewhere on the other side of the planet. I am making some heavy assumptions, primarily that you already know how to install the Meshtastic command line client. If not, take a look at the directions available at https://meshtastic.org/docs/software/python/cli/installation/. It is possible to configure the node without using the command line client but I don’t cover that here. I use the command line client because my static node is connected to a raspberry pi via USB which powers it and allows me to manage it that way.

Getting and setting your coordinates

Before you can set the coordinates for a Meshtastic node, you need to know what they are expressed as a latitude longitude pair. I found that the simplest way is to use google.com/maps, look for the location you want to advertise and get the latitude and longitude values from. To do so, search for the location, right click where you want to advertise and click the top pair of values which will copy them to your clip board. Next, modify the following script to suite your needs to set the values on your Meshtastic node:

#!/bin/bash

meshtastic --port /dev/ttyUSB1 --set position.fixed_position True
meshtastic --port /dev/ttyUSB1 --set position.gps_mode 2
meshtastic --port /dev/ttyUSB1 --set position.gps_enabled False
meshtastic --port /dev/ttyUSB1 --set position.gps_update_interval 300
meshtastic --port /dev/ttyUSB1 --setlat 45.126 --setlon -93.488 --setalt 1

Google will provide very precise coordinates but keeping 3 to 4 places of precision is plenty. One key thing to remember is that, despite what the command line help will tell you, you should set the altitude to something other than nothing or 0. You can provide a proper altitude in meters above sea level or simply setting it to 1 will suffice. Depending on your setup, you may not need to specify the port. I show my port for reference as the Pi the node is connected to has other USB devices attached.

After configuration, your node will begin to advertise its position as often as you configured it to using the gps_update_interval value. You can modify this to suit your network.

Bonus content

Keeping with our scripted methods of managing a Meshtastic node, here is a bit of bonus content. I also set a name for my static node so it is easier to identify consistently on the network. If you ever need to factory reset your node and want to set the name again (if you don’t have the config saved or whatever) then this simple script will help:

#!/bin/bash

meshtastic --port /dev/ttyUSB1 --set-owner "MOONBASE" --set-owner-short "R2D2"

This will set the name of your node easily. You can combine these steps into a larger script to help maintain your node more easily.