Christmas lights

[bmiller]

I have installed one outlet link for the lights for the Christmas tree, and may install one for the outside lights. I would like to have the lights go off and on daily from the middle of Dec. until say Jan. 3, and then have the outlet stay on, as would a regular outlet, for the rest of the year. I would also like this to be continuous, ie. i don't want to have to reprogram every year, so i made it run until 2030. The only way i could think of doing it was to create two programs for the outletlinc. Will this work?

Thanks

Brad

[apostolakisl]

ISY has no wild cards when it comes to dates. In other words, you can't do something like every Dec 5 and leave the year blank.

 

I wrote a series of programs that use the variable function in ISY to fix the problem. Or, you can just do what you are already doing and spell out the exact dates for each year all connected with a bunch of "or" statements. The programs I wrote allow for pretty much any kind of recurring date function you might ever think of.

 

http://www.universal-devices.com/mwiki/ ... _Variables

 

EDIT: I just read your program more closely and what you are doing won't work at all.

 

To write a single program and be able to not touch it again (for at least several years), it would need to go like this.

 

(from 2012/12/15

to 2013/1/3

or

from 2013/12/15

to 2014/1/3

or

from 2014/12/15

to 2015/1/3

etc)

 

and

(time is from 4:30 pm

to 10pm

or

time is from 7am

to 8:35am)

[oberkc]

I believe apostolakisl is absolutely correct...your program will not perform as you expect. With hope that this will help better understand why...

 

There are program triggers (when will a program perform an evaluation) and program results (what are the results of the evaluation). Triggers and evaluations are both dictated by the program conditions (if statement).

 

Your first program will trigger twice, and only twice: on January 4th 2013, and on December 15th, 2030. This program will do nothing between these two points in time. Once triggered, the evaluation will be "true" on the first date (thus running the "then" statement) and will be "false" on the second date (thus running the "else" statement). Bottom line...this program will turn your outlet on when january 4th 2013 rolls around, and will do nothing (empty else statement) in 2030. It will be, simply, a one-time event.

 

Your second program has a couple of problems. First, it will run (trigger) continuously between the "from" and "to" times, meaning it will run from 2013 until 2030 without stopping each January. Second, it will ALWAYS evaluate as "false", because it can never meet both conditions at the same time. This is because you chose "AND" rather than "OR". "AND" requires both conditions to be true in order for the entire condition to be true. Because of this, the second program will do nothing more than send out "off" commands four times daily between December 2013 and January 2030.

 

I also agree with apostolakisl that, short of writing a bunch of amazing programs such that he has done, I have not found a way for ISY to handle your sort of problem. I have taken a different approach. I have simply decided that I am going to be accessing the ISY several time a year regardless, and that I am too lazy to generate the set of programs necessary. Therefore, I simply create a single-year program for holiday lights, and update it each year.

[bmiller]

I see what you mean by the or instead of and in the first program. That program would be ok. I just wanted the outlet to be active all the time starting Jan. 4. I was hoping the second program would take over during the holiday season each year to avoid reprogramming the holiday schedule, but it appears that is what i'll be doing. I'll just have one program to activate the outlet on each Jan. and another to do the lights on a yearly basis.

The variable program looks a bit daunting.

Thanks for the help.

Brad

[oberkc]

The variable program looks a bit daunting.

 

Tedious is the word I would use. If I had multiple programs that required seasonal adjustments, I would probably go ahead, but I have basically two folders that use yearly conditions, and it is not that difficult making the once-per-year adjustment.

 

I think you are making a good decision (for now) to skip the variable approach. Become proficient with some of the basis things: the boolean logic (and, or, parenthesees, if, then, else), understanding what triggers a program, knowing the difference between "status" and "control", avoiding loops, effects and consequences of "wait" statements, etc.... Once there, then relook at the suggested variable program.

[bmiller]

I just had an idea. It hurts, but i have them every now and again. I have a spare keypadlinc button. I made a scene with the keypadlinc button and the Christmas Lights outletlinc. I then made a program with the time of day that i want the lights on and off, which will be activated with the button on. I made another program "if KPL button is off" then stop christmas tree program and turn lights on which in this case will be to activate the outlet when the lights are removed.

Sorry to keep adding jpegs, but sometimes a picture is worth a thousand words.

Thanks again

Brad

[Xathros]

I'm of the same mindset as oberkc on this. While the features offered by apostolakisl's programs are hard to resist, that is a lot of complexity to add and maintain. I'm hopeful that the ISY's native date/time/mvar handling will improve in the coming generations. Until then, if needed this is the solution.

 

