A while ago I learned about LoRa, or Long Range, protocol and some the applications of it. In short, LoRa is used on common ISM bands for sending data long distances over the air. While it sounded neat, it didn’t interest me enough to try it. More recently however I learned about Meshtastic which is an application that uses LoRa protocol to pass primarily text based information to other nodes by forming a mesh network. Meshtastic uses LoRa to pass messages between nodes and each node, depending on configured role, will continue to pass that message to up to (by default) three additional nodes within reach in an effort to get your message to the desired recipient(s). Additionally, Meshtastic can be configured to use MQTT to use as a backbone to pass messages over the local network or even the Internet.

Not to be confused with channels in radio jargon, but still similar, Meshtastic works by creating channels that you can be part of in order to interact with others using the same channel configuration. Channels are identified by name and, more importantly, by a pre-shared encryption key. Anyone with the encryption key is part of the group and can send or receive messages on that channel but a node doesn’t need the key in order to pass messages along. In this way, Meshtastic provides end-to-end secure messaging between users even of the message passes through a node that is not “part of the group.” You can create a channel and share it with a group of nodes/friends or share it with only a single other node to create a private channel. As long as there is a path between you and the target you are set. Meshtastic provides a number of additional features, almost all of the completely optional, which you can read about on the project’s documentation page at https://meshtastic.org/docs/configuration/module/.

The Meshtastic documentation provides information and links to supported hardware and all hardware is equally capable of providing the core experience. To get myself started, I opted to use two Heltec V3 modules. By getting two modules I was assured that I could test the basic functionality of Meshtastic even if there are no other nodes near me. When selecting a Meshtastic module it is important that you get the correct one for your region as the ISM band that is used is different depending on where you live. Refer to https://meshtastic.org/docs/configuration/region-by-country/ to determine what frequency module you need. How you want to use the module can also determine which module you get as modules can have different features. For example, the Heltec V3 is not as energy efficient as some others so if your plan is to create a solar powered outdoor station then a RAK WisBlock might be a better fit.

Once you have hardware you will need to flash the Meshtastic firmware to the device. The Meshtastic project has great documentation on how to do this and I recommend you follow their notes on how to do so. The documentation for flashing esp32 based hardware like the Heltec V3 can be found at https://meshtastic.org/docs/getting-started/flashing-firmware/esp32/.

After flashing the firmware you will need to perform some initial configuration. Again I recommend following the official guide on how to do this which is available at https://meshtastic.org/docs/getting-started/initial-config/. Configuring the correct settings is crucial for getting Meshtastic up and running properly and legally in your region. After the initial configuration you are immediately ready to begin communicating with other Meshtastic nodes that you have on hand or are local to you that are also using the default primary channel configuration. When starting out, you will find it is easiest to stick with the default primary channel in order to reach others with minimal fuss. You can read more about channel configuration at https://meshtastic.org/docs/configuration/radio/channels/.

Optionally, you can extend the range of your device using the internet and a tool called MQTT. This optional functionality allows your radio to leverage the internet connection of your device, or if you configure your node with a WiFi connection a direct connection, to communicate with an MQTT server. The default configuration for MQTT will use the project MQTT server and is preconfigured with the correct credentials. MQTT uses a concept known as “topics” to describe where content is posted to so that other clients can “hear” the information. By default, MQTT will use the msh/US topic which is extremely busy but is a good way to get started. You will want to configure the topic so something more local to you to lessen the noise. I will go into more detail on how to use MQTT in a future post.

For now, this is enough to get you going on Meshtastic. It can be a bit daunting and confusing at first but after some time you will get used to how it works. In future posts I will discuss channel configuration, using cli tools to configure devices and dig more deeply into using MQTT to tie areas together. In the meantime, you can find a lot of information on YouTube and I highly recommend doing a search for meshtastic there to find videos to fill in any gaps you may have.

Disclaimer: This post contains Amazon Affiliate links. If you purchase something from Amazon using a link I provided I will likely receive a commission for that sale. This helps support the site!

For some time I’ve been meaning to publicly release the custom component I’ve been using to show which if my Xbox friends are online and what they are playing. There was one issue I had with my component that kept me from releasing it however, it requires access to an API endpoint I would prefer to not offer to an unknown number of people and I’m not interested in scaling it up to sell.

What I decided to do instead is allow the service to be self hosted in the form of some add-ons for hass.io that the custom component can then talk to. The service is broken out into three parts. A part to manage an auth token, a part to basically proxy Xbox Live API requests and a part that glues to two together so the auth token can be shared. The original design was meant to scale well and easily and this is basically just a 1:1 port of the setup. 

The add-ons can be installed by adding this custom add-on URL to your add-on store on your hass.io instance – https://github.com/hassio-xbox/add-ons. Add the URL, refresh and then install the services in the following order

  • Redis Server
  • Xbox Live Credentials Manager (and then configure your username/password)
  • Xbox Live API Service

Once all services are up and running you can configure the component which is installed automatically. The component needs to be given the IP address of your hass.io instance as well as a list of gamertags to keep track of. The format looks like this:

- platform: xru
ip: <hass.io instance ip>
- RealAngryMonkey
- Qwik

Once configured restart Home Assistant and you’ll see the status of your friends in the form of individual sensors for each. You can then group them to create a nice panel in your groups.yml file:

name: Xbox Live Friends
view: no
- sensor.realangrymonkey
- sensor.qwik

The end result looks like this:

Recently I found myself needing to perform a downgrade of Home Assistant in Hassio which wasn’t immediately obvious. If you need to downgrade your Hassio install enable the ssh add-on (or the web based one) and enter the following command on the console:

curl -d '{"version": "0.57.1"}' http://hassio/homeassistant/update

The command will hang for bit while Hassio downloads the different versions and prepares to install it.


In a previous post I mentioned I had recently picked up a HiLetgo ESP8266 NodeMCU module along with a DHT22 temperature and humidity sensor. In this post, I’ll describe how I combined the board, the sensor, hass.io and MQTT using the mosquito add-on for hass.io to create a temperature sensor for my home office.

I’m not going to go into detail about how to setup hass.io on a Raspberry PI, their site does an excellent job of describing how to get it installed, but I do highly recommend using that installation method if you’re on the fence. Raspberry PIs are inexpensive and Home Assistant runs quite well on the platform.

Instead, I’m going to concentrate on what it takes to get this working while going over what you need to enable in hass.io to support a small, WiFi enabled board sending temperature and humidity readings.

Continue reading

What self respecting geek wouldn’t like home automation products? X10, yea that company with the ridiculous pop-up ads all over the web about the “spy” cameras they sell, actually makes some neat stuff that is inexpensive (although some of it’s cheap too). These products allow you to, among other things, remotely control lights and appliances using X10 enabled modules. X10 is actually the name of a company but also the name of a communication protocol used by these devices to well…communicate. Today, there are a number of products that either compete or compliment the X10 products that have existed for years. I’ll get to those later.

I got my first taste of X10 products when I lived at home. We lived in a smaller house and there weren’t quite enough bedrooms for everyone. I decided it was time for me to create my own room and that’s what I did. I converted our old toy room into my bedroom. The problem, there was no way for me to control the lights in the downstairs area once I was down there. After a bit of research, I found a couple of products at a local Radio Shack that would allow me to remotely control the basement lights from my new room. The products allowed me not only to remote turn off and on the lights, but also dim them, something we couldn’t do before.

Continue reading