IoT Devices · Super Screen

Super Screen deployment and acceptance

Deploy a Windows or Android player, choose cloud or LAN control, and verify restart, content and connection recovery before unattended operation.

Prepare the deployment record

Record the site, screen resolution and orientation, operating system, client version, device ID and responsible operator. Obtain the client package, checksum, workspace ID and actual console or cloud connection details from the project contact. This website does not provide a public player download or a shared cloud control credential.

Use Windows 10/11 64-bit or the delivered Android package. On Windows keep console and player directories together and start console/console.exe. On Android TV verify WebView with the actual dashboard. Register the assigned workspace and confirm the device in the project console before remote publishing.

Choose the control path and network boundary

Cloud control serves screens on different networks using the delivered project endpoint. LAN control uses the player listener on the local network. The player tries ports 9756–9765; use GET /ping on the responding port to confirm it. Prefer WebSocket /order for LAN integration and keep the six-digit control code private.

Place the player and local controller on the intended network and restrict access to that control path. An HTTPS webpage may be blocked from insecure HTTP or WS LAN endpoints by the browser. Use a suitable local service or supplied application; do not assume that opening a dashboard in a browser establishes a control connection.

Accept the installation on the physical screen

First query screen regions, publish one reachable page and inspect the physical image, orientation and sound. Record the message ID and response alongside the observed result. A successful ret: ok response is a command acknowledgement, not proof that the dashboard is visible or its data is current.

  • Restart: verify autorun starts the client and restore reopens the intended content; test these as separate settings.
  • Network loss: record which cached content remains visible and how stale online data is marked. Restore the network and verify reconnection.
  • Updates: Windows uses the complete-package OTA flow; Android uses the delivered installation package. Retain the previously accepted package and configuration for recovery.

Hand over the operating record

Keep the device and version inventory, network path, region IDs, approved content URLs, recovery procedure and support owner. Store credentials separately. The acceptance record should state what was observed, what failed and what remains untested; the guide itself is not a completed deployment.

Chat on WhatsApp