Jump to content

oberkc

Members
  • Posts

    5855
  • Joined

  • Last visited

Everything posted by oberkc

  1. My first instinct is to create a program "folder", with the conditions that program 1 be true. In that folder, put a program with only the condition that program 2 be true. The folder condition must first be true in order for the program to be enabled.
  2. The only problem that I see is that the motion sensors will trigger their individual lights on at schedules different than the ISY program. Even if you set your motion sensor only to work at night, the motion sensors will each likely have a slightly different sense of "night", which is also slightly different that the ISY "dusk til dawn". This may be the best you can get, however, given your hardware selection.
  3. You can try another brand of CFL. I suspect that the CFL issue is just one of several problems you have. Try a scene test on some of your scenes and see if they pass (I bet some will fail). I suspect you have other devices throughout the house that are contributing to this problem. I would start by putting all your computer stuff (except ISY) on a filter. I would put your home theater on one, as well, including the monster power supply.
  4. I believe the key word was "unswitched" power. I think he suspected that somehow the power to the new device was being interrupted when the other switches were engaged. I find your CFL exterior lights to be the most intresting part so far. As mentioned by others, some of these can cause (or contribute to) communication problems. Since it is so easy to confirm, temporarily replace them with incandescent bulbs and see if your problem goes away. I also agree with BLH on pointing out the TVs, cable boxes, and even your monster power supply could contribute to communication problems. First, however, check on the exterior CFL bulbs. The problem seems to be only associated with these being on.
  5. fitzpatri8, I think he noticed LeeGs advice and even commented that it was a "great idea". I think he was just responding to some alternative suggestions and questions from me.
  6. This is not consistent with my understanding. I thought programs ceased "then" and "else" statements at the point where conditions are evaluated, at which point the program starts over, based upon the condition as evaluated. SLee is pretty good with this stuff. Perhaps I was wrong and it only happens in conjunction with 'wait' statements, as he says. I have read about much confusion about this topic. . In general, any change in status or reciept of contol related to the program conditions. If a change is to a device not part of the conditions, the program will not be affected. That DOES sound like a potential solution to your problem! I second your sentiments....great idea. Another thought that I had....does the ISY give you any options for this inlinelinc setup? If you select the device from the tree, are there anything like device options along the bottom that one could set up to ignore off commands? I know that my triggerlinc has such options.
  7. I am unsure of how you can control the amount of time the lights stay on, other than through the motion sensor settings (1min, 5min, 10min). I think the problem with one light going off after a minute is due to the fact that this is how you have them set. If 5 or 10 minutes is what you want, I suggest: -set the motion sensors to 5 or 10 minutes as you desire. -remove all four devices from your scene -add all four devices back, only as controllers (rather than just responders) -eliminate the program altogether. Setting it up this way will use scenes to turn all on if one or more is triggered. It will also turn them all off when one or more times out. It will also happen nearly instantaneously (no delay between first light and other three). I am having difficulty envisioning how you can use the ISY to turn these off, since the motion sensor does not appear to have the ability to disable the off signal. I think this could require additional hardware.
  8. My understanding is that programs that are disabled will not run, except when called by another program. If I understand your setup correctly, yours will not run on their own. Another thing that strikes me as a little unusual are your two folder conditions for home and away. One is true when off. The other is true when 10%. This leaves a broad range of potential conditions (on, greater than 10%, 1-9%) where neither is true. Is this as you want?
  9. I am also wondering if you have created some type of loop as a result of your "else" condition peforming action that affects your "if" conditions. The following example program is a lot like yours. if status of light is on then turn light on else turn light off When the light status is changed to on, it will run the else condition, which turns the light on, which forces another evaluation, which turns the light on, which forces another evalation, which..... Unfortunately, I am not directly familiar with the motion sensor light device. Are your "light X" devices refering to the motion sensor, the in-line-linc, or the fixture, itself? Did you add the 2494MS device to the ISY? Could you use your motion sensors as your program trigger, rather than the light?
  10. I am wondering if in-line links are among those devices that cannot be used as controllers in a scene. (I understand that these may not send a status message.) If so, I wonder if that limitation also applies to using them in program conditions.
  11. I am unsure what this is.
  12. I originally responded by stating my understanding that KPL buttons could not be reponders to other insteon devices. I forget from where I recall that, but I know that in some cases I have had to create a special scene, just to control the KPL button. After thinking further, however, I know that this is not always the case. I DO have KPL buttons as responders in a scene, and this works well. Perhaps this was an issue only with older versions of the KPL? I don't recall. Perhaps I am thinking where one may not control a KPL button from another KPL button. Having said that, I am now wondering again why your initial scenes don't work. While your programs may be currently working, I would prefer using scenes, if possible. If you are interested in a couple of theories: a. is it possible that some of your scenes had the KPL on level set to zero when activated by the RL button? b. is it possible that creating the mutually exclusive relationship between KPL buttons may cause a conflict with the scene controllers? For example what happens if KPL C and A are both on? Is it possible the scenes requiring both KPL buttons to be on cause a conflict with the mutually exclusive relationship? My money is on theory A.
  13. Unfortunately, my understanding is that one cannot control KPL buttons (other than the primary) via other insteon device, by putting it into a scene with the other insteon device as controller. The solution is as you have done: create a single-device scene (including only the KPL button) and controlling it via program. Hopefully, enabling the program will solve any remaining problems you have.
  14. That is my understanding, as well. Regarding the query, I understand that a this would work, if being a bit inelegant.
  15. 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?
  16. 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.
  17. 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?
  18. 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.
  19. 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.
  20. 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.
  21. OK. So there was a problem, and it is now solved. I thought the problem still existed. Thanks.
  22. 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.
  23. 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.
  24. 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.
  25. 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?
×
×
  • Create New...