oberkc

MikeD, my zwave devices work very well in scenes, but only os responders. But, my number of zwave devices is limited

Did you create the scene with KPL as controller and lock as responder? If so, I am hopeful that pressing the button will control the lock.

Ajax. You are correct that a if statement is false it will run the ELSE path. What may be less obvious is that for a statement to be evaluated as false, it must be triggered at such times. One MUST be aware of when programs trigger an evaluation. In your case, it would trigger only at specific events: keypadH switced off and doorlock is locked. In both cases your condition evaluates TRUE. Your program has no triggers that can cause a false evaluation. Yes, try the kpl in a scene as controller with lock as responder. See if this causes the door to lock/unlock without further neednfor a program. On further review, also perform some tests to be sure the ISY reacts to the 'control...door lock" command. When I use zwave devices as program conditions, they respond to STATUS conditions only. As far as your program conditions, I pose a question for you to consider: how would your program behave differently if you used STATUS rather than CONTROL as conditions?

I think KeviNH nailed the problem. There may be an alternative solution to the "second program" approach. Try using "control" rather than "status" for the garage door sensor condition. (Suggested ELSE path not needed.)

gduprey, One other thought...is it possible that something is causing a variable change during the 15-second wait statement, causing the program to retrigger and cause unexpected results?

gduprey To confirm my understanding of variable triggers, I created a test program that is nothing more than: if state variable is 0 then nothing else nothing I then changed the value of the variable to 0, then to 1, and to 0 again. I did exactly what you and I and larryllix expected: all changes triggered an evaluation, the program triggered and ran true when the variable went to zero, triggered and false when the variable went to 1. I have no explanation why yours would be any different. I must admit to having trouble believing that a program is randomly not triggering for the same input conditions. There is something else going on here. Perhaps it is the computer's frustration sensor. As you know, computers can act up if the operator is frustrated or lose confidence. Computers are very sensitive.

I have not found it accurate to judge whether a program did not run based on observing redpibse from devices. Sometimes, devices dont respond because of pogram errors. Sometimes they dont respond because of comm issues. Dometimes, there are devicee failures. If you have not already done so, i suggest using the program status (ladt run time, true/false) as the only conclusive evidence regarding whether a profram ran.

Is there any observed relationship between the value of the variable and when it runs? Does it always run when the variable changes to 0 but never run when it changes to 1? Other way around? No relationship? Have you ever seen the program status as FALSE? Based upon what I have read so far, my best guess is that we both may misunderstand what is a trigger for this program. I thought it would trigger upon any change to the variable. Perhaps it triggers only when the variable changes to 0? I am sorry, but I dont see anything obvious here and can only help with suggestions on how I would troubleshoot. For the record, I have never noticed a program not trigger when input conditions warrant.

What does "kick over" mean? Why, in the if/else path, do you turn something OFF/ON, wait 15 seconds, then turn it OFF/ON again? Have you confirmed from the program list, that the program status is true or false as expected? (Is the status of this program always true when the variabe is 0 and always false when the variable is 1?) I dont see anything obvious in this program which would explain your unexpected behavior.

To expand upon stusview response... Your program will never run the ELSE path as written. Upon what condition do you wish to run thw ELSE path?

You need, hen, to re-wite a couple of you program actions. Your THEN and ELSE actions should be in the form: Set scene 'pool pump X' on. The current statements do nothing other than change the responder levels of the micro modules to a scene ON command. Thy do NOT actually transmit a command to tun the scene on.

Sometimes, trying the write process another day, or at different times of the day works. I have always assumed that the electrical environment can be more troublesome at some times than orhers. Also, try temporarult moving the lamplinc to the same outlet as the PLM.

Are you expecing the two timer programs to turn anything on or off? (As coded, they will not do this.)

Bbuchanan99, The ELSE path in your program (turning off your keypad scene) will never run. Your condition wil always evaluate TRUE whn triggered. At what point do you want it to turn FALSE?

I do not see how variables will have any impact or relevance to the interaction between the ISY and Axis camera. Variables are mostly used in programs, either as a condition or action. I assume you interract with your camera through the network module and network commands/resources, no?

By having them in a scene, pressing one should cause all to go on/off. Setting the backlight levels to 15/5 can be done via the ISY admin console, choosing the device>settings. Blinking is not an inherent function of insteon and would require a program to accomplish. Is this important? Unfortunately, I cannot help with the Elk integration and things like "double F1" commands. Please clarify your question...are you wanting to create a program which triggers an elk action when any one of the multiple D buttons is toggled ON, and trigger a different elk action when toggled OFF? Is that your question?

User manual and wiki. You have already read the wiki. The user manual is available at the wiki. Beyond that, none that I am aware of. I go back to stusviews observation. The first question I ask is "why" do you want to use variables. Is this, simply, an intellectual challenge, a solution looking for a problem, or is there some task for which you believe variables are the only solution? Other than some pretty extreme stuff, it is my opinion that darn-near everything can be done without variables. Yes, they may make things cleaner and easier to follow at times, but you can do A LOT without them.

it might, if you have nested IF statements. We don't. However, understanding triggers and effect on wait statements, you could accomplish similar logic by: if open then run second program (then path) else nothing second program: if nothing then wait 15 minutes run third program (if path) else nothing third program (disabled) if open then wait 15 minutes notify else nothing

Wholly agree!

Are you asking how to create a variable, or where/why/how one would use a variable? I would expect that the starting point would be to create the variable.

dba62, While I agree with stusviews response (in regards to nested conditions as well whethernthis is a solution to your trigger reverse problem), the ISY does (in my estimation) provide sufficient flexibility and power to program the logic you propose. If you wish to discuss further, let us know. I definitely believe the best solution to a trigger reverse problem is to replace the sensor with one that works as needed for the application.

Rather than "status" as a condition, use "control". If Control "entry door sensor" is turned on Then Same.....

Being in a folder causes, basically, the program to be enabled or disabled, based upon the folder conditions. In your case, the program is essentially enabled at 10pm and disabled at sunrise. Only once enabled will the conditions trigger an evaluation and response. With "status" conditions, only a change of status would trigger an evaluation. So, at between 10 and sunrise, the program is looking for change in status as a trigger. If the status does not change after 10:00, it will never get triggered.

OK. Hopefully, I did not give you bad advice this time. As I asked before, also, make sure your motion sensor is not in any scenes.

Break it into two programs. Program 1 If From 11:00:00PM To Sunrise (next day) And Control 'Driveway Sensor-Sensor' is switched On then run program 2 (then path) else nothing Program 2 if nothing thenThen Set 'Outside: Garage Lights' On Set 'Outdoor: Front Porch Light' On Set 'Outdoor: Garden Patio Light' On Set 'Outdoor: Walkway Lights' On Wait 5 minutes Set 'Outdoor: Garden Patio Light' Off Set 'Outside: Garage Lights' Off Set 'Outdoor: Front Porch Light' Off Set 'Outdoor: Walkway Lights' Off else nothing When one calls a program from another program, one must specify what part of the program to run. In this case, I want it to run the "then" path. (Not the IF path. Not the ELSE path.)