Custom logic: advanced automations and the case of crop steering

Most controllers offer two tools: a timer and a threshold trigger. That solves a light and an extractor. It does not solve “ventilate only when it is colder outside than inside, never with high humidity, and wait ten minutes before starting”, nor “irrigate up to a level and then hold it with short pulses every time it drops 10 %”. That kind of rule is not exotic: it is the daily routine of a well-run process.

Growcast’s automation builder starts from another idea. An automation is a tree of pieces that answer true or false, and the value of the root is the state of an output. If you can describe how the process should behave, the tree can express it. The timer and the trigger are two small trees, not the ceiling.

One tree, one output

The pieces come in two families, the same two the editor uses to split the add-node menu. Conditions ask something and answer true or false:

• Environmental condition: compares a variable against a value and is true while the comparison holds. The value can be fixed or can be another variable, with an optional difference.
• Time range: true inside the defined window, on the days of the week you choose.
• Average: averages between 2 and 5 analogue variables of the same device and compares that average against a reference.
• Group: joins conditions with AND (all must hold) or with OR (one is enough). From 2 to 8 per group.

Modifiers ask nothing: they take the result that reaches them and transform it before it gets to the output:

• Oscillator: while its condition is active, it pulses: so many seconds on and so many off. Minimum 5 seconds per phase.
• Delay: holds back the switch-on, and only the switch-on. When the condition stops holding, the output switches off at once. Between 5 seconds and 6 hours.
• Memory: stays active even when its condition stops holding, until the reset signal switches it off. If both arrive together, reset wins.
• Inverter: returns the opposite of its condition.

The tree is built in the cloud, compiled to a compact format and sent to the device, which evaluates it in its own control loop. That is why each piece requires a minimum firmware version. If the device is behind, the platform rejects the rule on save and says which piece cannot run.

Example 1: an extractor with hysteresis

You want the extractor to start when the temperature passes 28 °C and not to stop until it drops below 25 °C. A threshold trigger cannot do that: with a single value, the output chatters around 28.

There is no “hysteresis” node. There is a memory, and hysteresis is what a memory does when its set and its reset are two different comparisons on the same variable:

Between 25 and 28 the memory keeps the last thing it decided. If it was on, it stays on; if it was off, it stays off. And if for some reason both signals coincide, reset wins: when in doubt, the extractor switches off. That priority is not an implementation detail, it is what makes the piece honest. You know exactly what happens in the rare case, because it is written down.

Example 2: dehumidify at night, and only while the pump is not running

Now a rule with three conditions that cross. Dehumidify only between 22:00 and 06:00, only if relative humidity is above 65 %, and never while the pump is on, because the humidity spike a wash or an irrigation leaves is expected and not worth chasing.

Three things to read there. First, the condition on the pump is a comparison against another output, not against a sensor: a digital output is also a variable, and its state can be used as the input of another rule. Second, the inverter turns “pump on” into “pump off” without needing a special node. Third, the 120-second delay means opening a door for a moment does not trigger the unit: humidity has to hold above the threshold for two minutes. And since the delay only holds back the switch-on, as soon as humidity drops the dehumidifier switches off without waiting.

One detail the platform resolves on its own: a range that crosses midnight is not built like one that does not. From 06:00 to 14:00 both ends must hold at once; from 22:00 to 06:00 one is enough. You write the from and the to, and the correct tree is generated for you.

Example 3: comparing against another variable

An environmental condition can be compared against a fixed value or against another variable, with an optional difference. “The outside temperature must be at least two degrees below the inside” is a single condition, and it holds on its own even as the weather changes. If three probes measure the inside, the average joins them and compares the mean against the reference. Relative rules like this are what separate a controller from a system that understands the environment sits inside a climate that also changes.

Protections

A tree that can express anything can also express a mistake. Protections surround the tree in four layers, all of them real.

