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:
Before you can upload a JSON configuration profile, the setting will need to be enabled for a Zoom Room.
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 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.
{
"about": {
"type": "Medium Conference A",
"version": "v1.2.4",
"design_ref": "\\files\MediumConfA",
"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": [
{
"model": "iTachIP2SL",
"ip": "[IP_ADDRESS]",
"uuid": "GlobalCache_[UNIT_MAC_ADDRESS]",
"ports": [
{
"id": "sl_sharp_tv",
"name": "Sharp Display",
"settings": {
"baud_rate": "38400",
"flow_control": "FLOW_NONE",
"parity": "PARITY_NO"
},
"methods": [
{
"id": "power",
"name": "Power",
"command": "POWR000%\\x0D",
"params": [
{
"id": "displayOn",
"name": "On",
"value": "0001"
},
{
"id": "displayOff",
"name": "Off",
"value": "0000"
}
],
"type": "actions"
},
...
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. 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.
Device | Name | Image |
air conditioner | icon_air_conditioner | |
cable TV | icon_cable_tv | |
ceiling mic | icon_ceiling_mic | |
curtain | icon_curtain | |
DVD Player | icon_dvd_player | |
Xbox/PS4 System | icon_game_console | |
HDMI | icon_hdmi | |
laptop | icon_laptop | |
light | icon_light | |
projector | icon_projector | |
rack equipment | icon_rack_equipment | |
satellite dish | icon_satellite_dish | |
speaker | icon_speaker | |
speakerphone | icon_speakerphone | |
TV | icon_tv | |
power | icon_power | |
up | icon_up | |
down | icon_down | |
cold | icon_cold | |
hot | icon_hot | |
dry | icon_dry | |
wind | icon_wind |
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'.
{
"adapters": [
{
"model": "ExternalControlSystem",
"ip": "tcp://[USER_IP_ADDRESS]:[USER_PORT]",
"ports": [
{
"id": "example",
"name": "Example Device",
"methods": [
...
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.
"styles": [
"example.icon=icon_light",
"example.main_method=power"
]
Zoom also supports Material Design Icons (MDI) which can be found on Google's official MDI site.
To specify one of these icons, follow this format:
"example.icon=mdi:local_airport:two_tone"
Please note that that this should be in all lower case. Use an underscore (_) instead of a space in the icon name. If the icon is unable to be downloaded, the default icon will be displayed.
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:
"example.power.invisible=true"
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.
"rules": {
"meeting_started": [
"display.power.on",
"camera.power.wake"
]
),
"meeting_ended": [
"display.power.off"
]
}
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.
Note: The available stock Zoom commands inside of rules have been expanded as of Zoom Rooms version 5.13.0. Meeting start/end events also now apply to 3rd-party interop meetings, including Microsoft Teams Direct Guest Join Meetings. Other events do not apply to 3rd-party interop meetings in this release.
Type | Event | String | Notes |
Meeting | |||
Meeting | Meeting Started | meeting_started | |
Meeting | Meeting Ended | meeting_ended | |
Meeting | Incoming Meeting Invite Start | zr_meeting_ring_started | |
Meeting | Incoming Meeting Invite End | zr_meeting_ring_ended | |
Phone | |||
Phone | Incoming Phone Call Start | zr_phone_ring_started |
Any type of phone interaction (Zoom Phone, Audio Plan, 3rd Party PBX) will trigger this command |
Phone | Incoming Phone Call End | zr_phone_ring_ended |
All phone ring types must be inactive to trigger this event |
Phone | Phone Call Started | zr_phone_call_started |
PSTN Invites within an active meeting will not trigger this event |
Phone | Phone Call Ended | zr_phone_call_ended |
|
In-Meeting | |||
In-Meeting - Video | Video On (Camera Mute Off) | video_started | |
In-Meeting - Video | Video Off (Camera Mute On) | video_stopped | |
In-Meeting - Audio | Mic On (Mic Unmuted) | microphone_unmuted | |
In-Meeting - Audio | Mic Off (Mic Muted) | microphone_muted | |
In-Meeting - Content | Wireless Sharing Started | zr_share_started | Applies to direct share, whiteboard camera share, camera share, zoom apps sharing, and Apple Airplay (for multiple simultaneous shares, only the first command is sent). Digital Signage will not trigger these events. |
In-Meeting - Content | Wireless Sharing Ended | zr_share_ended | This command is sent when the last of multiple shares ends. Digital Signage will not trigger these events. |
In-Meeting - Content | HDMI Sharing Started | zr_hdmi_share_started | Digital Signage will not trigger these events. |
In-Meeting - Content | HDMI Sharing Stopped | zr_hdmi_share_ended | Digital Signage will not trigger these events. |
In-Meeting - Recording | Recording Started | zr_recording_started | |
In-Meeting - Recording | Recording Stopped | zr_recording_ended | |
Elevation | Meeting elevation | zr_elevate_to_meeting | This event triggers when a Zoom Room engaged in a telephony or screen-sharing session elevates the session to a video meeting. |
Pairing | |||
Pairing | User Paired to ZR | zr_user_paired | Each user will trigger a generalized pairing event. |
Pairing | User Unpaired from ZR | zr_user_unpaired | Each user will trigger a generalized unpairing event. |
Digital Signage | |||
Digital Signage | Digital Signage Begins | zr_digital_signage_started | |
Digital Signage | Digital Signage is dismissed | zr_digital_signage_ended | |
Whiteboard | |||
Whiteboard | Whiteboarding opened | zr_whiteboard_started | Applies to Classic Whiteboard, New Whiteboard, and in-meeting whiteboards |
Whiteboard | Whiteboarding closed | zr_whiteboard_ended | Applies to Classic Whiteboard, New Whiteboard, and in-meeting whiteboards |
Admin | |||
Operation Time | Operation Time Begins | operation_time_started | |
Operation Time | Operation Time Ends | operation_time_ended | |
People Detection | People Detected | zr_people_detected | Only applicable to hardware layer people detection |
People Detection | No People Detected | zr_people_not_detected | Only applicable to hardware layer people detection |
Voice Commands | Voice Commands are enabled | zr_voice_command_on | |
Voice Commands | Voice Commands are disabled | zr_voice_command_off | |
Zoom Apps | Zoom App is opened | zr_zoom_app_opened | Opening any app will trigger this event, even if an app is already open in the meeting. |
Zoom Apps | Zoom App is closed | zr_zoom_app_closed | Closing any app will trigger this event, even if another app is still active in the meeting. |
Note: Operating Hours for Operation Time events 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.
"rules":{
"operation_time_started":[
"light.power.on"
],
"user_customized_event1":[
"light.power.off"
]
}
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.
New in Zoom Rooms 5.13.0, the Scenes function allows Room Controls devotees to finally add Macros (multiple stacked commands on a single button) to their user experiences. This can be helpful for scene recall or dependant devices such as lowering a projector screen as well as powering the projector on.
Like Rules or Adapters, Scenes is a top-tier section in the JSON file. Today, a maximum of 20 scenes can be configured. Within those scenes, a maximum of 50 independent commands are supported.
Once configured, these new scene buttons are available at the top of the room controls window.
To configure scenes, you can reference the code sample below.
Before copying this content, please be aware that '//text' sections are notes for your reference and cannot be included in the final JSON file.
"scenes":[
{
"id":"scene_1", //required
"name":"Turn on all lights", //optional, shown if name and icon are empty
"icon":"icon_light", //optional, see icon list
"commands": [ //required
"light1.power.on",
"light2.power.on"
]
},
{
"id":"scene 2",
"name":"Turn off all lights"
"icon":"icon_light"
"commands": [
"light1.power.off",
"light2.power.off"
]
}
]
Response Filters are a powerful advancement in 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:
On the Zoom Rooms controller, 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 window 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.
Error Code | Description |
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.