Pre-purchase information on capabilities sought

[jgreco]

I'm toying with the idea of ditching a troublesome PowerHome setup for something else. The ISY is a natural candidate.

 

In fairness, the problems with PH have less to do with PH than the underlying Microsoft and database stuff; PH itself is pretty competent.

 

My big hot button item is scene status on KeypadLincs. I want each KPL to accurately display the status of the real world scenes it controls. This is in turn driven by Insteon scene commands, of course, but is a bit tricky because Insteon isn't oriented towards "the bigger picture" - that's where an automation controller comes in.

 

Let's say you have two KPL's and a SwitchLinc. Three scenes, "all on", "all off", "nightlight" (the SL at 30% and KPL's off).

 

You hit all off. Insteon "all off" scene fires, Insteon "KPL LED all-on off" scene fires, Insteon "KPL LED all-off on" fires. Everything's fine. I see how to do all that with the ISY too.

 

You hit all on. Inverse happens. Also easy.

 

But now you press off on the SwitchLinc. I want the KPL all-on LED to extinguish. This requires something in the network to be aware that a member of the real world scene is now not compliant. Further, if you then press on on the SwitchLinc, the KPL all-on LED should come back on, since all three devices are once again on. If you then press load off on the KPL's and set the SwitchLinc at 30%, the "nightlight" scene button should light up.

 

Now in theory you can sit there with a large IF/AND/AND/THEN structure that has to be grown each time a device is added; that's ugly and unmanageable. Trying to do this for a dozen scenes would be awful. PowerHome actually updates its internal group status to reflect things in the manner I describe above, and then it's just a matter of triggering when that status changes and pushing changes out to the KPL LED scenes. I have the required Insteon scene magic working great under PowerHome for manipulating the KPL's and Insteon device scenes... but I cannot really tell what the ISY's capabilities are for acting as the needed intelligence.

 

Is the ISY up to such a task?

[oberkc]

The ISY-99 is based on if/then/else programs, with conditions consisting of device status, program status, time, temperature, etc... joined by "or" or "and" conditions. If you can describe your needs using boolean logic, the ISY-99 can do it. Also, insteon sytems with the ISY-99 can take advantage of insteon scenes, so combinations of scenes and programs are typical. Your example sounds like something where you would use a combination of scenes and programs.

 

However, you state that such a construct is "unmanagable" and "ugly". Given this, I cannot think of anything to offer that you would find otherwise.

[jgreco]

I have no objection to using a combination of scenes and programs. What I'm looking for is some higher-level capabilities in the device.

 

What I *don't* want is for every time I purchase a LampLinc or SwitchLinc to have to go and be modifying every bit of logic associated with any member scenes; for example, I don't want to have to have a bit of logic that says

 

IF (KPL1 == ON && KPL2 == ON && SWL == ON && ALL_ON_SCENE == OFF) THEN ALL_ON_SCENE=ON, SEND_INSTEON(KPL_ALL_ON_LED, ON)

 

Because if I have to go about it like that, then when I add a LampLinc, I have to modify that to be

 

IF (KPL1 == ON && KPL2 == ON && SWL == ON && LAMPLINC == ON && ALL_ON_SCENE == OFF) THEN ALL_ON_SCENE=ON, SEND_INSTEON(KPL_ALL_ON_LED, ON)

 

But I have to do that for *each* scene that a device might be a member of, and probably for on AND off states, etc. This might not be so bad for a few devices, but gets ridiculous quickly with dozens of devices and a dozen scenes. It also gets complex for things like dimmed states, etc.

 

With PowerHome, now, it does something clever, and this gets to the heart of what I was asking about. PowerHome knows the Insteon network and its settings. That *includes* the scene settings. Let's say your all-lights-on scene is currently on. PowerHome knows that. Now you get an Insteon event that indicates SwitchLinc has been turned off. PowerHome updates SwitchLinc's status in its database of course. However, it also notes that all-lights-on is no longer active, since not all the devices are in the required state, and updates its internal database to note that. THAT update can be monitored for with a PowerHome event, and then we push out an LED status update turning off the all-on LED. If we get another Insteon event indicating that SL has been turned off, PH will note that all-lights-on scene is once again active, since all the devices are in the required state again. Once again we trap that with an event and can push out an LED status update turning on the all-on LED.

 

The important bit here is that PowerHome is aware of the change in the scene's status WITHOUT any user-generated code; it knows based on the Insteon configuration that if it were to send an ALL-ON, that KPL1, KPL2, and SwitchLinc are set to ON. But the inverse is also true: it also knows that the ALL-ON scene is on if KPL1, KPL2, and SL are locally switched on. Further, if any of those devices are locally turned off, it knows that the ALL-ON scene is now off, because the devices are no longer in the required state.

 

This logic is MUCH simpler:

 

ON INSTEON_UPDATE {

IF (ALL_LIGHTS_ON == ON && ALL_LIGHTS_ON_LED == OFF) SEND_INSTEON(ALL_LIGHTS_ON_LED, ON)

IF (ALL_LIGHTS_ON == OFF && ALL_LIGHTS_ON_LED == ON) SEND_INSTEON(ALL_LIGHTS_ON_LED, OFF)

}

 

And it has the advantage of not needing to be updated every time a new device is added into a scene; PowerHome already knows what devices are part of a scene and just takes care of that itself.

 

I still find even that a bit ugly, but it's manageable. It's also a completely reasonable expectation for a home automation controller to have a modest amount of intelligence to allow designers to focus on designing overall strategies rather than having to micromanage each device.

 

It isn't clear to me that the ISY is actually capable of tracking scene states automatically in this manner.

[apostolakisl]

ISY doesn't track scene status. Since individual switches in a scene can be controlled outside of the scene if so desired, it just doesn't make sense.

 

KPL buttons can be set as responders in scenes and will turn on when the scene turn's on and off when the scene turns off. In this way, you can track the scene status in ISY by having ISY check the status of that kpl. However, the kpl button won't turn on if one or more of the switches is turned on via some method other than the scene. If you set the kpl to be a controller in a scene, then the button will turn on when the scene turns on, and the button will control the scene (be able to turn the scene on/off).

 

It really comes down to how comlex your scenes are and for the most part how overlapping your scenes are. If you have a switch as a member of multiple scenes, tracking scene status starts getting all crazy.

 

If two scenes shared one switch, and both scenes were turned on, that is easy both scenes are on.

But, if you turn one of those scenes off, technically neither scene is on because the scene that is still on is missing one of its members.

 

It comes down to this, if all of your lights are a member of one scene and are only controlled by turning the scene on/off tracking scene status is simple and logical. But, most people would rather use the complex multi scene member capacities of ISY/Insteon.

[oberkc]

My understanding with regards to scene status is best shown by rhetorical question. If one has a hypothetical scene with two dimmer devices, each with scene "on" levels defined as 50%, is a scene on or off if both devices are currently operating at 60%?

 

While I am sure there are logical ways to respond to questions such as this, I agree with apostolakisl: the ISY-99 does not monitor scene status. I continue to believe that you will find the ISY-99 to be lacking in this "intelligence" that you seek.

[apostolakisl]

If you want to track the last action on a scene, you can commit an 8 button kpl to the task. Make each button a member of a scene. If you never push the buttons on the kpl (or otherwise direct them to be altered), the kpl buttons will turn on when the scene is turned on, and off when the scene is turned off. The status of those kpl's can be querried by programs and therefore the ISY knows the last action of that scene.

 

However, this only tracks the last action on the scene, not the devices. So if a scene were turned on, then each device were turned off some other way, the kpl would still be on.

 

This probably isn't what you want.

 

What I have done is write programs that turn kpl's on when certain devices are on. Essentially, I am using them as status lights for other devices. They are not members of scenes themselves. This is probably what you were saying you don't want to do in the original post. You don't necessarily have to put all the switches in programs like this. If you just include the load switches, life is easier and you still know whether the light is on.

[Goose66]

I will waste everyone's time by echoing the others' comments. The ISY does not track scene "state," and I don't know that it makes logical sense to do so. If I run around and manually set all devices in a scene to the specified levels, have I activated the scene? Not really, IMO.

 

To keep a KPL button in sync with the scene in the ISY requires programming. Once more, you will want to build in a delay to prevent "bouncing" of the program as the state of the devices change. So, if you have a KPL set to toggle and assigned in a controller for an "All Lights" scene, then you will want a program similar to the following in the ISY:

 

If
       Status  'Master Suite / Left Sconce' is not Off
    Or Status  'Master Suite / Right Sconce' is not Off
    Or Status  'Master Suite / Fan Light' is not Off

Then
       Wait  2 seconds
       Set Scene 'Master Suite / Keypad-All Lights (Status)' On

Else
       Wait  2 seconds
       Set Scene 'Master Suite / Keypad-All Lights (Status)' Off

This, of course, could be programmed in the inverse, depending on your preference. I prefer "All Off" functionality to "All On." Therefore, if any lights in the "All Lights" scene are on, I want the KPL button toggled on so I can press it and turn all the lights in the room off. Only if every light is off is the KPL toggled off so that pressing it turns all lights on.

[jgreco]

I will waste everyone's time by echoing the others' comments. The ISY does not track scene "state," and I don't know that it makes logical sense to do so. If I run around and manually set all devices in a scene to the specified levels, have I activated the scene? Not really, IMO.

 

I guess I'm curious as to why you think that.

 

Fundamentally, a scene ought to describe a given state of a set of lights in your lighting system, correct? Like "all lights on", "all lights off", "nighttime", "watch movies", "outside lights/driveway for late night arrival", etc.

 

For example, "all lights on" is when all the lights are "on". You have a group of devices, let's say "all", and they're in a defined state. Insteon provides a way for this to happen with a group message. So you probably agree that if the Insteon group message is sent, then the "all lights on" scene is on, right?

 

1) What if the signal comes from an IR controller to the ISY? The ISY then proxies the scene request to the Insteon network. Is that still activating the scene? If so, then we can dismiss the concept of a scene as being an exclusively Insteon thing; something else can trigger a scene.

 

