Provisioning consists of 2 steps:
- Installing signageOS Core App on the supported device
- Verification of the device under your account and Organization
Once is the Provisioning process completed, you can deploy your Applet to the provisioned device and perform device management actions via signageOS.
The following article covers the high-level steps, highlights important prerequisites, and points you to more detailed guides.
1. Installing signageOS Core App
Prerequisites
To properly provision your devices, you have to check the following items:
A. Is the device supported by signageOS?
- if not, let us know what device you have and whether it can be supported
B. Is there any network restriction?
- make sure your network firewall is properly configured to allow access to signageOS Cloud
- if you are deploying in the completely secluded/closed/local networks, make sure you are deploying signageOS Core App with your Applet built-in
C. Does your device have the right Firmware?
- some devices (Samsung Tizen, LG webOS, ...) are highly sensitive to what Firmware they are using
- kindly always check that the device Firmware is the same as the one we recommend to use on the Supported devices pages
How to install signageOS Core App on the supported device
Each of the supported devices has a manufacturer-specific installation procedure. The step-by-step guides are available in the Device Provisioning section.
The general process:
- Turn on the device (display) and walk through the initial settings (like time, date, network connection)
- Install signageOS Core App (or signageOS Core App with built-in Applet) for your selected device
2. Verification
- A) Verification code
- B) Auto-verification
- C) Bulk provisioning
Each option is designed to fit different processes - from manual device activation, and warehouse pre-registration to in-the-field swaps. You can mix and match these options.
Each of these options is fully covered by signageOS REST API to support your process automation and custom flows.
A) Verification Code
Best for: In-field swaps, API automation, individual installs
Supported by: CloudControl & DevSpace
Verification Code is a unique 6-character long code shown upon successful installation of the Core App on the supported device.
Once you get the Verification Code, you can finish the verification via Box or REST API.
Verification Code can be leveraged only while using the vanilla version of the Core Apps without the built-in Applet
Pros of using Verification Code
- you can come up with your flow for device verification and build a custom UI
- it's easy to name, categorize, and set initial configuration and Device Policy
Cons of using Verification Code
- you need to obtain the code and finish the process "manually", by submitting the code via Box or REST API
- this is a blocking operation - until the verification via code is finished you cannot show any content/assign Applet
B) Auto-Verification
Best for: Mass install with built-in Applet
Supported by: CloudControl (selected platforms) & DevSpace
Auto-Verification is leveraged for any Core App with a built-in Applet and for selected CloudControl provisioning (BrightSign, Linux, Windows).
DevSpace use case: Once you install the Deployment App (CoreApp with a built-in Applet), the device automatically verifies itself under the Applet's Organization.
CloudControl use case: Once you install the CloudControl agent, the device automatically verifies itself under the Organization UID you fill in while installing CloudControl.
Pros of Auto-Verification
- no need to use a Verification Code and perform a "manual" verification process
- Applet starts right after initial installation without any further steps needed
- less error-prone to network configuration; Auto-Verification happens once the network is ready
Cons of Auto-Verification
- with Auto-Verification, the device pops-up in a predefined Organization but has no name or identifier
- needs an additional mechanism to define what kind of device is and where it was provisioned
- more error-prone regarding proper deployment tracking and knowing where the exact device being deployed
C) Bulk provisioning
Best for: Mass install, takeovers, API automation, warehouse operations
Supported by: CloudControl & DevSpace
Upload your list of devices you plan to deploy into signageOS upfront with pre-configured Policy, Tags, and Location. Once the device connects to the signageOS it will get automatically paired with the settings and finishes the configuration.
Read more about Bulk provisioning here.
Pros of Bulk provisioning
- no need to use a Verification Code and perform a "manual" verification process
- Any settings, including Applet, are configured automatically
- suitable for large-scale deployments
- flexible in deployment, you do not need to bundle CoreApp with Applet
Cons of Bulk provisioning
- requires a working Internet connection to finish the setup
- requires knowing the device's unique identifier (MAC address or serial number) upfront