Irrigation & Site Control
Why a Commercial Irrigation Controller Should Work Offline
Understand which irrigation functions should remain local, how cloud services add value, and how controllers should handle network loss, queued changes, and recovery.
Internet access is useful for remote irrigation management, but the property still needs predictable behavior during an outage. A local-first design keeps time-sensitive schedules, limits, interlocks, and field service close to the equipment while using cloud services for fleet visibility, reporting, coordination, and support.
Key takeaways
- ✓Define outage behavior for every essential function before deployment.
- ✓Keep schedules, manual stop, maximum runtimes, and critical field rules available locally.
- ✓Queue remote changes carefully and reject stale or conflicting commands after reconnection.
- ✓Test power loss, network loss, clock behavior, storage limits, and recovery with the actual field hardware.
Decide what must remain at the property
Local responsibilities commonly include schedule execution, manual start and stop, maximum runtimes, output interlocks, pump and master-valve sequencing, sensor inputs, and a safe response to abnormal conditions. The exact list depends on the property, but it should be written and tested rather than assumed.
A technician should have a defined way to see status and place equipment in a safe state without depending on a remote application. Local access still needs permissions, auditability, and protection against casual or unauthorized changes.
Use the cloud for coordination and history
Remote services are well suited to portfolio views, reports, weather data, notifications, role administration, configuration review, software delivery, and support diagnostics. These functions can improve operations without becoming the only authority capable of opening or closing a physical output.
The interface should make connectivity state visible. Staff need to know whether they are viewing current field state, the last synchronized state, or a requested change that has not reached the property.
- Timestamp field events at their source and preserve time-zone context.
- Show the last successful controller contact and software version.
- Assign expiration times to commands that should not execute later.
- Keep an audit trail of who requested, approved, delivered, and executed a change.
Reconcile safely after connectivity returns
A reconnection is not permission to replay every queued action. Manual-run requests, stops, configuration edits, and schedule changes have different lifetimes. Commands should be idempotent where possible, carry unique identifiers, expire when stale, and be checked against the controller's present state before execution.
Conflicting edits need a defined authority and review path. The system should not silently overwrite a technician's local safety change with an older remote configuration merely because the cloud reconnected later.
Test the failures, not only the features
Disconnect the network before a schedule, during a run, and while a remote change is pending. Interrupt power and verify clock recovery, stored configuration, output state, event history, and startup sequencing. Fill or restrict local storage and confirm the controller fails visibly instead of losing history without warning.
Repeat recovery tests after meaningful software, networking, or field-equipment changes. Offline capability is a behavior demonstrated over time, not a label established by one successful demonstration.
Frequently Asked Questions
Direct answers
Will an offline irrigation controller still follow its schedule?
A properly designed local-first controller should have documented local schedule behavior. Verify the specific product, configuration, clock, sensor, and safety dependencies during acceptance testing.
What happens to remote commands sent during an outage?
Commands should be uniquely identified, queued only when appropriate, assigned expiration rules, and validated against current field state after reconnection. Stale manual actions should not execute unexpectedly.
Does local-first mean remote irrigation management is unnecessary?
No. Remote management provides valuable fleet visibility, reporting, notifications, coordinated configuration, and support. Local-first defines a safer division of responsibility when connectivity is unavailable.