VNNOX Standard: binding your screens and publishing from the cloud

VNNOX Standard is the cloud building block of the NovaStar ecosystem. The official documentation describes it as a service for remote content management and player control, for LED and LCD display control systems and multimedia players, presented as a lightweight content publishing application allowing efficient editing and one-click publishing.

That definition says the essential: VNNOX Standard replaces neither NovaLCT, which configures screen geometry, nor ViPlex, which drives a player on the local network. It adds a remote operating layer: binding screens, sending content, scheduling and checking fleet status from a browser.

This tutorial follows the flow documented by NovaStar: obtaining authentication information, binding synchronous then asynchronous players, adding and configuring screens, then creating and publishing solutions. We explicitly flag what the documentation consulted does not detail.

1. Where VNNOX Standard sits in the chain

Three tools coexist in the NovaStar ecosystem, and confusing them costs time. NovaLCT configures the screen: geometry, cabinets, receiving cards. ViPlex publishes content to a player reachable on the local network. VNNOX Standard operates the fleet remotely, without being on site.

On a new installation the order is therefore fixed: NovaLCT first to make the screen correct, then ViPlex to validate a first playback, finally VNNOX for day-to-day operation. Starting from the cloud on an unconfigured screen achieves nothing.

2. Obtaining authentication information

The first documented step is retrieving the screen or player authentication information. Those credentials are what allow a terminal to attach to your account: without them no binding is possible.

In practice that information should be kept with the installation file, never in a stray message or on a technician's laptop. Across a fleet of dozens of screens, rigorous credential management is what lets you regain control of a terminal years later.

• Retrieve authentication information before any binding attempt.
• Archive it in the installation file, with the serial number.
• Do not circulate it by email without traceability.
• Plan a renewal procedure when an operator leaves.

3. Synchronous and asynchronous players

The documentation distinguishes two terminal families, and the binding procedure differs for each. Synchronous players are the sending-card and receiving-card systems, that is architectures driven by a controller configured in NovaLCT. Asynchronous players are the Taurus series multimedia players, which store their own content.

That distinction structures everything after it: the Binding to Synchronous Players section covers the former, Binding Asynchronous Players the latter, with two documented methods for the latter — binding via device serial number, and binding via ViPlex Express or the ViPlex Handy app.

The exhaustive list of compatible models was not found in the documentation consulted: only the two terminal families are described there. Have compatibility of a specific model confirmed by NovaStar before building a fleet on it.

4. Binding an asynchronous player

Two routes are documented for a Taurus player. The first is binding by serial number: you enter the terminal's number in the interface, which assumes you recorded it from the device label before final installation.

The second goes through ViPlex Express on Windows or ViPlex Handy on mobile. As the software is already connected to the player on the local network, it transmits the binding to the cloud itself. That is the more reliable field method, because it avoids serial-number typing errors.

• Record and photograph the serial number before final installation.
• Binding by serial number from the VNNOX interface.
• Or binding via ViPlex Express on Windows.
• Or binding via the ViPlex Handy mobile app.

On site, bind each player to the cloud from ViPlex Handy before mounting it behind the screen. Once the structure is closed, local access becomes expensive and a mis-recorded serial number means dismantling.

5. Adding and configuring screens

After binding, the documentation moves on to adding screens then configuring networks, which makes remote management and control available. At that point the terminal stops being merely a bound device and becomes an operable screen in the interface.

Naming quality is decided here. On a real fleet, an explicit name including the city, the site and the precise location prevents publishing mistakes. Conversely, a list of screens named 'screen 1' to 'screen 40' guarantees that content will one day go to the wrong façade.

• Add the screens after binding the terminals.
• Configure the networks to enable remote management.
• Name each screen to a convention: city, site, location.
• Group screens by geographic area or by campaign.

6. Creating and publishing solutions

The VNNOX Standard user manual structures the rest of the journey around two main sections: solution creation and publishing, then remote control. A solution is the publishing unit: it gathers the media, their layout and their schedule.

The step-by-step detail of that procedure — importing media, composing the programme, scheduling then publishing — is not reproduced here, as it was not verified in the body of the manual. Only the section headings were confirmed. Refer to the official manual for the exact sequence.

