oberkc

It should be satisfying. It demonstrates your ability to think and to reason. Such skills put you near the top of your class.

I was, like fitzparti8, thinking scenes, but was not smart enough to come up with the correct combination. I kept thinking "a device can be controller of only one scene, but a responder in many". Looking at his response, I would amend as follows, for clarity: While you could do this with programs, I prefer scenes when possible. The are not reliant on the ISY, and they are quicker. This is consistent with my earlier explanation, I believe. Your program would never execute the "else" path, because it only triggers upon receipt of an "on" command, and always evaluates as true. Yes...it sounds like you have a good grasp of how this works. That is why I was looking for a better explanation than "This didn't work and neither did using the status".

I may be overlooking it, but I see five programs, labeled programs 1, 2, 3, 4, and 5. I see no program labeled "A2.BackYard Lights on 3 Minutes" or 'A1.BackYard Motion Sensed'. I see no device in your program called "back door light" What are the folder conditions?

I think, indeed, that you correctly answered your own question.

I think, actually, you are pretty close with your attempt. Please confirm which program is "A2.BackYard Lights on 3 Minutes" and which is 'A1.BackYard Motion Sensed'. Please, also, confirm that none of your devices are in any scenes.

No. How did this not work? Did it turn on, but not off (this is what I expect from the program shown). I am a little surprised that the status did not work, at least a little bit. A couple of thoughts from the program displayed.... It will evaluate any time that "Kitchen All" is switched on, and only then. It will always evaluate true, and never evaluate false, therefore, the "else" path will never execute. If the "kitchen front" did not turn on, open the event viewer (under tools), manually turn on "kitchen all" and see if the event viewer shows receipt of this command. If the "kitchen front" turned on, but did not turn off, add a second program: If Control 'Kitchen All' is switched Off Then Set 'Kitchen Front' Off Else

I would start off by defining, in english, what it is you want a program(s) to do, such as: a. motion from either of two sensors, A and B, triggers both lights, X, and Y, to come on for three minutes, then turn off. b. any new motion sensed restarts three-minute clock c. motion-triggered lights are active only between sunset and sunrise d. if either of the two lights are manually activated, they will remain on, indefinitely, until manually shut off. e. both lights will turn off automatically at 30 minutes past dawn, each day, regardless of how activated. f. double tap (fast off) will disable motion-triggered lights. Please modify and augment, as necessary. I consider it bad practice to program before having a complete understanding of requirements. No, unless you have included the MS in a scene.

disabled simply means that the program will not evaluate or execute on its own.

Hopefully, you can get the update and recognize your devices. Normally, when you add a device to a scene, it will give you the option to add as controller, or responder.

I see a problem with your first program, at least. For it to ever be true, ALL conditions must by simultaneously true (because of the AND statements). I doubt this will ever happen. I suggest the following changes to your first program, at least: If From Sunset To Sunrise (next day) And ( Control 'MS Garage' is switched On or Control 'MS House' is switched On ) And Status 'Back Porch Light' is not On And Status 'Garage Light' is not On And Program 'A2.BackYard Lights on 3 Minutes' is False Then Run Program 'A2.BackYard Lights on 3 Minutes' (Then Path) Else - No Actions - (To add one, press 'Action') Regarding program 4, it appears to me this one will rarely evaluate as true, since both controls must occur simultaneously (very unlikely). Furthermore, if it did evaluate as true, it would disable your motion sensor program. What is the purpose of this? Given your description (double tap disables the motion sensor), perhaps you would be better with: If Control 'Back Porch Light' is switched fast Off <<<"fast off" is double tap or Control 'Garage Light' is switched fast Off <<< "or" allow either condition down "then" path Then Stop program 'A1.BackYard Motion Sensed' Disable Program 'A1.BackYard Motion Sensed' Run Program 'A2.BackYard Lights on 3 Minutes' (Else Path) Else - No Actions - (To add one, press 'Action') I also wonder what devices are in your scene 'BackYard Lighting'

I would expect the answer to this to be no, unless your program is now looking for something new from the motion sensor that is disabled by jumper settings. Otherwise, program changes require no change to individual insteon device settings, including those of a motion sensor.

In case you did not know, the ISY supports X-10 also. There is little reason to abandon your X-10 equipment if it is otherwise working. My perception is that many folks around here still use X-10 to some degree.

I would like to confirm LeeG's response. Unfortunately, yours is the type of wiring that falls a bit short for insteon retrofit. In general, you need hot, neutral, and ground at each switch location. In addition, you need a way to supply the fixture with switched power. I also believe you will need an extra conductor between fixture and switch. Otherwise, you could use an inlinelinc.

This is as it should be. Turning a switch on via ISY does not affect any scene controlled by that switch. If you want the whole scene to come on, you must so specify. I have read through your various scenarios and am not convinced that anything is misbehaving from a communication standpoint (though it still may be). I think it a real possibility that there are simply a lot of variations on the status as a trigger. I still think you should try temporarily disabling the query program, and changing your timer program to: If Control “Upstrs Bathroom Remote Swlinc†is turned On Or control “Upstrs Bthroom Sink Lites†is turned On Then Wait 30 minutes and 10 seconds Set Scene “Upstrs Sink Lites†Off Else - No Actions This program is triggered only upon reciept of "on" commands, and triggered upon receipt of every "on" command, regardless of prior device status or prior scene status, or prior program status. See if this works. If so, get rid of the query program. You won't need it.

