oberkc

I would expect that one program would work. In this case, I would try "status" rather than "control" for your master bedroom keypad condition.

Well, I can only speculate, given that I know nothing of what is in the scene or the elk condition. How long does the kitchen motion violation stay on? Is this a momentary condition? Can you observe the status of the zone from the ISY-99 admin panel? Is it possible that the violation comes on for a short (less than two minutes) period, turns off (unviolated?) by itelf (or based upon motion sensor input), forcing a re-evaluation of the condition before the end or the two-minute wait period?

I use several outside, but protected from direct exposure to any precipitation, wind, or sun. Temperatures range from -15 to 100.

Typically, this is caused by a a program action that would force a re-evaluation prior to the end of the wait. Does changing the scene "front door / foyer" cause some change or violation in the elk zone "kitchen motion"?

Besides kitchen cans, What other devices are in the scene "kitchen sensor on", and what is your purpose in creating this scene? What is your intentions with your third condition (kitchen cans not on)? In my mind, this condition has no purpose given your stated requirements.

You may have to describe the desired response of each device.

I would investigate the use of program folders. With such a folder, you can specify conditions where included programs will be enabled. For example, you could create a folder with the condition that included programs would be enabled between 1010 and 0110 (next day). In that folder, place your current program, with the condition modified to be based only upon the garage door sensor (removing the time-based condition).

Yes

I did not mean to suggest that there are never reasons to check status, but, rather, in this case. The stated goal is simply to turn them on at a certain time, then turn them off at another time. I believe hyounker has the best approach given the stated desires.

I see no practical reason to check light status as a condition. If Time is from 1240 To 1245 Then Turn light on Else Turn light off

I don't believe there is "harm" from disabling the query program. I have always assumed it is there just to provide re-align ISY status with actual device, reducing the risk of a mismatch. I have never understood why running a query would change the status of a device. Perhaps the query triggers a program?

The point I was trying to make was that I see NOTHING that would cause "NIGHT TIME" scene to go off, accidentally or otherwise. I suspect there are things going on in programs or scenes that you have not mentioned or described.

I see nothing here that would cause a scene "night time" to turn off for any reason. I could only speculate on possible explanations.

Do you have access to the wiring feeding the outlet (such as in a basement or attic)? If so, break into this wiring and add an inlinelinc and filter. Replace the outetlinc with a normal outlet, controlling it with the inlinelinc.

I don't see a "night" scene. I see a "night time" and "night time indictor". What am I missing?

What is in scene "night time indicator"? Good night button? Anything else? If you are happy with how the system operates, i don't see any obvious problems.

Are you suggesting that you want this light to be, in general, permanently on, with the exception being the several-minute period immediately following a button press? Or do you want it to stay off until the following day? Do you only want these several lights to go to these levels and leave the rest as they are, or do you also want this to turn off some lights? Probably. I will call that scene "good night". you can either set the device ramp rate to this or create a program to wait some period and turn it off. I will assume the latter. I suspect there are details that are unspoken or unthought, but the logic of your stated desires should be simple enough. In pseudo code (hoping the intent is clear): If control "good night light set button" is set off << then turn scene "good night" on run program "turn button back on" (then path) run program "turn bedroom light off" (then path) else create a second program called "turn button back on" (and disable it) if then wait several minutes set "good nigh light set button" on else Create a third program "turn bedroom light off" (and disable it) if then wait five (TBD) minutes set "bedroom light" off Of course, use device and program naming conventions as you see fit.

I don't believe "keep existing links" makes any difference, either. My experience is that the relationship between the morninglinc and the lock is unaffected by anything insteon.

I am a relatively new user of mobilinc, so much of this is based on limited experience. I am not sure whether it is clear, but when you add a garage kit to your system, two devices (both part of the IOLinc) show up: the relay and sensor. You should not expect the relay to display status of the door. Neither should you expect the sensor to control the door. Mobilinc shows both devices, relay and sensor. Make sure you are looking at the "sensor" device when determining status of the door. Mine appears to work correctly.

I know I learned a few things today! Makes me want to go get some IOLincs and find interesting uses for them. I have always wanted to install a sensor on the front door and turn on lights when I enter. I just have to figure out how to programatically determine when I am entering versus leaving.

If you choose to use my suggested approach, add the delay to the second program: if status 'elevator 1-opened' is off then Set Scene 'Basement Scene 1 - Group' Fade Down else wait 15 seconds Set Scene 'Basement Scene 1 - Group' Fade Up As Xathros suggests, you can modifiy the wiats and delays to suit experience.

OK...let me take a shot at this. The general logic goes something like: I know that I want to do something (either turn them on or off) with the lights every time I the button is pressed (recieve an "off" command). What I want to do is dependent on the time between the "off" and subsequent "on" commands. If I receive an "off" command, wait a couple of seconds to see if it is still off. If so, turn the lights off. If not, turn the lights on. To do this via ISY: if Control 'Elevator 1-Opened' is Off Then wait 2 seconds run next program (if path) else Next program (disabled) if status 'elevator 1-opened' is off then Set Scene 'Basement Scene 1 - Group' Fade Down else Set Scene 'Basement Scene 1 - Group' Fade Up You will need to disable the second (next) program so that it does not trigger itself. Of course, you can use any naming conventions that you like.

I would expect this, given your original program. However, if you are trying to turn your lights off, would they not already be on? If so, then would this behaviour matter? If you still feel the need to avoid this, perhaps further program refinement could work. This is NOT what I expected (otherwise, I am surprised the suggested program works). Is not the "on" command sent as soon as you PRESS the button? Then, as you release the button, is not an "off" command sent. Knowing the answer to these questions is critical here. Your application strikes me as pretty unusual and it may be best to confirm this in your particular usage.

That would be great if it works! To this great suggestion, I add that the condition should be based on "status", as in: if status 'triggerlinc' is on

Agree with LeeG here. It is more important to know the door is fully closed, rather than fully opened (partial open is still open in my mind). Remounting the sensor is the optimum solution here.