oberkc

At one point he was talking about AC, which suggests summer, during which times 80%+ humidity can be quite realistic. But, you still may win the doll. Regarding furnace use of humidity settings, my honeywell prestige can handle heat and cooling requirements based (at least in part) on humidity. For heating season, however, control of humidity generally requires a humidifier.

You have two thermostats? And they differ only by 1%? Or, you have an ISY which reports 83 and the thermostat reports 84? But later, you report that the ISY reports the values "properly"? I am confused.

That is what it is sounding like, to me. I am not convinced that this is true. I have a few dual-band devices, but most of mine are powerline-only, so my personal experience is limited. Based upon what I read around here, it seems to me that the RF range of some of these devices can be limited (and affected, in part, by installation factors) and that RF should not be counted on as primary communication. Insteon remains, in my mind, primarily a powerline communication protocol, with RF provided as backup. I suspect you will have to solve any powerline communication problems (assuming that is your problem) to get your system to work well.

If you want a time-based panic mode, perhaps something like: If Control 'Living Room- G' is switched Fast On Or Control 'Dining Room - G' is switched Fast On Or Control 'Master Bedroom-G' is switched Fast On Then Send Notification to 'Kerry - Text' content 'Emergency Trigger' run panic program (then path) wait 10 minutes run panic program (else path) Else - No Actions - (To add one, press 'Action') add a new program (I call it "panic"): if then Set 'Siren' On Set Scene 'Every Light' Fast On Wait 1 second Set Scene 'Every Light' Off Set 'Siren' Off run panic program (then path) else I am not sure if the detailed steps are perfect, or even correct, but I suspect you can get the approach I am suggesting.

One can also get LED that emit the cooler, white light. Although, I don't know if these are available in GU24 base. My perception, based upon the various devices I have tried, is that LED is more compatible with insteon. Still, this is device-dependent. I have found an LED bulb that caused problems, but mostly not that I notice. Again, this is unscientific. I measure nothing...just observe the results.

I would first check out the wiki. Try here: http://wiki.universal-devices.com/index ... on_Sensors

While I have no scientific proof of this, I also believe that CFLs can get noiser over time. Perhaps you are seeing the results of the normal aging process?

In general, if you have a situation where a device, when on, causes communication problems, I would first suspect the device is causing problems. If, when KPL on the wall is on, there are communication problems, what is the load. If the KPL on the wall controls your nightstand lights, what are these lights? Incandescent? LED? CFL? Something else? If anything other than incandescent, there is risk of a really noisy device, or one which attenuates signals.

For that, I believe you will need a program. I don't believe insteon scenes can support such a scenerio. You will also need to create an additional scene, with the KPL button as the only device, as responder. Your program would look something like: if status "bathroom light" is on or status "closet light" is on or status "bathroom fan" is on then set "scene with KPL button" on else set "scene with KPL button" off

One of the guiding general-purpose principles involving ISY is that you should use the ISY to manage your "scenes". If you have linked these switches prior to adding them to the ISY, I suggest factory resetting them. While it is not absolutely necessary to reset them, I believe this to be good practice in all cases. Best to start with a known clean device. Once factory reset, add ALL individual devices to the ISY. Once added, create two scenes, calling it whatever you want, representing the four-way and three-way circuit. Add the three devices to the four-way scene, defining each as a "controller". Add two devices to the three-way scene, defining each as a controller. At this point everything should be working great!

Nor the WAF. The more I read, the more I become convinced that a few access points, strategically place, remains a valuable part of any insteon installation.

I would not expect this to be possible. Synchrolinc, I understand, detects when an attached device is turned on and off, but never actually disrupts power to the device. An appliancelinc would remove power to the attached device. If a TV, for example, were to be attached to an appliancelinc, I don't believe one would be able to turn on the TV without first turning on the applicancelinc. This would not be true with a synchrolinc.

OK. Do you percieve a problem with any of this? Is the door opening and closing properly from the keypad button (it sounds as if it is)? Is the keypad button displaying proper status (it appears that it is)? The only thing that looks a little suspicous to me is sensor status. Given your apparent setup is slightly different than my suggestions, sensor status is as I would expect until the morning, where I expected sensor to be "ON", yet it was "OFF". I would recheck these readings. What else troubles you, if anything?

