oberkc

Perhaps there is a list somewhere. Until then , I think you are safe assuming compatibility. If not, history suggests it soon will be.

I have never concerned myself with such a list. If I find an insteon device in which I am interested, I buy it. Never have I found one not compatible with the ISY.

This response leads me to believe that you are still unclear about what people are suggesting and the purpose of the suggested program actions. Nobody is suggesting a program that turns lights ON or OFF at specified times. What people ARE suggesting is to modify scene responder levels at specified times. Re-review suggested program in post 12, and again in post 18. Note actions such as : In scene 'device A' set responder on level 30% Such commands do NOT turn any lights on. Rather, it is an action to reset responder levels for devices within a scene, should the scene be turned on at a later time. This redefines how the scene responder devices responds to scene controller commands. Regarding switches, you have only three, correct? Are all three connected to a load (switch red wire connected to something)? You should have a single scene, with all three switches defined as CONTROLLER. Please confirm.

There is a finer point that LeeG is making that I would like to emphasis. In addition to clicking on the scene name (whether it be low, medium, high, whatever), you must also click on the corresponding two ON buttons (C, D, E, or F) within that scene. Each of those will show a corresponding set of responder devices, as well. Make sure that these responder levels are also correct. For example, when you select button C, you will see a responder button C, two each responder buttons D, E, and F, and the motor. Make sure the C button is set to 100%. I suspect you will find it is not.

When I hear your description of programs as "flakey", my mind instantly runs to communication around the PLM. With programs, perhaps unlike with scenes, there is reliance on a communication with a single device...the PLM. Because of the importance of this single device, it is paramount to ensure it is on a good, clean, circuit. Unfortunately, most of us, I suspect, find the most convenient location for the PLM to be near some of the noisiest and interfering equipment we have in our house...other computer equipment. Do take the time and effort to make sure your PLM is on a good circuit, or filter all that computer stuff. Better yet, do both.

I have had a few failures over seven years of using insteon. Only two were random, that I recall...one PLM failure, and my single "icon" device (no longer available). The other failures were arguably induced. I view insteon devices as not very robust, rather than having a limited life. Dont load them at max capacity. Dont change a light bulb while energized. Dont allow your house to be subject to power surges and spikes. If you have a stable environment, however, they can last a while.

To me, if I have to start making trades, the least painful would be to accept the small delay associated with programs and remove the motion sensor as direct controller of the scene. I dont find an extra second or so delayed response to be that big of a problem. If one must have the MS be scene controller, the options do, indeed become more limited.

Like bluesman2, I am a fan of LED, for a variety of reasons, including a simplification of the wiring. I have four zones, each powered by a 50w power supply. Each of those is controlled via appliancelinc. I cannot help with dimming.

I am with stusveiws on this...a few more details may be useful. Staying very general, however, this could be done with a program: If Control "switch" is turned on Then Do something Wait a little bit Do something else Wait a little bit more Do something else Etc.... If you need to initiate via a phone, one option would be to access via mobilinc app and run this program (then path).

Given your description of your wiring, supply is almost certainly introduced at the fixture box. Google is your friend when trying to understand different wiring approaches for three-way circuits.

True, there could be a global use for "daylight hours", but (being the fan of simplicity that I am) there is no need for variables in some cases: If Time is from sunrise To sunset Then Nothing Else Nothing This program will be either true or false, based on time of day, and could be used as a program conditon as well (no variable needed). If, however, one wanted a program condition that was not a program trigger, then the variable has an advantage, yes.

You would need to repurpose existing conductors by changing connections in the fixture box. If each switch location has only a single 3-conductor cable, then it is a near certainty that both cables terminate at the fixture box. If so, you will not need a micro module at all. At the fixture box, identify supply hot and neutral. From the 2 cables from the switch boxes, you would connect white to supply neutral and black to supply hot. This would give you hot and neutral at both switch locations. Using one of the new insteon switches, connect red wire to the red conductor in the cable. At the fixture, connect the other end of that red conductor to fixture hot. Cap unused red wires and conductors

A normal switch, insteon or zwave, will not work here without the micro module. There is no neutral in this box. (White is not neutral here...do you see any black tape or paint on this white wire?) Yes, this would be where the two wire switch would be appropriate, assuming compatible with the load. Halogen is, by the way, a type of incandescent and should be compatible with the two wire switch.

I am equally upsdt that I did not think of this approach.I would have taken your approach, except for the variables (use program status instead...variables seem unnecessary for this application). As one who sees elegance in simplicity, my admiration goes out to apostolakisl.

For example OTL = Outletlinc KPL = Keypadlinc IOL = IOLinc Etc....nothing special here, in my mind. I just like three character codes, I guess. I probably like xathros' codes better than mine

I use a convention DDD RRR NAME, where DDD is three-character device code, RRR is three-character room code, and NAME description narrative. I am not sure that this is a perfect solution, but it is the way I started it (before there were room folders, I believe) and I am too lazy to change it. My biggest (only) hangup is the one identified by416to305...using mobilinc and tasker, any widget I create on the homescreen shows the first few characters of the name from ISY. This is not especially useful for this purpose to have a widget with a name of OTL FRM north (rest truncated).

Rudy, I suspect you will be more satisfied with your system if you avoid your two programs (with the SET SCENE and FAST ON actions) and use ADJUST SCENE actions in a 9-6 program, as suggested by LeeG. Given your two posted programs, I continue to believe there to be some confusion on scenes and responder levels. One of the main characteristics of insteon is that responder levels for a given device can be different based on to which controller it is responding. A less obvious factor here is that the PLM is, technically, a controller device for all your scenes. For example, in your scene "main hallway upstairs", switch "main hallway upstairs master" is responder to three devices: main hallway upstairs 1, main hallway upstairs 2, and the PLM. When you created the 30% scene, you likely created a scene where the three switches were set to 30% on level when responding to the PLM...the scene level responder level. (In that scene, if you mouse-click on the individual devices, I susect you will find the on levels for the three devices to be something other than 30%.) I suggest re-reading LeeGs latest suggestion in detail. That single program will accomplish your goals and I expect you will find your system to be much more responsive, reliable, and robust.

I am confused. The manual states that applying more than 5v across the sense input can damage the sensor. I thought the sensor was more to detect contact closures rather than presence of voltage. Am I misunderstanding something here?

I misunderstood your request, then. You could further modify your program to look for kpl OFF commands and turn the light off manually.

You want them to turn OFF in response to an ON command from the switch? Adding the suggested condition would simply retrigger the timer.

I would activate the motion sensor and see if you get a command to the ISY. The event viewer will show all commands recieved by the ISY.

I think the best option is to replace the garage door sensor. Early versions had both NORMALLY OPEN as well as NORMALLY CLOSED configurations, where one could wire the sensor as needed. Mine, for example, is OFF when closed, like your hidden door sensors. This is the way I prefer. I believe the older "3-wire" sensor is still available.

ADd To Program: Schedule Schedule: choose "from" in the window which shows "time"

I know of no easy way to troubleshoot communication issues. Unless you have one of the classic problems (failure to couple phases, lots of stuff plugged into same circuit as plm), there is not much I can offer that doesnt take time. Only you can judge whether the amount of time is unreasonable.

Yes, it can act also as a time range. If there are other program conditions, the from/to will still be considered TRUE. A program will be triggered by its conditions. From/to conditions are triggered twice only. Status conditions are triggered at any CHANGE in status. Once triggered, however, ALL conditions are evaluated, and the from/to condition will always be evaluated as TRUE between the specified times.