Anyone else get annoyed that “smart” usually means “phone home to somebody else’s servers”?  I also don’t need a platform halfway around the world to tell me if a gate is open.

This didn’t start as a grand plan. It started because the off-the-shelf stuff wouldn’t cover the sensors, I needed my property.

First try was Zigbee. Inside the house those window/door sensors are fine. Out on the property? Range made them useless (yes, I added extenders), flaky links, and there were several spots that had zero signal.

So, I switched a bunch of things to Wi‑Fi. Longer reach, and bonus: I could ping stuff with normal network tools and see if it was still alive. That worked okay for many sensors but a couple of locations still sat outside Wi‑Fi like they were mocking me.

Then I found LoRa. Low power, long range, “up to like ten miles” depending on who you ask and how optimistic they’re feeling (and what lies between the nodes of course). The catch, according to everything I read, was that two nodes can talk peer-to-peer, but if you want *many* nodes you’re supposed to use LoRaWAN.

That sent me down the Things Network / ChirpStack rabbit hole. The Things network was right out since it was yet another cloud platform that didn’t need to know how cool I keep my office. ChirpStack was an option as it can run on your own local server or in a container, which sounds great, but the whole stack still felt like way too much complexity. Buy an expensive LoRaWAN gateway (they weren’t cheap when I looked). Wrestle the gateway onto ChirpStack. Register every sensor by its DevEUI (basically the device’s unique ID). Hang each one under a custom application. For “is my gate open” and “what’s the soil doing,” that was way too much to do for simple sensors.

So, I did the easiest thing instead. Bought a couple Raspberry Pi Picos and some RFM95 modules, fired up MicroPython and a RadioHead-style stack on the receiver and the sensor node, and added addressees to both in the code.  It worked! I then built a few sensors to monitor temperature and humidity. Watching packets show up on a serial terminal attached to the receiver was a solid dopamine hit. Also, completely useless for capturing data for home automations.

I needed those packets on the network where the automation lives.

My first bridge that actually worked was a Pico W forwarding sensor packets over WiFi to MQTT. This was a great achievement in my eyes. I wanted to keep the data off WiFi as much as possible as I thought it added one more layer of un-needed complexity. I also wanted the data straight into Node-RED, where I could sort it and decide what happens next — write it to the database, send it to MQTT for Home Assistant,  or whatever — without another radio hop onto Wi‑Fi if I can help it.

Around the same time, it clicked that all of this could be used in the real world, not just my property. A lot of businesses treat Wi‑Fi as an external / untrusted network for security reasons. So that really pushed me to create a wired Ethernet gateway. This could be very useful in a rural farming environment as well and I know the LORAWAN people were pushing that pretty hard. Probably because they wanted to collect and sell their data. Yeah, I said it.

So the bridge I run now looks like this:

RFM95 → Pico (LoRa RX) → UART @ 230400 → W5500-EVB-Pico → Ethernet → Node-RED WebSocket

The Pico uses the RFM95 to listen for LoRa packets and frames packets over serial to the Wiznet W5500. The WIZnet board opens a WebSocket to Node-RED and forwards those LoRa payloads over Ethernet. Inside Node-RED the packets can be sorted using the sending nodes address, and sent through custom flows. The gateway has built in connection recovery when Node-RED redeploys and drops the web socket. Keeping data off the public internet is important to me — but range, simplicity, and a stable path onto a trusted LAN are why I was so passionate about this project.

The same solution that covers my nerdy property would cover a field, a pump house, a tank, a gate and monitor equipment status on a farm or in factory.  Currently, my nodes are one-way: they send readings out. There’s nothing stopping receiving and acting upon sent conditions later — Node-RED sends a command, the bridge forwards it, node activates a relay, valve, contactor, alarm or whatever). I haven’t started on the control path yet. It’s on the list because there are certainly real world needs for that functionality. It wouldn’t take much to get there now, the hard part is done.

More to come on my custom sensors I have built or am building.