Platform
The same software runs a one-zone room and a four-zone glasshouse. What changes is the configuration, not the product.
Most climate computers assume a reliable link to somewhere else. Ours assumes the opposite: the greenhouse must survive on its own, indefinitely, without anyone noticing.
Architecture
Settings are written centrally, where a grower or agronomist can reason about them carefully. Execution happens in the greenhouse. Protection sits below execution, in the panel.
Each layer can lose the one above it and continue doing its job.
A cultivation strategy is written once, reviewed, and then issued to a house. It covers what the climate should be doing through the day and through the season, and under what conditions it should behave differently.
Changes are deliberate. A revision is prepared, checked and issued as a whole — not typed into a live controller at the moment someone thinks of it. Every issued version is retained, so it is always possible to see what the house was told to do on any given day, and who told it.
Instructions are cryptographically signed. The greenhouse will not act on a set of instructions unless the signature verifies, which means a corrupted or tampered file is rejected rather than executed.
Control runs on hardware inside the greenhouse, on a fixed, repeating cycle. On every cycle the system reads its sensors, compares them with the strategy currently in force, and drives the equipment accordingly.
The cycle does not depend on anything outside the building. If the connection drops, the current strategy stays in force and the house keeps being managed exactly as it was a minute earlier. When the link returns, history is reconciled and any newer strategy is taken up.
This is the substantive difference from a cloud-first product. Connectivity changes what the house can be asked to do next. It never determines whether the house is being looked after.
Beneath the software sits the control panel, and the protective logic lives there. Limits, interlocks and safe states are enforced by the panel itself, not by the application above it.
That means the protective behaviour holds while software is stopped for an update, while it is being replaced, and in the event that it fails outright. It is deliberately the least clever part of the system and the hardest part to stop.
More on how failures are handled →
Every control action is stored with the readings that produced it and the reason it was taken. Not a log of events, but an account of decisions.
When something goes wrong in a greenhouse, the argument is usually about what actually happened. This removes the argument. You can look back at any moment and see the state of the house, the strategy in force, the decision taken and why.
AgriKoda connects at the electrical control layer. In practice that means equipment which is switched by contactors, and movable equipment fitted with position feedback — vents, screens, fans, pumps, valves and similar.
It is not a universal adapter, and we will not pretend otherwise. Some equipment on a site can be brought under control as it stands, some needs work first, and some cannot be reached at all. Establishing which is which is the purpose of the site assessment, and you get the answer in writing before anyone commits to anything.
We build the control layer and the instrumentation it depends on. We do not manufacture or resell greenhouse equipment — vents, screens, fans, pads and pumps come from specialists, and we specify what is required. Agronomy stays yours: you set the strategy, the system carries it out faithfully and reports back.