2) What if the member devices include an X10 device that doesn't support scenes (not even sure the ISY handles X10, but pretend it does and follow along for the sake of debate)? So an IR signal comes in to trigger a scene and the ISY sends out an Insteon scene command and an X10 "on" command to our device. Is this still a scene? I see it as being so, because a scene is about the results, not about the technical details needed to make it happen.

 

3) What if someone then turns off one of the Insteon devices? I think we're in agreement that this no longer results in the scene being on. Because if it doesn't, then the question becomes at what point is the scene no longer on? One light off? Two? All? etc.

 

4) Someone having turned off the device, then what if someone then turns it back on? This is the ultimate question. All the lights are on. Is the "all lights on" scene active? All the lights are on. I say the scene is active. You're saying no, I believe. Why? Because a device was manually set? So you're saying that it requires an electronic command to set up a scene? What's the benefit of that?

 

It does make logical sense to track scene status, but you have to have a consistent vision of how to make use of this.

 

For example, we have an "all lights off" scene, which is all lights off, oddly enough. Now here's the cool bit. Besides just being able to hit ALL OFF when we leave the house, which is the obvious goal of the scene, we can ALSO see when lights are on - because PowerHome's scene status is propagated out to our KPL LED. So when a kid gets up at night and has turned on their room light, we can see on the master bedroom KPL that a light somewhere in the house is on (because ALL OFF is *not* lit). This is just one trivial example.

 

