apostolakisl

Thank you, I spent an hour or so this morning setting up the variables and changing the programs to use the proper variables because I have a few in use already and that messed up the number system. I noted on your screen capture that it thinks that iEvery.third.week and iEvery.fourth.week are true currently. At midnight will get a notification email of what I thinks the date is if it's off or not. Alan The number next to the "Every x whatevers" is not a 1/0 as in true/false. They count through the weeks, 0,1,2,3,0,1, etc. For example, every 4th week cycle and every third are below 0,1,2,3,0,1,2,3,0,1,2,3,0,1,2 0,1,2,0,1,2,0,1,2,0,1,2,0,1,2 So, you can see, every so often, the numbers line up. The way to use the variable is to first look at what today is in the schedule. So today both every 3rd week and every 4th are both zero. Say, you want to send an alert every 4 weeks, and you want it to start in 2 weeks. So 2 weeks from now, the variable will be "2". Then after another 4 weeks it will be "2" again. You write your program as such If $i.every.fourth.week is 2 Then do whatever. If you look at the equation it will make sense. For example, the every 4 weeks program, is dividing the total number of weeks since the counter started (I set mine to start Jan 1, 1900) by 4, then it sets the variable as the remainder of that division. All of this is based off of the number of days since Jan 1, 1900 (at least as I set the variable). If you look at my screen shot, you'll see it has bee 41,335 days since then. That keeps an uniterupted running tally of days, which when divided by 7 gives you the same thing for weeks. What you set that number at is not relevant to anything except that this is how MS Excel does it. And I used excel to test my programs.

Here is a screen shot from my computer this morning. You can just copy all the values as they are on m screen skipping the ones that have nothing to do with this program (13-33, 42, 43)

You have to set the variables to start with. It's like a clock, you need to tell it the date to start with, after that it keeps going on its own. Go to the integer variables page and manually enter the 1) month (3) 2) day (2) 3) year (2013) 4) leap year (1) 5) day of week (6) 6) day of year (61) that is 31+28+2 Also, I would try to test such things with a time that is further in the future than two minutes. Java is running the clock you see on your computer screen. When you start the admin console, it loads the time from ISY, then Java runs the clock on your local machine and in my experience, it can get way off fast. Lastly, you need to set up the email addresses in ISY. Have you confirmed that your ISY is properly sending emails using the address you used in that program? When trying to figure out what is going on, go to the program summary page. For each program, it will show you the last time the program ran, whether it ran true or false, and the next scheduled time. The program you wrote should list tonight at 10:35 as the next run time, and last night at 10:35 as the last run time. It should have ran 'true' last night, and it will run 'false' tonight (and every night until 4/1). If it lists that it ran last night at 10:35 but ran false, then that means you didn't "set the clock" (fill out the starting variables I listed above). If it says it did run last night and ran "true", then that means your email settings aren't working. You can always right click on a program and hit "run then" or "run else" to test that the "then" or "else" clause are doing what you expect.

If $iDay.of.Month is 9 And Time is (whatever you want) Then - No Actions - (To add one, press 'Action') Else - No Actions - (To add one, press 'Action') This will execute whatever you put in the "then" section whenever it is the 9th day of any month at whatever time you specified. Incidentally, I am not sure what happens if you import a program that refers to a non-existent variable. I have never tried it. You might need to re-import the programs if you did that first. Maybe not. Let me know.

OHHHH SHOOOT I just saw a mistake in my directions. Leap year variable is supposed to be set to 1 this year. 0 is a leap year, not 3 as I wrote. Please be sure to set leap year to 1.

Unzip the file, Right click on the "my programs" folder at the top of the folder tree on the "programs" page, the click import, and point it to the file you just unzipped. Just follow the directions I put on the wiki. There are like 4 steps total.

