oberkc

I have only a single v.41 switch, but it is a relay. The two switches I tested (both v.38) behaved just as did MikeD. When off, pressing the on button brings it up to preset levels. This happens always, regardless of recent paddle presses fast on or not.

Yes, the KPL button should come on and off with the motion sensor.

Based on memory, mine is the same as LeeG. At step four, mine would go to defined level, not full on. I will confirm when I get home, as well as check to see if I have any v.41 devices.

This is not something I routinely do with my system, however, my recollection is that if I press ON once, it goes to the pre-defined level. If starting at the pre-defined level and I press ON again (regardless of wait time) it goes to full bright. If starting at full bright and I press ON again, the device will revert back to the the local ON settings. In effect, repetitive presses of the ON button would toggle between full and the locaol ON level. I don't know why mine would be different than yours, other than some change made by smarthome, or a device defect. Is it possible that you have some program running which would cause this behavior? Do you see any program status who's last run time corresponds to switch input?

I only have a couple of things to observe. One is unrelated. First, the hop cound (hops left = 0) I see in your event viewer suggest (to me at least) that you have something going on that makes communication between devices a little troublesome. Regarding your stated problem, I don't see anything in the program that would cause the observed behavior. I cannot help but wonder about your switchlinc, however. It sounds as if it is reverting to last state, somehow, for "on" levels. I had a couple of X-10 devices that did this. What kind of device is this "switchlinc dimmer"?

. I forget whether ISY programs have the ability to command a device to go to a specified level. If so, one could use that capability. If not (and maybe even if so), I would create a new, additional scene. I will call that scene the "10pm scene". To that scene I would add Outside Front Can Lights and the Front Porch Can Lights. At the scene levels, I would set "ON" levels to be 0 (off) and 50% for each of the two devices, respectively. Modifiy your program (or create a new one) to turn this new scene on at 10pm.

LeeG's advice is probably most productive. Short of that, I would expect a program such as this to work: if from time xx:xx to yy:yy then run other program (then path) wait 1 hour run this program (then path) else other program if then do whatever you want done every hour else

I can only speculate, but I would be inclined to take it with me if needing to sell soon. But...everything is up for negotiation.

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.