The definition of "scene" should be very simple and straightforward: when all member devices are in the target state, then the scene is active.

[jgreco]

If you want to track the last action on a scene, you can commit an 8 button kpl to the task. [...]

 

However, this only tracks the last action on the scene, not the devices. So if a scene were turned on, then each device were turned off some other way, the kpl would still be on.

 

This probably isn't what you want.

 

What I have done is write programs that turn kpl's on when certain devices are on. Essentially, I am using them as status lights for other devices. They are not members of scenes themselves. This is probably what you were saying you don't want to do in the original post. You don't necessarily have to put all the switches in programs like this. If you just include the load switches, life is easier and you still know whether the light is on.

 

Yes, thanks, that's helpful in that it clarifies that there's no coherent scene concept. I already have an operational Insteon network and am not going to be able to rip open walls to install additional KPL's to address what I would call a very unfortunate deficiency in an otherwise awesome gadget; I had really been hoping to come up with a reason to buy one.

 

Our current system helpfully updates the status LED's based on the actual status of remote lights. This works even for things like local load sensing on a LampLinc; if I turn on a lamp on a nightstand by flicking its switch off and on in the middle of the night, PowerHome catches that and our "ALL OFF" scene LED extinguishes. At the same time, we can actually use the KPL buttons to send scene commands too. It's fairly intuitive. We like it a lot. It's great to be able to know that no one's in the basement because a KPL LED indicates that all basement lights are off.

 

I had, however, wanted to eradicate the need to run a Windows box. I don't think I need to explain that to anyone here.

[jgreco]

My understanding with regards to scene status is best shown by rhetorical question. If one has a hypothetical scene with two dimmer devices, each with scene "on" levels defined as 50%, is a scene on or off if both devices are currently operating at 60%?

 

In PowerHome: If the devices aren't set to the state defined by the scene, then the scene is off. I mean, it's really that straightforward, you run through the member devices, check their status, if all of them are in defined status, scene's on, you're all done.

 

That might be tough to get your head around the first few times you do something silly in programming things like the local on-level to some similar-but-not-the-same value (50 vs 60%). Been there, done that.

 

But really, my question in return would be:

 

