Raspberry Pi Internet of Things - part 1
Farm automation made easy as Pi
As some of you who follow my posts know, my latest labor of love involves the Farmsteading world. I wrote about the irrigation plumbing and my creek water pumping system. I didn’t really have the time to add any automation to these systems, since we were getting the Stella Porta™ farm business off the ground.
As things settled into place and winter hit, I had time to start researching what I needed to build to automate some of the day-to-day tasks.
The first step was to set design goals for the systems I installed at the farm. Reliability was high on my list. Even though this project is, in many ways, a hobby, I have better things to do than constantly fix things that should have worked the first time. Let’s do things professionally.
Here is what I came up with.
Environmental Ruggedness.
Arkansas has a wide variety of weather conditions. I have seen the temperature regularly range below 0°F and over 100°F. We also get plenty of rainfall, humidity, wind, and thunderstorms. Through trial and error, I also discovered that any equipment I use has to be resilient to electrical power surges and lightning strikes.
As an aside, here is an informative article about dealing with lightning strikes. 
Farms are also dusty and dirty. Things get banged around and covered with mud, and insects like to nest in any crevices they can find. The farm environment doesn’t play well with things like the I2C Qwiic Connect System I used in previous projects. (I’ll discuss that in detail later in the series).
The bottom line is that this is the field (literally), not the lab. Equipment gets abused by the environment and people, so it must be a little tougher.
Software Ruggedness and Stability
I am so grateful that I no longer work in the software industry, especially the Apple ecosystem. It was incredibly irritating to write a large piece of software only to find that a few months later, the programming language itself (Swift) or operating system under it (iOS) changed enough to break compatibility with existing code. Then they would make you pay thousands to go to a developer conference where they would try to gaslight you as to why this was a good thing.
This happened enough times that it drove me off the platform.
These days, I choose to create my projects on the Raspberry Pi platform, where Linux tries not to break userspace with every release. They even adopted the Debian Linux Extended Long Term Support (ELTS) concept. This means the current bookworm release running on Raspberry Pi has potential support out to 2033.
Further, I chose to write code in the more mature dialect of C++ 23 using Clang, instead of basing it on another thing with a history of changing under my feet. It’s also very easy to cross-compile with Clang, which speeds up the development process.
I am also a big fan of using as low-level an API as practical. For example, I employ the standard Linux libraries like libgpiod and the I2C/SMBus subsystem, rather than going through things like WiringPi or CircuitPython. Again, long-term support. Any third-party C++ code I use is compiled-in and won’t suffer from changes outside my control.
Expandable and Flexible
I like building frameworks that can be reused for other projects. In addition to the irrigation control, I imagined and scoped out several diverse use cases to see if the code was flexible enough to operate for the creek pump, the chicken coop, or the farm entry gates.
My tracking and scheduling code handles this with no problem; the only thing that changed across the use cases was the devices and sensors, which is why I designed in support for user extendable device plugin modules.
Later in the series, I will publish an article describing how to write device and sensor plugins, including sample code.
Open Source
Many moons before I worked on projects like Pretty Good Privacy (PGP), I was a huge advocate of releasing as much source code as possible to the public. Releasing source code not only makes your code more trustworthy, but it’s also an educational tool for others. If I created anything, it’s only by standing on the shoulders of giants. I will try to release everything I build on my GitHub site.
Cypherpunks write code — Eric Hughes.
Self-Hosted vs the Cloud
Cloud-based automation is the antithesis of the self-sufficiently I wrote about in “This Is My Dirt”. Cloud-based systems not only depend on connectivity to the Internet, but as time goes on, they depend on the continuity of the provider that hosts them. Denial of service attacks and hacking on these systems can affect your farm automation. However, what concerns me more is the termination of the product line. It happens, and it happens a lot.
On the other hand, I can understand how strong the attraction to cloud hosting is. Sometimes the company makes a great product that stands alone without the cloud connection, but the remote app makes it even better.
For example, I have two fabulous pieces of hardware. They are outstanding and trouble-free.
EcoFlow power systems
DAB EsyBox pump booster system
I like both systems. They are well built, have good mobile apps, and provide cloud-based developer APIs (REST) and programs. I was able to integrate those into my project in a snap.
However, neither publishes instructions on how to get local access, even over Bluetooth. If the companies decide to discontinue the product, there is no guarantee of continuity. This is frustrating, and I have even been looking into reverse engineering their setup protocol.
Small farm automation must run uninterrupted, even when external connectivity fails. I wonder what the vendors were thinking, short of locking in their customers.
Such hardware should have a self-hosted option, at the very least. I don’t have any issues with being able to access the systems remotely or from mobile devices. You can do this using something like the Cloudflare zero-trust tunnel.
Oh, and did I mention we have power failures, and lots of them? It helps if there is battery backup or, for that matter, if we can run entirely off-grid. I plan to dedicate an article to this topic alone.
Pi Internet of Things
I am calling this project PioT (Pi Internet of Things), and the server app is called piotserver. Here is how I imagine my Raspberry Pi Internet of Things ecosystem to work. The system will be self-hosted without an external cloud server. Mobile and desktop devices will be able to query the sensors and control the pumps and valves through a REST API.
I successfully used the REST API concept in some of my earlier projects, like the chicken coop controller, my well/cistern system, and my version of home control using the Insteon platform. (Insteon was another cloud ecosystem that failed, leaving its customers stranded.)
I even have a series of articles about how I did this in the past with the Raspberry Pi.
The code was reasonable enough to reuse much of it for my current application. But rather than write a native iOS mobile app like I did before, I’ll use a web application (JavaScript) to connect to the REST API.
Alternatives and tradeoffs.
You might ask, why roll your own when stuff is out there now? It’s a worthy question.
My first attempt at Irrigation was based on the OpenSprinkler platform. I am really impressed Ray Wang’s project. He’s done some fantastic work and has a great, affordable, and fun-to-work-with platform for running garden sprinklers and irrigation systems. I learned much about his design choices by digging through his blog articles. I highly recommend them to anyone considering building stuff on the Arduino and Raspberry Pi platforms. He posted his code and hardware design on GitHub.
A variant called OpenSprinkler Pi (OSPi) plugs right into the Raspberry Pi GPIO connector. It is compatible with the same OpenSprinkler software. I picked up one of these and plan to build a plugin for my project that will allow you to run with this hardware.
The other popular alternative is the Home Assistant platform. I happen to use this running on a Raspberry Pi to talk to some of my lights and HVAC. While it’s possible to do a lot of what I want with Home Assistant, it is way too much overkill, and although it has a somewhat extensive release schedule, it does way more than what I need. They try to please too many people.
OpenSprinkler would probably do for most people, but I wanted to do a few more things. In particular, I am very interested in tracking the temperature and humidity in the garden, greenhouse, and the ground temperature for our farm.
So I built on my past platforms and wrote my own system. During the design process, I even considered an alternative to the REST/JSON protocols I used in the past. I researched and hacked a few popular IoT protocols like MQTT and Matter. They are not bad systems. But they are more appropriate for devices like lightbulbs and switches. My system has the concept of scheduling and tracking changes in the environment, even when disconnected from any user interface.
Besides, I could always write bridge code to my REST API for these systems.
More to come
This article is the first in a series about how I am using a Raspberry Pi to manage our farm systems. Stay tuned for more articles about the PioT project. I have already queued up the following articles:
Reading from I²C sensors.
Getting the data and controlling the devices from the REST API
Using software devices to build on the hardware.
Scheduling and managing events
Securing your system from hacking
Further down the road
How I packaged the Raspberry Pi for farm use.
The power supply
How to add your own devices
Building a web-based user interface.
Stay Frosty, my friends!
