LeeG

Definitely not normal. When a device is added to the ISY link records are generated which cause the device to send messages to the ISY whenever the device is manually operated. First is powerline communication of good quality. Do devices turn each other On/Off as expected and can they be controller reliably from the ISY. If powerline communication is intermittent then noise or signal attenuation is suspect. If general powerline communication is good but specific device never notify the ISY of state changes either the link records in the device or link records in the PLM have been lost or corrupted. Pick one device that never works, Restore Device to restore the device link records. If that does not resolve the problem Restore Modem (PLM) to restore the PLM link database. EDIT: routine query of devices should not be necessary. It puts lots of traffic on the powerline that can interfere with other activity. Once the issue is identified and resolved devices will rarely if ever be out of sync. If the ISY is not seeing state changes the use of Control will make no difference. If the ISY sees an inbound state change message such that Control would work the device status would be updated. The status is not being updated because the ISY is not seeing the state change messages in the first place.

johnmsch You are making good progress. A basic Scene is an Insteon construct. The ISY makes defining Scenes pretty easy. Actually defining one ISY Scene results in multiple Insteon Scenes being generated under the covers. Any given Insteon Scene can have only 1 Controller. When you define an ISY Scene and add multiple Controllers, the ISY is actually generating multiple Insteon Scenes, 1 for each Controller and 1 additional which has the ISY PLM as the Controller, again all defined under the covers. It is this PLM Controller Scene that is used by Programs and the Admin Console. If you want other devices to turn On/Off in addition to KeypadLinc Secondary button B, these devices must be added as Responders to the Scene. Insteon does not propagate Controller requests beyond the specific Responders. That is, when KPL Secondary button B is turned On by the ISY Scene, the KPL DOES NOT propagate the On request to KPL button B Responders. A Responder does not turn into a Controller when the responder is directed to turn On by another Controller device. This is consistent across the Insteon line. There is a rather old but mostly still applicable insteondetails.pdf document that covers the basics of Insteon. The document is in the public space on insteon.net web site. Lee

johnmsch Sounds like the Scene is defined correctly. A Secondary KPL button has nothing to "adjust" so it may not appear in the Adjust Scene selection list. Use Insteon (rather than Adjust Scene), select Scene name and On or Off. The Scene names are not in collating sequence unless you restart the Admin Console. I defined a new Scene and added a Secondary KPL button as a Responder. My newscene appears at the bottom of the list. Then added an Action to a Then Clause using "Insteon" Set "newscene" "ON" to confirm I had not missed something. On the UDI Wiki in the How-to Guide section, under Scenes is a step by step explanation on Scenes. Lee

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?