Commissioning, testing and handover are three different things
The three words get used interchangeably in quotes, and separating them makes it much easier to see what a project is actually offering.
Commissioning is configuration. Devices are addressed, curtain limits are set at the fabric, dimming ranges are trimmed to the lamps that are fitted, keypads are assigned, scenes and schedules are written. It is the point where a collection of installed hardware starts behaving like a system.
Testing is proof. Each function is exercised deliberately, one at a time, and the result is recorded. Not assumed from the fact that it was configured, and not inferred from the fact that a neighbouring circuit works.
Handover is transfer. Understanding, documentation and control all move to the owner. A project can be fully installed, fully commissioned, and still not handed over, which is a more common state than it sounds.
What actually gets tested
Good testing is repetitive and slightly boring, and it is worth being present for at least part of it. The point is to find the one keypad button that was engraved for the wrong room before you find it on a Thursday evening with guests in the house.
- Lighting: every circuit taken through its full dimming range, with attention to the bottom of the range where flicker and drop out show up, then every keypad button checked against what its engraving claims, and every scene recalled from a cold start.
- Curtains and blinds: open and closed limits set to the fabric, obstruction behaviour tested by obstructing something, sheer and blackout layers moved independently and together, and the exact position each scene leaves them in confirmed.
- Climate: control proven at each unit for on and off, setpoint, mode and fan speed, the setback behaviour actually triggered, not assumed, and the schedule watched as it fires.
- Entry: the door station calling every answering point, the gate opening, stopping and reversing on obstruction, locks releasing on each credential type, and the mechanical override tried with a key in hand.
- Cameras and sensors: each camera's field of view checked on screen in daylight and after dark, recording confirmed against the retention that was agreed, and every sensor triggered physically instead of being ticked off a list.
- Network: every outlet tested through to its patch panel port, access points confirmed on the network they are supposed to be on, and the labelling checked against what the test found.
- Power interruption: the system taken down and restored, so it is clear what returns on its own and what waits for a person.
- Connection interruption: the internet link removed, so you can see for yourself which functions keep working locally and which pause until it comes back.
- Batteries: every battery powered device recorded with its type and location, because the one you can't find is the one that goes flat first.
The records that should exist at the end
Documentation is what makes a system serviceable by somebody who wasn't there when it was installed. That includes the next engineer, the next owner, and you in four years when the reason for a rule has faded. The list below is document types, not paperwork for its own sake; each one answers a question that gets asked eventually.
- A device schedule: every controlled device, what it is, where it is, which circuit or controller it sits on, and the name it answers to in the system.
- Wiring and as built records: what was installed where, the cable routes and containment used, and how the finished installation differs from the design, because it always differs a little.
- A board and circuit schedule: each way in the distribution board, what it feeds, and labelling that matches the physical labels on the board itself.
- Scene and schedule documentation: each scene by name, the rooms and circuits it touches, the levels it sets, and any condition that triggers it without being asked.
- A network map: outlets and their patch panel ports, switch ports, access point positions, address reservations, and how the networks are separated from each other.
- Camera and sensor documentation: positions, what each covers, the retention setting in use, and the accounts that can view footage.
- A credentials record: which accounts exist on which system, what level of access each has, and who holds them.
- Manufacturer documentation for the equipment installed, so the model actually on your wall can be looked up without guesswork.
- For a rented property, a record of what is removable and how, with the original parts kept and labelled.
- An open items list: anything left to finish, revisit or watch, written down instead of remembered.
Labels are part of the handover
Documents only help if the building agrees with them. Cables labelled at both ends, ways labelled on the board, ports labelled on the patch panel, keypads engraved for the room they control, and equipment labelled where it lives. The test for all of it is simple: an engineer who has never seen the property should be able to stand in front of the rack, read the records, and know what is in front of them.
This matters most in the places nobody looks at during the project. The network cabinet is the clearest example, because it is where every trade eventually terminates, and it is the first place anyone opens when something stops working.
The training walkthrough
Training is where a good installation becomes a used one. It should involve everyone who lives with the system, not just the person who commissioned it, and that includes whoever runs the house day to day.
The order matters. Wall control first, app second. If the household learns the system through a phone, the keypads never get used and the house feels complicated to anyone without the app installed. Teach the failure path as well as the demonstration: what to do when a device stops answering, how to get a room back to plain manual light, and where the mechanical override on the front door actually is.
A second, shorter session once the household has lived with the system for a while is usually worth more than a longer first one, because by then the household knows which questions it actually has. Scene names, lighting levels and schedule times are all easier to discuss once somebody has been irritated by them.
- How each keypad works in the rooms that matter, including what a long press or a double press does if anything.
- How to override a scene, and how the system behaves afterwards, since an override that never releases is its own kind of fault.
- How to change a schedule time, rename a scene and adjust a level, which are the three changes households ask for most.
- How to add and remove access for a guest, a housekeeper or a contractor, and how to check what has been used.
- What happens when the internet is out, demonstrated rather than described.
- Where the manual controls are for the gate, the door lock and any motorised curtain, and how to operate each one by hand.
- Who to contact when something needs attention, and what information to have ready when you do.
Credentials and ownership
This is the part that decides whether you own a system or merely use one. The administrator accounts should be in your name: the controller, the network equipment, the recorder behind any cameras, and any manufacturer account tied to the installation. Factory passwords should be gone before anyone leaves the property, and that should be demonstrable.
Your installer will usually keep access so support is possible without a visit, and that is sensible. The distinction that matters is that their access exists because you granted it and can be withdrawn by you. A system whose only administrator account belongs to the contractor is a system you can't change contractor on, which is a commercial arrangement dressed up as a technical one.
The settling period after handover
The first configuration of any system is a set of reasonable guesses about a household nobody has lived alongside yet. Corridor timeouts feel too short. The evening scene is a shade too dim for reading. A rule that made sense in March needs looking at again in July, when the sun is somewhere else and the house is empty during the day.
That's normal, and it is why handover is a stage in a project instead of the end of one. What is worth agreeing in advance is how post handover changes are handled: what you can adjust yourself from the app or a keypad, what needs a visit, and how requests get raised. Get that clear at the same time as the documents, while everybody still has the project in mind.
Why this matters in year three
The value of a documented handover shows up long after the project has been forgotten. A motor fails and the schedule says which one it is and what it sits on. A room gets repurposed and the scene documentation says exactly what changing it will affect. The property is sold, and the new owner inherits a system that can be explained instead of a mystery that gets ripped out.
Undocumented systems get replaced when they could have been extended. That is the real cost, and it is invisible at the point where a proposal is being compared on price. When you are comparing automation proposals, the handover section is worth reading before the equipment list, because it tells you what you'll be left holding.
Questions worth asking before you sign
None of these require technical knowledge to ask, and the answers separate a system supplier from a fit and forget one quickly.
- What documents will I receive at handover, and who prepares them?
- Will every circuit, cable and port be labelled at both ends to match those documents?
- Will the administrator accounts be in my name, with factory passwords replaced?
- What is tested in front of me, and what is tested before I arrive?
- Can you demonstrate what still works with the internet disconnected?
- Who delivers the training, who should attend, and can there be a second session once we have lived with it?
- What is on the open items list at the moment you call the project complete?
- If we appoint someone else later, what do they need from you, and will they have it?
In short
Testing proves the system works. Documentation proves what it is. Training proves the household can use it. A project that delivers all three hands over something that can be lived with, serviced and extended by anyone who comes after, and a project that skips them hands over a set of behaviours nobody can explain. The equipment on the wall isn't what separates a good automation project from a disappointing one three years later. The device schedule, the labelled board, the scene documentation, the network map and the accounts in your own name are. Ask what the handover contains before you compare anything else, because that is the part of the specification you keep.
Common questions
Three things. Proof that every function has been tested in front of you, including lighting circuits through their dimming range, curtain limits, climate control at each unit, entry and override paths, cameras and sensors, and network points. A set of records: a device schedule, wiring and as built information, a board and circuit schedule, scene and schedule documentation, a network map, camera and sensor details, and a credentials record. And a training walkthrough for everyone who uses the property, covering wall control first and the app second, plus what to do when something stops responding.
Commissioning is configuration: devices addressed, curtain limits set, dimming ranges trimmed, keypads assigned, scenes and schedules written. It makes installed hardware behave as a system. Handover is transfer: the documentation, the administrator accounts and the household's understanding all move across to the owner, usually with testing demonstrated along the way. A property can be completely installed and completely commissioned while still not handed over, which is exactly the situation that causes trouble years later when nobody can say what was fitted or how to change it.
Yes. The controller, the network equipment, any camera recorder and any manufacturer account tied to the installation should have an administrator account belonging to you, with factory passwords replaced before the project is finished. It is normal and useful for your installer to keep access so they can help without a site visit, but that access should exist because you granted it and be something you can withdraw. If the only administrator account belongs to the contractor, changing contractor becomes a negotiation instead of a decision.
It's the record of what was actually installed, as opposed to what the design drawing said would be installed. Real projects deviate: a cable takes a different route around an obstruction, a device moves half a metre for a fixing, a circuit gets split. As built records capture those changes, along with cable routes, containment, device positions and board schedules. It is the document anyone servicing or extending the system reads first, and it is the difference between a small job and an investigation when something needs attention years later.
They should be, and expecting to is healthy. The first configuration is a set of reasonable assumptions about a household that has not lived with the system yet, so corridor timeouts, evening light levels and schedule times usually want adjusting once real life has tested them. Some of that you can do yourself from a keypad or the app, and some needs someone with access to the programming. What is worth settling before installation starts is which changes fall into which category, and how you raise a request when it is the second kind.
Every controlled circuit through its full range, every keypad button against its engraving, every scene from a cold start, curtain limits and obstruction behaviour, climate control at each unit including setpoint, mode and fan speed, every lock and its mechanical override, the intercom call path and gate release, each camera view in daylight and darkness with recording confirmed, and each network outlet through to its port. Two whole system tests matter as well: a power interruption, to see what returns on its own, and a disconnected internet link, to see what keeps running locally.