oberkc

I can't tell if you are describing how it is, or how you want it to be. I would help if you describe the devices in your current "scene". Is the "kichen" part of that scene? What insteon device directly controls the pendents? What other insteon devices are in that scene and what loads do they directly control. Within that scene, which devices are defined as "controllers"? One option is to create a second scene...the one with just the pendants. This scene could have all the same devices as your kitchen scene, but a different controller. Or you could define different on levels for your kitchen scene, depending on which controller initiates it. For example, if your kitchen scene has two devices (say switch 1 and switch 2) defined as controllers, switch 1 can initiate full bright for all devices in the scene, switch 2 can be set to initiate 50% for pendants and off (or very low, depending on device version) for the rest.

The quick and simple answer is yes. This is also true with "repeat" commands. LeeG offered the standard solution for this "problem".

I recall certain insteon devices which would fail to accept certain settings from the ISY unless power was cycled. Have you tried temporarily shutting off power to the in-linelinc to see if this has any affect?

I will think some more on it. I agree, this is strange behavior. If I come up with some other ideas, I will post back, but I am drawing a blank right now. Another option is to use the insteon IRLinc and keep the ISY where it works. But I agree....I would want to find out what the problem is here.

I am not a reader of those messages, but I wonder if the "Hops Left=0" part is an indication of a device not responding. Just to get the conversation rolling: do you have access points? Are they close to the remotelinc? did you put your remotelinc into linking mode?

Do you have access points or some other means of bridging the legs of your house electrical system? When installed in your living room, what other electronic devices (home theater?) stuff is plugged in along with your ISY?

There are lot's of examples and subtle variations on the motion sensor program. It is definitely worth some time searching them out. In the mean time, make it simple: if control motion sensor is switched on then set light on wait 10 minutes set light off else If your requirements get a bit complicated (different reponse if light is manually turned on), the fine folks around here can discuss other options.

I suspect the reason your program is not working has little to do with KPL toggle or non-toggle. I suspect you need to make some adjustments to your IOLinc. Setting your relay on, waiting 13 seconds, then turning it off will not keep your relay open for thirteen seconds. Furthermore, how your relay responds to on and off commands is part of your IOLinc settings. Then Set 'Outdoor / Gate / Gate Relay' On Wait 13 seconds Set 'Outdoor / Gate / Gate Relay' Off The duration of the length of time the relay stays open is a setting. Whether your IOLinc responds to on, off, or both is part of the settings. Whether your relay is normally opened or normally closed is part of a setting. My suggestion is to open the settings from the ISY-99 admin panel and review them from the wiki: http://www.universal-devices.com/mwiki/index.php?title=ISY-99i/ISY-26_INSTEON:Linking_an_I/O_Linc Pay special attention to the "momentary" versus "latching" modes. How is yours set up? Is it in momentary setting (versus latching). How long is your momentary hold time? If in momentary, is it momentary A, B, or C? I cannot confirm, but if the IOlinc allows momentary hold times of 13 seconds, I would use this option to open your gate. Then, you would have only to send one command (no waits, no second commands) to your IOlinc to open the gate. The command required would depend on whether the setting is momentary A, B, or C. If the settings do not allow a momentary hold time as long as you need, I suggest putting your IOLinc into "latching" mode, and proceeding much as you have already done with your program. (You may find that changing this one setting would cause your existing program to work.) So you have a sensor hooked up to your IOLinc relay? After you check the settings in your IOLinc, and review the meaning of each from the wiki, I am hoping that you could report back if you have further questions about your setup. If so, please let us know how your IOLinc is configured.

Being unsure if the garybixler solution worked for you, perhaps there is an alternative. Given that it appears the the program condition evaluates every time the temperature changes (forcing a restart of programs with a wait condition), I thought that there was an alternative. I am also a fan of folders, so I tend to favor them, even if alternatives exist. Folder condition: If Status 'Living Room / Venstar House' > 71° (Temperature) the run the programs in this folder Program in the folder: if time is 0000 or time is 0100 or time is 0200 or time is 0300 . . . or time is 2300 then Set 'Living Room / Venstar House' Fan On Wait 10 minute Set 'Living Room / Venstar House' Fan Auto //turn fan off else While it is not quite as elegant, taking the temperature out of the program conditions will avoid the re-triggering of the program every time the temperature changes a degree.

Indeed! I would add this to my first program. if time from sunset to sunrise (next day) And Status 'EntryLightsEast' is not On And Status 'EntryLightsWest' is not On And Control Motion Sensor switched on <<<<<<then Set Scene 'FrontPorchControl' On Wait timeout period Set Scene 'frontPorchControl' off else But I like kingwr solution just as well.

Based on what I have read at places like this, I understand that some insteon devices are limited in capability such that they cannot be used as controllers. (Perhaps they don't broadcast status?) This includes certain lamplincs and appliancelincs. I would not be surprised if the outletlinc is such a device. If so, I assume status or control from such devices cannot be used as a program condition, either. If you want to perform a quick test, open the event viewer, then manually activate your outletlinc. If you see communication traffic, you may be OK. If not, I suspect you may not be able to do what you want.

That is quite the complicated web of programs there. It seems overly so, to me. What is the EntryLightControlStatus used for? This is your folder condition? Which programs are in this folder? You appear to have two entry lights (east and west). Do you want to disable the motion program if a SPECIFIC (east? west?) one is on, EITHER are on, or only if BOTH are on? If one light is on manually, how do you want this to affect motion control of the other? If both lights are on as a result of motion, and you manually activate only one switch, how do you want this to affect the automatic off of the second switch? If both lights are to remain on, are you willing to manually turn off two switches or do you want a single switch control of both lights? What devices are in your "frontporchcontrol" scene and which of these are controllers? Writing without fully understanding your requirements, why not take advantage of the oft-maligned feature that stops programs from executing when there is a change in entry conditions: Program 1 if time from sunset to sunrise (next day) And Status 'EntryLightsEast' is not On And Status 'EntryLightsWest' is not On then Set Scene 'FrontPorchControl' On Wait timeout period Set Scene 'frontPorchControl' off else This program would not execute if either a) during the day or if EITHER of the entry lights are on. Furthermore, if (after the scene is turned on and during the wait period) EITHER of the entry lights are turned on manually, the execution will stop and BOTH lights will remain on until both are turned off manually. The problem I foresee with this is the potential that sunrise occurs during a wait period. If so, the lights will remain on. To counter this possibility, I would add a second program: if time is sunrise then Set Scene 'frontPorchControl' off What am I missing?

