LeeG

All the home improvement stores in the area as well as many of the hardware stores sell a simple tester. It plugs in, about as large as a two to three prong adapter, has three lights/LEDs. The pattern of the lights indicates if line and neutral are connected to the correct prongs. Also verifies a valid Gnd. They run a few dollars.

"Does it matter that the same KPL button triggers the basement scene on AND triggers a scene that shuts all basement lights off, regardless if they're in the basement scene or not?" It can. Perhaps understanding what happens Insteon wise when the KPL button is pressed will help. First the KPL sends a Group Broadcast message which all Responders should react to simultaneously. Also the ISY Program is triggered by this message. Next the KPL sends a Group Cleanup Direct message to each button Responder device individually. This message must be ACKed by the individual Responder or the KPL will retry the Group Cleanup Direct for that Responder. While this KPL activity is going on the ISY Program is running issuing the Then statements. These Program statements can easily overlap the continuing KPL activity generated by the KPL button press. Depending on how many Responders are directly reacting to the KPL button press, the Program should Wait until this activity is complete before issuing Insteon statements.

If the link records were not updated in a particular device with the new PLM address a Scene would not work as they are dependent on correct link records in the PLM and device. Oberkc suggestion to do a Restore Device is a good idea as it will rebuild the device links table. Could still have a comm problem but eliminating the link record question since a new PLM has been installed is worth doing first.

On insteon.com under white papers there is an insteondetails.pdf document that provides much of the Insteon information. Google 'insteon plm manual' for link to a PLM Developer's Guide which will provide information on the serial commands to/from the PLM. The ISY adds some annotation such as describing the Hops counts. The same information is in the raw Insteon messages. The annotation eliminates the need to analyze some of the bit level information.

There are no ISY or PLM options to enable X10. Try plugging the X10 module into the same plug point as the PLM. Do the X10 messages show in the Event Trace at LEVEL 3? Insteon RF bridging does not bridge X10 signals.

The concept of controlling retries was introduced with I2CS protocol. Only I2CS devices functioning as a Controller can control retries. For example, a button press on a non-I2CS KeypadLinc operates on the retry scheme Insteon has had forever. No Tries means no Group Cleanup Direct messages. As the retry count is increased the number of possible Group Cleanup Direct messages increases. A high retry count on a marginal Insteon Mesh Network can result in an increase in Insteon traffic. The retry count is stored in D1 (the first of the three data bytes) in Controller link records. A value of 0xFF which was a common value in the past results in no retries with an I2CS Controller. I don’t think there is a proper setting per se. The lower the number the better as far as the volume of Insteon traffic. A marginal or unreliable Insteon Network would require more. I think it best to clean up a bad Insteon network than compensate by running with a high retry count.

If you are referring to the Green arrow to the left of the node that is "1011" (or something near that) which means there are updates pending for the device that could not be written, usually because of comm errors. The normal response is to right click the node and select Write Updates to Device.

The first thing the Then does is turn On Scene 'Breezway S'. If Dark Outside, Elk Zone, Garage / Third Garage-Breez L', or 'Back Hall / Back Hall Ext Door-Breezway L' changes state the Wait or Repeat will be cancelled driving the Else clause. This will leave 'Scene 'Breezway S' On. The advantage of being two programs is that any state change drives the first program Else, allowing the logic in program 2 to run to completion. If ( Program 'Dark Outside' is True And Elk Zone 'Back Door' is Violated And Status 'Garage / Third Garage-Breez L' is Off ) Or Control 'Back Hall / Back Hall Ext Door-Breezway' is not switched On

The exposure to combining into one program means that "any" of the If conditions changing will cancel the Wait or Repeat and drive the Else.

Insteon messages are not created by noise. They are too complex and contain a CRC on each message for noise to be misconstrued as a valid message. If the devices have X10 addresses assigned noise can look like the old X10 message structure. Look at the ISY Log for actions affecting the devices in question. Also bring up the Admin Console and watch the state of one of the switches. If something the ISY is aware of is changing the Status (Current State column) it should be reflected in what the Admin Console is displaying. Also the Event Viewer run at LEVEL 3 should show activity if initiated by the ISY. Disable all the Programs temporarily and see if the stops the Status change activity.

If the PLM is on 120v leg A and the InLineLinc is on 120v leg B, RF coupling is needed for the PLM messages to reach the InLineLinc because the InLineLinc is powerline only. An RF signal reaching the InLineLinc would not be useful.

What was the result of the 4 tap Set button test?

The InLineLinc is not responding to the command requesting the Insteon Engine supported by the device. Note there are no 02 50 inbound messages. The ISY tries three times, with no response each time. Thu 11/21/2013 11:57:29 AM : [iNST-TX-I1 ] 02 62 08 37 AC 0F 0D 00 Thu 11/21/2013 11:57:29 AM : [iNST-ACK ] 02 62 08.37.AC 0F 0D 00 06 (00) Thu 11/21/2013 11:57:37 AM : [iNST-TX-I1 ] 02 62 08 37 AC 0F 0D 00 Thu 11/21/2013 11:57:37 AM : [iNST-ACK ] 02 62 08.37.AC 0F 0D 00 06 (00) Thu 11/21/2013 11:57:46 AM : [iNST-TX-I1 ] 02 62 08 37 AC 0F 0D 00 Thu 11/21/2013 11:57:46 AM : [iNST-ACK ] 02 62 08.37.AC 0F 0D 00 06 (00) Thu 11/21/2013 11:57:50 AM : [8 37 AC 0 ] Failed to add device, reason 3 The following is a Query Insteon Engine that worked. Thu 11/21/2013 02:06:40 PM : [iNST-TX-I1 ] 02 62 14 41 95 0F 0D 00 Thu 11/21/2013 02:06:40 PM : [iNST-ACK ] 02 62 14.41.95 0F 0D 00 06 (00) Thu 11/21/2013 02:06:40 PM : [iNST-SRX ] 02 50 14.41.95 22.80.0B 2B 0D 01 (01) Thu 11/21/2013 02:06:40 PM : [std-Direct Ack] 14.41.95-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Unfortunately a working Insteon Mesh Network today does not mean it will work tomorrow. New devices/appliances are added to the home, existing electronics degrade, things like baby monitors operate on the same frequency as Insteon RF. The 2413 PLM is the Dual Band version. What Dual Band device is on the other 120v leg,

