With a Meshtastic antenna the advice is to put it as high as you can with as few obstructions as you can manage. For my home setup that meant a few physical iterations as it went from inside my office, to inside the attic, to outside the attic below the roofline, and finally outside the attic and higher than the roofline.

As an engineer I want baseline quality data before I make a change, so I know if my change helped, did nothing, or actually made things worse. I don’t have the knowledge or the tools to really measure the quality of my antenna setups, and I want real-world connectivity metrics more than I want a gain measurement.

I mentioned previously that I was playing around with Meshtastic stuff, but here’s more detail on the software side of those projects. I’ll show the hardware side and what Meshtastic does in a later post, but here I talk about three ways I’m getting information from my Meshtastic node into Home Assistant:

1. Using the MQTT pub/sub protocol
2. Polling a telemetry REST API on the node
3. Using the Meshtastic python API to poll the node

All of these offer a different subset of the same info and none of them offer everything. Years of operating long lived systems has me really reluctant to modify more than I have to to get what I want – every customization is a maintenance task when you upgrade. For all of these I’ve avoided integrations that aren’t built-in and Add-Ons/Apps that aren’t bog standard.

Back in October I talked about my growing, local Home Assistant setup, including some of my favorite custom automations. Three months on I’m still having fun with it. Recent automations include:

• Turning off the whole home’s water supply if a flood sensor triggers
• Turning on the north kitchen undercabinet lights when the south undercabinet lights are turned on
• Automatically turning off the christmas tree at 1am
• Polling a meshtastic node and alerting if it’s not available
• Relaying meshtastic (LoRa) messages to my phone if I’m not home

I’m particularly happy with how that undercabinet lighting synchronization worked out. We have a galley kitchen and wall-switched undercabinet lights on both sides. We always use the ones on the south side with a conveniently located switch and seldom use the ones on the north side with the awkwardly placed switch. Now when we turn on one, the other turns on. That could have been done when it was wired 20 years ago, but now one Sonoff switch module in each switch, and it’s done over radio in a way no one has to think about.

An acquaintance asked me about entering tech in today’s job market with a SRE, operations, or “devops” type role, and here’s the best response I could come up with:

The tricky bit about SRE and devops is that in any company we’re on the cost-side of the books, not the revenue side. Companies that are growing fast learn quickly that they need us to keep services available and to keep developer velocity high. Companies that are shrinking start by pulling back from cost-side groups like SRE, operations, and even security while they push resources toward feature development and sales. That’s short term thinking, and they end up with quality, reliability, and security tech-debt that they eventually need to pay down. If they survive they’ll come to understand that accutely, but it still might have been the right move at the time.

I’ve been futzing with home automation projects for longer than I’ve had a home, but it sure has gotten easier lately. Twenty years ago I was cobbling together individual hardware sensor and actuator pairs for automations with no central coordinating system and no logging. Ten years ago I was buying third party automation sets where everything was controlled by a cloud service and everything worked well until that company lost interest in the product they’d sold you and then everything stopped working suddenly. Now there are great local control options, with open sensors, open acutators, open controller software, and great history keeping. I’m buying parts from many companies, but the continued working of my setup doesn’t require any of them being around next year.

I’ve been blogging, unreliably, at ry4an.org since 2003, and just changed the software powering it for the third time. Up until today I was using blohg. It worked great, but hadn’t had a release in seven year and still required python 2.7, which is annoying to install cleanly these days.

A quick look around showed that the static site generator space has exploded since last I checked. Hugo is mature and doesn’t require a javascript runtime, which was good enough for me.