Articles in this section

Activity groups

Required firmware version: v.1.5.0 or newer


Activity groups are a way of linking activities, so the included entities' states are handled together when switching between activities in a group.

Already powered-on entities used in both activities, are kept running and no longer used entities are switched off. This means that depending on which activity was turned on last will automatically adjust the state of entities (included in all activities within a group) to transition to the newly started activity.

Activity groups can be created and configured with the web-configurator under "Activities & Macros".

For the remaining part of this document, we use the following terms:

  • new activity: the activity one is switching to (destination), from an already active activity in the same activity group.
  • old activity: the currently active activity (source), if one is starting another activity within the same activity group.
  • active state: a running activity which has completed its on-sequence. The activity is in state ON.

Activity groups rely heavily on the included activities' state, power-on and power-off sequences. A quick summary about activities:

  • activity state: the current state of an activity. OFF when it is not running, ON when running, also referred to as active state.
  • power-on sequence: automatically runs when an activity starts. It is only run if the activity state was OFF, otherwise only the activity UI is opened.
  • power-off sequence: runs when an activity is switched off and the state was ON. Afterward, the activity state will be OFF.

An activity group itself does not have any sequences, it's a mere collection of existing activities and linking them together and applying logic based on the current state.


How do activity groups work?

An activity group uses the state information of the "included entities" in its activities.
If there's no active activity in the group, then the on-sequence of the first started activity runs unmodified.

When switching activities, the activity group logic dynamically changes the activity sequences:

  • On-sequence of the new activity: automatically skip power-on commands, and eventually the following delay step, of already powered-on entities.
  • See configuration section below for more information.
  • Off-sequence: information about entities to power-off can be taken from the off-sequence. This can be configured in the activity group.
    Planned feature: run the off-sequence of the old activity, with power-off commands automatically being skipped of all entities used in the new activity.

It's important to note that included entities in the new activity are only powered-on, if they have an explicit power-on command in the activity's on-sequence!

Included entities in the new activity, which are not powered-on in the on-sequence, are ignored.

This provides more flexibility in creating activity UI screens.
For example, in a "watch movie" activity one can include additional entities like lights, which should not be powered on when starting the activity.

They are available to be controlled in the activity UI screen while the activity is running, without changing screens.

Need to quickly switch on a light while watching a movie? No problem, tap on the light icon on the screen :)



  • One activity can only be part of one activity group.
  • Only one activity can be in state ON in an activity group.
  • Keeping track of IR devices' states is best-effort, due to the nature of the protocol. See planned features below for "assumed state".
  • IR remote-entities require the power buttons to be named POWER_ON & POWER_OFF (or POWER_TOGGLE for "dumb" devices).
  • Otherwise, the power state cannot be controlled when switching activities.



An activity group can be configured in the web-configurator.


Remove turn on delays

This option controls the automatic removal of delays in the turn-on sequence of the new activity.

The on-sequence of the new activity is automatically modified, based on the power state of the included entities.

If a power-on command is skipped, because the entity is already in an active state, any immediate delay statements can be adjusted as well:

  • Previous command skipped (default): remove delay step if the previous command is a skipped power-on command.
  • Between skipped commands: similar as the above, but only skip the delay step if it is between skipped power-on commands.
  • Never: no entities are switched off. Everything is kept running, only the power-on sequence of the new activity is run.


Turn off unused entities

This option controls the power state handling of the included entities in the old activity.

  • Always (default): all entities of the old activity, which are not included in the new activity, are switched off.
  • In off sequence: like always but restrict the entities to switch off to only the ones which have a power-off command in the off-sequence of the old activity.
  • Never: no entities are switched off. Everything is kept running, only the power-on sequence of the new activity is run.



Let's look at an example with the following device setup:

  • TV
  • Audio video receiver (AVR): connected to TV on HDMI 1
  • Cable box: connected to AVR on HDMI 1
  • Media player (for example an Apple TV or Android TV box): connected to AVR on HDMI 2

To simplify this example, we are only using a cable box and a media player hooked up to the AVR.
Additional devices like Blu-ray player, game console(s), etc. follow the same principles as shown for the cable box and media player.

Note: further devices like lamps, blinds etc. can be included as well.

Either just as included entities in an activity, to control them directly in the same activity UI screen, or with additional logic in the activity's on- and off-sequence.



We create the following activities:

  • Watch TV (with the cable box)
  • Watch movies (with the media player)
  • Listen to radio (with the AVR)


Watch TV

Uses the TV, cable box and AVR.


  1. Turn on TV
  2. Turn on cable box
  3. Turn on AVR
  4. Delay 10 seconds
  5. Switch TV to HDMI 1
  6. Switch AVR to HDMI 1


  1. Turn off AVR
  2. Turn off cable box
  3. Turn off TV


Watch movies

Uses the TV, media player and AVR.


  1. Turn on TV
  2. Turn on media player
  3. Turn on AVR
  4. Delay 10 seconds
  5. Switch TV to HDMI 1
  6. Switch AVR to HDMI 2


  1. Turn off AVR
  2. Turn off media-player
  3. Turn off TV


Listen to radio

This activity only uses the built-in DAB tuner of the AVR to listen to radio stations.


  1. Turn on AVR
  2. Delay 10 seconds
  3. Switch AVR to DAB input


  1. Turn off AVR


Activity Group

After defining the individual activities, place them on a profile page to make them accessible in the UI. Each activity should now be individually tested, turning it on and off, to make sure it works as intended.

Now it's time to create an activity group, let's name it "Home Theatre".

Add the above activities, and we are almost done having smooth transitions between them.
The unused cable box an TV are no longer kept running if one simply wants to listen to radio after watching some TV!

