apostolakisl

Oh Yeah.

Erick, You are done. That is all you do. Now when you write programs you will use the drop down menu to pick variable, then the next drop down menu over picks which variable. Since you only have 1 so far, it won't be a long list. Just a quick helpful hint. I suggest naming your variables that are integer with an "i" and the state ones with an "s". So you will know right away what it is when it shows up on the drop down since all variables, integer and state, show up in the same drop down menu. IE $i.work.late Integer variables do not act as triggers. In other words, they will not cause a program to run when they change, they will only be checked when the program runs for some other reason. State variables will act as triggers. So if its value changes for any reason, any program that has it referenced in the "if" section will be triggered. Check out this video: And this wiki page http://wiki.universal-devices.com/index ... le_Details RE: parenthesis You will see that there are 2 conditions connected together inside of those parenthesis. The parenthesis simply puts those 2 things together as a single entity when they are compared to the other conditions. for example: (a and or c is not the same as a and (b or c)

Provided you need 4 of them. Of course you have to pay sales tax at costco so the price ends up equal to the 20% off sale, but like you said, no waiting for Christmas. I'd be happy to help you out, but don't really know if I can drop ship the device to canada or whether it would need to be shipped to me then reshipped to you.

I had no idea Costco sold Insteon. http://www.costco.com/Insteon-Dimmer-Sw ... 83308.html These dual band switches work out to $37 each including shipping. They list a model number that I am not familiar with, however. I assume this is just a Costco thing and that they are in fact 2477D switches. Anyone have any experience here? They also come with screwless cover plates which I suppose is worth a buck or so.

EDIT: I noticed a simple "mistake" that lets me take it all down to 2 programs (intead of 3) What you have done works but adds extra programs and makes it a little harder to organize/edit Variable syntax is just what I wrote above, except the word "set" isn't actually there. It is all in the drop down menu in the programming page under the details tab. You can do it all in 2 programs with no time gaps as follows. No need for any variables or anything fancy except parentheses in the one program. Program KPL working late If status KPL working late is off and time is 11:59pm Then set lights off Else - - - Program working late/default on off If time is from sunset-11 minutes ****this clause is the basic on/off at the 2 times to sunrise - 1 hour OR *** this clause turns the light on during those hours if you switch the kpl on, notice use of parenthesis (time is from sunset - 11 minutes to sunrise - 1 hour and control KPL working late is switched on) AND **** this clause will always run the else (and turn the light off) when kpl is turned off, no matter what time it is control KPL working late is not switched off Then set lights on Else set lights off The only "weird" thing this set of programs would do is: if you turned the KPL on, and the outside lights were on, and it was not inside those time constraints, the outside lights would turn off. If I understand how you are using these lights, I don't think this is going to be an issue.

Try making a scene that contains all the lights you want off and the KPL buttons you want off, then have the program turn that scene off when you double click it.

In that situation you would want to use a program that states If control kpl is switched off Then set light off Else - - - You could add time limits in there as well if you only wanted this to happen at certain times. You can not set the KPL as a scene controller since that would cause the light to turn on whenever you turned the KPL on. There are ways around that, like setting the scene on level to 0, but that also cause the light to turn off every time you turned the KPL on or off.

Yes, you got it. Integer variables work perfectly as indicators. Status, unfortunately, does not, especially when you have a program which uses the else clause. Variables are easy. There are other ways to do this besides variables, but I think in this case it will be at least as easy as any other method and probably more directly understandable. A couple tips. 1) No spaces in the name of a variable 2) Don't forget to hit the "save" button

The main problem you are going to have is the line that includes the STATUS of the KPL button. Every time the status of that button changes, it will TRIGGER both of those programs. This will at times cause the "else" to run when you didn't want it. I assume you want to use the KPL as a flag, not as a trigger. A simple solution to this would be to use an integer variable. Integer variables are never triggers, they are checked when the program runs for other reasons but do not cause a program to run. If time is from sunset to 1am next day And $i.worklate = 1 Then set light on Else set light off If time is from sunset to to 11:58 And $i.worklate = 0 Then set light on Else set light off If Status KPL button is on Then Set $i.worklate = 1 Else Set $i.worklate = 0 The details can be changed. But the point here is that the act of pushing the KPL button does not run the programs that turn the light on/off when you use the variable. Otherwise, all of the programs will run and you will always have each one end up executing a then or else clause and you will get unintended outcomes.

