LeeG

iostream212 Since I would bet that a large percentage of the issues posted on this ISY forum are Insteon related, not ISY, are you suggesting those folks should be told to take the issue to the Smarthome forum. You've got to be kidding. That is what happens on the Smarthome forum. Not a good idea to mention ISY over there as they are pushed over here even when the symptom is obviously unrelated to the ISY. Oh by the way, you will find UPB much more reliable than Insteon. The problem is a high premium is paid for that reliability. As I mentioned in my previous post, hard to find a better price point than Insteon. It is not the technology I have an issue with!

Is the cable at the KeypadLinc direct burial cable? If not the wire at the KeypadLinc might connect with exterior cable at a junction box inside the house. That could provide a common point for an InLineLinc. Difficult to know about any given CFL. Some work fine with no noise/interference. Others produce enough interference to prevent the Insteon device from receiving an Off command. If they are currently working with the KPL they would likely work with a micro module.

Nikki Regarding Smarthome, they are the sole supplier so either live with them or pull Insteon. Hard to find a better solution for the price point as I have looked. For reasons other than individual device reliability that Smarthome would not address I have pulled all Insteon out of the main house. Only thing left is what is in a detached garage and two KeypadLincs at the front door that monitor and control the detached garage. That equipment will go as soon as I can find an alternate solution. Either live with them or dump their products. I finally decided to dump their products.

The solution is to install an InLineLinc out on the post light and link one of the Secondary buttons to control the InLineLinc. As Brian has already indicated the ON/OFF function and the Red wire relationship cannot be changed. The Red wire would be moved to the soffit light circuit so the ON/OFF buttons control that load or cap the Red wire and link ON/OFF and the other switch in a 3-way cross-link.

I have several KeypadLincs that go dark (no LEDs) when there is a very short power interruption, on the order of .5 to 2 seconds. To bring the KeypadLincs back pull the air gap switch for a few minutes and then restore air gap switch to normal position being careful not to push the air gap switch past the surface of the frame as that can cause a factory reset. Rather than using Write Updates to Device, try a Restore Device. A simple device comm problem would have been detected and the ISY would have stopped the Update, leaving the changes queued for another attempt. The Restore Device will put back the links from scratch if that is the issue along with making whatever changes that are queued. Also note that once the ISY has been directed to Write Updates to Device for a specific device any other queued updates for other devices will be done at the same time. Should not have taken 24 hours however. As oberkc is going after there may be comm problems more wide spread that a single device. There should not be a continuous string of device failures. If devices continue to fail I have to suspect the electrical environment. Odd wiring, loose neutral somewhere, could be difficult to get a handle on with the Insteon install done by someone else. No way to know what wiring adjustments were made along the way.

What is a 2334-222? It is not listed as an item for sale on the Smarthome web site.

Responding would not cover that but perhaps a Program that checks for If Status 'TriggerLinc - Opened' is not Off and Status 'TriggerLinc - Opened' is not On Have not tried this but it seems like it would work.

The Responding check is looking for the Red ! indicator to the left of a node which indicates the ISY is unable to communicate with the device. With a TriggerLinc being a Controller Only device the only scenario I can think of would be the ISY tried to update the TriggerLinc for a Scene update/change and could not reach the device. Could be it was not put into linking mode or it was not in RF range.

For the RemoteLinc2 it sounds like it was not put into manual linking mode before clicking Ok on New INSTEON Device. Or the RL2 is not in RF range of Dual Band device. Need to see Tools | Diagnostics | Event Viewer at LEVEL 3 of the New INSTEON Device add of the new KeypadLinc. That message normally means communication with the device was not good enough to determine the Insteon Engine level in the device. The Insteon Engine determines the type of commands that must be used with the device.

There is some other Program that is producing the 3 PM Notify or perhaps this Program Else clause from a variant that has not been overlaid with a Save of the posted version.

I think it is a PLM problem. In all the years I have looked at PLM traces either the last byte returned by the PLM is an 06 for a command that is accepted or a 15 for a command that is not accepted. Never seen an 03 as the last byte and it is not listed in my PLM command reference. The problem is my PLM command reference is rather old and there could be additional valid codes that I am not aware of.

I suggest opening a ticket with UDI support. Fri 04/26/2013 06:56:18 PM : [LNK-BGN ] 02 64 01 00 03 The PLM message is now there as it should be but the last character should be 06; in your trace it is 03. My PLM command reference does not list an 03. The device response that should follow the PLM command is missing but I don't know if that is a PLM issue or device issue with the 03 in the last byte.

Power cycle PLM and ISY, bring PLM up first. Repeat Event Viewer at LEVEL 3 and New INSTEON Device. Do not attempt any Start Linking. Post the new event trace.

