Smart Irrigation System Design for Farms with Unreliable Internet
A smart irrigation system for a farm with unreliable internet should have a documented way to execute approved watering locally, show when information is stale, and recover without replaying inappropriate commands. Whether a particular system provides those functions depends on its controller, field network, software and configuration. An “offline” label alone does not establish what will keep working.
This guide provides a failure map, a local-recording calculation and a commissioning exercise for farm irrigation. The examples are proposed design and acceptance checks, not reported IrriNex installation results. Establish the hydraulic limits first using the drip irrigation design guidelines; then decide which operations may continue when communication disappears.
What does offline smart irrigation actually mean?
Separate the ability to view information, edit a program, execute irrigation and preserve records. These are different functions. A phone can display yesterday’s settings while the controller is carrying out a different program. A saved edit may exist only on that phone until someone synchronizes it.
| Function | What it means | Evidence to request |
|---|---|---|
| Offline viewing | Previously downloaded information remains visible | Last connection time and clear stale-data labels |
| Offline editing | Proposed program changes can be saved for later transfer | Pending-change list and synchronization confirmation |
| Local execution | The field controller performs an approved program without the internet link | A supervised disconnected test covering both start and stop |
| Local recording | Events and measurements are retained before later upload | Storage limits and a complete recovered record |
Rain Bird’s ESP-BAT-BT technical specification describes offline access to last-known settings and edits that synchronize when a user returns within Bluetooth range. That is a precise example of offline viewing and editing. It should not be read as a claim that an unsynchronized edit has reached a valve.
Netafim’s GrowSphere overview lists offline and remote control. Its overview does not specify every outage duration or recovery sequence. WiseConn’s article on agricultural productivity describes internet-connected access and field mesh devices, without establishing a detailed offline guarantee. Ask for the selected model’s manual and a demonstration of the required behavior.
Draw the connections that can fail
Mark the controller, gateway, field nodes, sensors, pump controls and operator’s phone on one diagram. Draw internet communication separately from local radio or wired connections. Then mark the power source for each device. A lost mobile-data connection is not the same event as a dead field-node battery.
NIST’s operational technology security guide addresses the distinct performance, reliability and safety requirements of systems that monitor or control physical processes. It provides a framework for reviewing dependencies, not a certification of any irrigation controller’s offline behavior.
| Interruption | What may be affected | Question for the test |
|---|---|---|
| Internet or cloud connection | Remote commands, weather updates and off-site reporting | Does the approved local program still execute? |
| Gateway-to-field link | Commands or feedback for the disconnected nodes | Which nodes retain control, and which are unavailable? |
| Sensor communication | Fresh measurements used by decision rules | How does the system identify and handle stale input? |
| Controller or gateway power | Processing, local communication and recording | What state remains, and how does startup recover? |
| Pump power or water supply | Actual delivery, even if electronics remain online | How is an unfulfilled watering command detected? |
Do not assign a universal open or closed state to a disconnected valve. Its behavior depends on the complete actuator and hydraulic arrangement. The useful deliverable is a site-specific response table identifying the affected equipment, permitted action and person responsible for intervention.
Specify what the controller must store locally
Request confirmation that the approved program is stored where it must execute. Record its version, active dates, block assignments, start conditions, stop conditions and permitted overlaps. Confirm the controller’s clock, time zone and handling of seasonal time changes. A schedule stored without a dependable time reference may start at the wrong moment after an interruption.
UF/IFAS’s guide to residential irrigation timers identifies basic settings: clock, permitted days, start times, zones and run times. Use these as a minimum program inventory; its residential guidance does not establish farm-controller storage or outage guarantees.
Also identify dependencies: a cloud weather update, remote soil reading, volume-meter pulse or upstream permission can change whether a program is allowed to run. Ask which dependencies remain available locally and what happens when one is missing. Save an approved configuration export and a readable operator copy; neither should be confused with proof that the controller has received the latest version.
Agree the response before communication is lost
For each block, choose an agronomically and hydraulically appropriate response with the responsible designer: continue a bounded local program, postpone the next start, or require an operator decision. State the conditions and the maximum permitted unattended interval. These are project settings to establish, not universal time limits for all crops.
A block on a well-understood schedule may have a different fallback from a substrate crop using frequent sensor-dependent pulses. Fertilizer injection may also need a different response from water-only irrigation. Define how injection is prevented when required flow or other interlocks are absent. A network workaround must not bypass protections built into the irrigation and fertigation design.
Rivulis’s automation module separates standalone valve control from advanced systems involving field units, pumps, filtration and fertigation. Use that distinction to check the whole operating chain. Keeping one controller alive does not establish that every dependent component can continue.
Handle stale sensor data explicitly
Every decision-critical reading should have a measurement time and a freshness status. A chart point uploaded after reconnection may be an old measurement, not a current observation. Distinguish the time a sensor sampled the field from the time the server received it.
Define a freshness limit for each application and an approved response when it is exceeded. The limit should reflect crop conditions, the measurement interval and how the value controls irrigation. A soil sensor used for trend review and a flow signal used to permit injection have different consequences when unavailable. Do not carry forward a plausible-looking number indefinitely.
Before re-enabling a sensor-driven rule, verify that new readings arrive, units remain correct and the signal behaves plausibly after watering. Compare uncertain soil readings with field observations. Do not increase irrigation merely because an old dashboard value still looks dry.
Size local recording and preserve useful logs
Ask what is stored: program changes, valve commands, acknowledgments, measured flow, alarms and manual interventions may have different retention rules. A log saying “command sent” is not a measurement of water delivered. Require enough information to reconstruct the event sequence after reconnection.
For an illustrative recording budget, sampling every 5 minutes produces 24 × 60 ÷ 5 = 288 sampling times per day. With 12 channels, that is 288 × 12 = 3,456 individual values per day, or 24,192 values over 7 days. This arithmetic is not a storage-size specification: timestamps, status fields, events, encoding and memory management add requirements.
Have the supplier state the supported recording interval, retention capacity and what happens when memory fills. Check whether older data are overwritten and whether gaps are visibly marked. After upload, retain original measurement times and avoid counting repeated transmissions as additional irrigation events.
Plan alarms that can reach someone
List the path of each alarm from field device to operator. An email or app notification that depends on the failed internet connection may not arrive promptly. A second communication option provides useful redundancy only if its power and connectivity dependencies are understood.
Define who checks the farm when remote visibility is lost and how a local operator records an intervention. Keep the equipment labels, contact list and isolation procedure available without cloud access. For existing valves, the irrigation valve maintenance checklist helps organize physical checks; remote status should complement those observations.
Run a supervised outage acceptance test
Plan the test with the installer on a suitable block and within an approved watering window. Keep an operator present and preserve the existing configuration. Test communication loss separately from power loss so the result identifies the actual dependency. Use the manufacturer’s test procedure for equipment isolation; do not improvise disconnections around operating electrical equipment.
- Establish the baseline: record program version, time zone, last synchronization, initial meter total and expected block sequence.
- Interrupt the internet path: use an agreed method that leaves the controller and required field equipment powered.
- Observe local execution: verify the scheduled start, permitted pump and valve sequence, and scheduled stop in the field.
- Check information quality: confirm that remote displays identify stale data and that local records continue as specified.
- Test a pending edit: prepare a harmless, approved future change and verify whether it remains pending, is rejected or becomes active after synchronization.
- Restore communication: check acknowledgments, original timestamps, duplicate records and the active program version.
- Review recovery: reconcile measured water, canceled or missed starts, manual actions and the next approved irrigation decision.
A worked recovery example
Consider a fictional test in which internet access is interrupted at 09:10 and restored at 12:40. A verified local program starts a block at 09:30 and stops it at 10:10. The communication outage lasts 3 hours 30 minutes, while irrigation runs for 40 minutes. Those durations must not be confused when reviewing the report.
If the illustrative flow is a constant 18 m³/h, the expected volume is 18 × 40 ÷ 60 = 12 m³. Compare that estimate with the actual meter difference; variations in real flow can change the result. A remote chart with no live points during the outage does not prove that no water was delivered.
On reconnection, confirm that the 09:30 start is not issued again simply because the cloud lacked its acknowledgment. Reconcile pending edits with any local operator changes before applying them. A missed irrigation should prompt a new decision based on soil, crop and system conditions, rather than automatic doubling of the next run.
Choose the approach around the farm’s working routine
For a regularly visited block, a documented local schedule with on-site program access may meet the operating need. For dispersed blocks, assess local execution together with field-link supervision, useful logs and a practical response to lost visibility. For intensive production, establish shorter review and intervention arrangements where justified by the crop and root-zone conditions.
Compare quotations against the same outage scenarios. Include installation, required subscriptions, communication service, battery or backup maintenance, training and fault-response visits. Ask the supplier to identify which functions remain available if a communication subscription ends. A feature available in a demonstration account is not enough without the corresponding model and service terms.
Questions about irrigation without internet
Will a smart irrigation system water when the internet fails?
Only if its local execution and required dependencies support that behavior. Confirm it for the proposed model, configuration and failure scenario.
Does offline operation also protect against power cuts?
No. Power continuity is a separate requirement for the controller, communication devices, actuators and pumping equipment.
Does saving a change offline update the field controller?
Not necessarily. Verify transfer, acknowledgment and the active program version before treating the change as implemented.
For a project discussion, bring your block layout, outage history, fallback decisions and completed acceptance table to the IrriNex team. Use the irrigation timing controller and multi-station controller pages as starting points for a specification request. Confirm local-storage and recovery functions in the exact proposed equipment; these links do not establish offline capability.
