oberkc

I thought that one way to "directly" control KPL buttons from the ISY was to create artificial scenes, where in it is only one device (plus the PLM). Create, for example, a scene called KPL-B. In this scene, add button B only. You should then be able to control button B from the ISY (and, I assume, mobilelinc) by controlling the scene. Create such scenes for all buttons for which you desire such control and use the scenes in programs to simulate the action you desire. While I am not sure that it is easy to program the entire response to KPL-control of a scene (dim, bright, double-tap, etc), it may not be too bad to program simple on and off functions. Hopefully, this is responsive to your questions.

If not X-10 (and it still may be), it is also possible to have stray links remaining in various devices. I don't know the extent of you system or the amount of programming you have done so far, but sometimes there can be leftover links in devices. Factory reset would clear those out, as well. Once reset, I would confirm that the undesired behaviour no longer takes place. If not, add your links back and confirm that all is still good. If the behaviour remains gone, that is good. If it returns, I would take that as an indication that there are incorrect scenes or programs somewhere.

I have read reports of NEW KPLs with X-10 addresses. While this may not be your problem, it is pretty simple to check out and fix. I would not ignore the possibility simply because they are new.

It is possible that there are leftover X-10 addresses in the keypad buttons. If you are willing to start over, remove them from the ISY and perform a factory reset on the two keypads. Check to confirm you no longer have that unwanted behaviour. Then add them back to the ISY and add to the scenes. Check each step along the way to make sure the problem stays gone. While not conclusive, you may find it interesting to open the event viewer and press some of the offending buttons. See if you see any signs of X-10 activity.

I am not sure that I would consider this a simplification. If you want nothing more than to duplicate with ISY programs what can be done with scenes, this sounds more complicated to me. This also introduces a bit more latency into your system. Regardless, you would have to set up a program (or multiple programs, most likely) to use the remote link commands as conditions, and define actions based on those conditions. You would have to define actions based on each condition (on, fast on, dim, bright). So, yes, you would have to program each of these functions. You most likely would have to make adjustments to the existing scenes, otherwise the scene would continue to operate as it does now.

I think many of us use keypadlinc buttons as conditions for running programs...an away button, party button, late button, etc.... Use the folders and look for KPL button status would be a viable option.

I am not a programmer, either, but the ISY does most of this work. If you were unable to add a program control (or a status) based off the Dakota or the EZSnsRF (or a node in the EZSnsRF), then I am fresh out of ideas. I made the assumption that the EZSnsRF sent an insteon message, when it is triggered, that could be used as a control. If you want to perform an experiment, open the event viewer in the ISY and trigger a motion event at the Dakota motion detector. See what events happen, if any, as a result. This may give us more ideas how to accomplish your goals. I suppose there are options to change scene settings based on time of day, but this is contingent on device versions. It is also a major work-around, in my mind.

I understand, and agree with your perspective on wasted energy, and the limitations on scenes with regards to time. I still wonder about: 1. Does your Dakota not show up in your device (my lighting) list? 2. Can you not use the Dakota as a control in a program?

It sounds like your request has less to do with setting up a program and more to do with how to use the Dakota IR and reciever systems with the ISY. Looking at some of you previous topics and posts, it appears you already have the Dakota system linked with each other and with the ISY, correct? It also sounds like you have this already set up as a controller in a scene, correct? Does the Dakota show up in your device list? Have you ever tried using the Dakota as a control in a program?

Is the front porch lights controlled by the KPL primary load? If not, how is it controlled. How is the lamp controlled? Is it on a lamp module? Are you familiar with the signal recieved by the ISY when the dakota transmits a signal? I can only speak in generalities. One option would be to create a program folder, with the condition: if time is from sunset to sunrise, next day In this folder, put a program: If control "dakota IR reciever" is turned on then run program "porch lights" (then path) Not in any folder, create a program called "porch lights": If then turn on porch lights turn on living room lamp wait 15 minutes turn off porch lights turn off living room lamp else These are generalities with code that is probably not to exact ISY verbage, but perhaps that will give you some ideas to solve your problem.

If you are happy with the current "kitchen is Dark' program, then I would use it in place of my suggested program (dusk to dawn). The only thing that jumped out at me is the possibility that turning the lights on would then cause your kitchen dark to change states. I don't think this will cause problems in your current situation, but it is something to watch out for. I am still a little surprised that sub-routine's suggestion did not work. He states that folder conditions (and I assume he means whenever a folder changes state) triggers a program. He did not state specifically that program changes-of-state trigger programs, but I would have assumed that they would as well. In my set up, I have not had the need to use this capability, so my knowledge about such things is based only what I have read. By chance, when you used Rand's suggestion, you did not happen to have your program inside the 'dinner 830 to 930' folder? If so, this could, in my mind keep your program from running when dark occurs before 830. If you did, I would try it again, ensuring that the program was outside the folder.

