oberkc

First, status of a program represents last run. If last program run is true, the program will stay true until run again AND false. Second, your condition "Control 'Living Room- F' is switched On" will trigger only by an ON command and, thus, will ALWAYS run true. There is no way this program can ever be false.

That devices so listed have changes that need written. I would right click on one of them, and choose "write changes...". If any remain, do another in the same way.

The ability to set responder levels different based on the specific controller is considered a "feature" of insteon. For example, switches A and B can both be controllers of switch C. When switch A is pressed, C can be programmed to come on at 50%, but when switch B is pressed, C can be programmed to come on at 100%. It is the very foundation of scenes. The point of confusion, in my mind, is that when one introduces a controller/PLM, what may not be obvious is that the PLM is actually a controller of each device and each scene, in addition to any other device defined as a controller within a scene. When you set the responder levels at the scene level, you are, in effect, telling the responder to turn to those levels when controlled by the PLM. This has no effect on the same responder when it responds to a controller other that the PLM. Insteon would be much less flexible without this construct.

It will also be good to know to which of your switches are the lights connected. The program statement, I recall, takes the general form: In scene [controller device] set [responder device] to XX% Given that you have three controller switches, I expected three such lines in your program. If the lights are connected to more than one switch, I would expect even more such program lines. I am only speculating, but assume that the "write changes to all...." statement enables updates to all affected devices. There are more than, one, I have always believed.

LeeG and apostolaksl have both offered what appear to me to be viable alternatives. I have seen no indication from you that you have tried them. Have you? While this is, technically, true, perhaps you missed a detail in the response of the others that you CAN set a device to turn OFF in response to an ON command from the motion sensor. Given this, perhaps you may reach an alternate conclusion whether one can use a scene to turn off the bathroom light from the hall motion sensor. Slow down, please. Read the responses carefully. Folks here are taking the time to try to assist and offering useful suggestions, but it does not appear (at least to me, from the responses) that you are taking the time to comprehend what they are saying. And, to be clear, if you try their suggestions, be sure to get rid of the programs (or at least disable them) so that they do not interfere with the performance of the scene. Great. This is how I would do it, also. Which will not happen if all you have is a single scene (and no programs) with the motion sensor as controller and bathroom light as responder, with the motion sensor sending only ON commands. Great. As others suggested, create a second scene with hall motion sensor controller (set to send only ON commands) and bath light as responder. Set the responder levels, when responding to this motion sensor, to zero. Again, make sure you have no programs running in the background.

I looked on previous posts and do not see where you asked that. The line being necessary or not has nothing to do with it being a motion sensor. (Stusviews response is the same as I would have given.) My sense is that you are trying to run before you can walk, and you will continue to have a system that will continue to behave in ways that surprise and frustrate you. My suggestion is to slow down and take this one small step at a time.

I see no rationale in the wiki explaining why a scene was used in one case and a direct command in another. Such decisions, ultimately, are based on what one is trying to achieve. In this case, I suspect this is an oversight...mturn lights on....turn same lights off. I would have used a scene in both cases unless I am missing something.

And, by the way... Yes, I have used Unix (and DOS). I have not hear to the term you use. Sorry. I hated Unix. I found it completely unintuitive, with commands based on words not used by normal people. The one I specifically got a kick out of was "cat", which I guess was short for "concatenate". I still don't know what that means. I will take your word for the fact that things can be visual without loosing function. My concern, however, is that most of the devices designed for the "masses" are, in my mind, dumbed down. I use examples such as the hub, iris, IFTTT, things like that. My perceptions, perhaps mistaken, is that they lack the flexibility and power that I experience with the ISY. Perhaps there is a way to combine power with simplicity or with a more visual interface, but I also suspect that there is a relationship between power and learning curve. I think there is a reason that microsoft paint is easier to learn than adobe photoshop. Audacity is easier to learn than FinalCut Pro. I just don't see many examples out there that are both simple and powerful.

