Garden Irrigation Evolution
“Stuff’s getting better. Stuff’s getting better every day.”
If you are new to this series, let me catch you up. We purchased some property and moved out to Arkansas a few years ago with a plan to, among other things, establish a market garden.
The property had previously been used for cattle, so part of the job was turning pasture into vegetable beds. We had plenty of water from a nearby well, but we still had to get it to the crops. So we dug trenches, laid pipe, hooked up valves and filters, and ran drip lines.
A farm has a lot of jobs, and I did not want irrigation to depend on someone remembering to open and close valves at the right time every day. So I needed a field-expedient way to automate the watering while the rest of the farm was still being built.
My first irrigation controller was based on OpenSprinkler. I still think Ray Wang built a great platform: affordable, open, well documented, and fun to work with. It got us watering, and I learned a lot from studying his design choices.
OpenSprinkler does the job for most people, and I am not knocking it. But I wanted more than valve control. I wanted to track temperature and humidity in the garden and greenhouse, monitor ground temperature, and start tying irrigation into the rest of the farm automation work. That is where the controller started evolving.
The next step was moving the brains onto a Raspberry Pi. I wanted the system self-hosted and local, not dependent on somebody else’s cloud server to water crops. So I created pIoTServer: a Raspberry Pi-based farm automation system that could expose sensors, valves, pumps, and other devices through a REST API.
The first hardware version was still very much a prototype: a Raspberry Pi, a Waveshare 8-Ch Relay Expansion Board, AC relays, and a fair amount of wiring. It was not pretty, but it let us control devices, read sensors, and start collecting environmental data.
One of the things I really liked about the Waveshare board was that it treated the Raspberry Pi as the daughter board, not the other way around. I adopted that approach for my later designs because it gives the main board room for power, protection, relays, field wiring, and whatever other interfaces the controller needs.
Once the initial Raspberry Pi version was working, power became the next issue. Rural power does rural power things, and I wanted the controller to survive outages and run from a backup battery. I also wanted better control of the irrigation valves than just feeding them straight DC.
That led to the first PWM prototype. It used pulse-width modulation to open the valves and then hold them with less power. It worked as a proof of concept, but it was limited to eight circuits, and I still needed a better answer for automatic shutdown.
The next version had to solve two other problems: managing power and protecting the controller from the realities of farm wiring.
That led to another custom board. This one had power management built in, including battery backup and controlled shutdown, instead of treating power as something bolted on later. I also moved more of the field-facing hardware onto my own pIoTServer board layout: isolated I2C, 1-Wire support, and isolated DC/DC power. The idea was to give the Raspberry Pi some separation from the long wires, valve coils, noisy equipment, and other nonsense hanging off the controller.
The valve drivers moved onto stackable 8-circuit PWM cards, so the controller was no longer locked into one fixed number of outputs. That design served us pretty well for about a year.
But the garden kept expanding, and the valves kept getting farther from the controller. At some point, it became painfully obvious that this needed to be an RS-485 network. I am not sure how I missed that at the beginning of the project, but there it was.
The cleaner answer was a field bus: one RS-485 run, with small ValveNode boards sitting closer to the valves.
That led to ValveMaster, a plug-in card for the pIoTServer controller with an AVR handling the RS-485 side and talking to the remote valve boards. The Raspberry Pi still runs pIoTServer and the farm logic, but valve control moves into a distributed network instead of everything home-running back to one box.
The power-management work was its own rabbit hole. I started with discrete components controlling the power relay, but that only gets you so far. At some point the board needed a real brain for power control, so I moved that job to an ATmega8-16.
That let the board watch the power state, control the relay, shut the Raspberry Pi down cleanly, and remove power after shutdown. It could also wake the system back up when AC returned, when someone pressed the button, or on a timer so the controller could conserve battery power, wake periodically, and do whatever work was needed.
What This Evolution Adds
This evolution is built around the new ValveMaster prototype and the move toward RS-485 ValveNode boards, but the hardware is only part of it. A lot of the work went into pIoTServer itself: new device drivers, better reporting, notifications, tracking, rules, test tools, REST cleanup, and a redesigned farm-web dashboard.
Hardware
ValveMaster / RS-485 ValveNode control
A new plug-in ValveMaster card lets the pIoTServer controller talk to remote ValveNode boards over RS-485, moving valve control closer to the valves instead of home-running every valve wire back to one box.Power management
Controlled shutdown and wake behavior.DS2482 / 1-Wire
Moved away from FUSE/OWFS toward native driver support.
Software
New device drivers and runtime support
Added the pIoTServer runtime/driver work for ValveMaster and power management.Incident reporting and notifications
Added incident reporting, and Pushover support so the system can report problems and send phone alerts when something needs attention.
Rules and ad-hoc sequences
Added rules and temporary sequences. This lets the system run one-off irrigation jobs, manual tests, and simple conditional logic without having to create a permanent schedule every time.Tracking, duration, and summary API
Added tracking so the system can record what actually happened, not just what the current state says. This includes how long things ran, when they ran, and summary data the dashboard can use without pulling the whole history every time.piottool
Consolidated the hardware debugging and module testing tools into one utility.
Raspberry Pi Wi-Fi hardening
As shipped, Raspberry Pis have been known to drop off Wi-Fi and do not always handle network recovery well on their own. We tightened up the Wi-Fi setup and added recovery behavior so the controller has a better chance of coming back without manual intervention.
REST cleanup for better web UI support
Cleaned up bugs and refactored parts of the REST API so the new farm-web interface could get cleaner, more consistent data.
More good stuff to come
I am in the process of deploying this version out to the farm now. As usual, every improvement seems to create three more things worth writing about, so I am going to break some of the details into separate articles instead of turning this update into a book.
Web dashboard / UI system
How the farm-web dashboard was redesigned around actual field use, and how the pIoTServer web interface is structured going forward.
Pushover notifications
I needed a way to find out when something broke without staring at logs or keeping the dashboard open all day. Pushover is a simple cross-platform push-notification service, and pIoTServer can use it to send alerts to my phone when something needs attention.
Cloudflare Access
I also needed remote access to the farm dashboard without exposing the farm controller directly to the public internet. Cloudflare gives me a controlled front door, so I can reach the web interface remotely while keeping the raw controller on the private side.
DS2482 / DS18B20 driver without OWFS
As part of the I2C debugging, I needed more direct control over the 1-Wire side of the system. That meant moving DS2482 / DS18B20 temperature sensing away from OWFS/FUSE and into native pIoTServer driver support.
There is always more work to do, and this thing is not done yet. But we are getting there. “Stuff’s getting better every day.” And man, what a long, strange trip it’s been.
If you care about how things are made and why they’re built the way they are, you’ll probably like the rest of what I write about. It is not always electronics. Believe it or not, I have been known to jump from baking to perfume to motorcycles without much warning.
Hitting like and sharing helps real people find the work. The algorithm can go pound sand.