The problem
The classic greenhouse problem isn't that people don't care — it's that they can't be there all the time. Conventional management runs on timers and best guesses: set the lights for 14 hours, check humidity when you remember to, refill the humidifier when you notice it's low. None of that is wrong exactly — but it's reactive, and the gaps between checks are where problems compound.
A humidity drop during germination slows development. A temperature spike stresses seedlings. An empty humidifier reservoir left running burns out the mister. Each of these is recoverable the first time. Compounded, they're not.
The goal was a system that doesn't wait to be checked.
The system
The controller centers on a Raspberry Pi 4B running custom Python, managing a cluster of sensors and actuators through relay boards. Sensor acquisition, decision logic, and hardware triggering all live on the same platform — compact, with predictable failure modes.
What it monitors
An HDC1080 thermohygrometer delivers continuous temperature and humidity readings over I2C — precise enough to catch the gradual drifts that matter, not just the swings. A resistive liquid level sensor (Adafruit 4965) watches the humidifier reservoir. That detail matters: the pump logic triggers a refill before the mister runs dry, not after. Running an ultrasonic mister on empty damages it quickly.
How it responds
When humidity drops below 80%, the ultrasonic mister activates. A fan runs continuously to distribute moisture and temperature evenly across the space — concentrated humidity pockets near the mister are a real problem, and moving air prevents them. When either humidity or temperature exceeds the upper threshold, a custom 3D-printed vent opens gradually to discharge the excess.
The vent is one of the more considered mechanical details in the build. It's adjustable and designed to open slowly rather than snap between states — gradual actuation avoids the oscillation you get when a controller reacts faster than the environment can respond. The grow lights run on a fixed daily cycle, defaulting to 14 hours on and 10 hours off, adjustable and fully automated after that.
Software structure
The Python codebase was built for reliability first. Sensor acquisition is continuous. Control decisions evaluate on each cycle. The modules — sensing, decision logic, relay control — are separated deliberately so a problem in one area doesn't cascade into another, and each piece can be tested and modified independently. Simple rules are easier to debug than clever ones.
What building it taught us
Most of the components were hobby-grade or pulled from earlier builds. Running them at high uptime in a genuinely humid environment pushed them in ways normal use wouldn't. HDC1080 sensors drifted. Water level sensors gave inconsistent readings. Ultrasonic misters failed.
Each failure forced a response. Sensor drift led to averaging logic that smooths transient readings before they trigger an actuator. Water level inaccuracy pushed the pump trigger earlier and more conservatively — which turns out to be a safer operating mode anyway.
The system that came out of those failures handles component degradation more gracefully than one tested under ideal conditions. The parts that would have been invisible in a clean build showed up in the field. That's a real result, not a setback.
What this demonstrates
This was a one-person project, end to end — from sensor selection to enclosure to control logic. It works.
The more transferable thing is the design approach: a physical system built for real operating conditions, with software structured to be resilient rather than minimal. The architecture scales. Adding a second climate zone means adding sensors and relay channels, not rearchitecting the system. Adjusting for a different crop means changing thresholds, not rewriting logic.
The greenhouse is a contained problem that touches every discipline simultaneously: mechanical design, electronics integration, software, and the constraints of assembling all of them in a humid environment. Getting all of them right at once is harder than getting any one right alone.
A greenhouse that runs itself isn't a complicated idea. Most implementations just don't account for what happens when the hardware misbehaves.
Sunfish Labs designs physical products and systems for founders and practitioners who need something built for real-world conditions. If your problem sits at the intersection of hardware and software, that's where we work.
Talk to us about your project →