Measure with our own hardware, act with simple pieces, talk to the rest

An operation produces data all day: temperature, humidity, CO₂, product or substrate moisture, the state of every piece of equipment. The question is not whether that data exists, but whether it can be trusted enough to let a rule act on its own at three in the morning. A spreadsheet and a smart plug do not get there. Neither does a thermometer that rounds.

Growcast was built on three layers, and each one is worth what the one below it is worth. Our own hardware that measures well. Simple rules that act on what was measured, inside the same device. And an abstraction layer on top, which you program or talk to, and which is reliable precisely because the two below it are boring and deterministic.

1. 01
   The data

   Our own sensors and each industry’s reference probes, read by a device that records on its own. No smoothing, no manual entry.

2. 02
   The action

   Rules and alarms that run on the device, each with its safe state. They keep working without internet.

3. 03
   The abstraction

   Templates, an editor, a natural-language agent, a simulator and an MCP server for whichever assistant you prefer.

Layer 1: measure well, or nothing else matters

Every reading is the last real value, unsmoothed. The temperature is 28, not “around 28”. That is the starting point, and it only holds if the hardware is your own and you know exactly what it measures, with which sensor and with what error.

A Growcast device — Growcast, Growcast + or Growcast Industria — reads sensor modules and commands control modules. A sensor module usually reports several variables at once — temperature, humidity, CO₂, pressure, substrate moisture, pH and electrical conductivity, depending on the module; the control modules expose outputs: ventilation, pumps, extraction, climate control, whatever you connect. Each module is designed and built with the sensing element chosen for its precision and its stability over time, not for its cost. A sensor that drifts half a degree per season turns every threshold into a guess.

And where an industry already has a reference sensor, we do not reinvent it: we integrate it. The clearest case is precision growing, where irrigation is decided by what happens in the substrate. For that Growcast reads the TEROS 12 probe by METER Group, which measures volumetric water content, electrical conductivity and temperature in the same body: the probe that laboratories and that industry have already tested, and the one everything else is compared against. When a rule decides to irrigate because the substrate dropped below 45 %, that 45 % comes from an instrument the industry already trusts. The same logic holds for any sector: if the reference instrument exists, the platform reads it as one more variable.

• Precision and stability of the sensing element before cost: the rule that runs at three in the morning is worth what the reading is worth.
• Reference probes where they exist, integrated like any other variable.
• A module reports each of its variables with its unit, range and type. A new module is seen, charted, alarmed and automated the same day it is connected.

Everything that goes in or out of the device is represented the same way: as a variable with a unit, a range and a type, analogue or digital. That single abstraction is what lets a probe and a pump be handled with the same tools, without a custom screen.

Recording is automatic. The last 24 hours are kept at one reading per minute; older history is stored as 15-minute averages. There is no manual entry and no “I think it was at 65 yesterday”.

Two infrastructure details. Each device has its own certificate and a policy that limits which channels it can publish to: one organisation’s device cannot see or write another’s, and that is enforced at the transport layer, not only in the application. And every digital output can carry an operating characteristic — nominal power, flow rate, dose — with which the system approximates consumption without a meter: time on multiplied by the characteristic gives kWh or litres.

Layer 2: rules that run on the device

Acting is communicating, not pressing a button. When you give an order from the app you are not touching the output: you are talking to the device. The order travels, the device executes it and only then confirms it. In Activity you see every action with its state, and you know whether it really arrived.

Rules follow the same logic, with one difference: they live in the hardware. An automation is built in the cloud, compiled to a compact format and sent to the device, which evaluates it in its own control loop. If the internet drops, the rule keeps running. When the connection returns, states and events are synchronised. The cloud is for sending new rules and showing what happens, not for deciding every second.

Alarms work the same way: they are evaluated on the device, fire an event when a variable leaves its threshold or range, and that event arrives by push, Telegram or email. It sounds once, clearly, and stays pending until someone acknowledges it. The normal state is silence.

Building a rule does not mean starting from scratch. The known cases are already solved as templates: you choose the output, fill in a form and save. The catalogue has nine:

• By variable: turns an output on according to the value of another variable, above or below a reference.
• Scheduled: turns on and off inside a time range.
• Multiple intervals: up to 8 times a day, each with its own duration, on the days you choose.
• Cyclic timer: so long on and so long off, repeated through the day.
• Multi-range: the same variable with a different reference by time of day, up to 6 ranges.
• Pulses: short on and off bursts, repeated.
• Super cycle: on and off cycles longer than 24 hours.
• Irrigation: pulses in two phases, from a set time or together with the light.
• Irrigation with sensor: pulses guided by substrate moisture.

This is what one looks like, the cyclic timer: how long on and how long off, from what time and how many times a day, on which days, and whether a condition on a variable must also be met.

Rules that depend on a sensor also declare a safe state: what the output settles to if that sensor stops reporting. It is the most important decision in a rule, because it is the one that runs exactly when something has failed.

Manual control coexists with the rules: if you command an output by hand, the automation takes control again the next time its condition is met. To block it, you pause it from its card.

Layer 3: the layer you program or talk to

Everything else rests on those two layers, and that is why everything else can afford to be flexible.

Templates are not closed boxes: what each one builds can be opened later in the advanced editor. And when the case fits none of them, that is where a custom rule is written, by hand or by describing it in words to the Agent, which builds it. Before it goes to the device, the Simulator tests it against invented curves. The note on advanced automations covers it in detail.

And there is one more layer outside. Growcast exposes an MCP server, the standard with which an application opens its data and its actions to an AI. You connect Claude, ChatGPT or Gemini and work by talking to it: it reads environments, variables with their current value and history, lots, cycles, tasks and the user manual; it writes tasks, lots, alarms and automations. It works with its own account and its own role, so in Activity you can tell what the assistant did from what each person did. Actions on hardware are flagged so it asks for confirmation, and they require a connected device.

With enough time, that layer lets you run the process from a conversation. Without time, it lets you ask for “the pump for 10 minutes at 8” and review the rule it built.

What it means for controlling a process

A short example. At 03:10 the humidity of an environment drops below the defined band. The humidifier’s automation sees it on the device and acts within seconds, without waiting for the cloud. The alarm fires a single event and reaches the phone of whoever is on call. In the morning, the panel shows the night’s dynamics with the exact moment it left the band and the moment it came back. And if you ask the assistant what happened, it reads the same history and tells you.

Nothing in that chain depends on someone having been awake. It depends on the data being real, on the rule running where the sensor is, and on the layer above having something reliable to read.

The next two notes go into detail on the tools most used on top of these layers: the advanced automation builder, with crop steering as a complete example, and the panels, with three different perspectives on the same operation.

Continue with automations→