Home automation systems — most houses do not need one

Design review — what the house should do, room by room

A designer walks the property and produces a schedule of what is controlled where: which loads, which zones, which keypad positions, which sensors. This is a drawing exercise before it is a hardware one, and it should be legible to you.

Watch for: A proposal that is a bill of materials rather than a design. If you cannot read what the system will do from the paperwork, neither can the person who has to service it in five years.

Ecosystem consolidation — deciding what everything speaks

Most houses arrive at this point with an accumulated pile: a couple of assistants, some Wi-Fi devices, a hub bought for one thing. Consolidation means choosing a control layer, deciding which existing devices are brought in natively, which are bridged, and which are honestly better replaced than integrated.

Watch for: Everything bridged and nothing replaced. Bridges add a failure point and a delay each; a system built entirely out of them feels sluggish and breaks in ways nobody can diagnose.

Deciding how much runs locally

A system where the logic lives on a controller inside the house keeps working during an outage. A system where automations are evaluated in a vendor cloud does not. Most real installations are a mix, and the question worth asking is which half your important functions fall into.

Watch for: Door locks, garage access and heating on cloud-only paths. Those are the ones you notice at the worst time.

Infrastructure — network, power and equipment location

Controllers, switches and power supplies need somewhere ventilated, accessible and central, with cable reaching it. This gets decided at design stage because it constrains cable routes. Network capacity and access-point placement are part of the same conversation.

Watch for: Equipment stacked in a sealed cupboard or an unventilated loft. Heat is the most common cause of premature failure in this equipment, and the location is chosen once.

Control interfaces — keypads, apps and touchscreens

The best-designed systems are usable from the wall by a stranger. Keypads are positioned and labelled at design stage, apps are secondary, and touchscreens are used sparingly because they date faster than anything else in the house.

Watch for: A design where the phone is the primary interface. Guests, children and visitors do not have the app, and a house that cannot be operated without one is a badly designed house.

Voice control, in proportion

Voice is a convenience layer added on top of a working system, not a foundation for one. It is genuinely useful for hands-full moments and for accessibility. It is unreliable as the only way to do something, it depends on a cloud service for most assistants, and it is worth being deliberate about which microphones are in which rooms.

Watch for: Automations that only exist as voice commands. If the only way to unlock a door or turn a light off is to say something, the system fails for anybody who is not heard, and during any service outage.

Programming, scenes and household testing

Scenes are written, schedules set, and the system is tested by the people who live there rather than by the installer. The useful test is whether someone who was not involved can walk in and operate the house.

Watch for: A handover demo instead of a trial period. Ask for a period of adjustment after you have lived with it — good integrators expect it and price for it.

Documentation, credentials and service arrangements

You should finish with a device schedule, a cable schedule, the programming file or a copy of the configuration, and administrator credentials in your name. What ongoing support costs, and what happens if you use somebody else, should be written down.

Watch for: Programming that only the original dealer can open, plus no copy of the configuration. That combination is the single biggest reason people end up replacing systems that still work.