oberkc

No, I dont find this overly difficult. One must, however, pay attention to things beyond ISY programs, to include the relationships to sceces and configuration of the motion sensor. Your panic exit, however, seems a bit more complicated. I suspect this will take a combination of several programs. The use of a variable may be the most viable approach. In what status do you expect master.light c to be after panic is initiated? How long do you want to wait between the individual toggles of button c before failing to recognize the sequence?

When was the last time the program ran, according to the log? Was it more than a day ago? Do you see any mismatches between light status as shown by the ISY and actual light status? In my experience, programs fire when conditions are met. Sometimes, the ISY can miss certain conditions if there is comm problems present. Somethimes, a program can run but comm problems prevent devices reacting. If this were me, I would be looking for clues to narrow down the cause to one of these possibilities. Without seeing the program in question, I would be unable to even speculate on possible programmatic issues, but feel free to post if you want second opinions on this possibility.

I think I would create a new party scene also, with the proper levels predefined.

How confident are you that the switches are wired properly? In three way white cannot be counted on to be a neutral. Does any switche loose power when another is toggled? If wiring is good, add all switches (for a given fixture) to a scene, all as controllers.

Not that I have seen

From a program, one may initiate another program. There are three parts of a program: if, then, else. When one invokes a second program from the first, one must specify which, of the three parts, is being invoked. In this, case I proposed invoking the "then path". In this case, in the second program, notice that there are NO commands in the IF or ELSE paths...only in the THEN path. I am always unsure of how familiar people are with programming the ISY, so I don't take a lot of time in early responses worrying about exact phrases. Beware, my proposed program wording is VERY approximate. The ISY will create the proper syntax for you. You must simply select the commands from various drop-down boxes. I takes a little practice, but you will get good at it soon enough.

I suspect you may need to refine your requirements a bit. Let me see if I can restate: a) you want a notification when motion is sensed. after any notification you want a 15 minute wait period before any subsequent notifications, regardless of whether motion is sensed. c) Once a 15 minute wait is over, you would like notifications to be enabled again. without thinking too hard, my initial temptation would be to break this into two programs program 1: if motion is sensed (in your case, if X-10 command is recieved) and if program 2 is false then send notification run program 2 (then path) else nothing program 2: if nothing then wait 15 minutes run program 2 (else path) else nothing see if something like this works for you. Let me know if you have questions about any of the concepts behind this approach.

When you press C or D, this sounds as if it is what you expected. Unfortunately, I missed where you stated your expectations with regards to whether the button stays on or off. Did you want the button to turn off after flashing a few times? When you press E or F, I also am failing to see your stated expectations with regards to whether the button stays on or off. Do you expect it to go off? I am drawing a blank on "SLD". Sorry. While I find mutually exclusive relationships to have a place in this world, I am not sure that you need to have a mutually exclusive relationship AND the scenes you describe with responders set to zero. In a mutually-exclusive relationship, pressing one button would cause that button to come on and the others to go off. The behavior you desire sounds to me like a button in "non-toggle off" mode. IN this mode, pressing the button always transmits an OFF command, causes the button to blink, then the button to turn off. Unfortunately, any scene responders linked to that button would all turn off as well (since the button is sending the OFF command). I see a couple of options. In both options, you should eliminate the mutually exclusive relationships. One option would be to put all buttons C-F in a non-toggle OFF mode, resulting the the blinking and condition behavior you want. Buttons C-D would NOT be scene controllers (since you cannot turn ON a scene by sending an OFF command). Instead, use a program to turn on the scene containing the affected devices triggered by the button OFF command. The second option would be to leave the scenes as they are, put buttons C and D in non-toggle ON configuration, but add a program to turn off thees two buttons after a few seconds, in response to an ON command from the buttons. Hopefully, you can see the concepts and fill in whatever gaps I have left.

The ISY itself has no insteon RF capability. Some PLMs at dual band, but I cannot imagine why their range would be any better than the hub. I understand theoretically that ISY devices can communicate with each other via commands through the network module, but this is something that I have never attempted.

I am using the morning industries lockset with the insteon morninglinc. It seemed a little finicky to set up but has been rock solid since. The downside to the morning lock is that it does not broadcast any status change...it can only be controlled. Unlocking the door manually, or from the key fob, or keypad cannot initiate any insteon action. With the introduction of the z-wave card, I understand this brings many of those options to play, but I have no first-hand experience. I understand that some z-wave locks will transmit a change in status when acted upon locally.

I recall reading an occasional question about this, but I don't recall that there was ever a common solution, if any. I don't believe it was a systemic problem with the ISY. I do not recall any posts about any relationship between a device action and ALL ON. Rather, I thought they were more random. Perhaps there was some relationship to power outages and queries, but that is just a guess.

How many wires are in the switch box? If only two, then it is a near certainty that you don't have a neutral. If you have more wires, you can test by measuring resistance between ground and a suspected neutral. Resistance would be near zero. Test without power.

Well, then. Have you tried the "start linking" option and letting ISY try to figure it out?

