oberkc

I see no reason why setting the ramp rate and ON levels could not be done independently, by a program. One thing to watch out for is to be sure to set the ON levels and ramp rates based upon which controller(s) you intend. Make sure you are setting the ramp rate for the motion sensor as controller, and not just the switch, or the scene level.

I am having trouble explaining the described behaviour based on apostolakisl program. I cannot see how turning off the light would trigger the fan. In your version of the second program, are you using "control" or "status"? If you don't mind, please post your programs.

there are lots of LED undercabinet light options that plug straight into normal outlets or can be hardwired. There is no need to go back to halogen, other than because of preference. Besides, halogen do not give off light at the 5000K range.

Have you read the wiki? Have you read the user manual? Have you read the manuals that come with each device?

In the listing of programs, right-click, run then path. It appears to me that you have a failure in the scene test. While not conclusive, this is a bit of evidence here. Does it consistently fail? More failures. Ugh. Did you disable the programs before trying this test? Did it affect the results? I think I am starting to see a pattern here. Your scene tests suggest communication problems. Your device failing to respond from manual triggers suggests communication problems. Perhaps this is the root cause of your issue? Have you read any of the (many) threads on communication problems and troubleshooting? It can be a frustrating process. Start with the easy stuff...is the PLM plugged into an outlet or circuit that has lots of other computer stuff, UPS, surge suppressors, computers, routers, modems, etc....? Do you have two access points or other means to couple your electrical legs (phases), confirmed on opposite legs by the method in the user manual?

Just to confirm I understand a few details... - you have a "hallway KPL G Basement Dim" device. Is this a different KPL G that is controller of the scene "basement dim"? If different, is it part of any of the same scenes as the other KPL G button? - what is the difference between the "basement off" scene and the "basement LED off" scene? The KPL G is controller in the 'Basement Dim' scene Its a responder to the All Off scene (just a whole house off scene) and the Basement Dim scene You state that the KPL G is controller to the basement dim scene and also responder to the basement dim scene. Correct? Since, with the ISY, any controller is automatically a responder, are you suggesting that these are, somehow, different scenes? Or...are you just reaffirming the principle that controllers are responders. Based on what I see, the KPL is part of the following three scenes: All Off, Basement LED Off, and Basement Dim. There are no other scenes in which the KPL G button is a part, correct? These two programs are the only two that affect on, or are affected by, the KPL-G button, or on/by a scene that includes the KPL-G button. Is this correct? There are two reasons (beyond device failure) that I can think would cause the KPL to not come on when you expect: communication error or program/scene error. I would like to eliminate the communication error. Have you performed any scene tests of the "basement LED off" scene? Have you performed any scene tests of the basement dim scene? What are the results? Have you manually executed the THEN path of either of these two programs? What are the results? Do they always turn the KPL G button on/off as expected? Be advised that you may need to temporarily disable these two programs to achieve successful results. Once we can reasonably eliminate comm errors as a factor, we can look at the interreaction of your programs/scenes/devices.

nothing wrong that I can see

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?