The Problem

Three bad options. Every grower knows at least one of them personally.

If you grow anything — hydroponically, in substrate, in soil, in a greenhouse — you've probably faced the same uncomfortable question at some point: how do I stop being the one who has to be there? The plants don't care if you're sick, traveling, or just want a weekend off. The sensors need checking. The pH needs adjusting. The pump schedule needs watching.

Today, growers choose between three unsatisfying answers to that question:

Each option forces a sacrifice: either your time (doing it manually), or your freedom (locked-in systems), or your sanity (endless DIY tinkering). What if there was a fourth option — one that didn't ask you to choose?

The Origin Story

Born from 10 years in the field. Not from a whiteboard.

CeresFlows was not designed by a committee. It was not conceived in a startup incubator or pitched to venture capitalists. It was written by a person who spent over a decade in hydroponics, aquaponics, and agriculture — and who, after years of doing the same things every single day, finally decided to stop doing them manually.

The frustration wasn't with the plants. It was with the infrastructure. There were sensors — good sensors — but each one was isolated. A pH meter here. A temperature controller there. A timer on the pump. No logic connecting them. No way to say: "Water not when the timer says so, but when the substrate is actually dry." No way to say: "If the temperature spikes, delay the next irrigation and turn on the fan first."

The commercial solutions were either too expensive, too rigid, or too generic. Home automation tools could talk to sensors but didn't understand growing. So the only option was to build it.

That is also why CeresFlows has a free version. Not as a marketing trick — not a "trial" that expires or a "freemium" that nags you. But because the platform was built out of necessity, not profit. It makes sense to make it accessible to growers who are in the same situation the author was in: capable, motivated, but not funded.

What is CeresFlows?

The sweet spot between a timer and a PhD in software engineering.

CeresFlows is an automation platform purpose-built for controlled-environment growing. It is not a smart home system adapted for plants. It is not a generic industrial SCADA repackaged with a nicer interface. It speaks the language of growers: pH, EC, VPD, DLI, substrate moisture, irrigation cycles, nutrient recipes.

You download a single executable — no Python runtime, no Docker containers, no database server to configure, no dependencies to install. Double-click. Open a browser. You are running. Windows, Linux, Raspberry Pi, Android — it works on all of them, without modification.

The hardware is yours. Use what you already have, or buy what fits your budget: a $20 Arduino, a $40 ESP32, a $2,000 industrial controller — it doesn't matter. CeresFlows connects to it. The intelligence lives in the software, not in proprietary hardware.

What Can You Automate?

Any Growing Method

CeresFlows manages the process, not the method. It works equally well for:

Why "CeresFlows"?

Ceres is the Roman goddess of agriculture — a symbol of abundance, growth, and nurturing the earth. Flows represents two things at once: the movement of water in hydroponic systems, and the logical flows you build in the software to control them.

Ancient wisdom. Modern logic.

Where Does It Run?

A single executable. Any platform. No dependencies. Runs on the computer you already own.

CeresFlows has one installation philosophy: no friction. You download one file. You run it. That's it. There's no Python to install, no Docker containers to configure, no Node.js version conflicts to debug. Everything — the web server, the database, the automation engine, the web interface — is bundled into a single binary that starts in seconds.

That binary runs on virtually anything.

Supported Platforms

The Android Option — A Grower's Dream

The Android support deserves a special mention, because it's not common. Most automation platforms are built for computers. CeresFlows goes further.

The Android app is not a remote control. It is the server. The full Go automation engine runs as a compiled native binary inside a foreground service — with CPU wake locks to prevent Doze mode, WiFi locks for constant network access, and a built-in watchdog that restarts the engine if anything crashes. Plug your phone into a charger. Mount it on the wall. Walk away. CeresFlows will be running when you come back — even after a power outage, because it auto-starts on boot.

Connect controllers via WiFi or directly via USB OTG. A $15 old phone becomes a production-grade automation server.

What the Server Needs

Installation in Three Steps

Bookmark that network address on your phone. It's your greenhouse dashboard — accessible from any browser on your local network, no app required.

License & Free Tier

CeresFlows is free to download and run. A free tier exists not as a marketing hook, but because the system was built out of necessity — and the builder believes access to good tools shouldn't depend on your budget.

To activate a license: CeresFlows generates a unique hardware code for your machine. You send it to the team, receive your license file, drop it in your CeresFlows folder, and restart. One-time process. No internet verification after that. No phoning home. The license lives locally on your hardware.

The Architecture

One brain. Many hands. One network. Everything talking to everything.

CeresFlows separates intelligence from action. The server thinks. The controllers act. The network connects them.

This separation is intentional — and it's what makes the system scalable. You can run one controller or twenty. You can add sensors without changing a line of logic. The server doesn't care whether there's one device or a hundred; it manages them all the same way.

The Three Layers

The Server — The Brain

The server is where all intelligence lives. It runs the flow engine that executes your automation logic, the scheduler that manages programs and time windows, the analytics system that stores and analyzes sensor history, and the web interface you use to configure everything. It's built in Go — a language chosen specifically for its efficiency and reliability on low-power hardware.

The database is SQLite — embedded, zero-configuration, and rock-solid. Everything is stored locally. Your data never leaves your network unless you explicitly set up remote monitoring.

Controllers — The Hands

Controllers are inexpensive microcontrollers that connect to your physical world. An ESP32 costs under $5. An Arduino Uno R4 WiFi is around $20. They have no intelligence of their own — they're intentionally kept simple. They connect to sensors and actuators via their physical pins and execute exactly what the server tells them.

CeresFlows flashes custom firmware onto controllers. Once flashed, a controller connects to your network, announces itself, and registers with the server. From that point, the server knows it exists — what type it is, what profiles it supports, and how to talk to it.

Communication Channels

Controllers connect to the server in three ways, giving you flexibility for different physical setups:

Sensors Connect to Controllers

Sensors and actuators don't connect directly to the server — they connect to controllers via their physical pins. CeresFlows supports every common protocol:

One controller can host multiple sensors and actuators simultaneously. Scale your hardware by adding more controllers to your network — no limit on how many you can run.

Key Vocabulary

Eight words. Once you know them, the whole system makes sense.

CeresFlows uses consistent terminology throughout. These aren't marketing terms — they're the actual names of objects in the system. Every screen, every button, every API call uses these exact words. Learn them once and you'll never feel lost.

Devices — Sensors & Actuators

A controller is just a circuit board until you attach something to it. Devices are what make CeresFlows see the world (sensors) and touch it (actuators). This is where raw wire meets real intelligence.

Two Sides of the Same Coin

Every device in CeresFlows is one of two things:

Both types live inside a controller's detail view — the page you get when you click Manage on any controller card. From there you can see all attached devices with their live readings, status, type, analytics label, and interface — and add new ones.

Adding a Device — Three Steps

Click Attach Sensor / Device from the controller detail page to open the three-step wizard.

The Template Library

CeresFlows ships with a library of pre-built device templates for the most common sensors and actuators on the market — DFRobot Gravity, Atlas Scientific, CWT Modbus probes, DS18B20 chains, SHT31/SHT41 climate sensors, generic pumps, grow lights, and more. Each template defines the exact protocol commands, voltage requirements, calibration strategies, and unit definitions.

If your device isn't in the library, the Template Builder — accessible from the wizard's first step — lets you create a custom driver from scratch. You define the interface (Analog, Digital, OneWire, UART, I²C, SPI), the read/write commands, how to interpret the response, and the calibration profile. Once built, your custom template behaves exactly like a factory one: wizard-ready, filter-ready, calibration-ready.

What Makes CeresFlows Devices Different

Most systems let you add a sensor and read its value. CeresFlows goes further — every device has a layer of intelligence built around it that makes cheap hardware perform reliably and makes expensive hardware perform accurately.

Protocols — One System, Any Hardware

CeresFlows devices communicate over six protocols, so you can mix professional-grade industrial sensors with hobbyist analog probes in the same system:

The Device Dashboard

Once registered, every device appears as a card in the controller's detail view, showing live data at a glance: current reading, status (Online / Offline / Frozen), analytics label, resource role, interface protocol, and fallback policy. A toggle lets you enable or disable an actuator directly from the grid without entering any menus.

The Test button opens a live dialog — force a sensor read and see the raw and calibrated value in real time, or activate an actuator and watch it respond. This is the fastest way to verify new hardware before it goes into production automation. The Service tab inside the same dialog provides access to advanced device actions: resetting calibration (Tare), changing Modbus Slave IDs, or adjusting bus parameters — all without touching the firmware.

⚡ Device Suite — Interactive Hardware & Sensor Tour

▶ Watch on YouTube 1 / 11

▶ Watch on YouTube (Full HD) YouTube Official • Opens in New Tab

‹ ›

WIZARD: STEP 1 🗂️ Device Wizard — Step 1: System Zones & Categories

🔍 Fullscreen

Chapter 10 — Hardware World

Expanders — Extending the Controller's Reach

Controllers are powerful. But sometimes a single board simply doesn't have enough outputs to drive everything your operation demands. That's where Expanders come in.

The Problem They Solve

Picture a compact ESP32 running five sensors and needing to switch eight dosing pumps, an irrigation valve, a grow light, and a circulation fan. A microcontroller has a finite number of I/O pins — and each pin can only carry a tiny signal current, nowhere near enough to drive a 12V pump or a 240V lighting circuit.

The classical answer was relay boards wired to individual controller pins. But that approach has hard limits: you run out of pins fast, wiring becomes complex, and the number of switching channels is fixed by the hardware you bought. CeresFlows takes a different approach — Expanders.

What Expanders Can Do

CeresFlows recognizes six categories of expander modules. Each solves a different class of problem:

The relay modules deserve special mention, because they are where most growers start. A Modbus RTU relay expander connects to the controller via RS485 serial bus. Through a single UART port, one 8-channel relay board can switch eight independent high-power circuits — pumps, solenoids, lights, fans — with full optocoupler isolation between the control electronics and the mains. Two of them on the same bus gives you sixteen channels. The controller never touches line voltage directly.

Adding an Expander — Two Steps

Expanders are added through the Hardware Modules button, accessible from the same panel where you select sensor categories when registering a new device. The workflow mirrors the device wizard philosophy: choose a model from a catalog, configure the bus parameters, done.

That's it. No pin assignment. No wiring map. No firmware changes. The expander is immediately visible in the controller's device grid.

Expanders in the Controller View

Once registered, each expander appears as its own card inside the controller detail page, alongside the sensors and actuators — but clearly distinguished with its own type badge. Channel indicators show at a glance how many outputs are occupied and how many are still free, with labels that adapt to the expander type: C1–C8 for relay channels, A0–A3 for ADC inputs, U1–U2 for UART bridge ports, G0–G15 for GPIO banks.

An actuator device (a dosing pump, a solenoid valve) is then registered as usual through the device wizard — but instead of mapping it to a controller pin, it is mapped to a specific channel on the expander. From that moment, the automation engine controls the actuator by sending commands through the expander's bus protocol. The grower never needs to think about RS485 frames or I²C register maps.

Monitor, Test & Commission

Every expander has its own test dialog — the same kind of live inspection tool that devices have. It opens directly from the expander card and contains three tabs, each adapted to the expander's function:

The Bus Scanner

Not sure what's physically present on the bus? CeresFlows includes a built-in Bus Scanner — also accessible from the device wizard panel. It scans both I²C and Modbus RTU buses directly through the connected controller:

• I²C Scan: The controller probes all 127 possible I²C addresses and reports which ones respond. Results show both hex address and its physical jumper position. Useful for confirming an ADS1115 is correctly wired before registering it.
• Modbus RTU Scan: Sweeps the RS485 bus for responsive slave devices. Includes direct write-and-verify for commissioning new relay modules at fresh Slave IDs.

The scanner only appears for controllers whose firmware reports the relevant capability (I2C_SCAN). No guessing. No wasted time.

🔌 Hardware Expanders Suite — Interactive Hardware Tour

▶ Watch on YouTube 1 / 9

▶ Watch on YouTube (Full HD) YouTube Official • Opens in New Tab

‹ ›

EXPANDER CATALOG 📦 Hardware Modules Catalog — Step 1: Categorized Expander Selection

🔍 Click image to expand in Lightbox

Template-Driven. Fully Extensible.

Every expander type in CeresFlows — just like every sensor and actuator — is defined by a JSON template. The template describes the communication protocol, the number of channels, the available commands, the bus parameters, and the service actions that appear in the commissioning tab.

The built-in catalog ships with the most common hardware. But if you work with a relay module from a manufacturer not in the list, or an ADC chip with a different register map, you can define a custom expander template and register it in the system — the same extensibility that exists for sensors and actuators, applied consistently at every layer.

What Is a Flow?

A Flow is a visual recipe — a sequence of instructions you draw on a canvas that the system then executes automatically, without any human intervention.

Think of it the way you'd explain a process to a colleague: "Read the pH sensor. If the value is too high, run the acid pump for a few seconds. Wait for it to mix. Read again. Repeat until it's within range." That logic — written in plain language on a whiteboard — is exactly what you build in the Flow Editor. Except here, you draw it with blocks and arrows, and the system runs it for you, 24 hours a day, seven days a week, without ever getting tired or forgetting a step.

A flow has exactly one entry point (Start) and one or more exit points (End). Between them, you place blocks and connect them with arrows that define the order of execution. The system reads your flow from Start, follows the arrows, executes each block in turn, and stops at End. That's the entire model.

The Canvas — Where You Draw Your Logic

Opening the Flow Editor brings you to a dark, infinite canvas. On the left is the Palette — a collapsible panel with every block type available. Drag any block onto the canvas and it appears, ready to configure. Connect blocks by drawing arrows between them. Pan, zoom, fit to screen — the canvas behaves exactly like you'd expect from a modern diagram tool.

On the right side, clicking any block opens its Properties Panel — where you configure what that specific block does. At the top of the editor, a Flow Health panel gives you a real-time overview: total blocks on canvas, how many are sensors, actuators, and logic blocks — plus a full variable usage map showing exactly which blocks read and write each variable in your flow. This is invaluable when flows grow complex.

⚡ Flow Suite — Interactive Tour

▶ Watch on YouTube 1 / 4

▶ Click to Play Video Walkthrough YouTube • CeresFlows Official

‹ ›

FLOW DIRECTORY 📑 Flows Directory — Active Library (16 Flows, 15,742 Runs)

🔍 Fullscreen

The Building Blocks

CeresFlows provides nine block types. Together, they can express any automation logic imaginable. Here is what each one does:

Variables — The Memory of Your Flow

Blocks communicate with each other through variables. A Sensor Read block stores its result in a variable; an IF block checks that variable; a Set Actuator block reads another variable to know how long to run. Variables are the connective tissue that makes blocks work together.

There are two types, and the difference matters enormously in practice:

Global variables are where the real power lives. Consider this example:

Global variables also support Tolerance Zones: instead of triggering on an exact value, you define a range of acceptance. A pH target of 5.85 with a tolerance of ±0.15 means the system only acts when pH falls outside the 5.70–6.00 window — not every time the sensor fluctuates by a hundredth of a point. This eliminates pump cycling, prevents equipment wear, and mirrors how professional industrial control systems handle setpoints.

⚙️ Variable Manager & Tolerance Controls

1 / 3

‹ ›

LOCAL VARIABLES 📦 Local Variables (Sensor Data) — Isolated Execution Scope

🔍 Click image to expand in Lightbox

Dynamic Value — Context-Aware Logic

Most blocks apply a fixed action or a stored variable. The Dynamic Value block does something more powerful: it evaluates conditions at runtime and sets a variable's value based on the current state of the system.

Imagine an EC dosing flow. You don't want to add the same volume of nutrient solution regardless of how far the EC is from target. If the EC is 0–1 mS/cm, you dose 20 mL. If it's 1–2 mS/cm, you dose 10 mL. If it's already above 2, you dose nothing. Without Dynamic Value, this would require multiple IF blocks and separate variable-set steps. With Dynamic Value, a single block evaluates the current EC reading and assigns the correct volume to your dosing variable — before the actuator block even runs.

The same logic applies to irrigation: if soil moisture is above 40%, water for 3 minutes; if it's below 20%, water for 10. One block reads the condition. One block decides the duration. One actuator executes it. Clean, readable, maintainable.

Resilience — Flows That Handle Failure

Real systems fail. Sensors return no data. Network drops happen. A pump doesn't respond. CeresFlows builds resilience directly into every block. Each block can be configured to retry automatically a set number of times before declaring failure. When failure is confirmed, the block can: stop the flow, pause it (resumable later), skip the step and continue, or jump to a named label elsewhere in the flow for graceful error handling. Blocks can also send a notification when they fail — so you know something went wrong before it becomes a problem.

For actuators, an additional Hardware Safety TTL is available: a maximum runtime limit at the hardware level. Even if the server loses connectivity, the controller's firmware will cut power to the device at the specified time. The software logic and the hardware watchdog work together — defense in depth.

A Real Example — pH Correction in 10 Blocks

Theory is easy. Let's look at a real flow: automatic pH correction for a hydroponic reservoir. The goal is to read the current pH, compare it to the target, and dose the appropriate correction pump until the pH is within the acceptable range — with a maximum of 10 attempts per run.

Every value you see in italics — pH Desire, Pump Mix Time, Pump pH UP, Pump pH Down — is a global variable. You set them once in the Variable Manager. The flow runs the logic. If next week you want to be more aggressive with dosing, you change Pump pH UP from 2 mL to 3 mL. The flow adapts — without any editing.

Testing Before Deploying

Every saved flow can be run in Visual Test Mode directly from the editor. The execution is real — it reads your actual sensors, controls your actual hardware — and you watch each block light up in sequence as it executes. The Flow Health panel on the right updates live: which block is running, what values the variables hold at each step.

This is how you build confidence before a flow goes into production. You test once, watch it work, fix what's wrong — and only then assign it to a live program.

The system distinguishes between two flow states:

• Valid ✅ — All paths connected, all blocks configured, Start-to-End reachable. Ready for use in a live automation program.
• Draft 📝 — Has unresolved errors (disconnected blocks, missing configuration). Saved, visible, but cannot be used in a running program until fixed.

Execution History — Every Run, Recorded

Every time a flow runs — triggered by a program, by a manual test, or by a schedule — CeresFlows records it. Open the Execution History for any flow and you see the complete archive: when it ran, how long it took, whether it completed successfully, what triggered it, and which time window it belonged to.

⏱️ Execution History — EC Control - CWT

● 100% SUCCESS RATE

🔍 Click to inspect in Fullscreen

The summary header shows at a glance: total executions, success rate, and min / average / max execution times. Below it, the full list shows every run — sortable and filterable by date range, status (completed/error), and source (program-triggered vs. manual). Each entry shows which program, which time window, and which trigger initiated the run.

Over time, this becomes an operational record of your automation. You can see how pH correction duration varies across the season, spot runs that took unusually long, and compare performance across weeks. Not just automation — accountable automation.

The Only Limit Is Imagination

A flow can be three blocks long — read, decide, act. Or it can be a complex multi-loop process with twenty blocks, dynamic values, mathematical calculations, and nested condition trees. Flows can call other flows. A master "Morning Routine" flow can trigger a pH check flow, then an EC dosing flow, then an irrigation flow — each one focused, each one testable independently, all of them orchestrated from a single starting point.

Flows can be organized into named Zones on the canvas — color-coded regions that group related blocks visually without affecting logic. A large flow becomes readable at a glance when its sections are labeled "pH Correction", "EC Adjustment", and "Irrigation Sequence".

The system keeps growing — new block types are added as real grower needs surface them. The Dynamic Value block did not exist in the early versions. It was added because real-world dosing logic demanded it. Every new block in the palette represents a problem that someone, somewhere, actually needed to solve.

Programs & Time Windows

You have built your flows — individual recipes for each task. Now it is time to tell the system when to run them, why, and under what conditions. This is the Program Builder.

Template and Program — Two States of the Same Thing

In CeresFlows, the terms Template and Program refer to the same object at different points in its lifecycle. A Template is the blueprint — your written plan: which flows to run, when, and why. A Program is what that blueprint becomes the moment it is activated and starts executing. The template sits in your library, editable, waiting. The program is live, running, doing work.

This distinction matters practically. You can have twelve templates in your library and only one active program at a time. You can edit a template while a program is running — the running program is protected by a frozen snapshot taken at the moment of activation. Your edits update the library template but do not interrupt the live session until the next time you load and start it. Creation is separate from execution. This chapter covers creation. Execution — the live dashboard, real-time monitoring, and active window management — is covered in Chapter 14.

The Templates page gives you an instant overview of your entire library: how many slots each template uses, which flows it contains, how many times it has been executed, and its total runtime. A dedicated row at the top shows the currently active program — the one actually running your greenhouse right now.

The Hierarchy — How a Template Is Built

Every template is built from three nested layers. Understanding this structure is the key to understanding everything else in this chapter.

Simple Mode — A Schedule in Minutes

For growers who just need a time-based schedule — run this flow at 06:00, run that flow at 14:00 — CeresFlows offers Simple Mode. No conditions, no trigger logic. Just events with start times and flows.

Each event has three fields: a Start Time, a descriptive name, and the flow to execute. Click Add Event and the system suggests the next logical time based on your configured Cycle interval. Build your daily routine in a few clicks.

Advanced Mode — Full Orchestration

Advanced Mode gives you complete control over the daily automation logic. Here you work directly with Time Windows and Triggers in their full form.

Time Windows — Scheduling the Day

A time window defines the hours during which the system is actively monitoring and evaluating triggers. Outside a window's hours, the scheduler is idle for that window — no checks, no actions. Inside the window, the scheduler wakes up at every Check Interval and evaluates all triggers.

Triggers — The Rules Inside a Window

A trigger is a conditional rule. It defines what the system checks, and what it does if the check passes. A time window can have one trigger or ten — they are evaluated in sequence on every check cycle.

The trigger form is where the real intelligence lives. Let's walk through each component using the example from the screenshots — a real irrigation trigger from a running tomato program.

Fallback — The Safety Net

Every time window can define a Fallback: flows (or an existing trigger) that execute when the window's time expires and no Break trigger has fired during the entire period.

The most intuitive way to configure a fallback is to point it at one of the window's own triggers. If the "Irrigation by PAR" trigger fires during the day, the fallback is skipped — the job is done. If it never fires — perhaps the PAR light was bright enough all morning and moisture stayed high — the window closes at 21:00 and the fallback executes the same irrigation sequence regardless. The plants get watered. No conditions needed at that point, no manual intervention.

This pattern gives you the best of both worlds: intelligent, condition-driven automation when the data supports it — and a guaranteed baseline action when it doesn't. You are never one dry night away from a failed crop just because a sensor stayed in range.