For your setup, if someone had set the local on-level to 50% for each of those dimmers, and then manually single-tapped each one on, so that both are in fact at 50%, is the scene on or off? Or do we call it two switches that happen to be set to the same level as a defined scene, but since it wasn't tripped electronically, we're unwilling to call it a scene? I'm even fine with that last one, if that's the way it is, but I'm not sure that such an option is beneficial.

 

I hope that these questions at least give you guys a little something to think about.

 

As for the rest, I'm quite disappointed to find that I'm going to have to find a way to put up with PowerHome (or maybe MisterHouse has gotten up to speed). I think the ISY is a fantastic little gadget regardless but I'm not prepared to lose significant functionality, and I'm not sure I have the time to spend figuring out how to use the ISY as an Insteon gateway to some code running on a server somewhere that can implement the functionality I seek. Thanks for your responses and I'll be happy to continue this thread (if anyone's interested in debating how many scenes can dance on the head of a pin!)

[apostolakisl]

I understand your thought, but having scene "status" is, practically speaking, untenable. A scene is defined by a set of insteon devices being precisely set a certain way. Even one device being one percent off makes the scene "false", but not exactly off. How would you like ISY to report that?

 

And since one device can be included in a dozens of scenes, this also makes it impractical.

 

The value of knowing the status of a scene is generally in knowing that the lights are off. So if you had a scene tracking method, and one of the devices was not exactly as described by the scene, it would be false or "off" (sort of), but that information is really not helpful.

 

What is helpful is perhaps knowing that a group of lights is actually off. And to this end you write a program that checks the status of whatever bunch of lights you are interested in and reports it. Here ISY has great value as the programs aren't hard to create and are quite versatile.

 

For example, I have a kpl next to my bed that tracks every load bearing switch in the house except for a couple I keep on at night. If anyone of them is not completely off, the kpl lights up. I have all of those lights in a scene for which that kpl is the controller, so pushing the kpl when lit turns the house off. Conversely, pushing that kpl when it is already off, turns all the lights on, like in an emergency, from the bedside.

 

You might also want to know all of the lights in the basement are off. Even if you only have on scene in the basement, if any one of those lights were locally changed by someone in the basement, the scene would be off, but lights on, and your button upstairs tracking the scene would give you the impression that the lights are off. Again, write a program that says whenever any of those load switches is not off, turn the kpl on.

 

And, no need to tear out walls to add kpl's. You can always replace a paddle switch with a 6 button kpl and use the top/bottom as the on/off and have 4 additional buttons. It is also quite simple to cut a little bit wider hole in the drywall and install a double gang box without any drywall patching necessary.

 

All the scene stuff aside, the ISY, in my opinion, is the ONLY reason that I like my Insteon switches. The ability to troubleshoot, update, repair, and track Insteon is second to none. Furthermore, the program versatility is tremendous, and the constant addition of new features makes it a joy to own. That and it never crashes.

[oberkc]

For your setup, if someone had set the local on-level to 50% for each of those dimmers, and then manually single-tapped each one on, so that both are in fact at 50%, is the scene on or off?

 

I suppose the answer to that would also depend on whether there are any controllers of the scene, such as a keypad button.

 

In the end, the answer really doesn't matter. I don't believe the ISY has what you are looking for. Good luck with whatever option you choose.

[jgreco]

I understand your thought, but having scene "status" is, practically speaking, untenable. A scene is defined by a set of insteon devices being precisely set a certain way. Even one device being one percent off makes the scene "false", but not exactly off. How would you like ISY to report that?

 

And since one device can be included in a dozens of scenes, this also makes it impractical.

 

The value of knowing the status of a scene is generally in knowing that the lights are off. So if you had a scene tracking method, and one of the devices was not exactly as described by the scene, it would be false or "off" (sort of), but that information is really not helpful.

 

What is helpful is perhaps knowing that a group of lights is actually off. And to this end you write a program that checks the status of whatever bunch of lights you are interested in and reports it. Here ISY has great value as the programs aren't hard to create and are quite versatile.

 

For example, I have a kpl next to my bed that tracks every load bearing switch in the house except for a couple I keep on at night. If anyone of them is not completely off, the kpl lights up. I have all of those lights in a scene for which that kpl is the controller, so pushing the kpl when lit turns the house off. Conversely, pushing that kpl when it is already off, turns all the lights on, like in an emergency, from the bedside.

 

You might also want to know all of the lights in the basement are off. Even if you only have on scene in the basement, if any one of those lights were locally changed by someone in the basement, the scene would be off, but lights on, and your button upstairs tracking the scene would give you the impression that the lights are off. Again, write a program that says whenever any of those load switches is not off, turn the kpl on.

 

