For the most part you do not want EZServe or any other HA software/firmware involved in basic lighting. Anything that can be done using native Insteon hardware should be done with native Insteon hardware. It is faster and should EZServe be unavailable for any reason, the basic lighting still functions.

Establish the device to device link relationships as you would if using the Tap Set button method. It is just much easier to accomplish with EZServe Scene/link management. When the proper links are established the status LEDs stay in Sync without any intervention from EZServe or any other HA software/firmware. This is the way Insteon hardware is designed to work.

The hardware linking should look like this… (Insteon calls this cross-linking of devices)

KeypadLinc1 – Button D – Controller
OD Front Yard Light – Responder
Entry Way – Responder
KeypadLinc2 – Button x – Responder
KeypadLinc3 – Button y – Responder

KeypadLinc2 – Button x – Controller
OD Front Yard Light – Responder
Entry Way – Responder
KeypadLinc1 – Button D – Responder
KeypadLinc3 – Button y – Responder

KeypadLinc3 – Button y – Controller
OD Front Yard Light – Responder
Entry Way – Responder
KeypadLinc1 – Button D – Responder
KeypadLinc2 – Button x – Responder

I included KeypadLinc2 and KeypadLinc3 for the sake of the example to show how your future KeypadLincs will be linked. When the devices are linked this way pressing Button D (KPL1) or Button x (KPL2) or Button y (KPL3) will control OD Front Yard Light and Entry Way and the other KeypadLinc button LEDs, all without any HA intervention. That is, pressing Button D on KPL1 will turn On/Off OD Front Yard Light, Entry Way. KPL2 Button x LED, KPL3 Button y LED.

To establish the above links/cross links using EZServe define the following…

Scene x
Controllers
KeypadLinc1 Unit 6 (representing button D in six button mode)
KeypadLinc2 Unit x (unit number representing button used on KPL2)
KeypadLinc3 Unit y (unit number representing button used on KPL3)
Responders
OD Front Yard Light LD3 0, (LD1 and LD2 values represent Bright and Ramp Rate values of your choice)
Entry Way LD3 0, (LD1 and LD2 represent Bright and Ramp Rate values of your choice)
KeypadLinc1 LD1 100%, LD2 .1 second, LD3 6 (for Button D in 6 button mode)
KeypadLinc2 LD1 100%, LD2 .1 second, LD3 x (value representing button x)
KeypadLinc3 LD1 100%, LD2 .1 second, LD3 y (value representing button y)

Note that EZServe is neither a Controller nor Responder as once these links/cross links are established by EZServe, you can unplug EZServe and the above device relationships work.

The time base Action at Sunset +15 requires a Scene where EZServe is the Controller and whatever device(s) you want to respond are Responders. The Controller Unit number is your choice for this Scene, just don’t duplicate Unit number usage where EZServe is the Controller. If you want KPL button LEDs to turn On/Off in response to this EZServe Scene add each KPL button as a Responder.

Scene y
Controllers
EZServe Unit 4 (this number is your choice, do not use same Unit number for different scenes)
Responders
OD Front Yard Lights LD3 0, (LD1 and LD2 represent Bright and Ramp Rate values of your choice)
Entry Way LD3 0, (LD1 and LD2 represent Bright and Ramp Rate values of your choice)
KeypadLinc1 LD1 100%, LD2 .1 second, LD3 6 (for Button D in 6 button mode)
KeypadLinc2 LD1 100%, LD2 .1 second, LD3 x (unit number representing button used on KPL2)
KeypadLinc3 LD1 100%, LD2 .1 second, LD3 y (unit number representing button used on KPL3)

The Responders listed in Scene y are whatever devices and KPL buttons that you want to respond to the Scene.

You will not see EZServe in the list of devices as there is nothing to check for EZServe itself. You are checking the state/status of individual devices, which EZServe firmware is keeping track of, but there is no specific state/status of EZServe itself.

Hope this clears up some of the questions. You do not need or want an Action to keep the KPL button LEDs in sync. Once the devices are properly linked/cross linked the Insteon hardware will keep things in sync as the hardware was designed to do. Remember the Insteon devices are designed to work without any HA. Only when you get into the more sophisticated things like controlling devices at certain times of day (Sunset +15 for example) or complex Conditioning is HA stuff needed and very useful. HA does make the process of defining and maintaining the links much easier. You could use the Tap Set button press technique to establish the links/cross links with the same results but it is much easier when doing from the PC.

