LeeG

propman07 Go back to my previous post which has 6 Adjust Scene statements in the Then clause. You have 4 in the last posted example. Both the Then and Else clauses must adjust 6 different values each for them to set all the values needed for the two switches and Scene to work correctly. For when 'Hardware / Family Room Light' is the Controller two values have to be set The Local On Level of this specific switch - 'Hardware / Family Room Light' The Responder On Level for 'Hardware / Family Room Light Slave' that is cross-linked to it For when 'Hardware / Family Room Light Slave' is the Controller two values have to be set The Local On Level of this specific switch - 'Hardware / Family Room Light Slave' The Responder On Level for 'Hardware / Family Room Light' that is cross-linked to it For when the ISY Scene name Is the Controller (the ISY PLM) two values have to be set The Responder On Level for 'Hardware / Family Room Light' The Responder On Level for 'Hardware / Family Room Light Slave' I know it looks like a lot of values being set but they are the 6 values involved

redsfancfp It will work if you follow the instructions provided by apostolakisl "If you want to fix this, make the else clause say the same stuff as the then clause." Then Send X10 '03/On (3)' Set 'garagecornerflood' On wait 2 minutes send x10 '03/off (11)' set 'garagecornerflood' off What was added to the Else is not what is in the Then clause. It turns the lights Off immediately because that is how the Else is coded. OK so I added Else set x10 o3 off set 'garagecornerflood' off

Use 'If Control' rather than 'If Status'. If Control looks for the commands coming from the device and will trigger the Program even if getting two Off commands in a row.

We seem to have gotten way off track. Unplug the ISY and PLM. Factory reset the devices and relink with the SmartLinc. The ISY cannot help you get back to a clean SmartLinc environment.

"PLM - links between PLM and all Insteon devices. Perplexed though as to why I can run a PLM links query and it shows the device I am having trouble with. Yet, when I try to run a device links query on that device, I get error messages telling me it can not communicate with it." The existence of the link records are needed for Scenes and for the ISY to be aware of device state changes. They do not insure the Insteon Mesh Network is working. Manual device control does not involve the use of link records so they do not matter unless it is an I2CS device. The I2CS devices cannot be manipulated from a PLM that has not been authorized to talk to it. If the authorization link record in the device is lost communication will not be intermittent. I don't think comments by me and others regarding the fact that there are comm problems have been understood to mean there are powerline and/or RF issues and/or phase coupling issues that have no relation to link records.

I traced a Delete device with the expectation I could post an event trace showing how the ISY deactivates the first link record which would logically clear the device link database. There is no Insteon command to cause the device link database to be physically cleared to zeros as a factory reset does. Either my memory is wrong or the ISY has changed along the way. Either way the ISY does not alter the device link database when a device is Deleted. The Controller link in the PLM is removed. Sat 02/02/2013 11:08:03 AM : [MNG-LNK-RSP ] 02 6F 80 E2 00 1C F2 EE 02 09 42 15 This means the devices can be Deleted from the ISY with no change to the device link database. Adding the device back to the ISY with 'remove existing links' is a logical process which when completed will leave as the only 'active' link records those needed by the ISY for event awareness and device control. It does not physically clear the link database. Without an Insteon command to do that it could take hours to write one byte of zeros into each link database memory location. My recommendation to factory reset the devices insures that each device will start out with a link database that is all zeros. There is no option through the ISY that can accomplish. I just saw the last post so here are the answers to those questions "PLM - shows the links between the ISY and each Insteon device in the network" The PLM contains a Responder link record for each device node that can generate an inbound command the ISY must be aware of. It also contains a Controller link record for each device node that is controllable by the ISY. I state it this way as some device nodes do not send commands and would not require a Responder link record and some device nodes cannot be controlled from the ISY and would not have a Controller link in the PLM. "Device - shows the links currently residing in tables stored on the individual device" Correct. There are active link records (Controller and Responder), inactive link records that have been removed from Scenes or unlinked with the Set button, and an End of List link record which marks the end of the logical link database. This link record starts with a 00 in the first byte. The device will not look for active link records beyond the End of List record. "ISY - Do not have a clue. Guessing that these are tables to describe relationships between devices that are necessary to run programs?" The ISY Links Table for a device contains the link records the ISY thinks should be there. That is, link records the ISY has managed. These include active Controller and Responder link records as well as logically removed link records (inactive link records). When the Compare button on the Show Device Links Table is clicked this is the database the ISY compares against to determine if the device link database is correct. "Maybe if I made an effort to better understand how the Links tables work, what they mean, how to read then, I could resolve my problems." There is an old but applicable insteondetails.pdf document at insteon.net that has some information on Insteon link records. Each link record is eight byte long and its format has not changed since the beginning of Insteon back around 2005. I don't think learning the link database will be of much use. The SmartLinc has no ability to display the link database of a device. The ISY must have a device defined to it to be able to use the ISY Show Device Links Table so even if the ISY was kept for diagnostic use only it would not be of any use with the devices Deleted. This link may be of use as far as understanding Insteon link records. He has accumulated a fair amount of Insteon information. http://www.madreporite.com/insteon/insteon.html EDIT: the nice thing about link records is the format has never changed. A link record written in 2005 will look pretty much like one written today. There are some new Flag byte bit combinations (first byte of link record) that have shown up for I2CS but the basic bits for Controller, Responder, Active, and End Of List are the same across the board.

