Home automation

Home automation is three things stacked: devices that sense or switch, a hub that they talk to, and automations — the rules that say what should happen when. The first is shopping, the second is a decision you make once and live with, and the third is the actual hobby.

The thing beginners underestimate is that the difficulty is not technical. Making a light come on when a sensor fires is a five-minute job on any platform. Working out which lights, at what times, with what exceptions, so that the house feels intelligent rather than possessed — and so that another person in the house does not want to rip it all out — is the part that takes years. The best automations are the ones nobody notices; the worst are the ones that surprise somebody at 3am.

The second organising idea is where the decisions are made. A local system keeps the logic in your house and keeps working when the internet does not. A cloud system puts the logic on somebody else's server, which is easier to set up and means your lights depend on a company continuing to exist and continuing to care. Almost every serious disagreement in this hobby is a version of that one question.

The easy part

Making something happen

The hard part

Deciding what should happen

The decision you live with

Local or cloud

The test of a good automation

Nobody notices it

1. 1

   Step 1: Buy two smart plugs and nothing else

   Under £30, no hub, no commitment, no wiring. Automate a lamp on a schedule and a heater on a temperature. This tells you whether the hobby is for you before you have chosen an ecosystem you will be stuck with.

   You will know it worked when: Something in your house does something without you.

2. 2

   Step 2: Decide local or cloud before the third purchase

   This is the decision everything else inherits, and it is much cheaper to make now than after twenty devices. Local means the logic stays in your house and survives the internet, the vendor and the subscription; cloud means less setup and a dependency you do not control. Neither is wrong; drifting into one by accident is.

   You will know it worked when: You can say which one you chose and why.

3. 3

   Step 3: Put a hub in and add one sensor

   A motion or door sensor is the moment the hobby changes character, because the house starts responding to the world rather than to you. Check the protocol against your hub before buying, which is the check that prevents the standard experience of buying something twice.

   You will know it worked when: An automation fires without anybody pressing anything.

4. 4

   Step 4: Write automations for other people, not for yourself

   The measure is whether somebody who did not build it can live in the house. Every automation keeps its manual control working, nothing surprises anybody at night, and anything clever gets a way to turn it off.

   You will know it worked when: Somebody else in the house has not complained.

5. 5

   Step 5: Write down what you have built

   The room that behaves oddly in eighteen months will be a rule you wrote tonight and forgot. A plain list of automations and what each is for is the single highest-value unglamorous habit in the hobby.

   You will know it worked when: You could hand the system to somebody else.

• The hub, which is the decision that matters — Everything else is replaceable and this is not, because it determines what you can add later. A hub can be a purpose-built box, a spare single-board computer running open-source software, or a vendor's cloud account. Self-hosted platforms are free, run locally, support far more device types than any single vendor, and cost you the setup evening; vendor hubs are quicker and bind you to that vendor's catalogue.
• Wireless protocol, which quietly decides everything else — Wifi devices are cheapest and each one is another thing on your network; low-power mesh protocols use their own network and are what battery sensors generally run on, at the cost of needing a compatible radio in the hub. This is the specification to check before buying anything, because it is the one that makes a device unusable rather than merely awkward.
• Smart plugs, which are the correct first purchase — Cheap, entirely outside any electrical regulation, and they teach the whole model — a thing that switches, a rule that switches it, and a manual override. Two of them will tell you more about whether you enjoy this hobby than any amount of reading.
• Sensors, which are what make it automation rather than remote control — Motion, door and window contacts, temperature, humidity, light level. Until you have sensors you have a house you can control from your phone, which is not the same thing and is considerably less useful. Battery life is the specification that matters and the one least often quoted honestly.
• Smart bulbs versus smart switches — The classic beginner fork. Bulbs are plug-in, reversible and stop working the moment somebody uses the wall switch; switches keep the wall working for everybody but live behind a faceplate and can require a neutral wire that older British installations often do not have at the switch. Bulbs first, always.
• A thermostat, which is where the money and the payback are — The largest single spend and the device with the clearest return, and also the one most entangled with your existing heating system. Compatibility with the boiler and the controls matters far more than the feature list.
• What can wait indefinitely — Cameras, voice assistants in every room, a dashboard on a wall tablet, and anything described as a hub for your hubs. All of these are downstream of having automations worth displaying, and most people build them long before they have those.

