oberkc

Perhaps you are correct. My knowledge (and interest) is limited to knowing that more hops remaining is better than fewer hops remaining. Having said this, if the initial command was sent, and the device responded with no repeats necessary, would this not constitute zero "hops"?

Is there a wall button? Is it the simple door-bell type button? Is that still working well? Have you checked the wires to ensure they are still tight? Have you tried adjusting the relay time-out? Teken may know something that I don't, but the communication looks good to me (three hops remaining).

I cannot say that I have noticed this action being available in a program.

The switches were referred to as "another" switch (the one on who's status the response by the lamp module would be based) and a "dimmable wall switch" (the device that would trigger a response by the lamp module). I tried to keep similar nomenclature, but my understand was that the "another" switch and "wall" switch were two different devices. The am unsure if the "other" switch is a dimmer. If so, the point about the status being "on", but something other than 100% is correct. I should have consistently used "status of other switch is not off" rather than "status of other device is on", just in case the other switch is a dimmer.

To the program above, you could create additional programs: if status of other switch is on and control wall switch is dim then dim lamp module if status of other swithc is on and control wall switch is brighten then brighten lamp module For me, this is only theoretical. While I am confident it will give you some ability to brighten and dim, I am unsure how smooth this will all work, or what happens if you hold the switch for extended periods. You may have to experiment around some. An alternative would be to add the lamp module as responder to a scene with wall switch as controller. Based on status of the other switch, you could create a program to adjust responder ON levels to your desired level when the other switch status is ON, and to zero when the other switch status is off. The down side to this approach is that when the other switch is OFF, and you toggle the wall switch, the lamp module will go to zero always, even if originally ON. I could see where this might be disruptive in some cases. It is up to you if you can live with this limitation.

Stusviews is certainly the clean approach. Short of that... The light connected to the switch cannot be disabled by program, scene, or any other method. It will come on when the switch comes on. Fortunately, this is consistent with your wishes. You do NOT want to create a scene (link) between the switch and lamp module. A scene cannot be disabled. The best you can do would be a program. The program (possibly programs) could be something as simple as: if status other switch is not off and control dimmable wall switch is turned on and control dimmable wall switch is not turned off then turn on lamp module else turn off lam module A program like this would simply turn the lamp module ON or OFF based upon commands from the wall switch. If you want dimming control, your progams will be a bit more complicated, but not too much.

Once a device is a responder in a scene, there is little than can be done programmatically other than to set responder levels (ON and ramp rates). To make a response to a device conditional the the status of another device would likely be done by a program alone. I agree, a few more details would be helpful.

keypad buttons can be used to dim and brighten, yes, so long that the device powering the load is so capable.

At the fan box, add a "fanlinc". At the north light box, add a "micro module". Keep the two lamps plugged into a single lamplinc, or plug each into their own lamplinc (does not matter). Replace single wall switch with 8-button keypad. Configure four buttons for fan speeds (off, low, medium, high). One button for the two lamps. One button for the north light. This leaves two spare buttons for growth or other creative use.

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.