This comes all the time. I really think the guys at UD need to just add a statement to the notifications screen that says "PLEASE BE SURE TO INCLUDE CONTENT IN BOTH BODY AND SUBJECT OR YOUR MESSAGE WILL NOT BE SENT" Or, if they wanted to be a little fancier, they should have an error message pop up when you save the notification and don't have content in both sections. Or, make it so that the message is actually sent even if one is left blank. I have never seen this problem with other email programs so I don't know why ISY has it. But the first solution I would think could be implemented with minimal coding effort on the part of UD.

As Lee said, you are right. The concept here is a trigger. ISY programs that are true or false are not enforced unless they are caused to run (triggered). So in a program that is a from/to program, there are only 2 triggers, the from and to times. At any other time it is as though the program doesn't exist. However, adding another clause in the program could change things. If Time is from 8am to 10 am And status of device x is off Then Do something Else Do something else Now realize that every time device x changes status the program will be triggered and the truth or falseness of the time being between (or not between) 8 and 10am will be important. Also there still would be no conflict with another program that also has time definitions on a device if it is idle (not being triggered). There would only be a conflict if 2 programs had the same triggers and different outcomes.

I think the most common use of "is not off" is in a "status" line of a program when you want the program to run "true" for any partially on or totally on state. These 2 are not the same program If status light x is not off *****light must be 1% or more to be true***** Then do something vs If status light x is on ****light must be 100% on to be true**** Then do something Please realize that there are other ways to say the same thing. The second use is in a control program when you want to run the "else" clause. This is much less common and is only needed when you have something of a more complex program with multiple conditions. But here it is If Control light x is switched off ***then clause runs when switched off, else clause never runs from this program**** Then do this Else do that If control light x is not switched off ****else clause runs when switched off, then clause never runs from this program**** Then do this Else do that In the above, switching off is the one and only trigger, so when an "off" command is received, it is either true or false depending on the "not" being there. I sometimes use a "is not switched" condition as a condition to abort a timer. If control button a is switched on and control button b is not switched on Then wait 10 minutes do something Else do blank In the above, if you push button a, the timer starts, if you push button b, the timer aborts.

I have had another documented issue that I believe is this same problem. The following program was running with every query of the device, even though the status was off before and after the query. If Status 'Downstairs Washer' is Off Then Wait 1 minute Send Notification to 'lou gmail' content 'Laundry Downstairs' Set Elk Speak Word '_Custom1' Else - No Actions - (To add one, press 'Action') I didn't get it, it shouldn't trigger on a query if the status didn't change. Then I noticed that when I clicked on the " Status 'Downstairs Washer' is Off" in the program, the working section at the bottom showed it as "responding" not "off". Please note, this is a fresh opening of the admin console and I made no changes to anything. I just opened the window. Something is up where what is showing in the "add to program" section, and the actual program, and what is displayed in the "program content for. . . " is out of sync. EDIT: And, the only way to fix the problem was to delete the program and start over from scratch. Each time I tried changing it to "off", it seemed to work as it showed "off" everywhere. But the program still triggered on a query. When I closed the admin console and re-opened it, once again it showed "responding" at the bottom of the screen and "off" at the top of the screen. EDIT EDIT: Except that the problem isn't fixed. It is indeed displaying "off" now everywhere. But, a query of it while it is "off" and it stays "off" still triggers a true response. Why are these things triggering on a query with no status change? EDIT EDIT EDIT: Well it is back to "responding" even though the program specifies "off". After I close and re-open the admin console the gui goes back to the photo above.

It is different and it upsets a lot of people because they want it to be the same thing that their brain is already use to. They have something of a point. But this works well in the environment it was designed to function in. Regarding disabled programs: Disabling ONLY stops a program from self-triggering. It can still be hit with a "run if" "run then" or "run else". It just won't do anything of its own volition.

This works too, but remember that the first program needs to be set as "disabled". I kind of like my way better because it is faster to write. Since the programs are almost identical, once you write the first one, you just copy it and make the couple edits. And you don't have to disable anything which comes in handy if you ever need to "disable all programs" when trouble shooting something. When you re-enable, you have to remember which ones to not re-enable.

