apostolakisl

Not to be outdone by ostrypuch, I have photoshoped up a diagram. What you see here is the user console. It is actually two programs but ISY shows it to the user as one program. The highlighted areas would not be shown to the user but would still exist on the back end.

The logic already exists in ISY (you can create the exact same results by using 2 programs). What it would require is the ISY developers creating the programming interface such that, hidden in the brains of ISY, the multiple program language is written based on the logic expressed in the above faux screen shot. I hope that sentence made sense! So, specifically, when you uncheck that box, ISY internally creates two programs. -The second program contains the if/then/else where the "if" stuff is not the trigger. This program is internally disabled (but it wouldn't show you that). -The first program contains the "trigger" in the "if" section and the "then" section says "run if statement on second (disabled) program". But ISY only shows you the "if" section of the first program (but lables it "trigger") and the entire second program as per usual.

Using the little boxes and having them default to checked means, that for the most part, programming ISY would be exactly the same as currently. Unchecking the boxes would be available to those who want to venture into it. And I think I may have made it too complex to have a "condition" box and "trigger" box since I can't think of any logic that would allow something to trigger a program and not at least be an "or" condition. So just one box needed, a "trigger" box. Using a separate "trigger" section would require that you have to write your conditions twice for the majority of your programs. It would sort of be like the current situation where you use two programs. Along those lines, perhaps a solution to this issue that wouldn't require redoing the logic of ISY, would be to allow opening multiple associated programs at once on the same screen. It would be easier to keep track of what you are doing in the current scheme if you could see both your trigger program and execution program at once.

That would be very nice. Two little check boxes next to each item 1) use as trigger, 2) use as condition. They would default to being checked. My suspicion is, however, that doing this would be like throwing a gigantic monkey wrench into the guts of the ISY code.

Actually that was me with "super awesome ISY programmer" comment. Anyway, I thought I would summarize this "control is not" and compare to "is". Tiggering "control is" and "control is not" both act as triggers for a program exactly the same. For example, "if switch xyz is (or is not) switched on" acts as a trigger only when the switch is physically acted on by pushing "on". Evaluation 1) When the "control is/is not" statement is the trigger - "is" evaluates to true - "is not" evaluates to false (keep in mind that only physically acting on the switch in the way listed (ie "on") is a trigger, any other action on the switch is not a trigger and the program will sit idle short of some other independent trigger. 2) When something else triggers the program - "is" evaluates to false - "is not" evaluates to true (keep in mind that the status of the switch is irrelevant, on/off/dimmed/whatever. . .no difference) Simply put, "is" and "is not" behave exactly the same except the outcome (true/false) is opposite. So, it seems the usefullnes of an "is not" statement is to have the program evaluate to the opposite state as an "is" statement when presented with the exact same trigger. In a single line program simply swapping the "then" contents with the "else" contents is functionally identical to swapping "is" with "is not". In a multi-line program it might be easier to get the outcome you want using "is not" so that your "true/false" outcome more easily jives with the "true/false" outcome of the other conditions. I can not think of a situation where "is not" allows for an ultimate outcome that you couldn't get to in some other way, but, there it is, use it if you like it.

Here is the most important unique feature that I can see with the "control is not" It evaluates to "true" when nothing is done to the switch. In other words, if something else triggers the program it will evaluate as true (this is why it worked the same in the "and/or" situation previously discussed). This is in contrast to "control is" which evaluates as "false" when something else triggers the program and no action is taken at the switch. I am not sure how to use it exactly, dnr had pointed out that the there is no use for a statement that is always "false" (I agree), but we were wrong, this can be "true". I have a feeling that you could use this feature to turn what otherwise would have been two programs into one. It would probably not be worth the confusion, however, unless you were just super awesome ISY programmer.

I think theoretically at exactly 7:44 it would behave differently. If you used "or" and managed to turn the light "on" at the exact same instant as the clock hit 7:44 it would evaluate to "true" instead of "false". But I think that is only theoretical because I am not sure that ISY can process 2 things as happening exactly at the same time.

OK, now I don't get it. By my understanding this program should be false always. My new understanding is the "is not" terminology allows a "true" outcome if no action is taken at the switch and a second statement is "true". Would this program run differently if you used "or" instead of "and"?

