Safety & reliability
A climate system is judged on its worst hour, not its best month. These are the failures we design for and how the house behaves in each.
In a temperate glasshouse, a controller that stops responding is an inconvenience someone deals with in the morning. Under full solar load in the Gulf, it is a crop-loss event measured in minutes.
Most climate control literature, and most of the equipment built on it, comes from northern Europe. There, the dangerous failure is losing heat. Shut things down, close things up, and a house will usually sit safely until someone arrives.
In extreme heat the dangerous failure is the opposite, and so is the correct response. A house that closes itself and stops ventilating is not failing safe; it is failing lethally. Our safe states are built the other way round — toward getting heat out of the building and keeping it out, and holding that condition without further instruction.
This is not a refinement of a temperate default. It is a different default, and it is the reason we did not simply adopt an existing control philosophy.
The house continues on its current strategy indefinitely. No degradation, no timeout that eventually stops control, no dependence on a remote service being reachable. The loss is recorded and raised, but the crop is never waiting on a network.
Protective limits and interlocks are enforced in the control panel, below the software layer. If the application stops, hangs or is mid-replacement, those limits stay in force. Equipment that must not run together still cannot. States that must hold, hold.
A reading that is impossible, frozen or absent is treated as a fault rather than as data. The system does not act confidently on a measurement it has reason to distrust, and it does not quietly substitute a plausible number. The fault is raised and the affected control moves to its protective position.
Equipment returns to a defined state on restoration rather than to whatever position it happened to be in. Nothing depends on someone remembering to check a screen or a vent after an outage.
It is not enough to notice a problem eventually. A deviation is detected within a fixed window, and an alarm is dispatched within a fixed window after that. Both are set so that the total elapsed time sits well inside the period in which a crop can be lost to a ventilation failure in summer conditions.
The exact intervals are set for your house and stated explicitly in your design documentation, then proven at commissioning.
An alarm that only exists on a screen in an empty office is not an alarm. Conditions that require a human are raised locally at the house and dispatched to the people responsible, in the language they work in.
Each control action is stored with the readings that produced it and the reason it was taken. After an incident you are not reconstructing events from memory and timestamps; you are reading an account of what the system saw, what it was told to do, and what it did.
This matters commercially as well as technically. It is the difference between a supplier who says the equipment was fine and an operator who says it was not, and a record that settles it.
Every behaviour on this page is written into your design documentation with its specific values for your house, and shown working in front of you at commissioning. You watch the connection get pulled. You watch the software stop. You watch the house carry on.
That is the point at which a control system stops being a promise and becomes something you can rely on.
