oberkc

Or, simply, create a program with no conditions or actions. Tasker would simply run the program THEN path as an entry task and run the ELSE path as an exit task, and you can use program status (TRUE or FALSE) as a program or folder condition. No variables required.

I don't fully exploit insteon ability to define different responses to different controllers. Most of my scenes are defined in such a way that, regardless of controller, the responses are the same. For people like me, an option to apply response levels to all controllers in one or two steps might be useful. However, I would not like it to impinge upon the ability to define different levels for each controller of a scene. That is not a trade I would support. In the end, I don't care about a little bit of work up front. I don't find it too much bother to create large programs because the interface to add program lines works well, in my mind. My perception, also, is that a lot of people have pinned a lot of hope on this version known as 5.X. I am afraid it is going to suffer the problems associated with high expectations....it is very difficult to live up to lofty goals.

Yes. You have two controllers. Each controller has two responders (itself and the other switch). Each responder has two parameters (ramp rate and level). 2x2x2=8.

IOLinc is not dual-band, so it will not respond, at all. The fact that some blink green is good and, I believe, sufficient confirmation that you have communication across legs of your electrical system.

Yes. I have a couple of fluorescent lights controlled by a switchlinc. For the past two years, this has worked flawlessly. Now...not so much. Things happen. Devices age. Electrical gadgets are added to your house. I am with the others. I suspect your communications is marginal. My suggestion, like the others, is to start with the basics. Do you have communication across the legs of your electrical system? Do you have your PLM plugged into an outlet and circuit that is relatively free of signal-disruptive devices? Is your garage door opener causing the problem?

No decoder ring that I remember. One can often figure out some things by inference, and I understand that smarthome publishes a developer guide, but that disclosure of that content may obligate the discloser to shoot you. Personally, I think I recognize insteon device addresses, in that they appear to be six-character hex addresses. I have also come to learn that "hops left=0" to be generally bad and "hops left=2" to be, generally, good. You might try a "scene" test, using any scene that is giving you trouble. As a whole, you are probably going to have to fall back on they typical troubleshooting methods to identify any problem-causing devices.

If a dimmer is powering the lights, and the dimmer LED indicator is moving to ON, and the attached light does not turn on, then I restate my best guesses from post #4.

Failure of the IOLinc is not my first guess. I would try a few simple troubleshooting steps first. Is the IOLinc plugged into the same outlet or circuit as the opener? Does unplugging the opener solve the problems? What is plugged into the same outlet and circuit as the PLM? Does moving it to another circuit solve the problems?

"Why would that cause a loop? I ask because the basement main control is part of the basement scene but works. " Xathros' response, above, is the same as I would suggest. It is one of those logic priorities, similar to the mathmatical "distributive" property we all learned in the fifth grade, but forgot by the sixth. Logical AND trumps logical OR.

Perhaps, also, I missed this....which device actually powers the room lighting? Is it one of the two dimmers, or is there a third device in the mix somewhere?

If the LED indicators on a switch move, but the light does not come on, I would tend to consider three possibilities: - loose wiring connection somewhere - failed bulb - failed switch I would be checking voltages at red wire on switch to see if present. If not, switch is possibly failed. (Sometimes a factory reset can "fix" a failed switch.) If the voltage is present, I would consider the other two possibilities.

I expect (made no attempt to locate a user manual) this to be a simple on/off switch. If so, I do not expect that you could use it as part of a three-way installation. I don't know how official you need, but that is as "official" as I can be. How many wires does it have coming from the switch, and what color are they?

Does scene 'Scene: Mbath Off' include any of these devices : 'Main House / Master Bath / Main: MBath Toilet Light' 'Main House / Master Bath / Main: Mbath Shower' 'Main House / Master Bath / Main: MBath Keypad' If so, your second program may be retriggering your first, which re-fires your second, which retriggers the first, etc..... You may have created another infinite loop here.

A quick lookup on 2470D switchlinc suggests that this is a "non-communicating" switch. I have no idea what benefit such a switch would have over any other dimmer switch, but I assume it is NOT insteon or X-10 capable.

"If I come home while the program is in the wait state and push the KPL button, turning the away variable back to a zero, the program seems to stop and never turns the light back on" I am a little confused. If the program is in a WAIT state, is not the light already on? Why would you expect the program to turn it "back on"? I would describe things a little different than LeeG. I undedstand programs can, in fact, run when in a disabled folder. They will not, however, self-initiate from their own conditions. They would run only if called externally, such as from another program. I am not confident with this, but I expect that a program, once running, would continue to run even after a parent folder becomes disabled. If I wanted to be certain, I would set up a simple experiment, with a temporary program that includes a wait statement and disable the folder while the program is executing. I would watch program status at the point the folder is disabled and observe whether the program continues to run. Is it possible, in your case, that the program has a condition based upon the away button or variable?

Absolutely. The responder levels will be based upon the "scene" parameters.

I would first confirm which of your nodes is changing when the drum is rotated. Once determined, I would follow the programming suggestions of LeeG. With the ISY, one can test for "status" and/or "control" for any given device.

I which case, you might not be getting signals from both nodes and one node moght be stopping at OFF. Best bet from here is to identify which nodes are changing status as the drum rotates.

My inclination would be to configure the buttons as non-toggle (off) and trigger a program from the button OFF command to turn on the scene.

My first inclination to wonder whether the use of of a sensor triggered on each drum rotation is a practical solution. I wonder if flooding the powerlines with insteon commands more than once per second will have unintended consequences, or whether it will even work reliably. Second, I am a little unclear how your sensor works. Does it have both an OPEN and CLOSED node? (Is it one of those wireless door sensors?) Does each node change status once per drum rotation? Is it possible that the status of your sensors are not updating fast enough that the ISY believes both sensors are OFF at the same time? I dont see anything wrong with the program that would cause intermittent problems. Have you ever watched the device status, program status, or the event viewer while the dryer is in operation?

Based on my experience, non toggle buttons will all blink a few times then settle into final status.

Yes, it seems that the definition of "scene" varies based on controller. With the ISY, create a single "scene" adding all keypad buttons that you want to trigger the scene as controllers. If there are other devices that actually power the load, but are not to be used as scene controllers, add them to thesceneas a responder. Each controller in this scene can be configured to drive different responses by the other devices in the scene. Click on each controller and adjust reponder ON levels and ramp rates for each reponder.

The only time this set of conditions will trigger AND evaluate as true would be when the button D changes to ON for any reason except (possibly) when it changes to ON as a result of FASTON action directly from the keypad button, itself.

This is consistent with my understanding. Secondary (non load controlling) buttons are either ON or OFF. They can send dim and bright commands as scene controllers, but, themselves, are either on or off.

I would take a simpler approach. One scene, including only the keypad button. One program: If From 8am to 4pm Or from 11pm to 7am (next day) Then Set keypad button scene on Else Set keypad button scene off I would then use the status of the keypad button as the indicator whether your system is armed. I would use that as a folder condition: If Status keypad button is not off Then allow programs in this folder to run In the folder, I would put any program I want to trigger, but only when the system is armed.