Edge and cloud: why the control loop stays on site
Local autonomy for real-time control, the cloud for analytics and coordination — and why connectivity should never be a safety dependency.
Rural sites lose connectivity. Mobile networks drop, routers reboot, fiber gets cut by a tractor. A water system that needs the internet to avoid overflowing a tank is a fragile system.
So we follow a simple rule: anything that must keep working when the connection fails runs at the edge. The cloud makes the system better; it is never required to keep it safe.
What runs on site
- Real-time control loops — pump staging, irrigation valves, battery charge and discharge limits.
- Safety interlocks — emergency stop paths, maximum runtime and minimum rest times, dry-run detection (pump on, flow zero), over-pressure cutoff.
- A local buffer that stores readings while the link is down.
- Protocol translation. Inverters, meters, PLCs, and sensors speak different languages (Modbus is common, many vendors add their own). The edge gateway translates them into one consistent internal model, so control logic does not care which brand is installed.
- Last known good configuration, so a site restarts into a safe, known state.
What runs in the cloud
- Long-term history and analytics across seasons and sites
- Forecasting (weather, demand, generation) as an input to scheduling
- Multi-site coordination and fleet-level reporting
- Dashboards, user management, audit trails, and software updates
The cloud can advise the edge. The edge validates what it receives and decides whether to act.
Making an unreliable link reliable
Connectivity is a spectrum, not a switch. A few patterns make a flaky link behave:
Timestamp at the source. A reading carries the time it was measured, not the time it arrived. Otherwise a ten-minute outage becomes a spike of "new" data.
Store and forward. The gateway buffers in order and syncs when the link returns. Ingestion must be idempotent — keyed by device, measurement, and timestamp — because retries and duplicates are normal.
Pick the right delivery guarantee. MQTT, a lightweight publish/subscribe protocol widely used in IoT, offers three quality-of-service levels: at most once (0), at least once (1), and exactly once (2). Telemetry usually runs at level 1 with idempotent ingestion; the higher cost of level 2 is rarely worth it for a temperature reading. MQTT's last will messages also let a broker announce that a gateway dropped off unexpectedly.
Expect out-of-order data. Late arrivals should slot into the right place in history without rewriting alerts that already fired.
Commands travel the other way, and need more care
A command sent from the cloud has to survive the same flaky link — and must never do harm because of it.
- Acknowledge. The edge confirms receipt and execution, so a dashboard shows the real state, not the intended one.
- Expire. A "start pump" command that sits in a queue for six hours must not fire when the connection returns. Commands carry a short validity window.
- Re-check at the point of execution. Safety is evaluated at the edge, at that moment — not only when the command was issued.
Offline is a mode, not an error
When connectivity drops, the right behavior is not an alarm storm. The site keeps running within its limits, the interface shows edge connectivity degraded, and operators see what is running locally and how much data is buffered. When the link returns, the site syncs and the gap in the cloud history closes by itself.
The cloud enhances the system. The edge keeps it safe.
That is the hybrid design behind the Greecon Platform: the same principle applies whether the site is a remote farm, a pumping station, or a solar plant.