The craft of this hobby is not wiring and it is not configuring a platform. It is deciding what should happen, and expressing that decision in a form that keeps working when the sensor battery dies, the internet drops, the clocks change and somebody who did not build it walks into the room. That skill is the same on every platform and it does not go stale, which is why it is written here while no product is named anywhere on this page.

Everything below is a rule, a structure or a decision rather than a physical skill, which is exactly the kind of thing writing is good at. The physical half of the hobby is not here. Anything behind a faceplate is electrical work governed by the boundary set out in the safety section, and this page publishes no wiring procedure of any kind.

The unit of work

Trigger, condition, action

Where beginners fail

The condition, almost always

The shift that matters

Events to state

The test of a good automation

Nobody notices it

• Trigger, condition, action — and the condition is the craft — Every automation on every platform has this shape. The trigger is what starts it: motion, a door opening, a time, a temperature crossing a threshold. The action is what happens. Both are easy. The condition is the test that decides whether the action should happen *this* time, and it is where nearly every bad automation goes wrong. "Motion in the hallway turns the light on" is a trigger and an action with no condition, and it will turn the light on at midday, when the room is already lit, and when somebody is asleep on the sofa. Beginners add automations; people who are good at this add conditions to automations they already have.
• Think in states, not in events — The single conceptual shift that separates a system that works from one that keeps surprising people. An event is a thing that happened — the door opened. A state is a thing that is true — the door *is* open, the house *is* empty, it *is* dark outside. Event thinking produces automations that fire once and are then wrong forever, because nothing re-checks them: the light came on when you arrived and stays on after you leave. State thinking asks what should be true given how the world currently is, which means the system corrects itself when something is missed. If you find yourself writing an automation to undo another automation, you have written the first one as an event and it should have been a state.
• Scenes decide what, automations decide when — A scene is a saved set of device states — "evening" putting four lamps at particular levels. An automation is a rule about when to apply one. Keeping these separate is the difference between changing your evening lighting in one place and changing it in nine, and the mistake is to bury the device settings inside each rule. Build the scene first, then write the rules that call it. This is the closest thing this hobby has to a refactoring discipline and it pays back within months.
• Design for the failure, because the failure is routine — Batteries die, radios drop packets, hubs reboot for updates, and the internet goes down. These are not edge cases; they are Tuesday. The question to ask of every automation is what it does when its input is *missing* rather than false — a presence sensor that has stopped reporting is not the same as one reporting nobody home, and a system that treats them identically will lock somebody out or leave the heating off for a week. Prefer rules that fail towards the house behaving normally, and be especially careful with anything whose failure mode is a cold house, a dark stairwell or a door.
• The manual control is a design rule, not a courtesy — Every automated thing keeps a physical control that works with the automation switched off, the hub unplugged and the phone flat. This is the rule that decides whether other people in the house tolerate the hobby, and it is also the honest accessibility position: a house that only answers to one person’s phone excludes visitors, children, carers and you on a bad day. It is much easier to hold as a rule from the start than to retrofit after somebody has stopped using a room.
• Watch the dependency chains — Automations that trigger other automations are how a system becomes unexplainable. Two rules that each look correct can loop, race, or fire in an order neither author considered — the classic being a humidity rule and a fan rule that turn each other on and off all night. Keep chains short and deliberate, prefer several rules reading the same state over rules calling each other, and when something inexplicable happens look for the second rule before you look at the device.
• Naming and documentation are technique, not admin — The room that behaves oddly in eighteen months is a rule written tonight and forgotten. Name devices for where they are and what they do rather than for what they are — "hall ceiling" not "Zigbee bulb 3" — because the name is what you will read at 2am. Keep one plain list of every automation and the sentence explaining what it is *for*, which is the thing that cannot be recovered by reading the rule itself. This is the highest-value unglamorous habit in the hobby and its absence is the commonest reason people abandon a system they built.
• Test by simulating the state, then by living in it — Every platform can force a state for testing, and the beginner habit of waiting until dark to see whether the dark rule works wastes weeks. Simulate first. Then leave it alone for a fortnight before adding anything on top, because the failures that matter are the ones that need a Tuesday in February, a guest, or a flat battery to appear — and a system with six untested rules stacked on each other cannot be debugged from either end.