🗓️ Programs & Time Windows — Interactive Orchestration Tour

▶ Watch on YouTube 1 / 7

▶ Watch on YouTube (Full HD) YouTube Official • Opens in New Tab

‹ ›

TEMPLATE LIBRARY 📚 Automation Templates Library — Schedules, Coverage & Active Program

🔍 Click image to expand in Lightbox

Variables — The Configuration Knobs

When you assign flows to triggers, CeresFlows automatically discovers all global variables used by those flows. These become the adjustable parameters of your template — the knobs you turn without touching the logic itself.

At the moment of activation (Load → Configure → Start), you are presented with every discovered variable and its current value: target_pH, ec_target, dose_ml, irrigation_seconds. You confirm or adjust them before the program goes live. Once running, most variables can still be adjusted in real time from the active dashboard — no restart needed.

The Cycle Interval — Hardware Protection

Every template has a global Cycle Interval (in seconds, default 60). This is the minimum time the system waits between consecutive trigger executions — a hardware protection layer. It prevents a pump from being activated twice in 3 seconds due to rapidly fluctuating sensor values, protecting both hardware and the growing environment from over-correction.

The Check Interval on each Time Window controls how often conditions are evaluated. The Cycle Interval controls how often action can actually happen. Together, they define the rhythm of your automation: frequent enough to be reactive, constrained enough to be safe.

You have built the template. You have drawn the flows, defined the triggers, set the time windows. Now it is time to make it real. This chapter is about the moment the logic stops being a design and starts being a running automation — and everything that keeps it running, day after day, without your intervention.

The Program Lifecycle

Every running program in CeresFlows follows a clear, linear path:

Step 1 — Load a Template

The Active Program page greets you with the Program Launcher when nothing is running. Select a template from the dropdown — every template you have saved appears here. Choose one and you instantly see a preview: the template name, description, and a list of all its time windows with their start times. One click on Load & Configure and the process begins.

Step 2 — Configure Variables (The Most Important Step)

After loading, the dashboard shows your program in Loaded status — and a button immediately lights up in the header: CONFIG REQUIRED. This is not optional. It is the bridge between the frozen template logic and the real-world values you want to use today.

Inside your flows you define Global Variables — named placeholders for values that can change: watering duration, target pH, desired EC level, minimum water volume. The Configure screen is where you set those values before the program starts running. Only flows that actually use Global Variables appear here — if a flow has no globals, there is nothing to configure for it.

This is also the screen you will return to most often while a program is running — not to change the logic, but to tune the values. "Today we water for 10 minutes. Tomorrow conditions change, we come here and set it to 8. Done." No touching the flow. No recreating the template. One field, one save.

The Color System — What Each Color Means

Inside the Configuration Screen

The configuration dialog uses a master-detail layout. On the left: a tree of every trigger in the current time window, with all the flows used by each trigger listed beneath it. On the right: the variables for the selected trigger-flow context, laid out in a table — variable name, target value, unit, and tolerance.

At the top of the right panel, a breadcrumb shows you exactly where you are: Window → Trigger → Flow. An Accept Defaults button lets you confirm all orange values in one click.

Smart Sync — One Flow, Multiple Triggers

The same flow is often used in several triggers. An "Add Water" flow might appear in both a PAR-based trigger and a DLI-based trigger. By default, CeresFlows synchronizes them: change the watering duration in one, and it instantly changes in all other triggers that share the same flow. No need to update each one individually. This is shown by the ⇔ Nx badge next to each flow item — it tells you in how many triggers this flow appears and is currently synchronized.

Breaking the Sync — Independent Values per Trigger

Sometimes you want the same flow to behave differently in different triggers. Morning irrigation: 10 minutes. Midday: 8 minutes. Same flow, same logic — but different durations. You unlock (unlink) the specific variable for that trigger. It becomes independent — editing it no longer propagates to the other triggers.

The left panel marks unlocked flows with a custom badge showing the count of independent variables. A tooltip explains: "N variable(s) unlocked with custom values for this trigger (will not sync from master)." You can re-lock at any time — the variable inherits the current master value when it rejoins the sync.

Step 3 — Start

Once all required fields are filled and confirmed, the START PROGRAM button becomes available. Click it. The Scheduler activates and begins its work immediately:

1. Determines which time window is currently active (based on system time)
2. Begins evaluating triggers at the defined check interval
3. Executes flows when trigger conditions are met
4. Sends real-time telemetry events to the monitoring dashboard

Your automation is now live. 🟢 Running.

Midnight Reset — The New Day

Every night at midnight, the Scheduler performs a day reset. All time window statuses return to Pending. Trigger execution counts go back to zero. The cycle begins fresh.

But not everything resets. Skip Counts are preserved — if you told the system to skip a window the next 3 days, it counts down through midnight boundaries and never forgets. The same applies to any custom trigger skip configurations.

There is also a reliability mechanism: the reset date is persisted to the database. If the server was offline exactly at midnight (power outage, restart), the reset executes automatically the next time the server starts — no day is ever skipped, no stale state carries over.

Starting Mid-Day

What if you start a program at 2 PM and your template has time windows for 06:00–12:00? The system does not try to "catch up." Windows whose time has already passed are automatically marked as Skipped. Current and future windows activate normally. Fallback flows are not triggered for skipped windows — the system was simply not running during that time. This prevents unexpected behavior like running morning irrigation at 2 PM because it was "missed."

🚀 Going Live — Load → Configure → Start Interactive Tour

▶ Watch on YouTube 1 / 7

▶ Watch on YouTube (Full HD) YouTube Official • Opens in New Tab

‹ ›

PROGRAM LAUNCHER 📦 Step 1: Program Launcher — Template Selection & Time Window Previews

🔍 Click image to expand in Lightbox

The program is running. The triggers are evaluating. The flows are executing. But watching it work — seeing which window is active, which trigger just fired, what the current sensor readings are — is a chapter of its own.

The program is running. Somewhere in the greenhouse, a pump is waiting for soil moisture to drop below 65%. A light sensor is accumulating today's DLI. A night window is about to open at 22:00. You do not need to be there. But when you want to look — when you open the laptop at midnight and wonder "what is it doing right now?" — this is the page that tells you everything.

The Command Bar — Status at a Glance

At the top of the Active Program page, a persistent header card acts as the control tower for your running automation. On the left: a status icon that changes color and behavior depending on what the program is doing. On the right: every action you might need, always within reach.

The Controls

Six tools live in the right side of the command bar — each one purpose-built for a specific moment:

The Timeline Carousel — Your Day at a Glance

Below the command bar, the entire screen is given to the Timeline Carousel. This is not a list. It is a spatial, navigable view of your automation day — each Time Window occupying its own card, arranged in chronological order.

The carousel uses a 3-column layout:

Inside the Active Window

The central card — the Active Window Hero — is where the real information lives. It shows you not just which triggers exist, but what the system is actually seeing and deciding right now.

Triggers are shown in two groups, mirroring the logic defined in Chapter 13:

Per-Trigger Context Menu

Every trigger in the Active Window Hero has a context menu — accessible via the ⋯ button — with four targeted actions:

The flows listed under each trigger are also clickable. Click a flow that is currently running → the Flow Viewer opens in Live mode and you watch it execute block by block in real time. Click a flow that has already completed → it opens in History mode, showing the full execution trace of the last run. Click a pending flow → preview mode, so you can inspect its logic before it fires.

Adjusting Values While Running

One of the most practical features of the dashboard is the ability to change variable values without stopping or restarting the program. The automation continues — the next check interval simply picks up the new values.

Click the Variables button in the command bar. The same master-detail configuration interface appears — but this time, the program keeps running in the background. Change a watering duration from 10 minutes to 8. Raise the EC target from 1.8 to 2.2 because your plants are consuming faster than expected. Hit save. Done. No restart. No downtime.

Manual Action — Override When You Need It

Automation handles the routine. But sometimes you need to act now, outside the schedule. Maybe the reservoir needs an extra dose of nutrients. Maybe you want to flush a line. The Manual Action button gives you exactly that — a way to execute any flow immediately, attributed to the correct program context so it shows up in your journal and statistics.

You choose the flow, optionally configure its variables for this one-shot execution, and click Load in Viewer. The Flow Viewer opens and you watch it execute live — block by block. While the manual flow is running, an amber-green banner appears at the top of the dashboard: "Manual Flow Running: EC Control — [View Live] [■ Stop]". You can watch it or stop it at any moment.

Live Monitor — Inside the Engine

The Live Monitor button opens the Flow Viewer in a special monitor mode — a real-time window into the automation engine itself. You see the flow canvas as it executes: active blocks highlighted with a green glow, traversed paths marked, sensor READ values streaming in. At the bottom, three tabs give you three simultaneous angles on the execution:

The Global Pause Banner

When you pause the program, an amber ribbon appears at the very top of the entire application — visible on every page, not just the Active Program page. It tells you the program name, and counts down to the configured auto-action:

Three controls are available directly from the banner — no need to navigate anywhere: Resume restarts immediately, +30 min extends the pause by 30 minutes (resetting the countdown), and the settings icon takes you to the pause timeout configuration. When the countdown reaches zero, a modal appears with a 120-second grace period. If you do not respond, the system automatically resumes or stops — whichever you have configured in Settings.

As the timeout approaches under 5 minutes, the banner turns red and pulses — a hard-to-miss signal that the automation is about to make a decision on your behalf.

Save As Template — Making Live Changes Permanent

Over time, while a program runs, you might hot-edit triggers, adjust time window settings, and tune conditions through the paused-state editors. These changes exist in the live program but the original template in your library is untouched. Save as Template closes that gap.

The dialog shows a clear diff before you commit: exactly which time windows changed, which triggers were modified, and what the before/after values are. You choose to either overwrite the original template (updates it permanently with the current live configuration) or save as a new template (creates an independent copy, leaving the original intact).

When Hardware Fails — Safety Banners

CeresFlows performs a pre-flight check before executing any flow: it verifies that every hardware device the flow needs — pumps, relays, sensors — is online and responding. If even one is offline or unresponsive, the flow is skipped and a red banner appears:

View Details opens a grouped list of the failing devices — organized by flow name, deduplicated, and showing the exact failure reason for each device. This is enough information to diagnose and fix the issue without guessing. Once fixed, you dismiss the error and restart the program.

A separate RUNTIME HALTED banner appears if a flow fails during execution (as opposed to before it starts) — covering hardware disconnects, timeouts, or unexpected responses mid-flow.

Diagnostic Insight Panel — The Program's Event Feed

At the bottom of the dashboard, a collapsible panel quietly accumulates the history of everything this program has done since it started. Expand it and you see the last 50 system events, sorted newest-first, refreshing every 10 seconds:

This is not a debug log for developers. It is a human-readable audit trail for the grower — a way to look back and understand exactly what happened and when, without needing to decode anything.

🎛️ Active Program Dashboard — Real-Time Monitoring & Operations Tour

▶ Watch on YouTube 1 / 10

▶ Watch on YouTube (Full HD) YouTube Official • Opens in New Tab

‹ ›

TIMELINE DASHBOARD 🎛️ Active Program Dashboard — 24-Hour Timeline & Slot Orchestration

🔍 Click image to expand in Lightbox

The Active Program Dashboard gives you everything you need to watch, understand, adjust, and intervene in your running automation — without ever touching the underlying template. The logic stays intact. The behavior adapts. But everything the automation engine has actually done — every trigger that evaluated, every flow that executed, every block that ran — is recorded in detail, and that record is the subject of the next chapter.