It does not leave the links intact when Deleting a device unless power is removed from the device by pulling the air gap switch before the Delete. Adding them back to the ISY with 'remove existing links' does not result in a physically clean device link database. Like all HA applications that support device event based triggering the ISY must add link records to the device and the PLM to allow Insteon devices to notify the ISY of device state changes. This process has already been shown to be unreliable as a result of the PLM to device comm problems. Also the device link database will still have the remains of other link records. This should not cause a problem but I recommend doing a factory reset on the devices to physically clear the entire device link database to zero. There is no function in the ISY that physically clears the entire link database to zero.

See my post to the other topic.

Since the PLM cannot communicate reliably with devices from its current location the only option is to factory reset the devices that have been added to the ISY and link them back to the SmartLinc. Even if the PLM communication issues are resolved first the manual Set button links that have been established outside the ISY environment make graceful clean up by the ISY impossible. The normal recommended clean up for Set button links is to factory reset the devices and do a Restore Device. Since the ISY is not in the final solution a simple factory reset of the devices is the safest approach. Of course if the comm. problems extend beyond PLM to device, linking to the SmartLinc could be the next issue. There is no need to do anything with the ISY itself.

There is a communication problem between the PLM location and some of the devices. After not being able to write link records from the PLM location, why would one expect to be able to read link records as evidenced by not finding the ApplianceLinc when adding the KPL. I understand the frustration of wanting things to work by simply plugging them in but achieving good Insteon communication is rarely that easy. The electrical powerline was established to provide power to the various electrical and electronic devices found in and around a home. The electrical system along with the various devices powered from it were not designed to carry a powerline signal injected on the 120v sine wave. It can be made to work, there are thousands of Insteon users scattered across this country and other who are ultimately satisfied. However, the few that just plugged in and wired in their devices and they all worked are the true exception. Likely the PLM plug point has sources of interference, either noise or signal attenuation that must be identified and corrected to obtain a reliable Insteon network. In addition reliable phase coupling is essential. There is no doubt in my mind that a reliable Insteon network can be achieved but that will not happen by consciously choosing to ignore the issues, in favor of looking into them later. And then compounding the problem by doing things like linking outside the HA environment. I can only speculate how those symptoms will be described when they surface and what will be blamed for them.

You are welcome. You know what to look for now. If the PLM loses the link database again a new PLM is needed.

It will cause problems down the road. Likely harder to diagnose than what you have now. You have an Insteon Mesh Network problem. Until that is resolved you will continue to have problems with future activity.

Run the Show Device Links Table as suggested above. It sounds like there is an Insteon Mesh Network problem. Are any electronics at the PLM plug point (other than PLM) on a FilterLinc? Is there a pair of Access Points for phase coupling that have been verified as being in RF range of each other and on opposite phases?

The PLM has lost the link database. DO NOT put all the RF only devices into linking mode. They will cancel each other out. Run the Restore Modem (PLM) which will rewrite the PLM link database and may update other devices including attempts at writing to the RF only devices which are asleep and will fail (as expected). Once the Restore Modem is complete, any RF device that has a Green Icon or Red ! to the left of the node(s) should be put into manual linking mode ONE AT A TIME, selecting Write Updates to Device. When the Write Updates to Device is complete for one device move to the next. If the PLM is defective it will not accept the link database rewrite. It may accept the link database rebuild and then lose the database later. No way to determine ahead of time. If it continues to lose the link database it has to be replaced. .

The ISY Scene definition is correct KeypadLinc 1 button A - Controller KeypadLinc 2 button A - Controller InLineLinc - Responder If the A buttons do not stay in sync either the link records did not get created correctly because of comm errors which should have updates pending, noted to the left of the KPL nodes with Green Icons Or there is comm issue between the KPLs such that the Off message generated by one is not being received by the other. Suggest a right click on the KPL Primary node, select Diagnostics | Show PLM Links Table followed by a click on the Compare button when the display is complete. The Compare results will show what link records are expected and exist in each KPL. Post the Show Device Links Table results.

I suggest moving to 3.3.10 as that is now the latest Official release. After the upgrade make sure Help | About shows 3.3.10 for both Firmware and UI. A Power Strip is fine if absolutely sure it has no surge/noise suppression. If power strip contains either it will make the situation worse.