The non-electrical risks, which are about dependence rather than danger:

• Never automate the only way in — A smart lock with no key, a garage door with no manual release, a boiler with no physical thermostat. The failure mode is not dramatic — it is a flat battery on a wet evening — and the rule is simply that every automated thing keeps a working manual path.
• Do not put life safety on a hobby project — Smoke and carbon monoxide alarms should be proper alarms meeting the relevant standard, mounted where they should be. A sensor that also tells your phone is a fine addition and a terrible replacement.
• Heating automations affect people who did not agree to them — Anybody vulnerable to cold in the house is relying on the heating working in a way they understand. A clever schedule that saves money and leaves somebody cold is not a good automation.
• Anything on the internet is on the internet — Cameras and microphones inside a home are a category of their own. Change default passwords, keep firmware current, and treat any device that must reach a vendor cloud as a device somebody else can see.
• The household has to be able to use it — The genuine hazard of this hobby is a house only one person can operate. It is also the commonest reason people abandon it.

• Ecosystem-led — Picking one manufacturer’s platform and staying inside it. Everything works, nothing needs configuring, and the ceiling arrives early — usually at the first automation the vendor did not anticipate. A perfectly reasonable place to stop, and worth naming as a choice rather than a failure.
• Hub-led and local-first — A coordinator of your own running the logic, with devices from many manufacturers behind it. More setting up, no dependency on somebody else’s servers, and the branch where the local-versus-cloud decision on this page actually bites.
• DIY device building — Making the sensors and switches rather than buying them, on cheap microcontroller boards with firmware that presents them to the hub. Overlaps heavily with microcontroller projects, which has its own page, and is where the battery arithmetic on this site gets used.
• Energy and monitoring — Automation aimed at measuring rather than actuating — consumption, generation, tariff-following, heating. The branch with the clearest payback and the one growing fastest in Britain for obvious reasons.
• Accessibility-led — Automation built so that a house can be operated by somebody who cannot easily operate its switches. Changes the priorities completely: reliability and predictability stop being preferences and become the whole specification.
• Media and presence — Whole-house audio, screens, and the presence detection that makes rooms respond. The branch that most often turns into an arms race with the people who live there, and the reason the manual-control rule on this page exists.
• Security and access — Cameras, locks and alarms. Named separately because it carries obligations nothing else here does — recording, data retention and the position of any insurer are questions before they are projects.

The first stage is switching things remotely, which feels like the hobby and is not. The second is sensors, where the house begins responding to the world without you — and this is the point most people describe as the moment it became interesting.

The third stage is where it becomes a systems hobby: presence detection, conditions that combine several inputs, and the slow discovery that most of the craft is in the exceptions. Nearly everybody arrives at the same conclusion here, which is that reliability beats capability — an automation that works every time is worth several that work usually.

Beyond that the branches are real. Some people go towards energy, which is the version with a measurable payback. Some go towards building their own devices, which is where this meets microcontrollers and electronics and where the hobby stops being shopping. Some go towards local-only independence, rebuilding to remove every cloud dependency. And some stop, deliberately, having got a house that works — which is a legitimate end state and one the hobby is oddly bad at admitting.