oberkc

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.

Arun, I just ran an experiment and I was incorrect. Controlling scenes that include Z-wave devices, using an insteon keypad button defined as scene controller, DID cause the Z-wave device to respond. I am sure this is handled via the ISY, rather than direct communication between the insteon keypad and z-wave module. Also, I notice that I cannot set z-wave ON levels to zero. But, for simple scenes, it seems the Z-wave devices turn on when a in insteon scene controller issues the command.

My experience is that z-wave devices can be added to scenes, but these only respond when calling the scene from the admin panel or by program (PLM as controller). Z-wave devices don't seem to respond directly to insteon controllers and it does not appear to me that the ISY tries to simulate this response. My z-wave experience is rather limited, though, so I would be happy to be corrected.

Make sure the the PLM is also on a clean circuit, as well. The PLM will be key to your system, and you don't want it plugged in with a bunch of computer stuff and other gadgets.

I still believe this is an issue with the speed of the double-tap. Comms between the switch controller and light in the MBR sound good, since the scene is working, but comms with the ISY may be suspect. An alternative to some of the other suggestions is to open an even viewer and press the switch once (see if you are getting the OFF command) and then quickly twice (see if you are recieving the FAST OFF command).

I suspect your program is fine. More likely is the possibility that a fast on requires two taps in quicker succession than you applied so far.

1. The time out will not send an OFF command is you have it configured to send only ON commands. It looks like the second check box needs unchecked for this to be the case. Once unchecked, it will not turn off the lights for which it is controller. If you uncheck that box, however, you will need a program to turn OFF the lights, but not to turn them ON. 2. Yes, you want that checked (first box). You want the sensor to send ON commands upon any sensing of motion. You do NOT want to wait for the time-out period. 3. The third box looks correct to me.

I find things in the wiki, the manual, and by exploring the admin panel. If I see an option in the admin panel that I don't understand, I specifically search for it in the wiki and manuals. Failing that, I come here.

I dont know whether it is "normal", but it is not necessary. The response is likely due to the way you programmed it. Feel free to post the program and I am sure some kind soul will analyze and confirm.

I offer up another consideration. Whether a given sensor has an ON or OFF state with the door closed is also dependent on how the sensor is mounted. A sensor could, for example be mounted in such a way that it is activated (energized, magnetized) only when the door is fully opened, rather than activated when the door is fully closed. The question becomes how does one treat a door that is neither fully open or fully closed. Do you want to consider any door position that is not fully closed to be open, or do you want to consider a door not fully open to be closed? For me, I consider a door open when not fully closed, even if only partially open. Answering questions like these could offer alternative solutions.