Proper Use of Programs and Scenes

[Grizzy]

I confused on the use of Programs vs Scenes

 

LeeG, In another thread you told me:

Scenes are a normal way of doing things in Insteon.   It would be unusual to do all things with individual devices and Programs.   Too slow and too much Insteon traffic to do things one device at a time..

 

 

So My question is:

 

If I had a program, say turn on outside lighting at sunset (simplified example)

 

    IF:

           sunset

 

    Then:

            Back Porch light on

            Front Porch Light on

            Driveway Light On

            Garage Light On

            Pole Light On

 

Else:

            All  The above off

 

Why does a scene execute this any faster ?

 

Don

[LeeG]

Using Direct commands each device turns On, one after the other.  Five Insteon commands are issued and 5 ACKs are received.

 

Using a Scene a single command issued and all the devices turn On at the same time.

[Teken]

Don,

 

I will only address this from a stand alone perspective. If the devices are all linked via scenes they will always operate regardless if a controller is present or not.

 

Outside of conditional programs executing timers, schedules, etc.

 

Scenes should always be used first. Programs are great way to compliment a scene to add more logic such as timers, schedules, or to call upon another 3rd party device or service etc.

 

 

Sent from my iPhone using Tapatalk

[Grizzy]

How can a single command turn on 5 different devices ?

[Teken]

How can a single command turn on 5 different devices ?

Because they are all linked.

 

 

Sent from my iPhone using Tapatalk

[Grizzy]

Being linked, does that mean each device somehow shares a common address ?

[Teken]

Being linked, does that mean each device somehow shares a common address ?

Has nothing to do with a common address. They are simply linked to one another. When a device issues a command any linked devices simply activate. With a ISY program the system manages the activation which sometimes can be delayed.

 

The amount of delay can be none to a few seconds in duration. I use programs to compliment scenes and provide more logic.

 

 

Sent from my iPhone using Tapatalk

[LeeG]

The PLM has 5 Controller link records with that Scene number, each pointing to one of the 5 devices.

 

Each of the 5 Responders has a Responder link record with the PLM address and Scene number.

The PLM issues a single Scene On that all  devices receive.   Those devices that have a matching Responder link record react to that single Scene On.

 

Suggest going to insteon.com and read the insteondetails.pdf doc 

[stusviews]

No. Insteon devices can be controllers or responders. Most devices can be both a controllers and a responder. When you create a scene, you are actually creating a link between the devices. A controller can have any number of responders, but can be a controller of only one scene. A scene can have a number of controllers with any one of them being able to control all responders to that scene.

[Grizzy]

Has nothing to do with a common address. They are simply linked to one another. When a device issues a command any linked devices simply activate. With a ISY program the system manages the activation which sometimes can be delayed.

 

The amount of delay can be none to a few seconds in duration. I use programs to compliment scenes and provide more logic.

 

 

Sent from my iPhone using Tapatalk

I guess I'm still x10 orientated and sometimes it takes a long nail to penetrate.

 

If linked via a scene ... the devices become controllers and turn on each other ?

 

Thanks for your patience

[stusviews]

Both devices would have to be defined as controllers for them to control each other. That's usually called "cross-linking." Otherwise, one device is the controller and the other is the responder.

[Grizzy]

No. Insteon devices can be controllers or responders. Most devices can be both a controllers and a responder. When you create a scene, you are actually creating a link between the devices. A controller can have any number of responders, but can be a controller of only one scene. A scene can have a number of controllers with any one of them being able to control all responders to that scene.

 

ok it's starting to come together, it's like a network of multi-tasking computers

 

 A scene can have a number of controllers with any one of them being able to control all responders to that scene:

   DOES THIS CAUSE ANY MULTIPLE COMMANDS AND COLLISIONS?

[Grizzy]

Both devices would have to be defined as controllers for them to control each other. That's usually called "cross-linking." Otherwise, one device is the controller and the other is the responder.

in my sunset example:

 

Should I place all the light in a scene and a program to determine sunset and then activate the scene ?

 

In my scene which will be a controller and which responders ?

[stusviews]

No problem. That's part of the Insteon protocol. If a controller has, say 10 responders, then the signal is sent out to all Insteon devices on your network, but only those 10 devices respond due to the link the scene created between the controller and the responders.

 

Each Insteon device has a unique address.That's one of the advantages of Insteon over X10. You can have controller A turn on responder C to, say, 80%, and controller B  turn on the same responder to 100%.

[stusviews]