Flight Recorder — Your System's Black Box

An airplane's black box doesn't prevent accidents — it explains them. It records every signal, every decision, every state change, so that when something goes wrong (or goes right), you have an exact, irrefutable account of what happened and why.

CeresFlows has the same thing for every flow execution. It's called the Flow Viewer, and it's not a debug tool for developers. It's a transparency layer for growers — a way to look inside your own automation logic and understand exactly what it did, one block at a time, in full detail.

Opening the Flight Recorder

Every flow that appears on your Active Program Dashboard is clickable. When you click the name of a flow attached to a trigger — whether it's currently running, just finished, or waiting — the Flow Viewer opens as a full-screen overlay. The system automatically selects the right mode based on context:

The Canvas — Execution Made Visible

The first thing you see when the Flow Viewer opens is the full flow canvas — every block, every connection, exactly as it was built in the Flow Editor. But now it tells a different story.

Blocks are shown in two visual states:

This alone answers a question growers ask constantly: "Did my pump actually run? Did the EC check pass? Which branch of the loop did it take?" You don't need to read logs to know — you can see the path the engine took, drawn out on the canvas in front of you.

Any block on the canvas is clickable. Clicking it opens the Block Inspector for that specific block and simultaneously filters the Console to show only the log entries from that block. The canvas and the panels below it are fully synchronized.

The State Inspector — Three Windows Into the Execution

Below the canvas sits the Flight Recorder State Inspector — a collapsible panel with three tabs. A quick facts bar in the top-right always shows the summary: total events, unique blocks visited, and total wait time accumulated. These three tabs give you everything you need to understand what the automation actually did.

① Variables Timeline

Every variable that existed inside the flow during this execution is listed here — the values they started with, the values they ended with, and a full chronological write history in between.

Variables are split into two categories:

Clicking any variable on the left expands its full detail on the right: a chronological table of every write, showing the exact timestamp, which block wrote it, the new value, and the delta from the previous write. For a variable that was rewritten 8 times during a loop, you can trace exactly how it evolved — step by step, write by write.

A Filter Logs button in the variable detail panel instantly filters the Console below to show only the log entries that involve that variable. The two panels stay in sync.

② Block Inspector

Click any highlighted block on the canvas, and the Block Inspector tab activates automatically. It shows everything that happened inside that specific block across every execution cycle it was visited.

This is the tool that answers: "My pump ran 5 times — did it read the correct sensor value each time? Did the EC actually drop? Did the condition pass on the third cycle?" All of it is here, reconstructed from the actual execution trace.

③ Anomalies & Warnings

The third tab runs automatically on every completed execution. It analyzes the full trace for patterns that indicate something may have gone wrong — not errors, necessarily, but situations worth knowing about.

