For years I have fumbled my way through the use of triggers to fire scenes, usually resulting in trial and error until I got what I needed. I never really understood them properly, but somehow got there in the end. However I now need to send trigger commands via the SIM and I have realised I just don't understand them well enough. So here is my limited understanding; Trigger commands share the same format as lighting commands therefore the following is true; Trigger Groups are analogous to Lighting groups and Action Selectors are analogous to Lighting levels. This is all fine and I can understand how to construct a Trigger message aimed at a particular Trigger Group/Action selector. What I don?t understand is how to associate a scene with an Action Selector. There only seems to be the ability to associate all the scenes on a device (let?s say a NEO to keep it simple) with a Trigger Group and no Action Selector for the individual scenes. Now If I was programming a local button on that same NEO to trigger a local scene then I set an Action Selector in that buttons programming and it works. But how, given there is no relationship between the scene and the action selector? I would have assumed each scene would have a unique Action Selector associated to it when the scene is programmed, but that does not appear to be the case. To fire the scene remotely, I used a similar methodology and just mucked around till it worked. Do date I have just accepted all this as some kind of C-Bus black magic. So I guess my biggest question is; How do I fire a scene on a remote device that does not (or may not) have a local button programmed for that scene, using the standard trigger control protocol command like \05CA0002ggsscc ? I can send it easily enough but how do I know what action selector to use for a particular scene? Hopefully I have explained it clearly enough. Cheers Rohan
It depends on the type of unit that the scene is stored in. With normal (Wired) input units, you cannot fire a scene remotely (or locally) without assigning it to a key (edit: which may be a Virtual Key as Nick points out below). When you create a scene key in Toolkit, opening the Details dialog (by pressing the button to the right of the Function drop-down) will allow you to assign a Trigger Group (for the whole unit) and an Action Selector (for the scene key). If your scene is stored in an Architectural Dimmer or an Occupancy Controller, or a Wireless key unit, you can assign a TG and AS to the scene directly within Toolkit, without needing to create a scene key. (For the Arch Dimmer, this is done directly in the Scenes tab; for the Occupancy Controller and Wireless key units, go to the Scenes tab and click the Edit Scenes button). If your scene is stored in a touch screen, you can assign the TG and AS from the Scene Editor in PICED (open the Scene Manager from the Edit menu, select your Scene and click the Edit button, then go to the Scene Trigger tab).
So far so good. Key units are limited to a single trigger group, but each different scene gets assigned an action selector when it is associated with a key in Toolkit. This apparent disassociation between the Action Selector and the scene number is really just a quirk of how the scene is configured under the hood in the key unit. You can create scenes without a Trigger Group assigned to the unit, or an Action Selector assigned to the key... in this case these scenes can only be triggered from that key. This is now discouraged, and Toolkit tries to enforce creation of a Trigger Group and Action Selector when a scene key is configured. If you have a scene triggered by a key in a unit, then you can trigger that scene remotely by assigning a Trigger Group to the unit, and an Action Selector to the key. Finally, if you have unused blocks in the key unit, you can also create scenes that can only be triggered remotely by assigning a Trigger Group to the unit and an Action Selector to a Virtual Key. If you look at scenes in touchscreens or the PAC, it should seem a little more logical, and you will see that your assumption about each scene having a Trigger Group *and* Action Selector is correct. To fire a scene remotely, it must have a Trigger Group and Action Selector assigned, then all you have to do is issue the corresponding Trigger command. HTH, Nick
I'll add: Try and avoid the "Trigger Group is analogous to Lighting Group" and "Action Selector is analogous to Lighting Level". You *can* think of things like that but it is misleading and will get you into trouble eventually. You really need to read the document "What the heck are scenes anyway", because you need to understand about how a Trigger Group is used to GROUP RELATED SCENES together (ie you can have a number of action selectors in a Trigger Group, but only one of those scenes thus triggered is considered "active" at any one time. Thats how you make key units indicators behave sensibly.) You can draw a 2 dimensional matrix - trigger groups on the Y axis, and action selectors on the X axis. The idea is you can then look across a row and say "only one of the things in that row can be active", but each row is independent of the other rows. A FURTHER WARNING: There are shortcut scene trigger commands which CAN BE EMITTED by older key units. These look like lighting ON and OFF commands, and they are a shortcut for Trigger Group X, Action Selector 255 (ON) and Trigger Group X, Action Selector 0, respectively. When you make a device that can receive scene commands, you need to handle this shortcut also. And a final word: If you make a device that can EMIT scene commands, you MUST ALSO make that device receive scene commands. It might not do much with the received commands but it *does* need to handle the mutual exclusion rules (see that tutorial above, again), and it needs to handle th indicator kill command. In general, scene processing in a device is one of the more complex parts of the device. You *must* do a lot of testing both sending and receiving scene commands (and lighting commands) in order to check correct operation. If you emit scenes (ie stream of lighting commands + allow triggering), you must also receive lighting commands and check for broken scenes in order to emit scene indicator kills. If you do full scenes (not just triggering), this it is *not* something where you can be 1/2 pregnant. That means you can't choose to do the easy bits and ignore the rest. You have to do the whole box-n-dice, like it or not. (The only easy way out it to issue triggers... even then if you have indicators you need to handle mutual exclusion and indicator kills). In key units, the code to make scenes run (fully) is at least as large as the lighting command processing, and considerably more complex.
Thanks to all you guys for taking the time to write such comprehensive replies, it's this level of support that really shows your passion to the product. I'm still to read the document Ashleigh pointed to, and I'll probably have a few more questions after I do, but I wanted to say thanks up front. And the good news is I was pretty much on the right track, and had an hunch I needed to assign a button to create the link to the action selector. Cheers Rohan
Ok, I've read and digested that document, and I now feel much more informed. I would like to make another statement, and see if it is true; Trigger groups, although related to lighting in format, to not hold state like lighting groups do. By that I mean, if a trigger command is used to trigger a scene, then the scene can and will have a state (as described in your document) but the trigger group once sent no longer exists in any sort of state. What I'm leading to is, the indicator on the button (or whatever input method) should be thought of as indicating the state of what the trigger command actually triggers and not the trigger its self, which may be a scene or something else. Cheers Rohan
That is exactly 100% correct. The Trigger Group and Action Selector have no state; they are the mechanism used to set the scene. The scene can have states, but the mechanism that triggered it cannot. The Trigger Control Application is a state-less application. As further evidence, you may notice that there are no MMI's (which reveal state inconsistencies) on the Trigger Control Application.
