What agricultural IoT has to solve in a controlled growing room
Agricultural IoT is often sold as a sensor problem: connect the room, read the temperature, draw a chart. In a controlled growing operation that framing stops early. A growing room is an enclosed environment where temperature, humidity, light and CO₂ are deliberately managed (OSU CFAES), and it produces four kinds of information. A system that carries only one answers very little — that is the problem agricultural IoT has to solve before choosing a platform, an approach or a first sensor.
Four kinds of information, not one stream
Climate measurements. What the room is doing now: temperature, humidity, light, ventilation state. Automatic mushroom climate controllers, for example, monitor temperature, humidity and CO₂ continuously (Fancom) — and in our experience such readings are often read without their context.
Equipment state. What the room is doing about it. Ventilation fans, heating and humidification equipment act on the climate continuously; which device is running, and whether a controller was left in manual, is part of the record. A measurement without the equipment state behind it cannot be explained.
Process records. What people did: feeding, weighing, cleaning, treating. In our experience it is the least digitised part of a growing operation — and the part that explains outcomes.
Batch identity. Which batch, which stage, which room, which day. Without it, a number is only a number.
The limits move, and that is normal
A growing operation is not steady. Suitable ranges differ between species and crops (Fancom), and the optimum temperature changes as a plant grows from seedling to maturity (Greenhouse Management). In our experience, limits also move between rooms and seasons. A system that treats one fixed threshold as truth for every room and stage produces alerts that are technically correct and practically useless. A limit belongs to a room, a stage and an agreed range, and somebody must own the decision to change it.
Measurements themselves carry conditions: accuracy depends on the operating range, and a reading can be wrong without looking wrong — hence the adjustment and calibration procedures manufacturers specify (Rotronic/PST).
Failure looks different in every operation
A sensor that stops reporting. A controller that fell back to manual. A log entry nobody filled in. A room that was never connected at all. In a general IoT project these read as edge cases; in a growing operation they are ordinary events, which a system must show — visible, dated and explainable — not hide behind a chart that looks complete. This is Manna's operating experience and design intent, not a benchmark.
What a useful system carries
Ask four questions of any platform before the first sensor is bought. Can it hold a measurement together with the room, stage and batch it belongs to? Can it keep the equipment state next to the measurement? Can it record what a person did? Can it show missing data as missing?
A system that answers all four can be configured around the operation; one that answers only the first is a room monitor, and the rest stays with you as manual work.
Where to start
Start with one question the operation cannot answer from its own records — what the climate actually did during a stage, or why a room drifted — and design the answer before choosing hardware. Hardware can be changed later. Context cannot.
Manna MIND grew out of this problem in our own black soldier fly production, where climate, equipment state, process records and batch identity are carried together. To see the approach, the MIND Agentic Server page describes how it brings climate and equipment data together with process records, batches and growth cycles, configured around an existing MIND installation or a growing system Manna integrates in a scoped project.
Prepared with AI assistance for Manna Insect Oy.