oberkc

If you were going to link the relays to a KPL button, then would the ISY not know the status of the scene containing the relay button? While this may not be direct feedback, if communication is good, the scene status and relay status would be the same, correct? Is this what you meant when you said "manually activate"....that is, using a KPL button?

I, too, am interested in this. I am a new user of the IOLinc (garage door kit) and notice that my relay status is always on, but that the sensor status accurately reflects the state of the door. I don't know if this is normal, a problem, or whether I should care. In your case, do you also have two devices (relay and sensor) for each of your six IOLincs? If so, are you looking at the status of the relay or sensor? I also notice an option "relay follows input" in the configuration options of the IOLinc. I wonder if this option must be checked in order for the relay status to match the sensor status, should this be important for it to do so.

Rand, When two devices are linked (put in a scene) manually, is the controlling device sending a scene command or a direct on/off command? I am assuming it is a scene command. Perhaps there is an unstated assumption here that when two devices are linked manually, they issue direct commands similar to those of the ISY direct commands?

I am with the others harboring a certain level of uncertainty about any conclusions at this point. In an attempt to help, some have suggested creating a scene. You have yet to try this yet?! In general, I have found that when one uses the ISY-99, links (known as insteon scenes) must be created by the ISY if you want to take advantage of the capability offered. Manually creating them as you have done here tends to cause problems when trying to use the ISY. This is true whether one is talking about garage doors or switches. With regard to the garage door kit, I suggest starting over. Remove the device from the ISY. Factory reset the relay (eliminating residual links). Reset, also, the switch to which the relay was linked manually. Re-add the device to the ISY. Disregard the smarthome instructions for linking (creating scenes). These instructions assume you have no whole-house controller such as the ISY-99. The ISY will create the scenes for you, instead. If you want to link a garage door kit and a switch, do it through the ISY, rather than manually. Once the device shows up in your admin panel, review the UDI wiki instructions for the garage door sensor. I have found the following pages most useful: http://www.universal-devices.com/mwiki/index.php?title=ISY-99i/ISY-26_INSTEON:Garage_Door_Kit http://www.universal-devices.com/mwiki/index.php?title=ISY-99i/ISY-26_INSTEON:Linking_an_I/O_Linc I have found the garage door kit to be the most complicated of the insteon devices I have used so far. It took me several attampts to get it working as I want. I am confident, also, that the smart people around here can help out, but it tends to work better if you follow their suggestions and respond to their questions.

