oberkc

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.

What you are suggesting should not mess with the ISY. Just so you know, it has never been overly complicated to control insteon with a harmony remote, hub or other, or any other IR remote. Insteon makes an IRLinc, and some versions of the ISY have an IR receiver. It did not take me very long to have the ISY recongize button presses from a remote control and perform a programmed action. If the goal is, simply, to have the insteon house react to button presses on a remote control, this is quite doable and has been for some time.

pretty cool video. Thanks.

Xathros' idea is a good one. Another option, if it doesn't conflict with other uses for scene "first floor lights" would simply be to keep the keypad button as non-toggle-on, but include that same button in the first floor lights scene. When that scene turns off after the 1 minute wait, then the button would turn off, as well. This has the potential value that when the keypad button is lit, you know the timer is active.

Battery devices, such as the motion sensor, do not constantly listen for insteon signals. This is to save battery life. The exceptions to this are when motion is sensed, when the set button is pressed, and when the battery is replaced. I wonder if replacing the battery allowed the ISY to write the now-correct settings to the motion sensor?