oberkc

I suspect that one contribution factor is the programming logic. The third condition of each program (or not switched off/on) will cause both programs to evluate as TRUE when triggered from the admin panel, regardless of current device state.

If you are reading the OFF command from the log, it was recieved. What you may want to do is change "STATUS" to "CONTROL" in the timer program. This could make it a little less sensitive to communication problems.

I don't see any motion sensor OFF commands. Perhaps you should check your configuration of the motion sensor. I think this can be done manually, with little jumpers, or through the ISY if the jumper in position 5 is enabled. Best to check the manual to be sure. The 3am looks the same as the first snapshot. Are you sure this is the correct snip? Comm errors certainly a consideration here.

My theory is that CFL bulbs degrade over time. The fact that they worked six months ago does not eliminate them from consideration now. Besides, it is so easy to test out (temporarily replace with incandescent) that it seems prudent to me to do so. Eliminate the easy stuff first. Are you certain that the motion sensor is sending an OFF command? Do you see it in the event viewer? Remember, it is possible to configure the motion sensors only to send ON commands (I think this is called occupancy mode?) So long that you are getting OFF commands from the motion sensor, I expect this program to work. Regarding the lamp...do you have any programs running at 3am? Query, perhaps? I agree with LeeG...the communication errors you are getting sounds like a contributing factor here.

One of these days I am goong to learn to take advantage of the REST interface.

I am not sure that it does all that you asked for (does it start a new countdown when you close the door, or when you open it a second time?), but if you are happy with it, then that is good enough for me.

The only time that I have experienced behaviour anything like you describe I attributed to one of those fancy lutron or levitron switches. Since taking them out, the behaviour is gone. Right now, I have a cooper light switch which inludes a nightlight and motion sensor. I continue to find this light off at night and on the next morning. I wonder if one of my insteon programs (perhaps the 3am query) is somehow triggering this. The point I raise is to consider the possibility that some non-insteon system may be triggering some funny behaviour. Do you have any other systems that communicate via powerline?

I may understand your needs a bit differently (and, perhaps, wrongly) than the others. It seems to me that some of these suggested programs may not trigger the lights until 60 minutes after the phone is detected, or perhaps 60 minutes after the phone has last been detected. Is this what you wanted? Be aware that I am generally unfamiliar with REST commands, so I am assuming you have that working, and that your variable is a state variable (will trigger a program). For the purposes of this suggestion, I will follow the lead of the others and assume the state variable is 1 when detected and something else when not. Obviously, you cannot use directly the value of the current variable as an indication of being home (because of the intermittent dropouts). I would, thus, create a second state variable, calling it $athome. I will define the values for this variable to be 0=away, 1= at home. timer program: if $statevairable = 1 then set $athome = 1 else wait 60 minutes set $athome = 0 From there, it would be a relatively simple task to create a light program based on the $athome variable if time is from sunset to sunrise (next day) and $athome = 1 then turn on lights else do whatever you want done when having left home

My memory conntinues to be a little vague on this, but I recall some of the arlier devices may reuire a power cycle befor accepting the new settings. It is, at least, worth trying.

My lighting design includes two master scenes: all lights inside, and all lights outside. Any device or switch which controls or powers a light or fan is part onf one of these two scenes. At the end of the day, my program turns off these two scenes. If I were to ever want to transition to a different scene, with all other lights to turn off, I would consider a program which first shut off the ALL LIGHTS scene, the activated the new one.

Are you able to log into your router settings and see any IP assignments? Bad or loose cable? Unfortunately, my knowledge of such things is pretty limited.

I am unaware of anything that any program (or any other ability of the ISY) can do that would cause a keypad to emit a long beep and then to stop working. If you wanted to be sure, you could disable or delete the program and see if this solves the problem. Another thing I would do is watch the event viewer when pressing the F button. Does the ISY see it? Loose wire? My guess at this point is faulty device.

When one chooses a program under "action", there are choices that include "run (if)", "run then", and "run else". These refer to which of the three sections of a program (if, then, or else) to run. Once selected, it shows up in the program content as Run Program "XXXX" (then path)

I think I will stand by my suggestion on cocoontech. Did you try it?

What happens when you try this one: http://isy.universal-devices.com/99i/4.1.0/admin.jnlp

Motion sensor nodes? The first is motion sense, i recall. Second is day/night. Third is low battery. (Forgive me if I remember wrong.). The correct node depends on purpose. Use the first node for the motion condition in the program. The second node provides an opportunity to detect darkness and can be used in a program to define your day or night condition. The third node provides the opportunity to use in a program to send yourself a notification that it is time to chane the battery.

Switches... Nice! Really creative. Pick a time of the year. Determine when sunrise is at that time of year. Use that sunrise time as the limit of your time condition. I may steal this idea.

There is a program condition for this. It looks something like: if time is from 3am to 7am (same day) You will have to decide how you want the ISY to know if it is dark. One option is, simply, to use sunrise or sunset times programmed into the ISY. Another option would be to use the motion sensor, configuring it to send commands only during periods of darkness. There are probably other options if you would rather avoid using one of these two. This is no problem. The ISY has a "wait" statement that can be configured for three hours, and you can send a command to a specific device, as well as to a scene. What do you want to happen with the other two switches? Leave them on indefinitely? Do you want any of the lights to automatically turn off at sunrise/daylight? If the three-hour period exceeds the period of darkness, do you want it to stay on? I believe a program is the best way to accomplish this. Making no assumptions about your potential answers to my questions above, simply doing what you ask and no more, the program would look something like: if time is from 3am to 7am (same day) and time is from sunset to sunrise (next day) and control motion sensor is turned on then run second program (then path) else second program if then set scene 'three light scene' on wait 3 hours set 'one of the switches' off else You will see activity in the event viewer if the motion sensor is communicating. Have you added the motion sensor to the ISY yet?

The closest Insteon device that I know of would be the fanlinc.

I am able to make some of my modules beep with the ISY-994. I don't have any dual-band lamplincs, but I cannot imagine why they would not be so capable.

I can think of a few possibilities: a) they were turned off or on individually from the admin screen or a remote app the ON level for one is zero c) these devices (one or both) are also responders from another scene d) the status is inaccurately stated due to a comm issue I believe the red text indicates both are controllers of the scene, but it is worth confirming. If not, there is another possible explanation.

You may want to consider "control" rather than "status" for your garage door sensor condition. As written, if $OCC is 0 and the garage door is open, any time you turn off one of those two lamps, your program will execute TRUE. I am unsure, of course, what drives your $OCC variable to go to zero, so this may not be a practical concern. Still, I think "control" is a better choice here.

Glad it worked!

One thing to remember is that insteon scenes can have different ramp rates and ON levels, depending on which controller. When you are programming ramp rates and ON levels you wish to be in effect when the remotelinc is used, make sure you have selected the remotelinc under the scene definition. With the remotelinc selected, you should see, in the main panel, each of the devices in the scene, with ramp rates and ON levels. Make sure the keypad has the correct rates and levels.

Not certain, but I don't believe so. I understand the stickers on the units refer to hardware version, rather than software. I would think that if you were to isolate the swich (pull the tab) and your system starts working, that would be a pretty solid clue.