The following trace is what the beginning should look like. The message in Blue is missing. Click Help | About and verify both Firmware and UI indicate 3.3.10 Fri 04/26/2013 09:10:19 PM : [22 8b e0 ] Added to list of devices to link to ISY Fri 04/26/2013 09:10:19 PM : [iNST-TX-I1 ] 02 62 22 8B E0 0F 0D 00 Fri 04/26/2013 09:10:19 PM : [iNST-ACK ] 02 62 22.8B.E0 0F 0D 00 06 (00) Fri 04/26/2013 09:10:19 PM : [iNST-SRX ] 02 50 22.8B.E0 22.80.0B AB 0D FF (FF) Fri 04/26/2013 09:10:19 PM : [std-Direct Nack] 22.8B.E0-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 04/26/2013 09:10:19 PM : [iNST-TX-I2CS] 02 62 22 8B E0 1F 09 01 00 00 00 00 00 00 00 00 00 00 00 00 00 F6 Fri 04/26/2013 09:10:19 PM : [iNST-ACK ] 02 62 22.8B.E0 1F 09 01 00 00 00 00 00 00 00 00 00 00 00 00 00 F6 06 LNK-ON (01) Fri 04/26/2013 09:10:20 PM : [iNST-SRX ] 02 50 22.8B.E0 22.80.0B 2B 09 01 LNK-ON (01) Fri 04/26/2013 09:10:20 PM : [std-Direct Ack] 22.8B.E0-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 04/26/2013 09:10:20 PM : [LNK-BGN ] 02 64 01 00 06 Fri 04/26/2013 09:10:21 PM : [LNK-STAT ] 02 53 M(01) gid=00 22.8B.E0 011C 41 Fri 04/26/2013 09:10:21 PM : [iNST-TX-I1 ] 02 62 22 8B E0 0F 0D 00 Fri 04/26/2013 09:10:21 PM : [LNK-END ] 02 65 06

When Start Linking does not stay up it is usually because the Finish button was not clicked. The Finish button must be clicked regardless of whether communication with the device has been successful or not. The popup closing is usually what happens the next time Start Linking is initiated without clicking Finish. It sounds like there is a comm problem to the new switches. These are going to be I2CS devices which use extended commands that may not have been used with other devices in the garage. Stick with New INSTEON Device. Run Tools | Diagnostics | Event Viewer at LEVEL 3. Factory reset one of the new switches. Using New INSTEON Device enter the Insteon address, Name of choice and Device Type at default Auto Discover. Post the event trace. I’m pretty sure the device is not responding to the extended message with the required information.

What kind of update are you looking for? rick.curl reports the Smoke Bridge is working.

Start Linking puts the PLM into linking mode. If the new device cannot reach the PLM it may stay in linking mode for several minutes. Power cycle PLM and ISY. Insure PLM is powered before powering ISY. Then use New INSTEON Device to add the new device. New INSTEON Device does not have the side effects Start Linking can have if dealing with a comm problem. What type of device is being added that is having the problems? The easiest way to test a new device is to connect it to an Appliance cord (plug on one end, bare wires on the other). Plug the Appliance cord into the PLM plug point which eliminates questions of comm.

There were many functional additions, new device support and bug fixes between 3.2.6 and 3.3.10. Take a look at the 3.3.x link below. It lists each 3.3.x release from 3.3.10 to 3.3.1 with what was added and fixed at each increment. viewtopic.php?f=25&t=9366 There are also things fix in each of the 4.0.x images that have come out since 3.3.10. I think the Start Linking problem you are seeing as far as not staying up is due to the Finish button not being clicked on the previous Start Linking session.

The 867 count may be correct or the same Insteon device sent a message during the two Show operations. Any Insteon message reaching the PLM during a Show affects the Next Pointer used to access the next link record. An Insteon message may match a link record that has not yet been read during the Show which produces a false 'low' count. If the message matches a link record that has already been read the same link records are read multiple times producing a false 'high' count. If the Insteon network is active multiple messages will move the Next Pointer around so that the count will be false but could be high, could be low. I like to see the same count 3-4 times to take it as accurate. Not being able to reach the RF devices is not a problem. In fact nothing should be done to the RF devices during the Restore. Any attempt to reach the RF devices will result in an error and the updates queued. When the Restore is complete put one RF device at a time into linking mode and select 'Write Updates to Device'. Putting more than one RF device into linking mode at a time cancels each other out.

Although most find this out by controlling an individual device rather than the Scene this is actually a positive capability of Insteon. There are occasions where control of an individual device is desirable, even when linked with other devices. If devices always turned into Controllers, propagating individual Direct commands on to linked Responders, it would not be possible to control that one device. With Insteon an individual device can be controlled and a group of devices can be controlled simply by choosing to send Direct commands to a device or Scene commands to the Scene.

Normal Insteon operation. To have both switches react from the ISY turn the ISY Scene that cross-linked the switches On/off. Sending On/Off commands to an individual Insteon device affects only that device. The device does not then control its Responder(s). To control all devices in a Scene the Scene must be controlled.

It is not an issue with what Device Type the device is using. The problem is the device is not indicating any device type. The following message from my system (missing from your traces) contains the device type highlighted in Red. This Broadcast message is missing in all of your the traces. Without this the ISY does not know it is an Open/Close Sensor (TriggerLinc). That is why two nodes are not being defined. Other users have posted similar symptom (not with Open/Close Sensor) which was resolved by factory resetting the device. Wed 04/24/2013 02:01:27 PM : [iNST-SRX ] 02 50 11.B8.2D 10.02.28 8B 02 01 (01) Wed 04/24/2013 02:01:27 PM : [std-Broadcast] 11.B8.2D-->10.02.28, Max Hops=3, Hops Left=2

Sorry, I am out of ideas. I can tell you what is missing that does not allow the ISY to know what type of I2CS device it is but not why the device is not providing the information.

Try releasing the Set button when the LED turns On rather than waiting for the LED to turn Off 5) Release the Set button when the Status LED turns on

The second tap puts the device into unlinking mode. 3) Set TriggerLinc to Unlinking Mode by pressing & holding the Set button for 3 seconds again I suspect Factory Reset is not working. What procedure is being used?