I don't use a lot of "true" statements, so I can only speculate without further experimentation, but it sounds like "true", as a condition of a program, also acts as a program trigger at the transitions, and perhaps not at all. The conditions: "from...until", "time is..." "control....", "status..." all act as triggers, so I can only surmise that it might be necessary to include on of these in your program. Since I am also curious as to the behaviour of these, I intend to check out when I get more time. I am also unsure how you define "dark". Is this an input from an Elk security panel? If so, I understand this to be sunset. It sounds like we must concern ourselves with two possibilities...one, if dark happens before 8:30, the other if it happens after 8:30. Until we can come up with something a little more efficient, try a brute force method: Create a time folder, with condtions being time is from 8:30 until 9:30 (same day). Create a program, called dark (or whatever), with your conditions from sunset until sunrise (next day), with no actions. This program should reside outside your time folder. Create a second program, inside your time folder, that looks like: If ( program "dark" is true and time is 8:31 <<) or time is sunset then Set 'Kitchen Counters' on This should get you pretty close until I can look into other options. Realize, of course, that your lights could come on up to a minute late under certain conditions.

I suspect that sub-routine had it nailed. I suspect you are seeing the difference between "status" and events that trigger an action. That is, when is a condition evaluated that will cause it to execute the program and choose the "then" or "else" paths? The condtion "kitchen is dark" is evaluated only when it changes from dark to light and from light to dark. As I understand it, these are the points in time, and the only points in time, where the program would execute. If you put it in a folder that is valid between these points-in-time, then the program will neither evaluate itself, nor executre. The folder condition, itself, never triggers a program. It only enables programs. It is only the conditions within the program, itself, that cause a program to run. For example, assume the light to dark transition happens at 7:00p and the dark-to-light transition happens at 7:00a. You then this program into a folder based on the condition that the folder is true between 8:00p and 9:30p. This program will never run. The folder conditions do not force an evaluation of the program. The program conditions fall when the program is disabled, due to the folder conditions. I hope this was of some help.

I think I have noticed a few, but there is a reason that most of us know the meaning of "WAF".

I am sure that you were right, but just haven't come up with a good explanation for you wife. Remember, between the husband and wife, the husband is always right. Also remember, what is said in the forum stays in the forum.

First, confessions. You already appear to me to be a more advanced programmer of the ISY than I. Still, I wonder if.... I like the idea of putting your program in a folder that is true only if your light is on. The missing part of that equation, however, may be to remove the blinking program steps from your "then" path and putting them into a separate program without "if" conditions. This new program should not be in the folder, so that once it starts running, it is not affected by the condition of the garage light. Something like: Folder condition If garage light status is on Edited program, in the folder If On Mon, Tue, Wed, Thu, Fri Time is 8:00:00AM Or Time is 1:00:00AM Then Run New Blink Program (then path) Else - No Actions - (To add one, press 'Action') New Blink Program, not in the folder: If Then Disable Program 'G light scene' Repeat 2 times Set 'Garage Light' Off Wait 1 second Set 'Garage Light' On Repeat 1 times Enable Program 'G light scene' Wait 1 second Run Program 'G light flag' (Else Path) Wait 1 minute and 15 seconds Run Program 'G light turn off' (If) Else - No Actions - (To add one, press 'Action')

Yes, that it a reasonable understanding by a reasonable person. If I recall correctly, however, the ISY also has a condition "not off". So, you have the ability to have a condition of "on" = 100% and "not off" = 1% - 100%. Pick one that meets your needs.

Perhaps you are correct. I was not at my ISY to confirm. Instead, if you prefer to avoid the folder approach: On Mon, Tue, Wed, Thu, Fri Time is 6:50:00AM AND Time is from 0001 to sunrise+30minutes (same day) It sounds like this is going to get solved.

As I understand "from/to", the program will execute the "then" condition at the from time, and the else condition at the to time. Given this, I don't think you need to use the from/to condition. How to you turn off your scene? Manually? If you are not going to use this program to turn off the scene, then I think you can achieve your stated goals by: if On Mon, Tue, Wed, Thu, Fri Time = 6:50:00AM and Time before sunrise + 30 minutes (same day) Alternatively, you could create a program folder that is active from some early time (say 0300) until sunrise + 30 (same day) and put the following program in it if On Mon, Tue, Wed, Thu, Fri Time = 6:50:00AM I hope I am not missing something.

