Features

Description

Send Pinning Capabilities In Device Identity

The device identity object now includes the pinning capability status via the field capabilities.appUpdate.pinning. For this release:

• Tizen devices will report pinning capability as true.

• All other device types will report it as false.

This enhancement enables the platform to accurately identify which devices support app version pinning, improving device management and update workflows.

Add New Pinnable Package Type

Starting with version 2.89.0, the pinnablePackageTypes value is set to ["TIZENTV"]. This update enables the platform to identify Tizen TV as a supported package type for app version pinning, enhancing device management and update control for Tizen TV devices.

General App Update Consistency

The app update process now provides consistent behavior across all supported platforms.

• Tizen devices now support recurring automatic software updates, ensuring they always run the latest app version.

• Automatic, scheduled, and immediate app updates now function as expected on Tizen, Windows Electron, and macOS Electron devices.

• Devices that do not support Appspace-managed app updates remain unaffected by these changes, which prevents unintended behavior.

Implement Microsoft cloud.microsoft Domain Support

The system now supports Microsoft's unified domain structure under cloud.microsoft. This update ensures compatibility with Microsoft’s latest domain initiative, enabling seamless integration and authentication for devices and services using the new cloud.microsoft domain.

A new staggered update approach for device script retrieval has been implemented to improve server performance. When numerous devices receive a timestamp update, they will now retrieve the script from the server with a random delay between 2 and 7 seconds, preventing a sudden surge in requests.

• Device Listing Page
• Device Overview Page
• Script Generation 

An updated Chromium caching method led to an accumulation of individual cache files on device storage, potentially causing performance degradation and application errors. To mitigate these issues, we have implemented BrightSign’s recommended solution: disabling the Chromium cache directly within the HTML registry.

Here’s an important update regarding BrightSign firmware:

• BrightSign firmware versions that include special suffixes for example (-OS-XXXXX) are now fully supported by our system.
• The exact BrightSign firmware version, including any suffixes, is now accurately reflected in the Firmware column of your Device Analytics reports.
• All capabilities and fixes tied to specific firmware versions will now function as expected on your devices, regardless of whether their OS version includes additional suffixes.
• Please ensure your firmware is updated. If your BrightSign firmware version is lower than 6.1.76, a message will display on boot stating, “Minimum firmware version required is 6.1.76. Current firmware version is <currentFirmwareVersion>.

ADA-Compliant Palette (when player.statuslight.colorpalette is set to ada)

• Available Room Status: Blue LED
• Occupied Room Status: Orange LED
• Check-In Room Status: Yellow LED
•  

Standard Color Palette (Default/Unspecified player.statuslight.colorpalette)

• Available Room Status: Green LED
• Occupied Room Status: Red LED
• Check-In Room Status: Yellow LED

The application’s identification process for Cisco Webex devices has been improved to ensure optimal performance within Appspace.

When a device running RoomOS is identified as a generic Progressive Web App (PWA) due to an undefined Webex device type, such as a Webex Board, Room Kit, or Room Navigator, the system will now accurately recognize its RoomOS platform. Following this recognition, the optimizing WebexDriver will be installed to implement all relevant performance and stability enhancements.

Channel ID in Content’s QR Link

As part of the Content Playback Reports initiative, the content QR link has been improved by appending the Channel ID. This allows the Channel ID to be passed directly from the Content Feed Service to the Analytics event.

The PWA now offers enhanced support and new capabilities for Qbic devices, as a result of recent feature enhancements. These include:

Broader Qbic Device Support:

The PWA is now better at recognizing more Qbic hardware, with improved detection for Qbic TD-0360 and Qbic TD-1070 Lite models. This results in wider compatibility.

LED Room Status Indicators:

Qbic devices connected via the PWA can now use their LED lights to visually show the current status of a room for example: available, busy.

Deeper Device Insights:

For easier monitoring and troubleshooting, detailed information about Qbic PWA devices can now be accessed, such as:IP address:

• MAC address
• Device Model
• Firmware version
• CPU usage
• Memory usage
• Available storage

Simpler Device Setup & Recovery:

The processes for registering a new device or recovering an existing one have been streamlined, enabling the direct use of the device’s serial number.

Note

With the release of version 2.84.0, Qbic PWA devices now feature built-in LED integration. This enhancement means that an external device task is no longer required for LED support on these devices, simplifying setup and management.

An enhancement has been implemented to resolve an issue that prevented broadcast events from processing if the broadcast alert service encountered a transient error during its startup. This previously occurred during active broadcast retrieval, service restarts, or maintenance because the startup process lacked a retry mechanism and would reject the app on initial failure, requiring a restart for recovery. The new retry mechanism robustly handles these startup rejections, ensuring the broadcast alert service consistently starts and processes events, even after temporary disruptions, which significantly improves service reliability.

New features streamline how the application loads its service worker for Announcement Cards. The service worker is now managed through the PWA Cache Service, improving performance and removing the dependency on npm.

Key improvements include:

• The service worker now loads from the PWA Cache Service instead of npm.
• Only cards using the Appspace domain are eligible for caching.
• All card types are now cached through the service worker.
• Old content hosted on appspace.com will be purged.
• The PWA Cache Service loads correctly after registration and unregistration, even across different environments and accounts (when the read flag is enabled).
• The cache service also loads properly after a device is registered.

