Insteon: Add Ability to Set Follow and Off Masks for KeypadLinc Buttons

[krkeegan]

Follow mask, whenever button B is on button A also turns on.

Off mask, whenever button B is on button A is off.

These are not stored in the link table or set with normal linking commands.

Instead these appear to be set by the extended get/set 0x2E command.

[krkeegan]

Sending the command 026211E2BE1f2e000500000000000000000000000000 to my KPL should cause the KPL to respond with a data packet describing all of its extended bits. Unfortunately, I get nothing in response. This may be because my KPL is an old i1 device.

This may complicate my ability to add this feature.

edit Sorry I meant to say my KPL is an i1 device.

[drippsb]

I'd like to help with this. Two questions:

How would I send "the command 026211E2BE1f2e000500000000000000000000000000 to
my KPL"?

Is there public documentation on these mask commands?

Thanks,
Bill

On Sat, Nov 23, 2013 at 7:03 PM, Kevin Robert Keegan <
notifications@github.com> wrote:

Sending the command 026211E2BE1f2e000500000000000000000000000000 to my
KPL should cause the KPL to respond with a data packet describing all of
its extended bits. Unfortunately, I get nothing in response. This may be
because my PLM is an old i1 device.

This may complicate my ability to add this feature.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/325#issuecomment-29145135
.

[krkeegan]

The best public documentation of the commands is here:

http://www.madreporite.com/insteon/commands.htm

You are interested in the "2E" commands.

You will also probably want to review the PLM modem developers guide so you can understand how messages are formatted for the PLM.

http://www.smarthome.com/manuals/2412sdevguide.pdf

Finally, to send raw commands straight to the PLM you can use the lib/Insteon/PLMTerminal.pl script. Instructions are included in the script.

[drippsb]

Kevin,

One further question. You wrote, "my PLM is an old i1 device." How can I
tell what kind of device my PLM is?

Thanks,

Bill

Bill Dripps
814-234-7975 ext. 531
www.dm.org drippsb@dm.org
365 Science Park Road, State College, PA 16803-2215

[krkeegan]

Sorry, I corrected that to say my KPL is an old i1 device. You can check this with "get_engine_version."

[drippsb]

Great! That has a voice command so I don't have to write code. All my KPL's
are i1 as well. Thanks.

On Sun, Nov 24, 2013 at 2:45 PM, Kevin Robert Keegan <
notifications@github.com> wrote:

Sorry, I corrected that to say my KPL is an old i1 device. You can check
this with "get_engine_version."

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/325#issuecomment-29163941
.

[krkeegan]

Ahh, ok well you are in the same boat as me then. I doubt the i2 commands that are documented will work for setting our KPLs.

When I have some free time I will try and see how/if Houselinc is able to do this for i1 devices. I caution, that it just may not be possible to set from the software for these older devices.

[drippsb]

Kevin,

On Sun, Nov 24, 2013 at 1:41 PM, Kevin Robert Keegan <
notifications@github.com> wrote:

The best public documentation of the commands is here:

http://www.madreporite.com/insteon/commands.htm

You are interested in the "2E" commands.

Ah yes. I remember that site now. It's very helpful.

You will also probably want to review the PLM modem developers guide so
you can understand how messages are formatted for the PLM.

http://www.smarthome.com/manuals/2412sdevguide.pdf

That's helpful as well. I just noticed that Smarthome seems to have
renumbered the Keypadlinc Dimmer to 2334-222 from 2486d. I hope that
doesn't mean incompatibilities.

Finally, to send raw commands straight to the PLM you can use the

lib/Insteon/PLMTerminal.pl script. Instructions are included in the script.

I finally got that to work. I have to run the program in the same directory
as the program. (There's probably some way to fix that in perl, but it's
not critical.) Then I needed to install "perl-TermReadKey" from Fedora and
it works great. I do have to stop misterhouse, I'm hoping to get a windows
box set up with a different PLM for experiments.

In any case I think I'm able to duplicate your results at this point.

Thanks,

Bill

Bill Dripps
814-234-7975 ext. 531
www.dm.org drippsb@dm.org
365 Science Park Road, State College, PA 16803-2215

[drippsb]

Kevin,

On Mon, Nov 25, 2013 at 6:07 PM, Kevin Robert Keegan <
notifications@github.com> wrote:

Ahh, ok well you are in the same boat as me then. I doubt the i2 commands
that are documented will work for setting our KPLs.

