oberkc

I am more than "pretty" confident. ISY is for those who want to AUTOMATE things. The hub seems better suited for those who want a fancy remote control.

Yes, current wiring does not include unswitched hot in fixture box. I believe power is introduced into this circuit at one of you switch boxes. Yes, putting the module in the switch box with power should work, but this may not be the "last" switch.

Yes, it is possible. You may, however, have to replace both swit hes with insteon. Was that your intention?

Most houses have only two "legs". My perception from the others around here who have multiple panels is that a coupler on the main panel is sufficient.

I understand. The downside for hard-wired motion sensors can be cost (when adding the micromodule) and effort (wiring). For you, it sounds like the benefit is worth it. Another benefit with hardwired micromodule is that, unlike the battery motion sensor, will contribute to the insteon mesh network, repeating signals transmitted by other devices. Otherwise, the use would be the same...trigger other insteon devices or scenes when motion is sensed. Depending on your controller, you can also add other conditions.

How close is the motion sensor intended location to the existing light switch (switches?) that control the light fixtures? I don't consider the mesh network anything to be "concerned" about...rather, something to be exploited. A dead battery in one sensor would not cause the other sensors to fail, or your lights fail to respond to those other sensors. Failed batteries are pretty obvious and require no chasing, in my experience.

I don't know that the battery lasts a whole year, but I would estimate that it is close (for me, at least). And I ue the cheapest batteries I can find and mine are outside. Connecting a generic motion sensor to a micro module would allow one to trigger other insteon devices (such as a switch controlling a light fixture) when motion is sensed. Whether this is accomplished directly (via insteon linking) or through a controller such as the hub or ISY-994 is up to the individual. Do you currently have any insteon devices? Do you understand the "mesh" network of insteon and that most insteon devices receive and repeat insteon commands? Or, are you starting from ground zero and looking at options?

Your code looks complete and accurate to me

Program status is nothing more than the results when last ran. If a progrm last ran the THEN clause, that program will be TRUE. If it last ran the ELSE clause, that program will show false. FALSE is not an indication that a program is not working. Quite the contrary...a program can be false only if it DID execute.

I believe this will take two programs to properly execute.

Your program looks fine to me. I would expect that, once button D is on, the programs would be enabled and should run at next trigger event. If the ISY is not recognizing the button presses, I would be looking for communication problems. It could also be a link record problem. I don't believe this is a program problem. From your device list, find the button D. Does it show correct status. Go press button D. Does the ISY still show correct status?

No, I would say that is, technically, NOT correct. While there is an option in the programs section that allows one to put programs in a folder, and that one can establish conditions for those folders, such folder conditions do not "RUN" the programs. Rather, those folder conditions "ENABLE" those programs. Once enabled, there must still be an event that triggers the contained programs.

In my experience, the "if...is not" statement is NOT needed for status conditions. Unlike control statements, an status condition will trigger upon any change in state, including from off to on, and from on to OFF. A condition such as If synchrolinc is on ...... Will trigger and evaluate true when changes state to ON, and will trigger and evaluate false when changes state to OFF. Also, unlike control, the cause of the state change is irrelevant. Whether controlled directly or remotely or as part of a scene, ANY change in status will trigger the condition.

I don't believe the program changes suggested are going to solve your problem. (I am not sure they are even necessary...I think your program is fine as is. Yes, it will trigger at two times, but will be false at those two times since no CONTROL statement was received simultaneously.) Next steps, for me, would be to break this into small pieces. I would now determine whether the program is triggering (if not, why not) or, if triggering, why the response is not as expected. If ISY time is correct, I would confirm (from program summary list) that the program ran and runs as expected. When did it last run? Sunrise? Sunset? Some other time? What is the status (TRUE or FALSE)? Toggle the ZW lock. Does the ISY see the command (view device status or watch event viewer)? Is the program responding? If not, you must determine why. Is it possible that your lock does not transmit status changes? If you confirm that the program IS triggering, but the expected response is not there, manually run the program2 (if path). Does this respond as expected? Is it possible that there is a program problem here? Communication problems? Isolating the cause of the problem is the first step towards solving the problem.

