Run Program when Scene is Triggered

[Pacificwing]

Hi,

 

I feel like I'm missing something obvious here.

 

How do I get a program to run any time a scene is triggered?

-PW

 

 

[LeeG]

There is no method for triggering on Scene execution.  Pick a device that is part on the Scene and use device state to trigger a Program.  

 

How is the Scene being invoked?

[Pacificwing]

There is no method for triggering on Scene execution.  Pick a device that is part on the Scene and use device state to trigger a Program.  

 

How is the Scene being invoked?

 

The scene is being invoked by keypad, REST or occasionally by program. Basically, any way a scene would be invoked.

 

I can figure out how to trigger a scene when a program runs. I suppose I could have the REST command call the program instead (this is not ideal), which would then run the scene. But it gets a little tricky when I try to run a program when a (for example) light switch changes state. There seems to be no way to do this.

 

Seems like (yet another) very basic functionality that should be there but isn't.

[LeeG]

It looks like something is missing but it is not that simple, unfortunately.

 

Scene xxx

Device 1 - On 100%

Device 2 - On 50%

Device 3 - Off

 

If Status xxx is On

Then

do something because xxx is On

Else

do something else because all devices in xxx do not match definition.

 

Seems straight forward.

 

Now Device 3 is turned On to 50% - is Scene On or Off? - some say On, some say all devices must be Off if Scene Off

 

Now Device 3 is turned Off - is Scene On or Off?

 

This is a simple case that raises questions as to whether 'If' is True or False when devices do not match definition but devices are not Off as would be expected for a Set xxx Off.

 

This discussion has been going on for years with no consensus of what Scene Status should mean. 

[larryllix]

I like to have all my Rest command inputs control variables only. Then I can do logic easier and control things from there.

 

It is more apparent, when reading programs, not to have them operated by an invisible trigger. The same thing would apply to a scene. Hidden is always bad programming form.

 

Months or years later how will you know what operates the method and where is the documentation to tell you?

 

Since scenes can contain no logic it's very easy to clone the trigger device input in programs as many times as needed,

[Pacificwing]

It looks like something is missing but it is not that simple, unfortunately.

 

Scene xxx

Device 1 - On 100%

Device 2 - On 50%

Device 3 - Off

 

If Status xxx is On

Then

do something because xxx is On

Else

do something else because all devices in xxx do not match definition.

 

Seems straight forward.

 

Now Device 3 is turned On to 50% - is Scene On or Off? - some say On, some say all devices must be Off if Scene Off

 

Now Device 3 is turned Off - is Scene On or Off?

 

This is a simple case that raises questions as to whether 'If' is True or False when devices do not match definition but devices are not Off as would be expected for a Set xxx Off.

 

This discussion has been going on for years with no consensus of what Scene Status should mean. 

 

Fair enough. It is true that all of the devices within a scene could have different statuses, so naturally the question would be, what is the overall status of the scene?

 

But that wasn't my question. My question was regarding when a scene is "triggered". My question was not in regards to the status of a scene or the devices therein.  The latter seems possible; the former apparently isn't.

 

Allow me to define what I mean by "triggered". Using your example above:

 

Scene "0x001"

Device 1 - On 100%

Device 2 - On 50%

Device 3 - Off

 

From what I've read (and my understanding could be wrong), when a scene is triggered in the insteon protocol, the device that triggers it (keypad, REST, switch, etc) sends out a broadcast that basically says "Engage Scene 0x001". This command is broadcast to all devices. When Device 1 sees this command, it knows to set itself to 100%. Device 1 doesn't really care what the other devices are doing. Device 2 sees the command and sets itself to 50%. Again, it is basically a stand-alone device specific response to a broadcast command. This is why the scenes continue to work even if the controller dies. The scenes are programmed into the devices themselves.

 

It seems fairly basic to allow the controller to respond to the "Engage Scene 0x001" command as well. This is not a "status" so much as a one-time event.

 

Yes, it is possible that the individual devices may change their states after the scene trigger command is broadcasted, but that wasn't what I was asking about. I was asking about responding to the main scene broadcast trigger.

 

 

 

I like to have all my Rest command inputs control variables only. Then I can do logic easier and control things from there.

 

It is more apparent, when reading programs, not to have them operated by an invisible trigger. The same thing would apply to a scene. Hidden is always bad programming form.

 

Months or years later how will you know what operates the method and where is the documentation to tell you?

 

Since scenes can contain no logic it's very easy to clone the trigger device input in programs as many times as needed,

 

 

That works for REST commands, yes, but there is no way to apply that whenever a scene is triggered. And if there was, it wouldn't necessarily have to be hidden.

[larryllix]

....

 

That works for REST commands, yes, but there is no way to apply that whenever a scene is triggered. And if there was, it wouldn't necessarily have to be hidden.

Maybe I have missed something here but you don't need to know when a scene has operated, only when the devices that could operate a scene have commanded it to operate.

 

This may mean duplicating some logic done in programs, from controlling source devices, but the logic is already done or can be cloned for a more modular programming style.

[oberkc]

 

But that wasn't my question. My question was regarding when a scene is "triggered". My question was not in regards to the status of a scene or the devices therein.  The latter seems possible; the former apparently isnt

 

