LeeG

stevehoyt Thanks for the update. It sounds like s few of the Secondary KPL buttons were linked to the load control button. This type of button relationship is established with device configuration settings outside the normal link database. Since the ISY had no record of setting this relationship a Restore did not affect it. The Factory Reset cleared the configuration information. That leaves the unanswered question of how it happened to begin with. Keep an eye on the switches. If the symptom comes back try and identify what the last thing done to the switch (if anything). Something changed the settings in two devices. Just do not know what at present. Lee

See this link. Per the end of the topic it is the same cost either way. Also explains the process of adding the IR feature later. http://forum.universal-devices.com/view ... light=cost

To control a Secondary KeypadLinc button define an ISY Scene and add the Secondary KeypadLinc button as a Responder. From a Program turn the Scene On/Off to turn the Secondary KeypadLinc button On/Off.

The Wait causes the If to be reevaluated. The "and status front door light is off" is no longer True so the remainder of the Then does not run. The standard solution for this type of problem, where the Program changes the If conditions and has a Wait or Repeat is to break it into two Programs. Program1 has the If and Run Then Program2. Program2 has the current Then statements.

jkuzmick I hate to be the one to ask this question, are you sure the Enable Internet worked before. Not all Routers support that technique. Also if nothing changed there should still be Internet access from before. Lee

Did you factory reset the KPL before doing the Restore Device?

