A safety envelope belongs below the automation, not inside it

Ask a supplier whether their control is safe and you will usually hear about alarms. An alarm tells someone that something has already gone wrong. A limit stops the command before it reaches the equipment, and it has to work when nobody is looking at a screen.

The failure that looks like normal operation

A sensor reporting nonsense is easy to catch. The harder case is a control loop doing exactly what it was told, against a target that should never have been accepted: a recipe stage with the wrong EC, or a copied zone whose dosing interval is ten times too short. Every component behaves as designed and the crop still suffers.

If the logic that sets the target also decides what counts as safe, the mistake passes both tests at once. That is the case for putting hard limits beneath the automation, in a guard every command passes through, rather than inside it.

Where BeeGrow puts the limit

In BeeGrow AI, PID control and actuator tests send their commands through a separate safety guard before anything is published to the equipment. It holds bounds for temperature, pH, EC, CO₂, water level, dose length, the gap between doses and doses per hour. A site can tighten those bounds. No recipe, schedule or model output can loosen them.

Not every breach gets the same response. A dose that arrives too soon after the last one, or would take the hour over its count, is refused. A dose that is merely too long, or a heating command that is too intense, is cut back to the limit and then sent. Refusing a slightly long pulse helps nobody; refusing a dose into a root zone that is already out of range is the whole point.

A limit needs a reading

An environmental limit only works if there is a reading to compare it with. The guard checks the latest reading held for the zone, and when that reading is missing the check has nothing to act on. For manual tests we close that gap in the riskiest case: a test that would start a pump or open a drain is refused if the zone has no water-level reading.

Software also cannot prove that a valve moved or a pump stopped. Physical feedback, hardware interlocks and what the controller does when it loses its connection still have to be specified and tested on site. The guard sits alongside those, not in place of them.

What gets written down

When the guard refuses a PID command, the refusal goes into the control log with its reason, so you can see how often the automation asks for something it should not. Actuator tests are audited when they are sent, and an emergency stop leaves an audit record listing the zone’s configured actuators. Scheduled lighting changes only reach the application log for now, so the record is not yet complete for every command path.

An emergency stop takes the zone out of automation and sends stop commands to its configured dosing, water, CO₂ and HVAC actuators, with ventilation commanded to full. Lights are left as they are, so the crop is not plunged into darkness, and humidifiers are not part of the sequence. It is still a software command, so it belongs alongside a physical stop rather than instead of one.

What to ask any supplier

• Are there hard limits outside the control logic, and where exactly do they sit?
• Which breaches are refused, and which are capped and then sent anyway?
• Do manual and test commands go through the same checks as automated ones?
• What happens to a check when the reading it needs is missing?
• What does the equipment do when the network or the control service goes away?
• Is a refused command logged as a refusal, or does it just quietly not happen?

Our own answers are on the closed-loop control and safety page, and the full set of questions is in the evaluation guide.