Long-range Sub-GHz wireless mesh networks have become essential for modern communication, particularly in remote areas where traditional infrastructure is impractical or impossible. By utilising lower frequencies (typically below 1 GHz), Sub-GHz networks can achieve remarkable range, low power consumption, and the ability to penetrate obstacles such as buildings and dense forests.

These characteristics make Sub-GHz mesh networks ideal for applications in IoT, outdoor communication, emergency response, and industrial networks. But with numerous technologies now available, choosing the right one for your needs can be challenging.

In the first two parts of this series, we explored why community telecoms matter and how resilient mesh networks can save lives during emergencies. Now comes the question I’m asked most often: “That sounds great, but how do I actually build one?”

This is the knowledge I wish I’d had when I started.

If my journey from those early Austrian tele-working centres to deploying mesh networks across remote Australian properties has taught me anything: the hardest part isn’t the technology—it’s overcoming the psychological barrier between “consumer” and “creator.” We’ve been conditioned to believe telecommunications infrastructure is something large corporations build, not something communities can create themselves.

In an emergency, information is as vital as water. The official advice is clear: “leave early.” But how do you act on that advice when the power is out, the mobile network is congested to the point of failure, and the emergency broadcaster’s tower has been consumed by the very fire you’re trying to flee?

This isn’t a hypothetical. As Fiannuala Morgan chillingly documented in her article, “No power, no phone, no radio: why comms dropped out during the Central Victorian fires{target="_blank”}", this is the reality for communities across Australia. The wholesale replacement of resilient copper landlines with power-dependent NBN connections, coupled with the shutdown of the 3G network, has created a communications infrastructure that is dangerously brittle in the face of climate-fuelled disasters.

We live in an era where a reliable connection to the digital world is not a luxury, but a lifeline. It’s how we work, learn, access essential services, and connect with our communities. Yet for many in regional and rural Australia, this lifeline is frayed, unreliable, or simply non-existent. We’ve been told to accept a digital landscape dominated by a handful of corporate giants, a landscape where postcodes dictate the quality of our connection to the modern world. But what if there’s another way?

In the first two posts of this series, we explored the risks of corporate-controlled IoT—from devices being turned into ‘bricks’ to the sustainability challenges facing ‘open-source alternatives’. But what if the bigger danger isn’t just that your smart device will stop working, but that it’s working all too well—just not for you? This post dives into the pervasive, built-in surveillance that has become a standard feature in so-called ‘smart’ devices.

In the last post, I explored the graveyard of ‘bricked’ devices—hardware rendered useless by corporate decisions. It’s a stark reminder that when you don’t control the software, you don’t truly own the hardware. The clear alternative is Open Source, but that path has its own critical vulnerability: sustainability.

But this is where the journey gets complicated. We flee to platforms like Home Assistant and embrace open-hardware projects, expecting a haven of stability and privacy. And while we find it, we often forget a crucial truth: “free and open source” does not mean free to create.

The promise of the “smart home” was a future of convenience, efficiency, and seamless automation. We bought into the vision of light bulbs that dim with a voice command, thermostats that learn our habits, and security systems we can monitor from halfway across the world. But for a growing number of consumers, that dream is turning into a nightmare of expensive, useless hardware. The culprit? A business model built on centralised control and proprietary systems.

As a new year begins, it’s a natural time for reflection. Looking back at the history of this blog, it started during my years working in online education. I was fortunate to be surrounded by inspiring colleagues who lived by the principles of “working out loud” and developing ideas “out in the open”. It was a vibrant, collaborative time.

A lot of water has flowed down the rivers Murray and Drau since then, and I’ll be the first to admit that my practice of sharing my work has become sporadic at best. I’m extremely keen to change that.

I’ve been living and working in Australia for a good while now, having moved from Europe with a healthy dose of open-source enthusiasm. Over the years, however, I can’t help but notice a stark difference between the two continents: the politically engaged, almost rebellious, hacker culture that is so vibrant in Europe seems to be missing its pulse here Down Under.

This has really hit home for me while watching the live streams from the 39th annual Chaos Computer Club Congress (39C3) in Hamburg. It’s one of Europe’s largest gatherings of hackers, activists, and creatives who don’t just write code, but actively question and shape the world it runs on. It’s a cultural phenomenon, not just a tech conference.

One of the tasks Google Earth Pro is really useful is getting a quick idea of the viewshed from a specific location. This is particularly useful for planning solar installations or other infrastructure projects such as LoRaWAN gateway deployments.

Whilst the tool is quite powerful, it has a very limited viewshed (roughly 5km) and this is not really useful when looking at gateway deployments that in flat regions of Australia easily can reach 25km+. Also it is not at all obvious how to modify the radius of the viewshed since that has not been a feature in the GUI and it is not documented at all.

“possum cam testing” (CC BY-NC-SA 2.0) by leogaggl

One common task for my Raspberry Pi Zero with (infrared) Camera is to do still image capture in regular intervals and upload the images for storage and post-processing. A simple way to achieve this with standard software tools available in the Raspberry Pi OS repositories is to use the S3 CLI tools and a simple bash script run by a scheduled cron job.

The Siemens IoT2000 series has been a very interesting development from Siemens and it’s really encouraging to see the use of Open Source in the Automation sector definitely on the increase. And that can only be a good thing for developer productivity. Seeing a different IDE for each manufacturer of a PLC invokes some nasty memories of last century web-application development…

Unfortunately, all the documentation for these units still assumes a Windows PC. And since I have not really been using a physical Windows machine for 10+ years now, that is really slowing things down. For the last few I didn’t really have to fall back to a VM, largely due to the fact that in web-development nobody cares about OS any longer. But I have a feeling that shifting my focus to the IIoT space this VM will get a bit more useful as some of these manufacturers don’t even bother with anything but Windows and are challenged enough to keep up with Windows upgrades.