oberkc

So you already have programs that do things. I was a little confused. I thought you used scenes. I suggest re-reading the post from Sub-routine. You might find his approach even better than using controls and programs. Using scenes would give you a perceptibly faster response to button presses. There is a little delay with using programs. I assume that this is due to the extra communication associated with programs and in the time it takes to execute the program, itself.

You are correct. This is, I believe, a presumed status on the part of ISY. I don't believe the actual device has a status and understand it has no bearing on the function of the remotelinc. Neither will it have any affect on controlled devices (after intial scene activation), unless you use this condition as part of a program. I continue to maintain that turning your remotelinc off to be an unecessary step.

I don't believe this is true. Remote linc buttons have no status, in my mind. They simply send on and off commands, depending on which side you press. If you press button 5 on, go to another scene, then press button 5 again, then scene 5 will come back on.

I like this solution for those who value highly the quicker reaction of a scene compared to a program. Keep in mind, however, that the ability to set on levels without a manual reset is not present in some of the older insteon devices. I cannot say which version incorporated this feature, but know that I can do this with some of my devices, and not others. My oldest are around three years old.

I cannot turn off the LED at all , ever eithe manually or via software So, you have created a scene with only the keypad button in it, but turning the scene off (either manually or through a program) has no effect. Maybe you are having communication issues. How many insteon devices do you have. Do you use access points or similar? Do you use any filters? Is you computer system on a UPS or conditioned power? Is your ISY/PLM in the same outlet as your computer system? My next temptation would be to perform a scene test on that scene to see if there are any indications of communication problems. This is available under diagnostics. Try it on this scene and on a few others. Do you see any indication of failure? The only other thing that I can think of is the possibility that certain versions (older) may not have the ability to respond in such a manner. I know that the backlight of older KPLs cannot be remotely dimmed. Perhaps this is available only in newer generation switches. We do know that MikeB can control his backlight in this way, and that I was able to do so as well. My KPL was about 2 years old.

I don't have the insteon motion sensor. Mine are X-10. Much has been written about the insteon version, though. I don't see why this is necessary. I also understand that the sensor does not respond to insteon commands, only sends them. Based on what I have read, the insteon motion sensor sends an on command any time that it senses motion, after it has reset itself. I understand that there are various jumper settings that reset the internal timer and one for sending an off command. If you configure the jumpers (perhaps jumper 4?) in such a way as to send only on commands, then I would expect to recieve on commands each time motion is sensed. Since you would be using the ISY program to turn off your lights, then this should work for you. As I recall, your problems are not unique. My link to the wiki is: http://www.universal-devices.com/mwiki/index.php?title=Main_Pag Hopefully, it still works.

Ooo!. This statement causes me to wonder if you have communication issues. Are you able to manually turn that scene 'Garage to Master Bed LED' off? I have a couple of other thoughts regarding the program, but are suspicions only and hesitate to post until I can confirm on my own ISY. Perhaps those with the real brains can spot something right away.

Programs are probably your best bet here. If you only have the motion sensor and one switchlinc, then there is no need to create the scene. In fact, as you point out, the scene would work without any time-based constraints. Create a program that respondes to the motion sensor as a control. You can either use a program folder to constrain the program operational time, or a second condition in your program. You did not specify what you intend to do as a response to motion, but be aware that there are a couple of pitfalls that one must avoid. These are generally associated with the possibility that your program is running when the time contraint expires. For example, if a program is waiting a few minutes before turning a light off, and your time condition expires, the light will remain on. Also, there is a pretty exhaustive discussion on the wiki about motion sensors. It is probably best that you check it out.

As usual, MikeB was correct. Out of curiousity, I wanted to confirm the ability to control the LED of a keypad button set for non-toggle. I was able to do this on the oldest KPL in my inventory. As far as why you are having no luck, I can only assume that the program may not be set up correctly. Perhaps you could post it so that others can see it. Otherwise, I suspect it will be hard to offer much solid advice.

I know that you can turn off the backlight of the entire KPL. On some newer keypads, you can dim the backlight level. The instructions for the KPL include the steps. I recall that it was dependent on which version (8 button or 6?) and it was to simultaneously hold two buttons. It can also be done through the ISY on some of the newer versions of KPL. In the device properties is a backlight property where one can set the backlight levels. I am unaware of any way to separately control individual KPL backlight levels. The suggestion from BLH may work, but I am unsure if this is effective for KPL buttons set in non-toggle mode.

