oberkc

OK, I think I have mine working. Once I have identified devices (v.35) and scenes that respond to local changes from the ISY, I was able to establish a program that does what I think we are both trying to do. That is, to write a program to establish different on levels when run. I wanted the on levels to be the same, regardless of which of the two switches were used to initiate the scene. As a little background, I have a scene much like yours with one light and two switches. One switch controls the load, the other is the slave, as you call it. The scene is called "Kitchen overhead", the two switches are "SW KTC Overhead Main" and "KTC Overhead Slave". The then action is: Then In Scene 'SW KTC Overhead Main' Set 'SW KTC Overhead Slave' 40% (On Level) In Scene 'SW KTC Overhead Slave' Set 'SW KTC Overhead Main' 40% (On Level) In Scene 'SW KTC Overhead Main' Set 'SW KTC Overhead Main' 40% (On Level) In Scene 'SW KTC Overhead Slave' Set 'SW KTC Overhead Slave' 40% (On Level) I made no attempt to adjust ramp rates, but that would be a simple variation of this theme. Assuming that you have devices that respond properly, and assuming you are trying to reach the same goals, your program should look like: In Scene 'master' Set 'Master' 50% (On Level) In Scene 'master' Set 'Master' 4.5 Sec (Ramp Rate) In Scene 'master' Set 'slave' 50% (On Level) In Scene 'master' Set 'slave' 4,5 Sec (Ramp Rate) In Scene 'slave' Set 'Master' 50% (On Level) In Scene 'slave' Set 'Master' 4.5 Sec (Ramp Rate) In Scene 'slave' Set 'slave' 50% (On Level) In Scene 'slave' Set 'slave' 4,5 Sec (Ramp Rate) This is, obviously, a lot more complicated that in your referenced thread. The differences are that they had only one controller, and they attempted to change only one attribute (brightness level). In your original program, you chose the master scene, rather than the individual controllers in the scene field. This is where I think you diverged from your quoted example. I am not sure what you mean by "reset" the switch. Do you mean restore? I would not expect this. My perception is that any adjustment one makes to the scene attributes is instantaly transmitted to the insteon device without requiring a restore. In fact, I tried a restore on my troubled devices and this failed to change any switch response.

I have experimented around on my setup. I have several scenes similar to yours in that there exists two controllers with one of the controllers powering the fixture and the other a slave. I added a test program to adjust on values and ramp rates. As an experiment, I manually ran the "then" path and confirmed scene porperties changed as expected, then manually ran the "else" path and confirmed expected changes. According to the ISY display, all worked as I expected. Then, I went to see if the new ramp rates and on levels were active in the switches themselves. THEY WERE NOT. Despite the ISY showing both scene and local on levels being 100%, they continued to turn on only to the original on level of 40%. OK, I thought, maybe I am missing something. Rather than relying on a program, I attempted to manually adjust the on rates from the admin panel of the ISY. Same results. I could not get the switch to go to full brightness. Out of stubborness, I tried this on another scene with two controllers, one primary and one slave. I found success here. I cannot explain why this worked once and not in both cases. I recall a lot of discussion about how different versions of insteon devices have different capability. Older devices may not support certain feature, but I don't remember the details. According to my admin panel, the version of the switch that I cannot program from the ISY is v.27. It is a relatively old switch. The switch I COULD get to work is v.35. I am starting to wonder if the ability to program the switches is limited to certain versions of the switch. Which versions are yours?

Being interested in trying something like this myself, I started playing around with the "adjust scene" action. In the "in scene" field, I notice that one can choose scenes, or devices. In your case, I wonder what would happen if you change your then (and similarly for the else) construct to look something like: Then In Scene 'master' Set 'Master' 50% (On Level) In Scene 'master' Set 'Master' 4.5 Sec (Ramp Rate) In Scene 'slave' Set 'slave' 50% (On Level) In Scene 'slave' Set 'slave' 4,5 Sec (Ramp Rate) It sounds like you have tried a lot of different options already, perhaps including this one. I look forward to hearing from the experts on this. I am going to try some things myself and will let you know if I can make this work.

I am simply making a guess here, but there are different ramp rates, depending on whether you speak of local control of a given device, versus control of a scene from one of the scene controllers. Are you trying to control a scene or a local device? Is the switch you control set up as a scene controller? I like your ideas, and it has inspired me to try something like this myself.

Good news on your new program. The one consequence to be aware of is that if you ever happen to use the individual controls to set the dim levels to exactly 40 and 30 percent, then the KPL will come on. Perhaps that is good? It is my understanding that all programs run all the time (unless disabled). I don't see why this one would be any worse than any other. It is looking for changes to the input conditions. When it sees them, it reacts per the if/then actions. I would expect no unique problems with added powerline communication traffic. I am not sure what program uses your "living room" switch. Is this a different program? When you refer to "adding" the familly room main, do you mean adding to a program, or to a scene?

Despite the definition of control versus status, I continue to be amazed at how many times suggestions on this forum are opposite of what I would have assumed. Back to your problem, I started to think your program is turning off your keypad before the scene is fully engaged. Do you suppose this is possible? I don't understand how long it takes a scene to react versus a program, but I suspect your program itself is acting quicker than the scene. What would one simply looked at this more simply? If 'Family Room Main' is 40% AND 'Family Room Recessed' is 30% Then Set scene 'MovieStatus' on Else Set scene "MovieStatus" off Would this achieve the results you are looking for?

I still remain uncertain about the differences between control and status. I recall some discussion about how one sends an on the off status. Since it is so easy to experiment, I would change the input condition from status to control and see what happens. As a troubleshooting attempt, I would also open the event viewer and watch the signal traffic as things happen. This may give a clue as to why your KPL goes off after a short time. Sorry I could not be more help. I will think more about it.