To ensure a seamless and up-to-date experience with Announcement Cards, significant improvements have been implemented regarding cache handling and service worker behavior.

These enhancements are designed to optimize performance and guarantee that you always see the latest information. Specifically:

• Upon switching to the AUC domain, the cache will be purged.
• Old content is cleared after it is removed.
• The existing service worker is reused after the read flag is on.
• The instance service worker will be purged after a card has been edited or removed.

The feature flag controlling the Push Notification Service Health feature has been updated to feature.devices.pnsdevicestatus. This change reflects a refinement in how the health and status of devices within the PNS are managed and controlled.

The connected PNS client now restarts automatically when the feature.devices.pushhealthstatus flag is enabled at runtime, ensuring the device’s “Online” status is properly reported and avoiding false “Lost Communications” states.

Note

Channel Browsing is not yet supported. Minimum Appspace version required: 8.10.0-ac.2 (tentative).

Device App Update Management: Execute (Manual) Update Based On Schedule Provided By PNS And Device Script

• Tizen Devices (Manual Update):
  • Upon reaching the scheduled update time, the device will update the launcher URL to the latest version and reboot.
  • After the update, the launcher URL will remain set to the version-specific URL.

• MacOS and Windows Electron Devices (Manual Update):
  • Upon reaching the scheduled update time, the device will update to the latest version.
  • Subsequent automatic update checks at 3:00 AM will be skipped.

• Other Devices:
  • The software.softwareupdates.schedule device property and <deviceId>device.#.sofwareupdate.configurationupdated PNS message will have no effect on software updates.

• General Behavior:
  • Upon receiving the <deviceId>device.#.sofwareupdate.configurationupdated PNS message, the device will initiate the scheduled software update.
  • Upon boot-up, the device will schedule the software update based on the software.softwareupdates.schedule device property.

• Upon receiving the <deviceId>device.#.sofwareupdate.configurationupdated PNS message, the device will schedule the update based on the schedule.updateTime property within the software update configuration.
• The device will also schedule updates based on the updateTime property from the software.softwareupdates.schedule device property during boot-up.
• The device will check for updates if the current time is within 5 minutes of the configured update time.
• The automatic update check time will default to 3:00 AM if:
  • The schedule.updateTime in the software update configuration is invalid or undefined.
  • The schedule.updateType in the software update configuration is not recurring.

• Tizen Devices:
  • Upon executing an immediate update, the device will set the launcher URL to the latest version and reboot.
  • If the device is configured for Manual Update, the launcher URL will remain set to the version-specific URL after the update.

• MacOS and Windows Electron Devices:
  • Upon executing an immediate update, the device will update to the latest version.
  • If the device is configured for Manual Update, subsequent automatic update checks at 3:00 AM will be skipped.

• General Behavior:
  • Upon receiving the <deviceId>device.#.sofwareupdate.configurationupdated PNS message with an Immediate schedule update type, the device will initiate the update process.

This feature ensures continuous content display on your devices by allowing you to configure fallback media (images or videos) that will be displayed. We’ve introduced a new device property, device.fallbackcontent.configuration, to enable resilient content fallback mode. Administrators can use this device property to define fallback content (Media type, image/video content types) at both the device and location levels, and the device will directly stream fallback content from the Appspace server.

The fallback content will be displayed in specific scenarios: device unregistered state, content unavailability, channel initialization timeout, or version upsert timeout. The fallback content will not be displayed when the device is in preview mode.

The device will automatically return to regular content once the issue is resolved. The fallback content settings are automatically cleared when a device is intentionally unregistered.

Learn more: Configure Fallback Content for Appspace Devices

SureVue Chrome App Update: Preparing for Electron Migration with MAC Address Upload

This update introduces the capability to retrieve your device’s MAC address and securely upload it to our cloud services. This crucial step ensures seamless device identification and registration as we transition to the new platform.

What’s New:

• MAC Address Capture: The SureVue Chrome App can now identify and capture the unique MAC address of your device.
• Secure Cloud Upload: For a smooth transition, this MAC address data is securely transmitted and stored in our cloud environment.
• Enabling Electron Migration: This preparatory step allows your device to be recognized and properly registered within the new Electron-based SureVue app, ensuring a consistent experience.

Key Improvements:

• Streamlined Migration: By collecting and storing MAC addresses beforehand, we aim to make the upcoming Electron migration process as smooth and hassle-free as possible for you.
• Continuity of Service: This update ensures that your devices will be readily identifiable in the new application, minimizing any disruption to your workflow.

What’s New:

• This release includes the migration of the existing device API layer from the Chrome app architecture to the SureVue Electron framework.
• This foundational update ensures that all device-dependent functionalities are available and consistent in the new Electron application.

What’s New:

• The SureVue Electron app now supports the playback of UDP streams.
• This functionality, previously available in the Chrome app, has been implemented using the internal API http://localhost:7070/udphelper/<udpURL>/out.m3u8 for on-the-fly conversion to HLS.
• This ensures that users migrating from the Chrome app will maintain the ability to view UDP-based content.