dnl, "What is the intended purpose of a condition that can only evaluate to False?" The only possible purpose would be as a trigger of that program. In the event that you use an "or" statement with an "is not" control and something else, it will allow a "true" result if the other statement is true and a false outcome if the other statement is false. So, if you had some situation where you wanted the true/false status of the other statement to drive the result after controlling a switch to a particular state, this would do it. I can't think of when I would need that, but it is the only situation I can think of that the "is not" would be helpful. But, you could still get that same result by having two programs where the first program contains "if xyz is switched on" "then run the other program" were used. In short, I totally agree with you in that "control . . .is not" is poorly conceived. Edit: I just realized you can use "control . . is" combined with another statement using "and" to allow controlling of the switch to a particular state to trigger a program where the other parameter is in charge of the "true/false" outcome. So I now believe that there is no use for the "is not" in a control program at all.

I think dnl is right on the money here. In effect, this syntax creates a situation where using "is not" or "is" simply changes whether you put the desired action in the "then" or the "else". Except during the actual button press, "control" commands are always false whether you use "is" or "is not". This means that having the "is not" language does not affect a program differently than "is" language in the event that something else triggers it. So I am having a hard time figuring out when using "is not" would ever provide a function that can't also be done using "is". "is not" would be useful in the event that any action taken on the switch allowed for evaluation of the statement and a "true" response in the event that it were anything but the stated parameter (on, off, whatever).

Here are some sample programs and what happens. If Control 'Kitchen / Kitchen Intercom/Puck L' is switched On Or Control 'Kitchen / Kitchen Intercom/Puck L' is not switched On Then Send Notification to 'dr-apo' content 'then' Else Send Notification to 'dr-apo' content 'else' The above executes the "then" clause when you turn the switch "on". It does nothing when you switch the light "off" If Control 'Kitchen / Kitchen Intercom/Puck L' is not switched On Then Send Notification to 'dr-apo' content 'then' Else Send Notification to 'dr-apo' content 'else' the above executes the "else" statement when you switch it "on" Does nothing when you switch it "off. This follows with the logic as described by IndyMike. Not to be confused with If Status 'Kitchen / Kitchen Intercom/Puck L' is not On Or Status 'Kitchen / Kitchen Intercom/Puck L' is On Then Send Notification to 'dr-apo' content 'then' Else Send Notification to 'dr-apo' content 'else' Which executes the "then" no matter what you do to the switch. Of course it also executes the "then" if anything changes the status of the switch, not just physically pushing it. The following executes the "then" no matter what you do to the switch. If Control 'Kitchen / Kitchen Intercom/Puck L' is switched Off Or Control 'Kitchen / Kitchen Intercom/Puck L' is switched On Or Control 'Kitchen / Kitchen Intercom/Puck L' is switched Fade Down Or Control 'Kitchen / Kitchen Intercom/Puck L' is switched Fade Up Or Control 'Kitchen / Kitchen Intercom/Puck L' is switched Fast On Or Control 'Kitchen / Kitchen Intercom/Puck L' is switched Fast Off Then Send Notification to 'dr-apo' content 'then' Else Send Notification to 'dr-apo' content 'else' And this also executes the "then" no matter what If Control 'Kitchen / Kitchen Intercom/Puck L' is not switched Off Or Control 'Kitchen / Kitchen Intercom/Puck L' is not switched On Or Control 'Kitchen / Kitchen Intercom/Puck L' is not switched Fade Down Or Control 'Kitchen / Kitchen Intercom/Puck L' is not switched Fade Up Or Control 'Kitchen / Kitchen Intercom/Puck L' is not switched Fast On Or Control 'Kitchen / Kitchen Intercom/Puck L' is not switched Fast Off Then Send Notification to 'dr-apo' content 'then' Else Send Notification to 'dr-apo' content 'else'

I think the interupt feature is very useful, but, to the novice a bit unexpected. It might be a nice feature to have a way to "protect" a then statement from interuption, but I have found you can get around this by putting your "then" clause into a separate program that the first program calls. It protects the "then" from getting terminated by the "if" turning false, but it still won't stop it from getting reset if the "if" gets revaluated to true again. That works perfectly, but requires the user to know to push it. Having a light switch usage indicate that the house is occupied works no matter who walks in. It appears that kingwr thought as I had. I actually wrote that program first then tested it and it didn't work. That's what prompted the other thread. kingwr knows his ISY pretty well and I bet he will appreciate this little tidbit. I have yet to figure out how to make the tidbit useful, however. I am sure there is a situation. Thanks to Indymike on somehow having a brain that works backwards to know that.

