Built in layers, from commodity parts, so it survives the day the internet doesn't.
A monitoring system that dies when the internet dies is not a monitoring system — it's a liability with a dashboard. The architecture that matters for a growing operation is built in layers, and the layers are the whole point: each does its own job, fails on its own without taking the others down, and adds value on top of the one beneath it. You can build the bottom layers yourself from commodity hardware and open-source software and walk away with a working local system; you add the higher layers only as your operation actually needs them. This page is how that stack goes together — the open, build-it-yourself shape of a serious CEA system, not a product.
The single most important property is this: a layer failing only affects that layer and the ones above it. The cloud analytics go down? The local system keeps running. The internet drops? The greenhouse keeps running — fans, dosing, alarms, all of it local — and the data simply waits until the link comes back. That is the fail-safe principle, and it's the line between a system you'll trust a crop to and one you won't.
The four layers, bottom to top
Layer 0 — the senses. The sensors and actuators out in the room: an ESP32 with a temperature-and-humidity sensor, a pH probe, the speed controller on a fan. They generate readings and do what they're told, and they are deliberately dumb. The same cheap board reading temperature in a greenhouse would read it the same in a warehouse — the meaning comes from the layers above. That's not a weakness; it's what makes the endpoints cheap, interchangeable, and replaceable without touching anything else.
Layer 1 — the edge. A small local computer in the building — Home Assistant on a Raspberry Pi or a mini-PC is the proven open option, and the site's Home Assistant library is the hands-on guide to it. This layer runs the local automations (dose the acid, run the fan, fire the local alarm), manages the devices, and — the part that matters most — keeps doing all of it if the internet drops. When the connection returns, a store-and-forward queue syncs the buffered readings up to the cloud, in order, with nothing lost. ("Store-and-forward" simply means the edge holds onto data it couldn't send and delivers it later.) This is the layer that makes the whole system fail-safe — and for the simplest operation, one greenhouse with basic sensors, this layer alone is a complete, legitimate system. Everything above it is optional.
Layer 2 — the memory and the watch. Off-site storage and monitoring: the historian where every reading is kept, the alarm engine that evaluates thresholds and routes notifications, and the view across more than one site. The open building blocks here are an MQTT broker for the messaging, a time-series database such as InfluxDB for the history, and a dashboard layer such as Grafana for the view. Add this layer when a single local dashboard is no longer enough — when you want the record kept somewhere safe and an alarm that can reach you anywhere.
Layer 3 — the meaning. The layer that knows this is agriculture. Crop recipes, growth-stage transitions, cascade detection, the Plant's Eye View, Clean Intervention tracking, cross-cycle analytics. A temperature reading from Layer 0 becomes "air temperature at canopy height in Flower Room 3, against this setpoint, coupled to these other inputs" only up here. This is the layer that turns raw data into agricultural understanding — and it's exactly what the rest of this section describes. The lower layers move numbers around; this one makes them mean something.
MQTT — the contract that lets you swap hardware
The thing that lets you replace a sensor without rewriting your whole system is a shared language for messages. MQTT is the common one (the Communications fundamental covers it in depth): every reading, command, and alarm flows through a broker — think of it as the central post office — on a structured set of named topics. Because the message format is a fixed contract, you can pull out the sensor underneath it and slot in a different one, and nothing above has to change. That contract is what keeps an open system from becoming a tangle of one-off integrations.
The digital twin — where data acquires meaning
Underneath the meaning layer sits a registry that maps every sensor to what it actually is: this reading is "the pH probe in reservoir 3," and it carries its setpoint, its alarm thresholds, its coupling references, and the crop lot it's feeding. The registry says what the data means; the historian stores what it was; the alarm engine decides what to do about it. Populating that registry when a system is commissioned is the moment a stream of anonymous numbers becomes a set of named, meaningful agricultural measurements.
How big does yours need to be?
The layers stack, so you match the build to the operation rather than buying the top of the stack because it exists — which is just the appropriate-technology frame applied to architecture:
- A single greenhouse, or a hobby grower: Layer 0 + Layer 1. A Pi, some ESP32 sensors, a local dashboard. A complete system, and an inexpensive one.
- A commercial single site: add Layer 2 — the record kept off-site, alerts that reach you remotely.
- A multi-zone facility: the full stack, with the meaning layer running recipes per room.
- A multi-site operation: the same again, plus traceability and cross-cycle analytics across every site.
Because every layer is open and they stack cleanly, you can start at the bottom and grow upward without throwing anything away. Nothing you build at the small scale is wasted at the large one.
The architecture isn't a product — it's a shape. Build the lower layers from open parts and you have a system you understand, can repair, and own. Add layers as the operation earns them. The expensive commercial platforms are, underneath, this same stack — with someone else's name on it, and often someone else's lock on your data. Knowing the shape is what lets you choose: build it, buy it, or have it built — with your eyes open either way.