Activity-Based Control

Introduction

In traditional remote control systems, each button on the remote control device simply sends a signal to the device being cotnrolled. The signal is always the same and is dependent on the button being pressed.

With the advent of more advanced, multi-device remote controls, the concept of Activity-Based control has emerged. This is based around what the user wants to do, rather than the exact commands which will be transmitted to the devices.

As an example, consider the Action "Watch TV". In a traditional system, this could be accomplished by simply turning on the TV with its remote control, but in more complex systems, it may be necessary to turn on the TV itself, turn on a set-top box, turn on an AV amplifier and set the amplifier input to the set top box. Using basic control techniques, this requires 3 different remote controls and 4 button presses.

In an Activity-Based control system, a single command of "Watch TV" would result in the 4 commands listed above being sent to the devices, but the user only needs to select the "Watch TV" activity and is oblivious to the actual commands that are being transmitted.

State

The implementation of Activity-Based control is more complex than simply chaining commands together. Consider another activity, "Watch Bluray". This could reasonably be expanded to Turn TV on, Turn Bluray player on, Turn AV amplifier on, set the input to Bluray. However, if "Watch TV" was then selected and the 4 commands from above sent, the Turn on TV command would likely result in the TV being turned off, since power commands are often used for both on and off functions, not the desired result!

To overcome this, the actual commands that are transmitted are dependent upon the state of the equipment. When a command such as Turn on TV is sent, the remote control system also notes that the state of the TV is now on, this means that if another request to turn the TV on is received, the system knows that it is already turned on and so no action needs to be taken. As illustrated below:

Then, when the Activity Command "Watch Bluray" is issued:

It should be emphasised that the remote control system does not actually know what the state of any of the devices is, it simply assumes that once a command has been issued, the device will enter the appropriate state. If the device is not powered on, or the IR signal is not received for some reason, the remote control system has no way of detecting this.

Activity Mapping

To allow an Activity request to result in a sequence of commands, as in the examples above, requires a two stage process:

Devices

For the purposes of the remote control system, a device may be a physical device such as a TV, or it may be a logical collection of part of the functionality of a device (e.g. a STB with PVR functionality could be split into two devices - this may, or may not be useful in real life)

Devices can also be associated with a category. Each device may have zero or more categories. Categories are used for performing multiple device activities, for instance, turning off unused devices when selecting a new input source

Each device within the remote control system must have a unique name for addressing purposes.

Desired States

Activities have no instrinsic heirarchy, although they may be arranged into one in order to simplify the control presentation to the user. Each activity is given a unique name and is associated with a list of controled devices and their desired states. For example, from above

States consist of two pieces of information:

The Attribute name can be in any format, however for clarity it is recommended that a Device name is used to identify the scope of the attribute. In this example Device and Attribute name are seperated by a dot

State to Command Mapping

IR commands are referenced by a Remote ID and a Command ID. The Remote ID indentifies the remote control being emulated, and thus a physical device such as a TV. The command identifies the button on the remote which is being emulated. Again, the convention here is to separate the two items with a dot.

In order to map from a desired state to an IR command, a table of States and values is used, as in the example below:

Note that when an IR Command is sent, the attribute is set to a new state value. This may or may not be the desired state. The remote control system will continue to inject commands into the table until the desired state is reached. This supports multiple IR commands for a single state transition.

Note that it should also be possible to list multiple IR commands for a single state transition. This then allows for additional bullet-proofing of the IR comamnd sequence.

Note that when no Current State is specified, the IR Command and New state are always generated for the specified Desired State value, regardless of the current state of the attribute.

Using a combination of Desired State mapping and State to Command Mapping, a single Activity can be translated into a sequence of IR Commands and Attribute State updates.

Designing the Mapping

Although, in principal, the design of the IR command mapping should be straightforward, there are a number of considerations which make the system more reliable. It should always be considered that one or more IR commands from a sequence may not be received correctly and sometime it is simple to recover from such an eventuality

On some occasions, there may be a choice of buttons on a remote control to accomplish the same function (for instance, on the Sky STB power on can be accomplished by the power button or the sky button). When a choice is present, the button with least state should be selected - so a specific power on command should be selected over a power on/off command, this minimises the potential for undesired results as introducted at the begining of this article.

Where possible, it is useful to assert a specific mode or state in the device being controlled. Sometimes a menu or back-up button will ensure the device is in a particular state, for instance to receive a channel number sequence. This helps in cases where a previous command sequence failed

External links