LeeG

jlamb Was a device replaced using Rename? There is a Replace xxxx with .... function that does all the work of changing references to the new device automatically. The new replacement device is added first. Then the Replace xxxxx with .... is issued against the old device. The Replace function will list the devices with compatible device types that can replace the old device. Lee

Pull the air gap switch for 30 seconds to power cycle the SwitchLinc. Be careful not to push the air gap switch in too far to avoid a factory reset. Are there other SwitchLincs available to test the LED Brightness button. The LED Brightness button works for my SwitchLinc on 3.1.4. I think you have a problem with that specific SwitchLinc. If the power cycle does not clear the problem suggest discussing with Smarthome support.

richardl007 Thanks, I sure was headed in the wrong direction. That is a Relay SwitchLinc which does not dim. What actually happens to the status LEDs? Under Programs | Summary does the Last Run Time column show the expected time for the Program ? Is the ISY Time displayed in the upper left corner of the Admin Console the correct time ? Please post the Program . Lee

richardl007 Do you mean the KeypadLinc LED background level or sending Off commands to each button to turn the button LED Off. If the later is it the Load button or Secondary buttons that do not turn Off? What is the KeypadLinc firmware level and the ISY firmware level? Lee

grossmd Divide and conquer. Can devices be manually controlled consistently and reliably through the Admin Console. If so that tends to clear a new powerline problem. If reliable manual device control exists then the PLM may have lost it link database. Link records in the PLM are necessary for device status changes to be seen by the ISY. Do a Tools | Diagnostics | Show PLM Links Table. When the Show is complete click on the Count button. How may links are counted and how many Insteon devices are installed. How many are KeypadLincs. Lee

Michel It is the exception path where the IOLinc Sensor node is already assigned as a Controller of Scene 1 and the Sensor is added to Scene 2. The popup message is displayed indicating the Sensor is already a Controller of a different Scene, do you want to add the Sensor as a Responder. This is on 3.1.4. If the same test is run using a ControLinc or RemoteLinc (Controller only nodes) it displays a popup that says the button is already a Controller in a different Scene and does NOT give the option to add as Responder. Just need to add the IO Linc Sensor node type to the check ahead of the popup decision and issue the message that does not give an option to add as a Responder when an IO Linc Sensor node. Lee

That would be a waste of Scenes. It is consistent in that from an ISY Program or Admin Console, Direct device commands only control that specific device. Perhaps the difference that is not obvious is that at the specific device, there is no option, a button/paddle press is ALWAYS using a Scene. There is no way at an individual device button/paddle press to issue a Direct command for individual device control. Only from a Program or the Admin Console or phone application (essentially same as Admin Console) do you have a choice of individual device control with a Direct device command or control all devices by controlling the Scene. EDIT: to be clear, the differences between a Direct command and a Scene command are not arbitrary ISY choices, this is the way Insteon works. I think as more and more Programs are created the flexibility of using Direct or Scene commands will looked at as a positive of Insteon rather than an inconsistency.

Thanks for documenting the situation. This is a glitch in the Scene GUI. It should not have allowed the I/O Linc Sensor node as a Responder.

I'm going to step aside on this one. There may be a simple solution but with the information posted I am not able to determine even what situation actually exists, let alone what was done to get it that way. I believe it would be a mistake to try and correct this by manually editing the ISY files. It is easy to delete the physical link record in the device but so long as the ISY believes it should be there it will come back. The I/O Lincs automatically notify the ISY of any Sensor state change. Relay state changes should only be made by ISY Programs or Scenes the ISY has created. If done this way the ISY will know the state of the Relay as well (unless using Momentary mode). Eliminating this particular link record does not begin to address the symptoms mentioned (ISY not being aware of state changes, Scenes needed to be aware of I/O Linc state). There are other link record problems or communications problems where the I/O Lincs are installed. Good luck.

An I/O Linc was deleted from the ISY, added to the ISY as a new device and when the add completed it has a responder link for 17.78.CF? Is that really all that was done.

The link record circled in red is a Responder link record. I/O Linc 15.B8.5D relay will respond to commands from device 17.78.CF. This link record does not control another device. To prove this remove all wires (Sensor and Relay) connected to 15.B8.5D. Tap the Set button on 15.B8.5D. No other I/O Linc will be affected by the Set button tap. Only link records which start with E2 control other devices. The only E2 link record in 15.B8.5D is the one pointing back to the ISY PLM 14.83.D8 which allows ISY to be aware of input Sensor state changes.

