Jump to content

Can you control the KPL Button Light only?


AnthemAVM

Recommended Posts

I have it set up in my house that any KPL A turns on the kitchen lights. When anyone turns them on via the KPL all the KPL A are on.

 

If someone turns on the kitchen island lights, the KPL A doesn't light up. I could go put a program that if X is on, turn on KPL A. The problem is that turns on all the kitchen lights.

 

I was just hoping to be able to have the KPL A Light on if any of the lights are on. Seems like I can't figure out how to control just the light as any program just turns on the switch.

 

Any ideas?

 

Thanks

Link to comment

Is this an 8-button KPL? KPLA is the controller of the load, right? If so, then turning it on turns on the load. I don't believe there is any getting around this. That is the design of the keypad. However, all other buttons are controllable in this way.

Link to comment
Is this an 8-button KPL? KPLA is the controller of the load, right? If so, then turning it on turns on the load. I don't believe there is any getting around this. That is the design of the keypad. However, all other buttons are controllable in this way.

 

No this is a KPL 6. A is not the load on the KPL, I call that On(Top)Off(Bottom) A is part of the 4 buttons.

 

So how would you control just the light, not the switching?

 

Thanks

Link to comment
So how would you control just the (KPL button) light, not the switching?

The KPL button must be part of a scene for the ISY to control it. If you want to control the button light independently of any other device, then put it in an ISY scene by itself. If it's part of other scenes, then it should behave as you expect in those scenes as well, as either a responder or controller.

 

--Mark

Link to comment
So how would you control just the (KPL button) light, not the switching?

The KPL button must be part of a scene for the ISY to control it. If you want to control the button light independently of any other device, then put it in an ISY scene by itself. If it's part of other scenes, then it should behave as you expect in those scenes as well, as either a responder or controller.

 

--Mark

 

Mark,

 

Thanks for taking the time to respond.

 

What is the connection between having the KPL is a scene by itself and the scene that turns the lights on and off?

Link to comment

So, let's see if I have this right...you want the KPLA to control kitchen lights. So, you have set up a scene with KPLA as a controller of a scene with other devices (switches, I assume). Did you set up those devices as controllers also, or just responders? It sounds like they are just responders.

 

I am not in a position to confirm at this point, but my recollection is that when the ISY turns on a controller of a scene (KPLA, in your case), the scene does NOT activate. But this sounds contrary to your experience. If my understanding is accurate, then a program:

 

if kitchen island is turned on

or kitchen lights are turned on

or other kitchen lights are turned on

then turn on KPLA

 

would do the job. Maybe tomorrow, I can play around some more to check this out. Sorry I cannot be more help tonight.

Link to comment

 

Mark,

 

Thanks for taking the time to respond.

 

What is the connection between having the KPL is a scene by itself and the scene that turns the lights on and off?

 

When you control the scene with all the lights all the lights will respond as well as the KPL button.

 

A scene with just the KPL button(s) will only switch the button(s) on/off.

 

Rand

Link to comment
What is the connection between having the KPL is a scene by itself and the scene that turns the lights on and off?

Rand gave a quick answer to this. I went back and reread your original post, and here's some additional info based on what I think you want to do:

 

- You have some kitchen lights and a KPL-A button.

- You want KPL-A to turn them all on when it's turned on. (And presumably turn them all off when it is turned off.)

- You want KPL-A to light up when any of the kitchen lights are turned on individually. And turn off when the last one is turned off individually, if individually controlled.

 

Right?

 

Then here's what might work for you:

 

1) Put all your lights in an "all kitchen light" scene, as responders.

2) Put KPL-A in that same scene, as a controller

 

KPL-A will now turn the "all lights" scene on and off, and the KPL-A light will go on/off accordingly. You probably already have this part done.

 

So now you need to address the other desire, to control the KPL-A light for the other conditions. Continue...

 

3) Put KPL-A in a scene by itself as a responder (in addition to the scene it's already in above as a controller).

 

You can now control the KPL-A light independently of the "all lights" scene by turning this scene on/off. If you want KPL-A to be on whenever any of the lights is on, and off when they are all off, then this program is one way to do it:

 

If
      Status  'kitchen light 1' is not Off
   Or Status  'kitchen light 2' is not Off
   Or Status  'kitchen light 3' is not Off

Then
       Set Scene '[KPL A]' On

Else
       Set Scene '[KPL A]' Off

 

By using Status in the program, it monitors lights no matter how they're turned on/off. By using "not Off" then the lights don't have to go all the way on (100%) to trigger the KPL-A light. And, of course, the "all lights" scene still works as expected.

 

One nice side benefit is that KPL-A can always be used to turn all the lights off even if only one of them has been turned on.

 

I hope this helps and makes things more clear. It's very similar to functionality I have running in my own setup.

 

--Mark

Link to comment

Thank you Mark.

 

I'm new to the ISY. I was trying to set KPLB on but had the same question as AnthemAVM, which Rand and you answered.

 

I have a question though...

 

Why can't I just use an "Insteon" command to "Set KPLB On"?

 

In an semi-related question...

 

When is a scene needed vs. a program? Do they provide different functionality or have different purposes?

 

Thanks again.

 

Steve

Link to comment

As far as "KPL -A On", KPL Button A is a controller, not a responder. You can't set a controller on, only responders. By setting up a scene in ISY/99i, you are creating a scene on the PLM that is cross-linked with the KPL button A, just as if you had two switches cross-linked. When the Scene is set to on, the cross-linked KPL A button changes status to reflect the status of the scene. Similarly, pressing the KPL A button will turn on or off the scene.

 

Just to clear up an area of confusion, the main buttons on your KPL (the big on and off, if that is how it is configured) are controllers as well, automatically linked to the responder in the unit.

Link to comment
What is the connection between having the KPL is a scene by itself and the scene that turns the lights on and off?

Rand gave a quick answer to this. I went back and reread your original post, and here's some additional info based on what I think you want to do:

 

- You have some kitchen lights and a KPL-A button.

- You want KPL-A to turn them all on when it's turned on. (And presumably turn them all off when it is turned off.)

- You want KPL-A to light up when any of the kitchen lights are turned on individually. And turn off when the last one is turned off individually, if individually controlled.

 

Right?

 

Then here's what might work for you:

 

1) Put all your lights in an "all kitchen light" scene, as responders.

2) Put KPL-A in that same scene, as a controller

 

KPL-A will now turn the "all lights" scene on and off, and the KPL-A light will go on/off accordingly. You probably already have this part done.

 

So now you need to address the other desire, to control the KPL-A light for the other conditions. Continue...

 

3) Put KPL-A in a scene by itself as a responder (in addition to the scene it's already in above as a controller).

 

You can now control the KPL-A light independently of the "all lights" scene by turning this scene on/off. If you want KPL-A to be on whenever any of the lights is on, and off when they are all off, then this program is one way to do it:

 

If
      Status  'kitchen light 1' is not Off
   Or Status  'kitchen light 2' is not Off
   Or Status  'kitchen light 3' is not Off

Then
       Set Scene '[KPL A]' On

Else
       Set Scene '[KPL A]' Off

 

By using Status in the program, it monitors lights no matter how they're turned on/off. By using "not Off" then the lights don't have to go all the way on (100%) to trigger the KPL-A light. And, of course, the "all lights" scene still works as expected.

 

One nice side benefit is that KPL-A can always be used to turn all the lights off even if only one of them has been turned on.

 

I hope this helps and makes things more clear. It's very similar to functionality I have running in my own setup.

 

--Mark

 

Mark,

 

Thank you very much this worked perfect.

 

The only question is why the else statement?

Link to comment

Thanks, Mark. I, too, have already created a program with this technique. It solves a problem I have not been able to address. Until now.

 

When is a scene needed vs. a program? Do they provide different functionality or have different purposes?

 

Scenes, in my mind, are simply another way to link insteon devices, so that they respond to each other. It duplicates the manual linking process described in the manual of the various devices.

 

Programs allow actions in response to conditions. Conditions may be time, sunset, darkness, motion, temperature, garage doors, or just about anything else one can imagine. Conditions may also be other insteon signals. Therefore, it is possible to duplicate scenes with programs, but I consider it better to use scenes where applicable.

 

Why can't I just use an "Insteon" command to "Set KPLB On"?

 

I don't think I would have remembered this, but I don't see keypad buttons (other than the primary) as a device which can be controlled by a program command. This surprised me...I thought that I had used this capability before. Perhaps it is one of those things available on certain versions of keypads and not on others. But you can put these buttons in a scene and then control the scene in a command. Go figure.

Link to comment

I think the part that gets confusing for people starting in ISY - I know it was for me - is the conceptual part of any button only being able to be a controller of one 'scene' though it can be a responder to many.

 

In a typical cross-link between two buttons you just make both controllers - A will turn B on and off, B will turn A on and off.

 

If you make A a controller and B a responder then A will turn B on but B will not turn A on. This is exactly what happens if you manually link two switches too. You must make B a controller of A in order for B and A to 'jive'.

 

In the case of a KPL-6 the primary button is always the Load - so turning it on or off will always turn the load on or off - you can't control the light without controlling the load. You can fool this in a KPL-8, though, by turning the switch upside down - effectively making the load button H instead of button A. This is a useful technique in some situations and you barely notice the little plastic tab on the wrong side.

 

The one button being only one controller gets conceptually difficult when you want to put that button in multiple scenes - but when you think deeper it only makes sense. Turning any one button on will ALWAY turn on everything that is in that scene - so clearly any one button can only be a controller of one 'scene' regardless of how many different things are happening. However any number of things can turn that button on or off so it can be a responder of as many scenes as its link table will allow (over 400, I think)

 

It gets a little more difficult if you have one switch turn on two separate lights that each have their own switches. It's easy to turn them both on by making A a controller of B and C but clearly you don't want B and C to be controllers of A because then if either B OR C turned off A would turn off despite the other being on. In this scenario you have to use a program that monitors a status change to B and C and make A match when B and C match - if B is OFF and C is OFF then turn A off.

 

As for your question, Steve, about sending an insteon command to turn the KPL button on that is, indeed, possible, and is, indeed what ISY does - it just keeps the links in the PLM so that it can keep track readily of what is on and what is off instantaneously. Without this system the ISY would continuously have to poll each device in order to determine if it is on or off - and THAT is a huge amount of unnecessary insteon traffic.

 

Dunno if that helps but there ya go.

Link to comment
Why can't I just use an "Insteon" command to "Set KPLB On"?

The simple answer is because the ISY does not allow you to directly control (as a "device") the non-load buttons of a KPL. I have no idea why, whether it's an Insteon limitation or a design choice in the ISY. Putting a button in a scene and controlling it that way works fine though.

 

In an semi-related question...

 

When is a scene needed vs. a program? Do they provide different functionality or have different purposes?

Hmmm. My answer to this would be: A scene is a grouping of devices that you want to be able to turn on and off as a single event. Each device can have individual response (light and ramp levels), although all member devices respond at the same time to a scene command. Scenes are fully supported by Insteon devices, and ISY scenes provide the same functionality.

 

Programs add a higher logic to the process, allowing additional functionality and processing. They definitely serve a different purpose than scenes, although complement them very well. Programs allow you to be much more creative in designing your automation events.

 

The UDI Wiki has lots more good info: http://www.universal-devices.com/mwiki/

Link to comment
The only question is why the else statement?

This allows you to combine both the ON and OFF actions in one program. As written, if any of the lights goes on, the IF is TRUE and the program's THEN executes (turning on the KPL-A scene). But if all the lights are off, the IF logically evaluates to FALSE causing the program's ELSE to execute (turning off the KPL-A scene).

Link to comment
...some good info...

A key concept with regard to the ISY:

 

In general, when the ISY adds a device to a scene as a controller, it automatically adds that device to the scene as a responder as well. This makes creating cross-linked scenes a snap, since the switches are all added as controllers and the ISY takes care of creating all the proper responder links as well.

Link to comment

A key concept with regard to the ISY:

 

In general, when the ISY adds a device to a scene as a controller, it automatically adds that device to the scene as a responder as well. This makes creating cross-linked scenes a snap, since the switches are all added as controllers and the ISY takes care of creating all the proper responder links as well.

 

I'm not sure that's true. You can make a kpl a controller without it being a responder too (I'm fairly certain). To crosslink you must make them both controllers. I may be wrong so don't throw things at me if I am ;)

Link to comment
I'm not sure that's true. You can make a kpl a controller without it being a responder too (I'm fairly certain). To crosslink you must make them both controllers. I may be wrong so don't throw things at me if I am ;)

Your statement is correct about needing to add both devices as (only) controllers in a cross-linked scene. What I was trying to say, however, was that the ISY automatically (and transparently) adds the required responder links in each of those devices in this same situation.

 

So: The ISY only shows the devices as controllers in the cross-linked scene. But the devices themselves each have controller and responder links written to them. Exactly as if you manually cross-linked the two devices in a setup without the ISY.

 

--Mark

Link to comment

ahh... I gotcha - I misunderstood what you meant.

 

So in an example scene

 

Switch A is a controller (non load)

Switch B is in the scene as responder (load)

When you turn A on and off B will turn on and off

When you turn B on or off it will have no effect on A

 

In a second example scene

Switch A is a controlller (non load)

Switch B is a controller (load)

A on or off will reflect in B

B on or off will reflect in A

 

What you were referring to was the responder link in the controller - not the reciprocal arrangement in a crosslinked 3 or n way relationship.

 

I only point this out because when I first got my ISY I came from a powerhome background where you had to write the responder and controller links manually. The first scene I created in ISY worked in a proper crosslinked manner even though one was a controller and one was a responder - this wasn't because ISY did it - it was because I had left over links from powerhome. It confused the bejesus outta me cuz I thought ISY was creating reciprocal links and I was afraid I wouldn't be able to control things in one direction only. Once I reset the switch and wrote only the ISY links to it it then worked as I would have expected.

 

Took me a week or two of scratching my head to figure that one out and I bet I'm not the only one who's come to ISY with a bunch of already crosslinked switches that wondered why they stopped working when the devices got rewritten by ISY with the actual scenes.

 

It becomes far more apparent with items that can ONLY be controllers or ONLY be responders.

 

mark

Link to comment

While I am very new to the ISY, I have used Insteon for a number of years, and much of the discussion in this thread is not consistent with my understanding of how Insteon works.

 

Perhaps someone can tell me where my understanding falls apart:

 

Programs and Scenes are completely different things. Programs execute in the ISY/99i and send Insteon commands (On/Off to scenes or devices) based upon the specified conditions (time, scene or device status, weather data, etc.) If the ISY/99i is not connected or not powered, programs will not run.

 

Scenes exist in the Insteon network, and consist of links between devices. In the case of the ISY/99i, every scene on the Insteon network is store in the PLM's link database. This provides a single place for the ISY/99i to read scene data and to turn scenes on and off. The scenes also exist in the link databases of each device in the scene. Therefore, scenes work without the ISY/99i present or connected, and even without the PLM connected, although controllers will report errors (flash) if the PLM is disconnected, because the PLM doesn't respond in the scene.

 

KPL buttons exist as controllers in scenes. The status light in the KPL button (a really bad idea, IMO) responds to local pushes AND to the on/off of scenes for which they are linked as a controller. There is no Insteon command to turn the light of a KPL button on or off, like you can with a responder (a load). For example, if I setup a scene with a KPL button as the controller and an ApplicaneLinc as the responder, then I can control the ApplicanceLinc with the KPL button. If I turn on or off the scene from the ISY/99i, then the KPL button light correclty reflects the the outcome. However, if I turn on or off the ApplicanceLinc directly, the KPL button light does not respond. The KPL button lights are not tied to the status of the load, they are tied to the scene.

Link to comment
What you were referring to was the responder link in the controller - not the reciprocal arrangement in a crosslinked 3 or n way relationship.

Yes, exactly. I was trying to clarify the ISY behavior in this situation, that one does not have to manually create all the links like you mention is required in powerhome. Those leftover links obviously cause difficulties when transitioning!

 

--Mark

Link to comment

Programs, as you say, exist in the ISY - no ISY, no programs.

 

Scenes do not live in the devices. Scenes live in the PLM.

 

Devices have controller tables and responder tables in them. If A controls B then it will have a record of B as a responder in its responder link table while B will have a record of A in its controller link table. This is why reciprocal arrangements aren't automatic. It's not just a matter of 'you and I are linked'. It's a matter of I control you or I am controlled by you. If you examine the database in any insteon device it has a list of who it controls and who controls it along with associate ramp rates, dim levels, etc.

 

Scenes work by group commands. When devices are grouped as responders to a scene then when a group on or off command is issued all devices that are in that group respond instantly. That's the biggest plus to Insteon imho - is that you can turn off literally hundreds of devices in a blink using a group command.

 

With that said - ISY writes all the records that correspond to a scene into the appropriate devices. So say you create a scene - ISY will give it a number in the PLM - say it's group 35. ISY will then write the links to all the devices so they are responders to group 35. When you issue a group 35 on or off every device that is a responder to group 35 will respond. That's why the ISY doesn't have to be involved in scene control - scenes work with or without the ISY present. What the ISY does is tie the PLM scenes together with its own link table to give you a snapshot view of the on-off state of every device.

 

Another thing is that every device even if NOT in a scene IS part of a scene. It's a member of group 0 of the PLM.

 

The KPL button lights are not 'tied' as you say, to anything. They are merely responders. When you press the button on a KPLit will turn its light on or off according to it's toggle mode and send the on or off command associated with its group number. If the KPL button is a responder to a scene then when the scene is turned on or off the KPL button LED will turn on or off (or dim) accordingly.

 

It's confoozalating, no?

Link to comment
Perhaps someone can tell me where my understanding falls apart:

 

. . .

 

KPL buttons exist as controllers in scenes. The status light in the KPL button (a really bad idea, IMO) responds to local pushes AND to the on/off of scenes for which they are linked as a controller. There is no Insteon command to turn the light of a KPL button on or off, like you can with a responder (a load). For example, if I setup a scene with a KPL button as the controller and an ApplicaneLinc as the responder, then I can control the ApplicanceLinc with the KPL button. If I turn on or off the scene from the ISY/99i, then the KPL button light correclty reflects the the outcome. However, if I turn on or off the ApplicanceLinc directly, the KPL button light does not respond. The KPL button lights are not tied to the status of the load, they are tied to the scene.

 

I think everything you said is consistent with what's been said in this thread (by me, at least), up to your last paragraph quoted above. Your example of a scene with a KPL button and an ApplianceLinc is not a good one in this context, because the ApplianceLinc cannot serve as a controller in a scene. Therefore, it's irrelevant whether the KPL button has a responder link in that scene or not.

 

But it's absolutely true that a KPL non-load button (for relatively recent KPLs, at least) can handle both controller and responder links. And they can easily serve as responder-only devices. I use a number of such buttons in my setup in exactly that capacity, with no problems whatsoever. And that functionality would be severely crippled if the buttons did not light up!

 

--Mark

Link to comment
I use a number of such buttons in my setup in exactly that capacity, with no problems whatsoever. And that functionality would be severely crippled if the buttons did not light up!

 

They work great as indicators too. I have a few that flash to indicate things like garage door left open.

Link to comment

Archived

This topic is now archived and is closed to further replies.


  • Recently Browsing

    • No registered users viewing this page.
  • Who's Online (See full list)

    • There are no registered users currently online
  • Forum Statistics

    • Total Topics
      36.6k
    • Total Posts
      368.1k
×
×
  • Create New...