Forget about the relay, period. The status of the relay means nothing. Regarding the sensor, yes, it is possible that the sensor LED is on when the door is closed. This is based upon which wires from the sensor one uses and where the sensor is mounted (see step . Still, this may not matter. Is the keypad controlling the door as you like? Is the Keypad button displaying the status as you desire (on when open? On when closed?) Does the LED light consistently come on when closed and off when open? If everything else is working as you wish, then I would simply not worry about it and remember that LED on means closed and LED off means open. IN the end, does it really matter whether the LED is on or off? The sensor status in the ISY is the same as in mobilinc is the same as dashboard is the same everywhere, hopefully. What does the sensor state say (in ISY) when the door is closed and the LED is on? Typically, I would expect the green LED indication to indicate sensor is "ON". The only way that I know to reverse this is in the IOLinc options, where one can set trigger reverse. Did you set trigger reverse?

While I claim no particular knowledge about insteon communication and hops and waits and cycles, my perception is that my devices respond faster when good communication exists compared to when good communication does NOT exist. This tends to suggest, in my mind, that the responding devices are capable of responding before all repeats/hops. Am I missing something?

ellesshoo, my earlier post expressing uncertainty about whether programs based on "status" would be triggered by anything but a direct paddle press was, apparently well founded. Xathros was, indeed, correct. While I was pretty certain that program conditions based upon "control" would be triggered only by direct paddle/switch press, programs conditions based upon "status" will be triggered by change of status regardless of how/why achieved. I apologize for my confusion.

I find this one a bit confusing, as well. Momentary A is "Either on or off". Compare this to momentary B, which is "both on and off". Momentary A can be set to respond either to "ON" or to "OFF", depending the state during which it was linked. Once set, however, it will not respond to both, but only the command set. If you want it to respond to both, use momentary B. A little-discussed detail about the relay is that it does NOT broadcast it's status. (That is why it cannot be a controller in a scene.) This means that the ISY will believe it is in the state last commanded by the ISY or by an included scene. If you commanded it to be "ON", then the ISY status will believe it to be on, even though it is in latching mode. My recommendation, do not worry about relay status. It has no meaning. This makes me think you skipped my step C. Put the keypad into "non-toggle on" mode. Direct commands are when you choose the device (not scene) in the admin panel and send a command (on or off). If you were to do this, the latching mode apparently would not work and you run the risk of damage to your garage door opener. Instead, choose the scene in which the keypad button is controller and relay is responder. Send on/off commands via that scene. From mobilinc, use the scene, not the relay device, itelf, to which to issue commands. By the way, if you want to know the status of your door, observe the status of the SENSOR. The relay has no relationship to the door being open or closed. You are correct. The garage door is a good example of how scenes and controllers and responders work. One cannot skip one step, because they are all interrelated. However, once you begin to understand HOW and WHY things work, it gets to be much easier.

Not necessarily. "ON" generally means 100%. Compare "ON" to "NOT OFF". Compare that still to other options, such as "NOT ON" and "OFF". In general, "NOT OFF" means anything over zero. "NOT ON" means anything under 100 percent. "OFF" means zero. "ON" means full on, or 100%. You understand correctly. A switch (or other insteon device) will trigger a program only when activated directly. When changing in response to a linked device (controller), an insteon device will NOT trigger a program. Despite this, I believe that if you look at the status of the linked (2nd floor switch, in your case), you WILL see an accurate status. Still, I am uncertain if this rule is true only for "control" and may not apply to "status" (as suggested by Xathros). Perhaps a program would trigger if based on "status", even if the affected device changed status based on being a responder in a scene. This should be easily verified by a couple of experiments.

That program looks a little strange to me. Your condition will be both "true" and "false" simultaneously, every time. While, logically, I am not sure that this explains why it does not work, it seems like a real possibility to me. Try: if status shop heat is on then send "on" notification else send "off" notification If the notifications are the same, then use the same notification in both paths. Understand that this program will trigger when the status changes, whether to ON or OFF. The path taken will be based on "ON" (then) or "OFF" (else).

Regarding all insteon device quick start guides and user manuals...these instructions assume NO ISY PRESENT. Once you introduce the ISY device into your insteon system, you should base your programming steps from the ISY user manual and universal devices wiki. The manuals are useful to help undertand how to put individual devices into linking modes, how to factory reset them, etc. However, all scenes should be created via the ISY. By the way, I found the manual for the IOLinc Garage Kit to be confusing and, possibly, incorrect. Regarding the wiki, there is a very nice explanation on how to setup a garage door IOLinc with a keypad button. Go to the wiki, search for garage, and it shows up in the search results. I also suggest searching the forum. The garage door scenerio is oft-discussed. Answers to most of your questions are addressed in some very recent threads. When LeeG speaks of "direct" commands, I believe he is talking about commands from the ISY admin panel, where one can choose the device (relay, in this case) and turn it on or off. Scene commands would be where another insteon device or ISY scene is used to control the relay. Like LeeG states, there is no single correct answer. The mode you want to use depends on the device you intend for control of your door (do you want to use a switch with ON for open and OFF for closed? Single keypad button? Separate keyad buttons for open/close). The correct mode can depend on whether you want to monitor status via the keypad button. The correct mode can depend on where you have your sensor mounted (is the sensor closed when the door is open or vice versa) as well as whether you are using a NO or NC sensor. I like using a single keypad button to actuate the door, either to open or close it. I like to use the same KPL to indicate status. I also place higher importance on knowing the door is FULLY closed, rather than knowing the door is open. I like CLOSED to be indicated by the keypad button being OFF with ON for open. For these reasons, I have chosen: a) mount the sensor such that it is engaged only when the door is fully closed. use the correct sensor wires (I believe this is the normally closed wire) such that when the door is fully closed, the IOLinc sensor is OFF (I like OFF to indicate closed). c) configure the keypad button so that it is in "non-toggle on" mode d) configure the IOLinc relay to be in momentary mode, responding to ON commands (can also respond to both ON/OFF, but not to OFF only). e) create an ISY scene with the keypad as controller and relay as responder f) create an ISY scene with the sensor as controller and keypad button as responder If you have already created links with the device outside the ISY, I suggest starting fresh with a factory reset of the IOLinc. Create all the scenes via the ISY. Configure the keypad and IOLinc via the ISY. This is NOT a trivial excercise. I believe that it is important to understand the concepts behind how and why these things work. Once you understand the concepts, you can mix and match devices to suit your needs and interests.

