Define the quantity and compatibility of third-party controllable devices:
- Check each device specification and ensure it is compatible to be controlled by a control processor
- Some devices may communicate using a proprietary control command protocol. If this is the case, these devices may not be suited for third-party control by a control processor
Survey the different control interfaces required for devices within a design. Ensure that they have a way to interface with the control processor.
- If all devices may be controlled by Ethernet, then the devices and control processor must be accessible to each other on a network. This has become the most common method of controlling devices due to its scalability and flexibility.
- If the devices of an AV system feature various control interfaces (RS232, IR, Relay contact closure, et al), these too require a way to get commands back to the control processor. It is common to use control interface expansion devices where a useful AV device does not include an Ethernet port.
- USB is a common method for control of sub-system elements that interface with a PC (e.g. document cameras, meeting room interfaces, PTZ cameras). Ensure that control considerations include USB functionality and that standards and limitations are understood and tested when designing control systems
Understand behaviour of the third-party controllable devices. If the behaviour is logical and predictable, then programming and automation of a device becomes more easily managed:
- If the device ignores incoming messages during its power-up or power-down sequence, make sure any control messages are buffered or delayed until the device is ready to receive messages
- If the device has any default modes or settings, make sure these will not impact the operation of the AV system
- Ensure the device behaviour is predictable. A sequence of commands may need to be included in the control system software to set the device to a known state
- If the device has a sleep timer that puts the device into a standby mode after a period of inactivity, make sure the control system software is able to account for this and only allow a standby state to be managed appropriately whilst maintaining control over the required device.
- If the device requires a handshake message to initiate communications via its control interface, ensure the handshake message is included for all messages sent by the control system software
- If the device requires an open network port to initiate communications via IP, ensure the network port is open and ready to receive messages sent by the control system software
- If the device is able to report its current status, ensure the status information is accurate and applicable for the control system software or management suite used.