If the action of the “bad†I/O Linc relay controls a circuit that leads to the Input Sensor changing state then seeing the “bad†I/O Linc Show Device Links Table output along with the Show Device Links Table output from two other I/O Lincs that are responding will show any linkage between the devices. If this information is posted identify the Insteon address of the “bad†I/O Linc, the other I/O Lincs displayed as well as the ISY PLM. Just read the last series of posts. Suggest posting each of the I/O Linc Show Device Links Table output.

This is a change in the way the ISY is defining a Scene where the I/O Linc Relay is a Responder. Scenes which I defined during the middle 2.8.x images were defined with 100% On Level FF 00 00. A Scene I created under 3.1.2 was defined with 0% On Level 00 00 00. It was 0% regardless of the On/Off state of the Relay under the Admin Console. Not sure which image changed this. I would have thought the 100% On Level as a default would have been better. Most are expecting the On command to turn On the Relay. At least it is now understood it changed the next time the question comes up. Thanks for posting back your answer. I thought I lost a post also (not this topic) and another user made a similar comment. I added a post to the New Forum topic documenting the possibility of a problem in this area.

dsegneri Below the ISY Scene name, select the KeypadLinc button (should be red entry) and look at the On Level displayed for the I/O Linc Relay. This should be 100% for a Scene On to turn the Relay On. If it is 100% then we need to know what the Show Device Links Table shows for the A2 entry in the I/O Linc. It should be FF 00 00 if the On Level is showing 100%. Lee

“I understand that the IOLinc relay cannot be a controller in a scene, only the sensor.†This is correct. The KeypadLinc button is the Controller, the I/O Linc Relay is the Responder. When the KPL button is pressed On the Relay turns Off. This is opposite to what the user wants and is opposite to what an ISY Scene normally does. “then I am thinking that the "trigger reverse" option in the IOLinc configuration could be the solution.†The Trigger Reverse option reverses the On/Off commands issued by the input Sensor. Normally when the Sensor turns On the I/O Linc sends an On command. With Trigger Reverse set an Off command is sent when the input Sensor turns On. Either there is a situation where the ISY Scene create is setting LD1 (On Level) to a 00 value when the I/O Linc is a Relay or the OP has changed the On Level for the Responder when the KPL is the Controller. All ISY Scenes I have created where the I/O Linc Relay is a Responder the On Level (LD1) is set to FF. This will cause the Relay to turn On when an On command is received (what the user wants).

oberkc I do not think the I/O Linc Set Options has an option that controls how the I/O Linc Relay responds to On/Off commands. dsegneri Under Tools | Diagnostics | Show Device Links Table, display the I/O LInc link database. The last three bytes of the link records for the Relay (link records start with an A2 for the Relay) determine how the Relay will respond. A 00 00 00 in the last three bytes has the Relay turn Off with an On command and On with an Off command. A FF 00 00 in the last three bytes has the Relay turn On with an On command. I did not think the ISY would write anything but a FF 00 00 link record. You can get other results if you play with the On Level and Ramp Rate values for the Scene but these should not be changed for an I/O Linc. Lee

Is the Relay in Latching mode or Momentary mode? If Momentary mode which mode? From the I/O Linc User Guide … “An ON command can be programmed to either open or close the relay; an OFF command will do opposite. For example, if the relay is programmed to open in response to an ON command, an OFF command will close the relay.†I did not think this mattered when establishing an ISY Scene.

Issuing a Replace xxxx with against the old KeypadLinc should have resulted in all the affected link records being updated and the new KeypadLinc definition being removed. There may have been Green Icons next to some of the nodes indicating pending updates because communication problems existed for the reasons you described. I'm not familiar with Load/Save as the ISY is very good at managing link records. You are the only person I can remember trying to manually change link records. Restore Device and/or Restore Modem (PLM) normally resolve link record problems. I'll see what I can determine through some testing on this end.

Did you issue the Replace xxx with …. against the old KeypadLinc node or the new KeypadLinc node. It sounds like the Replace was done against the wrong node.