That said, it is well worth studying apostolakisl's code as there are some very useful not so obvious techniques he has employed that can be used elsewhere. Understanding how that logic works will help your general understanding of how the ISY and variables work as well.

 

-Xathros

[bmiller]

Thanks, i'l do that.

I'll get this working with the KPL first.

I've programed as the jpegs and when i press the KPL button on and off, i can here the outletlinc clicking on and off, but the light i have hooked up stays on all the time. The isy shows the kpl turning off and on and the outlet turning on and off as it should, but the outlet itself stays active all the time. Is this a defective outlet?

[Xathros]

I believe only one outlet on an outlet link is switched (top?)

 

-Xathros

[bmiller]

Yes. That's the one i have a test light plugged into.

I just performed a scene test, and it came back successful.

[Xathros]

Have you tried the bottom then ? I was going from memory on which one is switched. If you can hear the relay in it clicking, it's likely working.

 

EDIT: What are you using for a test lamp? The manual for Outletlinc indicates that it supports load sensing. Load sensing works by passing a small current through the switched outlet to tell if there is a load present. If you use a voltage tester (Neon bulb) it may show voltage when the outlet is off. Make sure you test with a real incandescent lamp.

 

I ran into this with an X-10 outdoor relay with some LED xmas lights where they would glow dim when off.

 

-Xathros

[oberkc]

on mine, top is switched.

 

Agree on the concern about the test load. If it is a low-power LED, it could continue to glow, even when off.

[oberkc]

I made a scene with the keypadlinc button and the Christmas Lights outletlinc.

 

If you did this, then the outletlinc will turn on and off with the keypad button. Effects from programs will be in addition to this.

 

I am not familiar with the statement "stop program". Does this stop any ongoing execution of a program, or more broadly disable the program? My assumption is the former, in which case, this may not do what you expect.

 

What are you expecting to happen when "keypad linc D" is switched on, if anything?

[bmiller]

Thanks, you are correct. I was using an led potential tester. There was enough passing through to keep the light on. That's a good one to remember. Now i believe the strings of Christmas lights are small led, but the string is long enough, it shouldn't matter, i hope.

[oberkc]

LED christmas lights can sometimes glow, as well. If you get enough strung together, then not. Some have suggested plugging in an incandescent nightlight into the same outlet. Others suggest plugging in an unused power supply or charger. Others appear to go as far as to add a resistor.

 

If you have glowing LED problems, try one of those approaches as your skills and interest dictate.

[bmiller]

I made a scene with the keypadlinc button and the Christmas Lights outletlinc.

 

If you did this, then the outletlinc will turn on and off with the keypad button. Effects from programs will be in addition to this.

 

I am not familiar with the statement "stop program". Does this stop any ongoing execution of a program, or more broadly disable the program? My assumption is the former, in which case, this may not do what you expect.

 

What are you expecting to happen when "keypad linc D" is switched on, if anything?

 

It stops execution of the program(s). When the KPL is on, it will run the lights as in the program. When it is switched off, it will stop the program, turn the outlet on and leave active like a regular outlet until the KPL is turned on again. The advantage of this over setting a specific date is i never know when my wife wants the tree setup. This way i turn the program on with the push of a button, and disable it the same way no matter what the day is.

[apostolakisl]

I'm of the same mindset as oberkc on this. While the features offered by apostolakisl's programs are hard to resist, that is a lot of complexity to add and maintain.

-Xathros

 

I think you don't exactly understand how they work. There is nothing to maintain at all. Once it is installed it is maintenance free. The only caveat is if the ISY is offline at midnight and continues to be offline past the "catch up" time you set into ISY on reboot, it will fall 1 day behind. But there is a simple fix to that, you run the "advance one day" program. Since I finished the program, I have not had to touch it once.

 

The only "tedious" thing is that you have manually add the variable labels when first installed. The programs themselves can be downloaded and installed as is, no tinkering at all. And the best time to install this set of programs is BEFORE you start using up a bunch of variables for other things. It would be tedious to change the variable addresses, but you would only need to do that if you had a conflict because you already used those addresses for other variables.

[apostolakisl]

I am not familiar with the statement "stop program". Does this stop any ongoing execution of a program, or more broadly disable the program? My assumption is the former, in which case, this may not do what you expect.

 

Stop program does not disable disable the program. It merely stops the current execution of a "then" or "else". It has no impact on past actions of the program or futures executions of the program either from its own "if" or by some other program initiating it. It is only useful to stop a program that is in a "wait" or "repeat" where a "stop" could be interjected.

 