I don't keep much track of what devices are supported by what versions of ISY software. I am also unclear which method you are using in an attempt to add the new module. Are you using the "start linking" option, or something else? My working theory is that you are trying to add an unsupported device. Let's assume, for a minute, that your newly-acquired outdoor module is NOT supported by the software version on your ISY-99. Still, the ISY shows an outdoor outlet with an identical part number. Have you tried manually adding the device, inputting address and selecting the outdoor module from the drop-down box?

I cannot think of an obvious explanation. The program looks proper to me. A couple of questions come to mind that may lead to further thoughts: Does the event viewer show the ON command from the button ''1C.3F.D9 - C' ? Is it possible that you are holding the button for too long, sending instead a "dim" command from that button? Is it possible that the remotelinc has A16 assigned to it?

The problem with your first approach, I suspect, was that the same motion sensor which triggered your 2 minute countdown also made your other program true. Of course, I have not seen the second program, so I can only speculate, based on evidence presented. While you did not directly answer my question about whether "on" for the first program was the same as for the second, I will assume they are not. I will also assume that, for your location, dawn is always AFTER 5:30am. I will further assume that you will be satisfied if the lights turn off at 530 always, regardless of whether any wait period is in progress. a) Create two scenes, each having the same devices. The first scene having the ON levels for each device that you want to employ for your two-minute period, the second having ON levels for each device (assumed 50%) for the period between 530 and dawn. create a program: if time is sunrise set second scene off else nothing c) Create a program folder with the conditions: if time is from sunrise to 530am (next day) then allow programs in this folder to run d) create a second program folder with the conditions: if time is from 530 to sunrise (same day) then allow programs in this folder to run e) in the first folder, add this program if control motion sensor is switched on then set first scene on wait 2 minutes set first scene off else nothing f) in the second folder add a program if control motion sensor is switched on then stop program in first folder set second scene on This may not be the most elegant, but it should get the job done. Syntax is, obviously, very approximate.

While apostolakisl is correct technically, it is still likely a violation of code. This may be enough to sway someone against it (but probably not me). Consider, too, the possibility that this could have an affect on your insurance coverage should you have an electrical fire. While the fault may lie elsewhere, there is a chance this could get noticed and make collecting your claim a bit more difficult. After you sell the house, are you liable for what happens afterwards? It is up to you whether there is any risk involved, what is the risk, and whether it is worth it in order to avoid spending $50 on a micromodule (or inlinelinc if you can still find them).

First, I would create a scene with the lights you want to come on all included, all as responders, with the ON levels for each at 50%. First, I would create a scene with the lights you want to come on all included, all as responders, with the ON levels for each at 50%. Then I would create a program: if time is from 530am to sunrise (same day) and control motion sensor is set on then set scene on else set scene off So you want these lights to turn on at dusk-30, stay on, and turn off at dawn? Is "on" the same as above (50%)? If it is on until dawn, why do you need the first program?

Wow. The original program has a pretty blatant omission compared to the "actual" program. The question that is now coming to mind is what causes the program "morning walk" to become true or false? What is the purpose for this condition? My suggestion is to delete that condition and see if your original problem (lights continuing to stay on) goes away. If so, then we can try to address the other concerns you raise.

I see nothing in the program that would cause this. Often, when people use STATUS as a condition, wait periods can get interrupted. You, however, are using CONTROL. This will trigger only upon receipt of an ON command, and only execute the THEN path. Given this belief, i would try to look for clues to isolate the problem. - is you ISY seeing the ON commands? Check the program logs to see if the program is being triggered by motion, or watch the event viewer when motion is detected. If you have the motion sensor as scene controller with the lgihts as responder, it would be easy to falsely assume that the program is being triggered because the lights are turning on. - program runs, but the lights dont turn off. Try things such as manually running the THEN path of program. Do lights come on then go off? Does changing wait period affect this behavior? Try turning off the lights manually from the ISY.do they consistently respond?

No, i dont believe this isnormal. My mobilinc shows current status, I believe. Still, there are a couple of things that I have learned to watch.... A. It is pretty easy for mobiline to loose sync with the controller. If you make changes in device or scen settings, I find it necessary to re-sync mobilinc. If not, mobilinc will neither show correct status nor control devices B. It is necesssary to pay close attention to the difference between scenes and devices. I suspect your problem is more likely related to the first possibility.

My understanding is the same as LeeG. A better solution, in my mind, is to use a micromodule to power the load in the fixture box. Doing this would allow two wires to switch boxes to be converted to line and neutral. No return is required.

There is one general problem situation with switches: switch loops, where the supply cable enters at the fixture box and they send only a hot-and-return to the switch box. In this case, there is no neutral and one has to get a little more creative with the wiring and devices. If you can determine where the supply cable enters the circuit, and if it is in one of the switch boxes, your are golden.

Michel, This is a duplicate post. The original poster has not been back.

The basic idea is that each insteon device requires a neutral and a hot. Only one of the insteon devices connects to the actual load. Identifying and configuring the wiring is the trick. One cannot assume white is neutral, or black is hot. A voltmeter is, as far as I am concerned, a mandatory tool for people interested in engaging in these types of activities. Google is your friend for learning of the various wiring configurations for multi-way switches, matching to yours.