apostolakisl

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.

I am not so sure that this is true. As you pointed out, each 'off' statement triggers an evaluation, at which point it will halt the program and start it at the beginning. This assumes that the motion sensor sends repeated off's, which I suspect it will (after the motion sensor time-out period). The only problem that I can see is if the motion sensor time-out is longer than the program wait period. Based on the original post, however, it sounds as if the motion sensor wait period is less than 5 seconds. I was making the assumption that continuous motion would keep the motion detector in a continuous state of "off". In that situation the program would run its timed course to conclusion and shut the light off. If the motion paused, the motion detector went to "on" state, then back to "off" state it would work fine. So maybe if you did a jumping jack, stood still for a few seconds, then did another jumping jack. If the motion detector continued to send "off" commands despite already being "off", I think it would work I was just reading my last post and think I may have miss-spoken on one item. I said that status changes reset a status program no matter what the change is. In fact, I believe that a status update also resets the program, even if there is no change. For example, an Insteon switch may be off already and you hit "off". That also will reset the program despite no change at all.

Probably the reason that this didn't work the first time is because of the concept of triggers. In ISY, a trigger is something that causes the If section to be evaluated. When the If section is evaluated it will restart the program. "Status" is a trigger every time the status of that device changes, regardless of what the status changes is (on to off, off to on, partial on to some other partial on, etc). So, the motion detector is tripped, it becomes "off", this starts the program. But, since the motion dectector switches back to "on" when no further motion ocurrs, the program restarts when the motion stops long enough for the motion detector to switch back to "on" status. This time however, the if section is no longer true (because this change was to the "on" state) so the else section is exectued, which you had empty. Since the program was interupted prior to the delay you wrote in, it never finished the then section. If you stood in front of the motion detector and did jumping jacks, it probably would have finished and shut off even though motion was still going on, becuase there was no status change. "control" is a trigger only when the device was controlled as written. So, your program written as "control off" only gets evaluated when the motion detector changes to off. When it swtiches back on again, the program keeps running, unless it is tripped again prior to completing and this starts it over. But, now you want it to start over which effectively keeps the light on until the motion stops happening for a while. While writing the program using "control off" as you did works, it does have a flaw in that continuous motion will not keep the light on. I would suggest writing this as two programs, one that switches the light on when the motion detecotr switches to "off", and one that turns the light off several seconds after the motion detector switches to "on".

The IR Blaster that comes with the unit shoots 15 feet to where it is picked up by my channel plus whole house music system which repeats it in my media closet. I made no special provisions for this and it works very nicely.

You don't need to enable internet access, in fact, you don't even need an internet connection to get your sunset/sunrise. Under "configuration" tab, "system" subtab, you will see where to fill in your city. This sets the sunrise/sunset. An internet connection (or at least a home network connection) is necessary if you want to control your isy from anywhere but plugged directly into it. An internet connection is completely necessary for weatherbug. Please note, an internet connection and internet access are not the same thing. Enabling internet access automatically configures your home network to forward external requests to your ISY. This only works with certain routers so if you don't have one of those you need to do it manually. An internet connection is necessary if you want your ISY to be able to pull info from the internet (like weatherbug), or send stuff to the internet (like emails), but otherwise is optional. It will still control Insteon stuff without it.

The issue of devices being written to without progress bars and the flag at the bottom saying ready is consistent. I have now seen it happen on several occasions.

My upgrade went through fine. I even copied the directions to MS word so as to keep the instructions up with browser closed. The only odd thing was that after the upgrade, it indicated a device needed a write even though no changes were made to it. When I tried to activate the write nothing happened. I logged off, then back on a couple times before it would actually do the write. Then it quit doing the write (according to the progress bars), but still had the "writing" tag next to the device. Finally it went away. I am thinking that perhaps it was doing the writes in the background even though the "ready" flag was up and no progress bars existed. It is working fine now.

If you could communicate with everything fine before the firware update and now you can't, I doubt resetting devices will work since you would just be writing the same thing back to the devices. But my bet is that you won't be able to write to them anyway. Will it let you reinstall the firmare? Try downloading a fresh copy and install that again.

Try clearing your java cache again and logon using the http://your.ip.address/admin I did an update once and accidentally used the wrong version number in the java applet http and it opened a non-functioning console just like you describe. Once correcting that, all was fine. If this does let you logon, try redownloading the firmware and doing another install.