This is not a build log. The greenhouse doesn’t exist yet.
It’s the document I wrote before buying anything, because the most expensive mistakes in a physical project are made in the first hour — and because I’ve come to think that designing in public, before it works, is more useful than the polished write-up afterward.
I’ll publish the build when there’s a build. This is the thinking.
The Constraint That Defines Everything
I live near Québec City. The growing season is roughly mid-May to late September, and it’s not gentle at either end. A late frost in May and an early one in September are both normal.
That short season is the whole reason for a greenhouse. But a greenhouse in this climate has a failure mode a garden doesn’t: it cooks. An unattended greenhouse on a sunny 28°C afternoon can pass 45°C inside within an hour or two. Plants that survive a cold night outside will not survive that.
And here is the part that decides the architecture: my family goes camping. We leave for three days at a time, in exactly the weather that’s most dangerous.
So the system isn’t a convenience. A greenhouse here without automation is a greenhouse that dies the first hot weekend you’re away. That single sentence rules out every design where a human is part of the loop.
What I’m Optimizing For, in Order
Before choosing a single component, I want the priorities written down, because every hardware decision is a trade between them and I’d rather make those trades on purpose.
- Don’t kill the plants. Everything else is secondary. A system that’s offline is acceptable; a system that’s confidently wrong is not.
- Survive three days unattended, including a power blip and a Wi-Fi outage.
- Tell me the truth remotely — I want to know it’s fine, not assume it.
- Teach my son where food comes from. He’s four. If the system is invisible, it teaches nothing.
- Be interesting to build. This is real and I’m not going to pretend otherwise.
Note the ordering conflict between 1 and 4. A fully automated greenhouse is a black box to a child. A greenhouse where he opens the vent himself is a greenhouse that cooks when he’s not there. I don’t have a resolution yet — my current thinking is that the automation handles the dangerous window and he owns the visible, safe rituals: watering by hand when we’re home, harvesting, reading the temperature off a display.
The Same Pattern, Different Material
I’ve written before about giving a house a rhythm — a state machine where the home moves through Morning, Day, Evening, Unwind, Night, and each room can diverge and rejoin.
A greenhouse is the same shape.
States aren’t times of day, they’re growth phases: germination, vegetative, flowering. Each wants a different target temperature, a different watering cadence, a different tolerance for humidity.
Sensors replace the clock: soil moisture, air temperature, humidity, light.
Responses replace the lights: a vent opens, a fan runs, a pump pulses.
Presets are still presets — a day cycle, a night cycle, and a heat-wave override that ignores the phase entirely and just tries to keep things alive.
I find this genuinely encouraging rather than merely tidy. The reason I can design this at all without ever having built one is that the architecture transfers even when nothing else does. The material is different — an ESP32 soldered to a relay board instead of a Zigbee switch — and the pattern is the same.
The Decisions I Haven’t Made
I’m listing these openly because a design document that pretends to be finished isn’t a design document.
Which sensors, and how many. Soil moisture sensors are notoriously unreliable — the cheap resistive ones corrode within a season. Capacitive ones last longer. I don’t yet know whether one sensor per bed is enough or whether I need one per plant type.
Where the intelligence lives. ESPHome running the safety logic on the ESP32 means the vent still opens when Home Assistant is down. That’s clearly right for rule #1 and clearly more work. The tempting alternative — all logic in Home Assistant — makes the microcontroller a dumb relay and makes my Wi-Fi a single point of failure for whether the plants live.
I’m fairly convinced the safety-critical loop has to be local and the pleasant parts can be remote, but I haven’t built it, so I’m holding that loosely.
Power. Mains with a battery fallback, or solar? Solar is more interesting and more likely to fail in February.
The enclosure. This part I’m confident about: 3D-printed, designed in Onshape, and the STLs will be published. Humidity plus electronics is a solved problem and I intend to solve it the boring way — gasket, cable glands, silica.
What Would Make This a Failure
Worth writing down now, while I still have no ego invested.
If the system is more work than the plants it saves, it failed. If it needs me to check a dashboard, it failed at rule #2. If it’s so automated that my son learns nothing, it failed at rule #4 — quieter, but a real failure.
And if I spend the whole season building it and plant nothing, it failed completely and I’ll say so here.
Why Publish This Now
Two reasons.
The first is that I’ve noticed the write-ups I learn most from are the ones written during, not after. The finished article is a story with the dead ends removed, and the dead ends are the useful part.
The second is more honest: publishing the design makes it harder to quietly abandon.
I’ll follow this with the build. If the design turns out to be wrong — and parts of it will be — that’s the more interesting article anyway.
Francis Fontaine is a developer and photographer based in Québec City. He builds modular systems for the web (stnd.build) and for the physical world, and believes the best technology is the kind that disappears into the background of daily life.