oberkc

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.

No need to change the IOLinc. Change only the sensor. I don't remember "normally open" or "normally closed", either but understand you need the opposite type that came with the kit. My educated guess is that you would need a NC type so I believe your $5 sensor would work. BTW,I assume normally closed switches are those that are closed in the relaxed state...that is, when gap is wide. Hopefully, others will correct if I have it backwards.

When you delete the program, does it disappear from the list of programs along the left side? When you later log in has the program returned? When you delete the program, do you "save changes"?

I assume this is, simply, cut from my earlier suggested program (post #. Yes, the syntax is probably inaccurate and should be "switched" on. I also assume "device" and "dimmer button" are synonymous. stusviews...I suspect the statement in red is also left over from my earlier suggestion (post # and no longer applies, given the additional statements in the condition that you correctly point out would also trigger a TRUE result.

I expect that this will work. I don't think the ANDs and ORs and parentheses are too critical here, but test it out to confirm it does what you want. I think it will.

For CONTROL DEVICE XXX statements, they will trigger an evaluation only when the device is acted upon manually, and only when the specific XXX is recieved and will always evaluate TRUE when triggered. IOW, Control Dimmer is ON will trigger only when the dimmer button is pressed directly and only when pressed ON. OFF will not trigger it. DIM or BRIGHT will not trigger it. Additionally, CONTROL DEVICE IS NOT XXX will only trigger when the XXX command is received and will always evaluate FALSE when triggered. If you want a program that disables a program when a dimmer button is pressed ON and enable a program when pressed OFF: If Control Dimmer Button is ON <<<will trigger from ON command and evaluate true...all other times be false and Control Dimmer Button is NOT OFF <<<will trigger from OFF command and evaluate false...all other times be true then disable program else enable program If not obvious, a condition with multiple statements will trigger and evaluation when any of the individual statements are triggered, but the entire condition will be evaluated. So, when the ON command is received, the first condition triggers an evaluation, but both statements must be true for the condition to be true (AND) and runs THEN path. When the OFF command is received, the second condition triggers an evaluation, and if any of the statements are false, then the entire condition is false and runs ELSE path.

Whether or not you need it depends, I believe, on whether you are going to take advantage of "mobilinc connect", or make all the router settings yourself. If you are good with a router, ports, IPaddresses, and things like that (or are willing to learn), then I say skip it. If ease of setup is priority and cares about reliance on the cloud are minimal, then perhaps you should consider mobilinc connect. Moblinc connect has a monthly fee, I believe. I also understand it may have a few extra benefits. Personally, I do not use it. Be aware, also, moblinc for iOS is, apparently, a different experience than mobilinc for android.

Regarding control versus status, both are useful, but I would focus on what triggers a control/status statement and what does not, then understand that, once triggered, whether it is true or false. As far as disabling a program, yes, another program can disable the first. You need to decide under what conditions you want the program disabled. When someone turns on a switch (is it a dimmer or relay switch)? When someone turns off a switch? When a switch achieves a certain brightness level? When somebody dims or brightens a switch? Are there multiple switches involved? Rather than offer specific solutions, I suggest you simply decide what actions you want to cause a program to be disabled and we can go from there.

My understanding is the same as LeeG. Any retriggering and re-evaluation of a program will interrupt a halt or wait statement. In different words as LeeG, this is because such a statement is only triggered once per day. This condition is not triggered at 5:31 or at 5:32, or at 5:33. It is never triggered at any time other than 5:30.

That sounds like good advice. I am sure the one who recommended it is wise and good looking. I just wanted to point out (in response to your thoughts on integration between the harmony and ISY) that there is already integration to some degree. Just because the integration does not happen via the ethernet cable does not mean that it does not exist. There are more than one way that devices can communicate. IR is one such way. When it comes time to tackle this aspect of your home control, rather than starting with solutions (official hub support of the ISY), instead consider WHAT you want to do (control a light with a remote button). It is very possible that this can already be done.