Load shedding does not have to take your smart home down with it. The devices that draw the most power, such as lights, the geyser, pumps and motors, are exactly the ones you can let follow the mains and forget about. What has to stay alive is the small brain that runs your logic and the network it talks over. Get those two things right, design everything else to come back cleanly, and a two or four hour slot becomes a non-event.

Power the hub and the network, not the whole house

The instinct is to buy one big inverter and put the whole house on it. That is expensive and, for automation, unnecessary. A controller draws a few watts. A router and fibre ONT draw a little more. A handful of sensors draw almost nothing. A small UPS or battery pack can carry that combined load through a normal shedding slot without breaking a sweat.

Decide clearly what belongs on backup power and what does not:

• On battery: the controller or hub that holds your automations.
• On battery: the router and ONT, so remote access and time sync keep working.
• On battery: low-draw sensors, or the base station they report to.
• On mains: lights, the geyser, pumps, gate motors and anything else with a real current draw. These should fail safe when power drops and resume when it returns.

Make every device boot into a known state

When power returns, a device should never come back in a random or unsafe state. A relay that controls a heater should default to off, not to whatever it was mid-cycle when the lights went out. The clean pattern is to store the intended state in flash and restore it on boot, or default to a safe state and let the hub re-assert the correct one once it reconnects.

Avoid depending on the cloud to tell a device what to do at startup. If the internet is slow to return after power, a device that sits waiting for a cloud command is a device that sits dead. Keep the logic local-first: the device knows its own safe default, and a hub on your own network corrects it within seconds. The cloud is for visibility and history, not for the moment-to-moment control loop.

Keep clocks and schedules in sync

Cheap controllers lose track of time the instant they lose power. A schedule that says gate light on at 18:00 quietly fails if the clock reset to midnight on boot. There are two fixes and you usually want both. Add a small real-time clock with a coin cell so the device keeps time through an outage. And re-sync over the network as soon as the connection is back, so any drift is corrected automatically.

Write schedules that check the current wall-clock time rather than ones that count elapsed ticks since boot. A rule phrased as in six hours restarts its count on every reboot, so during a bad run of stage four it may never actually fire. A rule phrased as at 18:00 fires the moment the clock is right, no matter how many times the board restarted during the day.

Battery-backed sensors keep the picture alive

Sensors that run on a coin cell or an AA pack keep reporting straight through an outage: door contacts, temperature, motion, water level. If your hub is on the same UPS, it keeps receiving them, so you still know what happened in the dark. Have sensors buffer a few readings locally and flush them once the hub acknowledges, so an outage does not punch a hole in your record.

This matters for security, where a gap in motion and door events is the last thing you want, and for anything temperature-sensitive, where you need the trace across the whole outage, not just the parts with grid power.

Test your dark-start

The only way to know your setup survives is to cut the power on purpose and watch. This is the step almost everyone skips, and it is the one that finds the broken defaults. Pick a quiet time, kill the mains to the area, and work through it in order:

1. Cut mains and start a timer. Confirm the hub and router stay up on battery.
2. Confirm your sensors still report to the hub while the grid is down.
3. Wait past your battery runtime and let the hub die too, so you test a full cold start.
4. Restore power. Time how long until the hub is back and reachable.
5. Check that every actuator returned to its intended state, not a random one.
6. Check the clock is correct and that the next scheduled action fires on time.

Run this test after any big change to the system. Write down anything that came back wrong, fix the default, and test again until a dark-start is boring.

Where to learn and build this

These are habits worth teaching, not just gear worth buying. A tiny controller that survives a power cut is a clean project for a learner: a board, a couple of sensors, a relay, and logic that always defaults safe. It is often easiest to prototype the logic in a simulator before touching hardware, which you can do on the verse simulator, then move it onto the sheenbot∞ board for the sensor and relay side. For a running home, the sheenIoT platform gives you the dashboards and state history, while the home IoT solution line packages the hub and sensors. The rule stays the same either way: local-first logic, cloud for the view.

The takeaway

You do not need to power your whole house to keep it smart through load shedding. Put the hub, the network and the sensors on a small battery. Make every device default to a safe, known state and re-sync its clock when power returns. Then prove it with a dark-start test instead of hoping. A home that comes back clean every single time is worth far more than one that promises never to blink.

How long should my UPS last?

Long enough to cover a typical shedding slot, which is usually two to four hours of hub-and-router runtime. You are not trying to outlast the whole outage. You are trying to keep the brain alive through most slots and to recover cleanly from the rest.

Should the geyser or lights be on backup?

Usually not. High-draw appliances flatten a battery fast and give you little in return. Let them follow the mains and design them to fail safe, so the automation around them does the clever part and the appliance just switches.

What if my internet is down but power is back?

Local-first logic keeps working on your own network regardless. Cloud dashboards and remote access catch up when the line returns, and your automations should never wait on them to do their job in the first place.