Edge vs. Cloud PID Control: Latency, Safety, and Why It Matters

When you are controlling a heater, a pump, or a motor with a PID loop, where that loop runs is not an implementation detail. It is a safety decision.

Most cloud IoT platforms run PID controllers on their servers. The sensor reading goes up to the cloud, the PID algorithm calculates an output, and a command comes back down to the actuator. This works fine on a demo with a simulated temperature. It fails in the real world.

Here is why.

The Latency Problem

A PID controller needs to run at a consistent interval. For temperature control, that is typically every 1-10 seconds. For motor speed control, it can be every 100 milliseconds.

When PID runs in the cloud, every control cycle looks like this:

1. Pi reads sensor (1ms)
2. Data uploaded to cloud (50-200ms)
3. Cloud processes data (10-50ms)
4. Cloud runs PID calculation (1ms)
5. Command sent back to Pi (50-200ms)
6. Pi actuates hardware (1ms)

Total round-trip: 110-450ms per cycle.

When PID runs on the Pi edge:

1. Pi reads sensor (1ms)
2. PID calculation (1ms)
3. Pi actuates hardware (1ms)

Total: 3ms per cycle.

That is a 50-150x difference. For a slow process like room temperature, this might seem acceptable. But PID control quality degrades with latency:

• Phase lag — The controller reacts to what the process was doing 200ms ago, not what it is doing now
• Effective dead time — Network latency adds artificial dead time to the process, making tuning harder
• Jitter — Network latency is not constant. Variable delays cause inconsistent control behavior

The Safety Problem

Latency is annoying. Internet outages are dangerous.

When your PID runs in the cloud and your internet goes down:

• The PID controller stops. There is no control output.
• The actuator freezes in its last state. If the heater was at 80% output, it stays at 80%.
• Your process runs away. A fermentation tank overheats. A grow room humidity drops to zero. A heating element runs at full power with no feedback.

This is not hypothetical. Internet connections drop, DNS servers fail, cloud services have outages, and Wi-Fi access points restart. If your control loop depends on any of these, your control loop will fail.

The Real Risk

Consider a PID-controlled heater maintaining 65C for pasteurization:

• Normal operation: PID modulates heater between 0-100% to hold 65C
• Internet drops while heater is at 80% output
• Cloud PID: Heater stays at 80%. Temperature climbs to 90C, 100C...
• Edge PID: PID continues running locally. Temperature holds at 65C.

The edge PID does not care about the internet. It reads the sensor, calculates the output, and adjusts the heater. The cloud is irrelevant to the control loop.

The Offline Resilience Argument

Edge PID means your process continues running correctly when:

• Internet goes down (ISP outage, router restart)
• Cloud service has an incident (happens to every provider)
• Wi-Fi drops temporarily (interference, congestion)
• DNS resolution fails
• Firebase/AWS/Azure has a regional outage
• Your firewall rules change
• Someone accidentally unplugs the router

In all of these scenarios, a cloud PID stops. An edge PID continues.

What the Cloud Should Do

This does not mean the cloud is useless. The cloud excels at:

• Monitoring — Dashboards showing live and historical data
• Setpoint adjustment — Changing the PID target from your phone
• Alerting — Sending notifications when something goes wrong
• Analytics — Long-term trend analysis and anomaly detection
• Configuration — Updating the PID gains, polling intervals, and alarm thresholds
• Multi-site coordination — Viewing multiple devices on one dashboard

The control loop itself should run on the edge. The cloud should be the supervisor, not the controller.

How LoopString Does It

LoopString's architecture separates concerns cleanly:

On the Pi (Node-RED):

• Sensor reading
• PID calculation
• Actuator control
• Local alarm evaluation
• Data publishing to Firebase RTDB

In the cloud (Firebase + React):

• Real-time dashboard
• Setpoint adjustment (writes to RTDB, Pi reads it)
• Historical data storage
• Alert notifications
• Analytics and reporting
• Device management

The data flow is unidirectional for safety:

• Sensors to cloud: Pi publishes readings to Firebase RTDB. Dashboard subscribes.
• Cloud to actuators: Dashboard writes setpoints to RTDB. Pi reads and applies.

The Pi never waits for the cloud to tell it what to do. The PID runs on its own internal clock. If the cloud sends a new setpoint, the Pi picks it up on the next cycle. If the cloud is unreachable, the Pi uses the last known setpoint.

What About Hybrid Approaches?

Some platforms offer a "hybrid" model: PID runs in the cloud normally, but falls back to a simple on/off controller on the device when offline.

This is better than pure cloud PID, but still problematic:

• The on/off fallback is a different control algorithm with different behavior
• Your process may not tolerate on/off control (overshoot, oscillation)
• The switch from PID to on/off can cause a transient disturbance
• Tuning the on/off thresholds is separate from tuning the PID gains

The simplest and safest approach: run PID on the edge all the time. Use the cloud for monitoring and configuration. No fallback mode needed because there is nothing to fall back from.

The Counter-Argument

Cloud PID advocates argue that:

• "Our cloud is highly available (99.99% uptime)" — 99.99% is 52 minutes of downtime per year. Your internet connection is much less reliable.
• "We can run more sophisticated algorithms in the cloud" — A Raspberry Pi 4 can run a PID calculation in microseconds. Processing power is not the bottleneck.
• "Cloud PID is easier to update" — LoopString updates PID parameters via RTDB. No firmware flash needed.

Practical Implications

If you are choosing an IoT platform for process control, ask one question: Where does the PID loop run?

If the answer is "in the cloud," understand the latency and safety trade-offs. If the answer is "on the edge," you have a platform that takes control theory seriously.

Try Edge PID

Create a free LoopString account and build a PID-controlled system using the Configurator. PID loops run on your Pi from the moment you deploy. The cloud shows you what is happening. The Pi keeps it under control.

For a hands-on guide, see PID Temperature Control with Raspberry Pi.