oberkc

You did not provide a lot of details, so I can only suggest some general ideas. I am assuming that you want your scene to come on at a fixed time, and off six hours later, correct? First step I would consider would be to use a program as a condition, such as: if time from on time - 1 minute to off time + 1 minute then else I would then create a program such as if condition program is true and ( time is on time or control switch A is turned off or control switch B is turned off or .... ) then turn scene on else turn scene off There are probably more elegant solutions, but perhaps a concept such as this can be made to work for you. Better yet, maybe this can give you a start on your own thoughts.

I don't believe inlinlinc dimmers can be controllers, since there is no physical way to turn one off or on. A switch, on the other hand, has toggles or rockers used to turn the device on. The inline linc device only controls a load, and activates only inresponse to an insteon signal. Install it as a responder, with your actual switches as controllers, and you should be ready to go.

I also don't know which "starter bundle" you purchased for your friend, but if it does not have access points, and if they are not properly installed, you increase the risk of he being less impressed than you desire.

Programming an insteon network without an ISY is not overly difficult in concept, but can surely take much more time and button presses. I found the intructions to be pretty clear...to create a controller/responder relationship, first put the controller in linking mode, then the responder. Putting a device into linking mode usually entails a press and hold of the switch. Of course, as scenes become more complicated and with multiple controllers, one can spend a lot of time running around the house, cross-linking, and creating multiple controller/responder relationships. So, it is not at all difficult to learn the process but sure can take a lot more steps. In your case, with the devices all movable, you can avoid much of the running-around-the-house part. Like you, I have become dependent on the ISY and would probably find it overly difficult to program my current scenes. Without it, my insteon system would have ceased growing many generations ago.

I understand that this would not work, at least not without some broken links. I believe that, when programming scenes through the it, the ISY/PLM will be part of the scene just like any other insteon device. Subsequent relocation of devices without moving the ISY/PLM will result broken links and failed acknowledgements and general misbehaviour.

I understand that some battery-operated insteon devices don't respond to queries or to other insteon commands. Is it possible that such a limitation has an effect on ISY-displayed status?

I don't, because I don't like the hum that comes from using dimmers.

I disagree. I thought you did a good job explaining this originally. And I agree. I don't think that such a program would be very elegant or efficient. I was also unaware that there was any way (besides mutually exclusive relationships) to define a scene where turning a controller on would result in a responder turning off. I have found this to be true whether programming scenes in the ISY or manually. It sounds like you have found a way? I assumed that this is a feature of the insteon protocol.

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.