LG on demand screen control via Web Triggers

Overview

This document is an overview on commands and priorities when using screen control via Web Triggers on LG devices running client version 1.995 and above.

The new on demand screen control via Web Triggers API feature allows screen control for all supported webOS devices to be controlled remotely through Web Triggers API calls either individually or on groups.

Example of commands used

Example of ScreenOn Send Message POST sent to individual player:

{
"interrupt":1, //ScreenOn
"players":[00001],
"groups":[]
}

Example of ScreenOff Send Message POST sent to individual player:

{
"interrupt":2, //ScreenOff
"players":[00001],
"groups":[]
}

These ScreenOn and ScreenOff commands mimic the generic screen control functionality where:

• ScreenOn turns on the media player and content should start playing on-screen
• SceenOff stops the media player and should show a blank screen

If you have a screen control scheduled published to your player then when the next state change occurs (e.g. to turn the screen on) this will override the Web Triggers state you have sent to the player. Note that if you turn off the screen for the media player and then reboot the device then this should adhere to the screen off state. An example workflow would be as follows:

1. Web Triggers - sent ScreenOff command at 10AM
2. Screen control schedule is due to turn on the screen at 10:30AM
   • If you reboot the player before 10:30AM then the screen should stay off due to Web Triggers taking priority
3. At 10:30AM the screen should turn on and the media player should start
   • If you reboot the player after 10:30AM when the screen control schedule is due to take effect then the screen should stay on

Note screen control schedules that are published that are “in the past” compared to the last Screen on/off command will not override the current screen state. Although, the state of the player will be cleared on the next relevant ON/OFF of the screen control schedules available (as part of the expected workflow above).

As an example, consider the following workflow:

1. Send ScreenOff command - WBT API (e.g. at time of 16:10)
2. Publish a screen control schedule of ON: 15:00 and OFF: 23:59 (e.g. after 16:10)
3. The expected outcome is for the screen to stay in the ScreenOff state, this is because the command is ahead in terms of the device's current time and playback sequence; regardless of whether the screen control schedule was published after the command itself.