oberkc

I would simply turn it off at 11 without checking status. I have never perceived any harm in this. For the record, ON = 100%. One can also use NOT OFF as a condition, which is any percentage above zero.6IS RESPONDING will not accomplish your goal. This represents a condition that differentiates between when a device is communicating or not.

I suspect you wiring diagram is not correct. So, you have a single cable coming into switch box with black and white conductors, correct? I cannot tell from pictures, but do you have two cables at ceiling box, both with black and white conductors? If so, connect black and white conductors at ceiling box. To those, connect black and white from fanlinc. At the switch box, connect black conductor to black white from keypadlinc, and white to white. Cap the red wire. Back at the ceiling, connect whit from the fan to the bundle of other whites. Connect red from the fanlincnto the wire powering the fan. Connect blue from the fanlincnto to the wire powering the lights. You will also have to program (link) the keypad and fanlincnto.

When you put the ISY in "linking mode", is this the same mode you use to add insteon devices? For Z-wave, one must "add/include Z-wave device". Putting the ISY into linking mode will not work with Z-wave. My recollection is that one first must choose "add/include Z-wave device" then toggle the desired z-wave device. If this does not work, try first excluding the z-wave device. In case you have not checked, instructions are here http://wiki.universal-devices.com/index.php?title=ISY_Z-Wave_GenII_-_Instructions

I find variables an unnecessary complication in this case. I use a simple program such as: if control light switch is switched on an control light switch is not switched off then nothing else nothing Once a program like this is in place, I use the program status (TRUE or FALSE) as a condition to my motion program. Obviously, these additional complications eliminate the use of scenes between motion sensor and light, so it would all be done via programs. Also I assume the light switch controlling the motion program is the same one controlling the light. If not, there may be a few details different. Assuming I have it correct, only a manual activation of the switch, itself, will disable the motion response. Furthermore, if the light is on from motion and you turn on the switch, the timer is halted and the switch stays on indefinitely. Turning off the switch while the timer is active will, obviously turn off the light. if control motion sensor is turned on and status first program is false then turn on light light switch wait a little while turn off light else nothing

I must admit to being a little curious...in what way could it be more convenient? Put ISY in link mode, tap the devices, done. Are you looking to avoid the physical movement throughout the house? This can be done if you know the addresses for each device, but I have found it (personally) easier to simply tap the device.

If you have not already done so, draw the wiring diagram for the two switches and fixture. This is much easier to visualize than trying to do so in your head. Depending on your familiarity with these circuits, you may need to perform a web search. In case it is not obvious, RBW cables from both switch locations go to fixture box.

The trick, in my mind, on any of these three-way circuits is to identify where power is introduced...at the fixture, or at one of the switches (an which one). There sounds like a lot going on in that mudroom box, and I suspect it all comes in there. Are both of the fixtures controlled by switches in the same two boxes, kitchen and mudroom?

Stusview...fixture wiring was described in original post. In fixture box, one white conductor connected to one black conductor (forming one of the travelers). Everything matched up beautifully when I drew it up. Power in at mudroom. RBW cable from there to fixture, and RBW from fixture to kitchen switch. Yes, I am assuming white from mudroom to fixture is neutral (it was not stated what this white was connected to). I thought you were trying to control a single fixture controlled by a three-way circuit, with one switch in one box, and another switch in another. I remain convinced you CAN do this if you are willing to forgo the micro module and replace the two switches with insteon.

I understand mobilinc home supports homekit and siri, but dont know whether it supports insteon or the ISY.

Yes, the mudroom box is the one with supply. In the kitchen box, the red and white are travelers and the black is the switched hot that connects to the load in the fixture box. In the mud room, the black and red on the brass screws are the travelers that go to the other switch. The white in the RWB cable is neutral to the fixture. Hot is connected to your switch common screw. I must admit that I am having trouble picturing how to wire this with existing conductors, using only a micromodule. The module requires unswitched hot, which is available only in the mudroom box. Unfortunately, the three conductors from this box to the fixtures are taken...two as travelers and one as neutral. All are still needed, which means that there is not a conductor for the switched hot from the module to the fixture. Given this, I am not certain you can do this without two insteon switches (but no micromodule would be needed). Perhaps stusviews or someone else has other thoughts.

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.