You can find the wiki by going to a search engine and searching for "universal devices wiki". It is here: http://wiki.universal-devices.com/index ... =Main_Page Within the wiki, if one searches for "garage", a good set of instructions shows up. They are here: http://wiki.universal-devices.com/index ... e_Door_Kit While I suspect hardware and software has been updated and may not be an exact match to these instructions, the concepts are still accurate and clear enough to get you started. Be aware that older garage kits included a version of the sensor having wires for both "normally open" and "normally closed" states. I understand newer kits include a different sensor. Once you have an ISY, it is best to link all devices via the ISY admin console using scenes. Do not manually link devices via quick start guides.

Typically, it is as you suspected. Sometimes folks add waits to give things time to react. My experience is that this is only helpful with X-10 commands. I do not use waits between insteon commands. I would definitely NOT use a wait statement to start. if yours works without wait statements, then I would not worry about it.

In case it is not clear, also be sure that the motion sensor is not also part of the scene being controlled by the program.

The most thorough way would be to remove the Keypadlinc and motion sensor from the ISY, then perform factory resets on both, then add them back to the ISY. From the ISY admin panel, neither are showing up as part of scenes? If not, then it may be enough simply to "restore device". Right-click on each, and choose the option. For the motion sensor, you may have to put it into linking mode.

According to the wiki, choosing a "random" wait will vary the time between zero and the specified time. I am unsure if it is multiples of seconds, minutes, or something else. Try it and see how it works with a longer period.