LeeG

The last Show Device Links Table that came from a KeypadLinc looks like something that would come from a SwitchLinc. The Show Device has no E2 links for anything beyond the load control button. Also the Output Unit Number in the A2 entries is invalid for a KeypadLinc. Almost looks like the link record information for the SwitchLinc and KeypadLinc have been swapped.

Those are definitely KeypadLinc link records. A SwitchLinc uses a single Group number (01) in the second byte of E2 link records. A KeypadLinc uses up to 8 Group numbers (01-08) for an 8 button KPL. Many of the link records displayed have Group numbers in the 02-08 range. Physically impossible for a SwitchLinc to use. Same thing with the A2 link records except it is the last byte which identifies the "Output Unit Number". For a SwitchLinc it is always 00. The A2 link records that have values 01-08 represent KeypadLinc Group numbers acting as Responders. Again, physically impossible for a SwitchLinc to use. Recommend taking a backup of the system as it is now in case UDI needs it to determine why KPL link records have been associated with a SwitchLinc. Then restore a backup that does not have this bad link record association. An alternative would be to delete the SwitchLinc and add it back from scratch. The concern is something has happened to the configuration information and simply fixing this SwitchLinc may not resolve the underlying problem. Under the Admin Console when the SwitchLinc node is selected does the pane on the right show the device type as a SwitchLinc or a KeypadLinc?

Is MBedroom Light 18.0F.08 a SwitchLinc or a KeypadLinc? The link records make it look like a KeypadLinc.

After doing a Show Device Links Table, click on Compare. The results will indicate if the ISY beleives they should be there. Can you post the Show Device results?

When a device is added as a Controller it is assumed to also be a Responder (if it has responder capability) and was cross linked with every other Controller in the Scene including the ISY PLM which is why it is now turning On.

The v.00 is normal for all devices added when the specific Device Type is specified as is required for the Motion Sensor. That was a great diagnostic approach. How far off was the Insteon address label that came with the Motion Sensor? EDIT: never mind. I see you posted the address earlier. That does look like some test address that should have been replaced after testing. I would contact Smarthome Gold Line and see if they will replace. That may not be the only problem with that Motion Sensor.

The SwitchLinc is responding to button/paddle presses in other controllers that do not have this SwitchLinc as a Responder? If this is the case and there are not A2 link records in this SwitchLinc with the other controllers Insteon address the SwitchLinc is defective. Insteon architecture does not permit a device to respond to any Group (Scene) communication without the appropriate link record. Is there any chance the SwitchLinc is responding to Direct commands from an ISY Program that is triggered from the other controller button/paddle press?

With it working now it does sound like an X10 powerline situation. The more Insteon devices that are installed the more reliable Insteon gets because each Insteon device is a repeater of Insteon messages. The other side of that is X10 tends to get less reliable. Each Insteon device absorbs some of the X10 signal and Insteon devices do not repeat X10 messages. They do not block X10, just no amplification because X10 is not repeated.

MikeB The I/O Linc Relay is a Responder, just like a LampLinc, ApplianceLinc, SwitchLinc, etc. Sending it an On command turns the Relay On. Lee EDIT: sorry, the question was obviously does it respond to an All On to My Lighting. YES. Ran it on my system and I/O Linc Relay turns On in response to the All On button for My Lighting. All On sends a Fast On to Group 255. For the reason I originally stated except it is reacting to a Fast On instead of an On.

Two things to look at. Under Programs | Summary there is a column for "Last Run Time". Does this show any activity? Be sure the Program is Enabled. Run Tools | Diagnostics | Event Viewer with Device communications events selected (important step). Press the X10 button that should be triggering the Program and post the Event Viewer trace file.

jsveom There is a communications problem with the ICON Dimmer. Since neither the KeypadLinc nor the ISY PLM can communicate with the ICON Dimmer there is some problem with powerline communication or perhaps the ICON Dimmer has failed (not likely though). What type of load is the ICON Dimmer controlling? The easiest way to eliminate the possibility of an ICON Dimmer failure is to connect the switch to an appliance cord and plug it in at the ISY PLM plug point. Factory reset the ICON Dimmer and added it to the ISY. If that works the issue is with the load the ICON Dimmer is controlling or a powerline issue at the original location. If the ISY cannot add it when powered from the PLM plug point it likely defective. Lee

The only packaged Insteon device that might fit the bill is the RemoteLinc. The size may be too large. Also the 200' range could be a problem with any of the Insteon RF devices. If handy with tools a TriggerLinc (which is small) could be connected to a small button. The enclosure for the button could be a small project box from Radio Shack. It might be possible to use a miniature button installed in the TriggerLinc case. Again, range could be a problem. Placing an Access Point in the garage might help with the range. The TriggerLinc would be easy to proto type a solution to see if the range is sufficient. A more expensive solution but one with better range are RF devices from Dakota Alert. The Universal transmitter is about half the size of the RemoteLinc and comes with a built in button. This would require using a Dakota Alert receiver that has output relays which can be connected to an I/O Linc Sensor to bridge the gap between Dakota Alert and Insteon. I have used a Dakota Alert receiver connected to an EZIO6I for years with very reliable results. The Dakota Alert receiver has 4 channels so 4 different RF senders can be distinguished. This is an expensive solution compared to using a simple TriggerLinc.