You have to write 2 programs. Having the "status" of the lamp in there will force unwanted triggers of the else clause. Here is one of my examples. If IR 'IR_003' is Pressed And Status 'Family Room / Family Room-Ceiling L' is Off Then Set Scene 'Family Rm Ceil S' 100% Else - No Actions - (To add one, press 'Action') If IR 'IR_003' is Pressed And Status 'Family Room / Family Room-Ceiling L' is not Off Then Set Scene 'Family Rm Ceil S' Off Else - No Actions - (To add one, press 'Action')

In addition to what Lee said, it could be that the light is a noisy fluorescent or have some other noise producing transformer or whatever. The light turns on fine, but once on, the power line noise it generates may prevent the Insteon command from reaching its target and turning it off. A simple way to check this is to manually turn it on and off from the ISY main console. If that works fine, then it must be your program. For sure you don't need the line that says "if status is off". If it is already on, sending another "on" command does no harm.

as I recall, someone correct me if wrong, at reboot the ISY will query all devices so it knows what state they are in. Then it checks programs and places them at true or false depending on the If condition. It does not run them unless specifically set to run at startup. That would be worth checking. I can tell you that I have a program that every once in a while runs at 3am when the system does a query all and ISY had the Wrong status prior to query. Not sure if a status of "blank" changing to "something" is considered a change and thus a trigger. A UPS is still a nice idea. It really keeps your programs straight after a power cycle. And as mentioned, ISY only uses a few watts so that thing would run a long time. The number 5 watts rings a bell but that is just a vague recollection.

One option is like Oberkc said and wire the light hot all the time and put an inline linc at the light. Another would be tear out the box and put a 5'er in.

Put your ISY on a UPS, but not the PLM. In my experience, ISY never reboots except on power cycles.

ISY can't respond to response messages like that as far as I know. You would need to use REST commands, and I don't know that it is possible to get the itach to do that. You would probably have to use an intermediary, like a PC.

To add another advantage. A scene is one Insteon command sent over the power line no matter how many devices, a program controlling individual devices is one command for every device. As you get more devices, the transmission success rate will suffer.

If you were to add more conditions or if you were to call the program from another program, then the else could run. It is not ruled out as a possibility. Furthermore, it is just a "form" of sorts. You don't always need all the blanks on a form, and you don't necessarily need all the options in an ISY program. And if you want to substitute other terminology for the word "if" in your own mind, then fine. Like "in the event that" Elk, which uses similar event driven programs using the term "whenever" instead of "if"

Please read what I wrote again. You are being oddly judgmental for someone who is asking for help as a beginner. The fact is, ISY is event driven. Programs calling programs is a fundamental part of how ISY works in more complex situations. If you don't like it, tough luck. Don't use ISY. And, to your second question. ISY does not always run false because like I said, it is event driven. The only trigger for a "control swithed on" is receiving a "switched on" signal from the switch. How would it ever be false? It either receives that signal and the "event" triggers the program, and it is true, or no trigger ever occurs and the program simply doesn't run. The else clause has lots of value, but not in a single line "control switched" program.

As oberkc mentions, it does work and it follows its logic. But it is a different language. Don't try to just apply the usual stuff. Programs calling programs or programs checking the true/false nature of a program is very common with people who take the programming past the total beginner level. Understand triggers and you will get most of it. Important concepts. 1) "control" statements are triggers on ISY receiving that command. ie "control switched on" means someone must push the on paddle. Otherwise it is false. It will always be false if something else triggers. 2) "status" statements trigger on every change of the status no matter what it might be. It could be true or false if it is its own trigger or if something else triggers. 3) All of the conditions are equal as far as potential to be triggers. The first or the last statement makes no difference, a trigger causes the entire program to stop (if it is already running) and evaluate the entire "if" clause. 4) Conditions will be triggers whether you want them to be or not. In other words, you can't shut off a condition as far as being a trigger. This is when you use multiple programs where one calls another. It is a bit of a workaround. The program that you want to disable the trigger clause is set as "disabled" so it never self-triggers. Disabled does not stop a program from running, only self triggering. 5) Time commands are triggers as noted earlier. ISY is very powerful. But it is definitely different.