It is on the ISY SD card. The log can be offloaded to a file on the computer through the Admin Console (and maybe Telnet, don't remember all the Telnet commands).

Joe I made that mistake often in the beginning. What happens when using Tools | Log? Any prompt messages? What actually happens? Lee

Glad you got it working. The IO Linc can be complex to set up. It is relatively simple when each function is looked at individually but gets complex because the Sensor and Relay can be tied together as you have done with Momentary C. Depends on whether using a NO or NC magnetic sensor and there is a dependency on door Open/Close when using the Set button for configuration with Momentary C. Note the ISY provides configuration support through the Admin Console that allows setting the Trigger Reverse option that affects the door open close versus ON/OFF command response without having to use the Set button on the IO Linc. There can be an out of sync situation after a power cycle. Should just be a matter of cycling the On/Off buttons to get it back in sync. Door may move during the process.

satwar The IO Linc relay reacts differently when commanded with Insteon Direct commands from the ISY Admin Console or Program versus issuing Insteon Group (Scene) commands to the IO Linc Relay. Define a Scene with the IO Linc Relay as a Responder. Send On/Off commands using the Scene rather than the relay node directly. It will then respond as the SmartLinc instructions indicate. Outside the world of Home Automation, all Insteon device to device activity results in Group (Scene) commands so the Smarthome reference information is written in that context. Smarthome does not document how the relay reacts when receiving Insteon Direct commands. Lee

Joe Dunn For this type of debugging I suggest using the Event Viewer. Invoke Tools | Diagnostics | Event Viewer and select Device communications events option from pulldown. Device communications will be traced in the Event Viewer window and can be saved in a file if desired. Lee

apostolakisl The hardware does not react to the beep duration setting. As Insteon hardware evolves over time perhaps it will someday. Lee

The link count by the calculator is an estimate. Identifying the correct number of devices by type and number of scenes is important for the calculator to produce a useful estmate. Also try running the Show PLM Links Table and Count multiple times when there is no Insteon activity on the powerline. If the PLM sees Insteon traffic from devices on the powerline it will result in incorrect link information. The links displayed and counted can by be high or low if Insteon traffic occurs during the activity.

A failing PLM would not explain the majority of the lights turning Off. Sounds more like a very short power interruption that also hung up the PLM.

It would be helpful to have an Event Viewer with Device communications events selected running when a light failed to turn Off. I have seen LampLincs say they turned Off in the ACK response but not actually turn the load Off.

Keeping a spare ISY is overkill IMO. Having a spare KPL and PLM is okay. Depends on how critical a particular device failure would be on day to day living. I have a dozen+ KPLs installed. Should one that is used often in a given day fail I could move one from say the garage or basement. Most companies will ship next day air so a replacement for almost anything can be acquired quickly. When it became clear Smarthome was dropping the 2412S variant PLM I made sure I had a spare as I prefer that variant over the newer alternative. Overall I have found Insteon devices to be reliable. Not as reliable as a simple mechanical switch but what electronic device is. Because Insteon devices are logically linked together a failure of an Insteon device in a 3/4/5 way configuration does not prevent other Insteon devices from working (unless it is the load control device).

seacordean What type of device did not turn Off, SwitchLinc, ICON, LampLinc, etc and is it dimmer or relay? What type of load does the device control, incandescent, CFL, LED, etc and what is the total wattage? Lee

johnnyt I keep a few devices for expanding the system and backup. Does eliminate waiting for a new device to arrive or paying a premium in shipping cost. Down side is Smartlabs is constantly improving devices and adding new features so new devices could be better. A newer device could work against you. Although the ICON devices are speced to support 30 link records many of them actually contained enough memory to support 417 which is the norm for most devices. The latest ICONs I have received have gone back to supporting only 30 link records. The firmware level does not have to match. Interesting question. I’ll be interested to see what others do as well. Lee

Happy to help. I've been using an ISY for more than a year now but have been using Insteon almost from the beginning of Insteon itself. I think you find the ISY a great device from both a reliability and functional perspective. They UDI folks are the best in the business for supporting their product.

brock.travis Linking the SwitchLinc as a Controller with the LampLinc as a Responder is done through an ISY Scene. Define the ISY Scene. Then add the SwitchLinc to the Scene as a Controller and the LampLinc to the Scene as a Responder. The ISY writes link records in the SwitchLinc and LampLinc such that turning the SwitchLinc On/Off turns the LampLinc On/Off directly. This relationship is totally independent of the ISY/PLM once the link records have been written. The ISY also writes link records in both the SwitchLinc and LampLinc so that the Scene can be turned On/Off using an ISY Program or ISY Admin Console. This later activity does require the ISY to be present. If this Scene control is not exercised the ISY/PLM plays no role in the SwitchLinc controlling the LampLinc. When the SwitchLinc and LampLinc are added to the ISY as devices, link records are written in the SwitchLinc and LampLinc so that the ISY is aware of manual SwitchLinc/LampLinc activity. These are the link records I was referring to in my initial post. It is these link records that have to be removed should the ISY PLM be unplugged. Unplugging the ISY PLM is not necessary. Normally this is done by an installer that used an ISY to set up an Insteon installation and then removes the ISY and PLM from the premises. The Scene link records that allow the SwitchLinc to control the LampLinc are stored in the respective devices (standard Insteon stuff). A record of these Scene link records is maintained in the ISY configuration data. The link records that allow the ISY to be aware of manual switch activity are stored in the respective device and ISY PLM (standard Insteon stuff) and a record of the link records is also stored in the ISY configuration information. Insteon device response is the fastest when devices are linked (scenes) to each other directly. The ISY and PLM are very reliable. Over time you will find that the automation capability of the ISY is well worth the exposure of another device failure. I link as many of the Insteon devices to each other as possible as I do not want to be dependent on any HA for basic light control. However, some things such as the use of motion sensors is much more user friendly when taking advantage of the extensive ISY HA capability. Also things such as turning lights On/Off at Sunset/Sunrise, automatically turning Off lights after midnight to insure nothing is accidently left on, etc is well worth the exposure of another device failure. The ISY is an industrial strength device and the PLM is no different than the PLMs that are built into all the Insteon devices. Of course they can fail but it is rare. Lee

brock.travis You can link almost all the Insteon devices without physical access. The exception is the battery operated RF devices such as motion sensors, triggerlincs and remotelincs. These devices sleep to conserve battery power and have to be put into linking mode for the ISY to write link records into them. If Programs are not used the PLM can be removed but there is no need to do that. Unless ISY Programs are used the ISY is not a required element if all activity is done by linking device to device. The problem with removing the PLM is that every device has a link record pointing to the ISY PLM and this has to be removed if the PLM is removed. The ISY does this but it takes some time and is really not necessary. "Can I do all of my programming without any manual linking and use only the INSTEON addresses?" Not sure what you are asking here. If you do not want to link devices you can do all with ISY Programs but then the ISY must be present which seems contrary to one of the initial objectives. Unless you mean by manual linking Set button linking and Set button linking is not to be done anyway. All linking (Scene creation) needs to be done through the ISY. Lee

thruster999, There is something else very strange here. The first link table below is from the device at the time of failure. It has a responder link for device 13:ED:5A This is what I got when I ran the Device Links table for the device that failed 0FF8 : A2 00 13.22.8F FF 1F 00 0FF0 : A2 01 13.EF.5A 51 0A 00 0FE8 : A2 14 13.22.8F FF 1F 00 0FE0 : A2 3B 13.22.8F 51 0A 00 0FD8 : 00 01 13.22.8F FF 1F 01 After the recovery the Device Link Table now has a responder link for device 13:ED:86. Is a different motion sensor being used to control the responder after the recovery than before? Was a configuration change made somewhere along the line that changed which motion sensor used this device as a responder? 0FF8 : A2 00 13.22.8F FF 1F 00 0FF0 : E2 01 13.22.8F FF 1F 01 0FE8 : A2 11 13.22.8F FF 1F 00 0FE0 : A2 2B 13.22.8F FF 1F 00 0FD8 : A2 01 13.ED.96 4C 1A 00 0FD0 : 00 00 00.00.00 00 00 00 Is there some other application involved in your installation besides the ISY that could be manipulating the link records? Since the ISY does not write the device address when updating the responder On Level and Ramp Rate it suggests something else is involved here?

thruster999, I do not know why but it is the same problem as before. The E201..... Controller record is missing from both the responder device and the ISY database since the Compare does not show it as missing. Without that E201.... link record the responder cannot send manual status changes. After completing the recovery process you will find that there is an E201.... link record and the ISY will identify it as Identical which means the ISY now thinks that record should exist. Lee EDIT: I cleaned up the answer regarding where the Controller link record was missing. I noted it was missing from the motion sensor when I first did this post when if fact it is the responder that is missing the Controller record.

Brian Thanks for the great trace. Although at a different place in the process it is the same basic problem. The 2F ALDB ED message response containing the actual link record is labeled as a duplicate record with the original 2F ALDB command then being retried. After the normal 3 tries to access the link database the ISY stops the process. The trace covers both the ISY using I2 trying to reset the link records and the subsequent attempt to write the E201…. Controller for Group 1 link record. Although both sequences actually worked they are considered errors and thus the red ! The Link Management | Advanced Options | I1 Only option may work. Although the SynchroLinc supports only 25 link records with the first record located at 0x00FF, at Set MSB to 0F is likely folded back to 00 as the device has no additional memory. The newer ICON switches that have gone back to the hardware configuration that supports only 30 link records does fold a Set MSB 0F back over to an effective Set MSB 00. That is why the ISY works with the newer ICON devices without having to make adjustments for the minimal memory configuration. If you try the I1 Only option be sure to put it back to Automatic when all the SynchroLinc linking is done. Lee

Michel Nobody is counting. Even the Gods are allowed ONE oops. I was beginning to think I was having another senior moment. Thanks Lee