racekarl

Thanks for your help, Stusviews; that's pretty much exactly what I have. Seems like I'll just live with the way it works.

Here is what I would like to accomplish: I have two banks of recessed lights in my room ("near" and "far"). I would like to be able to turn them both on using a single "both" button on a keypadlinc, but also be able to turn them on and off separately. If both banks are lit, I would like the "both" button on the keypad to light (even if it was not used to turn on the lights) and if one or the other bank is turned off, I would like the "both" keypad button to extinguish. This both button should of course be able to turn both banks on and off together. I have gotten this working using programs to track the state of the lights and set the correct state on the keypad, but it's slow. When I press the both button there is a delay of about a second before the first bank comes on, then another second before the second bank comes on, with a similar delay when turning the lights off or when updating the status of the "both" light. The delay seems to correspond to the status LED flash on the sending switch, so it seems like the switches don't talk to the PLM until after they send their scene commands. My question is this: is there a way to accomplish what I want to do using scenes and without the programs? If this were all scene based it would both be faster as well as continue to work without the PLM or ISY.

Teken, Here's what I have currently. I am by no means an expert, but so far this seems to do what I want. I have two corresponding programs, one that runs at sunrise to set the LED level to off when the linked scene is off, and to a "medium" brightness when the linked scene is on: The companion program runs an hour before sunset to turn the off level of the LEDs to the minimum brightness when the linked scenes are off and their maximum brightness when the scene is on (on brightness is relative to off brightness as Lee noted): Given that's I'm running 4.0.5 I can not ever turn the LEDs completely off when the corresponding scene is on, which is fine for my purpose, but with 4.1.2 if that's what you want to do, set the brightness to 0/0. Note that I'm setting these brightness settings on the KPL6's large buttons (which are in non-toggle on mode, so that when the linked scene is off, the "All off" bottom button does not light). This seems to affect all the sub buttons globally, which is what I wanted.

Lee, Thank you very much, I just sat and played with the backlight levels on my KPL6s and I think I'm getting it. So, when you say the Off level is about 8 steps below the on level, are you referring to decimal numbers? Any setting I put in with off = 0 results in the LED being off all the way up to On=15 (which I assume is hex F). e.g. 01 - 0F = LED is not lit when OFF, 15* small increments of ON brightness above that 10-1F = LED is lit at minimum brightness when OFF, 16 small increments of ON brightness above that *00 is treated as a special case Is that generally correct? So if I understand this thread correctly, the change in 4.1.2 is that 00 now will have the LEDs off in all situations as opposed to today (4.0.5) where 00 results in some factory default brightness setting? Does that also mean the 1x is results in the minimum LED illumination when OFF? If true that's a minor disappointment since it's still a bit brighter than I'd like. Thanks again!

Thanks for the quick reply Lee, but I admit I am still confused. If those settings combine to create a "percentage of on" when is that percentage adjustment applied? Is that to say that the on brightness is fixed, and these two settings combine to set the "off" level as a percentage of the fixed on value? What I would ideally like to do is create a program so that during the day, the off level is off (no light) and the on level is pretty bright (so it can be seen in daylight). At sunset I would like the off level to be dim but noticeable so that people can see and read the buttons, and the on level to be probably a bit dimmer than the daytime on level. Sort of like how the dashboard lighting works in most modern cars. Thanks

Michel, I also wanted to say thanks for the fast response to this, it's neat to see how the ISY has evolved even in the short time I've owned one. The strange thing for me is that I already seem to be able to completely turn off the LEDs of my 6 button KPLs, even though I am still on 4.0.5, but I seem to have only very limited (binary) control over them. Unless I am missing something, setting the KPL6 main device to "non-toggle On" in the ISY, then setting the LED brightness Off level to 0 allows all the buttons on my 6 button KPL to be off when all linked scenes are off. I even run a program to turn the LED brightness Off level to 0 during the day and 1 at night, which works as expected. The thing that puzzles me is that no matter what numerical setting I use, I cannot change the apparent brightness of the buttons. Any number greater than 1 lights them dimly in the Off mode, and similarly any number greater than zero lights them a little bit brighter in On mode, but there is no variation in either brightness based on the numbers 1-15 for either on or off mode. I've tried setting the overall device brightness as well as individual buttons, but the effect is always the same.

Yeah it's bizarre. I currently have it set up so that the swtichlincs are scene responders only, so if I use them directly they turn their loads on and off but send no signals. Using this set up they work as expected, with the obvious caveat that the KPL LED backlights do not reflect changes made at the switchlinc directly. This is OK for me since the switchlincs are basically inaccessible (I kind of wish I had just installed in-linelincs there) So I think the conclusion is that there is a communications issue related to the wiring of the switchlincs. They appear to work fine when used exclusively as a controller, and when used exclusively as a responder, but when they are configured as both, they go berserk. I assume that when they're doing double duty like that they have to send and receive more information over the wires and RF and that this causes the wiring/communication issue to become visible. For now I think I'm just going to leave it as it is - it works well enough for my purposes, and as I said, the switchlincs are in a dead-end corner behind a table (the door to the room was moved and they were orphaned) so it's unlikely anyone will go mess with them.

I'm pushing the internal momentary buttons of the switchlink with the tip of a screwdriver because I had removed the switch paddles. Before installing the switches I had replaced the switch paddles with custom-etched ones. I suspected (based on a comment earlier in the thread) that perhaps I had installed the new paddles incorrectly and as a result they were getting stuck or something and causing the switch to send spurious traffic. So I removed the paddles from the switches to eliminate them as a potential cause of problems. Without the paddles in place, I used a screwdriver to gently depress the internal momentary button. The result was the same as with the paddles in place, allowing me to eliminate them as a potential cause of my problems. Make sense?