Hi Michel Thanks for that information. Link Management option is Automatic. I don't use the other options. It was actually a surprise when the Extended Set/Get worked as I thought the ISY made some determination about that for other devices. I'll delete that ICON device and add it back to see what responses the ICON is generating. Perhaps they implemented the Extended Set/Get without implementing the Extended data transfer or Extended ALDB command. I'll post an update later today. Lee

Michel The ICON Dimmer is DevCat=01, SubCat=1E. Firmware=39. Unfortunately I do not have access to any of the SmartLabs confidential information. Lee

I have a house full of ICON Dimmers and Relays since 2005/2006. I like their appearance and they have served me well. Right now UDI is all hands on the new ELK stuff. Once that is released and stabilized I hope to see lots of new things appear.

I used Powerhome 2 for this test. Traced the SwitchLinc command with the Event Viewer and replicated the command against the ICON Dimmer. The PH2 macro facility makes it a simple matter to issue just about any Insteon command you want. PH2 requires much more Insteon knowledge and attention to detail to access that flexibility. Very different paradigm than the ISY but a really fun toy.

j0dan This looks like the ISY has not implemented the Extended Set/Get for the ICON Dimmer. I have 2876DB ICON Dimmer at firmware level v.39. When I issue the same Extended Set/Get command against the ICON Dimmer the ISY is currently using for the SwitchLinc the Local On Level takes immediate effect without a power cycle. Don't give up on the ICON line. I feel sure the ISY will pick up this support in the future. Lee

If one of the users knows for sure they will jump in and post the information. Smarthome/Smartlabs does not publish that type of information. The link http://www.madreporite.com/insteon/Inst ... e_list.htm gets you to a list of devices with the hardware and firmware levels. This information is passed back by users to the owner of the site who has been accumulating this information. It may provide information on what level you have versus what others have received. It does not have a functional list by hardware/firmware level.

I think the newer ICON devices and SwitchLincs are handled with an Extended Set/Get command that does not require a power cycle. Older devices do not support that command making it necessary to Poke configuration changes directly into the device memory. The device firmware is not aware of the configuration changes done that way. The next time the device initializes from a power cycle the new values are picked up. The new Extended Set/Get command is being implemented incrementally in various devices. Don't know which devices have that support and which do not. It comes down to if the device does not react to the changes, try a power cycle.

Are you setting the Local On Level / Ramp Rate values or Scene Responder values. If the Local values it is likely necessary to power cycle the ICON Dimmer for the changes to take effect. Scene Responder values do not require a power cycle. If I am off base please expand on the difficulties.

andrew77 If the PLM reset was successful all the link records would have been erased. The result would be no device can communicate with the ISY PLM and no Scenes will work. Suggest running Tools | Diagnostics | Show PLM Links Table to see if the link records were erased by a reset. If so a Restore Modem (PLM) is required to restore the PLM link information. Lee

Better way to do it. There is an Adjust Scene Program statement that changes the On Level Or Ramp Rate for a Responder of a Scene. Run a Program at the appropriate times that change the Responder On Level. The light switch on the wall is the Controller of a Scene, whatever device(s) are the Responders of the Scene. No Program is involved in actually turning the Responder On/Off. That eliminates any latency going through a Program.

The ISY would not know the state of the ApplianceLinc before power was lost. Whatever logic was used to turn the ApplianceLinc on initially, such as within a certain time range, would have to be repeated in the startup program. If it was turned on based on device condition that makes it more difficult. There are latching relays that remain in a particular mechanical position across a power loss. A latching relay could be driven from an I/O Linc for example, and also connected to the I/O Linc Sensor input. Based on the I/O Linc Sensor (which represents the state of the latching relay) devices could be turned On. Seems like a lot of work for an infrequent situation. Maybe it would just be easier to access the ISY remotely and turn the ApplianceLincs On when power comes back.

An ISY Program can be defined with the Run at Startup option. When power comes back the ISY Program can turn On whatever devices are appropriate.

j0dan With the Scene Responder link records (A2) appearing before the Controller link record (E2) something has rewritten the sequence of link records. The only thing I know of that does that is a Restore Device or Restore Modem (PLM). Since the link records that are labeled Broken are actually correct, albeit in a different order which has no affect on the operation of an individual link record, the next suspect is the Responder link record in the PLM for that SwitchLinc. There must be an A2 01 18.0F.08 xx xx xx in the PLM for the ISY to be aware of the SwitchLinc paddle press. Suggest doing a Show PLM Links Table and then click Count. The Show PLM Links Table/Count should be done 2-3 times to insure the count is reproducible. Inbound Insteon traffic to the PLM during the Show activity will adversely affect the number of link records displayed and subsequently counted. With a display with a predictable count look for the link record shown above. When the SwitchLinc stops reporting a paddle press do a Show PLM Links Table/Count and look for the A2 Responder link record for the SwitchLinc. Lee