Each anomaly card shows a title, a severity level (Critical or Warning), and a plain-language description. Two action buttons are always present: Inspect Block → (jumps to the Block Inspector for that specific block) and Logs (filters the Console to that block's entries).

The example above tells a real story: a Loop block that measured reservoir volume ran 85 cycles without achieving the target — the EC didn't reach the desired level before the safety limit stopped it. That's not a system error. That's agronomic data. The system ran correctly. But the result tells you something about your nutrient concentration, your pump flow rate, or your target value that deserves attention.

If no anomalies were detected, the tab shows a clean green state: "All loop cycles, sensor reads, and variable mutations executed within expected operating parameters."

The System Console — Every Event, Line by Line

Below the State Inspector, the Console records every event the engine generated during execution. This is the raw stream — not filtered, not summarized — the actual sequence of decisions and actions, in order, with timestamps.

Each entry is fully rendered — not raw JSON. A sensor read shows the actual value with its unit highlighted in green. A WAIT block shows a live countdown badge that ticks down while you watch. A loop exit tells you which cycle it stopped at, and why (condition turned false, or safety limit reached). A condition evaluation shows the exact comparison: left value, operator, right value, result.

The Console has three controls that make it useful at scale:

• Buffer: 100 | 500 | All — for long-running flows with thousands of events, start with 100 (newest) and expand only if needed.
• Filters: All | Errors | Hardware | Blocks — isolate sensor reads and actuator commands (Hardware), or loop and condition logic (Blocks), or only failures (Errors).
• Export to JSON — download the full log for offline analysis or record-keeping.

The synchronized filter is the most powerful tool: click a block on the canvas, or click "Filter Logs" from the Variable Timeline or Block Inspector, and the Console instantly narrows to only the entries from that block or variable. The filter is shown as a pill tag in the header and can be cleared with a single click.

Execution History — Every Run, Ever

The Flight Recorder isn't just for the current execution. From the viewer header, a History button opens the Execution History — a full archive of every time this flow has run since it was created.

Each record in the history shows:

The history is filterable by status (Completed / Error / Running), by source (Program schedule vs. Manual), and by time range (24h / 7d / 30d / custom date picker). It's sortable by start time, duration, or status. Clicking 👁 View on any row reopens the Flight Recorder for that specific session — the full canvas trace, the variable timeline, the console — exactly as it was at the moment of execution.

✈️ Flight Recorder — Execution Trace, Inspector & Audit Trail Tour

1 / 6

‹ ›

EXECUTION TRACE ✈️ Flight Recorder Canvas — Replaying Full Execution Trace

🔍 Click image to expand in Lightbox

With a complete picture of what your system is doing in real time and in the past, the next question naturally follows: what does all that data actually mean? That's the domain of the next part — analytics, calculated indices, and the intelligence layer that turns sensor readings into agronomic insight.

Most automation systems collect data as a side effect — it goes into a database and stays there. CeresFlows treats data as a first-class citizen. The Analytics Suite is a dedicated intelligence layer built to answer the questions a grower actually asks: What did my system do last night? How much nutrient solution did I use this week? Is my pH trending in the wrong direction? Why did my pump run twice as long on Tuesday?

The Analytics section is organized into four specialized modules, each accessible as a dedicated tab. Every module is a licensed feature — your license determines which are active. If a module is licensed but not yet installed, the tab shows a clear "Not Installed" prompt with activation instructions.

📓 Journal — The System's Diary

The Journal answers the most fundamental question a grower asks every morning: "What did my system do while I was asleep?"

Select any date from the calendar on the left. The Journal shows every Time Window that was active that day, each with a status badge:

Click any window to expand it. This is where the real intelligence lives. The Journal shows a before-and-after sensor snapshot for every device that was active — two categories:

• Controlled Parameters — sensors tied to actions in this window (reservoir volume, EC, pH, etc.) with their Start / Peak / End values, the configured setpoint, and a sparkline trend.
• Environment Telemetry — all other sensors that were reading during the window (moisture, temperature, humidity, PAR, etc.) with their delta (Δ) for the period.

Below the sensor snapshot, you see Actuator Usage — exactly which devices ran, for how long, and how many milliliters (or liters) were dispensed. Below that: a Flow Summary listing which flows executed and how many times.

The Journal is powered by a Tiered Memory architecture. When a Time Window closes, a background aggregator compresses the entire window's data into a single pre-built snapshot — sensor sparklines included, with a 1% deadband algorithm that reduces the JSON by over 90%. Your morning review loads instantly, no matter how much data the system collected overnight. Even if the server crashes mid-window, a boot-time recovery process automatically regenerates any missing snapshots from the raw trace archive.

📦 Resources — Consumption Tracking

The Resource Manager answers: "How much am I using — and what is it costing me?"

The dashboard is split into two layers. At the top: Tracking Profiles — logical consumers you define (pH+, pH−, Fertilize A, Fertilize B, Irrigation Water, Clear Water Valve…). Each card shows total consumption for the selected period with a percentage trend indicator. Below that: Stock Inventory — the physical containers (barrels, bottles, tanks) behind each tracking profile, showing remaining volume, supplied vs consumed amounts, and estimated days remaining. A progress bar turns red as the container runs low.

Click any Tracking Profile to open the Resource Detail View — a full drill-down with three summary cards (Total Amount, Avg Daily, Peak Day), a daily consumption bar chart, and a paginated Detailed Log showing every activation event: date & time, window name, device, duration, and amount consumed.

The Resource Manager also tracks Runtime Analysis — how long each actuator ran, what percentage of total runtime it represents, and (if you enter the device's wattage) the estimated energy consumed in kWh. A stacked area chart shows the overlapping activity of all tracked devices across the selected time range.

CeresFlows supports three independent calculation strategies per resource:

When tube wear or calibration drift causes the calculated volumes to diverge from reality, you can create a Stock Reconciliation Checkpoint — physically measure the container, enter the actual volume, and the system recalibrates all future calculations from that verified baseline. Your historical data is untouched; only the forward projection changes.

📈 Sensor Lab — Data Visualization

The Sensor Lab answers: "What are my readings doing over time?"

Select the sensors you want to plot (checkboxes in the left panel), choose a time range, and the chart renders immediately. Multiple sensors overlay on the same timeline with distinct colors and dual Y-axes — so you can see EC, temperature, and PAR on one graph without any of them becoming illegible.

The Sensor Lab uses a Hybrid HOT/WARM data architecture to balance resolution and performance across any time scale:

A critical design detail: the Sensor Lab tracks sensors by their Analytics Label, not by hardware UUID. If a pH probe fails and you replace the physical sensor, the new device inherits the same analytics label — and every historical chart seamlessly continues with no gap or duplication. Your data outlives your hardware.

The chart is fully interactive: zoom into any period by dragging the minimap at the bottom, hover for cross-sensor tooltips, switch between Chart and Table view, and export the full dataset as CSV for external analysis.

🔍 Insight Engine — Advanced Query

The Insight Engine answers the questions the other three modules cannot: "When my reservoir was at 70 L and EC was between 1.0 and 1.2 mS/cm, how much nutrient solution did my pump inject — and was it consistent?"

It works in two steps:

Click View Details to open the Full Analysis — a rich breakdown of every matched cycle. The engine calculates statistics across all matching sessions (Average Expected, Deviation, Min/Max Achieved) and performs an Impact Analysis: given the resource dosed and the sensor that changed, it calculates the impact coefficient — how many mS/cm of EC change you get per milliliter of nutrient solution. This is calibration-grade data, generated automatically from your own history.

Queries can be saved and named for reuse — select from a dropdown at the top of the page to reload any previously defined search with one click.

Under the Hood — One Pipeline, Four Windows

All four modules read from the same data pipeline. Every sensor reading and every actuator command flows through this chain:

Engine executes blocks
    → Event Bus broadcasts events
    → Historian records every event to SQLite
    → Background aggregators compress data (journal_windows, insight_sessions, sensor_readings_compact)
    → Analytics modules query the compressed layers — not the raw traces

Result: instant dashboards. Zero impact on live automation.

SQLite runs in WAL (Write-Ahead Logging) mode, meaning analytics queries never compete with live automation writes. Your Flow Editor, your triggers, your sensors — none of them pause while the dashboard loads.

📊 Analytics Suite — Four Dedicated Agronomic Intelligence Modules

▶ Watch on YouTube 1 / 16

▶ Watch Journal Walkthrough on YouTube YouTube Official • Opens in New Tab

▶ Watch Sensor Lab Walkthrough on YouTube YouTube Official • Opens in New Tab

▶ Watch Resources Walkthrough on YouTube YouTube Official • Opens in New Tab

▶ Watch Insight Engine Walkthrough on YouTube YouTube Official • Opens in New Tab

‹ ›

JOURNAL SNAPSHOT 📓 Journal Window Snapshot — Controlled Parameters & Real-Time Sparklines

🔍 Click image to expand in Lightbox

But raw sensor data only tells part of the story. CeresFlows goes further — it computes agronomic indices from your sensors: VPD, DLI, GDD, water deficit, dew point risk, and more. These calculated values can trigger automation just like any sensor reading. That's the subject of the next chapter.

Every grower who has set up an automated irrigation system has faced the same moment of uncertainty: how long should the pump actually run? Two minutes? Five? And at what moisture level should the trigger fire — 45%? 50%? The honest answer is: it depends on your substrate, your crop stage, your ambient temperature, and a dozen other variables that change every week.

Most systems force you to start with a guess, watch, adjust, watch again — a manual loop that can take weeks to converge, and restarts from zero every time you change your setup. The Smart Advisor breaks that loop. Instead of asking you to guess, it reads your own sensor history — the actual moisture curves your substrate produced during real irrigation events — and extracts the physical parameters of your specific environment. It turns weeks of trial-and-error into a single analysis run.

🧠 The Advisor Gallery

Smart Advisor is organized as a template gallery — a collection of analytical engines, each designed to answer a specific agronomic calibration question. The gallery shows every available and upcoming template at a glance, with search, filter, and view mode controls.

💧 Irrigation Calibration — How It Works

The Irrigation Calibration template is the first fully active advisor. Open it and you are taken to a focused two-column workspace: setup on the left, results on the right.

🗄️ Dual Data Source — Live DB vs. Archive

The advisor needs historical data to work. CeresFlows gives it two places to look:

The Data Source toggle appears automatically in the Setup Panel only when the selected sensor has an archive file. No archive? Only Live DB is shown — no unnecessary controls. When Archive is selected, a small banner confirms the record count and date span being analyzed (e.g., "Analyzing 9,782 archived records (2026-07-22 → 2026-09-07)"). Switching sensors resets the toggle back to Live DB — because a different sensor may have a different archive state.

💡 The Suggested Trigger — Density-Guided Start Point

Before you even configure anything, the system runs a quick scan on the selected sensor's history. It uses a sliding density window to find the moisture percentage where the most natural irrigation events actually started in the past. This becomes the Suggested Trigger — displayed as a green banner with the detected threshold and the number of cycles that support it.

🌱 Substrate Presets — Physics Built In

Different growing media behave very differently when wet. Rockwool absorbs and stabilizes in minutes. Soil takes almost an hour to distribute moisture evenly. These physical differences directly affect how the algorithm interprets the sensor data. The Substrate Type and Irrigation Method dropdowns select a preset profile that configures two key detection parameters:

If you know your substrate's exact physical behavior — perhaps from prior lab measurements or a previous calibration — the Advanced Physical Parameters accordion lets you override both values manually. Your custom numbers take full priority over the preset.

⚙️ The Algorithm — What Happens When You Click Analyze

When you click Analyze Sensor Data, the backend AdvisorService scans the entire selected data source — potentially thousands of sensor readings spanning months — and runs a two-phase Finite State Machine to detect every irrigation event:

The detected cycles are then filtered by the Trigger Range you configured (±5% tolerance around your trigger threshold). Cycles within that range contribute to the statistical calculations. If none match exactly, the system falls back to the nearest recorded cycles and notes this in the results.

📊 Reading the Results

The Results Panel is structured in three sections, from the most important answer to the deepest physical detail.

The Recommended Duration already accounts for drain drop. The formula:

This is why the drain drop matters: if your substrate loses 7.74% of moisture to gravity after the pump stops, the system pumps proportionally longer to ensure the substrate actually reaches your target moisture — not just approaches it before settling back down.

📉 Dryback Dynamics — Understanding Your Crop's Thirst

Below the three hero KPIs, the Dryback Dynamics section answers a different set of questions: not how long to water, but how quickly your substrate dries — and therefore how often irrigation should trigger.

This data transforms the Smart Advisor from a one-time calibration tool into an ongoing agronomic intelligence layer. If your dryback speed doubles between spring and summer, you will see it here — and know that your irrigation frequency should roughly double too.

🎖️ The Confidence Badge — Know When to Trust the Numbers

Every analysis result carries a Confidence Badge — a colored indicator that tells you how statistically reliable the recommendation is, based on how many irrigation cycles were detected within your configured trigger range:

The badge is interactive — hovering it shows a tooltip explaining exactly what it means for this specific analysis. A HIGH confidence result (like the 72-cycle archive example) means CeresFlows has analyzed enough events to produce a statistically reliable pump duration. A LOW confidence result is still useful — it gives a starting point — but the system tells you honestly that you should watch and verify.

🔬 Detailed Telemetry & Physics Breakdown

At the bottom of the Results Panel, the Detailed Telemetry section surfaces the raw statistics that fed the analysis — useful for verifying the results and understanding what the system actually saw:

A small Preset / Manual Override badge in the results header always indicates whether the analysis used the substrate's built-in parameters or your custom overrides — so you always know the basis of the recommendation without having to remember what you configured.

🧠 Smart Advisor — Data-Driven Agronomic Calibration Tour

1 / 3

‹ ›

TEMPLATE GALLERY 🧠 Smart Advisor Gallery — Analytical Engines & Calibration Templates

🔍 Click image to expand in Lightbox

With the data layer and advisory engine covered, the next chapter moves to nutrition — the Fertilizer & Nutrition Lab, where CeresFlows brings the same precision to solution mixing, PPM calculation, and feeding recipe management.

Every plant has a hunger. And every grower who has mixed nutrients by hand knows the tedium: consult the target table, weigh each salt, do the math, adjust for the water's own mineral load, then do it again in three weeks when the crop enters the next growth stage. A mistake in the math means a plant that suffers in silence — because it cannot tell you its magnesium is wrong. It just grows slower. Or stops.

The Fertilizer & Nutrition Lab is CeresFlows's answer to that problem. It combines a raw material library, a PPM recipe database, an interactive solution mixer with a real-time element balance engine, and a structured crop diary — all in one coherent workspace. From entering your fertilizer bag data once to mixing a 1 000-litre batch with a single click, every step is covered.

Raw Materials — Your Fertilizer Library

Before any mix can be calculated, CeresFlows needs to know what is in your feed room. The Raw Materials page is where you build that library. Add each dry salt or liquid product once, enter its elemental composition from the bag label (up to 14 fields: N-NO₃, N-NH₄, P, K, Ca, Mg, S, Fe, Mn, Zn, Cu, B, Mo, and density for liquids), and it becomes available to every mix calculation from that point forward.

The page is organized into three tabs, each for a different material category:

Each row in the table shows the fertilizer's elemental Composition as a row of color-coded percentage badges — so at a glance you know a material is heavy on K, light on Ca, or carries sulfur as a side element. A Mix toggle controls whether a material is eligible for the Auto-Mix generator. A small Chart icon opens the Inventory Dashboard for that specific product.

Inventory Management

Every raw material has its own Inventory Dashboard — a live stock ledger that tracks what you bought, what you consumed, and what it cost.

The dual-axis chart (grams on the left, euros on the right) shows stock level as a line and each purchase or consumption event as colored bars. Every entry in the history table carries a typed badge — CONSUMPTION (auto-logged when you run a Batch Preparation), or manual entries for purchases and stock corrections. Notes like "Batch: Tomato — Stage 4 (500 L)" are attached so you always know where the product went.

Target Recipes — Defining What the Plant Needs

A Target Recipe is a PPM profile — the nutrient concentrations a crop should receive at a given growth stage. CeresFlows stores them separately from the mix itself, because the target does not change; only the mix of fertilizers used to reach it changes depending on what's available in your feed room.

Each recipe carries 12 PPM targets (N, P, K, Ca, Mg, S, Fe, Mn, Zn, Cu, B, Mo) plus target EC and target pH. The recipe page renders every element as a colored badge in the row, so you can compare the nitrogen climb and the calcium shift across four growth stages without opening a single dialog. A crop filter narrows the list; pagination handles large recipe libraries.

Solution Mixer — The Calculation Workspace

The Solution Mixer is the center of the lab. It combines everything: your fertilizer library, your recipe, your source water, and the volume you need to prepare — and it turns them into exact gram or milliliter quantities, live element status, and actionable mixing instructions.

Configuring the Mix

Every mix starts with four parameters in the top configuration bar:

The Working Area — Lead Element Logic

For each fertilizer you add to the mix, you assign a Lead Element — the nutrient that this fertilizer is primarily responsible for delivering. You then set a Target PPM for that lead element, and the system back-calculates the exact physical mass or volume needed. The Side Effects column shows what other PPM contributions that fertilizer brings along (every real-world salt delivers more than one element).

The core formula driving every calculation:

When you change the reservoir volume, a useEffect re-runs gramsFromLeadPPM() for every entry simultaneously — the PPM profile stays constant, only the physical amounts scale. Moving from 100 L to 1 000 L requires no manual recalculation; just change the number.

Nutrient Status HUD — Real-Time Feedback

The sticky right panel updates with every keystroke. It shows three header badges — Target EC (from the recipe), Estimated EC (calculated from your current mix using empirical ionic contribution factors, R²=0.985), and Target pH — followed by a full element-by-element table:

EL = element · WTR = baseline from water profile · SOL = what your current mix delivers · TGT = recipe target · +/− = delta · % = percentage of target achieved. Clicking any row filters the fertilizer search to show only products that supply that element. The panel also offers a Chart view — an ECharts bar chart comparing SOL vs TGT side by side for every element.

Element Balance Warnings — Nutrient Antagonism Detection

Raw PPM numbers alone are not enough. Two elements can both hit their targets and still antagonize each other in the root zone if their ratio is wrong. The Element Balance Warnings collapsible runs four agronomic ratio checks in real time:

Each check is graded ok / info / warning / critical. The collapsible header shows a summary badge ("2 Notes/Warnings") so you see the worst-case status without expanding the panel.

Stock Solution Preparation — A+B Split System

Mixing a 1 000-litre reservoir directly is rarely practical. Most growers prepare concentrated stock solutions — Tank A and Tank B — that are then diluted into the final reservoir. The Stock Solution Prep collapsible guides that process.

For each tank (A, B, C), you choose a dilution ratio from the preset dropdown — 1:50, 1:100, 1:150, 1:200, 1:250, 1:300, 1:400, or Custom. The system instantly calculates:

• Total Salt — total grams/ml for this tank at the chosen ratio
• Actual Ratio — effective dilution given your reservoir volume
• Add per 1 L — how many ml of stock to add per litre of final solution
• Status — ✅ SOLUBLE or ⚠ concentration warning

The solubility check is critical: if the chosen ratio would produce a stock concentration above 400 g/L (the safe dissolution limit), the status turns amber and a warning banner appears: "Stock B concentration is 1345 g/L which exceeds the safe limit of 400 g/L. Minimum required water: 3.36 L." Ratios exceeding this limit are automatically disabled (shown as "Dense") in the preset dropdown.

Why A and B? Calcium and phosphate / sulfate cannot coexist in concentrated solution — they precipitate. The Tank A / Tank B separation keeps them apart until they reach the reservoir, where the final dilution prevents precipitation.

EC Correction — Dialing In the Final Conductivity

After building the mix, the EC Correction collapsible helps you hit the exact conductivity target without recalculating from scratch. Two modes:

Example from a real session: Current EC = 3.0 mS/cm, reservoir = 100 L, recipe target = 2.4 mS/cm. The EC Correction immediately shows: Add 25.00 L → Final Volume 125.00 L → Result EC 2.40 mS/cm. No spreadsheet needed.

Generate Optimal Mix — The Solver

Manual mixing requires knowledge. Auto-Mix removes that barrier. Press Generate Optimal Mix, and CeresFlows runs a Nelder-Mead optimizer (from the gonum numerical library) against your eligible fertilizer library and the active recipe. The algorithm finds the combination and quantities of fertilizers that minimizes the sum of squared errors between achieved and target PPM — while also preferring cheaper fertilizers among equally valid solutions.

The result appears in a Coverage Report — a table of all 14 elements with target vs. achieved PPM, a percentage bar, and a status icon (✓ on target · ⚠ overshoot · ✗ unreachable with available fertilizers). A Warnings section below explains any deviations: "S is 218% of target — normal when using sulfate-based Mg and K sources." You can apply the result directly to the working area or tweak it manually first.

AutoMix Settings — Configuring the Solver

The solver's behavior is fully configurable via the AutoMix Settings panel. Settings are persisted to the system database so they survive restarts.

Mix Library & Batch Preparation

Every completed mix can be saved to the Mix Library — a named archive of your formulations organized by crop. The library shows each saved mix with its historical cost (€), live market price at current stock prices, and estimated EC.

Loading a mix restores the full working state: recipe, water profile, volume, tank assignments, and all fertilizer entries. From there, the Batch Preparation workflow scales the mix to any target volume. Enter "1 000 L" for a formula stored at 100 L, and every ingredient auto-scales (×10.00 in this case) and is displayed by tank with the required physical amount.

Pressing Done (Finish Batch) auto-logs consumption entries in the inventory of every ingredient — so your stock levels and running cost figures update automatically. No separate stock adjustment needed.

Nutrition Diary — The Farmer's Field Log

Numbers tell half the story. The other half is what you saw with your eyes: a leaf curling at the tip on Tuesday, the solution change that brought the plant back to green on Friday, the note about the batch number you sprayed last month. The Nutrition Diary captures that half.

The diary is organized around Objects — tracked entities you define. An object might be a crop batch ("Tomatoes 2026 Row A"), a greenhouse zone, a reservoir, or anything else worth observing. Each object has a type, a growth stage, and an archive state. The main page shows all active objects as cards or in a table, with a toggle to reveal archived ones.

Inside each object, logs are listed chronologically. Each log is created in the DiaryLogModal — a full-screen editor where you compose structured blocks, each capturing a different type of information:

Blocks within a log are drag-and-drop reorderable. Multiple blocks of the same type can coexist in one log entry — so a single feeding session can record measurements, log the solution change action, and add an observation, all in one chronological entry. Logs can be filtered by template type and by date range; Expand All / Collapse All control the view density in long crop histories.

🧪 Fertilizer & Nutrition Lab — Precision Feeding Tour

▶ Watch on YouTube 1 / 18

▶ Watch Fertilizer Lab Walkthrough on YouTube YouTube Official • Opens in New Tab

‹ ›

TARGET RECIPES 🎯 Target Recipes — Multi-Stage Elemental PPM Profiles

🔍 Click image to expand in Lightbox

With nutrition covered, the next chapter steps outside the local network entirely — CFL Remote Monitoring, which lets you watch your system from any browser in the world without a VPN, a static IP, or any cloud dependency.

CeresFlows Link — Your Greenhouse from Anywhere

Remote monitoring without VPN, without a static IP, without complexity.

It is 2 AM. Your irrigation program is running autonomously, your sensors are live, your relays are switching exactly when they should. The system is doing its job — but you are not there. You are 300 kilometres away, and the only thing you know is that you set it up correctly yesterday.

For most growers, the solution is a VPN, a remote desktop tool, or a static IP address — layers of networking complexity that exist only to answer one simple question: is my system OK?

CeresFlows Link (CFL) is built to answer that question without any of that infrastructure. It is a lightweight remote monitoring bridge — a window into your local system that opens from any browser in the world, with nothing more than a username and a password.

Offline-First. Remote-Second.

CeresFlows was designed from the first line of code to run entirely locally — no internet required, no cloud subscription, no external dependency. That principle does not change with CFL. The automation engine keeps running whether the remote connection is active or not. If the internet goes down at 3 AM, your irrigation program does not pause and wait. It continues exactly as programmed.

CFL is an addition, not a requirement. It extends the system's reach without touching its core. Think of it as a one-way observation window into a room that keeps running whether anyone is watching or not.

How the Connection Works

The local CeresFlows server opens a persistent WebSocket connection to the CFL Hub — a relay server that bridges local nodes with remote viewers. This is an outgoing connection from the greenhouse to the Hub, not an incoming one. The router never needs to expose any port to the internet.

Authentication uses a HMAC-SHA256 challenge-response: the Hub sends a random single-use nonce, the local server signs it with the shared cluster secret and returns the hash. If the signature matches, the tunnel is established. The secret itself never crosses the network.

If the internet connection drops, the server retries automatically using exponential backoff — starting at 1 second and capping at 30 seconds, with random jitter to prevent thundering-herd reconnection storms. The automation program running locally is completely unaffected.

The CeresFlows Link Web Viewer

Once connected, remote viewers access the system through a purpose-built web interface at ceresflows.com. This is not a generic dashboard — it is designed specifically to mirror the state of the local CeresFlows system: active programs, sensor readings, relay states, controllers, and more.

The viewer is organised into five tabs. Each one focuses on a specific aspect of the running system.

Managing Your Fleet

Every greenhouse is managed as a named node in your account. Pairing a new greenhouse requires three things: a display name, the Hardware ID (HWID) of the local server, and optionally a viewer access code — a PIN or password set on the local side that the viewer must enter to unlock monitoring access.

A single account can manage multiple greenhouse nodes — a second polytunnel, a rooftop installation, a friend's system that has been shared with you. Switching between them is a single click in the Greenhouse selector in the top bar. Each node has its own dashboard, its own device list, its own program state.

Setting It Up — Local Configuration

On the local CeresFlows installation, CFL is configured in Settings → Remote Access. The setup is straightforward:

The Tunnel Live Status card on the right side of the Settings page shows the current connection state in real time: green pulsing dot when connected to Hub, amber when reconnecting after a drop, grey when manually disconnected. It also logs total snapshots served — so you can see exactly how many times remote viewers have refreshed data from this greenhouse.

On-Demand Snapshots — Not a Live Stream

The remote viewer does not receive a continuous stream of sensor values. When a viewer clicks ⟳ Refresh, a request travels from the browser to the Hub, and from the Hub to the local node. The node collects the current state — all sensors, all relays, all controllers, the active program — packages it into a snapshot, and sends it back. The viewer updates.

This design has an important implication: if ten people open the same greenhouse's dashboard simultaneously and all click Refresh at the same time, only one request reaches the local server. The Hub holds the other nine in a queue and delivers the same snapshot to all of them the moment it arrives. The local system never receives more than one request per three seconds regardless of how many people are watching. This is called SingleFlight debouncing.

Phase 1: Read-Only. Always Growing.

CFL is openly described as a feature in active development — and intentionally so. The first phase provides what matters most: visibility. You can see what your system is doing, from anywhere, at any time, without any networking expertise. No command can be sent to the hardware remotely. The greenhouse operates on the automation logic it was given locally, and CFL only watches.

What comes next is already being planned: the ability to issue limited commands remotely (manual relay overrides, pause/resume programs), a cloud-hosted historical archive that retains telemetry data even when the local server is offline (Cloud Vault), multi-node comparison dashboards for operators running several facilities, and mobile viewer integration. The system will expand — but the offline-first architecture at its core will not change.

🌐 CeresFlows Link — Remote Monitoring Tour

1 / 5

‹ ›

WEB VIEWER DASHBOARD 🌐 CFL Web Viewer — Live Remote Monitoring Dashboard

🔍 Click image to expand in Lightbox

Next: Simple Mode — a touch-optimised interface designed for field operators who need to check sensors, run a relay, or read diagnostics without navigating the full system UI.

Chapter 22

Simple Mode

Your greenhouse at a glance — from a tablet on the wall or a screen next to the hardware.

Not every interaction with CeresFlows requires sitting at a full workstation. Sometimes you walk into the greenhouse, glance at the screen by the controller rack, and need to know three things immediately: is the program running, what are the sensors reading, and is anything wrong. You do not want to navigate menus. You do not want information density designed for a 27-inch monitor. You want the answer — right now, on a 10-inch touch panel, with your finger.

Simple Mode is CeresFlows' answer to that scenario. It is not a stripped-down version of the system. It is the same system, presented through a different lens — one that trades density for clarity, sidebars for touch targets, and configuration menus for the five things a field operator actually needs.

Where Simple Mode Lives

The intended environments are exactly those where Advanced Mode becomes impractical:

The Interface

Simple Mode discards the sidebar entirely. There is no navigation rail on the left, no AI Chat widget, no welcome overlays. Instead, the entire screen is dedicated to content, and navigation lives in a floating dock at the bottom — always reachable, never in the way.

The dock has two states. When collapsed, it shrinks to a single small "Menu" button in the corner — invisible until you need it, so it does not steal screen real estate from sensor readings. When expanded, it reveals the full navigation bar with all tabs, plus two scroll arrows so you can page through content without lifting your hand to drag.

Switching back to Advanced Mode takes one tap — a small icon in the dock sends you directly to the full interface. The preference is remembered, so the system always opens in the mode you last used.

Seven Tabs. Everything You Need.

The navigation dock currently holds seven tabs, each selected because it answers a specific question a field operator asks daily. They are not a reduced copy of Advanced Mode — they are a curated selection of what matters when you are standing next to the hardware. New tabs will be added over time, but only when a genuine field need justifies them.

① Dashboard — Everything at Once

The Dashboard mirrors the structure of Advanced Mode's home screen, but with touch-sized cards and no noise. At the top, a compact program card shows the active automation program — its name, current status, which time window is active, and the next scheduled check. Below that, two collapsible sections: Sensors and Actuators & Relays.

You choose which devices appear here. The dashboard is configurable: tap the settings icon, pick the sensors and actuators that matter most for your daily routine, and those are what you see every time you open Simple Mode. If nothing has been configured yet, the system shows the first six sensors and four actuators automatically as a sensible default.

Each sensor card shows the live reading, the last update timestamp, and a percentage trend for the past 24 hours — so you can see at a glance whether moisture is rising or EC has been drifting. Each actuator card shows ON/OFF state with a colour indicator. If a sensor goes offline or shows an error, its card immediately turns red. The dashboard does not require any action — it is designed to be read in under ten seconds.

② Program — The Running Logic, Laid Bare

The Program tab opens the active automation program in its full structural form — but stripped of the editor controls that belong in Advanced Mode. You see the three-panel time window carousel (Previous → Active → Upcoming), and below it, the full trigger pipeline for the active window.

Every trigger is listed with its name, execution count, and live condition state. When a trigger has conditions attached, those conditions are shown with their current sensor readings, their targets, and whether the reading is confirmed or still being evaluated. The flow pipeline assigned to each trigger is visible as a sequence of named steps.

This is the tab you open when the irrigation ran but you are not sure which trigger fired, or when you want to confirm that the PAR-based condition is actually being checked against the right value right now. No editing from here — but complete visibility.

③ Devices — All Sensors & Actuators in One List

The Devices tab shows every device in the system — sensors and actuators together — as a clean, scrollable list. Search by name, model, analytics key, or role. Filter to sensors only, actuators only, or by specific controller. Each row shows the device name, its live reading or ON/OFF state, and a colour-coded status badge (Online / Offline / Disabled / Error).

Tap any device to open its full detail modal. For sensors, that means three tabs: Monitor & Test (read once, start a live stream, view trend history), Calibration (full calibration suite — linear, offset, pH, EC, volumetric flow — all accessible with a touch numpad, no keyboard required), and Settings (analytics label, noise filter thresholds, fallback values, and more).

The calibration tools deserve a specific mention: the entire calibration workflow has been rebuilt for touch. A large numeric keypad replaces any text field, quick-step buttons let you nudge values by ±10, ±1, or ±0.1 without typing, and an SVG curve chart shows the calibration function in real time. You can calibrate an EC or pH probe standing next to it, tablet in hand, without needing a laptop.

④ & ⑤ Indices and Conclusions — The Agronomic Pulse

In Advanced Mode, calculated indices and diagnostic conclusions share space in the analytics suite. In Simple Mode they are two separate tabs — deliberately so. Reading a VPD value while simultaneously reviewing a stress conclusion on the same dense screen is asking too much of a glance.

The Indices tab shows a summary card for each active index: VPD, DLI, GDD, ET₀, DryBack, Dew Point, Leaf Temperature Delta. Each card displays the current value, its risk zone (optimal / warning / critical), a stale-data indicator if the sensor feeding it has not reported recently, and a tap-to-expand detail view if you need the full breakdown.

The Conclusions tab lists the diagnostic assessments — the system's interpretation of combined index behaviour over time. Is the plant experiencing chronic heat stress? Is VPD consistently outside the optimal window during the light period? Conclusions convert raw numbers into actionable sentences. Each conclusion card shows severity, a short description, and a timeline modal for inspecting how the pattern developed over the last 24 hours.

⑥ Stock — Resources at a Glance

The Stock tab is a field-ready view of the Resources module. It shows active tracking profiles (nutrient solutions, water, electricity) and stock inventory levels — how much is left, how much was consumed today, and at what rate.

A touch date picker lets you switch between Today, Yesterday, and the last 7 days to review consumption for any period without typing a date. When stock drops below a threshold, the card colour shifts to amber. If a refill needs to be logged, tap the profile and enter the quantity via the same touch numpad used in calibration. The stock reconciliation checkpoint is also accessible here — the point where what the system tracked is compared against what you physically measured.

⑦ Hardware — Controller Status

The Hardware tab shows all registered controllers with their connection status, transport type, and last seen timestamp. It is not a setup tool — it is a status check. If a controller goes offline, this is where you confirm it and see when it was last reachable. For field operators, this is the tab that answers "why did the relay not fire?" — the controller it lives on may have dropped.

📱 Simple Mode — Touch & Field Operator UI Tour

1 / 10

‹ ›

DASHBOARD TAB 📊 Simple Mode Dashboard — Touch Tiles, Time Windows & Actuator Grid

🔍 Click image to expand in Lightbox

Advanced Mode Is Still the Leader

Simple Mode covers the daily operational cycle: check, monitor, calibrate, confirm. It does not replace Advanced Mode for building flows, defining programs, adding new controllers, or tuning automation logic. Those tasks require precision and context that belongs on a full workstation with a proper screen.

The two modes are designed to work in tandem. A grower might configure a program in Advanced Mode once, then rely entirely on Simple Mode for day-to-day operations — checking the morning dashboard, confirming the evening irrigation ran, and calibrating the EC probe when solution gets changed. Advanced Mode and Simple Mode are not competitors. They are two views of the same greenhouse: one for building, one for running.

Next: Notifications — how CeresFlows reaches you when something needs your attention, even when you are not watching any screen at all.

Chapter 24

Safety Architecture

Built to Fail Safe — Five Layers of Defense Between Your Crop and Catastrophe

It is 3 AM. Your irrigation flow fires as scheduled. Halfway through execution, the soil temperature sensor stops responding — the probe cable was severed by a rodent. The server has no reading. What does the system do?

In most automation systems, the answer is either: keep going with the last known value indefinitely, or crash entirely, leaving the relay open and the water running. Neither is acceptable.

CeresFlows was designed from day one around a single safety philosophy: Fail Safe. Alert immediately. Recover autonomously. That philosophy is implemented as five independent, overlapping layers of protection — each one catching failures that the layer above it could not.

Layer 1 — Data Integrity: Protecting Against Lying Sensors

Every sensor reading in CeresFlows passes through a multi-stage validation pipeline before it is used in any automation decision. The system is explicitly designed to distrust a single reading.

When All Retries Are Exhausted

The final decision — what to do when data cannot be trusted — belongs to the grower. Every Sensor Read block in a flow has a Safety & Errors panel with explicit failure handling:

Layer 2 — Flow Execution Boundaries: Protecting Against Bad Logic

Even with perfect sensor data, a flow with a logic error could run forever, leave a relay open, or trigger a chain reaction. This layer constrains what flows are allowed to do before they are even permitted to start.

Layer 3 — Hardware Watchdog: Protection When the Network Fails

This is the deepest and most critical layer. It operates entirely within the microcontroller firmware — independent of the server, the network, and the software above it. Even if the server catches fire, this layer works.

The firmware's main loop() continuously checks all active TTL timers. If the TTL expires — even with no network, no server, no WiFi — the relay is switched off by the microcontroller itself, in hardware, unconditionally.

Millis() Rollover Protection

The millis() counter in microcontrollers wraps back to zero after exactly 49.7 days. The naive implementation — expireAt = millis() + ttl — would break near the rollover boundary, leaving a relay permanently on every ~50 days. CeresFlows firmware avoids this entirely by measuring elapsed time using unsigned subtraction: millis() - startTime. Unsigned arithmetic wraps correctly in all cases. A controller that has been running for months without a reboot has the same TTL accuracy as one that was powered on five minutes ago.

Layer 4 — Crash Recovery: What Happens When the Power Dies

The server host loses power mid-execution. An ON command was sent 4 seconds ago. The relay is open. The server has no memory of this — RAM is gone. When it comes back online, what does it do?

From the operator's perspective, the System Crash Detected dialog surfaces this information immediately on reconnect — showing the interrupted flow ID, the time slot it belonged to, and the pre-crash status. Three recovery paths are offered: Stop Program, Ignore Crash, or Resume Execution — with an automatic default that kicks in after a countdown if the operator does not respond.

🛡️ Safety Architecture & Anomaly Protection Tour

1 / 8

‹ ›

LAYER 1 · DATA INTEGRITY 🛡️ Sensor Safety & Integrity — Comprehensive Anomaly Defense

🔍 Click image to expand in Lightbox

Layer 5 — Observability: The System That Asks for Help

A safety system that fails silently is no safety system at all. Every time a protection mechanism fires in CeresFlows — a frozen sensor blocks a flow, a pre-flight guard rejects a plan launch, a TTL forces a relay off, a crash recovery loop runs — the system generates an internal ERROR or SYSTEM_ALERT event.

These events flow through the same notification infrastructure described in the previous chapter: UI banners, Telegram messages, email — depending on the grower's configuration and alert rules. The message includes precise context: which sensor failed, which flow was affected, what action the system took, and what the operator needs to do next.

CeresFlows does not just protect. It explains. You wake up to a message that says: Soil temperature sensor lost signal at 03:14. Irrigation flow was stopped safely. No water was delivered. Check sensor connection. Not just an alarm — a diagnosis.

Next: Data Safety & Continuity — backups, device archives, and the tools that protect your data with the same care this chapter applies to your hardware.

Part VII — Extended Universe

Data Safety & Continuity

Backup, Archives & System Health

Hardware can be replaced. Automation logic can be redesigned. But the historical data of a living, growing system — six months of sensor readings, calibration records, diary entries, fertilizer logs — is irreplaceable. CeresFlows treats data continuity with the same seriousness it applies to hardware safety: multiple independent mechanisms, layered by purpose, built to survive anything from a accidental misconfiguration to a full server migration.

Section 1 — System Backup: Your Configuration, Preserved

The Backup system is the first line of defense. It captures the structure of your CeresFlows installation — the hardware definitions, the automation logic, the nutrition recipes, the notification rules — and encodes it into a single, portable JSON file that can be restored on any machine running CeresFlows.

Before any data is written, the system offers an Inspect step. Upload a backup file, and CeresFlows reads its manifest without modifying anything — showing you the system version it was created on, the exact record count for every entity, and any dependency warnings (for example: "Backup contains Devices but not Controllers — orphan references may result"). You make an informed decision before committing.

Disaster Recovery & Migration

The backup format is platform-agnostic. A backup created on Windows restores on Raspberry Pi. A backup from an Android server restores on Linux. This means:

• If your server dies, clone the configuration to new hardware in minutes.
• Moving from a development machine to a production server? One export, one restore.
• Sharing a complete greenhouse setup with a partner? Same process.

Section 2 — Device Archives: The Historical Vault

System backup covers your configuration. Device Archives cover your data — specifically the full chronological telemetry of every sensor and actuator that has ever been connected to your system. This is a fundamentally different kind of storage, built on a different principle.

Each sensor and actuator in CeresFlows has a unique analytics label — a stable identifier that persists across device renames and hardware swaps. The Archive system uses this label to maintain a dedicated SQLite file on disk for every device. These files are never deleted by the system and never overwritten — only appended to.

Built-in Archive Viewer

Archives are not just files to download and ignore. CeresFlows includes a built-in Archive Preview Dialog that opens any device's archive directly in the browser, no external tools needed:

• KPI Bar: Instant summary — min, max, average, total points, sample interval, data span in days.
• Interactive Chart: Full timeline rendered with ECharts. Large datasets are automatically downsampled using the LTTB algorithm — you see the shape of the data, not noise. Pan, zoom, and inspect individual points.
• Data Hygiene Brush Tool: Draw a selection box on the chart to identify noise spikes. Batch-delete them directly from the archive. The metadata statistics are recalculated automatically.
• Trim Range: Remove test periods at the start of a device's lifetime before the grower set it up properly.

💾 Data Safety, Backup & Device Archives Tour

1 / 6

‹ ›

BACKUP & RESTORE 📦 Backup & Restore Hub — Modular Export & Offline Demo Mode

🔍 Click image to expand in Lightbox

Section 3 — Data Management: Storage Health & Lifecycle Control

A long-running automation system accumulates data continuously. Without active lifecycle management, the operational database grows without bound — slowing queries, increasing backup sizes, and making it harder to find relevant records. CeresFlows includes a dedicated Data Management panel in Settings that gives the operator full visibility and control over the database's health.

System Events Explorer (Audit Log)

Every significant action in CeresFlows — a hardware configuration change, a relay forced override, a license activation, a backup restore — is recorded in the system audit log. The Data Management panel exposes this log with full search and filter capabilities: filter by category (CONFIG, HARDWARE, LIFECYCLE), by severity (INFO, WARNING, ERROR), by time range, or by keyword. A built-in Diff Viewer shows exactly what changed when a configuration was modified — old values on the left, new values on the right.

When the audit log grows large, bulk cleanup is available: delete all records older than a configurable number of days, or multi-select specific records for removal.

Execution Management — Smart Cleanup

The automation execution history (flow run sessions and their traces) is the largest source of database growth in an active system. CeresFlows provides targeted cleanup presets that operate surgically rather than erasing everything:

Beyond manual cleanup, a global Retention Policy allows the operator to set an automatic maximum data age — for example, 90 days. The system enforces this limit automatically, so the database never accumulates unbounded history without explicit operator intent.

The panel also provides live storage indicators — record counts, session volumes, and database size — so you can see the actual footprint of your data before deciding what to trim.

Next: The Ecosystem — the Hardware Catalog, the CeresFlows HUB, and the road ahead.

CeresFlows is not just a piece of software that runs on your computer. It is a living ecosystem — a growing body of knowledge, tested hardware, and shared experience that gets more valuable with every grower who joins it. Three pillars make this ecosystem real: a built-in Hardware Catalog that tells you exactly what works and how to wire it, a Community HUB on ceresflows.com where anyone can share and download templates, and an AI layer that lets intelligent agents read and act on your system data.

🌐 The Ecosystem — Hardware Catalog, Community HUB & AI Gateway Tour

1 / 12

‹ ›

HARDWARE CATALOG 📚 Hardware Catalog Directory — Searchable Multi-Protocol Library

🔍 Click image to expand in Lightbox

Hardware Catalog — 42 Devices, Zero Guesswork

Every automation journey starts with a hardware question: Will this sensor work? Which pin do I use? Is there a wiring diagram? The Hardware Catalog answers all three before you even open a terminal.

Accessible from the sidebar at Hardware → Catalog, the page presents a searchable, filterable table of every device that has been tested and integrated with CeresFlows — currently 42 entries covering sensors, controllers, I²C/RS485 extensions, and accessories. Filter by type (Sensor / Controller / Extension / Accessory) or by role (EC, pH, Distance, PAR, Temperature, and more). Search by name, model number, or tag.

Click any row and a full detail dialog opens. Five tabs give you everything you need to go from purchase decision to working connection:

The Catalog is entirely local — static files embedded in the Go binary, no internet required. The cf_template_id in each catalog entry matches the device template already in the system, so the Catalog is not just reference documentation — it is a direct pointer to the exact configuration the system will use when you connect this hardware.

The HUB — Shared Knowledge, Ready to Import

The Hardware Catalog tells you what hardware works. The HUB tells you what other growers have already built with it.

Available at ceresflows.com → Hub, the HUB is a public community library — open to everyone, not just CeresFlows users. Anyone can browse, and anyone can contribute. The content is organized into three categories that map directly to what you build inside CeresFlows:

Each entry has a Download button. The downloaded file is a standard CeresFlows export format — the same format the system uses for its own Backup and Template export features. Open CeresFlows, import the file, and the template is immediately available in your system.

The philosophy is straightforward: if you want to buy a certain sensor and someone in the community has already built and tested a template for it, you should not have to start from zero. Not because it is difficult — but because time is finite and the collective knowledge of a community is worth more than any individual grower working alone.

AI Vision — Intelligence That Knows Your System

The last piece of the ecosystem is the one that points forward: a built-in AI layer that gives intelligent agents structured, real-time access to everything CeresFlows knows about your operation.

This is not a chatbot bolted onto the side. It is a proper protocol layer — built on the Model Context Protocol (MCP), the standard emerging as the common language between AI models and the software systems they work with. Any MCP-compatible AI client can connect to your local CeresFlows server and immediately gain access to 11 tools organized into two tiers:

Configuration lives in Settings → AI Settings, organized across four tabs: General Settings (provider, model, API key, system capabilities toggles), Agent Gateway (the REST API for external agents — auth token, rate limits, permission level, live audit log of every call), Actions & Automation, and Quick Questions.

The Agent Gateway is the bridge for external agents that prefer standard HTTP over the MCP protocol. It exposes the same 11 tools via a conventional REST API with Bearer token authentication, per-IP rate limiting (60 requests per minute by default), and three permission tiers: read (observe only), readwrite (observe + control), and admin (full access). Every tool call — successful or not — is logged to SQLite with the agent ID, client IP, tool name, arguments, duration, and result. The audit log is visible directly in the UI.

What CeresFlows has built is not an AI feature — it is an AI surface. A well-defined, protocol-compliant interface that any sufficiently capable AI model can connect to and immediately understand your greenhouse: what sensors exist, what is running right now, what has happened over the past 90 days, and what is consuming the most water. The model does not need to be trained on CeresFlows. It needs the tools — and the tools are ready.

Always Current — The Update System

One last piece of the ecosystem that quietly works in the background: the update system. At startup, CeresFlows checks ceresflows.com for a newer version. If one exists, an amber badge appears in the header. Click it — the License & Status dialog opens, shows the current and available version, and provides a platform-aware download link (Windows or Linux/RPi). A What's New button opens the full interactive changelog viewer — every release, every feature, scrollable and searchable.

🔄 System Status & Interactive Changelog

1 / 2

‹ ›

SYSTEM STATUS 🔄 License & System Status Modal — Version & Resource Footprint

🔍 Click image to expand in Lightbox

No account required. No telemetry. The check is a single HTTP GET to a JSON file on the website. If it fails — DNS error, no internet, anything — the system logs a diagnostic message and continues normally. Your greenhouse does not need the internet to run. The update check is a convenience, not a dependency.

Next: What It Saves You — the real return on the time you invest in setting this up.

Let's be honest for a moment. After reading everything in this document, a reasonable person might say: "This all sounds impressive — but I already have a timer. And a smart plug. I can turn my pump on at 7 AM and off at 7:15. Why do I need any of this?"

They're not wrong. A timer works. A smart plug works. For simple tasks, done the same way every day, they're perfectly valid tools. No one is here to convince you otherwise.

But let's look at what happens the moment your needs get slightly more complex. Because that moment always comes.

Timer. Smart Plug. CeresFlows.

These are not competing products in the same category. They are three different answers to three different questions.

Precision Is Not a Luxury

Consider something small: you want your pump to run for exactly 3 minutes and 35 seconds. With a mechanical timer, that is physically impossible — the dial simply does not have that resolution. With most smart plugs, it depends on the app, the cloud server response time, and the Wi-Fi latency at that moment. You get "roughly 3–4 minutes" on a good day.

CeresFlows executes to the second. Every time. Because the logic runs locally, on your hardware, without waiting for a server in another country to receive your request and send a command back.

"Why Do I Need All These Features?"

Fair question. CeresFlows has a lot of modules. Analytics, calculated indices, fertilizer lab, remote monitoring, flight recorder, smart advisor — it can feel overwhelming. And the honest answer is: you don't need all of them today.

Most software in this space is built to justify a price tag. Features are added to look impressive on a spec sheet, designed for specific proprietary hardware, and locked behind expensive subscriptions. CeresFlows was built the opposite way — every module exists because someone had a real problem that nothing else could solve.

Of course it has bugs. Of course not every module will appeal to every grower. That is not the point. The point is that when you need something, it is already there — waiting — instead of you having to switch to a different platform, learn a new tool, or write code.

The Automation Pyramid — Start Where You Are

You do not need to reach Level 3 to get value. Every level is complete on its own. But here is what happens in practice: you start at Level 1, you water automatically, you save an hour a day. Then one morning you wonder — "What if I added a moisture sensor?" One module leads to the next. Not because a marketing funnel pushed you there, but because you saw the value yourself and you wanted more.

The Time Math Nobody Does

Nobody sits down and calculates the hours they spend on routine growing tasks. It's background noise — always there, invisible. But consider this:

That time does not vanish into thin air. It goes somewhere real: a longer morning with your family, an afternoon expanding to a second greenhouse, an evening where you are not mentally calculating whether the reservoir ran dry. Each module you activate saves a few more minutes. The savings compound silently, every single day.

What You Actually Get Back

On Skepticism

It is natural to be skeptical of something that promises this much. Most software in this space overpromises. Features exist to impress, not to solve problems. They are built for specific brands and work perfectly — until you need something slightly different.

CeresFlows was not built to impress. It was built because the builder needed it and nothing else existed. That is why the feature list feels like a checklist of real problems — because it is. Not every feature will matter to you today. Some you will never use. But the ones you do use, you will reach for every single day.

You don't have to believe it. Start with one relay. One schedule. Five minutes of setup. See what happens to your mornings.

Next: Start Your Journey — where to download, what is free, and how to begin.

Start Your Journey

The honest conversation about value, cost, and where to begin.

Before we talk about anything else, let's have the conversation that every grower eventually has with themselves: Is this worth it? Will it cost me money? And is that fair?

These are good questions. Healthy questions. The kind a careful grower asks before making any decision. So let's answer them honestly.

CeresFlows costs something. That is true, and it would be dishonest to pretend otherwise. A system built over years, improved every single day, supported and maintained — it has to be sustainable. But the question worth asking is not whether it costs money. The question is whether what you lose without it is worth more than what you pay for it.

For most growers, the math is simple: one prevented harvest failure more than covers a full year of the most advanced plan available. The rest is profit — in time returned, in sleep recovered, in plants that don't need to be replaced.

With that said — let's talk about what CeresFlows actually costs. And you may be surprised.

Start With Nothing. Risk Nothing.

Every copy of CeresFlows installed on a machine is bound to its unique hardware fingerprint (HWID) and requires a license.key file — including the 30-day trial and the Free Forever tier. There are no hidden cloud accounts, no remote phone-homes, and no telemetry tracking. Every installation validates its cryptographic license strictly on your own hardware.

When you first install CeresFlows, you do not start with an artificial demo. You can request a 30-day full-access trial license — every module, every feature, and generous slots to test your entire setup — for €0, with no payment required.

No credit card. No cloud sign-up. No commitment. Download the executable, launch it to obtain your HWID, receive your license file, and see with your own eyes what CeresFlows can do in your grow room. After 30 days, you choose: continue with an expanded plan, transition seamlessly to the permanent Free tier, or step away. Your database and configurations always stay in your hands.

Free Forever — And More Powerful Than It Sounds

After the trial, CeresFlows has a permanent free tier. Not a time-limited trial, not a "free" plan that expires. A real, functional, forever-free operating mode.

To put it plainly: 2 devices + 1 flow replaces a mechanical timer, a smart plug, and gives you something neither of them can do — logic. Water when the substrate is dry, not when the clock says so. Turn on the fan when temperature exceeds 28°C and humidity is above 75%. Do both, in one flow, with one controller.

For a grower with a single growing space, this is often everything they need. Forever. At zero cost.

The Swap — Why Two Slots Is More Than It Seems

If You Need More — You Pay for Exactly That

Not everyone stays on the free tier. A serious small farm needs more sensors, more flows, maybe a second controller for a second zone. For them, CeresFlows has paid plans — structured around one simple principle: you pay for capacity, not for features.

Every plan includes the same automation engine, the same flow editor, the same safety architecture, the same notification system. The only difference is how many controllers, devices, and flows your installation can hold at once. A hobbyist with 9 plants pays for 9 plants. A commercial operation with 40 sensors pays for 40 sensors. That is the only fair way to do this.

Analytics Modules — Own Them Once

The analytical modules — Journal, Resource Tracking, Sensor Lab, Insight Engine — are a separate category entirely. They are not part of any monthly plan. They are not a subscription. You buy them once, and they are yours forever.

Every license renewal, they are included automatically — no additional charge. Buy once. Use indefinitely. This is intentional: data tools are about building long-term knowledge about your plants, your substrate, your environment. That kind of investment should not require a recurring payment to access your own history.

Getting Started — Six Steps

Every installation of CeresFlows — whether a 30-day trial or the Free Forever plan — runs strictly on your own hardware and requires a local license file cryptographically tied to your machine. There is no cloud telemetry and no background phone-home. The entire setup takes just a couple of minutes:

Where to Go from Here