I'm sure they will not, but don't the i1 devices have more primitive
commands that can eventually accomplish the same purpose? I have a vague
memory that while i2 devices have commands to read or write a whole link or
flags or masks, the i1 devices have to work one byte at a time. My hazy
memory is that the documentation is a little light on the i1 commands for
flags and masks.

When I have some free time I will try and see how/if Houselinc is able to
do this for i1 devices.

That would be great!

I caution, that it just may not be possible to set from the software for
these older devices.

You may be right, or it may be too much effort for too little return.

Thanks,
Bill

[krkeegan]

The i1 devices do have a more primitive command set that you describe. However, not all i2 features are available in an i1 form. Given the complexity of the commands at issue here, I am trying to avoid being overly optomistic.

[drippsb]

That makes good sense. Thanks for your work.

Thanks,
Bill

On Tue, Nov 26, 2013 at 5:10 PM, Kevin Robert Keegan <
notifications@github.com> wrote:

The i1 devices do have a more primitive command set that you describe.
However, not all i2 features are available in an i1 form. Given the
complexity of the commands at issue here, I am trying to avoid being overly
optomistic.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/325#issuecomment-29340021
.

[krkeegan]

Good news, I made some progress on this. Part of the problem is that my KPLs are i1 versions. The method for dealing with this looks like it will depend on the version number.

for i2 devices, it looks like the relatively simple 0x2E commands can be used. Of note these instructions from madreportite.com

