Commissioning and Handover Checklist for Smart-Home Projects
A gate-by-gate checklist for the last week of a smart-home job: naming and labelling, function and failure tests, security, backups, owner training, acceptance and the handover pack. Works for wireless, Matter and KNX systems.
By Abhi Bavishi, Founder, Smartify
Technical review pending
At a glance
You will learn
- Run six pass-or-fail gates before handover
- Test functions and failure cases with the client present
- Hand over a pack the client can keep
You need
- The device inventory
- Time with the whole household
Key takeaway
A job is finished when someone who did not build it can run it, and the client has accepted it.
Open the commissioning and handover checklist →
Key terms in this lesson (3)
- As-built drawings
- Drawings that show what was actually built, not what was designed.
- Commissioning
- The last stage of a job, where you prove that every function and failure case works and hand the system over. In Matter it also means adding a device to a controller.
- Snag list
- The record of what remains after handover testing. Every item has an owner, a target date and a status.
Short answer: run six pass/fail gates in order. Put failures on a snag list with an owner and date. Finish with client acceptance and a handover pack another installer can use. Use the printable checklist to record results on site.
See local control and load planning for supporting tests.
Safety first
A qualified electrician handles mains work: isolate at the MCB, test dead, and follow maker diagrams and local rules. Agree who performs power-cut tests and warn the household before switching supplies.
Gate 1: inventory, naming and labelling
Keep names consistent and protect setup-code records for future re-commissioning.
| Done | Item |
|---|---|
| ☐ | Every device that draws power or joins the network is in a device inventory. If it is not listed, it is not commissioned |
| ☐ | Each entry has a stable ID, the friendly name, model, where it is, which circuit or MCB feeds it, how it connects (Zigbee, Thread, Wi-Fi, KNX) and the firmware version at handover |
| ☐ | One naming convention is used everywhere: hub, app, labels on the distribution board and in the documents |
| ☐ | Circuit labels at the distribution board match the inventory (done by or with the electrician) |
| ☐ | Matter devices: the QR code or numeric setup code is photographed and stored with the inventory |
Gate 2: network and radio
Confirm the chosen network arrangement still supports the required local control paths.
| Done | Item |
|---|---|
| ☐ | Walk-test of Wi-Fi in each room, and of the radio coverage for Zigbee or Thread devices, with results recorded. See signal range in RCC homes |
| ☐ | Hubs, border routers and access points have fixed addresses or address reservations in the router, so they do not move after a reboot |
| ☐ | IoT devices and cameras are separated from the family’s laptops and phones (a separate network or guest SSID), if the router allows it |
| ☐ | Wi-Fi channel and Zigbee channel recorded; coordinator location recorded |
| ☐ | Wi-Fi network name, router admin login and ISP details are recorded in the handover pack, not in your head |
Gate 3: every function, every control path
Test the functions actually promised and record exceptions.
| Done | Item |
|---|---|
| ☐ | Each load can be switched from each control: wall switch, app, remote, voice, scene, schedule, sensor trigger |
| ☐ | App state follows the wall switch and the other way round |
| ☐ | Every scene and automation is triggered on purpose and the exact result is checked, and nothing else happens as a side effect |
| ☐ | Each load’s behaviour after a power cut is tested and matches what was agreed (off, on, last state) |
| ☐ | Lights tested for glow, flicker and buzzing with the actual lamps fitted. See retrofitting existing switchboards |
| ☐ | Motors (curtains, blinds, pumps, fans): full travel, limits, obstruction behaviour and manual use tested. See curtain and blind motor installation |
Gate 4: failure tests
Run with the client present and record pass/fail.
| Done | Failure | Expected result |
|---|---|---|
| ☐ | Internet disconnected, everything else powered | First and second tier functions from the local-control lesson still work. Voice, remote access and notifications are documented as internet-dependent |
| ☐ | Hub or controller restarted | Devices rejoin, no load changes state unexpectedly, recovery time noted |
| ☐ | Router or access point off | Result noted and explained to the client |
| ☐ | Power cut at the MCB and restore | Backup equipment behaves as designed; loads return in the agreed state; network recovery time noted |
Gate 5: security and backups
Keep regular backups on another system, ideally off-site. For Home Assistant, preserve the emergency kit needed for encrypted restores. Record the Zigbee2MQTT coordinator backup location where applicable.
For KNX, preserve the ETS project, group addresses, control philosophy, schematic, wiring schedules, functional layout and BOM.
Do not email passwords or put them in chat. Use the client’s password manager, sealed print or controlled vault; reset the owner password at handover.
| Done | Item |
|---|---|
| ☐ | Default passwords changed on the router, hub and every app or device that allows it; unique admin credentials where possible |
| ☐ | Firmware updated to a tested baseline and the versions recorded |
| ☐ | Owner accounts created in the client’s name, with two-factor authentication where available |
| ☐ | Your own working accounts and shared test logins removed or retired. Previous installers and vendors no longer have administrative or user access |
| ☐ | Unneeded remote access or cloud features turned off, and the ones left on are listed |
| ☐ | The hub or controller configuration is backed up, a copy is kept somewhere other than the device itself, and the restore steps are written down |
Gate 6: training, acceptance and the snag list
Acceptance records date, attendees, tested functions/results, snags, warranty start and signatures. Close each snag by fixing it or obtaining written agreement; a small snag need not block the whole handover.
| Done | Item |
|---|---|
| ☐ | Everyone in the household who will use it, including domestic staff who operate lights and locks daily, has used each key function themselves, not watched you do it |
| ☐ | A one-page quick-start is left on the premises, and a short video walkthrough is stored in the pack |
| ☐ | A scripted acceptance walk-through is run with the client and signed |
| ☐ | The snag list records every open item with an owner, a target date and a status |
| ☐ | Warranty start dates are recorded; support and AMC contacts are written down |
The handover pack
Give printed and digital copies. Keep your inventory and acceptance records.
| Item | Format | Note |
|---|---|---|
| As-built drawings and network map | PDF and print | Shows what was built, not what was designed |
| Device inventory | Spreadsheet | The live copy for future service |
| Warranty and model register | Scanned | Model, serial number, purchase date, expiry |
| Credentials | Sealed or in the client’s vault | Owner password reset at handover |
| Setup codes, QR codes | Photographs stored with the inventory | Needed to re-commission Matter devices |
| Backup locations and restore steps | Document | Includes the KNX project file where relevant |
| One-page quick-start | Short enough to stick on a wall | |
| Acceptance sign-off and snag list | Signed sheet | |
| Support and AMC contact | See quoting a smart-home project |
Common mistakes
Do not skip failure tests, leave the only backup on the hub, hand over installer passwords or train only the person who signed the quote. The app alone is not a handover pack.
Where to go next
Check yourself.
Questions from real jobs. Think first, open the answer, then say how you did. The score is for you and stays on this device.
Why should you not email the client the passwords?
Hand credentials over through the client's own password manager, a sealed print or a vault entry they control, and reset the owner password at handover.
Is a backup stored only on the hub enough?
No. Keep a copy on another system, ideally off-site, and write down the restore steps.
Sources
- Studio Matrx: smart home commissioning and handover in India
- Online Trust Alliance / Internet Society: smart home checklist
- Home Assistant: backups (common tasks)
- Home Assistant: Matter integration (setup codes, fabrics)
- Ivory Egg: a guide to the documentation required on a KNX project
- Zigbee2MQTT: FAQ (coordinator backup file, re-pairing)