In the program shown in the jpeg earlier in this thread, the "stop" command will do nothing. That program is not running except for a split second at the "from" and "to" times. So you will be stopping a program that is not running. Look at the program summary page, if the program does not saying "running then" or "running else", then telling it to "stop" does nothing. Stopping an "idle" program is a non-action. Programs are not "running" between the "from" and "to" times, they only ran AT the "from" and "to" times (assuming there is nothing else causing it to run).

[bmiller]

I have a vacation scene with 4 lights that come on at dusk, and turn off at various, random times to simulate someone at home. Mine are activated from a KPL button, and deactivated from the same button. When the button is on the lights come on as they should, and off at various random times as they should through the program.. If i come home, and the program is still running, i can turn off the kpl button, and all the lights go off as they should. This is done with a stop program command when the kpl is turned off. The program never runs again until i turn the associated kpl button on. The only caveat is if it is past dusk, and i activate the program, it won't run until the next instance of dusk the following day.

It also works from mobilinc from a scene. I have the Christmas tree lights set up the same way through a kpl button. It has tested alright so far. It will be tested again when i hook up the led strings.

apostolakisl, i'm not sure if this it was you are pointing too, but everything seems to work fine for me. Maybe it's the fact that it is activated from a KPL that is the difference, but i've had no problem since i set the program for my vacation scene. I think i have the Christmas lights setup the same way, and the tests work ok.

 

I forgot to mention, i added if KPL button is on to the " if " of the Christmas lights program. I'm not sure if it is needed, as i have it linked with the scene, but it's there and it appears to be working. I'll test on the weekend with a lamp to verify the setup works.

[apostolakisl]

I have a vacation scene with 4 lights that come on at dusk, and turn off at various, random times to simulate someone at home. Mine are activated from a KPL button, and deactivated from the same button. When the button is on the lights come on as they should, and off at various random times as they should through the program.. If i come home, and the program is still running, i can turn off the kpl button, and all the lights go off as they should. This is done with a stop program command when the kpl is turned off. The program never runs again until i turn the associated kpl button on. The only caveat is if it is past dusk, and i activate the program, it won't run until the next instance of dusk the following day.

It also works from mobilinc from a scene. I have the Christmas tree lights set up the same way through a kpl button. It has tested alright so far. It will be tested again when i hook up the led strings.

apostolakisl, i'm not sure if this it was you are pointing too, but everything seems to work fine for me. Maybe it's the fact that it is activated from a KPL that is the difference, but i've had no problem since i set the program for my vacation scene. I think i have the Christmas lights setup the same way, and the tests work ok.

 

I forgot to mention, i added if KPL button is on to the " if " of the Christmas lights program. I'm not sure if it is needed, as i have it linked with the scene, but it's there and it appears to be working. I'll test on the weekend with a lamp to verify the setup works.

 

In order to have a random shut off time you must have a wait. You are terminating a wait. As I mentioned, "stop program" only affects a program that is currently executing a "then" or "else" clause. The only way to have an "else" or "then" clause that lasts more than a split second (and thus has opportunity for a stop to be interjected) is during a "wait" or "repeat". . . mostly just "wait" since "repeats" without "waits" don't take very long either.

[oberkc]

Stop program does not disable disable the program. It merely stops the current execution of a "then" or "else". It has no impact on past actions of the program or futures executions of the program either from its own "if" or by some other program initiating it. It is only useful to stop a program that is in a "wait" or "repeat" where a "stop" could be interjected.

 

In the program shown in the jpeg earlier in this thread, the "stop" command will do nothing. That program is not running except for a split second at the "from" and "to" times. So you will be stopping a program that is not running. Look at the program summary page, if the program does not saying "running then" or "running else", then telling it to "stop" does nothing. Stopping an "idle" program is a non-action. Programs are not "running" between the "from" and "to" times, they only ran AT the "from" and "to" times (assuming there is nothing else causing it to run).

 

That was my assumption, but I was not certain. Given this, I agree with your conclusion: I don't think this statement will accomplish the desired goal.

[bmiller]

I have a vacation scene with 4 lights that come on at dusk, and turn off at various, random times to simulate someone at home. Mine are activated from a KPL button, and deactivated from the same button. When the button is on the lights come on as they should, and off at various random times as they should through the program.. If i come home, and the program is still running, i can turn off the kpl button, and all the lights go off as they should. This is done with a stop program command when the kpl is turned off. The program never runs again until i turn the associated kpl button on. The only caveat is if it is past dusk, and i activate the program, it won't run until the next instance of dusk the following day.

It also works from mobilinc from a scene. I have the Christmas tree lights set up the same way through a kpl button. It has tested alright so far. It will be tested again when i hook up the led strings.

