apostolakisl

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.

Yes, it does seem like a relay should be replaceable with a dimmer (but not vice-versa). Is this truly a link table issue or is it a function of the ISY just not letting you do it?

My understanding is that "replace with" simply copies the links table over. So if the new device accepts the same links, then it should work. Feel free to correct me if I am wrong on this point, but this is what my experience would indicate. I have also used this to replace icon dimmers with switchlinc dimmers.

UD I think was trying to make the world simpler by providing their own mail server to all ISY owners (thus no settings for the user) (and except when their server is down ) Your reliability is now subject to your mail server instead of UD's. There are of course other reliability issues like a stable internet connection , but those issues would be the same regardless of what mail server you use.

Yes, the replace function works for that. If there are problems, I certainly had none. I replaced several of mine that way.

Are you using your own email server or are you using ISY's default? Last I checked, ISY's server was offline. That started a week or two ago. Try putting in your own smtp server settings. Also, make sure to follow the format listed for the "from" section.

Why don't you wire it up to a lamp or something simple and obvious like that. Then you can turn the relay on/off from ISY and the lamp on/off at it's own switch (which would be simulating the thermostat flipping on/off) and I think you'll soon figure it all out.

Yes, that is about what I have heard. I am not aware of ANY insteon switch rated by UL or anyone else to use ground as a neutral. While power draw (when not loaded) may be minimal, I still think it a bad idea to hook up insteon other than how shown in the instructions, as designed. I am not recommending it.

I understand that some devices are, in fact, as you describe...using ground as a neutral for very low-power uses. Speculation on some of the other sites I read suggest that it is because these types of devices were becoming more common that the code was revised to require neutral in each switch location. Insteon switches draw about .7watts (5.8ma). Not sure what UL has to say about that. Of course a load bearing Insteon runs the full load to neutral when on, so that would definitely be off limits. I suppose I could put my amp meter on the ground and see what that maestro switch does.

I would like to point out that it is possible (and fairly common) for the load and hot to be in one (switch or junction) box with just a run of 14/3 to the remote switch box(s). I had two 3 way circuits in my place wired this way before Insteon upgrades. -Xathros I just installed a Maestro Lutron MS-OPS2 switch in my office. It is an occupancy sensing switch. It appears that it uses ground to keep it working. The unit specifically says in the instructions that it won't work without ground connected and it has no neutral. So, it appears that a UL listing is possible leaking power to ground. Perhaps it is only a few micro-amps and that is why it is allowed.

As has been mentioned, I think your likely to be satisfied by adding KPL1 button D as a responder to scene 2. The question then is how you have sw1, 2, and 3 setup. Basically, to what scenes are they responders and controllers. For example, if all 3 are responders only, when you shut them off at the switches, none of the kpls will go off. If sw1 is set as a controller to scene 1, then kpl1,d will turn off, but the other kpl will stay on. If all 3 control scene 2, then shutting any of the 3 off will shut down everything. If SW1 controls scene 1, then shutting it off will turn of kpl1d, but everything else will stay on. There is no perfect way to do overlapping scenes because the logic will always find a way to contradict itself somehow in some scenario (depending on your personal brand of logic).

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 taken. 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) - - Status: Triggers with a change in status. 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. 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.

According to the diagram above, the switches are using both of the traveler wires. It's just not alternating the power from one to the other as in a "dumb" 3-way. I assume the one traveler is functioning as a communication wire and the other traveler is carrying the load. It must be as oberck said, since neither the master nor remote are connected to neutral. It would work to run to ground, but that would certainly not be UL allowed.