The detailed steps for creating and publishing a solution were not verified line by line in the VNNOX Standard manual: only the main sections are confirmed. Consult the official manual for the complete procedure.

7. Remote fleet control

Remote control is the second major manual section after publishing. It is what distinguishes a cloud platform from a mere file transfer tool: acting on a remote screen without travelling to it.

Operationally, three uses alone justify the subscription: scheduling power on and off, adjusting brightness by season, and verifying that content actually reached every terminal in a campaign. Those three actions account for most of a fleet operator's time.

• Schedule screen power on and off remotely.
• Adjust brightness by season or time band.
• Verify actual content delivery on each terminal.
• Regain control of an isolated screen without travelling.

8. On-site network prerequisites

A cloud platform is only worth something if the terminal stays reachable. Each player needs stable outbound Internet access: wired Ethernet where the site allows, Wi-Fi client mode otherwise, or a cellular module at isolated locations such as street furniture.

The classic mistake is connecting the player to the customer's corporate network without checking firewall rules, then finding a week later that the terminal never reached the cloud. Validate the actual connection from the interface before leaving site.

• Stable outbound Internet access for every terminal.
• Wired Ethernet preferred, Wi-Fi client as fallback.
• Cellular module for locations with no fixed network.
• Confirm the terminal reports into the interface before leaving.

9. Standard, Pro and Care: what is confirmed

NovaStar offers several cloud services and their respective scope is often misunderstood. What official sources confirm: VNNOX Standard is presented as a lightweight application for remote content management and player control. VNNOX Care is described as monitoring-oriented, with visual data analysis, intelligent information management, condition monitoring and cloud backup.

However, no official page comparing Standard, Pro and Care point by point was found. The common distinction — Standard for lightweight publishing, Pro for advanced uses and large fleets, Care for maintenance — comes from third-party sources and is not verified against an official comparison. We flag it as such.

The functional differentiation between VNNOX Standard, Pro and Care could not be established from an official comparison. Ask NovaStar or your distributor for an up-to-date comparison table before choosing a subscription.

10. Fleet operation best practice

Fleet experience boils down to a few simple rules whose absence explains nearly every operating incident. The first is the naming convention, decided before the first screen and never changed afterwards.

Then come traceability of authentication credentials, systematic verification that a campaign was received before announcing it to the client, and archiving serial numbers with installation files. None of those rules is technical: all are organisational.

• Set the naming convention before the first screen.
• Archive authentication credentials and serial numbers with the files.
• Verify campaign delivery on every terminal before announcing it.
• Bind each player to the cloud before final mounting.
• Keep a written record of every scheduling change.

Commissioning procedure

1. Retrieve authentication information

   Obtain the screen or player authentication credentials, without which no binding is possible.

2. Identify the terminal family

   Determine whether it is a synchronous player with sending and receiving cards, or an asynchronous Taurus series player.

3. Bind the terminal

   Bind an asynchronous player by serial number or via ViPlex Express or ViPlex Handy; follow the dedicated procedure for a synchronous player.

4. Add the screen and configure the network

   Add the screen in the interface then configure the networks to enable remote management and control.

5. Name to a convention

   Rename each screen with the city, site and precise location, and group it by area or by campaign.

6. Create and publish a solution

   Create the solution gathering the media and their schedule, then publish it to the relevant terminals.

7. Verify before leaving site

   Check the terminal reports into the interface and that the published content was fully received.

Frequently asked questions

Official documentation

• VNNOX Standard — official documentation — Documentation
• Screen Binding — official documentation — Documentation
• VNNOX Standard User Manual V7.2.0 (official PDF) — User manual
• VNNOX Care — official page — Manufacturer page

Related tutorials

• NovaLCT tutorial: LED screen configuration
• NovaStar TB30 tutorial: asynchronous player
• NovaStar TU15 Pro tutorial: 2.6 Mpx player
• NovaStar TB60 tutorial: 4-port player

A screen fleet to run remotely?

We bind your terminals, define the naming convention and train your operators on cloud publishing.

• Talk to a technician
• Tutorials