• Safe state. Each environmental condition defines what it returns when the variable is unavailable, for instance if the sensor stopped reporting. It is the most important decision in the tree, because it runs exactly when something has gone wrong. A pump that depends on a level sensor should fail off. An emergency extractor, probably on.
• Output protection. Aside from the logic, every automation can carry a protection of between 5 and 3599 seconds that stops the output changing state more often than that. It is the insurance for a relay or a compressor that should not switch every ten seconds even if the tree asks for it.
• The device’s limits. The logic runs on the device, so it has to fit in its memory. A group takes between 2 and 8 conditions, the tree goes up to 16 levels of nesting, and the total weight of the tree is computed against the real capacity of the firmware before sending it. If you go over, the platform says so on save and you have to simplify. A tree that does not fit never reaches the device half-way.
• Analysis and simulation. Before deploying, the platform analyses the tree for structures that are technically valid but almost always a mistake: two branches of an OR group that overlap and compete for the same output, a branch that can never be true, a modifier whose effect is masked by a sibling. And the Simulator runs the tree against hand-drawn curves, with invented states for the rest of the variables, and shows the output second by second. The Simulator’s evaluator is the same one that reasons about the tree in the cloud, so it answers the same question the hardware will answer.

And three habits the manual recommends when building the tree: put critical overrides at the top level, so they prevail over timed cycles; make each oscillator’s windows mutually exclusive, to avoid overlaps that produce erratic pulses; and, when combining different behaviours, isolate each branch with mutually exclusive conditions.

Crop steering, read as a tree

The sensor-guided irrigation template — crop steering, a common case in precision growing — is the best example that the pieces compose, and that the platform integrates what each industry already uses: here, a reference substrate probe commanding a pump. It is a template, so you set it up with a form. But what it generates is an ordinary tree, and you can open it in the advanced editor to see the whole thing. Crop steering is described in four phases:

1. P0
   Phase 0

   A period with the lights on where the substrate dries naturally; the plants are awake and transpiring.

2. P1
   Phase 1

   Incremental irrigation with small shots that gradually raise the moisture until it reaches the target.

3. P2
   Phase 2

   Starts when the moisture crosses the desired threshold; the system irrigates at short intervals to hold the target moisture.

4. P3
   Phase 3

   The substrate is left to dry before the night to promote root growth.

The form asks for: the substrate moisture variable (for instance the volumetric water content of a TEROS 12), the target moisture, how it activates (with the light, with an optional delay for phase 0, or by schedule), the on and off duration of the phase 1 pulses, and for phase 2 the pulses plus a dryback percentage. A concrete example: target 50 %, phase 1 with 2-minute pulses every 10, phase 2 with 30-second pulses every 30 minutes and a 10 % dryback.

This is what the template generates with those values, activated by the light:

The “reached today” memory switches on the first time the substrate crosses the target and does not switch off until the lights go off. It is the day’s clock: it remembers whether phase 1 has already done its job.

The phase 1 branch pulses while the light is on, the substrate is below the target and that memory is off, that is, while it has not reached it today. As soon as the substrate touches 50 %, the memory switches on, the inverter negates it, and phase 1 is inhibited for the rest of the day. When the lights go off the memory resets and phase 1 re-arms for tomorrow. A phase that runs once a day, without a counter or a date: just a memory with the right reset.

The phase 2 branch uses two memories. The first is the same “reached today”, this time not inverted: phase 2 cannot start before phase 1 has finished. The second, “there was dryback”, is a hysteresis band identical to the extractor’s in the first example: it arms when the substrate drops below the floor (target minus the 10 % dryback, 45 %) and disarms when it goes back above the target. Between 45 and 50 it keeps the last thing it decided. So phase 2 only irrigates after a real dry-down, and stops irrigating as soon as it recovers the target.

And phase 3 is not a node. It is what happens when the lights go off: no branch has activation, the pump does not start again, and the substrate dries through the night.

Closing

Nothing in that tree is special. It is two oscillators, three memories, an inverter, a few groups and a few comparisons, the same pieces you can drag in the editor. The template arranges them for one industry’s known case; when the case is another — a ventilation, a dosing, a climate control — you arrange them yourself with the same pieces, or describe them to the Agent and review what it drew.

What runs on the device is exactly what you see on the canvas, what the Simulator tested and what the assistant reads the next time you ask it for a change. One logic, in four places. That is the point.

Continue with panels→