It also looks like whatever is being powered from the tested switch is having a negative effect on comm to the outbuilding. Note the Hops Left=0 count for the Off command where the Hops Left=2 when the device is going from Off to On. That type of response often indicates the load being powered is causing interference. Fri 02/01/2013 05:39:19 PM : [iNST-TX-I1 ] 02 62 19 ED 3F 0F 13 00 Fri 02/01/2013 05:39:19 PM : [iNST-ACK ] 02 62 19.ED.3F 0F 13 00 06 LTOFFRR(00) Fri 02/01/2013 05:39:20 PM : [iNST-SRX ] 02 50 19.ED.3F 19.74.C6 23 13 00 LTOFFRR(00) Fri 02/01/2013 05:39:20 PM : [std-Direct Ack] 19.ED.3F-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Fri 02/01/2013 05:39:20 PM : [ 19 ED 3F 1] ST 0 Fri 02/01/2013 05:39:20 PM : [iNST-SRX ] 02 50 19.ED.3F 19.74.C6 23 13 00 LTOFFRR(00) Fri 02/01/2013 05:39:20 PM : [std-Direct Ack] 19.ED.3F-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Fri 02/01/2013 05:39:23 PM : [iNST-TX-I1 ] 02 62 19 ED 3F 0F 11 FF Fri 02/01/2013 05:39:23 PM : [iNST-ACK ] 02 62 19.ED.3F 0F 11 FF 06 LTONRR (FF) Fri 02/01/2013 05:39:23 PM : [iNST-SRX ] 02 50 19.ED.3F 19.74.C6 2B 11 FF LTONRR (FF) Fri 02/01/2013 05:39:23 PM : [std-Direct Ack] 19.ED.3F-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 02/01/2013 05:39:23 PM : [ 19 ED 3F 1] ST 255

Plug the ApplianceLinc into the same plug point as the PLM and try again. The ApplianceLinc is not a Dual Band device so nearness to an Access Point does not mean much. The ApplianceLinc is an I2CS device which did respond to the initial request to indicate type of engine but did not respond to commands after that. What does Help | About show for Firmware and UI levels?

It sounds like the PLM has lost some of its link records. The PLM will not pass message activity from a device unless the PLM finds a matching Responder link record for the device. Controlling a device manually from the ISY is not dependent on link records. The fact that the devices respond to Scene On/Off from the Admin Console indicates the devices have their required Responder link records. I suggest doing a Restore Modem (PLM) to rebuild the PLM link database.

Something like this to start with. If Control 'Kithchen Dimmer' is switched Off And Status 'LR Dimmer ' is 50% Then Set 'LR Dimmer' On Else - No Actions - (To add one, press 'Action')

WetCoastWillie Also note the Adjust Scene statements do not physically change the On Level of the devices. If already On at 50%, the Adjust Scene to 100% means the next time the switch is pressed it turns On to 100%. Another Program that tests for the switch being On at 50% and changes it to 100% On is needed to physically affect the On Level without manually operating the switch. The additional Program can be invoked from the current example.

The second line in the If should be Control, rather than Status If Control 'Front Porch Switch' is switched On And Status 'Front Porch Switch' is not Off Then Disable Program 'Front Porch Sensor' Else Enable Program 'Front Porch Sensor' If Control 'Front Porch Switch' is switched On And Control 'Front Porch Switch' is not switched Off Then Disable Program 'Front Porch Sensor' Else Enable Program 'Front Porch Sensor' The current ‘And Status’ in the second line prevents the Program from disabling the other Program when the switch is turned On manually. Likely the variation suggested by TJF1960 used And Status rather than And Control as that variation should have worked also. Did not see the answer to TJF1960 question about the Motion Sensor being linked to the swtich. It should not be.

Try this. I have a working example somewhere but I can't find it and it is way past my bed time. When the switch is turned On manually it prevents (Disable) the motion program from triggering at all or terminates the Program (Disable) if it is already in the Wait. If Control 'Front Porch Switch' is switched On And Control 'Front Porch Switch' is not switched Off Then Disable Program 'Program 2' Else Enable Program 'Program 2'

Sorry, my bad. As soon as the Program turns the switch On and executes the Wait the If is reevaluated because the Status of the switch has changed, executing the Else so the Set switch Off is not executed. Needs to be broken into two Programs to prevent the change in switch Status from cancelling the Set switch Off. I'll post something else tomorrow or someone else with a working example can post tonight.

“What I am hoping to do is find a simple program that will allow me to turn the light on manually with the switch and stay on until the switch is turned off.†Nothing special needed for this part. No Program required. Either the switch controls the load directly or if an n-way configuration, a single ISY Scene with all the switches which participate in the specific n-way are Controllers in the ISY Scene. “I want to also have the motion sensors turn them on for 10 minutes when the switch is off. If during that time I turn the switch on, the lights should stay on until I turn it off.†The Motion Sensor(s) do not directly control the switch(s). A Program detects the motion On message and does something (or not) based on the state of the switch. If the switch is Off when motion is sensed the Program turns the switch On. If the switch is already On nothing happens. If the Program turns the switch On, it Waits 10 minutes and turns the switch Off. If the switch is turned on manually before the Wait 10 minutes completes the Wait is cancelled by the Status change of the switch and the Set ‘switchx’ Off is not executed. The switch has to be turned Off manually. If Control Motion Sensor – Sensor is switched On And Status ‘switchx’ is Off Then Set ‘switchx’ On Wait 10 minutes Set ‘switchx’ Off Else