The Farm's Sensor Network

The technology choice is broadly appropriate, but the details need scrutiny.

• Range: long-range low-power networks are designed for exactly this: many small devices sending little data over kilometres. A 3 km paddock is within the intended reach, though terrain and vegetation affect it, so a site survey or a repeater may be needed.
• Power: battery sensors sending occasional readings can last a long time, which suits paddocks without mains power. The design must avoid frequent transmissions, which would drain batteries and create maintenance trips.
• Connectivity: the gateway gathers data locally, so sensors do not each need mobile coverage. However, remote monitoring and software updates depend on the farm's broadband. With one unreliable connection, the system must keep working locally when the internet is down, and should buffer data to send later.
• Data volume: soil moisture readings are tiny, so bandwidth is not a constraint. The weak link is the single broadband line, not the sensor network.

The proposal is sound in principle; the risk sits in the gateway-to-internet link and in maintenance access to 40 devices spread over 60 hectares.

Design for graceful failure, because the worst case is valves stuck open or closed when water matters most.

• Fail-safe valve behaviour: decide explicitly whether a valve should close or stay as it is if it loses contact with the controller. A valve stuck open can drain a tank; stuck closed can cost a crop. The choice depends on water supply and crop, and should be documented.
• Local control retained: the gateway should run irrigation rules locally, so a broadband outage does not stop watering. Only remote viewing should depend on the internet.
• Manual override: every valve needs a physical override that a worker can operate without an app. This is essential given that two workers are not confident with technology.
• Alerts and limits: notify the owner of sensor dropouts and unusual valve states, and cap how long any valve can run continuously.
• Monitoring by people: a daily walk or a simple gauge check during forecast heat, so the system is not the only safeguard.

The judgement is that automation should reduce labour, not remove the fallback. A system that fails safe and can be overridden by hand is acceptable; one that fails silently and depends on an unreliable connection is not.

Adoption fails if the people opening valves every day do not trust the system, so their involvement is a design input, not an afterthought.

• Involve them early: ask what they check now and what would make them distrust an automated valve. Their knowledge of paddocks, slopes and problem spots is data the vendor does not have.
• Start small: instrument one paddock and run it alongside manual irrigation for a season. Compare water use and crop condition, and let the workers see the results rather than hear a claim.
• Design for their workflow: a physical override, a clear indicator on each valve, and alerts in plain language. Avoid requiring a smartphone app for routine tasks.
• Train on the real system: short sessions in the paddock, with the workers operating valves themselves, and a named person to call when something looks wrong.
• Share ownership: let one of them be responsible for the weekly sensor and battery check, with a simple checklist.

This changes the plan: a staged rollout over a season, with a decision point after the trial, is better than installing 40 sensors at once. The cost is slower adoption; the benefit is a system the workers will actually use and maintain.