Cloud, Local and Hub-Based Devices

Why this matters

Customers buy connected equipment for the night something goes wrong, and something going wrong often takes the internet down with it: a storm, a provider outage, a tripped breaker under the router. Whether the leak valve still closes, the thermostat still holds the house above freezing and the door still opens depends on where the device's decisions are made, and two products that look identical in the box can answer that differently. A tech who knows which kind they installed can tell the customer honestly what protection they have, and can refuse to rely on a cloud round trip for anything that keeps water inside the pipes or people inside a safe house.

Three places a decision can be made

Every connected device turns an input (a reading, a button press, a schedule time) into an action. The useful question is where that happens.

• Cloud-dependent. The device reports to the manufacturer's servers, the decision is made there, and the command comes back down. Even a tap in the app while standing next to the device goes out to the internet and back. Lose the internet and the device falls back to whatever it can do on its own, which for some devices is very little.
• Local-capable. The device holds its own logic: the thermostat keeps its schedule, the controller runs its program, the valve closes on its own sensor. The cloud adds remote access, history and notifications. Some of these also accept commands over the home network directly, so the app may still work from inside the house during an internet outage; many do not.
• Hub-based. Sensors and small devices talk to a hub over a low-power radio protocol (Zigbee, Z-Wave or Thread, explained in their own sibling) rather than Wi-Fi. The hub joins the home network and may run rules locally ("if a sensor reports water, close the valve") or may forward everything to the cloud and wait for instructions. Which one depends on the product, and sometimes on how it was set up.

The newer Matter standard aims to make local control between devices from different makers the norm, but support varies by device and by firmware version as of 2026, so check each product's documentation rather than assuming a logo guarantees it.

The paths, side by side

CLOUD-DEPENDENT
 sensor/device -> router -> modem -> INTERNET -> cloud
                                                  |
 action <- device <- router <- modem <- INTERNET <-+
 (internet down: no action, no alert)

LOCAL-CAPABLE
 sensor -> device -> action        (always)
 device -> router -> INTERNET -> cloud -> phone alert
 (internet down: action yes, alert no)

HUB-BASED, LOCAL RULE
 sensor ~~radio~~> hub -> valve/device -> action
 hub -> router -> INTERNET -> cloud -> phone alert
 (internet down: action yes, alert no)
 (power down: action only if hub AND valve on battery)

The diagram makes one point the rest of this card depends on: notifications always need the internet, and therefore power to the modem and router. Only the protective action can be made independent of them.

What survives which failure

Three different things can fail, and they fail differently. "The internet is down" is not the same as "the power is out", and neither is the same as "the Wi-Fi dropped".

Two consequences are easy to miss. First, in a power outage the router and modem are dead too, so even a battery-backed device can act but cannot tell anyone unless something in the chain has its own backup, such as a cellular communicator (see related: Cellular Backup and Alarm Communicators). Second, a motorized water valve may need power to move; some carry a battery, some do not, and some fail to a set position when power is lost. Read the spec rather than assuming.

The rule for anything safety-related

If a device's job is to protect the house or the people in it, its protective action must not depend on the internet. Applied to the equipment the trades install:

• Leak detection and water shutoff. The close-on-leak decision should be made by the valve or by the hub on a local rule, not by the cloud. A cloud round trip during an outage means the valve waits while the water runs.
• Freeze protection. The thermostat must hold its heating setpoint locally. A schedule stored only in the cloud is a schedule the house loses during an outage. For a vacant house, a local minimum setpoint is the protection; the alert is the bonus.
• Smoke and carbon monoxide. Life-safety alarms should be standalone listed alarms, interconnected as NFPA 72 and the residential code adopted in that jurisdiction require, that sound locally with no network. A connected alarm or a connected monitor adds notifications; it never replaces the local alarm.
• Locks. A connected lock must still open from the inside by hand and must keep a local entry method, a keypad that works offline or a mechanical key. A lock whose only entry is the app locks the owner out in an outage.
• Garage door openers. The safety reversal (photo eyes and force sensing) is built into the opener and works with no network. Remote close from the app is a convenience, and closing a door you cannot see is where the opener's own warnings apply.

A worked example: the overnight outage

A house with four connected devices the shop installed or services: a leak hub with three sensors and a motorized shutoff valve, set up with a local close-on-leak rule; a cloud-dependent video doorbell; a local-capable thermostat; and a keypad lock with app control. A storm takes the internet down at 11pm. The power stays on.

At 2am, the water heater's drain valve starts to weep. The leak sensor in the drain pan reports water to the hub over its own radio. The hub's local rule closes the shutoff valve within a few seconds. The house is now without water and the leak has stopped at a few cups. No alert reaches anybody, because the cloud cannot be reached.

At 8am the internet returns. The hub reconnects and the owner receives the leak alert, six hours after the event (the delay runs from 2am to 8am). Some systems deliver queued alerts on reconnect; others drop them, and the owner learns of the leak only by finding no water at the tap. Meanwhile:

• The thermostat ran its stored schedule all night. The owner could not change it from the app until 8am.
• The doorbell recorded nothing between 11pm and 8am, because it stores video in the cloud.
• The lock opened by keypad when the owner left for work at 7am. The app would not unlock it.

What changes the answer. Had the leak hub been set up to forward events to the cloud and wait for a cloud rule, the valve would have stayed open until 8am, six hours of a weeping drain valve instead of a few cups. The hardware was identical; the configuration decided it. Had the power gone out as well, the outcome would hinge on two spec-sheet lines: whether the hub has a battery, and whether the valve can move on battery. With neither, the sensors would sense and nothing would act. Had the thermostat been cloud-dependent, it might have held a default setpoint or none, which in January at a vacant house is the expensive version of this story.

How to establish which kind you installed

The box and the marketing rarely say plainly. Establish it at commissioning, with the owner's consent and the owner present, because it touches their network:

• Unplug the internet, not the power. Disconnect the cable between the modem and the router (or the router's internet port), leaving the router and the house Wi-Fi running. Do not power down the modem or router for this test; a restart takes minutes and may change settings.
• Trigger the protective action. Wet a leak sensor with a damp cloth, with no fixtures running and the household told the water will go off. Watch whether the valve closes with the internet disconnected.
• Try the app from inside the house and note whether it can see or control the device locally.
• Reconnect, then reopen. Plug the internet cable back in, confirm the router shows its internet light restored, reopen the valve slowly from its control while watching the valve body for leaks, and confirm flow at a fixture and that the queued alert, if any, arrived.

Record the result on the device record in one line: "Local close-on-leak confirmed with internet disconnected; alerts require internet; hub has battery, valve does not." That line tells the next tech and the owner exactly what protection exists, which is what this whole card is for.

References

• Device and hub manufacturer documentation (local rules, offline behavior, battery backup, valve fail position)
• NFPA 72 and the residential code as adopted by the local jurisdiction, for smoke and CO alarm installation and interconnection
• See related: Wi-Fi, Zigbee, Z-Wave, Thread and Matter Explained; Cellular Backup and Alarm Communicators
• See related: When the Manufacturer Shuts Off the Cloud; Leak Sensors and Automatic Water Shutoffs; The Connected-Device Commissioning SOP