Three layers, and only one of them is the internet
It helps to picture a system as three separate layers, because each one fails independently and each one is somebody's responsibility.
At the bottom is the physical layer: the wiring, the switching modules behind your plates, the curtain motors, the valve on a fan coil, the lock, the gate motor. This is electricity and mechanics. It doesn't know what the internet is.
In the middle is the local layer: the processor or hub, the network switch, the router acting as the local network, the access points and the radio mesh the wireless devices talk over. This is where the logic lives in a locally processed system. Scenes are evaluated here, schedules are held here, and a keypad press travels a few metres to this layer and back.
At the top is the cloud layer: the app connecting from outside the property, push notifications, remote voice processing, updates, and any recordings stored off site. This layer needs an internet connection by definition.
Once the layers are clear, the question becomes precise. It is not whether the house works without the internet. It is which layer each feature you care about depends on, and that is the most useful question to put to any supplier during system selection.
Four different failures, and people call them all the same thing
Almost every complaint that starts with nothing works turns out to be one of four quite different situations, and telling them apart is most of the diagnosis.
Getting this straight matters because the fix differs completely. A connection failure is a call to your provider, a router failure is a replacement, a hub failure is a service call, and a power cut is a question about what has battery support, which has its own section below.
- The connection to the outside world is down. Your router is fine, the home network is fine, and only the path out of the building is broken. In a locally processed system this is the least disruptive case: the house behaves normally and remote access pauses.
- The router or an access point has failed. Now the local network itself is broken, so devices that depend on it can't reach the hub. Wired keypads and physical switches usually still work. Anything wireless is on its own.
- The hub or processor has failed. The logic layer is gone. Scenes, schedules and automations stop, and what remains is whatever the physical layer can do unaided: switches, key overrides, manual releases.
- The power is out. Everything stops except what has battery support, and the interesting question becomes what comes back, in what order, when power returns.
What should keep working without an internet connection
In a system built local-first, the following should carry on during a plain connection outage. This is the list worth putting in front of a supplier and asking them to confirm line by line for the exact equipment they are proposing.
The last item deserves emphasis because it is the one people forget to ask about. A wall switch that is really a request to a distant server is a design choice, and it's a choice you can decline.
- Wall keypads and switches, including the scenes assigned to them.
- Scheduled events already programmed, such as landscape lighting following dusk or a cooling setback in the middle of the day.
- Sensor logic: occupancy triggering a light, a door contact arming something, a leak detector sounding locally.
- Room-by-room cooling control, where the controller is doing the work at the unit and not asking permission from elsewhere.
- Curtain and blind control from a keypad or a local schedule.
- Door entry and access at the door itself: a code, a card, a fob, a key.
- Camera recording to a recorder on the premises, and viewing it from inside the property.
- The app on a phone connected to the home's own network, provided the app is capable of connecting locally instead of only through a remote service.
What pauses, and reasonably so
There is nothing wrong with a feature depending on the internet when the feature is inherently about being elsewhere. What matters is that the dependency sits where it belongs and that you were told about it.
Two of those deserve thought. If you rely on an alert when a leak sensor triggers while you are away, that alert travels over the internet and stops with it, so a local siren is worth having alongside it. And if remote camera viewing matters, ask specifically how it is delivered, because the convenient answer and the safe answer aren't always the same.
- Remote access from outside the property, whether by app or browser.
- Push notifications and alert emails, since both leave the building to reach you.
- Voice assistants that send speech to a remote service for processing, which most of the well-known ones do.
- Cloud video storage and any camera whose footage only exists off site.
- Software and firmware updates, and any feature that checks a licence or an account on each use.
- Automations driven by external data, such as weather-based irrigation or sunrise data pulled from a service instead of calculated locally.
- Anything shared with a family member's phone while they are away from the house.
Graceful degradation means a manual layer underneath
The phrase sounds abstract until you apply it to a front door at night. Graceful degradation means every important function has a simpler layer beneath it that works when the clever layer does not, and that the fallback is something a household member can operate without instructions.
In practice that means specific, checkable things. Lighting circuits keep a physical means of switching, so a room can be lit with no system involved at all. A smart lock keeps a mechanical key override, and somebody in the house knows where that key is. A gate motor keeps a manual release, and the household has been shown how to use it. A cooling controller holds its own setpoint and schedule at the unit. A recorder writes to disk on the premises, so an outage costs you remote viewing and not the footage. Leak and intruder detection give a local indication somebody in the building can hear.
None of that is exotic. It is the ordinary discipline of designing a whole-home system so a failure removes convenience and never removes capability. It is also the part most easily lost when a house is assembled from products bought one at a time, because each product's fallback was designed in isolation and nobody checked what happens when several are unavailable at once.
A power cut is a different question
Losing power is not the same as losing the internet, and the two get discussed as though they were. When power goes, everything stops except what is on battery, and the useful design questions are about what to protect and what happens on the way back. We cover the comeback itself, step by step, in what a power cut does to a smart home in Dubai.
The equipment worth putting on battery support is a short list: the network switch and router, the processor or hub, the camera recorder, and any door entry and access control that must keep working at a door. That keeps the logic layer alive and the cameras recording while the mains is off. Beyond that, battery support becomes a much larger conversation about the whole property, which is a different trade.
Restoration is easy to get wrong. Devices come back at different speeds, and a system that assumes everything is ready at once produces odd behaviour: lights at full brightness in the middle of the night, a scene half executed, a schedule that fired while the clock was still wrong. A properly commissioned system defines what each circuit does on power restore, holds its time through the outage, and brings things back in order. Ask for that to be demonstrated, not described.
The network is usually the real culprit
Most houses blamed for internet dependence are actually suffering from a weak local network. If access points relay wirelessly to each other through concrete and solid block, if the router sits in a cupboard behind a metal door, if every camera, phone, television and sensor shares one crowded band, devices will be slow and unreliable on a perfectly good connection day.
A cabled backbone with access points wired back to a central cabinet fixes more of this than replacing any device would, and it means that when the outside connection does drop, the local layer left behind is solid. That is why Wi-Fi and networking is the first thing to settle in almost every project.
How to test it before you sign the handover off
Don't take this on description. Ask for the test at handover, with everybody standing there, and note what happens.
Run it in daylight, with the household present, and write down anything that behaves unexpectedly. A test like this at handover is worth more than any assurance, and it is the moment to find out that the bedroom keypad was quietly depending on something outside the building.
- Unplug the cable from the router that goes to the outside world, leaving the home network running.
- Press keypads and wall switches in several rooms. Everything should behave normally.
- Trigger a scene, then change the cooling setpoint in a room and confirm the unit responds.
- Open and close a curtain from a keypad, and open a door or gate from wherever you normally would.
- Check that a camera is still recording, and view it from a phone connected to the home network.
- Try the app from a phone on mobile data. This one should fail, and that is the correct result.
- Reconnect, confirm everything returns without anyone touching a setting, and check the time and schedules are still right.
- Separately, ask what the same test looks like for a power cut, and what is on battery support.
Questions worth asking any supplier
Short, plain, and the answers are revealing.
- Which functions run on equipment inside my property, and which depend on a service somewhere else?
- If my connection drops, what specifically stops working, and if the hub fails, what do I lose until it is replaced?
- Does the app connect locally when I am at home, or does it go out and come back?
- Where is camera footage stored, and can I get to it from inside the house with no connection?
- What is the manual override for every lock, gate and shutter, and who in the household will be shown it?
- What happens on power restore, and what equipment do you recommend putting on battery support?
- Will you demonstrate the outage test at handover?
In short
The honest answer to what happens when the internet goes down is that it depends on where the thinking is done. A house whose logic runs on a processor inside the building loses its remote features and keeps its behaviour. A house whose basic control is hosted elsewhere loses both, and the first time anybody notices is the first time it matters. That is a design decision, not an unavoidable property of smart homes, and you can ask about it before committing to anything. Establish which layer each feature you care about lives on, insist every important function has a simpler fallback underneath it, put the network and the equipment position right at the start, and run the test at handover with the cable unplugged. A house that keeps answering its own walls during an outage was specified that way on purpose.
Common questions
It depends where the logic runs. Systems that process automation locally, on a processor or hub inside the property, keep running scenes, schedules, keypads, sensor logic and local cooling control with no connection at all, and only remote access from outside the house pauses. Systems that route basic control through a cloud service do stop, because a button press is a request that has to leave the building and come back. Both are described in similar language when they are sold, so the useful question is which functions run on equipment inside the property and which depend on a service elsewhere.
The ones that are about being somewhere else. Reaching the house from outside by app or browser, push notifications and alert emails, voice assistants that send speech away for processing, cloud video storage, software and firmware updates, and any automation driven by external data such as a weather feed. It is reasonable for those to pause during an outage. What is not reasonable is a wall switch, a scene or a schedule depending on the same connection, and that is worth confirming feature by feature before anything is specified.
It is a piece of equipment installed in the property, usually in the network cabinet or a plant space, that holds the automation logic: the scenes, the schedules, the rules connecting a sensor to an action. When a keypad is pressed, the request travels a few metres to that processor and back. The alternative is logic held on a remote service, where the same press leaves the building. Keeping the logic local means the house continues behaving as programmed through a connection outage, and it also means responses are not waiting on a round trip.
This is a specification question and it should be settled at design stage. Smart locks normally keep a mechanical key override, and somebody in the household should know where that key is kept. Gate and shutter motors have a manual release, and the family should be shown how to use it, not told it exists. Access control at a door that must keep working through an outage is one of the few items worth putting on battery support, alongside the network equipment, the processor and the camera recorder. Ask for each override to be demonstrated at handover.
For a short list of items, it is usually worth it: the router and network switch, the processor or hub, the camera recorder, and any access control that has to keep working at a door. That keeps the logic layer alive and the cameras recording while mains power is off, which is exactly when you would want both. Beyond that list, backing up more of the property is a much larger conversation belonging to a different trade. The other half of the question is what happens on the way back, so ask what each circuit does when power is restored and have that behaviour demonstrated.
Unplug the cable running from your router to the outside world, leaving the home network powered, then walk the house. Press keypads and wall switches, trigger a scene, change a cooling setpoint, move a curtain, open the door or gate as you normally would, and check a camera is still recording and viewable from a phone on the home network. Then try the app from a phone on mobile data: that one should fail, and that is the correct result. Reconnect and confirm everything returns on its own with the clock and schedules intact.