oberkc

Like techman, my first reaction to most intermittent problems, including this one, tends to be to look at comm problems. Regarding you specifion question re status vs control, there are a couple of factors come into play here that could favor one approach versus the other. The basic difference is that CONTROL is ON will trigger on receipt of every ON command, regardless of current state of the device. STATUS will not. So...if your motion sensor is currently ON (and past The timeout period) and senses motion again, it will send another ON command. If using CONTROL as a condition, the program would trigger upon receipt of the ON command. If using STATUS as a condition, it will not trigger, since there was no CHANGE in status, since the sensor was alreay ON. Personally, I use an ISY program (not scenes) to control response to motion sensors. I like to reset my countdown timer at each ON command. This tends to suggest CONTROL as preferable to STATUS as a program condition.

My experienc is that slower write times are indicative of marginal communications

I believe the ISY will add the preceding $ to the variable name. I would put initial value as 0. This is the value that will be assigned if the ISY reboots for whatever reason (such as power interruption). I assume you are home more than away, so this seems like the natural starting point. There is a way to go through a power interruption and keep your variable, but I suggest getting this working first without worrying about such things, then we can talk about thenext steps. First program should be outside the folder.

I am away right now, so I cannot confirm on my admin panel. Have you created the variable yet. Is it a state variable? If your intention is to continue using the folder to enable or disable your two programs, I believe all you would do would be create a condition, based on the variable being = 1. The exact syntax will take care of itself, from the selection boxes available. Then you would simply create a whole new program: If Status hall keypad is not off <<<<must use STATUS here Then Wait hh.mm.ss <<<<pick your time Set variable =1 <<<enables folder Else Set variable =0 <<<or anything other than 1 If you are taking the folder approach, there is no need to include the variable in your two programs within the folder.

I don't recall that there is the option for a program to disable a folder, but there IS an option to disable programs. The way I see it, you have, thus, two choices. Create a variable (I will call it "$away"). Then create a program: If Status 'Hall Keypad-Hallway / Hall Keypad-Away' is not off Then wait 10 minutes "$away" = 1 else $away = 0 Modify your folder condition If Status '$away' = 1 Then run programs in this folder The second option would eliminate the variable and folder. So, get rid of the folder and keep the existing two programs out in the open. Then, create this program: If Status 'Hall Keypad-Hallway / Hall Keypad-Away' is not off Then wait 10 minutes disable motion alert program disable other program else enable motion alert program enable other program Pick one of these options that looks good to you.

For what it is worth, my latest router is from netgear. It comes with a complimentary static ip service mynetgear.com. So far, so good.

I took referenced "switch" to be in regards to the device that goes in the bathroom and actually powers the load. Which makes me think...if the actual wiring is as I suspect, with three conductors between the bath and kitchen location, there would be no reason not to put a relay keypad in the kitchen location and use that device to power the load. Then one could put the dimmer switchlinc in the bath and link it to the keypad via scene. The downside may be that the primary button in the kitchen would need be used for the fan.

Others have mentioned the four-button configuration, but relating this to high WAF may have been the slap to my head that this may be a solution to a WAF problem I have been having. Thanks.

Taking advantage of scenes, spare buttons, and an xacto knife, a seven-button keypad is quite possible.

Yes, you could put KPLs in both locations if your wiring is per the illustration. The lack of black tape is NOT conclusive evidence that hits is neutral. Most likely, they simply failed to add the tape. White, in this case, is NOT neutral. Basically, you would connect white from the power source to all whites. Connect black from the power source to the black going to the second switch. Red wire abandoned. At both boxes connect switch white to other white wires. Connect left switch red to black wire connected to load. Connect switch blacks to supply black.

My admin panel gives me the option to choose the following as a program control condition: on, off, fast on, fast off, fade up, fade down, fade stop, bright, dim. Does yours not show these options, or am I missing something?

Perhaps you are correct. My knowledge (and interest) is limited to knowing that more hops remaining is better than fewer hops remaining. Having said this, if the initial command was sent, and the device responded with no repeats necessary, would this not constitute zero "hops"?

