Every connected system eventually meets a bad day: the internet connection drops, a vendor retires a service, or a server somewhere has an outage. What happens next depends on a design decision made long before, namely where the automation logic actually runs. Understanding the difference between edge and cloud execution helps you decide what must keep working and what can wait.

What Edge and Cloud Mean Here

Edge (or local) automation runs on hardware you control and that sits close to the devices: a hub, a gateway, a home server, or a small industrial controller. Commands travel across your local network.

Cloud automation runs on a remote service. Your device sends an event over the internet, the service decides what to do, and a command comes back the same way.

Most real systems are hybrids. The question is which jobs sit where.

Trade-offs in Plain Language

Cloud services are attractive because they need little setup, offer polished apps and often provide features like voice assistants and remote access without extra work. Their weaknesses are dependence on connectivity, added delay on each round trip, and reliance on a provider continuing to operate and support your devices. Data also leaves your premises, which raises privacy and compliance questions.

Edge systems respond quickly, keep working without the internet, and keep sensitive data local. They ask more of you: you maintain the hardware, apply updates, take backups and fix problems. Their feature set may be narrower, and remote access takes deliberate, secure configuration.

A Comparison

Aspect	Edge (local)	Cloud
Works during internet outage	Usually yes	Often no
Response delay	Typically short	Depends on connection and service
Setup effort	Higher	Lower
Ongoing upkeep	You handle it	Provider handles it
Privacy	Data can stay on site	Data goes to provider
Long-term dependence	On your own hardware	On provider’s continued service
Remote features	Needs deliberate setup	Often built in

Always confirm details against each product’s current documentation, because behaviour varies even between devices from one brand.

Sort Your Automations by Consequence

A simple way to decide placement is to ask what happens if the rule fails to run.

• Critical: heating safety cut-offs, leak shut-off valves, alarm responses, equipment protection. These should run locally and have a defined safe state.
• Important: lighting in key areas, door and entry logic, ventilation. Prefer local execution, with graceful degradation.
• Convenience: voice commands, mood scenes, weather-based tweaks, reports. Cloud dependence is generally acceptable.

For industrial and commercial setups, critical protective functions should never rely on an internet connection, and safety functions follow their own engineering rules and standards. Consult qualified professionals for those.

Design the Fallback Deliberately

For each important device, decide in advance what it does when the brain disappears.

1. Manual control. A physical switch, button or thermostat dial should always work.
2. Device-level defaults. Many devices hold schedules or limits locally. Use them as a backstop.
3. Safe state. Define whether the device should turn off, stay as it is, or move to a protective setting.
4. Local alert. Where practical, a siren, light or buzzer that does not depend on a phone notification.
5. Recovery. After power or network returns, devices should resume sensibly rather than all firing at once.

Test these by simulating failure: unplug the router, disconnect the hub, and watch what each device does. Doing it on purpose beats discovering it during a storm.

Power Matters Too

Resilience is not just about networking. If a hub, router and gateway all lose power together, the cleverest local logic will still stop. Consider a small uninterruptible power supply for the network and controller equipment that supports critical functions. Size it according to the load and the runtime you need, following the manufacturer’s current guidance.

Handling Vendor Risk

Cloud-dependent devices carry a long-term question: what if the service changes or ends? Reduce that risk by favouring devices that support local control or open standards, keeping a record of device settings, and avoiding deep dependence on a single provider for the functions your household or site relies on. Review terms and support announcements when you buy.

A Hypothetical Example

Imagine a small workshop with a smart plug on a dehumidifier, a leak sensor near a sink and a few lights. The owner first connects everything through a cloud service. During a lengthy internet outage, the dehumidifier schedule stops responding and the leak alert never reaches a phone. The owner then reorganises: the leak sensor and a local siren connect through a local hub, which also runs the dehumidifier logic using a humidity sensor. The cloud service remains for voice control and remote viewing. A small backup power unit keeps the hub and router alive for a while. The next outage passes unnoticed, except that the voice assistant is silent for a few hours, which is acceptable.

Common Mistakes

• Assuming that because an app works, the logic runs locally.
• Having no manual override on important devices.
• Never testing an outage until a real one occurs.
• Forgetting that the router, modem and hub all need power.
• Putting protective functions behind a service with no local fallback.

Frequently Asked Questions

Is local control always better than cloud control? No. Local control wins for resilience, speed and privacy, while cloud suits convenience features and low maintenance. The right mix depends on consequences and your willingness to maintain equipment.

How can I tell if a device works without internet? Test it by disconnecting your router and trying the device through your local controller. Also read the vendor’s current documentation, since marketing pages are not always specific.

Do I still need cloud access if I go local? Not necessarily. Some people keep it for remote viewing and voice control, while keeping essential logic local.

What should a device do when it loses contact with its controller? Choose a safe default based on its purpose. Lighting might hold its last state, while a heater should typically revert to a conservative setting.

Does edge computing apply only to homes? No. Factories and commercial buildings use edge gateways for the same reasons: speed, resilience and keeping data on site.

Next Step

List your ten most important automated functions and mark each as critical, important or convenience. For any critical or important one that depends on the cloud, plan a local alternative or a manual fallback, and test it by switching off your router for a short, supervised trial.