oberkc

I responded at smarthome forum.

I am still suspecting issues I have already asked about, but have missed your response. This includes ON levels, in what scenes is the KPL button, little symbols, results of scene tests...? It really helps if you respond to those kinds of questions. Without details, one can only speculate. My best guess is that your KPL (both controller and responder) is part of multiple scenes, that the scene 'LED OFF Scenes / BASEMENT LED OFF" includes some, or all, of the devices that are a condition in your program (causing the program to retrigger), that you have other programs that turn the KPL button off, or some combination of these issues. Or, it could be a simple communication problem. Perhaps I can summarize: a) in what scenes is the KPL. Name all of them. Which controller, which responder? what devices are in scene "LED OFF Scenes / BASEMENT LED OFF"? c) what other programs affect the KPL button? What program or scene turns it off (have I missed this?)? This CAN be solved.

If you are using a KPL button to initiate a program to turn one scene on and another scene off, then, no. If you are using combinations of scenes and programs, I can see where this might get messy quick if one is not careful. Of course, no insteon device can be CONTROLLER of more than one ISY scene. Perhaps it would be worthwhile to select the KPL button, and check (on the right) which scenes this button is controller of, and which it is responder to. Report back the results.

This tends to confirm, in my mind, that the problem is NOT with your program. Possibly. It could also be a communication issue. Are you sure the keypad button is part of the scene? When you select the scene, what is the ON level of the button? 100%? Zero? Are there any red or green symbols next to the device in the ISY list of devices? What happens when you perform a scene test on the troublesome scene? If the above steps showed no indication of problems, I would go a little deeper. Because it is pretty easy to do, I would then restore the keypad device and hope this solves the problem. Please report back your findings.

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?