| Author |
|
judetf
Senior Member
Joined: January 23 2008
Online Status: Offline
Posts: 234
|
| Posted: April 11 2008 at 09:14 | IP Logged
|
|
|
I've read Dave's very thorough details on how macros can't control KPL buttons directly, and I have successfully created his "workaround" to have a PLC Group for every KPL button number (one group per number) and, using ph_insteongroupcu, I can control things just fine.
I have a KPL and Switchlinc (with the load) cross-linked so that, completely independent of PH, the KPL button controls the load and vice-versa. The LED status is always correct, as long as I use either the KPL button or the Switchlinc itself. When the light and KPL LED are on, if I hit the Switchlinc, the light turns off and so does the KPL LED. Excellent!
But here's what I don't get: why can't I use PH to send a single command to the Switchlinc and have both the load and the cross-linked KPL button turn off? When I press the Switchlinc it takes over, turns off the load and turns off the KPL LED. Why can't PH send the same command (in effect) to the Switchlinc? Not being able to do this means that I have to jump through hoops if I want to programmatically turn the light off (and have the LED get updated).
Am I totally missing something, or is that just the way it is?
Thanks
jtf
|
| Back to Top |
|
| |
BeachBum
Super User
Joined: April 11 2007
Location: United States
Online Status: Offline
Posts: 1880
|
| Posted: April 11 2008 at 09:34 | IP Logged
|
|
|
I have the same problem with a 2 way SwitchLinc and was told that basically it is by design of Insteon. So maybe the answer is “just the way it is”. Hopefully Lee or others can enlighten us more on the subject.
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: April 11 2008 at 10:26 | IP Logged
|
|
|
Actually, you can. You just have to do the control using a PLC group rather than a direct command. A direct command is aimed directly at a single unit. When you tell a device to turn on using a direct command, it turns on, sends an acknowledgement that it turned on and thats it. In order for the PLC to control two devices simultaneously (a switchlinc load and a KPL LED), it must do so through a group command with both of those devices within the group.
Ive always thought it a shortcoming of the Insteon protocol that there was no command for the PLC to tell a device (the SwitchLinc in this case) to "control" it's group. This would solve all the problems. The SwitchLinc is already linked to the KPL, the PLC would just tell the SwitchLinc to *turn on* as if it was locally controlled meaning it would turn on it's load *in addition to* sending out it's group command to turn on the KPL. Much cleaner and much fewer groups required.
So, you can achieve the desired effect, it's just as clean as I think it should be. You would need to create a PLC group (giving it an appropriate ID), and then add the SwitchLinc and the KPL as members of the group through the linking screen. I would then probably set the device type of the SwitchLinc to "Control Only" to keep it from showing on the Device Status screen since you would already have the PLC group ID showing on the DS screen. Then, just use ph_insteongroup to programmatically control the two together.
Another, less cleaner option, would be to create a trigger on the SwitchLinc (most likely an Insteon Device Chg trigger) so that anytime it's state changes from on to off or vice versa, you send an individual ph_insteongroupcu command to the KPL to keep the LED in sync. You could then still use the device status screen to control the SwitchLinc as well as normal programmatic direct control of the switchlinc and let the trigger automatically handle any cleanup  .
Hope this helps,
Dave.
|
| Back to Top |
|
| |
grif091
Super User
Joined: March 26 2008
Location: United States
Online Status: Offline
Posts: 1357
|
| Posted: April 11 2008 at 13:43 | IP Logged
|
|
|
As jtf and Pete have discovered and Dave (as always) explained, sending a command to only one device in the group does NOT cause that device to look through its link database and send on subsequent commands to the remainder of the group. In the existing Insteon architecture it would be impossible for a single device to keep track of the group cleanup commands that may or may not have already been sent to other devices defined in the group. Consider a 5 way light circuit (I have 2)with all the devices being cross linked to each other so they all work together correctly when no HA is used. Any of the 5 switches can initiate the ON or OFF and all the status LEDs in all 5 switches stay in sync with the load. Now think about what would happen if devices started to send group cleanup messages within the group without a button/paddle press. It would require the other 4 switches to somehow monitor group commands within the group to know if any or all of the other switches have received their respective group cleanup command for that particular ON/OFF action. An individual device in the group cannot just decide to send group cleanup messages to the rest of the group when it receives a group cleanup. Think of the number of group cleanup messages that would flow when every device in the group starts sending messages to all the other devices in the group. Can only be one Controller operating the group at one time and that is where the button/paddle press occurred. As Dave said, it would be nice for the HA world if there was a command that could be sent to a device directing it to do ALL the things it would normally do if a button/paddle press occurred at that device but none exists that I have ever heard of (and Dave would surely know of it).
__________________
Lee G
|
| Back to Top |
|
| |
judetf
Senior Member
Joined: January 23 2008
Online Status: Offline
Posts: 234
|
| Posted: April 11 2008 at 16:42 | IP Logged
|
|
|
Okay, do I did it the way Dave suggested, and created a new group for the KPL button and the Switchlink...
But now I can't turn the light on to a specific level. (I realize I can do that by setting the level in the group, but that would mean having to create multiple groups for the same light/kpl combo, one for each dim level I want).
I think I understand that to be a limitation of Insteon at this point, so I will live with it (and Lee's description helps to understand how/why), but it's unfortunate.
Regardless, I am now able to do what I want, so that's good!
jtf
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: April 11 2008 at 17:18 | IP Logged
|
|
|
Give my second option a try...it should allow you to set specific settings for the light AND keep the KPL button in sync.
Instead of the group, create an "Insteon Device Chg" trigger on the SwitchLinc light. Trigger ID should be the ID of the SwitchLinc, Trigger ID Number should be 1, Trigger value should be (Any). Set the Boolean field to:
([LOCAL10] = 0 and [LOCAL9] > 0) or ([LOCAL10] > 0 and [LOCAL9] = 0)
Set the Action Type to "Raw Formula" and the Action to:
ph_insteongroupcu("YOUR PLC KPL LED SETTING GROUP ID","YOUR KPL ID",if([LOCAL10] = 0,ioff,ion))
Of course, change the ID's in the formula above to match your actual ID names. Save and you should be good. Anytime the SwitchLinc is turned on, even not full on, but brightened or dimmed or direct to a value other than off, the KPL LED should be on. Dim the SwitchLinc to 0 or turn it off and the KPL LED should go off.
Try it out and let us know how it goes,
Dave.
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: April 11 2008 at 17:22 | IP Logged
|
|
|
Also forgot to mention. While researching the latest Insteon command set tables for another problem, discovered that there is a new extended data Insteon command that does exactly what we'd like. Allow the PLC/PLM to send a command to a device, instructing that device to send one of it's group commands. Dohh!, so they finally gave in and created the command.
The only bad thing is that it is an extended data command so it will most likely ONLY work with the PLM (not the PLC) and will also require the controlling device to be I2 (Insteon 2 or the later firmware devices) capable. Also, I'll have to implement extended command functionality within PowerHome so we've still got a little while before we can start making use of this.
Dave.
|
| Back to Top |
|
| |
grif091
Super User
Joined: March 26 2008
Location: United States
Online Status: Offline
Posts: 1357
|
| Posted: April 11 2008 at 19:32 | IP Logged
|
|
|
Dave, I think you are correct about not using a PLC to send extended messages. Simplehomenet posted an entry on their forum a few weeks back asking for customer feedback. They want to start using extended messages in their software but that would require moving away from the PLC. They already have an EZServ hardware device that supports extended messages (like the PLM) and were looking for input if they required an EZServ rather than a PLC.
__________________
Lee G
|
| Back to Top |
|
| |
judetf
Senior Member
Joined: January 23 2008
Online Status: Offline
Posts: 234
|
| Posted: April 12 2008 at 08:34 | IP Logged
|
|
|
This seems to work great... I've setup a trigger for every KPL/Switchlink cross-link I have, and this control seems to catch everything.
So I'll throw this out for the programmers in the group:
Before I read Dave's precise two posts ago, which rely on the Local variables, I had managed to make it work without using any Local variabls ('cause I didn't know a thing about them), and I'm curious as to feedback. The formula I used seems to respond more quickly than Dave's, but I'm sure there is some downside.
Other than the Boolean and formula, my trigger was as Dave described. I left the Boolean value at 1, and for the formula I used the following (please forgive the DIY nature of my coding):
ph_insteongroupcu("[KPL LED GROUP]","[KPL ID]", int(21-(2*ph_getinsteonstat("GR MID"))))
I found another thread where Dave points out that "the Insteon Device Chg trigger can fire without the level actually changing," which is why he has the Boolean lookup.
My trigger will fire on any change, but what it does is lookup the Switchlinc status at that moment and, using my ingenious math wizardry (ha!), send an ion or ioff as appropriate.
As far as I can tell so far this gives me the results I want. I suppose rational minds could differ on when they want a KPL LED to turn off if a light is slowly dimming. With this code mine turn off when the dimming starts which is arguably not "right," but it serves my purposes.
Anyway, just throwing that out there. For the moment I have a couple with Dave's code and a couple with mine, and if I notice any tangible differences I'll figure out which makes the most sense.
Thanks once again, Dave!
jtf
|
| Back to Top |
|
| |
|
|
Active Topics 
Memberlist 
Search 
Help
Register 
Login
PowerHome Messageboard : PowerHome General
Topic: Cross-linked Switchlinc/KPL - LED status?
