# Wallboard Device Management Complete Guide

## Device Registration Framework
### Registration Methods

#### 1. 4-Digit Code Registration (Universal Method)
**Process Flow:**
1. Install Wallboard application on device
2. Device moves into the **Unregistered** devices pool and is assigned a 4-digit code.
3. Device displays 4-digit code on screen
4. Navigate to Editor UI → Devices → Add Device
5. Enter 4-digit code in "Temporary ID" field
6. Complete configuration settings

**Characteristics:**
- **Availability**: Works on all supported devices
- **Use Cases**: General purpose registration, field deployments
- **Benefits**: Simple, immediate registration process

#### 2. Serial Number Registration (Device-Specific)
**Requirements:**
- Serial number must be 8+ characters
- Not available for standard Android devices
- Supported on: LG, Samsung, BrightSign, some Android devices (Qbic)

**Process Flow:**
1. Obtain device serial number from hardware/OS
2. Enter serial number during device registration
3. Device automatically connects when powered on and connected to network

**Benefits:**
- Automated device recognition
- No manual intervention required at device location
- Ideal for bulk deployments

#### 3. Pre-Registration (Offline Placeholder Creation)
**Purpose**: Create device configuration before physical device is available

**Requirements:**
- Valid 8+ character serial number
- Device must support serial number registration

**Process Flow:**
1. Create placeholder device using serial number
2. Assign license, content, teams, and settings
3. Device automatically adopts configuration when first connected

**Registration Validation:**
- **Duplicate Serial Numbers**: Cannot register the same serial number twice on one server (system prevents duplicates)
- **Serial Number Mismatch**: If actual device serial differs from pre-registered serial, device will not connect to the placeholder
- **Exact Match Required**: Device serial number must exactly match pre-registered serial for automatic connection

**Pre-Registration Use Cases:**

**Primary Value**: Enables bulk device deployment without technical personnel at each location.

**Key Scenarios:**
- **Warehouse Operations**: Register devices using serial numbers on packaging without unboxing
- **Bulk Deployment**: Pre-configure hundreds of devices before physical deployment
- **Remote Sites**: Deploy to locations where no technical staff available - devices work immediately when plugged in
- **Scalable Installation**: Transform complex setup into simple "plug-and-play" operation
- **Device Recovery**: Automatic reconfiguration after resets/reinstalls

**Business Impact**: Converts device deployment from a technical, time-intensive process requiring skilled personnel into a simple, scalable operation suitable for non-technical staff across multiple locations.

**Bottom Line**: Pre-registration is for operational efficiency at enterprise scale - deploy many devices quickly across multiple locations with minimal on-site technical requirements.

### Registration Configuration Options

#### Basic Configuration Settings
- **Device Name**: Human-readable identifier for management
- **License Assignment**: Lite, Professional, Premium, Video Wall, or Unlicensed
- **Content Assignment**: Immediate content deployment upon registration
- **Emergency Content**: Pre-assigned critical content for emergency situations
- **Team Assignment**: Access control and management permissions

#### Advanced Configuration Settings
- **Volume Control**: Default audio level setting
- **Brightness Control**: Screen brightness management
- **Organizational Folders**: Logical device grouping
- **Rotation Settings**: Screen vs content rotation preferences
- **Emergency Content**: Default emergency content/playlist assignment
- **Time Zone Configuration**: Device-specific time zone settings
- **Weather Location**: Geographic location for weather data widgets
- **Data Sources**: Primary data source binding configuration
- **Sensor Configuration**: Connected sensor setup (Enterprise license required)

#### Device Profiles (App Version 4.0+)
**Function**: Predefined configuration templates that replace all current device settings

**Implementation:**
- Applies complete policy configuration to device
- Overrides individual settings with profile defaults
- **Limitation**: Not supported by all platforms

**Use Cases:**
- Standardized device deployment across locations
- Consistent configuration enforcement
- Simplified bulk device management

#### Unlicensed State Management
**Purpose**: New "Unlicensed" state for license-free device preparation

**Key Benefits:**
- **No License Consumption**: Devices in unlicensed state don't consume active licenses
- **Unlimited Device Preparation**: Prepare unlimited devices for large projects without license limits
- **Flexible Deployment**: Move devices between customers or servers without license selection requirements
- **Cost Management**: Only consume licenses when devices are actually deployed and operational

**Functional Limitations:**
- **No Content Display**: Devices cannot display assigned content while unlicensed
- **License Expired Screen**: Devices show "license expired" screen until proper license is assigned
- **Configuration Only**: Device acts as configuration placeholder - settings saved but not functional

**Automatic State Transition:**
- Devices automatically enter "UNLICENSED" state when moved between customers or servers
- No manual license selection required during device transfers
- License assignment required to activate content display functionality

**Use Cases:**
- Large project preparation with hundreds of devices
- Device staging and testing without license consumption
- Flexible device inventory management between projects
- Cost optimization for enterprise deployments with phased rollouts

## Device Folder Tags