Don't worry about the Beta versions. Get the latest, I say.

Nice!

Yup. Just take care to use the correct connections on the ISY-99. "network" connection goes to router. "Port A" goes to PLM.

Can't (to lazy) do picture. For my hookup....RJ45 cable goes between PLM and ISY-99 (into port A). Other RJ45 cable goes between ISY (network) and router. Depending on version of PLM, you may also need a power supply for your ISY. I don't use the serial cable. I understand that this provides direct connection to computer if needed. I found this to be consistent with instructions: http://www.universal-devices.com/docs/isy99_userguide.pdf Page 9

I am unsure about the physical interface for the 12V power. I am assuming you have that figured out. Regarding the programming: if recieve on trigger is recieved <<<< insteon command recieved that you use to turn on reciever and reciever off trigger is not recieved <<<< command you use to turn off reciever and IO Input is not on <<< then Send IR signal on wait a little bit Repeat a few times else This program "if" condition would evaluate as "true" if a combination of ALL THREE conditions were all true. Otherwise, the "if" condition is false. Therefore, at receipt of 12V signal, or receipt of an off command, the "if" condition evaluates as false, forcing execution of the "else" statement, which is empty. Hopefully, I am understanding your problem and questions. At the risk of repeating myself, the syntax is VERY APPROXIMATE, only for the purpose of suggesting the program logic.

Hopefully, tdmarra does not have any of those "vintage" keypads. Mine are relatively new.

This scenerio is nearly identical to the wiki example on garage door control. Set the keypad on non-toggle off. Create a scene where the sensor controls the keypad. I see no adverse affects of having a non-toggle keypad turned on or off. Of course, I have not tried this, and there can always be complications that I don't forsee. Could there be timing issues (do non-toggle buttons recieve scene commands while flashing?) Maybe.

As LeeG suggested, this is the sort of LED behaviour which would require some additional program in the ISY-99. But, first, a little background: a. keypad buttons in the "non-toggle on" mode will always be illuminated, unless commanded to be otherwise by a linked device (such as the ISY/PLM) b. keypad buttons in the "non-toogle off" mode will always be off, unless commanded to be otherwise by a linked device (such as the ISY/PLM) c. when non-toggle X buttons are pressed, they will flash then resort to their native lighting mode. d. Some versions (maybe all) of keypads' secondary buttons may not be controllable directly from the ISY. e. While you did not explicitly state so, I assume the load is being controlled by some unspecified insteon device. I will call it "load". Given the understanding above, I would first create two scenes. One scene would include KPL-A as a responder only. The second scene would include KPL-C as a responder only. Of course, you would also have to create the scene suggested by LeeG, which includes the KPL-A and KPL-C as controllers and the load device as responder. I would then create a program: if status "load" is not off then set scene KPL-A on set scene KPL-C off else set scene KPL-A off set scene KPL-C on

I assume that you are speaking of ISY-99 programming. Correct? Given the nature of the way an ISY program works (evaluating input conditions during a wait statement), typical motion sensor programs will inherently restart each time motion is sensed. For example: if motion is sensed then turn on light wait three minutes turn off light else If motion is sensed during the wait period, the program execution stops what it is doing, turns on the light (which is already on), and restarts the wait period. The ISY-99 has a "repeat" command. I believe it can also restrict the number of repetitions. Repeats also give a program to cease execution if your input conditions change (I would think a finite number of loops would be good mitigation step against the possibility that your reciever never turns on for some reason), so your program logic would look something like: if recieve on trigger is recieved and reciever off trigger is not recieved and IO Input is not on then Send IR signal on wait a little bit Repeat a few times else Please be aware that the actual ISY-99 syntax will vary (I don't have it memorized) but I believe that this program flow would work for you. Hopefully others can confirm and offer other suggestions as necessary.

As LeeG says, any single device can be controller in only one scene. Putting them all in one scene should solve your problem, but you will obviously have to eliminate some of the older and superfluous (I have always liked that word) scenes.

OK(?!). That sure strikes me as an obscure request. While I did not see any mention of "non-toggle", I guess this is reasonably inferred from "pressing the on command". In retrospect, perhaps he is refering to the top button of a 6-button KPL? I am sure curious what benefit that offers over leaving the button in toggle mode and simply creating a scene. Perhaps polexian has some super-creative use for this idea from which others can benefit.

If you want to be able to control the scene from all these devices, then create one scene to include all devices as controller. What is "it"? What device will "it" not give you a choice to be a controller?

I agree with lawr100 on the solution to your problem. Use a scene. Still, I wanted to offer a suggestion on a possibility why your program was not working... Your conditions required two things to be true in order for the "then" to execute. These conditions were: 1. switch turned on 2. outlet being off When these conditions were met, the "then" executes, which turns the outlet on, which now makes your conditions false, which forces execution of the "else" statement, which turns your outlet off. My suspicion is that if you eliminated the second condition, your program may work. But then, your program would look a lot like that suggested by lawr1000.