LeeG

Would need a display of the before and after link database to evaluate. The thing about the link database, with all the various changes to Insteon protocols and commands, device features and functions, the format and function of the link database has not changed. Link records have the same format today as they had when the first Insteon device was shipped back in the mid 2000's.

Jumper 2 has no affect when Jumper 5 is installed. This Program needs parens to achieve the correct order of precedence If From Sunset To Sunrise (next day) And ( $sAlarmZ13_GarageDoorHoney is 0 Or $sAlarmZ14_GarageDoorPaco is 0 ) Then Set 'Outdoor / Garage Outside' On Wait 2 minute Set 'Outdoor / Garage Outside' Off Else - No Actions - (To add one, press 'Action') Not sure from the description what the symtom is.

Is this a Relay or Dimmer KPL? I ran my test on an 8 button KPL Dimmer with v.40 firmware. The only thing I can think of now is to Delete the KPL from the ISY. Do a factory reset of the KPL and add it back to the ISY from scratch under 3.3.4.

Run Help | About, verify Firmware and UI both show 3.3.4. If UI (Admin Console) is not 3.3.4 the URL invoking the Admin Console needs to be updated to get the Admin Console to 3.3.4.

Yes, the KPL User Guide describes the process of factory reset. Pull the air gap for 30 seconds. Push it all the way in past the level of the frame for 10 seconds. A Restore Device has to be done after that to restore the device link database.

There could be link database issues but in this particular example things are fine. In earlier images the ISY Links Table display did not display an End Of List record as that is not physically stored in the ISY. This always presented itself as an extra link record in the device because the device hardware/firmware must have an End of List link record to stop a link database search. The simulated End of List record now being display in the Show ISY Links Database is always 8 bytes of zeros. The actual End of List record in the Show Device Links Table often has only a single byte of 00 in byte 1 (flag byte). Depends on the past link record activity in the device itself whether the End of List record is all zeros or only a 00 in byte 1. Thus the possible label mismatch. In 3.3.4 (any maybe some of the earlier 3.3.x images) the End of List mismatch is now labeled [ignored/mismatch] to explain the mismatch in some of the physical data compare is ignored. Bottom line, the last record in the device is a valid End of List link record that must be there. It is not worth the effort but a factory reset of the device to turn the entire link database to all zeros and then a Restore Device will have the End of List records physically match. Really not a necessary step as the device firmware is only looking at the first byte (flag byte) to locate the End of List indicator.

The latest I have is v.40 which does support button B turning On/Off Main A. I'm running 3.3.4. Try a right click on the KPL Primary node, select Diagnostics | Query Insteon Engine. Then set Main A Responder On Level when Button B as Controller is selected to something different to force an update to the KPL. See if Button B will now turn On Main A. The Main A Responder On Level can be set back to 100% On Level. Changing the Responder On Level for Main A is to force a KPL update after running Query Insteon Engine. If that does not work it may be necessary to upgrade to 3.3.4. I don't think v.41 firmware dropped the capability of Button B controlling Main A.

The 3.3.4 release does not have support for the Dual Band KPL Relay device type.

Click the KeypadLinc Primary node in My Lighting tree. Second line in right pane has KPL firmware - v.xx.

What is the KeypadLinc firmware level and what is the ISY firmware level? Edit: what is the Main A or ON button responder On Level when button B node below the Scene name is selected.

The event trace looks fine as far as physical errors are concerned. The message indicating an error is simply the PLM coming out of linking mode after establishing the necessary I2CS authorization link. Happens with all I2CS devices. Two link records were written successfully which is not correct for a KeypadLinc but that is due to the fact that the ISY does not have the 02.44 cat/subcat values in the list of supported devices. Physical communication with the KeypadLinc is very good (Hops Left=2). Just need an ISY release that has the 02.44 cat/subcat so the ISY knows it is a KeypadLinc.

Looks like either go back to 3.2.6 or wait for some future ISY release.

A load connection with the Red wire is not a requirement. Devices in a 3,4,5 way configuration, only one normally is connected to a load. Cap the Red wire. I use an Appliance cord to test new wired devices before installing them. Allows them to be plugged near the PLM to insure they work before installing. That way if they work at the PLM and not at the final location it normally means a comm. issue.

Sure.

The Scene Test fail messages are false. Glitch in 3.3.4. The response from each device in the Scene Test has to be examined to determine if the test was actually successful.

If you go back to 3.2.6 be sure to restore a good 3.2.6 backup as the 3.3.x images made changes to the configuration information which is not backward compatible. In the past a specific Device Type selection would be used. Since this is an I2CS device that may not be possible any more.

It is a 3-way but I understood what the OP was talking about. You will find many technically incorrect references in all forums.

Cannot help with the backup as it looks like a .res file is missing. Has nothing to do with intermittent device communication. Devices that are not responding, KPL buttons which blink some of the time, which indicates the KPL did not get a response from one or more of it responders, all indicate an Insteon comm problem. Look for something new, an appliance, a charger for a cell phone, additional electronics, new noise suppressing power strip, etc. Also run 4 tap Set button test on Access Points to insure coupling is still working.

andyf0 The 2441TH I have is the original v1.0 revision hardware with v.0A firmware. I have heard later units do not react the mine does.

The 3.3.x images depend on the Insteon Engine information being correct because of all the new I2CS support. The Insteon Engine information might not be correct coming from older firmware. Did not bother older firmware without all the new I2CS logic the ISY images now contain.

aLf The Query is correct. There must be a comm issue with the INL location. The Scene Off marks the responders Off assuming they received the Off command. There is no positive device ACK for an ISY Scene. The Query changes the device Status to On which drives the Off Program again. The INL may be turned Off more reliably using a Direct Off rather than a Scene Off. Insteon will retry the Direct Off multiple times.

Pick one of the KPLs (not the 2D version as that and 2A firmware have issues), right click and select Diagnostics | Query Insteon Engine. Try the Backlight adjustment.

Plugging into the PLM (or PLM plug point) was diagnostic. Not meant to be a permanent solution. It means the MorningLinc is working and there a comm problem at its original location.

johnnyt The only I/O Linc commands setting options are for Key Beep Off and Latching Mode

io_guy Is the 12v supply needed in this case. The I/O Linc Sensor is triggered with GND to Sense. Seems like it would only be necessary to connect Smoke or CO Relay Com and NO to I/O Linc GND and Sense.