After the link records have been cleaned up, if there is still unexpected interaction between the I/O Lincs, please describe the situation with some additional detail. What is the actual interaction between the I/O Lincs? Relays turning On uncommanded, input Sensor changing state, etc If it is Relays turning on uncommanded does a Query indicate the Relays are On? What I/O Linc options are in effect? Latching mode versus Momentary mode, Relay follows Input, Trigger reverse, etc. Are the I/O Linc Relays controlled with Direct commands from an ISY Program (no Scenes)? How/what are the input Sensors connected to? How/what are the Relays connected to?

"A responder link for an IO Linc?" A Responder link record in an I/O Linc is associated with the Relay aspect of the I/O Linc. The Controller (with Insteon address 17.78.CF) sends a Group 1 On/Off command and the I/O Linc containing the Responder link record will turn the Relay On/Off in response. Depends on the Relay mode (latching, versus momentary) what the relay will actually do. With the last three bytes of the posted link record being 00 00 00, and the last three bytes of link records the ISY wrote to my I/O Linc being FF 00 00, I conclude the link record was created by the Set button method. "(I have to query them for ISY to know they changed.) " An I/O Linc that is not sending an indication to the ISY that the Sensor has changed state has a link record problem. Either missing or corrupted in the I/O Linc or missing or corrupted in the ISY PLM. This link is established when the I/O Linc is added to the ISY. With an indication that a link was established with the Set button in one of the I/O Lincs it sounds like a Set button link is in conflict with what the ISY established. "One, the other IO Lincs would react to my pushing the set button, which is inconsistent with the behavior of an IO Linc" If other I/O Lincs are reacting to the relay activity of one I/O Linc it might be the way the I/O Lincs are wired rather than being commanded to do so. There is so much wrong, link record that should not be there, I/O Linc not reporting a Sensor state change, I suggest deleting the I/O Lincs, Factory reset the devices, add them back to the ISY and DO NOT connect the wiring to any of the relays. Verify that the ISY sees the Sensor state change of all the I/O Lincs. Then verify that turning the Relay on one of the I/O Lincs does or does not have an effect on any of the other I/O Lincs. If things work correctly, connect the Relays and see what happens.

"The (sole) record is A2 01 17.78.CF 00 00 00 in both other devices." This is a Responder link record. It means the device containing this link record will respond to a Group 1 On/Off command from 17.78.CF. If 17.78.CF is the Insteon address of an I/O Linc, Group 1 is the input Sensor. The I/O Linc containing this link record will respond to the I/O Linc input Sensor with the Insteon address of 17.78.CF. If all else fails, delete the I/O Linc, perform a Factory Reset on it, add it back to the ISY.

From an earlier post on the same subject The SP version is SmartHome PRO version. I am not entirely sure what the difference is. For ISY, we consider both the same. With kind regards, Michel EDIT: the PRO line is available to professional installers only. Smarthome has a number of devices that are available only to the professional installer. One example was the Venstar thermostat with the Insteon adaptor integrated into the thermostat. This device was just recently made available to the DIYer.

This is normal for an RF device. Motion Sensors, TriggerLincs, RemoteLincs send multiple Group Broadcast messages. The second Group Broadcast is labeled "Duplicate", the third is labeled "failed". It reflects the existence of multiple Group Broadcast messages. If it were not an RF device something would be wrong. Ignore it for an RF device. Sun 06/19/2011 16:59:15 : [iNST-SRX ] 02 50 11.AE.4B 00.00.02 C7 13 00 LTOFFRR(00) Sun 06/19/2011 16:59:15 : [standard-Group][11.AE.4B-->Group=2] Max Hops=3, Hops Left=1 Sun 06/19/2011 16:59:15 : Duplicate: ignored Sun 06/19/2011 16:59:15 : [iNST-SRX ] 02 50 11.AE.4B 00.00.02 C7 13 00 LTOFFRR(00): Process Message: failed Some RF devices issue 2 Group Broadcast messages, some issue 3 as in this case.

Glad to hear the problem is resolved. As an FYI, the Set button sequence used on the Access Points does not do any setup or configuration in the Access Points. It simply provides a visual indication the Access Points hear each other over RF and they are on opposite 120V legs. Is a good test as it could have been the other Access Point but the test is not necessary to configure the Access Point.