LeeG

First the system has a bad mismatch. The post says the ISY firmware is at 3.2.4 and the UI Admin Console is at 3.2.6. Don't know if that is the problem but the ISY and UI must always be the same. Suggest updating the ISY to 3.2.6. Clear the Jave cache and start the Admin Console.

That is my understanding. Just like Status, once status goes to On a Program can trigger with that condition but it only happens once. The same device can be directed to turn On multiple times after that but since it is already On Status triggers only once. I believe Is Responding and Not Responding are based on the same thing, a change in the Responder (Is or Not) status, not a static state. Of course if something else triggered the Program the Responding state can be checked, just not a trigger after the first time. Since your nodes were responding there was no change to Is Responding.

Use New INSTEON Device, enter the Insteon Address, Name of your choice, and leave the Device Type set to the default Auto Discover. I do not think it necessary to screw in the bulb just before the New INSTEON Device. Just have it screwed in so it can receive commands. You do need to be on 3.3.4 for it to recognize the LED bulb device type. Double check the My Lighting tree to be sure it did not add. It is an I2CS device so it will not take long to add.

TJF1960 Are the EZFlora nodes being marked with a Red ! I unplugged one of my EZFloras and it is now being marked with the Red ! when I do a Query. This was not happening before 3.3.4. In that last post the device 01 7E 66 is responding with a 02 50 inbound message for the two commands being issued so it would not be marked Not Responding as it is Responding.

