oberkc

Everything I understand about the ISY tells me that this program should include a thirty minute delay before sending out a notification. Is it possible you have other programs in play here?

If this were me, I would be working to solve the reliability issue. Still, it is impossible to guarantee 100% reliability with any system. It is possible that one source of error is that the ISY is not receiving the notification that the door is open. If so, no amount of programming, short of scheduled and frequent queries, will help. If you are trying to maximize confidence that the door closes once the ISY becomes aware that it is opened, you might consider a notification when the door is opened, a notification that the door was closed, and a notification if the ISY cannot confirm that the door is closed when it should be.

Based upon your program, I assume you intend to constrain operation of the motion sensor relative to sunrise and sunset. This cannot be done through scenes and the inherent characteristics of the motion sensor. If this constraint is important to you, you MUST use a program. If you are willing to give this up for the sake of responsiveness (but losing some flexibility), then scenes can be an option and, as others have pointed out, programs can become unnecessary. "One follow up question - Is it necessary to have both the responder (Lamplinc in this case) and the sensor in the scene?" If you are referring to your "office lamp" scene, then, no. You should NOT add the motion sensor to this scene.

Some have reported comm problems from garage door openers. My perception is that it is relatively rare, but worth checking into. Does the problem go away if you unplug it?

I see one program referenced ("frontllightsmanual") that is not posted here. Are there others? Within the programs posted, I see NOTHING that would cause any lights to turn ON. I see that your second program will turn OFF family room and yard lights. Perhaps this is why you are seeing lights turning OFF but not ON?

Yes. Every ON command received will trigger a program evaluation. At that point, it will run either true or false. Any ongoing program execution will be halted. Understand, too, that time is also a program trigger...once at the beginning time, and once at the end. When triggered by the end time, or by the motion sensor past the end time, any running program will halt and the ELSE path will run. This means that the scene will not be turned off.

The ISY, to my knowledge, remains without this native capability. One of the crazy-good members has written a program using variables to keep track of such things. I understand it is on the wiki.

"There are NO Scenes with any of the Insteon devise here. Each MS are "controllers" to both light switches." I don't understand these two statements. In my mind both cannot be true. If there are no scenes, then a motion sensor cannot be controller. On the other hand, if the motion sensor is a controller, then it is part of a scene. Double check this. If motion sensors are controllers of those devices, and if the motion sensor is configured to send both ON and OFF commands, then those devices willturn on and off regardless of your programs. Check both sensors that they match your posted settings. As an aside, I see nothing in your programs that turns anything off after any pre-defined time period. Are there additional relevant programs not posted?

I have not checked the newest versions, but all mine have the ability to configure backlighting. I would first check on the admin panel. Choose the device in question. Along the bottom of the main window should be options or settings or something. In there I expect to find backlight level settings. Adjust those to your liking. If not, check the keypad user manual for method to make those adjustments.

Does snapswitch allows one to run specific program paths? Could one, for example, create a simple program such as: If Nothing Then Turn on lamp module Wait 30 minutes Turn off lamp module Else Nothing Then, from snap switch, run the THEN path of this program?

Unfortunately, I am not familiar with snapswitch. Does this simply turn on the lamp module directly, just as with using the admin panel? This lamp module is the same for both evening and morning programs? This will certainly add a few extra considerations. The brute force method would be to bound the evening program to specific times most likely to be good night times such as If time is from 6pm To 12am (next day) And status dimmer module is ON then run time program (then path) Else Nothing Timer program: If Nothing Then Wait 30 minutes Set dimmer module off Else Nothing The morning program would be unchanged from my earlier suggestion. There are probably other options if this does not meet your needs for some reason.

Sometimes one can get lucky with devices other than incandescent. Even if it "works", however, you may be running the risk of long-term damage to load, switch, or both. Personally, I would probably NOT leave them this way given the flickering and evidence of operation other than proper.

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