I am just starting to fool around with the garage door kit, myself. I have found there to be many things that can go wrong. While I have not tried setting up the kit in the same configuration as you, I have at least found it to work as advertised with the ISY. I am curious as to your response to Michel's most recent (Jan 24) questions. When you created a scene through ISY, did the scene include the relay? The sensor? The dimmer switch? Which of these, if any, were controllers? When you selected the various devices within the created scene (and when selecting the scene, itself), what are their "on" levels. More specifically, what is the "on" level for the relay. I found that when adding a controller to a scene with the relay, the relay "on" level was initially set to zero and that the relay appeared not to respond to an on command. I had to change the relay "on" levels to 100% before it would respond. When looking at your IOlinc options, have you tried the "relay follows sensor" option? Without this, I wonder if your IOlinc thinks that it is in only one state. That statement concerns me a little. Are you speaking of the state of the sensor or the state of the relay? If you don't see state changes of the sensor, then I wonder if you are experiencing some intermittent communication issues. My relay state also does not change (it is always on), but I assume this is normal for my setup. However, I am using only "on" commands (momentary to activate the garage door. I wonder, again, if selecting "relay follows sensor" would help you with your problem.

Devices CAN be part of multiple scenes, but controller only of one scene. This means that you COULD make a new scene that includes all devices that are part of your other two, with the addition of your keypad button as contoller to "control both scenes". You cannot use an existing scene controller (buttons D or E, in your case) to control additional scenes. Alternatively, with the ISY, you could create a program to turn on the existing two scenes in response to a keypad button. Yes, if you include the keypad button as responder in both scenes that were created to link your wall switches.

OK. So there was a problem, and it is now solved. I thought the problem still existed. Thanks.

I must have misunderstood your initial post of not being able to find anything on the wiki. You can get an IRLinc reciever, but this is unnecessary if your ISY is within line-of-site of your transmitter, or you are using one of those IR emitters from your block. My understanding is the the ISY has a library of codes, or you can teach the ISY to use a code if it is not part of the existing library. The link I put on the earlier post includes a section: "Teaching IR Codes To the ISY-99.9i (in place of or in addition to the 40 default IR codes)" I found this to be reasonably clear, when done in front of the ISY admin control panel. Is this not what you are looking for? As far as hardware issues, I don't understand the problem....Point the remote at the ISY. I am failing to understand the hardware confusion.

On the wiki, I used "IR" as a search criteria, and came up with many hits, including: http://www.universal-devices.com/mwiki/index.php?title=ISY-99i_Series_INSTEON:Quick_IR_Tutorial As far as your existing IR system, I am with wpmjones...attach an emitter to your ISY.

If you add an else statement to return the thermostats to how you want them when the house is occupied, you may get close to what you want, but not close enough. At risk of repeating the earlier observations, this program would run the "then" condition if '*Armed Away' changes state from true-to-false between 7:30 Friday and 7:00 Monday. This program would run the "else" condition any time the '*Armed Away' changes state from false to true during that same time period. Since this program would perform an automatic evaluation at 7:30 fridays and at 7:00 mondays, this program would also run the "else" condition at 7:30 Friday (unless a simultaneous '*Armed Away' false was received...unlikely) and at 0700 on Monday. I believe that this program will also execute the "else" statement at any other time of the week that '*Armed Away' changes state. I assume that this is not what you want. I suggest creating a program folder, with the condtions if On Fri From 7:30:00PM To 7:00:00AM (3 days later) then run the programs in this folder In that folder add a program: If Program '*Armed Away' is False then Set 'Indoor / Thermostats / Second Floor / HVAC Second Floor' Mode Auto Wait 5 seconds Set 'Indoor / Thermostats / Second Floor / HVAC Second Floor' Fan Auto Wait 5 seconds Set 'Indoor / Thermostats / Second Floor / HVAC Second Floor' 60° (Heat Setpoint) Wait 5 seconds Set 'Indoor / Thermostats / Second Floor / HVAC Second Floor' 80° (Cool Setpoint) else Set thermostats the way you want them when occupied. However, with this approach, if you happen to be in an unoccupied state at monday 0700, then there this approach offers no way to return the house to occupied. There is also a potential problem if your program is executing exactly at 0700 monday, at which point execution stops at whatever point it is. I can't help but wonder if you already have a program to return the house to occupied state at 0700 monday, but have not mentioned this.

If I may infer your intention here: is it to set the thermostats to one setting for the weekend and another for the weekdays? If so, you can add an "else" statement that would execute on monday morning at 0730 (based on your current condition). Perhaps this could be your weekday thermostat settings?

I believe your statement is accurate, but let me put it another way to see that you agree we are saying the same thing: All programs who's "if" condition is based on a given device will be evaluated any time the status of that device changes. Understand another thing...I am an engineer. This means that I am relatively good at math. I am not good with languages, including english.

Yes, it does make for a few extra programs. It is, I believe, important to understand what happens, however, in order to become proficient on this thing. You may want to do a forum and wiki search on "status". The big thing that I want to point out is in regards to your code: AND Status 'Portrait Light' is On If this is one of your program conditions, your program condition will get evaluated EVERY TIME there is a change in status of "portrait light". If status changes from on to off, then this WILL get evaluated. Changing from off to on will force an evaluation. Changing from on to off (as a result of your "then" condition) is what forced the evaluation of your program conditions.

I don't believe this to be a problem with double-presses or fast-on or anything like that. This appears to me to be the oft-discussed issue when one's program "then" or "else" responses change one or more of the "if" conditions. I am actually a little surprised that this does not result in something like an infinite do loop. I think the missing piece is a full understanding of when it is that a program evaluates the "if" condition. My understanding is that an if condition is evaluated at any change of state, or at reciept of included control input. In your case, for example, your "portrait lights" are off. You press your harmony button, which sends the "IR_001" signal to the ISY. This receipt of the IR_001 signal forces an evaluation of your conditions, which is, at this point, true. As a result, your "then" statement executes. Your then statement results in your "Portrait Light" turning on. Unfornately, this is one of the events which forces an evaluation of your program conditions. Now that the light is on (and the fact that there was no IR_001 signal recieved) the condition reports as false, and the "else" statement executes. I suspect the better way to solve your problem is to break this into two programs. If IR 'IR_001' is Pressed AND Status 'Portrait Light' is Off Then Set 'Portrait Light' On Else If IR 'IR_001' is Pressed AND Status 'Portrait Light' is On Then Set 'Portrait Light' Off Else

Yes. I am not necessarily disagreeing. I just wanted to offer a potential programming solution given the way things currently stand.

Except, I fear, that the first example may fail for the same reasons as did yours...that when the program first executes the "then" path, forces another evaluation of the conditions at the 1 second point. When this happens, the 5-second timer stops, and the condition evaluates as false.

I will let you judge whether this is overly complex. Conceptually, it sounds as if devonsprings wishes to have a window of time from 1 to 5 seconds after pressing a keypad button. Within that window, if another button "nightimemode" is pressed, the whole house goes into nightime scene. For the time window, I would use a folder. I would create a flag program to use as the folder condition. For the wholehouse lighting, I would create a nightime scene. Nightime folder condition: if program "flag" is true then run the programs in this folder Flag program: if then else Opens the folder time window (outside of folder): if control "KPL-B" is switched on then wait 1 second set program "flag" as true wait 4 seconds set program "flag" as false else Look see if nightimebutton is pressed (put IN folder): If Status KPL-B is on and control nightimebutton is set on then set scene "nightime scene" else Hopefully, this is clear and can be tailored to fit existing device and scene names.

I, too, was under the impression that DevonSprings scenario did NOT necessarily pass wires through the switch box. I thought power to the lighting fixtures were direct.

That is my understanding. Still, if you are going to delete the devices and add them, I suggest performing a factory reset, just to be sure.

I believe this is true in our area, as well. I am not sure that the proposed system fails this requirement, however. I have a switch at the wall near the entry. I have a light in the ceiling (controlled by the inlinelinc). The switch controls the light. What part is he not passing?

I found the instructions to be ambiguous, or inconsistent, or both. I don't think I followed them exactly, either. Nor do I think the IOlinc cares whether "on" is open or closed, so I do not suspect this to be your problem. "Manually" linked it? With what other insteon device? Did you not use the ISY-99 to establish your links (or scenes)?

I think the OP knows this to be true, but is making the point that the wiring is simplified using his approach (which is true). Taken to the extreme, one could even wire in such a way as to maximize communication reliability. Cleary, there are potential advantages (along with the potential disadvantages) to wiring this way. I must admit to wondering about the code implications. I was not sure whether code required certain wiring techniques, or simply the ability to control lights at certain locations. I thought it was the latter.

I can only assume that the percieved state of your sensro was initially incorrect and that the query corrected this. I understand that the state of the ISY is based on acknowledgement from devices or reciept of state changes from devices. It can get out of sync if it fails to communicate with those devices, however. Failure to communicate is not generally a problem with the ISY, per se, but due to noise or interference of some type on the powerlines. If there are communication problems, the ISY will assume a state for each device based on latest commands. This assumed state can be incorrect. Do you ever notice any failure of a device to respond to commands? How reliable do you perceive your insteon system?

In math, multiplication and division happen ahead of addition and subtraction. One can add parentheses to dictate which operations happen first. The same is true with logic. I understand that the ISY-99 follows the standard boolean logic prioritization. Like multiplication over addition, "Ands" happen ahead of "Ors". Like with math, the ISY also provides the ability to group operations with parentheses, forcing the operations within the parentheses to be evaluated as a group. For example, "A and B or C" is naturally evaluated "(A and or C". However, one could add one's own parentheses and force this to be "A and (B or C)". These two statements have different outputs (true or false) with varying inputs (A, B, or C).

Buttons are easily replaceable. You could even choose one of your two. For example, away. On means away. Off means not away. If you choose to keep both, consider the possibilities if both are on (or both are off). Can this happen? Does this have any adverse consequences on your programs or folders? If you have not already, consider making these to "Mutually Exclusive".