I am not so sure that the motion sensor changing to "off" is an indication of someone being present, but if that is what you want, then I am starting to understand the approach you took. The only other question remaining in my mind is whether there would be any difference if you used "control" rather than "status" to track your motion sensors. In your case, based on my understanding, my guess is no. Thanks for the dialog. i found it interesting and enlightening. Some people enjoy Sudoku. I enjoy logic. I am hoping it keeps my mind fresh. I don't use my mind as much as I should. I don't have any insteon motion sensors, but I assume that they flip "on" when motion is detected and then after a few seconds of no motion flip "off". I also am going to assume that a motion detector changing state is a "control" command from ISY perspective (in other words, the same as physically pushing a switch). If your motion detector was working properly, I would think that having both lines about flipping "off" OR flipping "on" would be unnecessary since every time it flips "on" you would expect it to flip "off" a few seconds later when motion stops. But with it on the fritz maybe it gets stuck on way or the other and having both lines would help it to work better. When I saw your question, it basically made me think about using a regular switch as an occupancy detector. In other words, someone physically pushing it would put your ISY into an "occupied" frame of running. That means only using "control" in the if language since your "unoccupied" programs turn the switch on and off (which would cause "status" programs to erroneously put the house into occupied mode). So in short, I thought it would be nice to use the "is not" language together with "control" to mean that someone pushed the switch in any way (and thus the house has a person in it). But, to my surprise, "control" plus "is not" logic is not what I had expected. So, you would need to use multiple "control" lines separated by "or" for every possible physical action one might take at the switch (on,off,fade up,fade down). A program does not have to be enabled for another program to call its "then" or "else" section. Only the "if" section is shut down when a program is disabled. Thanks for the question, I enjoyed playing with it and learned some new stuff.

Mike, Thank you for helping me out with the logic. So it is, "Switched on" is the trigger and "is not" makes it false and runs the else. I am not sure how to use that logic right now, but perhaps it will find a place. It would obviously only be useful in a multi-line "if" section. A single parameter "if" statement would just use "is" and put the desired action in the "then" section. Lou

Not sure what happened here but this post showed up twice. Anyway, What you say, however, doesn't seem to be panning out. The then statement does not run when I put If switch xyz is not switched on and then physically push it "off" (or "on" or anything). My expectation for that "if" clause would be that physically taking any action at that switch would run the "then" clause except for switching it on.

Mike, The trouble with only addressing the "switched on", "switched off" states is it leaves behind all of the in between dimmed situations. What I was trying to accomplish here is have a program trigger and run the "then" clause whenever the switch was touched in any way. Furthermore, I didn't want the program to trigger in the event that the switched was turned on by another program or from a scene, so this eliminated using the "status" commands. I think your scenario 1 answers my question. I would expect scenario 1 to run the "then" clause if the switch is switched "off", since, the switch is being switched and it wasn't switched to "on" so to me this equals "true". But it appears that ISY logic first looks at the "switched on" part, then to the "is/is not" part of the clause. Assuming this is the case, it would seem that having "is not" available in programming a control command is kind of useless. Perhaps I can accoplish what I want with Is switched on or is switched off or is fade up or is fade down etc etc. Lou

I have succesfully used "is not" lots of times in a "status" program but was just playing with it as a "control" program. The goal was to have a program run anytime a switch was touched in any way. Two lines I figured would do it. if switch xyz is switched on or if switch xyz is not switched on I have discovered the the "not switched on" doesn't seem to do anything. I figured it would trigger the program if you did anything to the switch, except turn it on. I further experimented by writing the line if switch xzy is not switched on all by itself. Nothing I did to that switch caused the program to run. So I don't quite understand what "is not switched" means to ISY in a control line.

I have succesfully used "is not" lots of times in a "status" program but was just playing with it as a "control" program. The goal was to have a program run anytime a switch was touched in any way. Two lines I figured would do it. if switch xyz is switched on or if switch xyz is not switched on I have discovered the the "not switched on" doesn't seem to do anything. I figured it would trigger the program if you did anything to the switch, except turn it on. I further experimented by writing the line if switch xzy is not switched on all by itself. Nothing I did to that switch caused the program to run. So I don't quite understand what "is not switched" means to ISY in a control line.