I agree with apostolakusl....I think we need to make sure we understand when, or if, your various programs trigger. He has in interesting thread on this. Check it out. How is it ever set to true? The only listed examples set it to false, by running the else path. When DO you expect it to get evaluated, if ever? I would expect it to be evaluated every day at 11:18p (since it is partly based on "front final shut down", which is evaluated every day at 11:18p. No, the state TRUE does not change, but it is evaluated). I would expected to get evaluated any time the folder changes state, which I now understand is the result of a switch. Unfortunately, since that same switch disables/enables the folder in which the program resides, I am not sure that this evaluation will happen. This is a least part of the "confusion" mentioned by apostolakisl, I believe. The only action in Re Dim Final (when evaluated true) is to run "front Final Shut Down (then path). Since "Front Final Shut Down" runs on its own at 11:18p, the call out from Re Dim Final appears redundant, at best. When is it that you believe this program (Re Dim Final) will trigger? Have you checked the event viewer to confirm? You state that there are five programs in the ReDim folder. I note only one program highlighted as being in that folder. Are all the other listed progams (Front Final Shut Down, Front 4 level, others not listed) part of this program as well? This may be a timing issue. Unless the folder is true, these progams are disabled. I am unsure about the timing of events, but I assume this condition first makes the folder true. Once the folder is true, the event has already passed and will never force an evaluation of the conditions of the programs residing in it. This is how I see it. The problem that I see is that running the front final shut down makes the parent folder false, which suspends any further activity of programs within. As such, it will never continue past the first then line of your "Re dim Final" program. Perhaps that is the heart of the issue. I think I may be repeating myself, but this may be what is happening. I cannot help but suspect that there is an easier way to do this, but the relationship between your alarm system and other programs is still one that I don't understand.

No you don't have to buy the module. I did, however, and like the ability to stay organized. You can give names to X-10 codes, and they show up in your 'my lighting' tree. I no longer need to keep track of these on a spreadsheet.

It is not required.

Wow. You spin a complicated web. I am not sure that I am able to sort through what you have, and I still think there may be something missing. I will offer some thoughts and, with luck, this may help. Regaring your "Re Dim Folder", the condition of this folder is based upon the condition of a program "redimswitch". I don't see this program anywhere. What is in it? When is it true? When is it false? Regarding program "Re Dim Final", there is a condition, "if folder 'Re Dim' is True'. Since this program already resides in the folder, it won't run unless the folder is true by definition. I conclude that the stated program condition is redundant. Why is it there? Is it your intention that the change in status of this folder trigger the program to run? In this same program, your second condition is that "Front Final Shut Down" is true. As I understand conditions, this program will ALWAYS be true. This program will be evaluated at 11:18pm and show true. It will remain true until it is evaluated again. It will be evaluated again in 24 hours, at which point, it will still be true, etc.. Without knowing the conditions defining the status of the folder, itself, I am not sure when to expect this program to run. It may never run. In this same program you run "front final shut down" then path. This appears to have the potential to run twice, simultaneously, at 11:18pm (since the next program will trigger the then path at 11:18p). I am not sure about the consequences of trying to run the same program twice, but I am not sure why one would want to. I see nothing in the remaining two programs which, by themselves, cause a problem. I noticed that you moved a line in a program because it never executed. Is it possible that this whole program never executed? Why would the first line execute and not the second? Again, is it possible that your conditions are never evaluated as true? It is possible that you have commands running in the ReDimSwitch" or "Front 3 Level" programs that are causing loops, but they are not listed so I cannot offer any comment. Sorry I cannot offer more. If you care to post the contents in the other programs, I may be able to see something.

It seems to me that if you have a program "front 1 level" that has conditions in which it can be true or false, the then path will run any time it becomes true. The set of code you quote would run the same set of commands again, so long as the both conditions are true. Yes, it seems like a potential for a loop to me. Before reaching any conclusions, however, I would like to see your entire front 1 program and the conditions of your dim folder. Is is possible that your front 1 program, itelf creates a loop of some type? Does the actions in the program cause the conditions to be re-evaluated?

Not true, as I understand your question. While it is true that you cannot incorporate X-10 addresses into scenes, you can set up a program to turn scenes on and off, etc. A typical program may look something like: if x-10 A6 is turned on then set scene "bedroom" on You could create a scene to include all your lights, then a program if x-10 a6 is turned off then turn scene "all lights" off