- **Setup:** In Devices, a folder's **Manage folder tags** action opens **Manage device folder tags**. Saving changed tags enables inheritance for devices in that folder and all nested subfolders; there is no separate inheritance switch in the UI. Existing folders are not automatically enabled. The separate **Manage tags** action edits tags on devices inside the folder.
- **Hierarchy and updates:** Devices combine tags from every ancestor folder with inheritance enabled, including their immediate folder. A folder without inheritance does not block an enabled ancestor. Folder-tag edits and device or folder moves recalculate inherited tags; devices arriving later inherit too. These tags participate in existing device-tag targeting and Quick Filters.
- **Individual tags:** The device tag editor shows **Inherited tags from folder** as read-only chips, separately from manually assigned tags. The same name can have both origins. Removing its manual assignment leaves the inherited tag; removing it from one folder leaves it effective if another ancestor or a manual assignment still supplies it. There is no per-device exclusion of inherited tags. Clearing editable folder tags withdraws only that folder's contribution.
- **Access:** Folder tag editing requires device/folder management permission and write access to the folder. Inheritance recalculation follows the request's device visibility; folder write access alone does not guarantee updates to devices outside that scope. Existing tags outside the operator's tag access remain locked and are preserved on save. Inheritance does not change device team membership. New device tags created by inheritance receive the contributing folders' teams at creation, with writable access winning where assignments overlap; existing device tags retain their team assignments. Later folder-team changes do not continuously synchronize tag access.
- **Limits:** Duplicate tag names are case-insensitive; accents remain distinct. Each device's combined manual and inherited tags must fit the 2048-character serialized tag limit, including JSON overhead. An overflowing update is rejected, not truncated.

## Device Lockdown & Kiosk Mode

### Overview
Device lockdown prevents users from accessing device settings, exiting the application, or performing unauthorized actions. Essential for public-facing installations, retail environments, and corporate deployments.

### Platform-Specific Lockdown Capabilities

#### Android Lockdown (Rooted Devices Only)
**What Android Locking Does:**
- **Disables Pre-installed Applications**: Every unnecessary application disabled for maximum performance and security
- **Sets New Home Application**: Wallboard becomes default home app (Home button launches Wallboard)
- **Custom Boot Animation**: Replaces default Android boot animation with Wallboard branding
- **One-Time Process**: Locking needs to be done only once, takes several minutes, requires reboot

**Lockdown Methods:**
- **During Installation**: Enable "Lock device" option in installation configuration
- **Editor UI**: Devices → Device → Settings → Lock switch
- **Secret Menu**: Available through Android secret menu options
- **Wallboard Toolbox**: Device management → Lock/Unlock → Enter device IP → Select disable/enable launcher applications (safest option)

#### Windows Lockdown
**Default Lock Mode:**
- **Application Isolation**: Users cannot interact with applications other than Wallboard
- **Interface Hiding**: Option to hide taskbar and disable edge gestures on touch displays
- **Fullscreen Requirement**: Must select fullscreen mode to enable locking option

**KIOSK Mode (Enterprise License Required):**
- **Requirements**: Windows 10/11 Enterprise, Wallboard 3.1.329+, English language OS
- **Shell Replacement**: Replaces Windows Explorer with Wallboard as default shell
- **Keyboard Filtering**: Filters specific keyboard shortcuts
- **Automatic User**: Creates dedicated Windows user for Wallboard operation
- **Setup Command**: `{"user_command":"SetUpKioskMode", "command_data":{}}`

**Lockdown Methods:**
- **During Installation**: Enable "Lock device" if fullscreen mode selected
- **Editor UI**: Devices → Device → Settings → Lock switch
- **Secret Menu**: Available through Windows secret menu options

**KIOSK Mode Access:**
- **Normal Mode Access**: Press Windows button 5 times to switch to default user
- **Automatic Return**: Next restart automatically logs into Wallboard user and starts application
- **Unlock Procedure**: Contact support@wallboard.info for KIOSK mode unlocking

#### JSCore Platform Lockdown (BrightSign, Samsung, LG)
**Platform-Specific Behavior:**
- **BrightSign**: Lock screen option has no effect
- **Samsung**: Lock screen disables remote control inputs
- **LG**: Lock screen disables remote control inputs

**Lockdown Methods:**
- **Editor UI**:  Devices → Device → Settings → Lock switch
- **Secret Menu**: Available through JSCore secret menu options

**Limitations**: JSCore lockdown capabilities are platform-dependent and more limited compared to Android/Windows

### Lockdown Use Cases
- **Public Kiosks**: Prevent user access to device settings or other applications
- **Retail Displays**: Secure customer-facing screens from tampering
- **Corporate Installations**: Maintain professional appearance and prevent unauthorized changes
- **Educational Environments**: Restrict student access to device functionality

## Working Hours & Power Management

### Working Hours Overview
Working Hours provide automated device uptime control for energy savings and operational optimization. The system supports two distinct power management modes:

- **Device Type**: Powers entire device on/off at scheduled times
- **Screen Type**: Controls display on/off while keeping device running

**Health Recommendation**: Always configure Working Hours or Automatic Reboot to preserve device health and performance through memory management.

### Working Hours Types

#### Device Type Power Management
- **Function**: Complete device shutdown/startup at scheduled times
- **Benefits**: Maximum energy savings, automated device lifecycle management
- **Use Cases**: Locations with defined business hours, energy conservation requirements
- **Device Behavior**: Complete system shutdown during off-hours

#### Screen Type Power Management
- **Function**: Display control only, device remains operational
- **Benefits**: Faster wake-up, continuous system monitoring, reduced wear on device components
- **Use Cases**: 24/7 monitoring with scheduled display periods, digital menu boards
- **Important**: Proof of play reports not collected during screen-off periods

### Platform-Specific Working Hours Implementation

#### Android Devices
**Requirements:**
- Only works on rooted devices with Wallboard 3.0.x or higher
- **Recommendation**: Always choose rooted Android devices - makes deployment and management significantly easier
- Non-supported devices (beyond Giada/Qbic) may not function properly
- **Critical**: Test before large deployments on unsupported hardware

**Qbic Special Configuration:**
- Uses built-in working hours functionality
- Cannot accept different hours for different days of week
- Simplified configuration options compared to standard Android

**Auto-Restart Behavior:**
- When "Turn off type" is set to "Device", device automatically restarts after sleep period

#### Windows Devices
**System Requirements:**
- Windows 10 or 11 Pro/Enterprise editions only
- Wake up timer must be enabled in Control Panel
- **Configuration Path**: Control Panel → Hardware and Sound → Power Options → Change Plan Settings → Change Advanced Power Settings → Sleep → Allow wake timers
- Enable for both "On battery" and "Plugged in" options

**Kiosk Mode Considerations:**
- If not in Kiosk mode, Autologon must be configured before enabling feature
- **Capability gate (as of windows-client PR [#209](https://github.com/WallboardPlatform/windows-client/pull/209), merged 2026-09)**: display power control uses **Modern Standby** detection, not a touch/tablet capability check. Traditional signage PCs with USB touchscreens (e.g. Giada + Samsung touch) are no longer wrongly excluded by a tablet-mode gate; customer hardware validation may still be pending after merge.

**Auto-Restart Behavior:**
- When "Turn off type" is set to "Device", device automatically restarts after sleep

#### BrightSign Devices
**Limitations:**
- Only supports "Screen" type turn-off (cannot power off entire device)
- Hardware-dependent functionality for display control

**CEC-Capable Displays:**
- Device will control screen power via CEC commands
- Full display on/off functionality

**Non-CEC Displays:**
- Will disconnect HDMI interface when possible
- Limited display control options

#### Samsung/LG Smart TVs
**Implementation Strategy:**
- Leverages built-in TV working hours functionality
- Platform-optimized power management

**Samsung TVs:**
- When set to "Device" type, entire TV powers off
- Integrated with Samsung's native power management

**LG TVs:**
- Uses TV's integrated working hours system
- WebOS native power control integration

#### Sony Signage Displays
**Required Setup Configuration:**
- Remote device control: Settings → Network → Home network setup → Renderer → Enable
- Simple IP protocol: Settings → Network → Home network setup → IP control → Simple IP protocol → Enable

#### Vestel OPS Devices (Windows)
**Special Configuration Requirements:**
- Windows Signage application version 4.0.103 or higher
- AutoStart must be enabled
- Microsoft AutoLogon application required
- Vestel TV UART 0 and UART 1 set to ASCII
- Special screen control configuration required via CMS

#### Allsee Devices
**Critical Setup Requirements:**
- Android application version 4.0.94 or higher
- **Essential**: Advanced configuration required - Working hours will NOT work without proper setup
- Must specify DEVICE_API configuration: `{"api": "ALLSEE"}`

### Advanced Working Hours Features

#### Reverse Hours Configuration
**Capability**: Configure working hours where start time is later than end time

**Example**: Friday 09:45 - 00:15
- Active from 09:45 to midnight
- Then from midnight to 00:15 next day

**Technical Implementation**: Reverse hours effectively creates 2 working hour periods per day (before midnight + after midnight)

**Known Limitations**: 
- **LG Devices**: Some LG models cannot handle reverse hours because they only support 1 working hours period per day
- **Platform Variability**: Other platforms may have similar single-period limitations

**Warning**: May not function properly on all devices - use cautiously and only when essential for business requirements

#### JSCore Device Special Behavior
**Logic**: If "Working hours" device type is applied and scheduled wake time is less than 3 minutes away, device will not shut down immediately

**Rationale**: Prevents unnecessary power cycling for imminent wake times

### Automatic Reboot Management

#### Purpose and Health Benefits
- **Function**: Set daily reboot time for devices
- **Health Benefit**: Clears device memory and improves performance over time
- **Recommendation**: Use either Working Hours OR Automatic Reboot for optimal device health

#### Configuration Methods

**UI Configuration:**
- Navigate to Devices menu → Select device → Details tab → Settings → Reboot time
- Enable "Set auto reboot time" and enter desired time

**Best Practices:**
- Schedule reboots during off-business hours
- Stagger reboot times across multiple devices to prevent simultaneous downtime
- Consider content schedules when setting reboot times

## Update Management System

### Update Distribution Architecture

#### General Update Process Flow
1. **Check Frequency**: Devices check for updates every 30 minutes
2. **Download Process**: Updates downloaded automatically when available
3. **Installation Trigger**: Updates take effect only on next device reboot
4. **Two-Stage Process**: Download first, then install on restart

#### Update Distribution Characteristics
- **No Server-Side Rollout Groups**: The active version is server-wide per client application type; eligible devices discover it through their own update cycle
- **Device Rules Apply**: Version limits, update windows, platform requirements, and network availability can delay or prevent installation
- **Activation Is Not Installation**: Making a version active does not immediately install it across the fleet
- **No Automatic Downgrade**: Devices already running a newer version do not downgrade when an older server version is activated

### Update Control Mechanisms

#### Server-Wide Client Application Activation
- **Location**: **Administrator > System Settings > Client Applications Settings**
- **Version states**: **Active version** is the server-published package; **Latest release** is the newest available release; **Version** selects an exact installer to download; **Version to activate** selects the server-wide active release
- **Scope/permission**: Per licensed client application type; requires Super Administrator write access
- **Activation**: Selecting **Activate** downloads the chosen published version when needed and publishes it to that application's active update location
- **Device effect**: Devices below the active version are recalculated as outdated and may update through their existing client workflow; activation does not force a restart or bypass device update rules
- **Older versions**: An older available release can become active, but already-newer devices require a separate supported installation workflow to downgrade
- **Automatic activation**: **Activate updates automatically** can later replace a manually selected version with the latest release

#### Application Version Limiting
**Device-Level Control:**
- Version limits set per individual device
- Batch operations supported for multiple devices simultaneously
- Maximum version setting prevents updates beyond specified version
- "Never Update" option completely deactivates updating using limit settings

**Strategic Benefits:**
- Controlled update rollouts
- Version compatibility maintenance
- Testing environment isolation
- Compliance with specific software requirements

#### Install Application Method
**Remote Installation Capabilities:**
- Remotely trigger specific application version installation
- Selective installation on chosen devices
- Testing capability for limited device sets before wide deployment
- **Platform Limitations**: Same as automatic updates (Android root requirements, etc.)

#### Advanced Nexus Integration Strategy
**Nexus Integration Workflow:**
- Server connects to Nexus to download applications
- New versions available on server without automatic activation
- Testing pipeline: New versions accessible for testing before wide activation
- Staged deployment process: Test → Validate → Activate workflow

**Recommended Staging Process (Workaround for Limited Native Staging):**
1. **Download Phase**: New version downloaded from Nexus to server (not activated)
2. **Testing Phase**: Use "Install Application" command on limited test devices
3. **Validation Phase**: Partner server managers conduct their own testing procedures based on their environment and requirements
4. **Activation Phase**: Activate version server-wide after successful testing
5. **Deployment Phase**: All devices receive update in normal 30-minute cycle

**Framework Limitations:**
- Staging capabilities are workarounds rather than native built-in features
- Partners must develop their own testing and validation procedures
- No standardized rollout controls beyond version limiting and manual installation commands

**Validation Responsibilities:**
- **Partner Server Managers**: Responsible for conducting their own device update testing
- **Wallboard Lab Testing**: Covers standard tests (application updates, installation, new feature-specific functionality)
- **Custom Testing**: Partners develop testing procedures based on their specific deployment needs and use cases

### Platform-Specific Update Behavior

#### Android Devices
**Rooted Android:**
- Application updates automatically on device restart
- Silent installation with no user interaction required
- Full system integration capabilities

#### Windows Devices
**Standard Windows:**
- Automatic updates similar to rooted Android devices

**Windows Kiosk Mode:**
- Update command restarts entire device (not just application)
- Maintains kiosk lockdown through update process
- Enterprise-grade update control

**Update Command Behavior:**
- Standard: Restarts application only
- Kiosk Mode: Restarts entire device

#### JSCore Platforms (BrightSign, Samsung, LG)
**JSCore to JSCore Updates:**
- Software attempts to update every time it restarts
- Automatic process with no manual intervention required
- Platform-optimized update mechanisms

**Legacy Applications:**
- **BrightSign Legacy**: Automatic updates similar to Android and Windows
- **LG and Samsung Legacy**: No auto-update available, can be updated through Editor interface

#### Legacy to JSCore Migration
**Migration Requirements:**
- User command required: Cannot auto-migrate
- Specific migration command: `{"user_command": "UpgradeToJsCore"}`
- Manual intervention necessary for migration process

## Firmware Update Management

### Firmware Update Availability
**JSCore Platforms Only**: Remote firmware updates are exclusively available on JSCore devices
- **Supported Platforms**: BrightSign, Samsung Tizen, LG WebOS
- **Not Supported**: Android and Windows platforms do not support remote firmware updates

# Wallboard Content & Performance Management Guide

## Content Type Selection Framework

### Performance Hierarchy (Lowest to Highest Resource Impact)
1. **Playlists** - Low overhead sequential playback, efficient memory usage
2. **Simple Contents** - Moderate resource usage for basic layouts
3. **Complex Contents with Interactivity** - Higher resource requirements for advanced features
4. **Content Widgets (iframes)** - Highest performance impact due to nested rendering

### Content Type Decision Matrix

| Use Case | Recommended Type | Performance Impact | Key Benefits |
|----------|------------------|-------------------|--------------|
| Sequential media display | Playlist | Low | Minimal processing overhead, efficient playback |
| Simple single-page content | Slide | Low-Medium | Fast loading, playlist-compatible |
| Multi-page interactive content | Content | Medium-High | Full feature set, embedding capabilities |
| Dynamic content distribution | Channel | Medium | Balanced performance, flexible targeting |
| Temporary overrides | Schedule | Low | Lightweight, minimal system impact |

## Content Distribution Architecture

### Push-Based Distribution System
- **Centralized Control**: All content distribution initiated from CMS
- **Real-time Updates**: Content changes pushed to devices immediately
- **Device Notifications**: Devices receive update notifications from CMS
- **No Pull Polling**: Devices don't continuously poll for updates

### Local Device Caching Strategy
- **Content Storage**: Frequently used content cached locally for performance
- **Offline Operation**: Devices continue operating during network outages
- **Automatic Cache Management**: Old content automatically cleaned up
- **Intelligent Preloading**: Content downloaded before scheduled display time

## Platform-Specific Performance Guidelines

### BrightSign Performance Constraints

#### General BrightSign Limitations
- **File Format Restrictions**: Limited to supported media formats only
- **Memory Constraints**: Available memory affects maximum content complexity

#### BrightSign Series 5 Specific Issues
- **Rotation Limitation**: Per-widget rotation not supported
- **Display-Only Rotation**: Only entire display can be rotated
- **Hardware Acceleration Impact**: Non-hardware accelerated players can rotate but media sources inside cannot

#### BrightSign Series 4 Critical Limitation
- **4K Portrait Problem**: Rotating 4K video content to portrait orientation fails
- **Required Workaround**: 
  - Keep content and player in landscape mode
  - Pre-rotate video content 90 degrees during video editing/production process before encoding
  - Encode the pre-rotated video as 3840x2160 (content is already rotated within the video file)
  - Maintain landscape orientation throughout system
- **Resolution Constraints**: More limited than Series 5 for high-resolution content

## Performance Troubleshooting Framework

### Common Performance Issues and Symptoms
- **Slow Page Transitions**: Large files or complex layouts causing delays
- **Stuttering Playback**: Insufficient processing power for content complexity
- **Memory Issues**: Resource-intensive content or memory leaks
- **Network Bottlenecks**: Large files overwhelming available bandwidth

### Systematic Diagnostic Approach
1. **Variable Isolation**: Test individual content elements separately
2. **Hardware Verification**: Confirm hardware meets content requirements
3. **Network Testing**: Verify adequate bandwidth and connection stability
4. **Content Analysis**: Review content complexity and file sizes
5. **Platform Comparison**: Test identical content on different platforms

### Resolution Strategy Hierarchy
1. **Content Simplification**: Reduce complexity of problematic elements
2. **File Optimization**: Compress images, optimize video encoding
3. **Hardware Upgrade**: Deploy more powerful hardware for demanding content
4. **Content Restructuring**: Break complex content into simpler components
5. **Alternative Implementation**: Use different content types or widgets
6. **Platform Migration**: Move to more suitable platform if necessary

# Wallboard Platform & Hardware Complete Guide

## Supported Platform Architecture Overview

### Platform Categories

#### Mobile/Tablet/Mini PC Operating Systems

##### Android Platform
- **Type**: Mobile/tablet operating system with native Android application
- **Version Support**: Android 5+ supported, up to Android 12 with specific caveats
- **Architecture**: Native Android application with full OS integration

**Core Strengths:**
- Full device control capabilities (brightness, volume, power management)
- Hardware-accelerated video support for optimal performance
- Comprehensive sensor support (Enterprise license required)
- Flexible deployment options across various hardware types

**Root Access Enhanced Features:**
- Silent updates without user intervention
- System time synchronization capabilities
- Complete device lockdown for kiosk deployments
- WebView replacement for enhanced compatibility

**Android 12+ Challenges and Solutions:**
- **Limitations**: Restricted customization options, limited device management capabilities
- **Primary Impact**: Non-signage consumer devices more difficult to manage
- **Solution**: Wallboard Lite (browser-based client application)

##### Wallboard Lite (Android 12+ Alternative)
- **Type**: Browser-based client application for modern Android devices
- **Target Audience**: Android 12+ devices with Google Play Store access
- **Implementation**: Progressive Web Application approach (not native Android app)

**Advantages:**
- Handles newer Android versions effectively
- No root access requirements
- Compatible with consumer Android devices
- Simplified deployment process

**Limitations:**
- Content display limitations compared to native application
- Reduced feature set versus full Android implementation
- Limited device control capabilities

##### ChromeOS Platform
- **Type**: Google Chrome-based operating system
- **Application**: Browser-based client with Chrome extension support
- **Architecture**: Web-optimized performance with integrated Chrome browser

**Strengths:**
- Web-optimized performance and security
- Simple deployment and management processes
- Robust security model with automatic updates
- Good integration with Google ecosystem

**Limitations:**
- Limited advanced device control features
- Dependency on Chrome browser capabilities
- Reduced offline functionality compared to native applications

#### Desktop Operating Systems

##### Windows Platform
- **Type**: Full desktop operating system with native Windows application
- **Application**: Native Windows application with complete system integration
- **Requirements**: Windows 10/11 (Enterprise required for Kiosk mode)

**Core Strengths:**
- Complete PC functionality and system access
- Robust performance for complex content and multi-screen setups
- Excellent support for 4K content and high-resolution displays

**Enterprise Features:**
- Kiosk mode lockdown capabilities (Enterprise license required)
- Advanced multi-screen management
- Integration with corporate IT infrastructure
- Comprehensive device management features

**Characteristics:**
- Reduced resource usage compared to full Windows Wallboard client
- Limited advanced device control features

### Smart TV Platforms (JSCore Technology)

#### Samsung Tizen Platform
- **Platform Types**: TEP (Tizen Entertainment Platform) and SSSP (Samsung Smart Signage Platform)
- **Application**: JSCore cross-platform technology
- **Architecture**: Integrated TV solution with native Samsung TV integration

**Strengths:**
- No external hardware required (built into TV)
- Good display control and power management
- Integration with Samsung's smart TV ecosystem
- Professional signage features (SSSP models)

**Limitations:**
- Limited system-level access compared to dedicated hardware
- No sensor/IoT integration capabilities
- WebView version fixed per model series (firmware updates don't change browser version)
- Platform-specific performance constraints

#### LG WebOS Platform
- **Platform**: WebOS TV platform with JSCore implementation
- **Application**: JSCore cross-platform technology
- **Architecture**: Built-in TV functionality with WebOS integration

**Strengths:**
- Easy deployment with no additional hardware
- Good display control and power management features
- Integration with LG's WebOS ecosystem
- Simple content management and updates

**Limitations:**
- Limited advanced feature support compared to dedicated platforms
- No sensor/IoT integration support
- WebView version fixed per model series (no browser updates via firmware)
- Reduced customization options

### Dedicated Digital Signage Hardware

#### BrightSign Platform
- **Type**: Purpose-built digital signage hardware platform
- **Series Support**: Series 3, 4, and 5 with varying capabilities
- **Application**: JSCore cross-platform technology optimized for signage
- **Architecture**: Professional reliability hardware designed for 24/7 operation

**Professional Advantages:**
- Designed specifically for continuous 24/7 operation
- Excellent reliability for mission-critical deployments
- Hardware-accelerated video processing capabilities
- Full sensor/IoT integration support (Enterprise license)
- WebView updates available through firmware updates
- No consumer hardware limitations

**Series-Specific Capabilities:**
- **Series 5**: Latest generation with enhanced 4K support and performance
- **Series 4**: Reliable mid-range with good 4K support (with rotation limitations)
- **Series 3**: Basic signage functionality for standard deployments

### Web-Based Platforms

#### Browser Client (PWA)
- **Type**: Progressive Web Application for universal browser compatibility
- **Requirements**: Chromium 71+ browser engine
- **Architecture**: Cross-platform web application with Chrome extension support

**Advantages:**
- Universal browser compatibility across platforms
- Easy testing and temporary deployment scenarios
- No installation requirements for quick setup
- Good for proof-of-concept and demonstration purposes

**Limitations:**
- Limited device control capabilities
- Requires browser extensions for advanced features
- Reduced offline functionality
- Performance limitations compared to native applications

## Hardware Requirements & Recommendations

### Detailed System Requirements

#### Android Root vs Non-Root Feature Matrix
**Features Unavailable on Non-Rooted Android Devices:**
- Silent background application updates
- System-level time synchronization with NTP servers
- Complete device lockdown
- WebView replacement for compatibility improvements

**Impact Assessment:**
- **Rooted Devices**: Full feature set with enterprise-grade capabilities
- **Non-Rooted Devices**: Basic signage functionality with manual update requirements

#### Android Platform Requirements
**Minimum System Requirements:**
- Android 5.0+ operating system
- 4-core ARM or x86 processor
- 2 GB RAM minimum
- 32 GB internal storage

**Recommended System Specifications:**
- Android 8.1+ (rooted devices preferred for full feature set)
- 6-core processor with hardware video acceleration
- 4 GB RAM for optimal performance
- 32 GB internal storage (SSD preferred for faster access)
- **Note**: Android 12+ devices face customization challenges, consider Wallboard Lite

#### Windows Platform Requirements
**Minimum System Requirements:**
- Windows 10 or Windows 11 operating system
- Dual-core processor with integrated GPU
- 2 GB RAM minimum
- 20 GB free disk space for application and content storage
- .NET Framework 4.6.2 or higher
- Administrator rights required for installation and advanced features

**Recommended Mini PC Specifications:**
- Mobile dual-core or quad-core processor (undervolted for heat management)
- 4 GB DDR4 RAM
- eMMC or SSD storage for reliability and performance

**Recommended Desktop/Signage Specifications:**
- Quad-core standard voltage processor
- 8 GB DDR4 RAM for optimal performance
- SSD storage for faster boot times and better overall performance
- Integrated or dedicated GPU based on content complexity requirements

**Windows License Requirements:**
- **Professional License**: Basic Wallboard functionality supported
- **Enterprise License**: Required for advanced Kiosk mode lockdown features
- **Home License**: Not supported for Wallboard deployments

#### Smart TV Platform Requirements
**Samsung Tizen Requirements:**
- Minimum: Tizen 4.0 (Chromium 56 equivalent)
- Recommended: Tizen 6.0+ (Chromium 76+ equivalent)
- Professional signage models preferred for commercial use

**LG WebOS Requirements:**
- Minimum: WebOS 4.x (Chromium 53 equivalent)
- Recommended: WebOS 6.x (Chromium 79 equivalent)
- Commercial display models recommended for professional deployments

## Browser & WebView Compatibility

### General Compatibility Requirements
- **Editor UI**: Google Chrome latest version recommended for content management
- **Device Content Rendering**: Minimum Chromium 53+ equivalent webview engine
- **Browser Client**: Chromium 71+ required for Progressive Web Application features

### WebView Update Management
- **Android Devices**: Manual WebView replacement possible but carries risk of system failure
- **Samsung/LG Smart TVs**: WebView version permanently fixed per model series, firmware updates do not change browser version
- **BrightSign**: WebView version built into firmware, firmware updates can change browser capabilities
- **Windows**: WebView built into Wallboard application, regularly updated by Wallboard
- **ChromeOS**: Automatic Google Chrome updates provide WebView improvements
| Feature | Android | Windows | BrightSign | Samsung | LG | ChromeOS | Browser Client |
|---------|---------|---------|------------|---------|----|---------|--------------| 
| Screen Orientation | ⚠️ Some Models Limited | ✔️ Full Support | ✔️ Full Support | ⚠️ Tizen 6.5+ Limited | ✔️ Full Support | ⚠️ Extension Required | ❌ Not Available |
| Content Orientation | ✔️ Full Support | ✔️ Full Support | ✔️ Full Support | ✔️ Full Support | ✔️ Full Support | ✔️ Full Support | ✔️ Full Support |
| Auto Rotate | ❌ Not Available | ✔️ Available | N/A | ⚠️ Tizen 7+ Limited | N/A | N/A | N/A |

## Platform Selection Decision Framework

### Selection by Primary Use Case

#### Simple Content Display Requirements
- **Recommended Platforms**: Browser Client, ChromeOS, Samsung/LG Smart TVs
- **Key Benefits**: 
  - Easy setup and deployment process
  - Minimal ongoing maintenance requirements
  - Cost-effective for basic signage needs
  - Good for proof-of-concept and testing

#### Interactive Installation Requirements
- **Recommended Platforms**: Android (with touch capabilities), Windows with touch displays
- **License Requirements**: Premium license for full interactive feature support
- **Key Benefits**: 
  - Full interactive capabilities with touch and gesture support
  - Sensor integration for advanced IoT scenarios
  - Kiosk mode capabilities for public installations
  - Advanced user interaction tracking and analytics

#### Professional 24/7 Signage Requirements
- **Recommended Platforms**: BrightSign, Windows with professional hardware
- **Key Benefits**: 
  - Maximum reliability for continuous operation
  - Comprehensive remote monitoring and management
  - Hardware designed specifically for signage applications
  - Professional support and warranty options

#### Video Wall Deployments
- **Recommended Platforms**: Dedicated video wall controllers, multi-output BrightSign units
- **License Requirements**: Video Wall license for multi-output support
- **Key Benefits**: 
  - Unlimited video outputs with proper licensing
  - Synchronized playback across multiple displays
  - Advanced content spanning and management
  - Professional video wall configuration tools

#### Enterprise IoT Integration Requirements
- **Recommended Platforms**: Android (rooted preferred), Windows, BrightSign
- **License Requirements**: Premium license for full IoT feature access
- **Key Benefits**: 
  - Full sensor integration capabilities
  - MQTT/HTTP server functionality for IoT communication
  - Advanced data collection and processing
  - Real-time response to environmental conditions

## JSCore Technology Framework

### JSCore Architecture Overview
JSCore is Wallboard's comprehensive cross-platform application technology used across Samsung Tizen, LG WebOS, and BrightSign platforms. It provides consistent Wallboard functionality and user experience across these diverse hardware platforms.

### Performance & Platform Relationship
- **Performance Variations**: Performance and capability differences are primarily due to underlying platform limitations (Tizen vs WebOS vs BrightSign OS), not JSCore implementation differences
- **Platform-Dependent Capabilities**: Actual device capabilities depend entirely on what each underlying platform can support at the hardware and OS level
- **Consistent User Interface**: JSCore provides uniform Wallboard experience and functionality across all supported platforms
- **Cross-Platform Development**: Single codebase maintains consistency while adapting to platform-specific capabilities

### JSCore Implementation Benefits
- **Functional Equivalence**: JSCore provides equivalent functionality where platform capabilities allow
- **Platform Optimization**: JSCore is optimized for each specific platform while maintaining consistent core functionality
- **Resource Efficiency**: Designed for optimal resource usage across different hardware configurations
- **Update Management**: Consistent update mechanisms across all JSCore-supported platforms


# Device Metrics

## Overview

Device Metrics provides comprehensive real-time monitoring and historical analysis of digital signage device performance, health, and operational status. The system enables remote diagnostics, preventive maintenance, and performance optimization across device fleets.

## Access and Navigation

**Primary Access**: Analytics -> Device Metrics
**Device-Specific Access**: Devices -> [Select Device] -> Metrics tab; Overview includes an uptime chart
**Time Range Options**: Overview initially Last 24 hours; Metrics initially Last 30 days. Remembered or custom ranges can override these defaults.

## Metric Categories

### Uptime Monitoring

Shows recorded online activity alongside working-hours bands, including device comparison.

**Components and interpretation**:
- **Online status** (blue): Recorded online duration. Percentage = recorded online time / full selected period, not working-hours compliance. Eight online hours in a 24-hour period = 33.33%, even if all scheduled hours were covered.
- **Working-hours bands** (green): Actual schedule changes automatically save the previous configuration and its validity period. The chart uses saved previous schedules plus current settings. Labels read **Working hours** when history entries exist; otherwise **Configured working hours**.
- **Historical coverage**: Selection is day-based, not exact within-day replay. No history is backfilled. Uncovered ranges fall back to current settings; an unknown first start extends that saved value backward without reconstructing earlier changes. Retention follows device metrics (default 90 days, configurable); entries ending before the cutoff are pruned on subsequent schedule changes.
- **Always on / missing settings**: Historical empty-days values render all-day; historical absent values can leave gaps. Current Always on days can lack bands when older restricted bands exist. Clearing settings therefore does not guarantee a full-period band. Bands use the current saved timezone and current offset, not historical timezone settings.
- **Event markers**: Red reconnection events retain their count. Orange dashed **Configured reboot** markers repeat the current configured reboot time across the range; they are neither reboot history nor proof of an actual reboot.

### CPU Performance

**CPU Usage**
- Percentage of processor utilization
- Normal operation: <70%
- Performance impact threshold: >80%

**CPU Temperature**
- Thermal monitoring in °F or °C
- Safe operating range: <60°C (140°F)
- Critical threshold: >80°C (176°F)

**Thread Count**
- Active system processes
- Indicates multitasking load and resource competition

### Graphics Performance

**Frames Per Second (FPS)**
- 1-minute averaged rendering performance
- Optimal range: 55-60 FPS
- Minimum acceptable: 30 FPS
- Below 30 FPS causes visible stuttering

### Memory Management

**System Memory**
- Total device RAM consumption including OS
- Includes all running applications and services
- Measured in GB

**Application Memory**
- Wallboard-specific memory usage
- Normal range: 100-500 MB
- Spikes indicate content loading or complex rendering
- Continuous growth suggests memory leak

### Storage Monitoring

**Primary Storage Usage**
- Cached content and application data
- Temporary files and logs
- Database storage
- Available space tracking

### Network Analytics

**Network RX (Receive)**
- Data downloaded from server
- Content updates and configuration changes
- Measured in KB/MB with sum totals

**Network TX (Transmit)**
- Data uploaded to server
- Logs, status updates, proof of play
- Typically much lower than RX

**Network RX System**
- Total device network consumption
- All applications combined
- Identifies bandwidth competition

**Server Response Time**
- Latency to Wallboard servers
- Excellent: <50ms
- Acceptable: <100ms
- Problematic: >300ms

### System Status

**Wi-Fi Signal Strength**
- Measured in dBm (0 = perfect)
- Good: > -60 dBm
- Poor: < -70 dBm

**Wi-Fi Signal Level**
- Simplified 0-5 scale
- Platform-dependent representation

**Internet Connection**
- Online/offline period visualization
- Pattern identification for connectivity issues

**Battery Level**
- Relevant for mobile and tablet deployments
- Power consumption tracking

### Event Logging

**Info Logs**
- Standard operational messages
- High volume normal for active devices

**Warning Logs**
- Non-critical issues requiring attention
- Pattern analysis recommended

**Error Logs**
- Critical failures
- Immediate investigation required
- Target: 0 errors

### Application Stability

**Startup Count**
- Application initialization frequency
- Normal: 1-2 per day (scheduled reboots)
- High count indicates instability

**Crash Metrics**
- **Application Crashes**: Complete app failures
- **WebView Crashes**: Content rendering failures
- **Frontend Process Crashes**: Display process failures
- Target: 0 for all crash types

**ANR Count** (Application Not Responding)
- UI freeze events (Android-specific)
- Indicates performance bottlenecks

**System Error Count**
- OS-level failures
- Requires immediate attention

### User Interaction Tracking

**Sensor Events**
- IoT and environmental sensor triggers
- Requires Premium license
- Motion, temperature, proximity detection

**User Interactions**
- Touch, click, and gesture events
- Must be enabled in content configuration
- Engagement analytics

## Performance Thresholds

### Critical Alerts

| Metric | Threshold | Impact |
|--------|-----------|---------|
| Any Crash Count | >0 | Service disruption |
| CPU Temperature | >80°C | Hardware damage risk |
| Error Logs | >10/hour | System instability |
| FPS | <20 | Unusable experience |
| Uptime | <50% | Service level failure |

### Warning Indicators

| Metric | Threshold | Action |
|--------|-----------|---------|
| CPU Usage | >70% | Content optimization needed |
| Memory Usage | >80% | Review content complexity |
| Response Time | >200ms | Network investigation |
| Wi-Fi Signal | < -70 dBm | Connectivity improvement |
| Warning Logs | >100/day | Pattern analysis required |

## Troubleshooting Workflows

### Performance Degradation
1. Check FPS metrics for rendering issues
2. Review CPU usage and temperature
3. Analyze memory consumption patterns
4. Verify network latency
5. Optimize content or upgrade hardware

### Stability Issues
1. Review all crash counts
2. Analyze error log patterns
3. Check startup frequency
4. Verify memory leaks
5. Update software or investigate hardware

### Connectivity Problems
1. Verify Internet connection status
2. Check Wi-Fi signal strength
3. Review network RX/TX patterns
4. Analyze server response times
5. Investigate network infrastructure

### Overheating
1. Monitor CPU temperature trends
2. Check CPU usage patterns
3. Verify device ventilation
4. Review ambient environment
5. Reduce processing load or improve cooling

## Platform Considerations

### Android
- ANR events indicate UI responsiveness issues
- WebView crashes common with complex content
- Battery optimization may affect background operations
- Root access enables additional metrics

### Windows
- Higher memory usage baseline than other platforms
- Antivirus software may impact performance
- Windows updates can affect stability metrics
- GPU metrics available for graphics-intensive content

### Smart TV Platforms (Samsung/LG)
- Limited metric availability
- TV-specific services affect performance
- Firmware updates may reset metrics
- Power management features impact uptime

### BrightSign
- Purpose-built for digital signage
- Most comprehensive metric set
- Storage card health monitoring important
- Network storage performance impacts

## Data Management

### Retention Periods
- Real-time data: Immediate
- Historical data: Typically 30-90 days
- Aggregated trends: Long-term storage
- Export options for archival

### Update Frequency
- Real-time metrics: Every 60 seconds
- Aggregated data: Every 15 minutes
- Historical charts: Hourly/daily averages

## Use Cases

### Preventive Maintenance
- Monitor temperature trends to prevent hardware failure
- Track memory patterns to identify leaks early
- Analyze crash patterns before widespread issues
- Review performance degradation over time

### Capacity Planning
- Identify devices approaching performance limits
- Plan hardware upgrades based on metrics
- Optimize content distribution by device capability
- Balance load across device fleet

### Service Level Monitoring
- Verify uptime SLA compliance
- Document performance benchmarks
- Track stability improvements
- Measure impact of changes

### Remote Diagnostics
- Troubleshoot without site visits
- Identify issues before user reports
- Correlate problems across devices
- Reduce mean time to resolution