oberkc

MustangChris04, The remaining hops count tends to suggest the need to repeat some of the command until acknowledged by the device. As mentioned earlier, these acknowledgements and repeats dont happen with scene commands. I take these indications of less-than-optimum communications. By your post count, I am hoping you have heard the common suggestions about phase coupling and avoiding electronic gadgets on the same circuit as your PLM. If not, start there.

my understanding is that there is no order of program execution when triggered by the same event. All programs would run simultaneously, at least from a practical standpoint. There would be no need for one program to finish before the other starting. If you must force one program to stop before the other start, you could try the hart2hart method, or something like: if event then do something run next program (then path) else nothing next program if nothing then do more run third program (then path) else nothing third program if nothing then do even more run.....

Qkb333, Stusviews is correct that battery device status is often inconsistent or inaccurate. I remain hopeful, however, that it should work beautifully in this case. As I understand it, ISY will assume a status based upon commands received from the mini remote. My biggest concern is the nightly query. Battery devices generally dont listen, so they dont respond to queries. The query may render the status as unknown each night, forcing you to re-enable your program. Watch out for this possibility. Experiment around a bit with this. If I am wrong here, you may need to employ the extra programming steps suggested by stusviews.

Simplest option may be: if status mini remote is on and control door sensor then send notification else nothing

If you are using programs to turn lights on in response to motion, I suggest considering using programs to control the time period waited until lights are turned off. The program can be as simple as If Control sensor is switched on Then Turn lamp on Wait 30 seconds Turn lamp off Else Nothing

Unfortunately, when one asks in a forum, forum posts are the likely reponse. Universal Devices is better than most with involvement in forums, but this is still dominated by users not affiliated with the company. Perhaps they will see this question and respond. Direct communication with them is probably a better option if you pass along the suggestion or seek official documentation. For the record, I agree that there should be such a list, and probably is somewhere in the records of UDI.

I am not sure if garage hawk is considered an insteon device, but it may not be supported either.

BTW, if you are inclined, and it is important enough to you, you could try a forum search. Compatibility with new devices is typically identified in the announcement for new releases. One interesting topic surfaced: http://forum.universal-devices.com/topic/14735-insteon-onoff-outlet-2663-222-review/

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.