Perhaps the issue is that, at the core of insteon, a "scene" is nothing more than the relationship between a single controller and single responder. The "scene" that one sees in the ISY is, as I see it, a convenience...an effective method for visualizing and managing many individual insteon scenes. An ISY scene is typically made up of multiple insteon scenes.

 

The only way I know to track whether a scene is triggered as you request is to write a program to track it, wathing for all the potential triggers.

 

If

scene controller1 is on

or scene controller2 is on

or programx runs

or REST does something

[LeeG]

"It seems fairly basic to allow the controller to respond to the "Engage Scene 0x001" command as well. This is not a "status" so much as a one-time event."

 

Triggering a Program has two aspects.  First is the process of making the Program to run (trigger).  The second is the command associated with the trigger.  All Insteon conditions which trigger a Program have a True/False evaluation based on trigger command versus command being checked.

 

It sounds like you want some aspects of Trigger conditions to apply and some aspects should be ignored (change of Status). That would be more new function added to the ISY.   Trigger when Scene initially used but not trigger if Scene is changed.

 

What should happen when a Scene On occurs and later a Scene Off occurs..   Does the Scene On trigger and the Scene Off is ignored.   If the Scene Off triggers what should happen if the individual devices are turned Off.  Both situations result in the devices being Off.  If an application wants to know the devices are Off would not both situations result in a trigger.

[mcqwerty]

"It seems fairly basic to allow the controller to respond to the "Engage Scene 0x001" command as well. This is not a "status" so much as a one-time event."

 

Triggering a Program has two aspects.  First is the process of making the Program to run (trigger).  The second is the command associated with the trigger.  All Insteon conditions which trigger a Program have a True/False evaluation based on trigger command versus command being checked.

 

It sounds like you want some aspects of Trigger conditions to apply and some aspects should be ignored (change of Status). That would be more new function added to the ISY.   Trigger when Scene initially used but not trigger if Scene is changed.

 

What should happen when a Scene On occurs and later a Scene Off occurs..   Does the Scene On trigger and the Scene Off is ignored.   If the Scene Off triggers what should happen if the individual devices are turned Off.  Both situations result in the devices being Off.  If an application wants to know the devices are Off would not both situations result in a trigger.

 

Sorry for being late to this party but I have more to add on the subject:

 

I am of the opinion that a Scene is not an device but a trigger such that is has no 'status' but can be 'switched' in ISY terms.

 

Regardless of the particular levels each responder in a scene is programmed to respond at, if any controller of a given scene issues an ON, OFF, DIM or BRIGHTEN broadcast as a result of a physical press of the device then this should be able to be used as a trigger of an ISY program defined as:

 

If Control 'myScene' is switched On/Off/Dim/Brighten

 

If Status 'myScene' is [anything] would be invalid since a scene has no Status.

 

Since the PLM is a controller and responder of all scenes setup by the ISY, the PLM and hence the ISY would see all 'all link broadcast' messages from all scene controllers and would also receive the cleanup messages sent to each responder from the controller so it should just be a case of how the ISY chooses to interpret this.

 

Regarding a scene 'set' AKA triggered via REST or via an ISY program, then I think it may be breaking some 'rules' to have that count as a 'Control 'myScene...' event since it was not initiated by a physical action, however I could argue that an exception should be made for this particular case.

 

Also, for clarity, I would still expect the ISY to raise a Control and Status event for the individual device that was pressed, but if that device is also a controller of a scene then I think a 'control' event for the scene 'item' should also be raised as detailed above.

 

 

Anyway, I realise any of this would be new functionality for the ISY firmawre, but if the first step is to reach a proposal that work in all cases and is as intuitive as possible I would like to open this idea up to comment.

 

Thanks!

[larryllix]

Sorry for being late to this party but I have more to add on the subject:

 

I am of the opinion that a Scene is not an device but a trigger such that is has no 'status' but can be 'switched' in ISY terms.

 

Regardless of the particular levels each responder in a scene is programmed to respond at, if any controller of a given scene issues an ON, OFF, DIM or BRIGHTEN broadcast as a result of a physical press of the device then this should be able to be used as a trigger of an ISY program defined as:

 

If Control 'myScene' is switched On/Off/Dim/Brighten

 

If Status 'myScene' is [anything] would be invalid since a scene has no Status.

 

Since the PLM is a controller and responder of all scenes setup by the ISY, the PLM and hence the ISY would see all 'all link broadcast' messages from all scene controllers and would also receive the cleanup messages sent to each responder from the controller so it should just be a case of how the ISY chooses to interpret this.

 

Regarding a scene 'set' AKA triggered via REST or via an ISY program, then I think it may be breaking some 'rules' to have that count as a 'Control 'myScene...' event since it was not initiated by a physical action, however I could argue that an exception should be made for this particular case.

 

Also, for clarity, I would still expect the ISY to raise a Control and Status event for the individual device that was pressed, but if that device is also a controller of a scene then I think a 'control' event for the scene 'item' should also be raised as detailed above.

 

 

Anyway, I realise any of this would be new functionality for the ISY firmawre, but if the first step is to reach a proposal that work in all cases and is as intuitive as possible I would like to open this idea up to comment.

 

Thanks!

Sounds reasonable and good to me but you should post this in the Product Requests thread.

[mcqwerty]

Sounds reasonable and good to me but you should post this in the Product Requests thread.

Done: http://forum.universal-devices.com/topic/21925-enable-triggering-of-programs-via-scene-a-proposed-solution/?p=213566