The Hidden Challenges of AV Control Programming

• January 3, 2022
• Steve Greenblatt

While most AV manufacturers build their products with integration in mind, the effort to control third-party AV devices can still be a challenge.

In the early years of integrated AV systems, control and automation were accomplished with purpose-driven equipment hardwired to provide specific user interaction. These systems were essentially fixed in their functionality with little room for adjustment or preferential modifications once it was designed and built. As software-driven, programmable systems became more of the norm, an AV programmer’s role was born and the ability to deliver fully customized solutions became more of a reality. During that time, in the early ‘90s, the idea of simply touching a screen in one location and making an action of your choice happen somewhere else was mind-blowing and often described as magic.

As the idea of programming was still fairly new to the AV industry, dedicated programmers were uncommon, and a programmer’s role was often misunderstood. In many cases, the individual who was the most computer literate, the most comfortable working with software, and who best understood AV systems was dubbed the programmer by default. The ability to write code effectively—or being knowledgeable about computer science at all, for that matter—was a bonus. Initially, effective AV programming meant getting devices to communicate with a central controller, getting the system to work reliably, and providing the required controls for user operation. Optimal user interface design, customized user experience, modification and management of source code, enterprise standards, and scalability did not enter the conversation until years later.

[ How to Get Started at AV Programming ]

As time passed, it became clear that an effective AV programmer needed to possess a lot more than simply just computer skills. In addition to the software component (which itself is an art), programming AV systems requires understanding of how these systems work from a signal flow perspective, what each individual component needs to do to create an outcome, the sequences and logic necessary to make the system operable for the user, and how to effectively and reliably control each device in the system.

[ How Software Alternatives Can Address Hardware Supply Chain Issues ]

One of the challenges that accompanied the dawn of programmable AV control systems was simply that manufacturers were reluctant to release information about controlling their devices. Although infrared and relay controls were easier to solve through “learning” remote control codes and reverse-engineering wiring configurations, serially controlled devices were not as straightforward to decipher without product-specific information including their unique command set and control port pinouts.

Over time, more manufacturers readily published details about controlling their devices in an effort to encourage third-party integration; however, many remained protective of this information by default. Despite a product’s ability to support external control, it was common for manufacturers to reserve this feature for their own proprietary needs, such as integration with approved equipment like purpose-built controllers or other complementary products. The idea of integrating disparate equipment together with a third-party control system was a foreign concept to many AV product manufacturers—thus obtaining a control protocol and the pinout of a serial communication port in order to communicate with a device was a challenge in its own right for AV programmers. Delving a little deeper, the lack of standard control codes, commonalities amongst device types, or consistencies within products developed by the same manufacturer further contributed to the difficulty of device control and a programmer’s quest to succeed.

[ SCN Hall of Fame 2020: Steve Greenblatt ]

The variations and range in complexity of a serial command set specified by device manufacturers can be significant. Some devices support simple, readable text, while others utilize numbers and characters that are representative of low-level computer values, adding complexity to the already demanding task of device control. Not only do programmers need to obtain control information for devices and know what functions are needed for a particular application, but they also need to understand how to effectively interpret and implement the commands once they are obtained.

New Set of AV Programming Challenges

Some devices maintain a simple command set for both their dedicated serial connection and their network communication using Internet Protocol (IP); others support a separate approach to network control that does not use the same commands as the serial interface. Instead, these devices turn to a different method of network communication using HTTP and a common format like a REST API. This modern IT approach that is growing in popularity lends itself to ease of integration with webpages, software applications, and IoT devices in addition to support for third party control systems. Furthermore, since network communication does not have the inherent privacy of a point-to-point serial connection, more manufacturers are embracing the responsibility of implementing secure communications to make their products more IT-friendly and respect network safeguards. With security naturally comes complexity and extra requirements to implement effective device control. It is this shift toward standardized network communication and the influence of security requirements that has become the modern-day challenge of AV device control.

Just as AV programmers are benefiting from friendlier device controls using serial and IP communication, more manufacturers’ products are now leveraging web services in response to the rise in demand for interoperability between devices and software that include the exchange of information for monitoring and control. While this move makes the integration of products more accommodating to modern software developers leveraging mainstream programming languages, it prompts the need for AV control systems and programmers to evolve their capabilities and skill set.

While becoming an AV programmer 30 years ago was a feat that simply required computer literacy, understanding of AV systems, logical thinking of system operation, and the challenge of obtaining and implementing device control protocols—much of the mystique has subsided with the growing number of no-code, configurable control solutions. As we evolve in the era of network-based AV systems, device control requirements have evolved and there is a new need for programmers who possess the skills required to enter the realm of software development just to effectively address these advanced requirements. Some AV programmers will embrace this opportunity to leverage modern programming languages and build the software skills required to tackle the challenges of network communication that now exist for successful device control. Others will be more comfortable mastering the configuration approach that leverages device control middleware and the other pre-developed software pieces needed to deliver working solutions. Although there are ample opportunities for those who pursue either path, it is important to understand the differences and be aware that there is an industry need for both to exist. While it may seem like AV programming has become simplified to the point where advanced knowledge is no longer required, the challenge of interfacing with third-party equipment will continue to be needed to support configured and programmed systems, as well as provide opportunity for those AV programmers who are ready to evolve their skills.

Steve Greenblatt, CTS, is president and founder of Control Concepts, a provider of specialized software and services for the audiovisual industry.