Program devices vs scenes best practice

[chachdog]

I have read that it is preferred to use scenes instead of controlling devices directly. 

 

Does the same apply to programs? 

 

If I wanted to set up a demo scene that does a light dance should they all be scenes even if i have to make one a new scene with every device in it or can i just call the devices in the insteon program options. 

 

Thanks

 

[stusviews]

Scene transmit signals to all members of the scene concurrently and are inherently faster than programs. Programs are the best only choice if conditions must be met.

 

BTW, I have a scene that turns off nearly all of my more than 100 devices. In particular, the scene turns off nearly all interior lights except those in the bedroom (and a few others).

[apostolakisl]

I have read that it is preferred to use scenes instead of controlling devices directly. 

 

Does the same apply to programs? 

 

If I wanted to set up a demo scene that does a light dance should they all be scenes even if i have to make one a new scene with every device in it or can i just call the devices in the insteon program options. 

 

Thanks

 

Scenes are only better at controlling 2 or more devices simultaneously.  Creating a scene and putting one device in it will not work better than just controlling the device directly and in some ways will be worse (devices don't report back after scene commands).  As mentioned, a scene works better with multiple devices because it is one command that all devices in the scene recognize.  In other words, one Insteon command over the power line instead of 2 or more.

 

So if your light show is flipping one light at a time, you should just control the device's directly.  If 2 or more lights are meant to activate simultaneously, put those together in a scene.

[stusviews]

Devices do report back after scene commands. Otherwise Status wouldn't work in programs. And in some cases, a scene is the only way to control the status of, for example, a keypad button.

[apostolakisl]

Devices do report back after scene commands. Otherwise Status wouldn't work in programs. And in some cases, a scene is the only way to control the status of, for example, a keypad button.

 

Lee can chirp in here if he wants, but it is my understanding that the status change in the ISY register is created by ISY when a scene is executed, not by an ACK from the device.  There is logic to this since a scene could have dozens or more objects and ACK's from all of them at the same time could overwhelm the com.

[LeeG]

apostolakist is correct, a Set Scene 'xxxxx' On (and turning Scene On with Admin Console) does not receive ACKs from the Responders.  The ISY issues a single Group Broadcast message for the Scene number which has all Responders reacting at the same time.  The change in Responder device Status is what the ISY expects to happen from the Scene execution.

 

Same result from a device turning a Scene On (button/paddle press On).   Although the Controller device does receive ACKs from the Responders the only thing the PLM/ISY knows is the Scene was turned On.  The ISY sets the Scene Responder Status to what the Scene should do rather than knowing what actually happened.   

[chachdog]

Is it possible to add scenes to scenes? 

[stusviews]

Same result from a device turning a Scene On (button/paddle press On).   Although the Controller device does receive ACKs from the Responders the only thing the PLM/ISY knows is the Scene was turned On.  The ISY sets the Scene Responder Status to what the Scene should do rather than knowing what actually happened.   

 

So, even if the device did not respond correctly, the ISY "thinks" it did?

[stusviews]

Is it possible to add scenes to scenes? 

 

No, it it not possible to add a scene to a scene. It's not even possible to past the members of a scene into another scene.

[chachdog]

Possible to rearrange item order in the structure? 

[apostolakisl]

So, even if the device did not respond correctly, the ISY "thinks" it did?

yes.  You might instead phrase this as "ISY assumes it did"

[apostolakisl]

Possible to rearrange item order in the structure? 

 

The order is alphabetical and you can't change that.  The order makes no difference, of course.  The devices don't get activated sequentially.  A scene is a single Insteon transmission from the controller (either the PLM (as controlled by ISY), or a device) which each device in the scene is programmed to recognize as a queue to do as programmed for that scene.

 

So if you want them ordered differently for the sake of viewing them in the tree, you would need to change the names so that alphabetically they get into the order you like.

 

Also, a scene in scene would unnecessarily add layers upon layers of confusion.  If you want all the devices from one scene in a second scene, then you just put all those devices into your second scene.  A scene command is a single message, so you can't have scenes nested inside of scenes.  That is the whole point of a scene, to boil down a slew of device activities to a single broadcasted message.  Only this way can the com keep up.

[chachdog]

The order is alphabetical and you can't change that.  The order makes no difference, of course

 

 

I was referring to the order how the devices are listed within a scene. The were appearing in the order they were added. I restarted the console and they sorted themselves out. Much better! 

[stusviews]

You can also click the [a z] symbol (top, left) to sort w/o closing and restarting.

[sfroach]

apostolakist is correct, a Set Scene 'xxxxx' On (and turning Scene On with Admin Console) does not receive ACKs from the Responders.  The ISY issues a single Group Broadcast message for the Scene number which has all Responders reacting at the same time.  The change in Responder device Status is what the ISY expects to happen from the Scene execution.

 

Same result from a device turning a Scene On (button/paddle press On).   Although the Controller device does receive ACKs from the Responders the only thing the PLM/ISY knows is the Scene was turned On.  The ISY sets the Scene Responder Status to what the Scene should do rather than knowing what actually happened.   

 

 

So, even if the device did not respond correctly, the ISY "thinks" it did?

 

 

yes.  You might instead phrase this as "ISY assumes it did"

I understand using scenes permits Broadcast mesages which in turn reduce Insteion PL traffic. But since the ISY updates its status table based on the broadcast commands it issued & assumes to be implementd.

* Would the ISY have better data if you called out devices in programs, when possible, rather than scenes?

* When devices report back there status, how is that used by the ISY?

* How many device status tables are there in an ISY & PLM network?

[LeeG]

* Would the ISY have better data if you called out devices in programs, when possible, rather than scenes?

 

Yes.  But Scenes should/do work unless you have Insteon network issues.  Doing individual devices brings the devices to the new state one at a time.  Much better to use Scenes and fix the Insteon network.

 

 

* When devices report back there status, how is that used by the ISY?

 

The new Status is associated with the device reporting. 

 

 

* How many device status tables are there in an ISY & PLM network?

 

PLM has no Status information stored for device.  All Status information storage handled by ISY (in one place as far as I know).