Right click the node and select Query. As I remember that does not generate traffic to the Smoke Bridge but does reset the node to Off. Again from memory tapping the Smoke Bridge Set button causes it to send On or Off messages to several of the nodes.

Moving from the 99i to the 994i will not alter the comm characteristics. Run Tools | Diagnostics | Event Viewer at LEVEL 3. Add the device using New INSTEON Device with Auto Discover. Post the trace. Check that the Access Points are on opposite 120v legs and in RF range of each other. The 4 tap Set button test will verify these conditions. Are there other electronic devices on the same circuit as the PLM ? If so are these on a FilterLinc? It sounds like PLM communication with the InLineLinc has failed. The event trace will show if it is responding to any commands.

That sequence would result in the PLM being restored. EDIT: an additional note. Restoring an ISY Backup could result in the device link information in the ISY not being in sync with link information in some of the devices. Depends on how different the Backup is from the current definition. It may be necessary to do a series of Restore Device commands to bring the devices in sync with the older ISY Backup.

The ISY Backup has all the configuration information which includes link information. Restoring an ISY Backup refreshes the information in the ISY. It does not restore that information to devices. Restoring all device configuration and link information to every device would be time consuming and usually not necessary. The Save of the link display is useful for debugging. I have had users send me a file particularly when a large number of links is involved.

The requirements indicate a different set of devices should react to the On button press versus an Off button press. Also a KPL button should be On if either of two devices is On. A Scene alone cannot provide that type of logic. The logic to accomplish this level of sophistication has to be implemented with ISY Programs. There will be Scenes involved in the implementation, such as needing a Scene to control a Secondary KPL button LED, or a Scene to control multiple devices at once which is the power of a Scene but the Scenes cannot be driven directly from a button press. Program(s) will have to be triggered by a button press, by a device being turned On/Off, etc which contain the logic to determine what devices are currently On or Off and control KPL button LEDs in response. Also an On button press turning On one device and an Off button press turning Off multiple devices requires Program logic. Again, the Program logic will utilize Scenes but they will be driven by Program(s) rather than directly by a button press. I don't see any reason why the requirements cannot be implemented. It is simply how much effort you want to expend to accomplish the various complex results.

That complexity cannot be done with Scenes. Insteon Scenes do not have the conditional logic you describe. Programs are needed. Note that a Secondary KPL button LED must be controlled with a Scene. An Insteon Direct command cannot be used in a Program to turn a Secondary KPL button On or Off. A Direct command cannot identify a specific KPL button. Define an ISY Scene, add the Secondary KPL button as a Responder in the Scene. The Program(s) turn this Scene On/Off to turn the KPL button LED On/Off.

The number of links in a PLM is directly related to the number and type of Insteon devices defined. If the PLM lost its link database only those devices that were deleted/readded or a Restore Device issued could have PLM link records. A new PLM required a Restore Modem (PLM) to rebuild the new PLM after the ISY power was restored with the new PLM connected. The Save function is not a backup. The ISY backup and restore is used to bring back a configuration that has been corrupted. The Show ISY Links Table is on a per device basis. A single active link record could be valid depending on the device type. If several devices have been corrupted because of the old PLM there is a File | Restore Devices which restores all the devices.

There should be 7 nodes for the Smoke Bridge. What does Help | About show for the ISY Firmware and UI levels. Sounds like the UI (Admin Console) is not at the required level.

The OP states the 10 second value is for testing purposes only

Both Motion Sensors must be Controllers of the Scene. As a 'Controller only' device the ISY should not link either as a Responder of the Scene.

It did not work because the Status changes when Barn Spots is turned Off. This cancels the Wait before the Set Scene that turns the KPL button Off. Turn the KPL button Off, then the Barn Spots Off. A Wait is not needed between these two actions.

Things in the ISY are event driven. When a specified time occurs, when a message is received from a device (If Control) because the button/paddle/toggle has been pressed, when the state/Status of the device is changed. ISY Programs DO NOT sit there checking on the various conditions in the If section. Some event has to trigger the execution of the Program which then checks the If conditions. Status is what the ISY thinks the state of the device is in. This state/Status can be the result of a Program turning On/Off the device, manual operation of the button/paddle/toggle, the device being turned On/Off by another Controller (device). The Status is accurate unless the Insteon Mesh Network is unreliable. An unreliable Insteon Mesh Network should be fixed, not compensated for by Queries. If the Insteon Mesh Network is not reliable such that Status is not correct then If Control will also fail. Status is not accurate because Insteon traffic is not reaching the PLM. A message that does not reach the PLM can make Status wrong and also prevent an If Control from triggering a Program. The choice of If Control or If Status is dictated by what you want to accomplish. If Control is looking at inbound commands from the device, If Status is looking at the State information the ISY keeps track of. Some folks use both in the same Program. An If Control monitors the inbound commands and when ANDed with a If Status Off for example will run the Then clause only when a particular command is received when the device is Off. Back to what you want to accomplish. The answer to the last question is to use If Status. This covers all the cases presented.