What This Checklist Is For
Commissioning an exhibition hall is not the same as commissioning a meeting room. The distinguishing requirement is unattended operation: the hall must open and close on schedule, day after day, without a technician present, and it must recover from a power cut on its own.
Most commissioning failures in exhibition work are not "it doesn't work" — they are "it worked on handover day and stopped working three weeks later". This checklist is organised around preventing that.
Phase 1: Before You Go
- Collect the RS-232 / IP control specification for every model on site. Not the brand — the model. Command sets differ across generations within one brand.
- Confirm which control transport each device supports — serial, TCP, HTTP, PJLink. Prefer network where available; it removes cabling, COM-port assignment and the crossover question in one move.
- Check whether devices ship with serial control disabled. Optoma requires a remote-key sequence to enable it; many LG consumer TVs need a service menu.
- Pack a terminal program that can send hex — PuTTY cannot, and half of AV protocols are binary.
- Pack a null modem adapter. It converts any straight-through cable on the spot. See null modem vs straight-through.
- Pack a USB-to-serial adapter with a genuine FTDI chip. Cloned chips enumerate but never pass data.
Phase 2: Network
- IP plan documented before anything is configured. Static addresses for all controlled devices — DHCP leases changing overnight is a classic cause of "it stopped working".
- Control devices and the control PC on the same subnet where possible. This is a hard requirement for Wake-on-LAN and for Art-Net broadcast.
- Lighting on its own VLAN or physical network if using Art-Net at scale — broadcast traffic reaching every media PC is a real load.
- IGMP snooping: exactly one querier, if snooping is enabled. Zero breaks multicast discovery, two fight. Affects Dante and sACN.
- No second DHCP server on the network.
- Record every IP, MAC and port in the handover document as you go, not afterwards.
Phase 3: Per-Device Verification
Do this with a terminal, before touching the control system. This is the single highest-value discipline in commissioning: it proves the device independently, so that any later problem is definitively in the control configuration.
For each device:
- Link established — a bare terminator or query returns something. Epson returns
:to a bare CR; PJLink greets on connect.
- Record the working serial parameters — baud, parity, data bits, stop bits. Do not assume 9600/8/N/1: Sony is 38400/8/Even/1, Modbus RTU is often even parity, legacy Barco is 19200.
- Record the working terminator — CR, LF, CR+LF, STX/ETX, or none. See command format.
- Power on and power off both verified. Test them separately — power off working proves nothing about power on.
- Input switching verified by observation, not by table. Switch the input by hand, then query the device and record what it actually returns. Published input-value tables are model-specific and frequently wrong.
- Any checksum recomputed, not copied. If a table's checksum fails the protocol's own rule, trust the rule. We found a widely-circulated Samsung Ex-Link power-on code that fails its own checksum this way.
- Status query works — you will need it for the control logic, not just for testing.
Phase 4: The Unattended-Operation Settings
This phase is what separates an exhibition install from a meeting room, and it is where handover-day-success turns into week-three-failure.
Displays and projectors
- Standby power mode set so the control receiver stays alive. In deep eco standby the serial/network receiver is off, producing the signature symptom: power off works, power on never does. Specific known cases: BenQ needs standby power at 0.5 W; Samsung displays need the wake-from-sleep setting to accept RS232/Ethernet.
- Samsung: ID Settings → PC Connection Cable set to "RS232C cable". Without it the port is logically disconnected.
- Cooling-period delay built into every power-off → power-on sequence. NEC refuses commands while cooling; Barco wants 30 seconds after power-up; Panasonic has a 10–60 second blackout after the lamp strikes.
- On-screen feedback disabled. Barco's OSD messages in a gallery during opening hours are unacceptable — set
OSDCto 0.
- Auto power-on-after-mains configured where the building cuts power at night.
PCs and players
- BIOS: Wake on LAN enabled, PXE/network boot disabled, SSD first in boot order. Network boot ahead of the SSD produces the
Checking Media Presencehang. See Wake-on-LAN not working.
- BIOS: restore on AC power loss = On. WOL alone does not survive a nightly power cut, because the NIC may not re-arm until the machine has booted once.
- Windows Fast Startup disabled. It breaks wake-from-shutdown on many NICs.
- NIC: "Allow this device to wake the computer" and "Wake on Magic Packet" enabled.
- Verify the link LED is lit with the machine powered off. If it is dark, WOL cannot work and no software setting will change that. Ten-second test, eliminates an entire branch.
- Windows Update disabled or scheduled outside opening hours. An unattended reboot mid-exhibition is a client-visible failure.
- Auto-login and auto-start of the playback application configured and tested by full power cycle.
- Screen saver, sleep and display-off all disabled.
The verification that matters most
- Full cold-start test: cut mains to the whole hall, restore, and let it come up untouched.
This is the single test that predicts week three. Everything else can pass while this fails. Do it at least once, ideally at the end of a day so you can leave it off overnight and check in the morning.
Phase 5: Control System
- Every command in the control system is one that was verified in Phase 3. No commands typed in from a PDF and never tested.
- Delays inserted where the device requires them — cooling periods, lamp-strike blackouts, the 30-second Barco wait.
- Power state confirmed by query, not assumed from the send. Panasonic echoes commands in standby, which naive systems read as success. WOL has no reply at all — poll the machine to confirm it woke.
- Scene/sequence tested from every starting state, not just from all-off. Operators press "open hall" when things are already half on.
- The all-off sequence tested last thing, since it is the one that runs unattended.
- Third-party integration framing documented — if another system sends commands to yours, state the terminator, connection style and max length. See UDP works but TCP doesn't.
Phase 6: Handover
The client's staff are not AV technicians. The handover should let a receptionist open the hall.
- One-page operating instruction with the two or three buttons they actually use.
- What to do when a display does not come on — the one procedure that covers 80% of incidents.
- Device schedule: model, location, IP, MAC, COM port, serial parameters, control transport.
- The verified command list, with the values you observed rather than the values in the manual.
- Named contact and response expectation.
- Photos of the rack, labelled, and photos of the BIOS settings you changed. In two years nobody will remember why the boot order looks like that.
The Failure Modes This Checklist Is Built Around
Ranked by how often they cause a call-back:
- Standby power mode — power off works, power on does not, three weeks later
- No cold-start test — the hall never comes back after the first real power cut
- Commands copied from a PDF, never verified — wrong input values, bad checksums
- Windows Update / Fast Startup — unattended reboot, or wake stops working
- DHCP on controlled devices — addresses move overnight
- No delay for cooling — the second command in a macro vanishes
- Trusting a send as confirmation — echoes and fire-and-forget protocols read as success
Six of those seven are configuration, not hardware. They cost nothing to prevent during commissioning and a site visit each to fix afterwards.
With SoftControl
SoftControl covers serial, TCP, UDP, HTTP, PJLink, Modbus and Wake-on-LAN in one interface, so an "open the hall" macro can wake the media PCs, power the projectors, switch inputs and set the lighting scene as one sequence — with per-command delays for the cooling and warm-up rules above.
Its command tester shows the request as text, bytes and hex plus the raw reply, which is what makes Phase 3 verification quick: you can confirm a device's real behaviour and keep the working command, rather than transcribing from a manual and hoping.
For the protocol overview see AV control protocols explained; for a worked deployment see the museum control system case study.