oberkc

The ability to set these parameters differently for the primary scene versus the individual controllers allows flexibility to have different responses depending on which controller is pressed. The primary scene parameters is, I guess, the parameter executed when controlled by the ISY itself. I have found a bit of a learning curve in programming the ISY, but once you get used to the idea of cut-and-paste, updates versus adds, the actual creation of these type of repetitive-lined programs can be done pretty efficiently. I guess that would explain my issues with older devices and confirm the recollections of Quixote. Thanks.

Hopefullly, someone can offer suggestions based on those specific error messages. Unfortunately, they mean nothing to me. Sorry. I assume that your scene tests failed? I wish I could give come up with any new ideas, but I am sure you by now you know the routine trying to identify problems with communication and all the normal kinds of questions to ask. Not fun.

I do not expect this to help. Capability to adjust on levels and ramp rates came in 2.6.7 Regardless, I have never had trouble updating. I recall it simply a matter of going to the posted link and saving the zip file at some location that you can remember. Once done, go to the admin console, under the help tab, choose "manually upgrade my lighting". After the appropriate response to the prompts, locate the zip file and the ISY will take care of the rest.

Consider it confirmed. I am able to manually adjust ramp rates without pulling the tab, and can do so in a program.

I believe that is incorrect. I am able to change ramp rates without pulling the tab. That is part of typical setup I thought....link devices to ISY....add to scenes....change scene properties, including ramp rates. All this is done without pulling the tab in my experience. In my experimental program, I was able to change on levels without pulling the tab. I admit, though I did not try to adjust ramp rates. I will try and report back.

comminication problems? Have you tried a scene test on your troubled scenes?

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.