And, no need to tear out walls to add kpl's. You can always replace a paddle switch with a 6 button kpl and use the top/bottom as the on/off and have 4 additional buttons. It is also quite simple to cut a little bit wider hole in the drywall and install a double gang box without any drywall patching necessary.

 

All the scene stuff aside, the ISY, in my opinion, is the ONLY reason that I like my Insteon switches. The ability to troubleshoot, update, repair, and track Insteon is second to none. Furthermore, the program versatility is tremendous, and the constant addition of new features makes it a joy to own. That and it never crashes.

 

I'm fine with the scene being "false" if a member device isn't in the exact state. Practical experience with a working system tells me that this isn't really a problem.

 

I don't see why having a device in dozens of scenes makes it impractical. The algorithm isn't particularly complex; when a device's status changes, you traverse each scene it is a member of and update the status of the scene if needed.

 

The value in knowing the status of a scene CAN be in knowing that lights are off, but we use it both ways. When the wife calls and says she's going to be working late, it's convenient to be able to override the scheduled events and set outside night arrival lighting, but she also sometimes comes home early when she's supposed to work late, and the LED's a reminder. We make reasonably frequent use of enough scenes that I cannot agree that it's just convenient knowing a scene is off.

 

I certainly agree that knowing a group of lights is off is convenient; we have an ALL OFF scene that goes on when all (interior) lights are off. But this requires no special code... PowerHome's scene code just notices that all member devices are in the proper states and the scene's state transitions to on. There's an event that pushes an Insteon update out to the KPL, but that's it. We can add more Insteon devices to the network, and as long as they're members of the right scenes, all configured KPL buttons will both control and report the scene just fine with no additional twiddling of code.

 

See, and that's what I want to avoid, I don't want to be adding devices and then forgetting that I need to modify this program and that program for each scene and possible thing that might happen throughout the automation system. The ISY appears to be extremely useful in implementing some higher level logic that Insteon is incapable of on its own, but this sort of logic is the kind of thing that I would want in an automation system ... abstraction with a mind towards allowing developers to focus on function rather than micromanaging devices.

[jgreco]

I suppose the answer to that would also depend on whether there are any controllers of the scene, such as a keypad button.

 

I'm really trying to figure out what that means. Why would it depend on that?

[Goose66]

 

I guess I'm curious as to why you think that.

 

Fundamentally, a scene ought to describe a given state of a set of lights in your lighting system, correct? Like "all lights on", "all lights off", "nighttime", "watch movies", "outside lights/driveway for late night arrival", etc.

 

For example, "all lights on" is when all the lights are "on". You have a group of devices, let's say "all", and they're in a defined state. Insteon provides a way for this to happen with a group message. So you probably agree that if the Insteon group message is sent, then the "all lights on" scene is on, right?

 

1) What if the signal comes from an IR controller to the ISY? The ISY then proxies the scene request to the Insteon network. Is that still activating the scene? If so, then we can dismiss the concept of a scene as being an exclusively Insteon thing; something else can trigger a scene.

 

2) What if the member devices include an X10 device that doesn't support scenes (not even sure the ISY handles X10, but pretend it does and follow along for the sake of debate)? So an IR signal comes in to trigger a scene and the ISY sends out an Insteon scene command and an X10 "on" command to our device. Is this still a scene? I see it as being so, because a scene is about the results, not about the technical details needed to make it happen.

 

3) What if someone then turns off one of the Insteon devices? I think we're in agreement that this no longer results in the scene being on. Because if it doesn't, then the question becomes at what point is the scene no longer on? One light off? Two? All? etc.

 

4) Someone having turned off the device, then what if someone then turns it back on? This is the ultimate question. All the lights are on. Is the "all lights on" scene active? All the lights are on. I say the scene is active. You're saying no, I believe. Why? Because a device was manually set? So you're saying that it requires an electronic command to set up a scene? What's the benefit of that?

 

It does make logical sense to track scene status, but you have to have a consistent vision of how to make use of this.

 

For example, we have an "all lights off" scene, which is all lights off, oddly enough. Now here's the cool bit. Besides just being able to hit ALL OFF when we leave the house, which is the obvious goal of the scene, we can ALSO see when lights are on - because PowerHome's scene status is propagated out to our KPL LED. So when a kid gets up at night and has turned on their room light, we can see on the master bedroom KPL that a light somewhere in the house is on (because ALL OFF is *not* lit). This is just one trivial example.

 

The definition of "scene" should be very simple and straightforward: when all member devices are in the target state, then the scene is active.

 

For what its worth . . .

 

