oberkc

Normally, I have had good luck with filterlincs. You could always try the standard test, where you get an extension cord an use it to plug the PLM into a different circuit. If that works, it tends to suggest something on the circuit is a problem-causer. Is EVERYTHING on that circuit filtered? Is there anything else on that circuit not on the UPS?

No. Use the serial interface version.

Iamnot following your desires. When you say "I will turn on the night light", how do you intend to do this? Manually, or by time? Is the device you intend to turn on the same one that powers the night light? The morning program seems simple enough. If time is 4:20 Then Turn on night light Wait 2 minutes Turn off night light

Jimbo is, of course, correct. CONTROL conditions respond only to the expected command (on, off). STATUS conditions respond only to changes in state (will not repond to an ON command if state is already on.) This is a key feature, in my mind, of the programming of the ISY. A review of the wiki may be a good thing here, as suggested.

More specifically, one will often see: If CONTROL device is on and CONTROL device is not off then... else... Such constructs can be used when one wants to take one course of action (then path) if ON is received, and a second course of action if an OFF (else path) is received.

Does your program include any waits or repeats?

Yes, for counting (whether time or events) they are wonderful. For simple true/false calculations, I find them overused.

To answer your specific question, the only documentation of which I am aware is the wiki and the user guide. I know of no other formal documentation. As an alternative, I see nothing in your examples that require the use of variables. Personally, I have very limited need for variables. Unless there is a use that I cannot accomplish without them, I find (for me) variables to be an unecessary complication.

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).