I am concerned that you are, indeed, mistaken. They are not the same in the ISY world. As an aside, these statements are not a term of status...they are a statement of an event. There is a "control" word as part of the statement that you omitted. This is important. Also, as you get into "status" statements (as opposed to "control" statements), consider the possibility that ON = 100%, whereas NOT OFF is anything over 0%. This distinction can be important for dimmer switches. Control Switch not off is triggered by an OFF command. Control Switch on is triggered by an ON command. That is one difference. Control Switch not off is FALSE when triggered. Control Switch on is TRUE when triggered. That is another difference. Take the simplest of examples... if control switch is not off then do something else do another thing This program will be triggered (if condition evaluated) only when the switch paddle/toggle is turned off, and always when the switch is turned off. It will NOT be triggered by turning the switch ON. It will not be triggered by dimming or brightening the switch (if so capable). Once triggered, the condition will be evaluated. This particular condition will ALWAYS evaluate as false when triggered. It will never evaluate true. Since it will never be true, it will never do something. Since it evaluates false, it will only do another thing. Compare to this program... if control switch is turned on then do something else so another thing This program will be triggered only when somebody presses the switch ON (compared to OFF in the prior example). It will not be triggered by turning the switch OFF. It will not be triggered by brightening or dimming. Once triggered, the condition is evaluated and will ALWAYS evaluate TRUE. Since this program is only triggered by an ON command, and when triggered, always comes back as TRUE, this program will never do another thing. It will only do something. Combining the two statements into a single IF condition... if control switch is on and control switch is not off then ..... else ..... Such a program will be triggered by BOTH ON and OFF commands from the switch. The condition is evaluated when triggered, regardless of whether by an ON or OFF command. Once triggered, the evaluation results will be based on both statements. This is where it is useful to understand basic logic statements. In this case, you have two statements (calling them statements A and B, for brevity sake). If A and B are true, then the condition is true. If A is false, the condition is false regardless of B. If B is false, the condition is false, regardless of A. Both have to be true for the condition to be true.

Which is a great point. Really, there is no typing when creating a program. It may not be "drag-and-drop", but it is far from manual data entry. That is kinda visual, yes?

I would like to see some sort of visual programming be implemented for the 'average Joe people' (maybe in reality I am an average Joe). A drag and droip inteface. When I see these types of comments, I often get a chuckle. I am not even sure who is the average joe anymore. Is this the person who is helpless if the car breaks down and extent of household repairs is limited to changing of light bulbs? If so, then, yes, the ISY (and home automation in general) is probably not for such a person. When I hear folks asking for a more "visual" interface, it saddens me a little. Are these average joes the ones who cannot comprehend the written word and need pictures to understand things. It seems so many of the instructions I see anymore are all picture-based. Really!? Are we that stupid that the only thing we can understand are pictures? Part of the complications of programming is that computers are the ultimate engineer. They will do exactly what you tell them to do. Every time. But the downside is that they will do exactly what you tell them to do, and no more. One must be very specific. I am not sure that visual approaches will solve this unless some flexibility is lost. Enough of the political commentary...to your specific question.... The example program is a typical ISY example that is the solution to the question: if the switch is turned ON, to this....if the switch is turned off, do that. THe reason you need both is because the first statement is triggered (event) only by an ON command. The second is triggered only by an OFF command. If you want a program to respond to both, you must include statements that are triggered by both. To LeeG's response, I add that the CONTROL IS TURNED ON statement is triggered by an ON command. The CONTROL IS NOT TURNED OFF is triggered by an OFF command. When the first statement is triggered by the ON command, that statement is TRUE. At any other time it is evaluated, it is FALSE. When the second statement is triggered by the OFF command it is FALSE. Any other time it is evaluated, it is TRUE. So, lets say somebody turns the switch ON, triggering an evaluation of the entire (two statement) condition. The first statement is TRUE. The second statement is TRUE. Therefore the complete condition is TRUE (runs then path). If somebody turns the switch OFF. The first statement is false. The second statement is false. Therefore, the complete condition is false (runs ELSE path). The reason such constructs are useful is that it allows (contrary to your observation) single programs to achieve what would otherwise take multiple programs. Similar logic can be used to differentiate when a switch is turned ON from an OFF condition, versus when it is turned ON from an ON condition. As you get into this, it will become more intuitive. It is, simply, one has to learn a new language. It is necessary to understand precisely what is the meaning and consequences of each statement. Fortunately, the vocabulary is limited.