Each of your scenarios pre-supposes that scenes have a state, e.g. "is the scene active" or "the scene being on." Prescribing a state to scenes does not translate to it being logical that scenes have state. IMO, scenes are simply groups of devices, not devices in themselves. And this is precisely how they work in Insteon. For example, when I send an On command to a "scene" (really a group), each device in the scene is set to its preset on-level. Following your logic, the scene is On or Active. If I manually turn one device Off, then the scene is not On -- it is Off . . . or is it? In you logic there exists an inconsistency between a scene being Off and sending an Off to a scene, which could result in completely different states of the devices. So when is the scene Off -- when it is not On, or when all devices in the scene is Off?

 

The term "scene" is an unfortunate artifact from X10, and it would have been clearer to stick with the Insteon "Group." You can conveniently turn the group on (to pre-set on levels) and turn the group off, but the state of the group is made up of the state of the devices in the group.

[apostolakisl]

If all of your devices belong to no more than one scene, and each device in that scene is a controller of that scene, you can do what you want.

 

In effect, you will only be creating virtual 3-way, 4-way, 5-way, etc scenarious. In this case, it makes logical sense to track it as a scene since all devices will work together at all times. (it is possible with programs to throw devices out of sync, but lets not go there.) Since ISY will respond to the state of any one device, and in a virtual x-way scene the devices move together, asking ISY to track the status of any one of the devices will tell you the status of the scene.

 

But, the beauty of scenes is that you don't have to do this! You are free to make all kinds of crazy permutations to suit your needs. x-way scenes exist without Insteon, they have been around for 100 years via good old fashioned hardwires.

[jgreco]

For what its worth . . .

 

Each of your scenarios pre-supposes that scenes have a state, e.g. "is the scene active" or "the scene being on." Prescribing a state to scenes does not translate to it being logical that scenes have state. IMO, scenes are simply groups of devices, not devices in themselves. And this is precisely how they work in Insteon. For example, when I send an On command to a "scene" (really a group), each device in the scene is set to its preset on-level. Following your logic, the scene is On or Active. If I manually turn one device Off, then the scene is not On -- it is Off . . . or is it? In you logic there exists an inconsistency between a scene being Off and sending an Off to a scene, which could result in completely different states of the devices. So when is the scene Off -- when it is not On, or when all devices in the scene is Off?

 

The term "scene" is an unfortunate artifact from X10, and it would have been clearer to stick with the Insteon "Group." You can conveniently turn the group on (to pre-set on levels) and turn the group off, but the state of the group is made up of the state of the devices in the group.

 

Okay, so you are hung up on the term, implementation and technology

 

Fundamentally, I don't see "scene" as an artifact from X10, because the term far predates X10 scenes and has a general meaning that fits what we're discussing. We can call them a "group" too but then there's confusion as to whether we're talking specifically about an Insteon Group or just a collection of lights. So to keep things clear, I'm not talking X10 scenes, or Insteon Groups. I'm talking lighting-functionality scenes.

 

You raise an interesting edge case, and I can see cases where it'd be problematic.

 

The problem is that it's extremely handy to be able to set your lights to some known state. Insteon Groups address that, but for completeness within the Insteon protocol they also allow a Group Off signal to be sent. Makes sense for hopefully obvious reasons, but of course this inserts a third possible state because instead of "ON/ANY-OTHER-STATE" you have "ON/OFF/ANY-OTHER-STATE". Computer programmers would typically look at the first case and say "well that's obviously 1 or 0". But we look at the second case there and kind of pull our hair because the ambiguous state cannot be articulated in a useful fashion.

 

For a home automation system, though, it's really difficult to support ambiguous states that cannot be articulated in some useful fashion. Maybe you COULD have "OFF/SOME/ON" or something like that but the usefulness of the middle state is highly questionable. So PowerHome doesn't do that. It simply defines a scene as ON when the lights in that group are in the defined states, and OFF otherwise. Now I've tried to be very clear about the underlying thinking so that it's clear that the ambiguous state is both a problem and not very useful. I *think* we agree on that at some level.

 

So here's the solution to the problem you are asking about: you can use two scenes, one to match scene on, and one to match scene off. This works, at the expense of adding a scene, but gives you your tri-state answer: you get an indication when all lights are in the defined scene mode (SCENEON == ON), an indication when all lights in the scene are off (SCENEOFF == ON) and when things are in the ambiguous state (SCENEON == OFF && SCENEOFF == OFF).

 

Now, here, we actually do use two scenes, one for ALL ON and one for ALL OFF; this works great to provide some very useful functionality in our system. You can feel free to deny that it's logical to want scenes to have state, but I think what PowerHome does is reasonably sensible *and* it provides some very useful capabilities for reporting the status of lights. So far I haven't found any reason to test for the ambiguous state in our setup, so from my point of view being able to identify when a group of devices is in a defined state is very useful, and hand-wringing about what it means when they're not in that state is not useful.

