apostolakisl

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)

I just tested one of my dual band switchlinks, no probs. Added one for every click. 2477d v.40

I agree with oberkc in that the program should work. Are you sure the ISY is receiving the "control on" from the device. Just because the status is listed as "on", doesn't mean it received an "on" command just now, only that the last time it received any command, it was an "on" command. Try writing a simple program that has only that motion sensor control on listed in the if section. Then check your program summary page to see if it is triggering that program last run time as expected when you walk in front of it.

There are quite a few flaws to the Insteon logic in my opinion which is probably why it works like 99% of the time instead of 100%. Not that they haven't made the best of less than perfect environment, or maybe not, I really can't say. For example, for a 3 hop timeslot to be reserved, all the devices have to receive the first broadcast. If a device is 2 hops away from getting the message, it could start its own separate broadcast while the first signal is still in the midst of those 2 hops. Then you get 2 overlapping messages and I just don't know what the devices make of that. Having lots of devices helps with the exponential growth of the signal as it hops, but it also increases the possibility of getting simultaneous broadcasts. My wife says, "yes it is possible to have too many Insteon devices, thus causing marital difficulties"

Are you sure it tells you everything the dedicated thermostat does? If you hold the "advanced" button on the carrier thermostat you get a huge menu of stuff. This includes a log of any faults, run times in the various modes, and a ton of other stuff. If your system runs perfectly then no, you don't need a lot of that info. But if you ever have a fault, 1) you can diagnose it yourself if you have much knowledge of the stuff, and 2) your hvac guy can go straight to the problem and not screw around replacing stuff that isn't broke as he tries to trouble shoot an intermittent problem.

I have the same carrier unit you have with the same fancy thermostats. You can use a standard thermostat instead of the carrier and then it wires up like normal instead of the rs485. But, you lose all the diagnostic and maintenance info that the dedicated carrier thermostat offers. I looked at getting the SAM unit but laughed at the absurd price. In short, I decided that I really didn't need to control my thermostat from my ISY.

Yes. You want acknowledgements for linking. If you are using set buttons to setup scenes, you for sure want acknowledgements so they can let you know if a communication was missed lest you end up with some really messed up scenarios. The powerline is not full duplex...it's only half. There cannot be two messages at the same time since they all share the carrier. Think of it like the radios where when you are pressing the button to send, the other guy can't talk back. You might hold the button and say, "The mission is a go...I repeat, the mission is a go." Now someone hearing the other end can't push their button in the middle and say "ok, we got you the first time". They have to wait until you are done transmitting (including your repeat) before they can speak back. That's exactly why radio communications end with "Over". That's essentially the way of saying "I am done transmitting; you may transmit now." For Insteon devices, the "Over" is implied to be after the last hop. So the receiving device gets the message with 2 hops left, he must (and will) wait out those 2 hops so he knows "the other guy has stopped transmitting". An ACK during linking makes sense. But an ACK during a regular command still doesn't make sense and in fact would just add needless noise. Aside from having an ISY which might repeat the entire process if an ACK isn't received, regular Insteon stuff doesn't seem to make any use of it. I get your analogy about the radio. But you could also "let off the button" in between the 3 hops, wait for an ACK, and then push the button again if none is received. I kind of feel like I am watching Beetle Juice here. So I understand that it is the way it is, but the necessity of the ACK seems to be missing. Even in an ISY environment, the ACK doesn't serve much use. If the message didn't get through on the first 3 hops, what do you think the odds are that doing the exact same 3 hop sequence a second time will turn out any different? My bet is pretty slim. Perhaps if a noise maker quit making noise in that split second between the first and second try. Benjamin Franklin once said, "only a fool does the same thing twice and expects a different result".

So would it be safe to say that the 3 hop and done is the Insteon standard, and that the entire 3 hop and done thing can start all over again once you involve a plm/isy? And your saying that all three hops always occur even if it only took one hop? If indeed this is the case, then what is the purpose of sending an ACK (at least in a non-ISY environment)? In a non-ISY situation, why would any switch need to know the signal got there if it is going to repeat 3 times either way? I'm not saying that this isn't the case, but from a logic standpoint it baffles me. I thought the purpose of the ACK was to shut things down to open up the power lines for other comm.

This post of mine regarding a different but similar question should help. 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. 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. 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 2) Once a trigger event occurs, then EVERY line is evaluated. - - 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.

Makes sense. You can also use ISY's Find and Replace function also, assuming you have the programs all next to each other, if you start with the first one you just hit the "replace in selected" button then find and it will jump to the next where you hit "replace" again and so forth till you get to the last one.

You could refine it a little an drop one program Not sure I understand your last question. These programs will run 3 network resources sequentially with each sequential push of the KPL button. IF $matrixmode is <3 THEN set $matrixmode += 1 init $matrixmode to $matrixmode ELSE set $matrixmode = 0 init $matrixmode to 0 Write one program for each level: IF KPL button is switched on and $matrixmode = 0 THEN networkresource 1 run first program "if" ELSE - - IF KPL Button is switched on and $matrixmode is 1 THEN networkresource 2 run first program if ELSE - - Etc.

I know you already did and R and R with smarthome on it, but is is still possible to have 2 bad switches. I assume you have other toggle lincs in your house that are wired to a load that are behaving fine. Consider swapping them and see if the problem follows the switch or stays at the location. Have you tried pulling the air gap instead of resetting the breaker? If the problem is something with your 3 way wiring where a different switch is affecting power to this switch, resetting the breaker may be resetting a different switch which in turn is affecting this switch. Pulling the air gap on just this switch will only affect that switch. If it starts working again after an air gap reset, you can at least say that the problem is internal to that switch once locked up. That doesn't mean that some other switch isn't transiently doing something which scrambles the logic control on that switch. Consider going through all of the j-boxes that have any wires to that switch and checking that your splices are tight. Arcing can cause transient power surges that may be locking it up. When the switch stops functioning, is there any LED activity? Since I don't own any toggle lincs, I don't know what the led is supposed to look like when the light is on vs off, but what state is it indicating (if it is on at all).

My understanding is as follows: The original signal is sent out over the power lines. All devices within range will hear the signal. In a clean environment, that very well may be every device in your house, thus no hops needed. After a predetermined number of 60hz cycles on your power line, all the devices repeat the signal. Each repeat has an additional piece of info added that indicates it is a repeat until it hits 3 at which point it gives up. Once the target device receives the signal, an acknowledgement is sent which shuts down the hop process.

The first thing to do is look at your program summary page. If the light is consistent, you can pull the screen up a few minutes before you expect it to turn on/off and watch for a program to update it's last run time as the light does it's thing. Once you see what program did it, then you can figure out why.