Pergola commissioning: test the combinations people will actually use

Turn the supplied configuration into a checklist

List the roof zones, available controls, installed screens and any confirmed sensors or optional equipment. Build the commissioning checklist from that actual package and the supplied instructions. A quotation's optional feature should not appear as a completed test if it was not installed. Identify which items can be demonstrated to the owner and which need the installer's own recorded checks. The purpose is to make the commissioning scope visible, not to create an arbitrary endurance test. Test frequency, sequence and conditions should follow the product procedure and the responsible team's approved plan.

Check interactions, not only individual buttons

A roof and screen may each operate correctly in isolation while users still need clear instructions for combined use. Review the documented relationships among zones, manual commands and protective states. Ask how stop commands, mode changes and return to normal operation are demonstrated under safe conditions. Do not manufacture hazardous weather or bypass protections to complete a box on the checklist. Where a condition cannot be tested on site, mark it as not tested and identify the evidence or later step required. An honest incomplete entry is more useful than a general statement that all functions passed.

A two-zone terrace example

Imagine a terrace with two roof zones and screens serving different sides. The installer demonstrates each motor once, but the owner later discovers that the handset labels do not match the expected area. The hardware may be working while the handover still leaves users confused. A commissioning matrix with device identity, command source, expected action and observed result would expose that mismatch. This hypothetical example illustrates a documentation and usability check, not a claim about any particular control system. It also makes clear why staff training and hardware testing belong in the same delivery process.

Keep results, exceptions and ownership together

Record the date, configuration revision, observed results and any unresolved items. Attach only the photographs or short clips that clarify important observations, without replacing the checklist with a long unlabelled video. Assign each remaining action to a responsible party and record its closure. For a TTH project, this creates a useful baseline for later support: a service team can see what was installed and checked rather than asking the owner to reconstruct the original handover from memory. After a component replacement or control adjustment, update the affected checklist items and retain the earlier revision for traceability. Without that link, an otherwise useful commissioning record can stop corresponding to the installation after maintenance, leaving a later service team unsure which results remain applicable.

• List installed devices, command sources and relevant operating combinations.
• Record expected and observed results, including items not tested.
• Assign unresolved actions and retain a dated configuration-specific handover.