[jgreco]

If all of your devices belong to no more than one scene, and each device in that scene is a controller of that scene, you can do what you want.

 

In effect, you will only be creating virtual 3-way, 4-way, 5-way, etc scenarious. In this case, it makes logical sense to track it as a scene since all devices will work together at all times. (it is possible with programs to throw devices out of sync, but lets not go there.) Since ISY will respond to the state of any one device, and in a virtual x-way scene the devices move together, asking ISY to track the status of any one of the devices will tell you the status of the scene.

 

But, the beauty of scenes is that you don't have to do this! You are free to make all kinds of crazy permutations to suit your needs. x-way scenes exist without Insteon, they have been around for 100 years via good old fashioned hardwires.

 

Sadly, all our devices belong to multiple scenes, at a minimum ALL-ON and ALL-OFF. I bought into home automation to get away from overly simplistic lighting control restrictions. We have some lights that are members of maybe half a dozen scenes. Insteon is fantastic since it provides more capabilities than any of the old hardwire or low-voltage control systems did, and it's reprogrammable without rewiring.

 

Thing is, we bought KPL's because there are key points throughout the house where it's nice to be able to call for certain scenes, only a few of which can reasonably be implemented as an x-way Insteon Group. Most of our KPL's have a few regionally-appropriate scenes, such as the one at the bottom of the basement stairs which has "basement walk", "basement off", "laundry", "workshop". "basement walk" will bring up a set of lights at a set dim level to allow people to walk around without running into doors and walls, which really needs to be a scene due to the number of affected devices. "laundry" and "workshop" can be a simple Insteon link because they're hitting single targets, but "basement off" has to hit maybe a dozen targets. Having the status lights are really neat because sometimes family members don't hear each other; it's not unusual for someone to come on down and work on laundry, and the status light there is a great reminder not to hit basement off. So both the ability to set scenes and to see what's going on are nice.

[apostolakisl]

Your concept has some validity, but practically speaking it falls apart when you start having switches that are members of multiple scenes.

 

Also, don't forget that a switch can be designated "off" in a scene. I have several scenes which I have included to be shut off becuase they are commonly on and those particularly scenes specifically want them off. So this scenario also puts a monkey wrench into the scene on/off/ambigous logic.

 

Truly this is what programs are for, you get to define exactly what it is you want to know. You can write a dozen programs in less time thant it takes to participate in this debate.

[Goose66]

I don't suspect such a feature will be added anytime soon. It has been discussed many times before, and never has been set as a priority by the developers. I (and others) have suggested dummy devices that could be added to the scene to simply reflect the last command issued to that scene (on or off). That has been poo-pooed as well. Perhaps something in a future incarnation of variables will allow a variable to be tied to a scene to reflect its state. But that's a long way off.

[oberkc]

I'm really trying to figure out what that means. Why would it depend on that?

 

Suppose one has a scene with a controller keypad button and two responder dimmer switches. Suppose the "on" levels for each responder is set at 50%. Suppose, then that each individual dimmer was manually set to 50%. The keypad controller would not be on. Is the scene on? That is all that it means.

 

Suppose one has a scene with three devices, all controllers and responders. Each scene is defined differently, depending on which controller is used to activate it. When is this scene on?

 

This topic has been discussed before, and I don't believe the omission of scene status is due to a failure to consider it. Certainly, it can get complicated pretty quickly.

[jgreco]

I'm really trying to figure out what that means. Why would it depend on that?

 

Suppose one has a scene with a controller keypad button and two responder dimmer switches. Suppose the "on" levels for each responder is set at 50%. Suppose, then that each individual dimmer was manually set to 50%. The keypad controller would not be on. Is the scene on? That is all that it means.

 

Fair enough. Answer: Scene's on. Insteon's not sufficiently sophisticated to deal on its own with representing the situation since Insteon is essentially a system with no centralized controller; I kind of expect a device like the ISY needs to address the logic check needed to turn on the keypad LED.

 

That, incidentally, is the trivialized version of my initial inquiry ... which was whether or not the ISY *actually* handled this sort of thing without someone needing to manually code up the logic to tally the state of a scene. Having to send out the proper Insteon event to update LED's is fine, but I don't really want to have to string together several dozen individual status checks in order to implement large scene state checking. The automation controller already knows Insteon group memberships and ought to be able to derive whether or not the devices are in state with a simple traversal of the device list.

 