in my sunset example:

 

Should I place all the light in a scene and a program to determine sunset and then activate the scene ?

 

In my scene which will be a controller and which responders ?

 

In that case, the program is the controller and all devices in the scene are responders. But, as I indicated, the scene can have more that one controller. You can define any and all devices in the scene to be controllers as well as responders--or not.

 

A scene controller is any device that turns the scene on.

Edited January 20, 2015 by stusviews

[Grizzy]

In that case, the program is the controller and all devices in the scene are responders. But, as I indicated, the scene can have more that one controller. You can define any and all devices in the scene to be controllers as well as responders--or not.

 

A scene controller is any device that turns the scene on.

 

ok, I do have a very different idea now and realize I made assumptions without any understanding of the Insteon protocol.

 

I looked through the wiki tutorials and when it covered device linking I skimmed it thinking I was not doing any device to device linking since I had the ISY to do all my control. Very Bad Assumption !

 

You  guys have been a tremendous help , I appreciate your patience and persistence to get me re-orientated from the x10 thought process.

 

I will re-read the tutorial in the Insteon protocol and device linking.

 

Thank You Very Much

Don

[stusviews]

This'll keep you busy: https://www.insteon.com/technology/

[Teken]

I guess I'm still x10 orientated and sometimes it takes a long nail to penetrate.

 

If linked via a scene ... the devices become controllers and turn on each other ?

 

Thanks for your patience

 

Hello Don,

 

Speaking for myself only from a personal point of view.

 

I always create my system(s) so that it can operate as a stand alone Insteon network. A controller is simply used to accomplish more complicated events / scenes. Or where another device is interacting with the Insteon network like say main water shut off valve, power management, temperature, etc.

 

I have seen lots of million dollar homes literally remove every physical switch from a wall and rely on a HA controller. This offers a clean look in the home, but is truly stupid in ever possible way you could think of.

 

As you're probably aware the PLM is the most important part of the Insteon integration to a controller. You have no doubt read countless threads where it has failed or where the HA controller was off line and not operating correctly.

 

Imagine you couldn't turn on a simple fan, light, door because it relied on a controller??

 

I have supported many Military, Financial, Federal, EMS, Fire, Hospital environments. There isn't one of these agency's or business's that would allow a controller to operate and have full control of their systems, none.

 

My key point is that if you grow your system and linked them natively in the worst case scenario even with out a PLM / Controller your home would still operate.

 

NOTE: Outside of scenes nothing beats the ISY Controller in integrating fire, weather, energy, network, HVAC related data to the Insteon network.

[stusviews]

Teken may be using "controller" differently than I am. I'm referring to "controller" in the context of a scene. Neither the ISY nor the PLM are involved in the scene other than to create the links between the devices. Once the scene is created, you can remove both the PLM and the ISY and the scene will function.

 

