This article is posted here with the consent of the author. The views and opinions expressed in this article are those of the author and do not necessarily reflect the official policy, position, view, or opinion of Crestron Electronics, Inc., or of any of its employees. Crestron Electronics is not responsible for, and does not verify the accuracy of, any of the information contained in this article.

By Jon Ottesen

How to use IoT for “meet in the room” automation with displays, scheduling systems, and UC room systems support.
 
IoT today
In the 1980s a pair of academics decided to use a network connection to gather information on the number of soda bottles in a vending machine and for how long they’d been in there. (The "Only" Coke Machine on the Internet). With this data one could determine which button could be pressed to provide a cold bottle of soda. In a nutshell, IoT is a set of interrelated networked services and devices that exchange meaningful data to reduce human-to-human or human-to-machine interactions. In the mid-1990s, AV and IT met up in Ethernet-connected room control systems. This is when AV joined the IoT world and has kept pace as IoT has evolved. 
 
A great example of IoT in action is the Crestron XiO Cloud® platform and Crestron Flex UC room systems.  Using Crestron XiO Cloud to pre-configure groups with settings based on a device type, when that device is claimed into that group it receives its settings and is ready for credentials.
 
Another example is the TSS scheduling touch screen and a POE occupancy sensor with Microsoft Exchange Server®, Google Calendar™, or Office 365® software. Not only can you configure and manage the devices, but you can also pair act as an IoT room availability manager.  The scheduling touch screen pairs with the occupancy sensor and connects to the resource account for the space and can decline a meeting for no-show.
 
“Meet in the room” is just that; install both systems in the same space, configure, operate, and support the systems via an IoT infrastructure. Together, the systems provide a self-managing room with support services integration. Crestron Flex, TSS, and POE occupancy sensors have Crestron XiO Cloud for alerting and management. Microsoft Teams® and Zoom Rooms™ software have their respective admin portals, as well. Awesome. But there is a gap – the displays. What ensures their operational state? How do they notify the support systems when there is an issue?
 
The gap
To a computer, every display is a PC monitor. This means that all UC room systems expect the video outputs to be PC monitors and act like them. It is fair to say that many of the displays in the UC rooms are not PC monitors. No biggie. Configure the display’s power and standby settings and it is all good – until it’s not. The typical approach to managing the displays is to add a control system and perform custom programming, unless you have Crestron Fusion® software and displays with embedded Crestron Connected® technology. But what if you don’t? There is a better way for the displays to align with IoT concepts for interacting with support services systems directly. What does that look like?
 
The solution
The IoT concepts for this application are automation, management, and configuration of the control environment and programs for displays in non-integrated spaces. The primary method of interfacing is via APIs; user interfaces are secondary and mirror the features and functions of the API. The implication is that after server configuration is complete scripts and configuration files can be used to build up and manage the solution. 
 
Start with centralizing the programming using Virtual Control (VC-4). VC-4 is a server-based (Ubuntu® 16.04 LTS OS) control platform providing a RESTful API for the creation, configuration, and management of Software Defined Control Systems. This includes managing interfaces and configuration files that make up the Software Defined Control Systems. These programs are created with C# using the VC-4 packages posted here https://www.nuget.org. The server hosting VC-4 should have the same resiliency and redundancy configuration as any server in the environment.
 
The functional needs of the programming break down into two operational silos: interacting with various displays and producing/consuming data via APIs. In this case, there are lots of producers (displays) and a few consumers (service APIs) for the data. One programming architecture option for this application is referred to as a Broker pattern. The Broker pattern breaks up the tasks between “Display Daemons” for the devices and a “Broker” providing a single point for all API interfacing.
 
The Broker should expose a keyed RESTful API and a WEB UI for configuration and management of the Display Daemons data, fulfilling the requests for data and pushing error notifications to the ticketing system on the Daemon’s behalf. This implies a couple of things. First, the broker will store the Daemon’s data and have direct access to that data. Second, there is a user interface component. The UI is added so the solution can be used if automation is future state. 
 
This Display Daemon should support the configuration of the CCD framework for up to two displays via an API and a WEB UI. The Display Daemon should allow for an optional configuration to pair with a Crestron Flex room system and a Crestron POE occ sensor to awaken the Crestron Flex system and the displays upon occupancy.  It ensures that the displays are online, in an operational state, provide corrective action to maintain that state, and report any changes and failures to the “Broker.” The UI is added to allow for configuration without automation, like the Broker. With every display manufacturer having a different control protocol, how do you get consistent status in that environment?
 
The Display Daemon should use Crestron Certified Drivers (CCD) and its SDK as a framework to overcome the challenges presented by the lack of a common communication protocol shared by the different display manufacturers. Think of a universal translator using a driver file for the display and providing a standard interface to the broker and user interfaces. Using this framework means that having to recompile the program for each display configuration is not necessary. Crestron has a library of certified drivers at drivers.crestron.io (login required). If a driver does not exist, it can be created using the CCD SDK. For serial devices, use a CEN-IO-COM-102 or a CEN-IO-COM-202 for connectivity to the display(s).
 
Here is the solution in a picture: