# Compatibility and protocol notes · 0.1.0-beta.4 source candidate This is a cross-platform **testing source/build candidate**, not a released or hardware-validated build. It follows the cross-platform beta.3 candidate; the installed/website build remains Windows 0.1.0-beta.2. Beta.4 has not been released, and no expiry behavior is claimed for existing beta.2 binaries. Automated adapter tests do not validate a specific TV, computer, package, login integration, or wake behavior. The original Samsung prototype’s full-off sequence was observed working on a 2021 The Frame; that is the extent of prior physical-TV evidence. Test every TV in person with the beta's full-off test before enabling it. ## Samsung Tizen and The Frame Uses REST `8001/api/v2/` for identity and power state, then an authenticated TLS WebSocket on port 8002 for remote control. The initial pairing prompt must be accepted on the TV. This beta requires a token-capable encrypted remote API. The Frame is recognized by `LS03` in its model identifier. Its full-off command holds `KEY_POWER` for three seconds, then releases. Other Samsung models receive the dedicated `KEY_POWEROFF` key. Unsupported keys cause a failed physical off test and must not be enabled. Before opening the remote channel, the TV must report on. Power/identity are checked again after connecting. The client omits Origin, which was necessary on the tested Frame firmware. No Wake-on-LAN packets are sent. Primary implementation references: [Samsung TV WebSocket API project](https://github.com/xchwarze/samsung-tv-ws-api), [Home Assistant Samsung bridge implementation](https://github.com/home-assistant/core/blob/dev/homeassistant/components/samsungtv/bridge.py). ## LG webOS · experimental Uses TLS WebSocket port 3001, a permission prompt, and a client key. The registration manifest requests power control, power-state access, network state, and software information. It contains no copied vendor signature or impersonated vendor identity. Uses `ssap://com.webos.service.tvpower/power/getPowerState` and `ssap://system/turnOff`. The power API must return a recognized state. Insecure port 3000 and older firmware without this state endpoint are outside this beta. Turn on mobile/network control if present; menu wording varies. The TV must be awake for pairing and testing. Primary references: [LG Connect SDK](https://github.com/ConnectSDK/Connect-SDK-Android-Core/blob/master/src/com/connectsdk/service/WebOSTVService.java), [aiowebostv registration](https://github.com/home-assistant-libs/aiowebostv/blob/main/aiowebostv/handshake.py), [aiowebostv endpoints](https://github.com/home-assistant-libs/aiowebostv/blob/main/aiowebostv/endpoints.py). ## Sony BRAVIA with IP Control · experimental Enable IP Control and **Normal and Pre-Shared Key** authentication. Enter that key during setup. Do not select unauthenticated access. Some consumer models lack this API or expose different settings. Uses Sony’s HTTP REST API on port 80 with `X-Auth-PSK`: `getSystemInformation`, `getPowerStatus`, and `setPowerStatus` with `status: false`. JSON error responses are checked even when HTTP succeeds. The PSK is sent over the trusted local network by this protocol; do not expose the TV’s control ports to the internet. No Android debugging/ADB connection is used. Primary reference: [Sony BRAVIA REST API reference](https://pro-bravia.sony.net/remote-display-control/rest-api/reference/). ## Vizio SmartCast · experimental Uses the local HTTPS API on port 7345, with legacy port 9000 selectable during setup. Pairing starts an on-screen PIN challenge and stores the returned AUTH token. Responses use `ITEM` for pairing and `ITEMS` for power state. Checks `/state/device/power_mode` for on and sends `/key_command/` codeset 11, code 0 (dedicated off). It does not use code 1 (on) or code 2 (toggle). Certificate pinning is checked before authentication on later requests. Firmware can remove or change this community-documented API. Primary implementation references: [Vizio SmartCast protocol project](https://github.com/exiva/Vizio_SmartCast_API), [pyvizio pairing implementation](https://github.com/raman325/pyvizio/blob/master/pyvizio/api/pair.py), [successor vizaio project](https://github.com/raman325/vizaio). ## Roku · control excluded The [current Roku ECP documentation](https://developer.roku.com/dev/docs/external-control-api) prohibits ECP commands from third-party platforms. This beta can label a discovered Roku device as unsupported, but includes no Roku command adapter. A commercial integration needs an acceptable vendor-supported path. ## Other platforms Generic Google/Android TV and Amazon Fire TV are not implemented. TCL and Hisense sell TVs with multiple operating systems; their brand name does not identify a supported local-control protocol. These models should remain outside the beta unless they match a documented adapter and pass its off test. ## Common limits Private IPv4 home-network addresses only. No IPv6, hostname entry, subnet sweep, internet control, account linking, or vendor-cloud credentials. Discovery uses SSDP and is optional. IP address reservation is recommended; remove and pair again if it changes. Self-signed TV certificates are trusted on first explicit pairing; later certificate changes require pairing again. An offline response is never treated as confirmed off. Failed authentication or changed identity disables that TV. Unknown states cause no power command. Physical off-test confirmation is required for every device before enabling schedule control. ## Testing-build expiry Alpha, beta, rc, test, and dev builds with testing-build metadata expire 30 days after their embedded UTC BUILD timestamp, not 30 days after installation or first launch. Deleting/reinstalling local state does not extend the embedded deadline. Stable non-testing releases do not expire. No claim is made that existing beta.2 binaries expire. The expiry date is shown in the app UI. Expiry checks run at app start, on actions, before TV-command authorization, on resume, and at randomized 30–120 second intervals. Local last-seen time and monotonic runtime help detect clock rollback with a five-minute skew tolerance. Invalid metadata/state or inability to persist state fails closed. Expiry disables the guard, stops TV commands, and releases keep-awake. Diagnostics export, inspecting/removing saved TVs, and explicitly disabling startup/wake settings remain available. There is no automatic administrator prompt or privilege cleanup at random expiry; an existing native wake task may remain until the user disables its setting in Settings. Expiry does not delete local data. This local testing safeguard has no server entitlement or tracking, makes no anti-debug claim, and is not tamper-proof. Testing builds are free during testing; users can download a newer testing build to continue testing. ## Desktop platform and power support The build scripts target Windows x64 Setup/portable, macOS Intel and Apple Silicon DMGs built on a native Mac runner, and Linux x64 AppImage/deb. GitHub Actions uses native OS runners to run automated tests, build, calculate checksums, and upload CI artifacts only. This workflow does not publish a public release, and CI packaging is not hardware validation. Candidates are unsigned evaluation packages. The guard checks TVs only while the user is signed in, the app is running, the computer is awake, and local network access is available. Startup and wake features are optional and best-effort: - **Windows:** Electron login/startup launches the app in the existing signed-in session. The optional wake task also launches there; Windows wake settings and hardware must support wake timers. - **macOS:** Electron login items provide startup. Optional app-owned wake events are managed through a privileged native helper/launchd and may request administrator authorization. OS power policy, hardware, lid state, and FileVault/login conditions can affect whether wake succeeds. - **Linux:** XDG autostart requires a desktop session that honors the entry. The optional systemd `WakeSystem=true` timer requires systemd, a supported RTC wake alarm, and a `pkexec` administrator-authorization prompt. Distribution, firmware, RTC, and power policy determine whether wake works. Pairing requires a secure desktop keyring; the Electron `basic_text` storage backend is refused. No platform guarantees wake from power-off or app startup before login. Sleep initiated manually, closed lids, power loss, OS policy, missing RTC/keyring support, or network loss can prevent operation. Optional wake requests do not make the app an always-on service. Schedule weekdays refer to the local calendar day a quiet-hours window starts; overnight windows continue into the next day. The app uses JavaScript local-time semantics: the first occurrence of an ambiguous repeated DST time is used, and a nonexistent time in a spring-forward gap advances through the gap. Native wake integrations may resolve DST and power conditions differently. Before uninstalling or moving the app, disable the guard and turn off startup/wake options in Settings, then save. Removing the binary alone does not remove app-owned wake integration or local data. Uninstalling does not itself delete app data. Consult PRIVACY.md for data locations; no manual cleanup commands are specified here. Protocol research checked September 28, 2026. Vendor policies and firmware may change.