The Room Controls feature allows you to control third-party, IP-capable equipment so that the equipment can be controlled by the user through the Zoom Room controller. Admins can create a configuration profile to add outgoing IP control messages from Zoom Room.
This article covers:
- Using Room Controls
- Zoom Rooms for macOS or Windows or Zoom Rooms Appliances, version 5.1 or higher
- Third-party devices controllable by LAN or WLAN
- iTach network adapter (IP2SL/IP2CC or wifi equivalent), if the device does not have native LAN or WLAN access
Enabling Room Controls
Before you can upload a JSON Configuration Profile, the setting will need to be enabled for Zoom Rooms. This can be configured at any level of the Zoom Rooms hierarchy.
- Sign in to the Zoom web portal.
- Click Room Management, then select Zoom Rooms.
- Click Edit to the right of the Zoom Room name.
- Under Devices, toggle Enable Room Controls to on (blue).
- Click Create Profile.
- Enter the JSON configuration for this room.
Writing a Room Controls Profile
Before writing a Room Controls Profile, some working knowledge of JSON is needed. The key items to note are that JSON is a key:value pair-based system and that syntax is important to correctly lay out the file. For additional information on the basics of JSON, consult an online intro course.
In any coding language, some courtesy should be extended to the next person that handles your file. While there is no specific requirement around this for Zoom Rooms Native Room Controls, it is recommended. To leave a record of the author, version, or other history, the 'about' object can be used and placed above 'adapters'. This is not parsed by Room Controls, but will persist in the portal. An example of how this could be leveraged is below.
"type": "Medium Conference A",
"created": "Mon, 21 Oct 2020 16:35:52 GMT"
Setting up the adapters connects Room Controls to devices. This section is the primary section for configuration. Individual devices inside the nested JSON format should follow a similar format (this example is nested to parallel the code example below):
- Adapters: Adapters defined the individual device connections
- Model: Models can be "GenericNetworkAdapter", "IP2CC", and "IP2SL". More details below.
- IP: this is the IP Address + Port of the network device
- UUID: this is only required with Global Caché devices and would follow "GlobalCache_[MAC]"
- Ports: Ports define the device attached to the connection
- ID: this is the name of the device in code. Should follow JSON variable formatting
- Name: this is the friendly name that your users will see on the Interface
- Methods: methods define the individual UI section
- ID: this is the control type ID that is called in code (specific to the control type)
- Name: this is the user-accessible name shown on the Zoom Rooms Interface
- Command: this is either the full command or the shared parts of the command string depending on the action type
- NOTE: When the action type is 'actions' a % should be placed in the command string as a placeholder for the inserted elements inside of 'params'
- Params: this section is only used with 'actions' type and contains the elements that can roll up to the parent command.
- ID: this is the programming ID that is called in code
- Name: This will be the user-accessible text on the Room Controls Button
- Value: this is the command section that is inserted in the parent command. An example of this would be using 'POWR000%\\x0D' as the parent command, '0' for Off or '1' for On could be inserted for some Sharp Displays
"name": "Sharp Display",
Below 'methods', an additional section can be used: "response_filter". The Response Filter is a beacon that allows the Response Filters defined below to understand which connection to listen for. There are no functions defined in this area. How a Response Filter fits into other sections will be covered inside of those sections.
Styles control the visual styling of your interface elements. Today, the adjustments aren't extremely extensive, so it isn't very hard to learn.
There are many icons available in the interface. They span everything from Air Conditioners to Speakerphones. The icons below are the current list, but this list is regularly expanding.
There are three primary modifiers within styles: icons (as we discussed above), Main Methods, and Visibility.
Icons are the visualizations of the system. You can use them either to mark a device or to replace the text tied to a button. In the below example, we've defined a device called 'example'.
"name": "Example Device",
Once 'example' is defined as a device, we can use this ID inside of styles. For example, setting the main icon for our example device to be a light is easily done.
You may also notice that within a single line, we've also defined the Main Method for the device. The Main Method pulls the referenced command that you've defined into the title bar of the device giving it a prominent billing like so:
We've defined the power command as the main method, and so it is shown in the upper bar separate from the other commands.
The third style type is Visibility. Visibility allows the programmer to define a function, but hide that function from the User's Interface completely. It can be defined just as easily:
Following the format of "device.command.invisible=true" allows this command to be completely hidden from the Rooms User.
Rules are the automation engine of Room Controls. This is the area where things that happen on their own are defined. For example, if I wanted my display to only be active when a meeting is active, I could leverage "meeting_started" and "meeting_ended" (stock Zoom events) to make this occur.
This example can be used to reduce power consumption for your system.
If one command per rule isn't enough, these commands can easily be stacked. While they technically fire sequentially, they process quickly enough that we'll consider these events simultaneous. In my above example "camera.power.wake" is added beneath "display.power.on" to activate my camera when my display wakes.
The available stock Zoom commands inside of rules today are straightforward:
- Meeting Events
- Audio Events
- Video Events
- "video_started" (camera unmuted)
- "video_stopped" (camera muted)
- Admin Events
Note: Operating Hours are set in the Zoom Rooms settings page.
It is also simple to add your own for Response Filters. Within the rules section, you can also use the Trigger Events discussed below to drive your own automation with outside inputs.
In this example, our "user_customized_event1" is turning our controlled light off. This could be driven by an input from a button or maybe a motion sensor going inactive or maybe even a third-party system like a booking system sending the room an update that no users checked in for the meeting. How you can use this feature is primarily limited by your imagination.
Response Filters are a powerful advancement in Zoom Rooms Native Room Controls functionality. These filters read messages coming back from defined devices and instantaneously scan for a phrase to match. When this phrase (or expression) is identified on that connection, the Rules Trigger Event (described above) fires.
Each Response Filter is comprised of three elements:
- "name": the name is used in the "ports" section of "methods". When the response filter matches this name in the "ports" area, this begins to span the defined connection
- "filter_regex": the regex (or Regular Expression) is the set of characters that the Response Filter is attempting to match. When the match occurs, the "trigger_event" will activate
- "trigger_event": the Trigger Event is used within the rules section. When the "filter_regex" activates, the automation defined within this Trigger Event in Rules will occur
Using Room Controls
On the room controller device, simply tap the Room Controls icon to access these added functions.
When not in a meeting, the Room Controls icon can be found in the main menus.
During a meeting, tapping the icon at the top right of the controller will display the same Room Controls.
Troubleshooting is an important part in any custom configuration. While Room Controls can be simple, it is also flexible enough to be complex when needed. The below sections should help to resolve possible roadblocks.
Room Control Errors
|No_Config_Error||JSON Profile is not loaded in web portal|
|Json_Syntax_Error||JSON Profile contains a syntax error|
|Json_Config_Error||JSON Profile contains a configuration error|
|IP_Error||There is an issue connecting to a specified IP|
|IP_Is_Public||Public IPs are not allowed at this time|
|DeviceID_Error||One or more Device IDs are incorrectly set|
|MethodID_Error||One or more methods are incorrectly defined|
|ParamID_Error||One or more parameters are incorrectly defined|
|IP2SL_Settings_Error||Serial Port incorrectly configured on GC IP2SL|
|Empty_Device_Error||One or more devices are called without being defined in the JSON Profile|
|Unknown||An unknown error has occurred|
These files have been compiled from various sources and should be used as a starting point only. Some modification is likely required to fit your application.
- Generic Files
- Middle Atlantic