Premise KeypadLinc Support
- Thread starter kzboray
- Start date
Motorola Premise
View attachment 1631Kaz,
That's the problem. The posted version doesn't have KeypadLinc 8 support. I quickly added support for the 8 key version, but haven't tested it. It's attached here. Let me know if it works and I'll post a complete update to the downloads area.
-John
That's the problem. The posted version doesn't have KeypadLinc 8 support. I quickly added support for the 8 key version, but haven't tested it. It's attached here. Let me know if it works and I'll post a complete update to the downloads area.
-John
John,
First and foremost Thank You!. I didn't expect you to drop everything today and rework the code just for me. I know this kind of thing is a labor of love, and supporting others can be a real pain. Again thank you.
Second, It works mostly. Version 1.6.2.2 recognized the KeyPadLinc 8 button Model 2486D FW version 1.65 and imported it into Premise adding all 8 buttons automagicly. The status field correctly shows the status of the individual buttons, for buttons 3,4,5,6. Buttons 1,2 7 and 8 are not update. I can control the locally attached load from the InsteonRoot.KeyPadLinc properties page.
Now for the million dollar question? How do I get the status lights on the KeyPadLinc to actually reflect the true state of linked devices. I know that the driver dose not support linked devices, so I'm wondering how you cheat. With normal SwitchLinc I can send a .powerstate = true to all SwitchLincs that are linked and get their local LED's to reflect the actual state of the load. I am wondering how you do this with your 6 button KeyPadLincs.
I added this at my wifes request so that she could turn off any lights in the house that might still be on when we head to bed. If I can't get the KeyPadLincs local LED to indicate the lights that are still on.... well I like the couch but just not that much. Let me know if you have a work around.
Thanks mate.
Kaz
First and foremost Thank You!. I didn't expect you to drop everything today and rework the code just for me. I know this kind of thing is a labor of love, and supporting others can be a real pain. Again thank you.
Second, It works mostly. Version 1.6.2.2 recognized the KeyPadLinc 8 button Model 2486D FW version 1.65 and imported it into Premise adding all 8 buttons automagicly. The status field correctly shows the status of the individual buttons, for buttons 3,4,5,6. Buttons 1,2 7 and 8 are not update. I can control the locally attached load from the InsteonRoot.KeyPadLinc properties page.
Now for the million dollar question? How do I get the status lights on the KeyPadLinc to actually reflect the true state of linked devices. I know that the driver dose not support linked devices, so I'm wondering how you cheat. With normal SwitchLinc I can send a .powerstate = true to all SwitchLincs that are linked and get their local LED's to reflect the actual state of the load. I am wondering how you do this with your 6 button KeyPadLincs.
I added this at my wifes request so that she could turn off any lights in the house that might still be on when we head to bed. If I can't get the KeyPadLincs local LED to indicate the lights that are still on.... well I like the couch but just not that much. Let me know if you have a work around.
Thanks mate.
Kaz
John,
It occurred to me that the reason that buttons 1,2,7 and 8 do not correctly update is because I don't currently have any linked loads on those buttons. So I added a link to button 2 and the .status property correctly updated. Sorry I didn't catch this before my first post.
With that said it seems to be working as advertised.
Kaz
It occurred to me that the reason that buttons 1,2,7 and 8 do not correctly update is because I don't currently have any linked loads on those buttons. So I added a link to button 2 and the .status property correctly updated. Sorry I didn't catch this before my first post.
With that said it seems to be working as advertised.
Kaz
One more thing to consider is that there is "generic" support in the driver for devices that aren't explicitly supported. You simply define a new class using an XML file that inherits from one of the predefined types in the driver. In this case, you could have setup an 8 key keypadlinc by creating a generic class that inherits from the multiswitch controller class, but with 8 keys instead of six. It's documented in the release notes.
Thanks John,
Always good to learn a new trick.
I was still wondering how you by-pass the linked state "feature" for your 6 key KeyPadLincs. I would like to use what ever work around you have in place until there is actual linked object support.
As it is I'm running around everynight turning on lights that are already on just to get the KeyPadLinc in sync with the actual state of things.
Kaz
Always good to learn a new trick.
I was still wondering how you by-pass the linked state "feature" for your 6 key KeyPadLincs. I would like to use what ever work around you have in place until there is actual linked object support.
As it is I'm running around everynight turning on lights that are already on just to get the KeyPadLinc in sync with the actual state of things.
Kaz
Kaz,
I'm not exactly sure what you're asking. The driver does keep Premise in-synch with the state of the keypad. You need to cross-link each keypad button with the PLC manually, then associate the button with a script. In my setup, I actually don't let the keypadlinc directly control a device. I use the keypadlinc to control scripts within premise which in-turn are used to control various combinations of devices.
Hope that helps,
-John
I'm not exactly sure what you're asking. The driver does keep Premise in-synch with the state of the keypad. You need to cross-link each keypad button with the PLC manually, then associate the button with a script. In my setup, I actually don't let the keypadlinc directly control a device. I use the keypadlinc to control scripts within premise which in-turn are used to control various combinations of devices.
Hope that helps,
-John
John,
Thanks for hanging in there with me. I'm probably doing something wrong. Let me explain in a bit more detail what I'm up against and hopefully you can point out the error of my ways.
In this example I have a 3 way switch setup using two cross linked SwitchLinc's. Let's call them SL1 (Master) and SL2 (Slave) for this example.
If I tap the top of the paddle on SL1 three things happen.
1.) The SL1 LED's change from 0% to 100%.
2.) The attached load is powered on to 100%.
3.) SL2's LED's change to 100% mirroring SL1's status.
If I then tap the bottom of SL1 the same sequence occurs in revers, and the load attached to SL1 is powered off.
If I do the same thing to with the SL2 SwitchLinc I get the same results. Tap SL2 on and SL1's LED's change to mirror the status of SL2 and the load attached to SL1 powers on. Exactly what you would expect.
Problem:
If I setup a script in Sys that does a PowerState=True for SL1 this is what happens.
1.) The SL1 LED's change from 0% to 100%.
2.) The attached load is powered on to 100%.
3.) SL2's LED's remain at 0%.
Setting up the KeyPadLinc(KPL) I cross linked the KPL to first SL1 and then to SL2. When I do the cross linking I first hold the top of SL1 for 10sec, then press and hold the 3 key on the KPL for 10 sec. The lights flash and the cross link appears to be working. I then do the opposite cross link. I hold the 3 key on the KPL for 10sec it starts blinking. I then hold the top of SL1 for 10 sec and the KPL 3 key stops blinking. I now do the same process again for SL2.
Now if I tap the KPL 3 key the following happens.
1.) The KPL 3 LED changes to bright.
2.) The load attached to SL1 in powered on to 100%.
3.) SL1's LED's change to 100% mirroring the KPL 3 LED status.
4.) SL2's LED's change to 100% mirroring the KPL 3 LED status.
I can control the load on SL1 from any of the 3 possible locations, SL1, SL2 and KPL. The LED's reflect the correct state of the load attached to SL1.
Problem:
If I now send a PowerState = true to the SL1 SwitchLinc this is what happens.
1.) The SL1 LED changes from 0 % to 100%.
2.) The load attached to SL1 in powered on to 100%.
3.) SL2's LED's remain at 0%.
4.) KPL 3 LED remains dim.
I believed this behavior to be due to the lack of current support for cross linked devices. So as a work around, when I want to power on SL1 I send a PowerState=true to both SL1 and then SL2. This keeps the LED's on SL1 and SL2 in sync. However on the KPL there is no way to send a PowerState=True to the individual keys. So I can't get the KPL 3 LED to transition from dim to bright when the SL1 PowerState is set to true. Help me Obi Wan!
Kaz
Thanks for hanging in there with me. I'm probably doing something wrong. Let me explain in a bit more detail what I'm up against and hopefully you can point out the error of my ways.
In this example I have a 3 way switch setup using two cross linked SwitchLinc's. Let's call them SL1 (Master) and SL2 (Slave) for this example.
If I tap the top of the paddle on SL1 three things happen.
1.) The SL1 LED's change from 0% to 100%.
2.) The attached load is powered on to 100%.
3.) SL2's LED's change to 100% mirroring SL1's status.
If I then tap the bottom of SL1 the same sequence occurs in revers, and the load attached to SL1 is powered off.
If I do the same thing to with the SL2 SwitchLinc I get the same results. Tap SL2 on and SL1's LED's change to mirror the status of SL2 and the load attached to SL1 powers on. Exactly what you would expect.
Problem:
If I setup a script in Sys that does a PowerState=True for SL1 this is what happens.
1.) The SL1 LED's change from 0% to 100%.
2.) The attached load is powered on to 100%.
3.) SL2's LED's remain at 0%.
Setting up the KeyPadLinc(KPL) I cross linked the KPL to first SL1 and then to SL2. When I do the cross linking I first hold the top of SL1 for 10sec, then press and hold the 3 key on the KPL for 10 sec. The lights flash and the cross link appears to be working. I then do the opposite cross link. I hold the 3 key on the KPL for 10sec it starts blinking. I then hold the top of SL1 for 10 sec and the KPL 3 key stops blinking. I now do the same process again for SL2.
Now if I tap the KPL 3 key the following happens.
1.) The KPL 3 LED changes to bright.
2.) The load attached to SL1 in powered on to 100%.
3.) SL1's LED's change to 100% mirroring the KPL 3 LED status.
4.) SL2's LED's change to 100% mirroring the KPL 3 LED status.
I can control the load on SL1 from any of the 3 possible locations, SL1, SL2 and KPL. The LED's reflect the correct state of the load attached to SL1.
Problem:
If I now send a PowerState = true to the SL1 SwitchLinc this is what happens.
1.) The SL1 LED changes from 0 % to 100%.
2.) The load attached to SL1 in powered on to 100%.
3.) SL2's LED's remain at 0%.
4.) KPL 3 LED remains dim.
I believed this behavior to be due to the lack of current support for cross linked devices. So as a work around, when I want to power on SL1 I send a PowerState=true to both SL1 and then SL2. This keeps the LED's on SL1 and SL2 in sync. However on the KPL there is no way to send a PowerState=True to the individual keys. So I can't get the KPL 3 LED to transition from dim to bright when the SL1 PowerState is set to true. Help me Obi Wan!
Kaz
Actually, my son calls me Yoda 
You're right the driver doesn't support this (yet). What I'm thinking about doing is implementing the linked switch concept by creating subobjects under switches with a reference to the switch object that is linked. When the driver sees there are other linked switches, it will set the state of those switches accordingly (both in Premise and the physical device). I've got to find some time to implement this, but does that sound like a workable approach to you?
Thanks,
-John
You're right the driver doesn't support this (yet). What I'm thinking about doing is implementing the linked switch concept by creating subobjects under switches with a reference to the switch object that is linked. When the driver sees there are other linked switches, it will set the state of those switches accordingly (both in Premise and the physical device). I've got to find some time to implement this, but does that sound like a workable approach to you?
Thanks,
-John
Yoda,
Yep it sure does. I was thinking about how to do this and had come to the conclusion that you would have to poll the devices on the net and either fill an array with the know links, or create a DB to hold that information. Then things would of gotten complicated. How often do you poll. How do you track manual changes. ICK! I like your idea better. It means more work during setup but gives a lot of flexibility as well. One other observation, If I send a PowerState on to a "Slave" SwitchLinc the load attached to the "Master" is not powered up, the "Slaves" power LED's change to 100% but that's about it. I know this is a by-product of current design, but I thought I should mention it just in case.
Also when you get to the place where your fiddling with the code, it would be nice to have this compatible with the KeyPadLinc's as well. I know, I know always asking for the world.
I look forward to testing the next release.
Kaz
Yep it sure does. I was thinking about how to do this and had come to the conclusion that you would have to poll the devices on the net and either fill an array with the know links, or create a DB to hold that information. Then things would of gotten complicated. How often do you poll. How do you track manual changes. ICK! I like your idea better. It means more work during setup but gives a lot of flexibility as well. One other observation, If I send a PowerState on to a "Slave" SwitchLinc the load attached to the "Master" is not powered up, the "Slaves" power LED's change to 100% but that's about it. I know this is a by-product of current design, but I thought I should mention it just in case.
Also when you get to the place where your fiddling with the code, it would be nice to have this compatible with the KeyPadLinc's as well. I know, I know always asking for the world.
I look forward to testing the next release.
Kaz