Is there a wall button? Is it the simple door-bell type button? Is that still working well? Have you checked the wires to ensure they are still tight? Have you tried adjusting the relay time-out? Teken may know something that I don't, but the communication looks good to me (three hops remaining).

I cannot say that I have noticed this action being available in a program.

The switches were referred to as "another" switch (the one on who's status the response by the lamp module would be based) and a "dimmable wall switch" (the device that would trigger a response by the lamp module). I tried to keep similar nomenclature, but my understand was that the "another" switch and "wall" switch were two different devices. The am unsure if the "other" switch is a dimmer. If so, the point about the status being "on", but something other than 100% is correct. I should have consistently used "status of other switch is not off" rather than "status of other device is on", just in case the other switch is a dimmer.

To the program above, you could create additional programs: if status of other switch is on and control wall switch is dim then dim lamp module if status of other swithc is on and control wall switch is brighten then brighten lamp module For me, this is only theoretical. While I am confident it will give you some ability to brighten and dim, I am unsure how smooth this will all work, or what happens if you hold the switch for extended periods. You may have to experiment around some. An alternative would be to add the lamp module as responder to a scene with wall switch as controller. Based on status of the other switch, you could create a program to adjust responder ON levels to your desired level when the other switch status is ON, and to zero when the other switch status is off. The down side to this approach is that when the other switch is OFF, and you toggle the wall switch, the lamp module will go to zero always, even if originally ON. I could see where this might be disruptive in some cases. It is up to you if you can live with this limitation.

Stusviews is certainly the clean approach. Short of that... The light connected to the switch cannot be disabled by program, scene, or any other method. It will come on when the switch comes on. Fortunately, this is consistent with your wishes. You do NOT want to create a scene (link) between the switch and lamp module. A scene cannot be disabled. The best you can do would be a program. The program (possibly programs) could be something as simple as: if status other switch is not off and control dimmable wall switch is turned on and control dimmable wall switch is not turned off then turn on lamp module else turn off lam module A program like this would simply turn the lamp module ON or OFF based upon commands from the wall switch. If you want dimming control, your progams will be a bit more complicated, but not too much.

Once a device is a responder in a scene, there is little than can be done programmatically other than to set responder levels (ON and ramp rates). To make a response to a device conditional the the status of another device would likely be done by a program alone. I agree, a few more details would be helpful.

keypad buttons can be used to dim and brighten, yes, so long that the device powering the load is so capable.

At the fan box, add a "fanlinc". At the north light box, add a "micro module". Keep the two lamps plugged into a single lamplinc, or plug each into their own lamplinc (does not matter). Replace single wall switch with 8-button keypad. Configure four buttons for fan speeds (off, low, medium, high). One button for the two lamps. One button for the north light. This leaves two spare buttons for growth or other creative use.

There is, indeed, a little toggle button among that top row of icons, one for most devices, and another for battery devices. If they are green, then the ISY will immediately create all links. If they are gray, then the ISY will wait until you click on these to write updates to devices. As an aside, creating a program will create no new links. All links are created via scenes.

Reminder, if you put them all into the scene, with devices 1-4 set to desired ON level, and 5-12 set to an ON level of zero, then not only will selected lights come on, but other lights will turn off. If they are already off, then no harm. If some were on, well....only you can determine if you can live with this.

Yes, if you put ALL devices in the scene, with zero ON levels for the devices beyond the primary 3 or 4, this would simplify the programming. You will still need a program to turn ON the keypad button if any of the dozen are on if status device 1 is on or status device 2 is on .... or status device 12 is on then set keypadbuttonscene on else nothing the keypadbuttonscene is a scene with a single responder device...the keypadbutton. Unfortunately, these buttons respond only to scene commands, so this is a necessary step to control them from an ISY program.

I would probably tackle this with a combination of programs and scenes. A program is definitely required. The approach may depend on what you want to happen to those lights beyond the 3-4 when you toggle ON the button...turn OFF? Stay at current level?

That has been discussed from time to time. There is, I understand, no native insteon definition of a scene being "on". Beyond that, how does one define a scene being on? When every device in the scene is NOT OFF? Every device exactly matching the ON level when PLM is controller? It gets messy pretty quick.