One of the things that could be unclear is that CONTROL triggers a program each time pressed, but whether or not the program condition is true is based on the entire condition. For example: if control switchlinc is switched on and time is from sunrise to sunset then ... else .... this program will be triggered each time the switchlinc is pressed ON, but would be false if outside the specified time range. As as further point of clarification, this program will also trigger as sunrise and sunset, but will also evaluate as false, since there was no simultaneous receipt of an ON command from the switchlinc (both have to be true for the entire condition to be true). Compare to status if status switchlinc is on and time is from sunrise to sunset this program would be triggered if the switchlinc changes status. The program condition would be true when the switchlinc is changed to ON and between the specified times. Unlike the first example, however, this program will evaluate as TRUE at sunrise if the switchlinc is ON. Sometimes, one has to just practice with things.

Mostly, I would describe the difference as what causes the two conditions to trigger and force an evaluation of the condition in which they are included. STATUS will trigger an evaluation upon any change in status, and for any cause of that change. CONTROL will trigger an evaluation only upon receipt of the specified command and ONLY when that command is initiated from the specified device. For example, CONTROL DEVICE X IS SWITCHED ON will trigger only upon receipt of an ON command from DEVICE X. Another factor is that, for condition evaluation purposes, STATUS will yield TRUE any time the specified device matches the stated value. CONTROL, on the other hand, will only yield TRUE when that specific condition is received (otherwise, it will yield a false value).

