LeeG

Sorry, not familiar with either. Turn both Off temporarily. The ISY will have to be rebooted to get out of Start Linking mode. Before trying Start Linking again I suggest invoking Tools | Diagnostics | Event Viewer with LEVEL 3 selected. With the firewall and AV Off invoke Tools | Diagnostics | Show PLM Links Table. Do any trace entries appear in the event viewer window? Okay. Leave the firewall and AV as is. Do the above except skip the part of turning Off the firewall and AV. Does the Show PLM Links Table produce any messages in the event viewer window? If not either the firewall or the AV is blocking the efforts of the ISY to communicate with the Admin Console.

Set the LED Brightness to 1.

If the Start Linking popup does not appear a firewall or Antivirus is preventing ISY data from being pushed out to the Admin Console. There should have been a popup displayed with a Finish button that closes out Start Linking. With no Finish button error message described is the result of issuing Start Linking a second time. What firewall and AV is being used?

Each time motion On is sent by the motion sensor the Scene is turned On and a 10 minute Wait established. If additional motion On messages are received before the Wait completes the 10 minute wait is reestablished so the Scene Responders remain On for 10 minutes past last motion On. The Scene is turned Off at 5 AM regardless. If Control 'Motion Sensor I2CS-Sensor' is switched On And From 1:00:00AM To 5:00:00AM (same day) Then Set Scene 'SceneSwitchLincDimmers' On Wait 10 minutes Set Scene 'SceneSwitchLincDimmers' Off Else Set Scene 'SceneSwitchLincDimmers' Off

Rebooting the ISY should not be necessary. Only restarting the Admin Console which should not affect Program execution. If the ISY IP was known to the firewall/AV it could be the ISY IP address has changed.

An ISY Program can react to the ApplianceLinc being turned On/Off and turn a KPL button On/Off in response. An ApplianceLinc has no Controller capability so it cannot be done directly with a Scene. Any linking done outside the ISY can prevent the ISY from being aware of device state changes.

If the Current State column is always blank look at firewall or Antivirus such as Kaspersky or Avast (and some others) that block the ISY from pushing changed data to the Admin Console. If it is intermittant Exit the Admin Console and invoke it again. This happens with mine infrequently when the OS has paged out a lot of virtual memory making the Admin Console slow to initialize. Not sure that has anything to do with the situation. If it is AV related the ISY IP should be added to some trusted list so the AV no longer blocks ISY activity.

Do not manually Set button link Insteon devices when using an ISY. It is not aware of manual Set button links and will eventually overlay or delete the link records. This results in half/broken links with various undesired affects. Do all device linking with ISY Scenes. The link record Flag byte might be defined in the old insteondetails.pdf document at insteon.net. It is an old document but the basic stuff about Insteon still applies. The common values A2 - active Responder link record E2 - active Controller link record 02, 22, 62 - deleted link record - 22 was a Responder link record, 62 was a Controller link record 00 - End of List marker AA - a new combination that has been showing up. Has something to do with I2CS (?) but the meaning of the 08 bit is not documented to the general public. The Ax makes it an active Responder link record.

What is in the first byte of the link record in question? If it is a 02, 22, or 62 the link record is inactive and nothing to worry about. When link records are deleted only the Flag byte (first byte) is changed to make the link record inactive. Once inactive the remainder of the data in the link record has no meaning. A Restore Device will physically remove the link record but there is no functional need to do that.

This can happen if the Motion Sensor had been linked manually to the KeypadLinc before being added to the ISY. The ISY does NOT generate user level Scenes between devices as described. When a device is added to the ISY the default 'remove existing links' option insures the device being added will not contain old links. That action alone will not remove the other half of the link which is in the KeypadLinc. It sounds like the ISY was still in the process of removing the Scene information when the Motion Sensor continued to control the KeypadLinc. There are Green Icons displayed to the left of the device nodes as the ISY is updating a device such as removing a link record. The KeypadLinc Primary node can be right clicked, select Diagnostics | Show Device Links Table. When the display completes check that the link records do not have the Insteon address of the Motion Sensor. The same thing can be done for the Motion Sensor. It has to be put into linking mode first. Then right click the motion sensor Sensor node, select Diagnostics | Show Device Links Table and insure none of the link records have the KeypadLinc Insteon address.

The If requires a specific 0.5 inches and only 0.5 inches. Is that what you wanted? If Time is Sunrise - 2 hours And Module 'Climate' Irrigation Requirement is 0.5 inches And Module 'Climate' Temperature > 34 °F

ffpllc UDI recommends updating the ISY image when local. The ISY supports it being done remotely but that introduces issues associated with external internet performance. Best to be done when local.

JMC The event trace did not get posted. Note that the ISY will not send the LED Backlight level commands to the KPL if it has already set those values. To be sure the commands are traced change the Program statement(s) to some other LED Backlight level, Save and then run Program.

The Finder window remains open so additional definitions can be added even when only 1 exists.

No. The physical load control button cannot be re-designated. Could put the load on some other Insteon device and use any KPL button to control the other Insteon device.

