oberkc

I have also been watching that thread. It seems you are getting good advice there, by folks generally more knowledgeable than I. I may jump in soon, however.

So...I think we can eliminate the program as a cause, for now. Possibly, but not my first guess. It does seem, however, that some PLMs work better than others (for some reason). I would try a couple of things first. I would perform a device restore from the ISY on the switchlinc to see if this helps. There are no funny green or red symbols on your list of devices, are there? Does a device query give any results? What happens if you perform a scene test on the scene that includes the stubborn swithlinc? Failing all else, I would remove device from ISY, perform a factory reset, then re-add.

What happens when you turn the scene on manually from the ISY? Does it come on? I see no program problem here. Why the wait?

Have you tried the scene manually from the ISY? I dont believe that this is a program problem. Most likely communication issues with that switch.

Does your sidewalk and driveway have expansion joints?

To LeeG's typically thorough explanation, I would add one common programming error with "status" that are, generally, not an issue with "control". Often, one sees program constructs with a variation of a theme (admittedly extreme) such as: if status switchX is off then turn switchX on wait a few seconds turn switchX off else turn switchX off Such programs are those that change the status of a device which then trigger a reevaluation of the condition, can halt wait statements, trigger follow-on actions, and so on and so forth. Such programs can create loops, including infinite loops. When you create programs, watch out for programs with status conditions for a device, and actions for the same device.

By integrate, do you mean to -insteon ability to sense when the gate is open -open and close the gate with insteon -both If the first, then techman's solution may work for you. If the second or third, then I agree with xathros. However, is there a possibility for you to extract 120VAC from the solar battery system? (I doubt it, but this may offer an option to consider).

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?