My first inclination is to check the ISY time to see if it matches reality.

I understand and don't disagree. Perhaps, rather than thinking about it as "in scene", perhaps better words would be " for scene controller"

"It is the KPL that controls the load​" I thought you said the switchlinc controls the load? (I am also having trouble keeping track of which names are which device. Is it the same KPL that you press that also controls the load? In general, if you want a responder device ON level to change in response to a given controller, the statement would be something like: In Scene 'controller' Set 'responder' 31% (On Level) Of course, pick the devices from the drop-down menu and the names will auto populate. For each controller/responder pair, you will need such a statement, since responder levels can be unique for each controller.

OK. So the controller is the KPL button and the responder is the switchlinc. Your program is close, but it should look more like (changes in red): If From 9:00:00PM To Sunrise + 9 seconds (next day) Then In Scene 'Great Room / Great Room Scenes / KPL Button' Set 'Great Room / Great Room Devices / switchlinc' 31% (On Level) Else In Scene 'Great Room / Great Room Scenes / KPL Button' Set 'Great Room / Great Room Devices / switchlinc' 100% (On Level) For each controller/responder, one must have a "set scene" line. Since you only have one keypad button you use to control the switchlinc, you should need only a single line in each action.

I can confirm that a togglelinc relay can control a dimmer switch. It sends dim and bright, and fast on.

My first inclination centers around a couple of possibilities: slow ramp rate or ON LEVEL set to zero. My guess is the second option. When you manually linked these switches, were they off? Turn on the primary switch. After that turn on (single press) the secondary switch. Does the primary switch turn off when you turn on the secondary switch?

I will be watching for the light show as I travel to he Greene Town Center tonight.

So, is 'GarageDoorMain​' the scene that includes the balky keypad button? I agree with xathros that this sure seems overly complex for the stated requirement. Since the particular scene is driven based on multiple criteria, it seems to me that it is nearly futile to try to solve this by a continuous bac,-and-forth series of questions. I can only suggest that it is a bit of forensic analysis should yield the answers you seek. If the KPL button is in a state that you believe to be incorrect, review the program that you expected to maintain the correct state and check the variables that make up the various conditions. Find the one that is causing the program to run false and trace the cause of that variable being other than what you expect. If all looks well on this front, consider the possibility that the ISY program is running as designed, but the commands are not getting to the keypad. Have you manually triggered any of these program (THEN path) to confirm that the commands are getting through? Are the "i" and "s" an indication of integer or state variable? I notice that when some program execute (THEN path), they change variable value for $s.gdm. Changing this value would subsequently trigger other programs. I also notice a particular value (3) of this variable has the potential to simultaneously trigger multiple programs and some of those programs have WAIT statements. Is it possible that these wait statements are being interrupted by the changing variable value and not running to completion? Could this be a problem?

I assume you are using the sunrise and sunset conditions as "dark", correct? I suspect you have some logical priority issues here. This can be corrected with a couple of parenthesis. I also suspect your THEN clause is incorrect. Rather than setting the responder levels, simply turn the scene on. If From Sunset To Sunrise (next day) And ( On Tue, Wed, Thu Time is 6:00:00AM Or On Mon Time is 5:30:00AM ) Then Set scene 'Outside / Side Yard' ON Wait 15 minutes Set Scene 'Outside / Side Yard' OFF Else -No actions

Such a program will run true if ANY ONE of the sensors change status to OFF. Even if two of the sensors are missing or ON or having no status or with dead batteries, this program could evaluate true if one of the other sensors changes to false. The only way for this program to run false is for ALL of the sensors to be ON. Is this what you intended?

First one is the one I always pick. I have the 994pro with z-wave module added.