Bad news: when I pressed the buttons with the tip of a screw driver I got the same behavior I've been seeing, so I have a wiring or communication issue. So, what is the next step I should take? Pull them out and check the wiring (e.g. make sure the wire nuts are tight, etc?) I'm curious why the switches behave fine when they're only in a single scene each as controllers, but then misbehave when they're added to another scene as a responder (and then only when their buttons are pressed directly)? I guess the signals they try to send are different or something based on scene membership?

Indeed! I ended up having the same problem on the other switchlinc, so I pulled both faceplates (the buttons did indeed feel a little mushy and I didn't hear or feel the "click" like I usually do). So far everything works perfectly as long as it's controlled from the KPLs. Later today I'll try pushing the buttons in the switchlink with a little stick or something to see if they work as expected. If that's the case then it was bad paddle installation, otherwise it would be a communication issue and it's on to the next step of debugging.

Thanks for the input, I am pretty comfortable with wiring so if needed I will definitely pull the switch out. The electrician was very familiar with Insteon, it's part of his specialty; the main reason I hired one as opposed to DIY was that the previous electrician had done very shoddy work in this room and I didn't feel comfortable enough to try to fix it. I've never controlled any of these lights from the ISY, I only used it to manage the scene creation for now. As I understand it, all of the scene data gets saved into the devices themselves, which are then communicating with each other, is that right? The room is about 20x15 and all devices are dual band, so in theory they could talk to each other via RF as well, right? I have tested the scene a few times without the ceiling switchlinc being a part of it (I removed it from the scene and it currently has its air gap pulled out) and it works perfectly, so that switch does seem to be the offending party whether it's because it's wired wrong or maybe (hopefully!) because the switch padddle is installed incorrectly and is keeping the button pressed. I'll report back as I do more experimenting. Thank you very much for your help! I have been very impressed with how FAST and high quality the responses on this forum have been.

Huh, there are a *lot* of other things on the same circuit with the smokes, not just these sconces. Seems like it was built that way, maybe code was different circa 1990 when this place was built? Anyway, more info to report - the plot thickens: I set up my "All" scene as before, although this time I added the KPL buttons as well so they would light up when the corresponding loads were on. I go into the room and try to turn off the ceiling lights via their load controlling switchlinc (I don't remember turning them on, but maybe I did inadvertently when creating the scene). So I push the bottom of the paddle the turn the lights off and the LEDs travel to the bottom and begin flashing rapidly, and the load turns off. I turn it back on again and the LEDs travel to the top but are still flashing, as are the load lights themselves. I turn them back off, LEDs go down but still flashing. I opened the event viewer and unsurprisingly there is my switchlinc flooding the lines with thousands of DOF commands: Fri 06/21/2013 10:06:07 AM : [ Switclinc.Address ] DOF 1 I pulled the air gap and now that traffic has disappeared. I DID change the faceplate to a custom etched one, so I think my next two steps are 1. See if the scene works otherwise without that switchlinc participating in it 2. Pull off the switch paddle and see if the problem still persists after I add the switchlinc back to the scene

OK thanks, that is much clearer. I realize I still may have a communications issue, but it seemed worth asking if I had done something obviously wrong with my set-up since that's an order of magnitude easier to fix. I'll set the "All" scene back up today and let you know how it goes - the three way scenes are working perfectly so hopefully it was just some sort of transient gremlin. I dread having to deal with a signal issue on this circuit - when the previous owners re-configured this room the genius who wired it stole power for the sconces off the circuit that the smoke detectors are on, and they talk to each other over the powerlines as well, right?

Thanks, the mashing was not programming, just trying out my scenes that I created in the ISY (i.e. I was mashing the keys of the switches to turn the lights on and off and verify that the lights turned on and off, etc.) What do you mean by other KPL buttons added as responders? Are you saying that I should add the other KPL buttons to the scene in place of the actual load-controlling switches, or in addition to them? If it's the latter, what is the point of that, to get the LEDs behind the buttons to light up?

Thanks everyone for the rapid responses! What I meant was that after mashing KPL buttons for a while (not totally sure what I did - turning scenes on and off, dimming lights, etc.) I went over and started flipping the switchlinc switches up and down and soon everything got sideways - lights would not turn on or off and LEDs on switchlinc were flashing wildly. So, what I did was delete everything from the ISY, factory reset everything, then re-added it all to the ISY. I've now re-created the basic "Three way" scenes and they seem to work well: Ceiling 3-way scene: - "Ceiling" Switchlinc with attached load added as controller - "Ceiling" button on KPL 1 added as controller - "Ceiling" button on KPL 2 added as controller Scones 3-way scene: - Sconces Switchlinc with attached load added as controller - "Scones" button on KPL 1 added as controller - "Sconces" button on KPL 2 added as controller Lamp 3-way scene: - Lamp Outletlinc with attached load added as responder - "Lamp" button on KPL 1 added as controller - "Lamp" button on KPL 2 added as controller I've tried turning these scenes off from all three controls (both KPLs and the Switchlincs) and everything works as expected - The LEDs all reflect the current state of the load, I can turn the lights on and off and dim from any controller and all is happy. So now, I would like to get the big buttons of the KPLs set up so that if I push the top "All on" button of either KPL all the lights in the room turn on, and if I push the big bottom button of either KPL all the lights turn off. Ideally I would also be able to hold these buttons and raise or lower all the lights at once. So what is the correct way to do that? For background: all three loads are regular incandescent bulbs, everything was installed today by a professional electrician (the wiring in this room was a horror show and needed to be fixed), and everything was purchased new from Smarthome last week, all are new dual band devices. All linking and scenes were created in the ISY, none of these devices participate in a program.