my uderstanding is that the non-toggle on mode leaves the backlight in the on level. In non toggle off, the backlight is always in the off level. While one may be able to adjust the backlight levels, I believe that to be the extent of the flexibility offered by these devices.

Flood away, I say! I have scenes with 20+ devices all turning on at once. There are others, I have no doubt, which are far more still. I have an all-house program turning every scene and every device (nearing about 40, if memory serves) off "instantaneously". It works flawlessly. The only problems I have had when I suspect are caused by clashing signals is when I try insteon too soon after an X-10 command. Even then, a wait of a couple of seconds proved sufficient. Waiting a minute would be an overkill in all cases, I suspect.

I am assuming that putting the motion sensor in a scene will cause your light to react to the off commands as well as the on. Therefore, I assume that using a program is your best option My first instinct is to create program folders...one for each time range in which you are interested. The condition would be: if: from beginning time to end time Make sure that there are no times throughout the day not covered by one folder. Make sure that there are not time periods covered by more than one folder. Create a timer program, not in any folder, like: if then wait 15 minutes turn light off else within each folder, create a simple program like: if control motion sensor is turned on then turn light to TBD level run timer program (then path) else the TBD level would be whatever level you choose for the applicable folder time range.

I suppose in extreme cases, one may get too much insteon traffic, signal collisions, repeats, etc, but it does not sound like this would be a concern for you. The good news is that it sounds like your children will continue to be amused.

There may be another option to consider, as well. The scenerio you describe basically eliminates local control of such a scene. In effect, you want a scene that comes on at a certain time, goes off at a certain time, and cannot be changed by light switches (unfortunately, I am unaware of a way to recognize adult fingers versus those of a child). What about modifying your current scene to make all included devices as responders (no controllers)? In my mind, such a scene would have no use for switches, so take those out of your scene. (Or you could leave them in as responders to give the kids something to play with.) Of course, there would be no way for adults to turn this scene on and off, except through the ISY. If that limitation is too great, you might consider adding a KPL in an enclosure and keep it hidden from curious minds. Use one of the buttons in the KPL as a scene controller should you ever desire to manually control the scene. There also are likely programmatic options (perhaps using program folders) to give local control between sunrise and 8pm then eliminate local control between 8p and sunrise. For example, get rid of your current scene. Then, create a program folder with the condition: from sunrise to 8p In that folder, create a program: if control 'light bath light switch' is turned on or control 'hall light switch' is turned on etc... then set 'hall light' at 100% else Add a second program in the folder: if control 'light bath light switch' is turned off or control 'hall light switch' is turned off etc... then set 'hall light' off else Create a third program that turns the hall light on at 8p and off at dawn. This program would be outside the folder. None of your control conditions could include the switch that actually controls the load. I am unaware of any way to disable the ability to locally control a load of a device where the load is connected. The only option that I can think of here would be to use an inline linc. One other thing that interests me in your scenerio...have you considered having your lights come on based on sunset, rather than at a fixed time? More sophisticated users even have lights come on based on interior or exterior light levels (measure by motion sensors or weatherbug). I don't know where you live, but in my area, the house can be pretty dark at 5p some times of the year, and pretty light at 9p other times of the year. I've already made this post too complicated I fear, so I will stop.

I agree that the flexibility offered with different on levels and ramp rates adds a degree of complication. That seems to be a common problem with technology (I can't help but think of the windows mobile vs iPhone analogy). Some have a great deal of flexibility at the expense of an up-front learning curve. Others are less up-front effort, but at the expense of having limits on what one can do. I think, however, that the ISY interface offers a reasonable solution. I am thinking that when you set up a scene and have it selected in your device list, you will see the scene properties (on-levels, ramp rates, etc). I think there is a check-box available that causes scene properties to be applied to all controlling devices within the scene. This sounds like what you are looking for. Perhaps that will help. As an additional thought, I think the ability to create different levels and rates to be a basic insteon capability....one could do this with the manual tap-linc process as well. One could reasonably argue that the ISY simply gives an easier method to achieve this inherent insteon capability. I have no doubt there would be more complaints if the ISY limited this capability for the purpose of making things simpler to learn.

I was not sure, but it made sense in my mind that it would not be used as a controller. Regardless, it makes no sense to me why you could not define a scene with several swithes as controller and the inline linc as a responder and have the scene behave as you desire. Assuming that the physical behaviour you are looking for is nothing unusual, the only thing that I can think of would be that on and off levels for the various controllers were set wrong. Or it could be a bug, as you suggest, or a software update to the inline linc not yet recognized by the ISY. Hopefully, others can respond with confirmation.

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.