This approach sounds like it might be incloude some unintended consequenses, but that is only a gut feel. I don't know enough about the inner workings of the ISY to help much. As much trouble as I have had getting exact dimming values, I would first check to see if you have not accidentally set 39% or 41% as the programmed dim value and confirm that, in fact, 40% is the posted value when the movie scene is triggered. Assuming all is good.... Your program may need a couple of parentheses in it. Based on my understanding of boolean logic and your program, the first two conditions are evaluated as a group, with the third condition evaluated independent of the first two. Your progam may need to look more like... If Status '06.6E.FB.D KPL Movie' is not off and ( 'Family Room Main' is not 40% or 'Family Room Recessed' is not 30% ) Then Set scene 'MovieStatus' off Also, what are your ramp rates? Is it possible that a slow ramp rate would cause this program to evaluate mulitple times over a short time period?

You say that the device will run scenes on all buttons but that the ISY does not recognize it. How did you set the scenes up if the ISY did not recognize it? Did it once recognize it but now it does not? At the risk of sounding stupid: a. did you set all scenes up using ISY or did you create some directly with the devices? b. is it possible you changed the configuration of the switch from 6 to 8 key configuration after it was linked to the ISY? c. what buttons are now showing up in the event viewer, all eight or just the four you mentioned? d. have you added some new electronic device, appliance, or charger to you house since this was last working?

One has to reprogram them from one type to another. The steps are in the instructions, available online from smarthome if you have lost them.

Hopefully, the suggestion to use status, rather than control, is a quick fix for you. If it were me (having a vague understanding of the difference between the two can mean), I would be tempted to play around some to get a better understanding of how these motion sensors work. I would take the motion sensor down and bring it to the room where the computer is visible. Open the ISY admin box, then open event viewer. From there, trigger some motion in front of the sensor and see what kinds of signals it transmits. You can also see what kind of responses the ISY gives. Find out where the command to turn off the light comes from. Is shutting down before turning on the normal response of a device when it recieves an on command when it is already on? Another option to consider it to use the ISY to turn the lights off after motion sensed. Simply put a five-minute wait in your program, then send an off command. You will need to address the possibility of sunrise occuring during the five-minute countdown, but this is pretty easy to solve. There is a very interesting discussion of motion sensors in the UDI Wiki. Check it out. There are many threads on this topic in the forum here.

It may help to post your ISY program to be able to determine if it is a bug or program fault.

There is a post about this in the X-10 forum under the index. It is the sticky one on top. I understand the X-10 support is an add-on module. One requires, however, v2.7.7 to be able to access the module. I was unable to get the module on 2.7.6.

Assuming one has downloaded the add-on module, from the admin console showing your main tab, choose: link management>>new insteon/a10/x10 device In the pop-up window, give your device a name of your choice, in the address field, add house code and number (example A12), in the device type choose generic X10 device. Worked for me. You can move the new device to folders if you wish. In programs, the device name shows up in conditions and actions. I understand you cannot use X-10 devices in scenes.

I may not be a lot of help, but I can at least confirm that it is possible. I have two scenes involving the same devices, and the transition is as you desire. We at least know it is possible. I guess the trick is to figure out how yours is set up differently than mine. Perhaps a few more details about your installation would help. Are you using an ISY? What device is controlling the kitchen light? What device (keylinc? keypadlink?) are you using to initiate the scene? Are you using the ISY to establish all these scenes?

I think the simple solution would be simply to create a program to perform the actions you want, then enable or disable the program as your needs apply. This would avoid having to rely on a KPL button. I have a "guest" scene that I control in such a way.

I see no v at the center/top of the Admin Console. Mine says "13.F6.8A - Unsupported Device:2.6".

I can confirm this being the case. I used capital letters, no spaces, in the address field (example "A8"). Once done, the x-10 devices shows up in the device list. I can move the x-10 devices to room folders and I can use them in programs. I cannot use them in scenes, which is consistent with my understanding of the design intention.

I have recieved mine and it appears to work just like any other insteon module, with a couple of extra options, including ability to disable the load sense. The current draw, when off, appears to be lower.

I upgraded without problem. This allowed me to download X-10 module without apparent problem. The thing I observe immediately is that each time I log onto the admin console, there is an initial time period where the system gives a busy indication with the percentage bar showing in a dialog box. During this period, much of my system turns off. This did not happen in 2.7.6 or earlier, as best I can remember. I find it a nuissance to have my lights turn off as a result of opening the admin console. Hopefully, this is a result of something I did, rather than a characteristic of the new version.

While not quite as elegant, I have one of those X-10 key fobs that would work well. Unfortunately, it would require a manual press of the button. I would imagine that those are still available and pretty inexpensive.

I assume the lamp is controlled with a plug-in module? My experience is exactly as described by the others. Communication problems cause errors when adding devices to scenes. To confirm, you may wish to try moving the newly-introduced lamp module to a different location. I suggest a location close to the access point you are using. Once there, try again to add it to a scene. Hopefully, you will find that the ISY can now add the device to the scene. If so, you have almost certainly identified communication as your problem. Then you get to enjoy identifying the culprit(s) behing your communication problems.

Around 3000K is pretty close to incadescent, or soft white, based on my visual assessment. 5000K is pretty stark. over that, and it gets to near daylight. Regarding the elimination of incadescents, I understand that this is not a forgone conclusion. The new law requires certain efficiency, rather than banning specific types of bulbs. I also understand that there will be new-and-improved incadescents that will meet these new requirements.

I am not sure that I follow this statement. I have several programs which turn on and off scenes. Are you saying you could not find a way to use this program to set a scene to off?

That sounds like the same problem I had, which was corrected in a later version (2.7.4, I think). I suggest updating your software.