apostolakisl, i'm not sure if this it was you are pointing too, but everything seems to work fine for me. Maybe it's the fact that it is activated from a KPL that is the difference, but i've had no problem since i set the program for my vacation scene. I think i have the Christmas lights setup the same way, and the tests work ok.

 

I forgot to mention, i added if KPL button is on to the " if " of the Christmas lights program. I'm not sure if it is needed, as i have it linked with the scene, but it's there and it appears to be working. I'll test on the weekend with a lamp to verify the setup works.

 

In order to have a random shut off time you must have a wait. You are terminating a wait. As I mentioned, "stop program" only affects a program that is currently executing a "then" or "else" clause. The only way to have an "else" or "then" clause that lasts more than a split second (and thus has opportunity for a stop to be interjected) is during a "wait" or "repeat". . . mostly just "wait" since "repeats" without "waits" don't take very long either.

Maybe future execution of the program is a better statement then stop program. I see what you mean about about a momentary command to stop a running program. In my case the program will never run until the kpl is on, at least that's the way my vacation scene is working. I'm not sure about the Christmas lights, but i've got a lamp setup, so i'll see how that works this weekend.

They all have a wait, and shut off at random times. I gather the "wait" is the key.

Thanks for your patience everyone. It's a giant learning curve.

Brad

[Xathros]

I think you don't exactly understand how they work. There is nothing to maintain at all. Once it is installed it is maintenance free. The only caveat is if the ISY is offline at midnight and continues to be offline past the "catch up" time you set into ISY on reboot, it will fall 1 day behind. But there is a simple fix to that, you run the "advance one day" program. Since I finished the program, I have not had to touch it once.

 

The only "tedious" thing is that you have manually add the variable labels when first installed. The programs themselves can be downloaded and installed as is, no tinkering at all. And the best time to install this set of programs is BEFORE you start using up a bunch of variables for other things. It would be tedious to change the variable addresses, but you would only need to do that if you had a conflict because you already used those addresses for other variables.

 

apostolakisl-

 

Sorry, that was a bad choice of words on my part. I realize they are mostly set and forget. You just described my reason for nor proceeding with them however. I have many programs, integer vars (86) and state vars (37) defined already and have enough trouble sorting through those as it is. It was just more than I want to add unless I absolutely need these features. That coupled with the fact that I have noticed that Mobilinc's performance dropping off as I add more programs and vars. I believe this is due to it parsing the list of everything in the ISY at each launch. I don't dare add that much more for it to sift through.

 

All of that said, I am very impressed with what you have developed here and will not hesitate to point those that need these features your way. And as I said above, there is much to be learned from studying your code. I have already employed some of your methods for other things.

 

Thanks.

 

bmiller-

 

Sorry to have hijacked your thread here.

 

In reference to your posts above, the stop program statement is terminating any "currently waiting" wait statements only, The fact that you have turned off the KPL button is likely what is preventing further/future executions as the status of that button is no doubt a key element in the IF of that/those programs.

 

-Xathros

[bmiller]

I see what you are saying. I gather then that i can remove that statement, and just leave when kpl is turned off, turn Christmas tree on ie. keep the outlet active to use as normal, until the the following Christmas. I use that statement in my vacation program to end a currently running program if i return home before it's finish time. I assumed i needed it here also, but i it isn't needed in this case.

Thanks for the clarification everyone.

Everything so far is working as programed with the test lamp.

Brad

[bmiller]

I have a lamp hooked up to the plug for testing out the Christmas light program. On the same circuit i have another lamp that has been plugged into another outlet linc for a few months and is operated from a kpl button, or from a vacation program. A couple of times now i've turned the switch on the test lamp. and although the isy shows Christmas lights off, the lamp will come on and shut the other lamp off, or turn it on depending on which state it is in. Both are cfl's. I ran a test a few times with the older lamp on, and the Christmas lights running through a few timed programs. All worked ok those times. When i physically turn the test lamp on or off, it turns both on and off without a command from the isy. Is this a normal condition for cfl's, or is this some spooky Halloween thing. Last night when the Christmas lights should have turned off, the other lamp turned off and the Christmas test lamp stayed on. Tests i ran again today were ok.

I ran a scene test and all was ok, at least it said successful when finished, and i did see the isy change, and the light change.

 

Note. I thought it might be the tri-light lamp i was using with a single way cfl bulb for testing the Christmas light circuit,, so i got another lamp, and just unplugged the lamp i was using. The other lamp turned off, and when i plugged the replacement test lamp in, both lamps turned on. The isy still showed off, so i toggled the light on and off from the isy, and now both lights are in the sate they should be. I didn't think unplugging a lamp should have an affect on another device.

Brad