Regarding part 2, scenario 1... I continue to be a little surprised that the timer program kicks in after the manual query. The ISY status for the light was confirmed on prior to the manual query. Running the query returns an "on" statement (did you confirm the ISY light status AFTER the query?). This does NOT constitute a CHANGE in status, therefore, I would not expect any evaluation of the timer program to occur. Perhaps I don't understand the relationship between what you call "the light", the device "upstrs bathrrom remote swlinc", the device "Upstrs Bthroom sink lites", and the scene "Upstrs Sink Lites". I have been assuming that the two devices are part of the scene, and that "the light" is one of the two devices. I must conclude that I don't understand program triggers as much as I had thought. BTW, I expect the timer program status, while interesting, to be irrelevant to your problems here. The scenerio 2 is consistent with my prediction of how this program should behave. It does not surprise me that the timer program does not kick in after running the query program, since there appears to be no change in status. The only thing that I can think of (regarding your programs) is that one of your two devices ("upstrs bathrrom remote swlinc", and "Upstrs Bthroom sink lites") is, somehow, changing status throught scenerio 1. I am curious which of these two devices actually controls "the light" and as to the relationship between this one and the other. fitzpatri8 had a good suggestion regarding GFCI outlets. I believe I have read that these can interfere with powerline signals. Are your two insteon devices downstream of a GFCI outlet (many baths are wired this way)? If you are unsure, you can check by pushing the test button on the GFCI. If you insteon devices loose power, then they are downstream and limited by the outlet's ability to pass insteon signals. I also don't know the exact devices in question here, but have you looked to see if there are dual-band replacements for these two? If so, I wonder aloud if this may alleviate much of your communication problems.

Very likely the latter for both of us. Regarding scenerio 1, last bullet....I am actually surprised that the timer program kicks in. Since the light was already on, running a query would yield these results, with no change in status detected, and no program evaluation conducted. The only explanation that I can think of is that the ISY thinks the light started as off. Did you check the ISY-assumed status for the light prior to performing the manual query? Understand that it is possible for a light to be physically on, but the ISY think it off (and vice versa). I am still unclear whether you checked ISY status for these devices. My suggestion is to confirm ISY status for both light and swlinc prior to running these two experiments again.

I am only theorizing, but how did you add the remotelinc to the ISY? Start Linking? Manual? Is it possible that the ISY thinks this button is something other than a remotelinc? My understanding is that remotelincs cannot be queried or commanded....they only send commands. The ISY understands these limitations, so the fact that it is trying (and failing) to communicate makes me suspect that the ISY has this device identified as something other than a remotelinc.

I understand manual and programmed queries to yield the same results. Did you happen to notice whether the status of your light was changed? Programs based on status only evaluated if the status CHANGES. If your light status already showed "on", and the programmed query resulted in "on", then there was no change in the status, and the program conditions would not evaluate. I am unsure about whether device status is more or less reliable than reciept of device control signals, but you may give "control" a try as a condition of your program, rather than "status". Perhaps you will find it more reliable. Also, while I share your suspicion of the various power supplies being a problem, I feel compelled to ask what are your bathroom lights? CFL? Low voltage? LED? Is it possible that the lights, themselves are contributing to the communication problems?

I am not familiar with the "x10 security system", but assume it broadcasts X-10 messages at defined security events, correct? If so, you can use these X-10 messages as triggers for ISY programs to perform any action within the capability of the ISY, including email alerts.

My experience is that these surge suppressors can attenuate powerline signals, including X-10. Can you temporarily unplug the surge suppressor? What is plugged into this suppressor? Lots of power supplies? Computer? If you can determine that this contributes to communication problems, a filter would likely solve this. I still use a few X-10 devices, also. In a few situations, I prefer them.

There are often intermittent conditions which could cause communication issues, especially if your normal condition is marginal to start with. There are likely devices in your house which run only some time, such as washers, dryers, refrigerators, HVAC, water heaters, etc.... Perhaps you have some noisy fluorescent lights which are not always on. Perhaps this is why one of your devices fails some of the time and not all of the time. If you have insteon devices which turn on reliably, but not off, it is possible that the load is causing problems (CFLs, low voltage lighting). I also could not tell whether your troubled device is part of the scene in which you tested. If not, then run a test on a scene that DOES include the troubled device. I understand the scene test to be less than fully 100% conclusive. Rather it is a general representation of the communication between the PLM and devices within the chosen scene. It does not offer any troubleshooting ability, in terms of identifying problem-causing devices on your electrical system. I don't know your system. I assume you have access points or dual band devices or some means of coupling your electrical legs of your house, correct? Is your PLM plugged into an outlet or circuit that includes lots of other electrical gadgets, such as the computer and related electronics (UPS?).

So you have one attempt at a scene test that failed, and one that passed. I take this as less-than-ideal communication. One thing I like to do during scene tests is watch the event viewer. I have found that when communication is good, events occur at quick, regular intervals. If one sees delays, this is a sign of potential problems. Otherwise, it looks as if the scene test confirms your experience. You have one device that sometimes fails to responds. You have a scene test that sometimes fails. If it were me, I would begin the trial-and-error process of fault isolation.

This sounds pretty conclusive....for some reason the signal is not getting from the original location to the PLM. Are your electrical legs coupled somehow? Is your PLM plugged into a location that includes computers, UPS, power supplies, surge suppressors, etc....?

I agree that it shouldn't be this hard. My worst case so far is that writing changes to multiple devices would get only part-way complete. At that point, again (a second or third time) selecting the option to write changes completed the task. I am assuming you have no RF devices that require enabling the link mode in order to accept changes?

You can use dates as program conditions. Is this what you are asking?