You are correct. You would need to use an OR statement to connect 12 dates per year for as many years into the future as you want. If you haven't already started using variables, implementing the programs is not hard at all. Just download them from the wiki and install them. Then label the variables using the screen shots. Then all that is left is setting all the variables to today's date (month 3, day 1, year 2013, and day of year (31 plus 28 plus 1). The other variables will self populate at midnight. It only gets tricky if you already are using the same variables. But I get the feeling you haven't used any of them yet.

You can have programs run on certain days of the week, as mentioned, just by unchecking "all days" and then checking just the day you want. You can have programs run on specific dates, like 01/01/2014 at 1am. But you can't have it run every 1/1 at 1am, at least not without more effort. I wrote a whole series of program that uses ISY variables so that you can do recurring dates without having to set every date specifically. For example, you can do every 3rd day, or the 15th of every month, or every 4 weeks, or every Dec 25th. Here is the link to it in the wiki. http://wiki.universal-devices.com/index ... _Variables

Perhaps you can use the switched outlets on the back of your receiver? They shut down 100% when off, assuming you have a receiver, and you always have it on when using the system. Otherwise a wall wart or resistor. If you have a strand of dead christmas light with the pass through plug, that works well. You cut the wire and solder in a resistor and then plug it in. Since it has a pass through plug it doesn't require any other plug multipliers to still plug in your lights.

Your program should trigger on any change of state of the Elk. It must change from anything else to armed away to run true, all other changes will run false. So, either something is wrong with your ISY/Elk, or something else is changing your variables. First, check your program summary page. Assuming you are home, your alarm will not be armed away so the program should be false. If it is true, something is wrong with your Elk/ISY. Second, arm the alarm to away. You should immediately see the program change to true and show "running then". After 8 minutes it should show a finished run time and the "running then" change to "idle". Now, there is no excuse for variables not being "0". If they are not 0 then look to see if you have another program that ran at the same time this program finished, a program that might have run because those variables are state variables and they were a trigger for some other program to change them.

Fine work. It is nice how you guys actually pay attention to your customers.

This morning I was able to get the flicker to happen. Yesterday evening it was still daylight and perhaps it just wasn't dim enough for me to see the flicker. It flickered with query. So indeed it would appear to be something with the powerline "noise" that is an Insteon command. Not sure whether the root of the flicker is in the switch or the bulbs. All 3 bulbs on the switch seem to be in unison, so the switch itself is certainly a reasonable candidate.

So I went to test your theory. And of course it isn't flickering no matter what now. I'll try in the morning again.

I have my kids bedroom lights set to shut off after 30 minutes, and during the last minute I have the beeper set to beep once per second as a warning. I noticed the other day that a different set of lights on a different switch flicker in sync with the beep. It is as if the beep is drawing huge current with each beep. Of course, the beep is not doing that. The kids lights are icon dimmers (2876db v.39) and the other light that actually does the flickering is on a 2476d V.38 (at least that is the load switch). The load on the flickering light are LED's. The load on the kids lights are incandescent (and they don't flicker, only the led's on the other switch). Any idea on what the mechanism of this would be? I'm going to rule out power draw and consider that the problem is either in the 2476d responding to the beep command from ISY erroneously with a flicker, or that the lights themselves are responding to the power line "noise" that is the beep command. But I can't think of a reason either of these would happen.

Wow, those are some serious brackets. Something you had in the "I'm saving these brackets just in case I ever need them in the future" box? (I have several of those boxes and my wife hates them). How are they attached to the meter box. . . since it would be illegal and all to open it up for running a screw through the backside. By the way, you probably knew this, but the latest firmware on the CAI board posts directly to ISY variables. . . no need for any intervening PC/linux thing.

I kind of feel like you will be re-inventing the wheel here. Teaching rasberry pi to understand IR commands and then processing that info so as to post it to the ISY REST interface is a lot of work and several extra steps. All you need is inexpensive, off the shelf ready to go learning remote that ISY directly understands and already has dedicated functionality for.

no-ip.com still has free dyndns hosting.

If your remote control is one that can learn codes or has a library of codes, you set your remote to transmit one of the codes that ISY understands as part of your macro that turns stuff on. The ISY is just one more device like your TV, cable box, stereo, etc.

The purpose of "control" is to ask the question: "Did someone push the button?" The purpose of "status" is to ask the question: "At present, what state is the light in?" So these are very different things which serve different purposes. The below program asks the question, "when I open the front door, and it is dark outside, are the outside lights already on?" If not, it runs a separate program which turns them on for a specific period of time. I have done it this way so that if the light were already on, then the lights would be left alone (no off timer gets started). If Program 'Dark Outside' is True And Elk Zone 'Front Door' is Violated And Status 'Foyer / Foyer-Coach L' is Off And Status 'Foyer / Foyer-Portico Can L' is Off Then Run Program 'front door 2' (Else Path) Else - No Actions - (To add one, press 'Action') The below program asks the question, "is the light already off when someone pushes the off button?". If so, it turns the light on to a low setting. This is a function I use as a night light. When you wake up to go to the bathroom, you can easily bring the lights up just bright enough to see without overly waking you. If Status 'Alexis Room / Alex Bath-Mirror L' is Off And Control 'Alexis Room / Alex Bath-Mirror L' is switched Off Then Set 'Alexis Room / Alex Bath-Mirror L' 25% Else - No Actions - (To add one, press 'Action')

What do you mean by this? The itach has 3 ports, you select which port you want that IR command to use as the sending port when you set up the learning software. You can easily change it manually after the fact, it is one of the very first numbers in the code, I forget which one, but it is easy to figure out.

That is what "status" is for. Control means that you physically went to he device and "controlled" it by pushing the button. "control on" triggers itself only when an "on" command is received from that device. If something else triggers the program, it is false, since no one pushed the "on" button at the exact same point in time. Everyting I said is backwards if you use "control is not". It just swaps the true/false outcome of the event, but otherwise it is the same.

The "repeat 1 time" should not have changed anything. The default is to do things 1 time. "repeat 1 time" is only used after a repeat multiple times to signal that what comes after does not get repeated. This program will execute the else clause every single time that keypad changes status, and assuming the lead sensor is dry, will thus send you a text. You need 2 programs to do what you want. If Status 'Leak Sensor Basement Door-Wet' is On And Status 'Door Pad 8 / Door Pad 8-G / Away Mode' is Off Then Send Notification to 'Verizon Text' content 'Leak Alarm Basement Door' Repeat Every 2 seconds Set Scene 'Leak Alarm' On Wait 2 seconds Set Scene 'Leak Alarm' Off Else - - blank If Status 'Leak Sensor Basement Door-Wet' is On And Status 'Door Pad 8 / Door Pad 8-G / Away Mode' is On Then Send Notification to 'Verizon Text' content 'Leak Alarm Basement Door' Else - - blank If you still are getting multiple emails, then the cause would be that the leak sensor is not holding steady at on. In other words, it is maybe not fully wet and it is sensing wet, then not wet, etc. If indeed that is the case, let me know, and I can show you how to limit the texts to 1 per some period of time of your choosing. Edit: Here it is anyway. Program send text If $limit.text = 1 (this is a state variable you need to create) Then Send Notification to 'Verizon Text' content 'Leak Alarm Basement Door' wait 1 hour (or whatever) Set $limit.text to 0 Else - - And change the other two programs as follows If Status 'Leak Sensor Basement Door-Wet' is On And Status 'Door Pad 8 / Door Pad 8-G / Away Mode' is Off Then Set $limit.text to 1 Repeat Every 2 seconds Set Scene 'Leak Alarm' On Wait 2 seconds Set Scene 'Leak Alarm' Off Else - - blank If Status 'Leak Sensor Basement Door-Wet' is On And Status 'Door Pad 8 / Door Pad 8-G / Away Mode' is On Then Set $limit.text to 1 Else - - blank The program "send text" will only trigger and be true (and thus send a text) when the variable changes from 0 to 1. It will not run again no matter how many times the other 2 programs set the variable to 1, because it is already 1. State variables are only triggers when the change, so if it is already 1, setting it to 1 is not a change. Then an hour after it changes to 1, it resets itself back to 0, at which point it can be triggered again.

The only thing that would make you keep getting messages is that the program keeps re-triggering. Both If conditions are "status". That means any change in status of either thing will trigger the program, and if either item is false, you will get an Else execution and thus a text. The repeat and wait commands won't block that. Any item in the IF that is a trigger will automatically abort a Then or Else clause that is running and start over again. I don't know what this "door pad" is and I don't know if the water sensor could be flipping back and forth on/off/on/off. But one of those 2 things has to be changing repeatedly for you to get hammered with texts. Also, if this door pad device ever changes status, you will get the else text even if the leak sensor was never wet. I don't really understand why you have the Else clause at all. Don't you want a text to tell warn you of a leak in the Then section only?

GC doesn't send codes to ISY. You get the codes via a couple of possible methods and install them into ISY. I have an itach, which has the learning feature built in. Not all GC stuff has the learner built-in so you best confirm. You can download a lot of codes from http://www.remotecentral.com/ Many times they are in a hex format but GC has a free download that converts to their format. To learn your own codes, you download GC's free learning software which displays the codes when you point the remote at the GC (if your GC has the learning ir receiver like mine) However you get the codes, you copy them into the network module (their is a thread on that in here with directions) and set it as a network resource. Then you use programs to call the network resource which sends the instructions to the GC unit which shoots it to your AV stuff.

It is totally a double negative. Pretty much I think of "control is not" (as compared to "control is") to simply mean, swap the "then" and "else". Or in other words, figure out what the line would do under "control is", and then it does the opposite with "control is not" as far as then or else. The trigger on the other hand is the same regardless. "control is" when acting as its own trigger only runs true, any other trigger and it is always false. "control is not" when acting as its own trigger only runs false, any other trigger and it is always true. The only purpose I find for using "control is not" is when you have other conditions in the "if" section which lend themselves to being true or false and you want the particular "control" line to match the true or false simultaneous state of the other lines. As a single line in the "if" section, you get the same exact result if you just swap the "then" and "else" contents, so there is no point in using "control is not" as a single "if" condition.