The ISY Links Table and the Device Links Table should be the same. Depending on the ISY level being used the End Of List link record (00 in first byte) in the Device Links Table will be flagged with some words indicating there is not a match in the ISY Links Table. This is normal as the ISY Links Table does not carry the End of List indication. At 3.3.3 (don't know when this change was made) the ISY Links Table now shows an End Of List record so the two lists look the same. I suspect the internal ISY Links Table really does not carry a physical End of List record, only displays one to match the Device Links Table display. Other than the End of List record the two displays should be the same. EDIT: linking the device outside of the ISY will create a mismatch.

Right click the Program name. The bottom selection is "Copy to Clipboard". Then Paste in the forum post. Does the Rope Light turn On and Off reliably with the Admin Console? When something does not turn Off the load on the switch is suspect for generating enough interference when On to prevent the Off command from reaching the device.

You're welcome. If a Restore Device does not eliminate and the Compare shows them as expected the only way I know of is to Delete the device and add it back. Then add it to the Scenes. I don't think it will hurt anything with them there but I don't like to leave behind link records that are wrong.

This is an End Of List link record (00 in first byte). 0 : 0FF8 : 00 00 1E.47.21 00 00 00 Do a Restore Device. You can see what the ISY thinks should be there by clicking on Compare after the Show completes or do a Show ISY Links Table for the device

Run Tools | Diagnostics | Event Viewer at Level 3. Turn the Scene On through the Admin Console since that is the aspect that is in question (or perhaps from a Program which is the same thing as using the Admin Console). A message (along with a few others) that looks like this will be displayed in the Event Viewer window. The value 1D is the ISY Scene number. It will be something different on your system for your Scene. Thu 11/08/2012 10:40:06 PM : [iNST-TX-I1 ] 02 62 00 00 1D CF 11 00 Now do a Show Device Links Table for one of the devices that does not respond to the Scene. There should be link record that looks like this A2 1D xx.xx.xx FF 1F 01 Where xx.xx.xx is the Insteon address of the new PLM and the second byte (1D) matches the ISY Scene number from the Scene On command that was traced on your system. The FF and 1F could be different depending on the Responder On Level and Ramp Rate for that device. Does not matter unless the FF byte is 00 which is Off. If that link record is not there or has the old PLM address try a Restore Device. If that does not get the correct link record restored Delete the device from the Scene and add it back. If the link record is there, there is a comm. problem with the device

Post your Program. The Repeat goes before the statement(s) to repeat.

The event log does help, thanks. The communication with 1D 5F BC is unreliable. Could be some form of interference on that circuit or at the PLM plug point. With earlier problems with a RemoteLinc it might be good to look at what is on the PLM circuit. Any other electronic devices, UPS, etc that is not on a FilterLinc. Also verify with the 4 tap Set button test that phase coupling is working. To the specifics of the event trace The following outbound command to 1D 5F BC got no response at all (no inbound 02 50 message) Thu 11/08/2012 08:10:56 AM : [iNST-TX-I1 ] 02 62 1D 5F BC 0F 28 0F Thu 11/08/2012 08:10:56 AM : [iNST-ACK ] 02 62 1D.5F.BC 0F 28 0F 06 SET-MSB(0F) The Hops Left count is varying which is another indication of comm. problems. The following two commands got a response with Hops Left=1. That is not the best but okay if consistent which it is not. Later some inbound messages have Hops Left=0. That is as bad as it gets and still working. The next step from Hops Left=0 is no response at all. Thu 11/08/2012 08:11:05 AM : [iNST-TX-I1 ] 02 62 1D 5F BC 0F 28 0F Thu 11/08/2012 08:11:05 AM : [iNST-ACK ] 02 62 1D.5F.BC 0F 28 0F 06 SET-MSB(0F) Thu 11/08/2012 08:11:07 AM : [iNST-SRX ] 02 50 1D.5F.BC AA.AA.AA 27 28 0F SET-MSB(0F) Thu 11/08/2012 08:11:07 AM : [std-Direct Ack] 1D.5F.BC-->ISY/PLM Group=0, Max Hops=3, Hops Left=1 Thu 11/08/2012 08:11:07 AM : [iNST-TX-I1 ] 02 62 1D 5F BC 0F 2B E0 Thu 11/08/2012 08:11:07 AM : [iNST-ACK ] 02 62 1D.5F.BC 0F 2B E0 06 PEEK (E0) Thu 11/08/2012 08:11:07 AM : [iNST-SRX ] 02 50 1D.5F.BC AA.AA.AA 27 2B 00 PEEK (00) Thu 11/08/2012 08:11:07 AM : [std-Direct Ack] 1D.5F.BC-->ISY/PLM Group=0, Max Hops=3, Hops Left=1 Another case of no response from device (no inbound 02 50 message) Thu 11/08/2012 08:11:07 AM : [iNST-TX-I1 ] 02 62 1D 5F BC 0F 28 0F Thu 11/08/2012 08:11:07 AM : [iNST-ACK ] 02 62 1D.5F.BC 0F 28 0F 06 SET-MSB(0F) This message 02 50 response has Hops Left=0 followed by a complete failure – no response at all Thu 11/08/2012 08:11:16 AM : [iNST-TX-I1 ] 02 62 1D 5F BC 0F 28 0F Thu 11/08/2012 08:11:16 AM : [iNST-ACK ] 02 62 1D.5F.BC 0F 28 0F 06 SET-MSB(0F) Thu 11/08/2012 08:11:16 AM : [iNST-SRX ] 02 50 1D.5F.BC AA.AA.AA 23 28 0F SET-MSB(0F) Thu 11/08/2012 08:11:16 AM : [std-Direct Ack] 1D.5F.BC-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Another case of no response from device (no inbound 02 50 message) Thu 11/08/2012 08:11:16 AM : [iNST-TX-I1 ] 02 62 1D 5F BC 0F 2B D8 Thu 11/08/2012 08:11:16 AM : [iNST-ACK ] 02 62 1D.5F.BC 0F 2B D8 06 PEEK (D8) These message 02 50 responses have Hops Left=0. Thu 11/08/2012 08:11:25 AM : [iNST-TX-I1 ] 02 62 1D 5F BC 0F 28 0F Thu 11/08/2012 08:11:25 AM : [iNST-ACK ] 02 62 1D.5F.BC 0F 28 0F 06 SET-MSB(0F) Thu 11/08/2012 08:11:26 AM : [iNST-SRX ] 02 50 1D.5F.BC AA.AA.AA 23 28 0F SET-MSB(0F) Thu 11/08/2012 08:11:26 AM : [std-Direct Ack] 1D.5F.BC-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Thu 11/08/2012 08:11:26 AM : [iNST-TX-I1 ] 02 62 1D 5F BC 0F 2B D8 Thu 11/08/2012 08:11:26 AM : [iNST-ACK ] 02 62 1D.5F.BC 0F 2B D8 06 PEEK (D8) Thu 11/08/2012 08:11:26 AM : [iNST-SRX ] 02 50 1D.5F.BC AA.AA.AA 23 2B 00 PEEK (00) Thu 11/08/2012 08:11:26 AM : [std-Direct Ack] 1D.5F.BC-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 With these errors it is not surprising that Updates are not successful. It is not uncommon to get a single On or Off command to work with the multiple retries Insteon has built into the protocol. However, Updates often take dozens or more commands that all must work to complete the Update. Out of the 8 commands attempted in this trace, 3 failed to get any response from the device and 3 received responses with Hops Left=0. The other 2 responses have Hops Left=1.

Connect the I/O Linc Ground and Sense to the Com and NO relay connections for whatever channel is being used. Does not matter what is connected to what. The receiver relay Com and NO contacts act like a switch that is closed when that channel receives a signal. I have the 3000 series Dakota Alert Motion Sensor which turns On with Motion for only a few seconds so the I/O Line Sensor will be On for only a few seconds.

Insteon has no concept of Scene Status. The ISY has not tried to invent one. Under the Admin Console when a Scene is selected individual device status is displayed. An ISY Scene can have multiple Controllers. It is not uncommon for different Controllers to set different Responder states. A "Scene On" when turned On by Controller A can have a different meaning when turned On by Controller B. Also when an individual device is changed locally what does that mean to a theoretical Scene status?

How are you determining the Motion Sensors are being skipped? As an RF device the ISY does not send a Query command to any battery RF device.

Yes, that is what should be done. The factory reset will clear the extra link records. That motion sensor has Controller links for at least 3 different devices. With it not being in any ISY Scenes there should only be three Controller links pointing back to the ISY PLM, one for each node, Sensor,Dusk/Dawn,Low Bat.

From a post by Michel 2. Go to http://www.universal-devices.com/99i/admin.jnlp ... this should install an icon on your desktop Before running, delete the existing Icon and clear the Java cache again. The current Icon is trying to load the 3.1.17 Admin Console from the cache which is now gone and would not be valid to run with 3.2.6.

Are there any wireless baby monitors, wireless phones in the 900 MHz band, any appliances that have wireless monitor devices, Venstar thermostats, etc that could interfere with Insteon RF.

I would not move anything at this point. Pick a Motion Sensor that is close to the Dual Band PLM. Put the Motion Sensor into linking mode with the Set button. Right click the Sensor node, select Diagnostics | Show Device Links Table and post the results. The flashing LED is a lack of an ACK. Usually the result of comm. problems but could be a link record issue. Being that close to the Dual Band PLM comm. problem seems low on the possibility list unless something between the MS and the PLM like a floor, wall, something metal like a refrigerator, etc

One or more devices that are linked as a Responder are not ACKing the Motion On message sent by the Motion Sensor. If no devices have been linked as Responders the Motion Sensor is not receiving the ACK from the ISY PLM. It means there is not reliable RF communication with the Motion Sensors.

Put the one with the Red ! into linking mode, right click the RemoteLinc Primary node and select Write Updates to Device. Sounds like the ISY has a pending update that fails because the RemoteLinc is not in linking mode when the ISY tries to write the update. The update remains queued which causes the Red ! later when the update is attempted and fails. Scenes can work even with broken links. May not be as reliable as they should/could be but they work.

I do not think it is a RemoteLinc2 problem. The error message is the result of not getting back the expected 02 50 inbound message from the RL2. The following is a trace from 3.3.3 of the Query Insteon Engine (same command in your trace) which shows the missing 02 50 inbound message because I failed to put the RL2 into linking mode (not your situation but same result. Without being in linking mode the command was not received so it would not be answered Mon 11/05/2012 05:39:47 PM : [iNST-TX-I1 ] 02 62 1C 27 E3 0F 0D 00 Mon 11/05/2012 05:39:47 PM : [iNST-ACK ] 02 62 1C.27.E3 0F 0D 00 06 (00) Mon 11/05/2012 05:39:55 PM : [iNST-TX-I1 ] 02 62 1C 27 E3 0F 0D 00 Mon 11/05/2012 05:39:55 PM : [iNST-ACK ] 02 62 1C.27.E3 0F 0D 00 06 (00) Mon 11/05/2012 05:40:04 PM : [iNST-TX-I1 ] 02 62 1C 27 E3 0F 0D 00 Mon 11/05/2012 05:40:04 PM : [iNST-ACK ] 02 62 1C.27.E3 0F 0D 00 06 (00) Mon 11/05/2012 05:40:08 PM : [ 1C 27 E3 1] ERR 1 The following is what the trace should look like when the RL2 can communicate with the ISY PLM. Mon 11/05/2012 05:40:51 PM : [iNST-TX-I1 ] 02 62 1C 27 E3 0F 0D 00 Mon 11/05/2012 05:40:51 PM : [iNST-ACK ] 02 62 1C.27.E3 0F 0D 00 06 (00) Mon 11/05/2012 05:40:52 PM : [iNST-SRX ] 02 50 1C.27.E3 19.70.06 2B 0D 01 (01) With multiple RL2s having the same problem they are not in range of a Dual Band device or the phase coupling is not working. Applications like the ISY have control over the RF aspects of the Insteon mesh network. RF communication is automatic and autonomous. There could be interference from things like baby monitors which operate on the same frequencies as Insteon RF. Could be out of range or the phases are not coupled because the Dual Band devices are out of range of each other or are not on opposite 120v legs. Change the location of the RL2. If the ISY PLM is Dual Band move the RL2 to the PLM location. EDIT: some of the older Venstar dongles had comm problems which blocked RF communication.

IM, Michel That is exactly what happens. As the PLM is retrieving link records sequentially it relies on what I have been calling the Next Pointer which is the location of the next link record to be read by a Get Next request. This Next Pointer is altered by a link database search resulting from inbound traffic. If the inbound traffic results in the Next Pointer being set to a location already read by the Get Next Process the same link records are read twice. They are not physically duplicate, but logically duplicate from being read more than once. If the link database search generated from inbound message matches a link record that has not yet been read by the Get Next process, link records are skipped by the Get Next process because the search alters the Next Pointer to a point later in the link database. I have reproduced this condition at will. It is not intermittent. It happens every time an inbound message is received during the Get Next processing. Either the link record count is high because some link records are read twice (or more if more than one inbound message is received) or the count is low because some of the link records are skipped. When I ran tests to determine how many link records actually fit in a 2413 PLM, during reading the link records back I could consistently create a false high count or false low count simply by when I sent the inbound message to the PLM relative to how far the Get Next process had progressed. The only solution is to use the Serial PLM commands that access PLM link records by specific address rather than just asking for Get Next.

You can send the event log to lwgwork@embarqmail.com. A .txt file cannot be attached to the forum. The event log should be very short. Edit under WordPad and copy/paste into post as any other text.

Use New INSTEON Device, enter the Insteon Address, Name of choice, and leave the Device Type set to Auto Discover. Before clicking OK put the RemoteLinc2 into linking mode by pressing the Set button until the LED blinks continuously. Put only one RemoteLinc 2 into linking mode at a time. Putting both into linking mode will cause the linking mode to be cancelled. Also suggest standing the RemoteLinc2 vertically rather than laying horizontally.

Are these RemoteLincs or RemoteLinc 2 devices? Before a Write Update to Device or Restore Device can be done the RemoteLinc (2?) must be put into linking mode. For a RemoteLinc press the Dim/Bright buttons until the RemoteLinc LED blinks continuously. For a RemoteLinc 2 press the Set button until the LED blinks continuously. Only one RF device can be done at a time. If two RF devices are put into linking mode at the same time one will link with the other, cancelling both out of linking mode.