oberkc

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.

This, in my mind, is the most common use of motion sensors. Yes, there are good programs available, but will require adaptation for your own types and numbers of devices. Are you familiar with the udi wiki? There is a good discussion about motion sensors used in a bathroom. The basic concepts are the same and pretty well explained there: http://wiki.universal-devices.com/index ... _Bathrooms The way I do this is to use several programs. The first one is simply to keep track of manual control of lights. If Control light switch is turned on And control light switch is not turned off The Set variable (integer type) = 1 Else Set variable = 0 I then use these variables to decide whether i want to enable the motion program If variable = 0 (lights have not been manually turned on) And ( control MS1 is set on Or control MS2 is set on Or control..... (Add as many motion sensors as you wish) ) Then Set lights on Wait x minutes Set lights off Another key is supplementing this with the right scenes. First, the motion sensor should NOT be controller of any scene. The light switch controlling your outside lights SHOULD be in a scene with the lights if there are multilple devices powering your outside lights. For the variable, make sure you define it as an integer. Understand that there are settings on the motion sensor that can affect performance of this setup. Hopefully, you recognize that my syntax is only vaguely accurate, and can see the ideas behind it and adapt for your actual devices.

if control motion sensor is on << then turn on light wait x minutes turn off light else nothing

Perhaps I am loosing track of what you are trying to accomplish, but I am not sure why you have all those STATUS conditions in there. Specifically: And Status 'Garage Interior / Interior - Garage Lights' is Off I suspect it is this condition that is keeping your motion sensor from retriggering the countdown.

The only reason, besides device malfunction, that I understand would case a switch to come on at certain levels are the local settings for that switch. If you are confident you have the programmed appropriate, I would consider cycling the power to the switches. I recall that, for some settings, older versions of switches require a power cycle for the settings to take hold. Alternatively, check that you don't have any funny green or red symbols next to any of these devices indicating a need to write to these devices.

My assumption is that your program is triggering at sunset. The question, then, is how to set up the program with the same conditions, but does not trigger at the from/to times. This is what I came up with: From Sunset To Sunrise (next day) Then run the programs in this folder In the folder, add a program: If $My_iPhone_home is 1 Then Send Notification to 'Text Message' content 'My Home' Set Scene 'Scenes / Outside Rear Pole Lamp' On Wait 3 minute Set Scene 'Scenes / Outside Rear Pole Lamp' Off TJF1960 version would work as well, I expect. Beware....I expect your program has another hole. What happens if you leave home (or sunrise occurs) during the 3 minute wait? (hint: the light may not turn off.)

I vaguely recall once switching line and load. My recollection is that the switch can appear (leds on) but act very strangely. If you think this is a pssibility, best to confirm independently with a volt meter.

Another option to consider is to look at your program log and see if any fired at the time of the latest log event. If you can identify a program that is causing this, then you should be able to make adjustments to make it behave more as you intend.

Basically, yes. STATUS conditions trigger at any change of state. CONTROL conditions trigger upon receipt of the specified control, but not other controls for the same device. FROM/TO conditions trigger only at the specified times...not anytime between.

based on the reply from apostolakisl, I would also consider the possibility that your first program may suffer similar problems as the second, if one of your elk conditions becomes unviolated. Subsequent sensing of motion would restart the timer, but if the timer is running and an elk condition retriggers the program as FALSE, then your timer will stop and the lights will remain on until another trigger (and TRUE) occurs.