Suppose one has a scene with three devices, all controllers and responders. Each scene is defined differently, depending on which controller is used to activate it. When is this scene on?

 

That's silly. A scene cannot be defined three different ways; what you are describing would be three separate scenes. Even the language you use to describe the situation indicates that it's not the same scene. You had to say "Each scene" - making it clear that this is really more than one. You can certainly have multiple scenes controlling the same set of lights.

 

This topic has been discussed before, and I don't believe the omission of scene status is due to a failure to consider it. Certainly, it can get complicated pretty quickly.

 

Speaking as a longtime software designer who has been highly successful in simplifying systems so that they can then be scaled massively, I'm fairly comfortable in theorizing that people can get bogged down in trying to deal with everything possible when it would be better to focus on some manageable and reasonable point that isn't a quagmire, and then running with that.

 

If your model of a scene doesn't work in practice because it's too complicated, throw out the model and substitute a simpler one. I've presented a simple definition for a scene that's very functional, and not just hypothetical, since PowerHome uses it and it works fine here. It may not mesh with some of your preconceived notions of what a "scene" ought to be, but the fact is that my "scene" definition is useful in what it can do, and can be trivially coded, while your notions of a scene "get complicated pretty quickly" and I certainly understand why you'd see implementing code for it as a headache.

 

It's something to think about, in any case.

 

From my perspective, it's a tragedy because I really wanted to do something practical like an ISY, but I don't want to be manually managing large if/and/and/and/and/and/and/and/[...]/then code structures, because experience teaches that along that path lies madness (and errors).

[oberkc]

Fair enough. Answer: Scene's on.

 

OK. I will take your word for that. Should I dare suggest that is not the insteon definition of a scene being on and run the risk of being called silly again?

 

I kind of expect a device like the ISY needs to address the logic check needed to turn on the keypad LED.

 

If you choose to use the programming logic of the ISY, it could address the logic to turn the keypad on. To do so, however, the keypad button in our example would not be part of the defined scene. However, if you define an insteon scene as including the keypad button, then you are relying on the inherent insteon capability of the devices rather than the logic of a program.

 

That's silly. A scene cannot be defined three different ways; what you are describing would be three separate scenes.

 

I don't know about whether this is silly. I will leave that to your expert judgement. I am just a simple user of an insteon system.

 

Yes, indeed, a scene can be defined three different ways. The ISY-99 creates such scenes. Perhaps the ISY-99 use of the term "scene" is sometimes a combination of pure insteon "scenes". Regardless, in my mind, this makes establishment of relationships between devices a bit easier to accomplish. Where you have three "scenes", the ISY-99 construct has one. It works for me. Apparently, this is not your preference.

 

If your model of a scene doesn't work in practice because it's too complicated, throw out the model and substitute a simpler one.

 

I actually find the ISY-99 model of a scene works pretty well. Perhaps the trade-off is that the definition of scene "status" becomes a bit more difficult to define. Design, as in life, is about tradeoffs. Apparently, powerhome has made different design choices.

[jgreco]

Fair enough. Answer: Scene's on.

 

OK. I will take your word for that. Should I dare suggest that is not the insteon definition of a scene being on and run the risk of being called silly again?

 

I'm sorry. I wasn't aware that you weren't following the full conversation; I see now I had been talking to kingwr when I said "I'm talking lighting-functionality scenes." The choice of technology to implement lighting is just a way to get stuff done. If you want to define "scene" as being an Insteon thing, what happens when one of your lights is controlled by a legacy X10 device? It can't be part of the scene because of a technicality - that it doesn't support a more modern signal protocol?

 

I'm not interested in Insteon's definition of a scene, which someone else pointed out is called a group anyways, not a scene. What I'm interested in is useful lighting and controls. I want to click buttons and have lights do specific things. I want the LED's on the KPL's to do meaningful things. etc. One of the most useful things our home automation system adds to our Insteon network is the correct reporting of the state of scenes, because that's something that Insteon generally lacks. If all my lights are off, I want the ALL OFF LED to light. If anyone turns a light on, via any means, I want the ALL OFF LED to go out. If that one light is again turned off, I again want the ALL OFF LED lit. Likewise, when other scenes go into state, it's very handy to have those LED's light and extinguish as appropriate. It's easy and intuitive for people to use.

The Insteon plumbing behind the scenes is irrelevant, as we can integrate X10 or other supported devices as well, and it still works the same way.

 

From my point of view, when the lights are set in the right state, scene's on. That turns out to be very useful for driving KPL LED's, web reporting, API control, etc.

[oberkc]

It sounds, then, that you understand things well enough to make a decision about which way you want to go. Good luck.