In effect, you tell the ISY which devices to include in the scene (drag 'n drop) and whether that device should be a controller or responder (all controllers are also responders to the scene). The PLM interfaces between the ISY and the powerline allowing the links to be written to the devices. At that point, the scene is "self-contained," that is, independent of the ISY.

 

OTOH, programs require use of both the ISY and PLM.

[Grizzy]

Hello Don,

 

Speaking for myself only from a personal point of view.

 

I always create my system(s) so that it can operate as a stand alone Insteon network. A controller is simply used to accomplish more complicated events / scenes. Or where another device is interacting with the Insteon network like say main water shut off valve, power management, temperature, etc.

 

I have seen lots of million dollar homes literally remove every physical switch from a wall and rely on a HA controller. This offers a clean look in the home, but is truly stupid in ever possible way you could think of.

 

As you're probably aware the PLM is the most important part of the Insteon integration to a controller. You have no doubt read countless threads where it has failed or where the HA controller was off line and not operating correctly.

 

Imagine you couldn't turn on a simple fan, light, door because it relied on a controller??

 

I have supported many Military, Financial, Federal, EMS, Fire, Hospital environments. There isn't one of these agency's or business's that would allow a controller to operate and have full control of their systems, none.

 

My key point is that if you grow your system and linked them natively in the worst case scenario even with out a PLM / Controller your home would still operate.

 

NOTE: Outside of scenes nothing beats the ISY Controller in integrating fire, weather, energy, network, HVAC related data to the Insteon network.

 

You have a very valid point. I fully understand and agree. And yes your absolutely correct, I bought a second PLM because of the numerous posts I read relating to the failing PLM

 

I understand why your design does not depend on the ISY or PLM. I worked in an large electric generating station for 37 years the later part doing digital process control. Reliability was our #1 priority. The system had multiple processing nodes each with a full redundant unit. Redundant network, switches, routers, power supply's, everything that may fail had a twin running the same program instruction matching instruction. This created a bump less fail safe.

 

I see your posts and appreciate all the information you share with others.

 

I have a completely different philosophy to pursue and learn

 

Thanks for you input and design thoughts.

 

I'm quite sure I'll be asking for more help, I hope you guys are around.

 

For the most part I thought the forum was a great learning experience and watch it everyday.

 

Again Thank You

 

 

Thank You

[larryllix]

 

 

.... I worked in an large electric generating station for 37 years the later part doing digital process control. Reliability was our #1 priority. The system had multiple processing nodes each with a full redundant unit. Redundant network, switches, routers, power supply's, everything that may fail had a twin running the same program instruction matching instruction. This created a bump less fail safe.

....

A little off-topic but...

Did you use DNP 3 for these comms? If not what protocols?

[Grizzy]

A little off-topic but...

Did you use DNP 3 for these comms? If not what protocols?

 

Our company almost exclusively used Westinghouse WDPF. Westinghouse sold the Distributive Process Control  to Emerson Water Power and Electric somewhere in the 1990's.  We did have one unit with a Foxboro System and One other I cannot recall the manufacture.

 

Some of the smaller subsystems were net90 and ??  I retired 8 years ago, amazing how fast one forgets

 

My  home automation controller was centered around TLHA and opto22 I/O , which had a design philosophy much like what I worked with.

 

I guess that's why I'm grasping at insteon.

 

Don

[Teken]

You have a very valid point. I fully understand and agree. And yes your absolutely correct, I bought a second PLM because of the numerous posts I read relating to the failing PLM

 

I understand why your design does not depend on the ISY or PLM. I worked in an large electric generating station for 37 years the later part doing digital process control. Reliability was our #1 priority. The system had multiple processing nodes each with a full redundant unit. Redundant network, switches, routers, power supply's, everything that may fail had a twin running the same program instruction matching instruction. This created a bump less fail safe.

 

I see your posts and appreciate all the information you share with others.

 

I have a completely different philosophy to pursue and learn

 

Thanks for you input and design thoughts.

 

I'm quite sure I'll be asking for more help, I hope you guys are around.

 

For the most part I thought the forum was a great learning experience and watch it everyday.

 

Again Thank You

 

 

Thank You

 

SOAP BOX COMMENTS:

 

I guess my views are quite different from many others who are mostly consumers. Based on your reply, I can see you fully understand why I hold this view.

 

In the big picture its really personal choice and having faith in your systems to operate and react to your will. After working in many commercial environments and seeing how others cope, or endure system issues. I have gleaned all of the *Don't Do* opposed to the *Must Do*.

 

I love my toys just like all the rest but my personal experience keeps me grounded in the fact. Reliance on too much high tech will leave you stranded when its needed the most.

 

I believe if people plan and deploy their systems on a base level to operate independently. This resolves about 90% of the possible issues that could arise. The biggest No, No, in my mind is mixing security with HA.

 

Lots of people do it and have great experience with it.

 

But, from a security and safety stand point this is counter to what the goal is.  

 

If people had your personal experience in a power generation plant they too would understand why things are done in pairs or in three's.

 

The military always chirped on and on about the power of three. Sometimes it was really a PITA for us in the field but you know what? After going through a few disasters with them and watching how their systems operated even with two things down.

 

It didn't take much for me to emulate that same view and philosophy in all that I do. 

 

Sorry for the off topic reply . . . 

[Grizzy]

No need to be sorry:

 

I can find there is something interesting and always something to gain by listening and welcoming any and all input.

 

A persons background many times defines their thought process, after all that's how we spent a big part of our life.

 

Thanks for your "soap box comments"

 

As I mentioned I read your posts and value information you share.

 

You once mentioned doing all the work for ????  WELL I can tell you there are many of us that appreciate the time and effort you spend to evaluate and provide us with factual information.

 

For every programmer there is a different way to accomplish the same thing. Guess What They are all right, all good, and each of can learn from the other if we just open our minds.

 

Thanks, I appreciate ALL the feedback I get.  Sometimes it may take 3 teachers to get a point across, but when you see that light bulb go on it was worth every bit of the effort expended !!

 

Keep up the work !!

 

Don