I doubt the cai stuff is changing the event viewer unless it has ISY specific support. I have assumed the Admin Console insures the event viewer starts off active. Either at level 1 or something higher if previously set to a higher level (2 or 3). I would expect the event viewer to stay at level 0 so long as the event viewer remains active and another client is not used.

I do not think so. It would help only if the Access Points are not able to effectively couple the two 120v legs. The purpose of the hardwired coupler is to pass Insteon messages that are already on the powerline from one 120v leg (phase) to the other. The same function the Access Points perform. In addition the Access Points also provide the bridge between the powerline and RF only devices. I would expect other Insteon network issues if the Access Points were not coupling effectively. Installing the hardwired bridge will not hurt anything.

Another client would be something like MobiLinc, the DSC support, etc that is setting the level to 1 from the looks of the posted trace.

Installed on 994i successfully. Step c. identifies 3.3.9. I used 3.3.10 successfully. c. http://isy.universal-devices.com/99i/3.3.9/admin.jnlp

I ran this test Program with 5 Wait 1 minute (Random) statements. The actual Wait times were 26, 17, 0, 51, and 2 seconds. This was run on 3.3.9 (RC6). A Wait 1 minute Random seems to be working okay here. Then Send X10 'A1/On (3)' Wait 1 minute (Random) Send X10 'A1/On (3)' Wait 1 minute (Random) Send X10 'A1/On (3)' Wait 1 minute (Random) Send X10 'A1/On (3)' Wait 1 minute (Random) Send X10 'A1/On (3)' Wait 1 minute (Random) Send X10 'A1/On (3)' Else Wed 01/16/2013 10:14:43 PM : [X10] A1/On (3) 26 second wait Wed 01/16/2013 10:15:09 PM : [X10] A1/On (3) 17 second wait Wed 01/16/2013 10:15:26 PM : [X10] A1/On (3) 0 second wait Wed 01/16/2013 10:15:26 PM : [X10] A1/On (3) 51 second wait Wed 01/16/2013 10:16:17 PM : [X10] A1/On (3) 2 second wait Wed 01/16/2013 10:16:19 PM : [X10] A1/On (3)

I don't have a good answer why some command sequences physically work and some do not. The initial trace of the motion sensor add when near an Access Point has some commands getting responses but those responses are at the very outer edge of working. Other commands got no response. One logical difference is a device add requires a whole series of commands to work. If there is an error that a retry does not resolve the add has to terminate. Can't add a device when only some of the information is known or only some of the setup information completed. A Motion On or Motion Off message is an Insteon Group protocol sequence which can have multiple messages all with the same intent. Notify the PLM that motion has been sensed. If the first message fails to arrive it is followed by up to three additional attempts with a different message type, all indicating motion On or Off. The messages associated with device add and configuration do not have the redundancy of a Group Protocol sequence. The assumption is an Insteon Mesh Network will be working reliably with only sporadic interference which is compensated for by the redundancy of the Group Protocol for device control. The RF aspects are marginal right from the beginning so the device add and configuration has much less chance of being successful. The wired SignaLinc coupler is passive. It will not be affected by RF interference. It does not have an active repeater so the message on the opposite 120v leg will likely start off at a lower signal level. I don’t believe it can hurt to have one. I prefer Access Points as they repeat the signal on the opposite 120v leg at a full signal level.

No wired Insteon motion sensors that are functional equivalents to the 2420M. There are outdoor Insteon floods that use a 120v powered motion head. It does seem like there is another 915 MHz source when the motion sensor will add when a few inches from an AP but not a few feet.

It does sound like there is an RF problem. Something in the 900 MHz band could be interfering. Anything that operates wirelessly. Speakers, baby monitor, some appliances like a washer/dryer have a remote device that signals when cycles complete. Not sure if the RF part of the PLM itself is working or there is some interference from the other electronics that are found in a media closet. Power cycle the PLM is simply unplugging for 30 seconds or so to give the power supply a chance to drain off before plugging it back in.

That is odd. I changed level from the default 1 to 0. At level 0 the event viewer did not show Insteon traffic. Changed it to 3 and see all the Insteon traffic. Changed it to 0 and Insteon traffic stopped. Did not try variable updates.

Without any tools from SmartLabs to diagnosis RF specifically the things to do next are somewhat limited. I would try another RF device such as another motion sensor, triggerlinc, remotelinc2 to see of the issue is isolated to this specific motion sensor or all RF devices. It appears the RF aspects of the PLM are not working. Could try power cycling the PLM. Could try a factory reset of the motion sensor. At this point it is just trying things until a pattern develops across multiple devices. The last trace shows the motion sensor did not respond to any of the command requests. I guess the motion sensor could be moved back to an access point location to see if any communication is still possible with the motion sensor. The event trace will show inbound Insteon messages which start with 02 5x when the RF aspect of the Insteon Mesh Network is working. Applications such as the ISY have no control over the RF aspects of Insteon. It is suppose to work as soon as the devices are plugged in.