oberkc

Perhaps you don't need to add them all to the program, but can identify a few key devices (the canaries in the mines) that, if the scene is on, then one of these would certainly be on?

good call

Option 1 will not do as you want, I don't believe. If all three switchlincs are controller of the KPL button, then turning one off will turn off the KPL button, even if the other two are still on. Option 2 is the way I would do it.

Phikapjames, Your approach is exactly the same as mine. I expect it to work. Erick and stusviews concerns are he same as mine, so to expand a little... When you have your four individual lights "on", I suggest checking each in the admin panel to see what ISY thinks the status is. If the ISY shows that a device that is physically on to be off, then I would suspect comm problems. If the ISY shows a device that is physically on to be on, but at something less than 100%, then stusviews nailed it. Regardless, if any of your four devices are dimmers, I second the suggestion using "not off" as a better condition.

I, too, have access points (or range extenders) in the four corners of my house. Based on my experience, I would not be overly concerned with elevation. I find that my rf coverage is sufficient on all three levels with the access points being only on a single level. This may be less true if you are relying not on range extenders, but rather devices in boxes or lamplincs or whatever. I would wait for signs of trouble before pre-emptively deploying devices in the basement solely for the purpose of providing rf coverage.

Yes, clearly there is an attempt to develop tools to aid in diagnostics. But, in the end, knowing what phase one device is on relative another, knowing that a message has arrived, or knowing whether an acknowledgement has been received is not much new. I can already perform phase testing using access points. If a message has been received by a device, I can tell by observing the response. Many of my older devices already blink when there is a failure to receive acknowledgement. Still, my bigger problem remains...how do I react to this knowledge. I am having trouble envisioning how this helps me identify the CAUSE of these problems. Perhaps I am missing something. Part of the problem in my case may be that I have already been through the troubleshooting pain and now have a mature and reliable system. I do not much keep up with the additional capabilities of the newer devices. I certainly dont read the manuals for every iteration of every new device. If I want a new device here and there, I simply buy it, add it to my system using the methods I have already learned, and it works. Given this, I admit there may be more value here than I am able to recognize.

My impression of the smarthome tool is that it will simply confirm that which is obvious from observation...that some devices are not communicating well, or at all. The ability to identify the source of the difficulty remains up to trial-and-error processes.

"I have the relay set as Momentary A - triggered by either on or off. I have a program that watches the relay turning on and turns it off a few seconds later. I don't think this will cause a second relay hit...right?" There may be a couple issues with this logic. First, the relay does not broadcast its status. There is no way for the ISY to be notified of the relay status. Second, if you are sending commands directly to the relay, outside of a scene, then I dont believe momentary mode matters. If you tell the relay directly to turn on, it will do so, and stay on until you tell it differently. 8nly if the relay is responding to a scene command will the momentary mode be in force. Perhaps part of your reliability problems are the result of program issues? If you post all relevant programs (actual programs - best to avoid approximations in this case), I am sure somebody would be happy to take a look and advise.

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.