IoT-ready growing equipment: what a manufacturer should hand over

What should an equipment maker hand over at design time so an IoT integration of growing equipment is repeatable instead of a one-off project? Six things: interface documentation, test access, control authority, failure states, change behaviour and identity. All six are manufacturer decisions, best made before any customer asks.

Published protocol standards give an integrator part of the foundation — Modbus is a published application protocol (V1.1b3) with function codes, serial-line and TCP implementation guides and a security protocol, and BACnet is the building-automation data communications standard published as ANSI/ASHRAE 135 and ISO 16484-5 — but a protocol standard does not describe your machine. The device-specific handover does.

Interface documentation

Document which values exist, what each means, its unit and range, its register address and data format, and which are read-only versus writable, with the read/write function codes. Real growing-relevant equipment ships this way: a Condair addendum manual for its DL II, ME II, RS II, RO-E and Vita humidification and evaporative cooling equipment — cited purely as an illustrative example of a manufacturer handover document — lists per-model register tables with each value's name, range, address, format and read/write function codes, plus status and error code enumerations, and states the settings an integrator needs: baud, parity, addressing, topology and timeouts.

Test access

Provide a test unit, or a documented way to exercise the interface without touching a production room. The Condair manual again illustrates the pattern: it includes a written communication test procedure — verify RTU and TCP settings, read out registers — so the interface is proven on a bench, not on a batch.

Control authority

State which values may be written from outside the controller, who owns each one, and what the equipment does when a write arrives — or stops arriving. The Condair manual shows a documented answer: remote enable and demand values arrive through defined registers, and if the control signal is not updated within the configured timeout, a warning is raised and the unit stops instead of running on its last value.

Failure states

Document behaviour when the network drops, a sensor fails, a setpoint is out of range or the machine restarts. A related principle applies to what the integration sees: a returned heartbeat is not proof of current data — connectivity, data freshness and backlog are distinct states, and documentation that distinguishes them makes the states diagnosable, not mysterious.

Change behaviour

Version the interface document and say what changed between revisions. The Condair document carries a revision code on its title page; an integrator needs to know which revision a register table describes. Firmware and model revisions belong there too.

Identity

Decide how a device is labelled — serial numbers, hostnames, nameplate fields — so the record of a room stays attached to the right machine when units are commissioned, replaced or moved. The Condair controller, for example, exposes a hostname derived from its serial number.

Written once, reused on every project

A documented interface is written once and reused — the next room, customer or revision starts from a known state. An undocumented one costs every project: the supplier keeps the knowledge while the customer carries the schedule.

On the integrator's side of the table, the reading-side interface documentation checklist covers what to verify in a document before coding starts. If you build growing equipment — insect rearing, mushroom or greenhouse systems — and want your machines to connect without surprises, Manna can discuss a scoped integration project around your existing or new growing system, starting from exactly these handover decisions.

Prepared with AI assistance for Manna Insect Oy.