oberkc

No need to change the IOLinc. Change only the sensor. I don't remember "normally open" or "normally closed", either but understand you need the opposite type that came with the kit. My educated guess is that you would need a NC type so I believe your $5 sensor would work. BTW,I assume normally closed switches are those that are closed in the relaxed state...that is, when gap is wide. Hopefully, others will correct if I have it backwards.

When you delete the program, does it disappear from the list of programs along the left side? When you later log in has the program returned? When you delete the program, do you "save changes"?

I assume this is, simply, cut from my earlier suggested program (post #. Yes, the syntax is probably inaccurate and should be "switched" on. I also assume "device" and "dimmer button" are synonymous. stusviews...I suspect the statement in red is also left over from my earlier suggestion (post # and no longer applies, given the additional statements in the condition that you correctly point out would also trigger a TRUE result.

I expect that this will work. I don't think the ANDs and ORs and parentheses are too critical here, but test it out to confirm it does what you want. I think it will.

For CONTROL DEVICE XXX statements, they will trigger an evaluation only when the device is acted upon manually, and only when the specific XXX is recieved and will always evaluate TRUE when triggered. IOW, Control Dimmer is ON will trigger only when the dimmer button is pressed directly and only when pressed ON. OFF will not trigger it. DIM or BRIGHT will not trigger it. Additionally, CONTROL DEVICE IS NOT XXX will only trigger when the XXX command is received and will always evaluate FALSE when triggered. If you want a program that disables a program when a dimmer button is pressed ON and enable a program when pressed OFF: If Control Dimmer Button is ON <<<will trigger from ON command and evaluate true...all other times be false and Control Dimmer Button is NOT OFF <<<will trigger from OFF command and evaluate false...all other times be true then disable program else enable program If not obvious, a condition with multiple statements will trigger and evaluation when any of the individual statements are triggered, but the entire condition will be evaluated. So, when the ON command is received, the first condition triggers an evaluation, but both statements must be true for the condition to be true (AND) and runs THEN path. When the OFF command is received, the second condition triggers an evaluation, and if any of the statements are false, then the entire condition is false and runs ELSE path.

Whether or not you need it depends, I believe, on whether you are going to take advantage of "mobilinc connect", or make all the router settings yourself. If you are good with a router, ports, IPaddresses, and things like that (or are willing to learn), then I say skip it. If ease of setup is priority and cares about reliance on the cloud are minimal, then perhaps you should consider mobilinc connect. Moblinc connect has a monthly fee, I believe. I also understand it may have a few extra benefits. Personally, I do not use it. Be aware, also, moblinc for iOS is, apparently, a different experience than mobilinc for android.

Regarding control versus status, both are useful, but I would focus on what triggers a control/status statement and what does not, then understand that, once triggered, whether it is true or false. As far as disabling a program, yes, another program can disable the first. You need to decide under what conditions you want the program disabled. When someone turns on a switch (is it a dimmer or relay switch)? When someone turns off a switch? When a switch achieves a certain brightness level? When somebody dims or brightens a switch? Are there multiple switches involved? Rather than offer specific solutions, I suggest you simply decide what actions you want to cause a program to be disabled and we can go from there.

My understanding is the same as LeeG. Any retriggering and re-evaluation of a program will interrupt a halt or wait statement. In different words as LeeG, this is because such a statement is only triggered once per day. This condition is not triggered at 5:31 or at 5:32, or at 5:33. It is never triggered at any time other than 5:30.

That sounds like good advice. I am sure the one who recommended it is wise and good looking. I just wanted to point out (in response to your thoughts on integration between the harmony and ISY) that there is already integration to some degree. Just because the integration does not happen via the ethernet cable does not mean that it does not exist. There are more than one way that devices can communicate. IR is one such way. When it comes time to tackle this aspect of your home control, rather than starting with solutions (official hub support of the ISY), instead consider WHAT you want to do (control a light with a remote button). It is very possible that this can already be done.

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.