The transition between activity groups now modifies the on-sequence on the fly to keep entities running and switching off unused entities.

Now we get the following behaviour, with the default activity group configuration:


Starting first activity: Watch TV

Since no activity is running in the "Home Theatre" group, the first activity runs as defined:
TV, cable box and AVR are switched on, and the input set to the cable box.


Switch from Watch TV -> Watch movies

The activity group detects that the TV and AVR devices are already running, the cable box is no longer used, and that the new activity requires the media player.

Modified "Watch-movies" on-sequence:

  1. Switch off cable box -> inserted command, device no longer used
  2. Turn on TV -> skipped, already in ON state
  3. Turn on media player
  4. Turn on AVR -> skipped, already in ON state
  5. Delay 10 seconds -> skipped because of Previous command skipped delay setting.
  6. Switch TV to HDMI 1
  7. Switch AVR to HDMI 2


Switch from Watch movies -> Listen to radio

The activity group detects that the AVR device is already running, the TV and media player devices are no longer used.

Modified "Listen to radio" on-sequence:

  1. Switch off media player -> inserted command, device no longer used
  2. Switch off TV -> inserted command, device no longer used
  3. Turn on AVR -> skipped, already in ON state
  4. Delay 10 seconds -> skipped because of Previous command skipped delay setting.
  5. Switch AVR to DAB input



Activity power-on and power-off sequences

Keep power-on and power-off sequences as simple as possible. Only the required devices should be included.

Optional logic, which is not always required, might be better put on the activity UI screen to run manually.


Network controllable devices

Most of the time, network-control is preferable over good old infrared, especially for two-way communication (yes, I am really powered on) and event notifications (someone manually changed a channel or volume).

For the best experience we recommend enabling the "network power-on features" on the device when using our network-based device integrations.
Please check the manual of your device how the manufacturer calls this feature, and if it's enabled or not by default.
The downside is an increased standby power consumption.

Currently, this applies to the following integrations:

  • Denon AVR network integration. Denon calls it "Network Control", with option "Always On".

Also, the Apple TV and Android TV integrations work best if the devices are not completely cut-off from power with an additional power-switch.
Furthermore, some Android TV devices like the Nvidia Shield TV can't even be remotely powered-on anymore once they were powered-off in the system menu.
However, they will automatically start after a hard power cycle.

For activity sequences it can have advantages using IR to power on a network-controllable device and then switch over to network communication once it has started up.

Certain devices offer configuration options for power on, like "fast start-up" or "allow power on over network / app".

Usually, this implies an always-on component listening on network requests with much higher power consumption while the device is "powered off / in standby".

Disabling this feature makes it impossible to power-on the device over TCP communication.

Furthermore, it may take over a minute until the device is finally reachable over the network.
(See planned features below on how we plan to deal with such situations).
In this case, sending an IR power-on command to the device shortly after switching on the external power, can drastically reduce the time until a device can already be used.



Switch off if it gives you trouble.

The HDMI CEC features can either be very convenient and helpful for controlling multiple devices like a TV and several media players with the original TV remote.

However, it only takes one misbehaving device to create utter chaos.

A few examples we've dealt with are power states getting out of sync - AVR turned on and TV turned off - or client devices fighting over who gets to select the AVR input.

(We've witnessed that Apple TV and Nvidia Shield TV are not best buddies).

If you encounter such issues, it's best to disable HDMI CEC functions and handle the usual power state, volume, and input control with an activity.

It's best to start with a single device, and then work through every scenario (all activities in your activity group).

With an AVR in a home theatre setup, start with this device to have manual control of the input selection.



Power-off sequence when switching activities

The power-off sequence of the currently running activity is not run when switching to a different activity in the same activity group.

For simple setups as shown above, this is not an issue. The unused devices are automatically detected and switched off. However, if more logic is put into an off-sequence, like controlling blinds or setting a screen mask, then this is currently not executed when switching activities.


Nested activities

A nested activity is an activity which includes one or multiple other activities.

  • The device power-state handling is restricted to the main activity only.
  • Nested activities in sequences are only considered as "On / Off" devices.
  • If a nested activity changes the power state of devices used in the main activity sequences, the result will be unpredictable.

Power toggle only devices

Devices without dedicated power-on and power-off commands are the hardest to control. Activities do not offer "assumed state" yet.

It is a planned feature, but for now these devices must be controlled manually.


Note: it's worth searching the Internet for dedicated POWER_ON and POWER_OFF IR commands.
Even if the original remote doesn't contain an on- or off-button, many devices still support dedicated IR commands.



No support for on- and off-states.
This will require customization settings to define what on and what off means. For example, if on relates to a closed blind or to the open state.


Future development and planned features

This is just the initial release of activity groups. We have the following features planned:

  • "Fix state" feature for the user to correct power states. The UI is already prepared (tap on the title of a running activity), but the state correction is not yet implemented.
  • Assumed state for "dumb devices" only having a power-toggle command. This will require the "fix state" feature.
  • Simple mode. The current implementation is more of an expert mode with many knobs to turn for custom behaviour. The simple mode is targeted to common setups with default behaviour. We might even make the activity groups an "expert feature" and hide it by default and all activities will be part of a default group.
  • Activity creation helper, based on included entities: automatically create default on- and off-sequences and a default activity UI.
  • The user can specify which devices are used to control volume, switch channels and media control.
  • Additional helper commands for the power-on sequence. For example, a "wait until entity reaches state X with a timeout Y". This feature can be useful for standby-power hungry devices (like certain AVRs) behind a controllable power switch, which are IP controllable once booted up.
Was this article helpful?
0 out of 0 found this helpful