apostolakisl

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.

I have 1) Several Harmony remotes (2 890's and 1 900) 2) A GC IRtach 3) The IR version of ISY with the network module I have all these crossed referencing each other. It works quite well. I don't see any problem in having the GC unit not locally store the codes. The ISY network module stores the IR sequences and I don't know why it would be better to have the locally stored. Anyhow, I have my Hamrony remotes set to trigger the ISY which triggers the GC unit. I have the ISY set to trigger the GC from KPL's and programs (like when I leave the house it shuts all AV stuff off). It is a rather complex web. Probably the best way to simplifiy the web would be to get rid of the Harmony and use a tablet or phone to work through the ISY. But, I still like real buttons when I am watching TV. It just is so much faster and you don't have to look away from the TV. It seems silly, but when you want a quick pause or mute of the TV, you don't want to have to wake your device up and hit the correct spot on the screen without accidentally brushing some other "button" which activates somethinge else.

This post of mine on a previous thread may help you to understand the logic. Two concepts: 1) Triggers 2) True vs False after the trigger 1) Most ISY statements are triggers under certain situations. Some things (like integer variables) are never triggers. - - Control: Triggers whenever the action listed is physically taken on that switch (responding to a program or scene is NOT a physical act on that switch). ie Control switched on will trigger with an "on" press every time. It does not matter if it is already on to start with. NOTHING else you do to that switch is a trigger. Dim up, dim down, off, fast on, etc, etc will NOT trigger no matter what (however they still will evaluate when the program runs by some other trigger). (Note: with motion detectors, the act of "physically pushing" is actually the act of presenting motion to it. - - Status: Triggers with a change in status regardless of what caused the change. ie 'Status on' will trigger with every change in status regardless if being "on" ever occurred and regardless if the change occured because the switch itself was pressed or because it responded to a scene or program. For example, on to Off, 50% to 55%, On to 45%, etc. will all trigger. It will not trigger if it is on and you press on, or off and you press off. The trueness or falseness of the statement is independent of whether it was the trigger. - - State variables: Trigger on any change in the variable's value. - - From:To times: Both the from and the to time itself is a trigger. - - An outside program or manual "run if" is a trigger - - Most Elk events are triggers (like zone status change, or armed change, but not voltage) 2) Once a trigger event occurs, then EVERY line is evaluated, and either the "THEN" or "ELSE" clause will execute every time. - - Control statements are always false unless it was the trigger. If something else triggered the program, then it would be impossible to simultaneously have received an "on" or "off" or whatever was listed. A control statement is true if 1) it is the trigger, and 2 it is written as an "is" statement. It will run false if written "is not". - - Status statements will be true if at the time of the trigger the status is as listed, regardless of how the program was triggered. Use "is not" is commonly used with status for "is not off" so that the light dimmed to any level will run true. - - State and Integer variables evaluate the same way. If the actual value is as the program line asks, it is true, otherwise it is false. It doesn't matter how the program was triggered. - - From:To times: The from time is a trigger and will be "true" when self triggered at that time. The "to" time will trigger the program and evaluate to false at that self trigger. If something else triggers the program, a from:to line will be true between the times, and false otherwise. (NOTE: if the to time is before the from time, the program will not be a trigger. Like if you say sunrise to 7am, and sunrise at that time of year is after 7am, then neither the from nor to are triggers, and if something else triggers it, it will be false) Motion Detectors have a feature to only send "on" commands as lee mentioned. Choices are to only send an "on", or to send "on" followed by "off" according to an internal timer if no further motion is detected. If set to only send "on", they will only trigger "control on" statements. They will never trigger a "status" statement since the status is always on and thus never changes. If set to the on mode, they statement "status is on" will never be a trigger and always evaluate to true. So the combo of using the "on only" mode and a "status" statement serves no purpose. Think of a light switch that is always on, and every time you walk in the room, you hit the "on" switch even though it is already on. Multiple lines in a program connected by "OR" statements require only one line to be true for the entire statement to be true Multiple lines connected by "AND" statements will be false unless all lines are true. Using paranthesis combined with 'AND/OR' statements allows for various combinations and follows the standard rules you learned in high school algebra.

Putting this in the context of Elk. Elk rules only trigger on the FIRST line (whatever is listed immediately after "whenever"). ISY Programs will trigger off of any line. You'll notice that "Whenever it is dark outside" is not an option because that has no trigger time. It is only offered as a secondary condition to be checked whenever something else triggers (like Whenver zone x is violated) Elk rules have no "OR" statements. That means you would need an entire rule for every "or" you want. Elk rules have no "ELSE" clause. Meaning that again you would need two rules to do what one program can do in ISY Once an Elk rule triggers a timer, the timer is no longer part of the rule. The timer runs independently. In ISY, the timer is running within the program, so if the program gets interupted, the timer stops. This feature can confuse people, but it does give the program more control. As Lee mentioned, "wait" statements and "repeat" statements both offer the opportunity for interuption. You'll also notice in Elk rules, when you write a rule to trigger a timer, it offers you the option to restart if already running, that option exists because the timer is a separate thing. There are ways to get around this interupting of a program in a wait. It requires using 2 programs where the first program calls the second program. This is really the only situation where ISY requires two programs to do what Elk could do in one rule. But no worries, ISY has enough room for a gazillion programs, Elk is very constrained in the number of rules. ISY also lets you organize your programs in folders so you can follow your logic later on when you want to do some editing.

right, you didnt' put the wait 2 minutes in the else.

My suspicion would be that your PLM is having some sort of issue. Direct links between devices are only monitored by ISY, it doesn't do anything but listen, and the listening is really done by the PLM (the ISY listens to the PLM). Perhaps you PLM was interjecting noise? It might be worth it to try a different PLM.

I agree - I tried this on my one (only) 2477D V.40 and received the same results and virtually identical event log. I have tried disabling programs, removing my passive coupler, and adding accesspoints to no avail. The ISY seems to regard every other paddle press as a "duplicate" event. By slowing the paddle presses to 1 every 3 seconds, the ISY recognizes the presses as "unique" events. This does appear to be something related to the 2477D or the way that the ISY interprets its communications. I have been running similar counting programs on non-dual band relays and dimmers since variables were introduced (fan timer programs). I have never seen a hiccup on these. OK, yes. I just did it rapid fire and had the same problem. If you wait a few seconds between clicks it gets every one. I have no idea why it would do that.

Because Elk zone garage 1 and garage 2 are triggers. If you close the door before 2 minuts have passed, the zones become secure, the program re-triggers, the wait terminates, the program evaluates as false which runs the else. If you want to fix this, make the else clause say the same stuff as the then clause. Then it will turn off 2minutes after the door is closed, or 2 minutes after the door is opened if no one closes the door. Also, you need paranthesis around the two elk zones. From sunrise to sunset And (elk zone 1 or elk zone 2)