Greenhouse rules in one sentence

Remote control is not automation

The app connects greenhouse sensors and controllers to operators' phones. Operators could monitor every hall and switch fans, misters and heaters from anywhere, but only a few fixed rules ran on their own. When humidity rose, the app sent an alert, and the operator still switched the device by hand. The app was a remote control, not an autopilot.

“I have to manually adjust things, like turning the fans on and off throughout the day.”

Our team lead visited several greenhouses and interviewed operators in person, then brought the findings back to the design team. We worked through them together in a brainstorm. Two needs stood out: rules that run on a schedule, and rules that combine a schedule with a sensor threshold. The team scoped three requirements: scheduled rules, multi-condition rules and rule categories.

From there, I owned the rule builder and the trust layer around it: how operators build a rule, and how they see and control what's running.

More capability, fewer people able to use it

The core users were older, non-technical and not comfortable with technology in general. They were unhappy doing everything by hand, but in the greenhouse visits, our team lead saw many of them already struggling with the simple threshold rules they had. Each new requirement added expressive power and moved the product closer to programming. A logic editor would have served the few power users and lost the core segment.

The goal: deliver the expressive power of conditional logic to users who will never think in conditional logic.

A rule is one sentence: if this, then that

A new rule opens with two blocks, Condition and Event, each with a hint that completes the sentence: “if the sensor meets this condition…” and “…this happens to the controller.” Execution time sits below them and defaults to Always. Save stays disabled until the sentence is complete. There are no operators, variables or device IDs anywhere in the flow.

IF humidity(orchid_hall) > 85
THEN heater_1.set(40%)
  REQUIRE circulation_fan == ON
  REQUIRE vent == 10%
  DELAY 30s
WHEN always

Heating while venting is how greenhouses bring humidity down.

Trade-off:less flexible than a free-form editor, and more taps for power users. Accepted, because a wrong rule moves physical equipment. The model also has a limit: with several prerequisites, the event sentence gets long, as in the example above. That's where one sentence starts to strain.

Start from what's real, never from a blank field

Every choice in the flow starts from suggestions grounded in the operator's own greenhouse:

1. Source. A condition watches one specific sensor or the hall average, so a single sensor near a door doesn't have to decide alone.
2. Live readings. Suggested sensors show their current value (“air humidity, now 65%”), so thresholds are set against the actual state of the hall. Added after testing.
3. Ready-made conditions. Each sensor offers presets, including one with an exit: “if it drops below 20%, until it reaches 30%”. The exit keeps machines from flickering on and off around a single threshold. A custom condition covers the rest.
4. Suggested controllers. The event starts the same way: the likely devices first, then the full list.

Trade-off: presets anchor operators to the values we chose, so they need agronomic review.

Add complexity in the operator's own words

Power is added one step at a time, and every step is phrased as the question an operator would ask:

1. “What should the controller do?” Turn on, turn off, or run at a specific value, such as 40%.
2. “Before running, in this order.” Prerequisites: another controller's state, or a wait (“How long should the heater wait?”, added after testing), reordered by dragging.
3. “All conditions must be met together.” Additional conditions combine in one way only, and the screen says so.

Trade-off: with a single way to combine conditions, either/or logic takes two rules. A smaller model the operator can trust was worth more.

Simple by default, detailed on demand

Execution time defaults to Always, so most rules never touch scheduling. Choosing Selective reveals the rest: every day, alternate days or chosen weekdays; optional start and end dates; a fixed time or an interval, such as every two hours staying on for 25 minutes; and active time windows, such as 08:00–12:00 and 13:00–14:30. Combined with a condition, it delivers what customers asked for: a sensor threshold that applies only at certain hours.

Trade-off: the full schedule is one long screen, shown only to those who opt in.

Four managers, four rules, two changes

We tested the flow with four greenhouse managers. All four built a rule on their own, without help. Two things they needed were missing:

1. The current state. Choosing a sensor showed only its name. Managers wanted to see what it reads right now before setting a threshold, so every sensor card now shows its live value.
2. A wait between devices. Prerequisites only covered another controller's state. Managers needed time between machines, so a timed wait became a second prerequisite type.

Making automation observable and controllable

Handing control to software raised three operator questions. I designed the answers, starting from a brainstorm with the other designers:

1. Which rules are running? Rules are grouped into categories, such as seasons, with one active per zone. Switching requires an explicit confirmation of what will run.
2. Who changed this device? Every controller shows its current control mode: manual, rule-based or scheduled.
3. Will I know when it matters? Two alert tiers: a limit sends a notification; an alarm triggers a phone call.

Trade-off: one active category per zone, so mixed periods need a category of their own.

Shipped to production

The rule builder is live, in Persian with a right-to-left layout, on a platform that runs real greenhouses every day.

I left before post-launch measurement. Before leaving, I defined three metrics for the team:

1. Adoption. Share of accounts with at least one scheduled rule.
2. Effort. Manual device switches per week, before and after.
3. Conflict. Manual overrides of rule-controlled devices.

In automation products, the limit is rarely the engine. It's the user's model of it. Design the model first, then the interface.

What I'd do differentlyThe schedule is the one screen where the one-sentence idea breaks. With an interval, an on-duration and active time windows combined, operators can't see when their device will actually run. I'd end the schedule the way the rule itself works: with one summary sentence, such as “Monday and Friday at 08:00, 10:00 and 13:00, on for 25 minutes each.”