bsn.Control API Integration Guide

bsn control was formerly called the control cloud bsn control is our free service for player provisioning, diagnostics, and control for brightsign players it allows for automated provisioning of your customers' players to your cms solution you can also use bsn control to perform a host of diagnostic actions on a brightsign player, including retrieving/modifying settings, updating its os, rebooting, performing a factory reset, and even passing down custom data this document will walk you through the bsn control integration process in the course of this document, you will learn how to provision brightsign players out of the box (and to help your customers do the same, if necessary) and interact with the player over the internet using the bsn control rest api glossary of terms bsn control a set of player management and deployment services that include the b deploy api, remote dws, authentication services, and a limited set of bsn apis partner the content management system (cms) to integrate with brightsign client credentials a set of credentials, provided by brightsign, that allows the partner to create and manage networks customer the individual purchasing content management services from the partner in order to manage brightsign players person a set of credentials (email and password) that allows an individual to create networks and access them as a user network the structure for managing and monitoring players on bsn cloud a network can have any number of players, but a player can only belong to a single network at a time to switch a player to another network, the device entry must be deleted from the original network on the bsn and b deploy services a network can have multiple users (i e persons), and persons can belong to multiple networks the person who creates the network is the network administrator, but the administrator may give other users equivalent privileges a newly created network defaults to bsn control one or more player subscriptions are required to upgrade the network to bsn content resources the following resources are used for bsn content operations note that bsn content networks have a limited set of bsn endpoints they can call bsn cloud main apis docid\ goemci9nmvgakttr5qcjs brightsignnetwork com apis docid\ xtw 9auvyfzy6wh ubh26 remote dws apis docid\ kku9e7f7chc5lwofxs9e0 b deploy https //brightsign atlassian net/wiki/spaces/doc/pages/378831792/b deploy+device+provisioning b deploy/provisioning apis docid\ wccw4tqerzpxv7kjq a3p obtaining bsn cloud client credentials see the 2025 api usage guide docid\ hbyhyv8svq0u6bzhuv50 determine your network structure before creating bsn cloud networks, you will need to determine how to manage customer players on bsn cloud there are three options one network for all customers you manage a single network for all customers' players there is no way to segregate players by user, so you could not give customers direct access to remote dws or b deploy functionality you create networks for customers you will create a network for each of your customers you can create an additional user on the network to give the customer access (as creator, you remain the network owner) the customer can either have full permissions or a subset of permissions each customer creates a network the customer creates a network using the bsn cloud ui (or a custom ui that you create using the apis) if you want access to your customers' networks, they will need to add you to the network or hand over their credentials determine network interface priorities brightsignos metric logic prior to os 8 4 6, the brightsignos (bos) updated the metrics (interface priority) of wired and wireless interfaces using 0 as the highest metric value, and 1 as the secondary value, when specified through brightauthor\ connected in brightsignos 8 4 6 and above, the bos will assign metrics in the following cases targeted interfaces once the player has successfully connected to bsn cloud, metrics will be updated in interfaces provided by a brightauthor\ connected device setup package discovered interfaces once the player has successfully connected to bsn cloud, metrics will be updated in interfaces which are discovered either through a physical interface connection before power is applied or as a hotplug after power has been applied metric value logic is used to determine the actual value used when applying to the bos relative to the order of all the targeted interfaces and discovered interfaces, the metric will be calculated by starting the "metric assignment" at 100 the location (or index) of the interface is ordered relative to other interfaces, then multiplied by 10, then increased by 100 for example interface index final metric value ((index 10) + 100) eth0 0 100 wlan0 1 110 ppp0 2 120 usb0 3 130 metric range definitions these metric range definitions are loose there are no actual restrictions 0 99 used for interfaces which are not assigned by the bos, possibly because the player is not connected to bsn cloud or older bos version, or autorun these would be explicitly assigned by older software 100 199 used for the bos when assigning metrics 200 n used for interfaces which are not assigned by the bos this may be because the player is not connected to bsn cloud, or an older bos version or autorun are running, where these were not assigned by any software disabling brightsignos metrics to keep the bos from applying metrics for all interfaces, set supervisor apply metrics to false in the networking section registry key determine your provisioning workflow depending on the network structure you've decided on, there are two workflows for provisioning customer players for your cms and bsn control option a partner provisions customer devices you will use the b deploy apis to generate a device object for each player (using the serial number) and associate the device objects with one or more device setup objects you can either add device objects using your client credentials (for example, before shipping them from your warehouse), or you can have customers enter the serial numbers themselves (which would require you to build a customer facing ui that interacts with the b deploy apis on the backend) when the customer connects players to the internet on site, they will contact the b deploy servers and provision themselves for your cms option b customer links bsn controlnetwork with partner cms have the customer add players to their bsn control network, which your cms has access to players that are registered on the customer's network will provision themselves for your cms this option requires that you gain access to a customer network; there are two ways to do this you create a bsn control network for the customer (using the bsn control apis) and hand the credentials to the customer the customer creates an account using the new brightsign device activation scheme the customer will then need to hand the the credentials over to you hosting a provisioning package you can use the b deploy application to set up players for your cms application to do this, you will need to host a fixed application url that brightsign players can use to download a provisioning package contact brightsign for help generating a provisioning package work with the bsn control apis once you've taken the above steps, go to the postman collections docid\ hmkkvvtaul2u2x8p6byb0 for a walkthrough of bsn control tasks, including the following creating a person creating a network performing person/network authentication adding a device setup object and device record to the b deploy server provisioning a player retrieving a list of players on a bsn cloud network making websockets calls to the player security the brightsign player exposes some apis that serve up information required by various internal processes these are open apis, which are not secure however they can only be called by other processes running on the player, not externally, and they do not serve any sensitive information