Introduction to Device Provisioning

Have more questions? Submit a request

Provisioning is a process of:

  1. Installing signageOS Core App on the supported device
  2. 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:

Is the device supported by signageOS

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

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:

  1. Turn on the device (display) and walk through the initial settings (like time, date, network connection)
  2. Install signageOS Core App (or signageOS Core App with built-in Applet) for your selected device

2. Verification

The goal of the Verification is to connect the newly installed device with your account and selected Organization. Verification can be accomplished by using one of these options:
  1. Verification code
  2. Auto-verification

Verification Code

Verification Code is a unique 6-characters long code shown upon successful installation of the Core App on the supported device.

verification_censored.jpg

Once you get the Verification Code, you can finish the verification via Box or via 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 own 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

Auto-Verification

Auto-Verification is leveraged for any Core App with a built-in Applet only.

Once you install the Core App with a built-in Applet, the device automatically verifies itself under the Applet's Organization.

Pros of Auto-Verification

  • no need to use 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 that and where it was provisioned
  • more error-prone regarding proper deployment tracking and knowing where is the exact device being deployed

 

Was this article helpful?
0 out of 0 found this helpful
Share