oberkc

well.... Outletlinc Dimmer can be used as a control condition in a program. No, outletlincs do not emit any audible noise that I can detect. Certainly not the click sound associated with the higher-powered relays.

Thanks, teken. I will not need to check now. I will, however, check the dimmer outlet (I have one).

I will try to remember to check later today to see if the newer outletlincs have the control option. Will let you know.

The manual for this device describes only the process for making the outletlic a responder. This makes me suspect it cannot be a scene controller, which would explain why there is no "control" option for ISY programs.

I would have to research to be certain, but I fear that lack of a "control" option is an indicator that your outletluc is a model without the ability to be a scene controller.

Trojanhorse most likely found the root cause of your problem. I should have asked upon what evidence you judged the program not working. Sometimes, a program can work perfectly, but just not doing what you expect.

Is it possible that your program is disabled? Is your program in any folder? Could the folder be disabled?

Yes, I understand there is a lot of z-wave capabilities in v5, including z-wave direct scenes, but I have found zwave devices to work in insteon scenes (assumed enforced by the ISY since, obviously, no direct comms between insteon an zwave devices). I don't believe z-wave devices can be controllers in insteon scenes. I also understand that this capability may vary by device. I use z-wave outlets and modules and they all have worked so far. I don't think I have tried my lock in a scene.

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.