D1: 0x00-0xFF Button/Group number, D2 0x00 for data request (D3-D14 0x00) 
D1: 0x00-0xFF Button/Group number, D2 0x01 for response, D3 button's LED-follow mask, D4 button's LED-off mask, D5 button's X10 house, D6 button's X10 unit, D7 ramp rate, D8 on-level, D9 global LED brightness, D10 non-toggle bitmap (0 = toggle, 1 = non-toggle), D11 button-LED state bitmap (0 = off, 1 = on), D12 X10-All bitmap (0 sends X10 on/off, 1 sends X10 All-on/All-off), D13 button non-toggle on/off bitmap (0 if non-toggle sends Off, 1 if non-toggle sends On), D14 button trigger-all-link bitmap (0 send normal, 1 send ED 0x30 Trigger All-Link Command to first device in ALDB).   KeypadLinc
Set LED-Follow Mask for button: D2 0x02, D3 bitmap (0 = not affected, 1 = associated button's LED follows this button's LED)     
Set LED-Off Mask for button: D2 0x03, D3 bitmap (0 = not affected, 1 associated button's LED turns off when this button is pushed).  
Set Non-Toggle State for button. D2 0x08, D3 0x00 for toggle, 0x01 for non-toggle.   
Set Non-Toggle On/Off State for button. D2 0x0B, D3 0x00 send off, 0x01 send on.     

For i1 devices, I had to reverse engineer the EEPROM memory locations. This is what I found:

0x0241 = Button 1, Enable Follow/Off Mask for Button.  The value stored in the location is the bitmask of the affected buttons.  So 03 to affect group 1 & 2.
...
0x0248 = Button 8 Same thing.

0x0249 = Enable Non-Toggle Mode set affected buttons in bitmask to 1.  So 0C is for group 3&4.

0x024A = Button 1, Follow/Off Mask type.  0=Follow, 1=Off.
...
0x0251 = Button 8 Same thing

0x0252 = Set non-toggle mode. 0=Off, 1=On

After all of this you need to send message type 0x24 to cause the KPL to re-read the EEPROM.

With this data, I should be able to code this up to work. I will caution it is going to be a confusing setting, it is confusing by nature there is no way around it.

[drippsb]

This is wonderful. I appreciate that it's inherently confusing. I'm hopeful
that long term we may be able to clarify things.

I'm keeping in mind your suggestion that I keep my expectations in check,
but this excellent progress does bring a couple of questions to mind. I
don't expect immediate answers, but I'll write them here so they aren't
forgotten.

Could read_table_A declarations be written for these flags?
Could mh read the current state of a KPL's flags like it does for links?
Could mh keep an "in memory" copy of the flags like it does for links?
Could these things also be done for the KPL "global" flags? (backlight
dim/bright/off, 6 or 8 button)

Again, your work on this is much appreciated.

Thanks,
Bill

[krkeegan]

Bill, last night I successfully set IntraDevice Links (my new name for
these things) on my i1 KPL using MH, it worked well. I still need to:

• Add the same support for i2 devices (shouldn't be too much work)
• Add support for toggle/off/on button types. (These are stored in close
  proximity to the IntraDevice Links, so we might as well add the support now)
• Add the voice commands (should be easy)

On Thu, Mar 6, 2014 at 8:08 AM, drippsb notifications@github.com wrote:

Could read_table_A declarations be written for these flags?

So, for the IntraDevice links I actually used the SCENE_MEMBER definition.
MH will ignore IntraDevice links during the normal Sync/Delete Links, but
a seperate Sync IntraDevice Links voice command on KPLs will look
specifically for these and sync them. To define a Follow link simply set
the on level to 100% and to define an Off set to 0%. This was everyone's
natural inclination, so it should work well.

Could mh read the current state of a KPL's flags like it does for links?

It could. I wasn't planning on doing this though.

1. Due to the nature of how they work, there is no distinction between
   syncing the IntraDevice links and deleting orphans, they have to be done
   together.
2. One of the reasons for the Scan of the regular links is that they can be
   easily changed on the device. IntraDevice links are unlikely to be
   manually changed.
3. Scanning is needed for regular links to make sure we don't overwrite a
   memory address. The IntraDevice links have defined locations, so we don't
   need to worry about that.
4. Syncing all of the IntraDevice links doesnt take very many messages. At
   most 33 messages. For comparison a regular link takes 17 messages just to
   sync one.
5. Debugging can already be done by examining the messages themselves. Not
   very user friendly, but once we finalize the code, there really shouldn't
   be any room for variation, or need to even debug at this level.

I will think about it, but I am not sure it is needed. Can you articulate
a use case in which it would be needed? (Please don't take my comments as
argumentative, I am just trying to limit the number of "user options" to
make things easier in MH)

Could mh keep an "in memory" copy of the flags like it does for links?

Again it could, but I am not sure if it is needed. MH's cached version is
really whatever you have written in your SCENE_MEMBER definitions.

Could these things also be done for the KPL "global" flags? (backlight
dim/bright/off, 6 or 8 button)

Not sure what you mean here. Do you mean creating a definition in
read_table_a? Or do you mean scanning the status of this setting?

[drippsb]

Kevin,

On Thu, Mar 6, 2014 at 1:19 PM, Kevin Robert Keegan <
notifications@github.com> wrote:

Bill, last night I successfully set IntraDevice Links (my new name for
these things) on my i1 KPL using MH, it worked well.

Wonderful.

I still need to:

• Add the same support for i2 devices (shouldn't be too much work)
• Add support for toggle/off/on button types. (These are stored in close
  proximity to the IntraDevice Links, so we might as well add the support
  now)
• Add the voice commands (should be easy)

Great.

On Thu, Mar 6, 2014 at 8:08 AM, drippsb notifications@github.com wrote:

Could read_table_A declarations be written for these flags?

So, for the IntraDevice links I actually used the SCENE_MEMBER definition.
MH will ignore IntraDevice links during the normal Sync/Delete Links, but
a seperate Sync IntraDevice Links voice command on KPLs will look
specifically for these and sync them. To define a Follow link simply set
the on level to 100% and to define an Off set to 0%. This was everyone's
natural inclination, so it should work well.

Better and better. An "audit" version of that IntraDevice sync links would
be helpful as well.

Could mh read the current state of a KPL's flags like it does for links?

It could. I wasn't planning on doing this though.

I've left out your numbered comments below. They were very convincing. But,
they also made clear that I have not been clear.

I will think about it, but I am not sure it is needed. Can you articulate

a use case in which it would be needed? (Please don't take my comments as
argumentative, I am just trying to limit the number of "user options" to
make things easier in MH)

Thank you for your gracious response. Please allow me to approach this from
another angle.

The normal use case is that a user sets up mh via the .ini and .mht files.
The user gets a few devices working and finds that mh and Insteon is
arguably the best home automation solution. The user adds more devices and
all is well. mh could always be improved, but currently handles this use
case very well.

There is another use case, perhaps not as common. The use gets a few
Insteon devices (or X10) and gets them working manually or with software
other than mh. The user looks for a better solution and finds mh. It would
significantly reduce the barrier to switching to mh if mh could read his
current set up from his working devices and generate a .mht file to start
with. (I realize the names of the devices would have to be entered
manually, but having the rest would be very nice.) I understand perfectly
if this is too much. I suggest it because it might help win more users and
hopefully more developers. Again, I am very appreciative of all that's been
done over the last couple of years and my expectations are well moderated.
:-)

I mention this for two reasons. First, I have seen comments from newbies
along these lines. Second, I have experienced it myself with the
IntraDevice links and other flags. I needed these capabilities and mh did
not support them. So, I manually programmed the devices. I'm delighted that
you've been able to make progress on them and am looking forward to getting
this in my .mht file. I also thought that it would be nice if mh could read
the flags I've set manually and write them in .mht format. I further
realized that newbies might feel the same way. Now, please don't do this
for me. Once you've got the IntraDevice links working, I'm ready to add the
appropriate SCENE_MEMBER definitions and test them out. But, please do
consider if this might make sense to help newbies and what might be an
appropriate place for it on the giant list of enhancements.

Could these things also be done for the KPL "global" flags? (backlight

dim/bright/off, 6 or 8 button)

Not sure what you mean here. Do you mean creating a definition in
read_table_a? Or do you mean scanning the status of this setting?

I do need to work on clarity. The answer is, yes, both. This is really a
different situation connected only by the use of flags. Here's the deal. I
have at least one six button KPL that I have made into an eight button by
swapping faceplates. Every few months we get a power blip that knocks it
offline - no lights - no response - appears dead. The only way I have found
to bring it back to life has been a factory reset. (Which is better than
not coming back to life.) When I do that all flag setting are gone. It
would just be nice if all links and flags were in the .mht file and I could
have mh read the devices memory and then sync it with the .mht file. This
process works wonderfully for normal links. Link management is IMHO the
best feature of mh. I'm just wondering if we can extent that to other flags
as well?

Thanks,
Bill

[krkeegan]

On Sat, Mar 8, 2014 at 10:17 AM, drippsb notifications@github.com wrote:

Better and better. An "audit" version of that IntraDevice sync links would
be helpful as well.

Could mh read the current state of a KPL's flags like it does for
links?

I think I over looked the value of an "audit" command. Users may not
always understand how to properly draft the Scene Definitions. It would be
helpful if they could see how their changes will affect the KPL before they
are implemented. Let me look into adding an Audit command.

It would
significantly reduce the barrier to switching to mh if mh could read his
current set up from his working devices and generate a .mht file to start
with.

All of your points are very valid, and I can certainly see the value in
something like this, but it would be a very complicated beast to craft a
routine that creates an initial MHT file. It isn't impossible. I will
start a separate issue for this so that we can hash out what something like
this would look like.

Could these things also be done for the KPL "global" flags? (backlight

dim/bright/off, 6 or 8 button)

Not sure what you mean here. Do you mean creating a definition in
read_table_a? Or do you mean scanning the status of this setting?

I do need to work on clarity. The answer is, yes, both. This is really a
different situation connected only by the use of flags.

Yes your issue is certainly annoying. In the short term, you could create
a voice command that calls the necessary routine. Then when you reset the
device, you just need to locate the voice command in the web interface.

Your issue speaks to a broader problem that I mentioned a few weeks back.
I am going to start another issue for this as well.

[drippsb]

Wonderful. MH continues to make excellent progress. Thanks so much for your
efforts!

On Mon, Mar 10, 2014 at 2:33 PM, Kevin Robert Keegan <
notifications@github.com> wrote:

On Sat, Mar 8, 2014 at 10:17 AM, drippsb notifications@github.com wrote:

Better and better. An "audit" version of that IntraDevice sync links
would
be helpful as well.

Could mh read the current state of a KPL's flags like it does for
links?

I think I over looked the value of an "audit" command. Users may not
always understand how to properly draft the Scene Definitions. It would be
helpful if they could see how their changes will affect the KPL before they
are implemented. Let me look into adding an Audit command.

It would
significantly reduce the barrier to switching to mh if mh could read his
current set up from his working devices and generate a .mht file to start
with.

All of your points are very valid, and I can certainly see the value in
something like this, but it would be a very complicated beast to craft a
routine that creates an initial MHT file. It isn't impossible. I will
start a separate issue for this so that we can hash out what something like
this would look like.

Could these things also be done for the KPL "global" flags? (backlight

dim/bright/off, 6 or 8 button)

Not sure what you mean here. Do you mean creating a definition in
read_table_a? Or do you mean scanning the status of this setting?

I do need to work on clarity. The answer is, yes, both. This is really a
different situation connected only by the use of flags.

Yes your issue is certainly annoying. In the short term, you could create
a voice command that calls the necessary routine. Then when you reset the
device, you just need to locate the voice command in the web interface.

Your issue speaks to a broader problem that I mentioned a few weeks back.
I am going to start another issue for this as well.

Reply to this email directly or view it on GitHubhttps://github.com//issues/325#issuecomment-37217418
.