Sorry, I did not get that you were trying to control multiple KPL buttons on the same KPL. You cannot assign the same device address as more than a single responder to an EZServe Scene. This will have to be done with the SHN Utility or with the Tap Set button process. For KPL secondary button control of the same KPL load there is a process documented in the KPL User Guide to establish this relationship. Of course a KPL secondary button can always control a different KPL button (but only one of a given KPL with a Scene established through EZServe).

You cannot trigger an Action Condition using an EZServe Scene name. Actions are triggered from time based events and/or individual device based events.

To trigger an Action based on a device event that device or device button (KPL, RemoteLinc, etc) must have the EZServe as a Responder. The Group number xx used (11xx, 13xx, etc) is that of the controller device that is triggering the Action. For single button controllers the Group number is always 01. For multiple button controllers such as a ControLinc, RemoteLinc, KPL, it is the Group number used by the respective button. These Group numbers are established by the device itself and cannot be changed. The exception to this convention are the Simplehomenet products which can have a different Group number assigned to the Inputs of many of the devices.

Insteon devices can be assigned an X10 address and that device will respond to an X10 command. To send an X10 command from EZServe an Action will have to be triggered with the Effects issuing X10 commands.

Are you using the HTML interface and what device type is the OD Frontyard Lights as defined to EZServe?

If using the HTML interface, you have to click SAVE on the Condition screen after setting Status and 1106. Then click Back button on Condition screen. After setting (or not) any Effects, click SAVE on the Actions screen. The specific Condition1 must be checked to Enable it as well as the Action is Enabled box before clicking SAVE on Actions screen which is the last interaction with the Action.

That is the problem. A device defined as OTHER does not present “Status” as an option because the nature of the device is unknown. How was the device initially added, as what device type. Once added you cannot change the device type. The device has to be Deleted and Added as what it actually is.

I would not try to modify the Devices.xml file for changing the device type (Cat/Subcat). Each device entry has much more cluster data in V2. Delete the device. When it asks if the device is available, respond NO so that the link database will not be changed. Add the device again specifying the Insteon Address and device type. The device link database will be retrieved as part of the Add process.

If you really want to try manual modification, add a dummy device with the device type in question. Then make the real device entry look like the dummy. Again, I do not recommend this approach.

Adding a device with the Auto Discovery technique requires that EZServe (or whatever HA software/firmware is being used) be aware of the Cat/Subcat values of every device and variant of every device. Smartlabs is changing these values so often now that is nearly impossible to stay up to date. Even HouseLinc2 (Smarthome’s HA software) has not been able keep up to date with current Cat/Subcat value changes and they should know when a new variant is coming before a device every ships. There is a link to a user web site off of one of the Smarthome forum topics that has a list of the various Cat/SubCat values that have been found in the field. For a KeypadLinc Dimmer there are at least four Cat/Subcat variants that have been identified so far.

Once the device is added with the correct device type, “Status” will be an Attribute option.

The “linking” of a KeypadLinc secondary button to the primary button for load control is not done with conventional link records so the SHN Utility cannot be used to establish this. Follow the procedure in the KPL User Guide for this. The relationship is all done with various bits set in the KPL memory, not the link database.

The “local” bright level and ramp rate in effect when the paddle is pressed On is done at the KPL itself. Follow the procedure in the KPL User Guide for this. Basically you set the Bright level and then press the Set button, set the Ramp Rate and press the Set button twice. All of that is from memory and probably wrong and I think it varies depending on whether the KPL is before or after revision 1.5. In theory you can issue Insteon commands to set the various memory locations required to accomplish these settings and then power cycle the KPL to make them active. If these values are established using the procedure described in the KPL User Guide a power cycle is not needed to make them active. The memory map of the KPL varies depending on the revision (last I heard there are 3 different memory maps). This is all considered confidential information which I do not have. Again, follow the procedure in the KPL User Guide that matches the KPL revision level. I think you can configure these “local” values through the Harmony client. The Harmony client is Beta level so this particular capability may or may not be there at present.

A KPL that is responding to a Group command from another controller does not access the “local” bright level and ramp rate information used when the paddle in the responder KPL is pressed. When using the Set button to establish links the bright level and ramp rate in the responder are established first, locked in, then the device is linked as a responder. The bright level and ramp rate that was locked in before the device is linked as a responder is stored in the LD1 and LD2 fields respectively in the “Responder To” link record in the responder device. So, set the LD1 and LD2 values in the “Responder To” link record to whatever values you want. A full Bright level of 100% is LD1=0xFF which is decimal 255. A 90% bright level is LD1=0xE5, decimal 229. This is an approximate value and may have to be adjusted to meet the visual result desired.