oberkc

There is, indeed, a little toggle button among that top row of icons, one for most devices, and another for battery devices. If they are green, then the ISY will immediately create all links. If they are gray, then the ISY will wait until you click on these to write updates to devices. As an aside, creating a program will create no new links. All links are created via scenes.

Reminder, if you put them all into the scene, with devices 1-4 set to desired ON level, and 5-12 set to an ON level of zero, then not only will selected lights come on, but other lights will turn off. If they are already off, then no harm. If some were on, well....only you can determine if you can live with this.

Yes, if you put ALL devices in the scene, with zero ON levels for the devices beyond the primary 3 or 4, this would simplify the programming. You will still need a program to turn ON the keypad button if any of the dozen are on if status device 1 is on or status device 2 is on .... or status device 12 is on then set keypadbuttonscene on else nothing the keypadbuttonscene is a scene with a single responder device...the keypadbutton. Unfortunately, these buttons respond only to scene commands, so this is a necessary step to control them from an ISY program.

I would probably tackle this with a combination of programs and scenes. A program is definitely required. The approach may depend on what you want to happen to those lights beyond the 3-4 when you toggle ON the button...turn OFF? Stay at current level?

That has been discussed from time to time. There is, I understand, no native insteon definition of a scene being "on". Beyond that, how does one define a scene being on? When every device in the scene is NOT OFF? Every device exactly matching the ON level when PLM is controller? It gets messy pretty quick.

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.