LeeG

It would be good to post your actual Program. Right click Program name, select Copy to Clipboard and paste to the forum. Did you add the parens as noted earlier by someone If From Sunset To Sunrise (next day) And ( Elk Zone 'garage1' is violated or Elk Zone 'garage2' is violated ) Without the parens the Elk Zone is not included in the Time range check. EDIT: also the statements in the Else run when the If is False which means they run day and night, any time the Program is triggered and the If is False. Requires using two Programs so the Wait is not bothered by the If reevaluation. Was the Program broken into two Programs

Sorry, I should have been more clear. A message with Max Hops=1 Hops Left=0 is great. It means the device message made it from the device to the PLM on the first attempt. A message with Max Hops=3 Hops Left=0 is bad. Also situations where Max Hops=3 and Hops Left=x count is varying from message to message is an indication of problems. Finding Insteon comm problems is a challenge. I always suggest starting at the beginning. Be sure the PLM is plugged into an outlet, not a surge/noise suppression power strip. Other electronics powered from the same circuit (PC, UPS, etc) as the PLM should be isolated with a FilterLinc. Then start analyzing communication with various devices around the Insteon network. Using the Admin Console with the Event Viewer running at LEVEL 3, turn various devices On and Off and watch the Hops Left=x counts. Messages from the PLM will have Max Hops=3 so Hops Left=2 is the best, Hops Left=1 is okay if the count remains consistent over several command executions, Hops Left=0 does not leave any room for additional sporadic noise or signal absorption. As mentioned before if Hops Left=x count is changing from command execution to command execution to the same device, that indicates problems even if some have Hops Left=2. It is common to have some change in Hops Left=x count if enough commands are sent. By analyzing what devices have good comm and what devices have marginal/bad comm a pattern may evolve. All the marginal devices are on one circuit for example would require looking at what is powered from the circuit. It can be useful to unplug (not turn Off) appliances/devices to see if that improves comm on a particular circuit. Some cell phone chargers have been known to destroy comm in the area where they are plugged. Other devices can cause the same type of problem. The first thing is determine how well comm is working around the structure and then evaluate what is causing problem areas. Not a particularly fun project and time consuming but there are no good Insteon based devices for Insteon network analysis. Some of the X10 tools can be used to measure the noise level. Insteon is on a different frequency and Insteon messages start earlier in the AC cycle but I have used an X10 Monterey Powerline Signal Analyzer to successfully locate noise. It is an expensive tool from my attempts to get X10 to run many years ago. Only if you already have something like that. I would not suggest getting one for Insteon.

redsfancfp The ISY Program characteristic that is key here is using Wait and/or Repeat statements allows the Program If section to be reevaluated when something the If is checking has changed. Without a Wait or Repeat statement the If section is not reevaluated. The change in state/status often results in the If going from True (running the Then clause) to False (running the Else clause). When this happens the statements after the Wait or Repeat in the Then clause are not executed. One solution is to split the single Program into two Programs where the If in the second Program has nothing to be reevaluated. Another solution is to add logic in the Else clause that executes when the If reevaluation drives the Else clause. It is the possible reevaluation of the If when a Wait or Repeat statement is used that is the driving force. Whether additional logic is added to the Else or the single Program is split into two Programs with nothing in either Else clause are two of the possible solutions. Understanding the implications of using a Wait or Repeat statement which allows If reevaluation is most important in understanding how to code ISY Programs.

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.