To the other replies, I will add/emphasise (if not already clear from Mwareman's post) that one needs to worry about programs halting only when there is a WAIT or REPEAT statement. Otherwise, programs will run to conclusion and not be interrupted when a condition is triggered.

What do you want to happen if it is sunrise and light if ON? Do you always want the light to be ON, starting at sunrise, regardless of the state prior to sunrise? What do you want to happen if sunset and light is already off? Stay off? If so, one program is fine. if from sunrise to sunset then turn on light else turn off light There is no harm in turning ON a light that is already ON, and OFF a light that is already OFF. Keep things simple, I say.

I second the suggestion to get the z-wave version. While I have been happy with insteon and intend to continue using it, every once-in-a-while I see zwave devices that are good deals. It is nice to be able mix and match and take advantage of sales and clearances. And, at the risk of starting another discussion about security, I prefer the options with z-wave-enabled locks.

I use the same approach as larryllix. Just be aware that when you call the second program, make sure to choose IF path: Run second program (if path)

Your understanding that single-band devices should not be affected by RF issues is the same as mine. That "monster" power strip concerns me. Is this a surge suppressor or some type of power conditioner? I think it a possibility that this could be a contributor to some comm issues. You may want to consider replacing it with a simple power strip without any electronics or suppression capability. I would also tend to filter UPS in general, regardless of circuit, as a preventative measure. Once filtered, I would keep the power supply of the ISY on the UPS rather than move it to the same circuit as the PLM.

I have found the built in log of the ISY sufficient for any desire I have to track device activity and history. Yes, it can be exported to an excel file. I did nothing to enable this, it tracks these events without any action on my part, so I consider it automatic. I perceive that it tracks every communication event, either to or from the ISY.

Does it run at the same time every night? If so, perhaps this might be a clue as to the cause. (Specifically, I wonder if ithis is being triggered by a nightly query or some other programmed event.)

My experience is that programs, themselves, do not fail. I consider it more likely that the ISY/PLM is no longer seeing the communication from the switches. This seems to be supported by the fact that your event viewer is not seeing the commands. I would treat this as a communication problem. I also believe you can focus on two major possibilities: - something is messing with your powerlines or RF comms - link records in switch, PLM, or both become corrupted. For the first concern, ensure you have a good, clean circuit on which your PLM resides. No other electronic gadgets allowed, unless filtered (my rule). Be sure, also you have good communication between legs of your electrical system. For the second, my temptation would be to peform "show links table" option for one of your switches and "compare". If there is a mismatch, make a judgement about whether the mismatch is due to loss of links on PLM side or device side. It seems there is lots of talk around here lately regarding PLM failures and the loss of link records. I understand your PLM may actually show NO LINK RECORDS when these begin to fail. So...yes, this could be another bad PLM. It could also be one of those random, unexplainable things that happen from time to time. Restoring the PLM or the device can often solve these. I am not absolutely confident about this, but the fact that your device responds to queries suggests to me the link records are intact and you should focus, instead, on pure comms issues. I would not spend any more time trying to fix the program, itself. I don't believe this is the cause of your problems.

I see no programmatic reason why your program would cease working. My experience is that programs ALWAYS run. The only problems I have experienced is when the ISY does not see accurate device status for whatever reason, and programs don't trigger as a result, or that a program runs, but something interferes with the communication with the device commands from the program. Given what you have described, I would check a couple of things. What time does the ISY think it is? I recall examples where the clock time on the ISY can be inaccurate. When you ran the IF path of your program, did the program listing show that the program last ran at that time? If so, does it show TRUE or FALSE? If FALSE, this suggests that it ran the ELSE path, rather than the THEN path. What happens when you manually run the THEN path, with the same conditions that you originally ran the IF path? Does everything respond as you expect? I suggest this to check to see if the ISY is not communicating to the devices, for some reason. Definitely check the ISY status of the '07.2 Den Bk A Patio Lanterns / 07.2 Den Bk G Garage Door'. It may be lit, but something may have prevented this information from reaching the ISY.

I must admit that I have not run into any programming limitations because of this, but (yes) it could drive separate programs or variables or some combination of the two. I have never "run out of programs" by creating too many, but have sometimes chosen to put related programs in folders for organizational purposes. I have, personally, found TRUE and FALSE to be sufficient as is and have never wanted for the ability to know when a program is in a wait state, but I may not be trying overly-complicated programs as you may be. There are some pretty creative folks around here. Perhaps you could post an example of what you are trying to accomplish and someone may think of an approach that you like better than the one you currently use. To answer your original question as to how to detect if a program is active, I would probably use something as simple as: if whatever condition you want then set active variable to x do something wait a bit do something else repeat, shake and stir set active variable to y else set active variable to y it seems to me that when active variable is x, the program is active. When it is y, then not.

"I am still having trouble determining how to programatically detect a Program who's IF logic is TRUE but is not actively Running when it should be. In the attached file screenshot you will see Program "Hall HAL Monitor 1CON" the program is true as indicated by its Color Status, however its WAIT condition is not active therefore the program will never perform the actions after the WAIT should have expired. In other words it is IDLE but TRUE if you look at it in Summary.​" Perhaps others have already explained this (but I missed it). A program will show status of TRUE if it ran THEN path last. That status will remain TRUE indefinitely, or until it runs again and runs the ELSE path, at which point it will show FALSE and will remain FALSE until it runs again...etc.., Unless interrupted, the wait statement likely ran, followed by the subsequent commands. The fact that it is TRUE but IDLE is not an indication that the program will "never perform the actions after the WAIT". In other words, a program does not have to be "active" to be true. The status is simply an indication of which path it last ran.

"For low action background devices they work just fine. eg. China cabinet light, Christmas tree lights." I use x10 only for temporary (holiday) stuff or outdoor applications where I still have those B&D modules. I argree that I would like a chime, but I never had any x10 versions of those, either.