The Monitors Section

Use the Emergency tab to configure emergency messaging. The source of emergency messaging can be as follows:

• A URL to the Broadsign Publish emergency messaging.

Copy this URL from the Emergency Messaging section in the Broadsign Publish Admin Dashboard. For more details, see Configure the Emergency URL in the Broadsign Publish documentation.



• A URL to the Broadsign Creator emergency messaging.

Copy this URL from the Settings tab of the Broadsign Creator interface. For more details, see the Broadsign Creator "Help" PDF.



• A URL to a static file on an external server.
• A URL to an HTML5 package on an external server.

Configure Emergency Settings

The following options are available:

• Enable the Emergency Monitor – Enables the feature.

• URL – Your unique emergency messaging URL.

• Emergency Ad Copy Type – Two methods are available to send the emergency message protocol. See Emergency Ad Copy Type - Static File and Emergency Ad Copy Type - HTML5 Package.
• Send "Power On" RS-232 command to attached displays – When enabled, if you are using RS-232 device control, an emergency message will automatically turn on your screen if it is not already on. Likewise, it will restore the correct power state after the emergency message finishes. You must define the “Power On”, “Power Off” and “Assert Power” actions for this to work. For more information, see Add a Device Control Time Span.

Emergency Ad Copy Type - Static File

You can activate/deactivate the emergency message protocol by adding and removing a static file on the remote server. The player sends an HTTP HEAD every 60 seconds to the specified URL.

• If the response is anything other than a 200, the player ignores the response.
• If the response is a 200, the player follows up with a full HTTP GET. The contents of the URL response is displayed in a browser, in fullscreen. The emergency message is now considered "active".

Note: When active, emergency messages interrupt the loop and play fullscreen.

• The HTTP HEAD requests continue every 60 seconds until the player receives a response other than 200 (for example, 404 not found). In that case, the player uses the response to deactivate the emergency message and return to the normal loop.

• Append Player Id – Enables the player targeting feature. You can add behaviors that target specific players (for example, site-specific messages).
• Variable name – The default player ID variable is com.broadsign.suite.bsp.player_id. You can rename the variable, if you want. For example, you can change the variable name from player_id to franchise_id or retail_player_id. See Variables in Emergency URL for more details.

Note: For best results, ensure that any content variables used in the Emergency Monitor URL are identical across synchronized Display Units (e.g. Leader-Follower). Otherwise, when the variable gets substituted in the emergency message URL, it may occur that Leader and Follower point to different sources for their emergency message.

Note: The player append its ID as an HTTP GET variable to each request, allowing server-side logic to selectively activate emergency messages per player.

Note: If you are using multiple frames, the frame_id in which the emergency is playing is appended to the end of the URL. The frame_id is always 0, and not what it was previously, because emergency messages use the whole screen and are not associated with a frame ID.

Broadsign Control supports valid HTTPS website URLs.

Emergency Ad Copy Type - HTML5 Package

Activates/deactivates the emergency message protocol by adding and removing an x-html-package instead of a regular .html file on the remote server. The player sends an HTTP HEAD every 60 seconds to the specified URL.

Note: The path to the main HTML file of the HTML5 package must be index.html. For more information, see Add an HTML Package Ad Copy.

Note: You can use a BroadsignObject for your emergency messages.

• If the response is anything other than a 200, the player ignores the response.
• If the response is a 200, the player follows up with a full HTTP GET and unzips the emergency x-html-package to local disk. The contents of the URL response is displayed in a browser, in fullscreen. The emergency message is now considered "active".

The player checks the “last modified” date and issues a new HTTP GET if the date changes. This ensures that, if the emergency message changes during the emergency period, the screens get refreshed with the new message.

The x-html-package is unzipped before being displayed on screen.

Note: When active, emergency messages interrupt the loop and play fullscreen.

• The HTTP HEAD requests continue in the background from the player to the edge server every 60 seconds until the player receives a response other than 200 (for example, 404 not found). In that case, the player uses the response to deactivate the emergency message and return to the normal loop.

Note: The player append its ID as an HTTP GET variable to each request, allowing server-side logic to selectively activate emergency messages per player.

The following options are available:

• Send requests through edge server – When this option is activated, the player will issue an HTTPS request to the currently assigned edge server. If multiple edge servers are assigned, it will not rotate but instead always use the one with the lowest ID. It is acceptable for the emergency message to not be activated if the edge server is down. The player will pass the full destination URL as an HTTP header to the edge server.
  • Request Frequency – When Send requests through edge server is enabled, the request frequency, in seconds. The minimal value is 5 seconds and the default value is 30 seconds.
  • Maximum number of errors – When Send requests through edge server is enabled, number of errors allowed before the player goes through a secondary edge server at the same level, if available.

Variables in Emergency URL

You can use content variables to dynamically transform the URL of emergency messages.

• The list of variables is described in Content Variables.
• Variables are identified with {{variable_name}}.
• Variable replacement in the emergency URLs works as described in the Configuration Settings section of the Monitor Sync documentation.
• The variable replacement works for both the standard Emergency Monitor URL and the HTML5 Package Emergency Monitor URL.
• All automatic variables, as well as player and/or display unit variables (display_unit_address, display_unit_id, display_unit_lat_long, display_unit_location_code, display_unit_resolution, and player_id), can be used and follow the same rules for inheritance. Custom variables created by the user on the display unit or player can also be used in the emergency URL.
• The variable replacement can happen anywhere in the URL, EXCEPT the protocol.
• It is possible to have multiple variables in the same URL.
• If the resulting URL is invalid after variable replacement, it will be logged in the player’s log.
• The variable replacement is done player-side and is transparent to the edge server when using the Send requests through edge server option.
• To retain the synchronous display of an emergency message across a group of synchronized displays, avoid using player-specific variables, as this will limit the edge server’s ability to cache a single message and server it to all players. The variables should be structured such that they generate the same final URL for all players in a synced group using the Send requests through edge server option.

The CPU tab contains settings to enable High CPU usage and duration thresholds.

• Threshold – With the Threshold setting enabled, the Player will send an incident notification if the CPU usage exceeds the High CPU Threshold for a duration longer than the High CPU Period specified in seconds.
• Frequency – The Frequency section controls how often the CPU usage monitor verifies the CPU usage settings and how often CPU usage is logged. A log frequency setting of zero (0) seconds disables the logging.

The Memory tab enables or disables the Player’s ability to reboot itself if it exceeds 90% usage of the system memory.

This ensures that third-party content does not exhaust all the system’s memory, leading to swapping, poor playback or crashes.