oberkc

What you are suggesting should not mess with the ISY. Just so you know, it has never been overly complicated to control insteon with a harmony remote, hub or other, or any other IR remote. Insteon makes an IRLinc, and some versions of the ISY have an IR receiver. It did not take me very long to have the ISY recongize button presses from a remote control and perform a programmed action. If the goal is, simply, to have the insteon house react to button presses on a remote control, this is quite doable and has been for some time.

pretty cool video. Thanks.

Xathros' idea is a good one. Another option, if it doesn't conflict with other uses for scene "first floor lights" would simply be to keep the keypad button as non-toggle-on, but include that same button in the first floor lights scene. When that scene turns off after the 1 minute wait, then the button would turn off, as well. This has the potential value that when the keypad button is lit, you know the timer is active.

Battery devices, such as the motion sensor, do not constantly listen for insteon signals. This is to save battery life. The exceptions to this are when motion is sensed, when the set button is pressed, and when the battery is replaced. I wonder if replacing the battery allowed the ISY to write the now-correct settings to the motion sensor?

Answered in the post from LeeG, just above. You didn't. You chose the motion sensor as controller. The responder is the switch called "bathroom big micro dim" and it will respond with an ON level of zero.

No, it does not appear that you are understanding. Within each of the two scenes in your screenshots is a device in red. This is the controller of that scene. Click on that controller and see what are the responder levels. I am betting that the responder to the hall motion sensor is not set to zero.

I am with apostolakisl...I am uncertain what you are trying to accomplish and how this fails, if at all. If important, be aware that having a button in non toggle mode affects only what happens when the button is physically pressed. It does NOT prevent a scene command or direct command from putting in the opposite state.

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.