belias Posted April 14, 2010 Posted April 14, 2010 I'm looking for some advice on controlling scenes from the ISY that involve KPL sub-buttons. Here goes... I have a KPL where a few of the sub-buttons are set up as a controller for other buttons on the same KPL (i.e. in a "scene" type configuration). In other words, I have scenes setup in the ISY with 1 KPL button as the controller, and the remaining 7 as responders. Clicking on the one controller (in red), I can set the status of the 7 remaining(blue) buttons. This works perfectly when standing at the KPL - all devices and sub-buttons work as programmed. The problem comes in with trying to execute this same scene directly from the ISY (either through a program or through MobiLinc, etc.). Given the limitation of not being able to directly control KPL sub-buttons from the top-level scene (i.e. clicking on the scene title next to the scene icon), I end up with the KPL indicators completely out of sync. I'm wondering if anyone has some suggestions for how to deal with this. One thought was to make a program that looked for the status of various lights, and when it matched up with a specified 'scene', then it would adjust the KPL indicators. However, this results in the KPL indicators turning on/off one-by-one as the program runs, and results in a lot of Insteon traffic for 8 buttons; it also runs unnecessarily when I use the KPL to set the scene. Is there some way that's a bit cleaner to accomplish this? Ideally, I'd like the scene as activated by the ISY to behave identically to the scene as activated by a KPL button-press (all indicators change immediately, etc.). P.S. Out of curiosity, why is it that the PLM (or the ISY?) isn't able to directly control KPL buttons? I ask because if I look at a scene with, say, 3 KPL's and 1 SWL, the 3 KPL's can control each other's sub-button status (i.e. on, off). Why can't the ISY simply mimic this action? Judging from previous posts, I realize this is a common issue and I think it's an Insteon limitation...just looking for a bit of clarification in my own understanding... Thank you! - Brian
Michel Kohanim Posted April 15, 2010 Posted April 15, 2010 Hi Brian, Unfortunately I cannot give you any expert advice on the setup. I can only answer your last question: That's precisely what ISY is doing: that's why the KPL has to be in a scene since all those interactions are accomplished via group commands. With kind regards, Michel
oberkc Posted April 15, 2010 Posted April 15, 2010 I thought that one way to "directly" control KPL buttons from the ISY was to create artificial scenes, where in it is only one device (plus the PLM). Create, for example, a scene called KPL-B. In this scene, add button B only. You should then be able to control button B from the ISY (and, I assume, mobilelinc) by controlling the scene. Create such scenes for all buttons for which you desire such control and use the scenes in programs to simulate the action you desire. While I am not sure that it is easy to program the entire response to KPL-control of a scene (dim, bright, double-tap, etc), it may not be too bad to program simple on and off functions. Hopefully, this is responsive to your questions.
belias Posted April 15, 2010 Author Posted April 15, 2010 Thanks for the replies! I didn't do a good job of explaining this one...my apologies... oberkc: You are right - this does work. However, in my situation that means a program would have to run to update each of the 8 KPL indicators every time I change a scene using MobiLinc, etc. The problem is that there's much more flexibility in implementing a scene (involving KPL buttons) when the scene is triggered by a KPL button-press. When the same scene is triggered by the ISY, some of that flexibility is lost and my KPL no longer represents device status correctly. In other words, if I create a scene with all 8 KPL buttons and a few SWL's; I'll set one of the KPL buttons (say Button C) as the controller. Now I can be quite flexible: Clicking on "Button C" in the scene, I can set the SWL's as desired and all 7 KPL buttons to either "On" or "Off" individually. So now when I walk up to the KPL and press "Button C", some KPL indicators turn on and others turn off as programmed, and the SWL's turn on/off as programmed. Beautiful! However, let's say I want to invoke this same scene either through an ISY program or through MobiLinc. Now I lose this control over the KPL buttons - I can either turn them all on or all off. So, now I have a mismatch between what's actually on and what the KPL shows is on. My goal is to figure out some clean way to manage this issue such that the KPL always correctly shows the scene / device status regardless of whether it's invoked by a button-press at the KPL or through an ISY program or by MobiLinc. By "clean" I mean that I'd prefer it to be an instantaneous update with minimal Insteon traffic (hey, I'm wishing here...). I think I have something figured out with a small collection of programs...but I thought I'd throw it out there in case someone else has already done the leg-work. Thanks! - Brian[/b]
Michel Kohanim Posted April 15, 2010 Posted April 15, 2010 Hi Brian, The main issue is this: You cannot send an On command to a scene and have a KPL sub button turn off (as well as the reverse). This problem is not limited to ISY scenes. Consider adding another KPL button from another KPL as a controller. Now, although you can control all the responders within the scene properly but the status of "other" KPL sub buttons is EQUAL to the command sent. That's the crux of the problem and has been an outstanding issue for over 2.5 years. With kind regards, Michel
oberkc Posted April 15, 2010 Posted April 15, 2010 Thanks for the replies! I didn't do a good job of explaining this one...my apologies... oberkc: You are right - this does work. However, in my situation that means a program would have to run to update each of the 8 KPL indicators every time I change a scene using MobiLinc, etc. I disagree. I thought you did a good job explaining this originally. And I agree. I don't think that such a program would be very elegant or efficient. So now when I walk up to the KPL and press "Button C", some KPL indicators turn on and others turn off as programmed, and the SWL's turn on/off as programmed. Beautiful! I was also unaware that there was any way (besides mutually exclusive relationships) to define a scene where turning a controller on would result in a responder turning off. I have found this to be true whether programming scenes in the ISY or manually. It sounds like you have found a way? I assumed that this is a feature of the insteon protocol.
belias Posted April 16, 2010 Author Posted April 16, 2010 Michel: Yes - that's exactly the issue - summed up in far less words than my post! Somehow it's comforting to know that this has frustrated others as well Oberkc: I think it is possible to configure various devices on/off using a single "ON" command from a controller. For example, if you set up a scene with a RemoteLinc as the controller and a few different SwtichLincs as responders, you can then click on the RemoteLinc and adjust the sliders for the various scene devices to any level (including full off). Now press the RL "on" and some devices will turn off while others turn on. Regarding doing this same thing within the KPL, I think the ISY handles this differently. Using the ISY it's possible to create a scene as I described in my previous post where KPL Button-B "ON" can turn off KPL Button-C (they have to be in the same KPL). I think, however, that what the ISY is actually doing is setting mutually exclusive relationships (as you described), but I (as the end user) simple see it as a controller/responder link. I'm a relative newbie to Insteon, so if I got that wrong - please correct me. So far I've come up with a fairly small program set to correct the ISY buttons (using status checks, etc) when the scene is initiated from outside the KPL (i.e. we don't have the advantage of MA buttons). If I can get it working smoothly I'll post my general idea in the how-to section. God knows, I've benefited from enough of other people's work! Thanks, -Brian
Recommended Posts