The else section of your first program will start running every time the motion sensor goes from "on" to "off" (I assume it can only be on/off) or if someone physically controls the switch to anything but "on". So if your motion sensor is on the fritz, then someone controlling the light to anything but "on" won't disable your second program. You might add "or control living room light is switched off" which will cause the program to run the "then" anytime anyone physically touches the switch at all. With that done you will have the opposite problem in that if the motion detector is stuck "on" the else section will never have call to run. If you add to your "then" statement "run program occupancy detector else" it will have the effect of disabling the night lighting program every time someone touches the switch and causes the else to starts its 24 hour countdown to switching the lights to auto. The only question I have is if a "then" clause can run an "else" clause of the same program. You might need to copy that else clause to a whole different program if that is the case. Other than that, I can't figure a way to mess it up. Addendum: You can have the "then" section run the "else" section of the same program. Addendum 2: It ocurred to me that since nothing else is referencing the "else" clause, you wouldn't need the "then" clause to run the "else" clause, you would just add the "else" clause contents to the end of the "then" clause. So in short, anytime the motion detector changed state, or the switch was pushed, the program would disable the night lighting program and reset the countdown to re-enabling the night lighting program for another 24 hours.

I once had a keypad linc led brightness adjust from a program and it seriously scrambled stuff. I ended up having to remove the switch from ISY, factory reset it, and put it back to ISY. I don't know why this happened but I will never use programs to change the led brightness again.

Sounds like you are starting to get the hang of this. It takes a while and you will still make lots of mistakes and scratch your head saying "why the heck is it doing that?" The ISY programming interface is very powerful but has a few quirks that aren't that intuitive. Once you get to know those things you will start to find it to be a fun challenge to get your programs to do all kinds of subtle things.

I believe you are correct except that scenes do not have a status. You will need to use one or both of the switches to monitor the status. That program will evaluate at 1) Sunset 2) 11 pm 3) any time the status is addressed (of whatever switch you choose to watch) You would be better off to write a program that turns the lights on at sunset, and another program that turns them off at 11pm.

It does no harm to send an "on" command to a device that is already on (or "off" to a device that is already off, or any command for that matter). In fact, there is a world of possibilities using things like an "on" command to a light that is already on. For example, I have my bedroom and bathroom lights set to turn on to 25% if they are off and you switch them off. It is a way to easily turn the lights dimly on if you need to get up during the night. If you have lights on a timer and you want to override the timer, this is another great use. For example, if the light is already on but it is timing down to a shut off shortly, then clicking "on" can abort that timer and allow them to stay on. When writing ISY programs it will help you greatly to understand triggers. In ISY programs, the "if" clause may be re-evaluated (triggered) while the program is still running and in that case, the program is aborted and started over. So if a "then" clause is still running, it will abort (like if you have a "wait" command in it). The most common situation that confuses people is the difference between a "status" and "control". Control statements are only triggers if the actual event happend (ie control on, even if it is already on). So if a program is running and "control on" is the only condition, that program will run to completion unless someone hits "on" on that switch. Also, "control" statements always pertain to the actual device being controlled. "control on" means someone physically pushed the "on" paddle. This is different then "status on" which works no matter how the device became on. Status statments are triggers any time there is any traffic relating to the device. So if you say "status on" in a program the program will abort and re-evaluate the entire "if" clause should any command be sent to that device and it doesn't matter what state the device is currently in.

Look at the Wiki as oberck says. A good motion program will 1) turn the light on for a period of time if the light is already off 2) do nothing if the light is already on 3) do nothing during the daytime 4) allow you to adandon the timer by either hitting the on or off button on the switch (and having the light follow that command as well). 5) not get caught in an endless loop By using multiple programs, separating your "then" from "if" sections, and using flag programs all of this can be done.

You will probably need to have two programs. The second program contains the "then" section of your current program. The first program has your current statements but also includes an "and status off" of one of the lights in the scene. The then section of this program will run the the then section of the second program. The reason for this is becuase adding the "status off" statement in the if section will cause the program to retrigger when the then secton turns it on and kill your program again. All of your headaches here are based on the fact that you have the delay mixed into the same program with all of these conditions. That delay allows for the program to be terminated since the then section changes things in the "if" section. By separating the "then" items into a whole different program you avoid this problem and you could actually go back to using "status" as you wrote thins the first time.