Trigger Groups in Scenes - SHAC

[ks04]

Hi - 

I noticed in v1.12.0 of the SHAC firmware i had an issue where I could not add trigger groups into a scene (When searching on the trigger group, nothing was returned).  

Has this issue been resolved in v1.13.0.  Given downgrading is not officially supported, I'm hesitant to upgrade not knowing if this has been resolved.

Thx

[DarrenMullighan]

Hi there,

I can confirm that on the 1.6 firmware that it was possible to use trigger groups inside of scenes. As of newer firmwares, this was fixed under the understanding that trigger groups are not supposed to be used in scenes (due to the possibility of creating looping scenes). This was something that was warned about in PICED, but still allowed you to do this.

What this tells me is that if you wish to include a trigger group in a scene, it would have to be managed out of logic with an event-based script. Detecting when the scene is set (via monitoring the status of the trigger group which actions the scene) and then setting the secondary trigger groups to their required level.

[DarrenMullighan]

Alright, so i can definitely confirm that the prevention of use of trigger groups in scenes on a NAC/SHAC/AC is a design intention. There are a few reasons at the C-Bus protocol level, but mostly it is to prevent user error.

In saying that though, I would love to understand the use cases you have for including trigger groups within scenes. Any details that can be provided would help me go back to the business and argue the functionality

[ks0410]

Thanks for confirming - 

My main use-case here for having scenes in scenes is for 'whole home' scenes. 

Example here is as follows:

• I have a scene for each room 'bedroom', 'kitchen' etc. which has a number of levels 'off','ambient','all on' etc for each. 
• I then have a series of whole home scenes 'evening', 'entertainment', 'all off' etc.

When I trigger All Off scene - the preference would be to have each of the room scenes trigger to off, rather than a large scene which has each lighting group in.  Otherwise, when I set the scene all off, the individual room scenes stay at their previous level (unless I build some additional logic as an event-based script).

[Coppo]

FYI.
PICED did allow you to have triggers in scenes, but there was a pop-up warning message to advise 'use of triggers in scenes couls result in unwanted scene cycling or looping".

As @DarrenMullighan  said it can be handled with a script instead    

[NickD]

---

@ks0410 wrote:

When I trigger All Off scene - the preference would be to have each of the room scenes trigger to off, rather than a large scene which has each lighting group in.  Otherwise, when I set the scene all off, the individual room scenes stay at their previous level 

---

I'm not sure if I understand correctly what you mean by "stay at their previous level", but if you're referring to the "level" of the scene (called the Action Selector), then this should change, as changing the level of any group in a scene that is set should cause that scene to become "broken" ie not active. Breaking the scene should turn all scene indicators off.

Nick

[ks0410]

Hey Nick,

You're correct that the scene indicator goes to off, which is great for the traditional light switches.  However, for EDLT and SHAC Visualisations the preferred approach would be that the Action Selector/Level for 'All Off' sets the Scene for each individual room to 0 / All Off to match the current scene.

Likewise for Ambient Scenes - Let's say I have a Whole House scene which turns the Kitchen and Living Room to ambient light levels.  The Kitchen and Living room scene selector would be seen as -1 / indicator killed, however the lights are in-fact on so the scene indicator is incorrect - the ideal would be that the scene for those rooms now displays the equivalent ambient scene.

[NickD]

Thanks for explaining the use case. I will keep this in mind as we work on the new products.

[Mr_C]

Just adding a Few comments to the ticket even if it can be  to those who are reading in future.

I think it is clear understood what is trying to be achieved and it makes a lot of sense to provide the solution in the way that is described, in the situation where you have a relatable scene in each room that in some way ties into an overall home scene or area scene,  and where scenes are being used in Key Input units to give a greater degree of control over a rooms ambience and behavior.  Then this is a good approach to use the Scene Triggers for each room to Trigger the common overall area behavior. 

However there are few things potential wrong with taking this approach by just adding the action selector of each trigger group to a Scene in the Automation Controllers. 
1. Is that depending on the size of each Scene in the Key Input unit and if there is more than 1 key input unit with the same trigger group and action selector, this kind of approach can get a little heavy on the Bus as it may create a race condition,   as you trigger many devices to want to respond at near to if not the same time,  C-Bus can cope with this quite well but it may cause some commands to need to be retried as they may not be successful on there first attempts.  (if they are not successful after 3 attempts then they will also not occur).  As C-Bus is generally know for its reliability and robustness you would like to think that you do not want your customer reporting that sometimes when the go out some rooms do not turn off and at other time they do. While this may not happen for the specific project mentioned it can happen depending on scale and size and timing.   C-Bus Scenes were designed to concatenate Scenes across 2 devices using the Action selector but this purpose was different,  in this case one device would send the lighting groups in the scene onto the bus as the action of someone pushing the button on the plate, at the end of the lighting groups the device would send the Trigger Group and Actions Selector for that Scene, and a second device with the same Trigger Group and Action selector could be triggered and in response send its Lighting groups onto the bus - in this way there is not usually a race condition as the devices following in sequence. Where as what is trying to be achieved here is the triggering of the scene using the trigger group and action selector, of multiple scenes at once so as to have the Indicators of all these scene set as active. 

The second challenge with this methos is based on a mistake being made, The Automation Controller is unfortunately not the same as our legacy controllers like  those based on PICED projects.  These devices used projects that were compiled by PICED and PICED and thee devices had a means to detect the creation or existence of a circular reference, In that is if the programmer created a scenario where 1 event would cause a loop back on itself or through a sequence lead back to triggering itself again this could be picked up and prevented or if it was observed in logic that the same events were happening all the repetitively they would be stopped.   Either way the Bus was protected from mistakes and circular references that may result in flooding of traffic  onto the bus,   The Automation Controllers have no way to implement that same protection, so we are forced to prevent them from being created easily,  One way to do this was to prevent putting triggers inside scenes and thus avoid scenes from trigger scenes and creating potential loops. 

Currently The best way to use the controller to do what you want is indeed to use a Trigger Group and Action Selector,  and a Event Script,  in the Event Script you would look for the action Selector Level being set,  and if it is set then define a sequence of steps to send the individual trigger groups and action selectors for each Scene if that action selector is not currently set,  I would suggest a small delay between each step. again to prevent the race on the bust (delay of 200ms would be sufficiently big enough).  By testing that the scene is not already set you will also avoid triggering things that are not required.

A final Benefit of this approach is as follows.
Using this approach you can select the order with a delay time between each step that may provide a elegance effect in that you may in the case of welcome home and goodbye create a effect of turning of / on rooms so that int he case of when leaving the home, the last lights to turn off may be the Porch light or entry, you can also have a different effect based on night or day my using a time check in the logic.  for example leaving the porch lights on for longer period if its night time.

The second benefit of using Scripts is that when we finally give your customer the ability to edit and modify scenes in a similar way to how we provided schedule editing there is no risk of the customer breaking the scene that joins other scenes.