oberkc

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.

Is it possible you have communication issues? Are you otherwise able to control it? Is the status accurate? In event viewer, level 3, if you send a command to the KPL, do you get any indication of failure? You could also try running an extension cord to an outlet on the same circuit as your KPL. Use this to power your PLM. See if this solves your problem.

I have set up my garage door IOLinc and Keypad just as you suggest. I used the wiki instructions suggested by AnthemAVM. They work great. You must pay attention to details, but my keypad is on when the door is open and off when closed. Pushing the button activates the door, just like pushing the hard wired button in the garage. While the ISY-99 makes setup much easier, there is a post at Smarthome from one who did it without an ISY. (There is no program required.) Configuring the devices can be done manually, apparently. I was impressed.

farm, regarding hardware, I would judge hardware on reliability. Notwithstanding your issues (still TBD), I suspect you will find a whole legion of users here who will attest to continued operations without failures. As far as interface, I guess it is a taste thing. If function is all that is important, you will find it completely sufficient.

I do something similar with the garage door kit sensor.

I am not familiar with all the details of those event logs, but can generally recognize when the ISY recieves a signal from a device. As you both indicated, it does not appear the PLM is able to recieve signals from a couple of your devices. This can also affect the ability to program these devices and restore these devices. Did the restore of these devices seem to take longer than expected? If the restore devices and PLM did not solve your problem, then I think we can only conclude that you are having some communication issues. You can try removing one of your offending devices and adding it back in. There is also a scene test available, but I am not sure that it would tell you anything that you don't already know. There are lot's of posts about solving communication problems, here, and at the smarthome forum. I understand that most communication problems occur when other devices in your house cause interference on your powerlines or attenuate the signals. The typical types of questions that are asked are: a. do you use any filters? b. do you have access points or some other means to bridge the phases of your electrical system? c. does your computer sytem include lots of devices with power supplies? Is your PLM plugged into the same outlets and circuits as those devices? d. do you use a UPS or power conditioner? Is your PLM plugged into this? In your case, I would add: e. does your family room include lots of home theater electronic stuff? There are a few quick things one can do to further confirm communication issues. If you can identify an outlet on the same circuit as your mis-behaving devices, power your PLM from this, using an extension cord if necessary. See if you get better results. Alternatively, you can move some access points around to see if this helps. Put one directly on your PLM. Put another on the same circuit as your troubled devices. See if this helps. As best I can tell, there are no way of positively identifying trouble-causing devices in your house. Best practice seems to be to make educated guesses (computer stuff, home theater stuff, TVs, CFLs, Low voltage lighting systems) and go around unpluggins such things, while observing performance of your insteon system as a result. If you identify any offending devices, put a filter on them.

I believe that it would work when perpendicular, but that this is not necessary. I have my magnet mounted on the upper corner of the door, with the sensor on the door frame, immediately adjacent (and parallel) to the magnet.

Yes, it would. Of course the sensor can be wired where open (or closed) is either on or off, based on which wire you attach to the IOLinc The problem with this approach, I assume, is that most people want positive indication when the door is CLOSED. If one mounts the sensor up high, activated only when the door is fully open, then you have that potential that a door might be in a partially closed state with the sensor not yet activated. The owner is happily laboring under the false impression that door is not "open" when, in fact, it is (at least partially). My guess is that the best solution for you is to mount the sensor near the top of the garage door opening. The sensor should be triggered only when the door is fully closed. Run your wire along the track stucture a much as you can, to avoid the unsightliness of wires on walls. Install your IOLinc in the outlet powering the opener. This should minimize visible wires.

I think it concievable that you could even mount the sensor on the track nearer still to the opener. This would further minimize unsightly wires. Wires could also be taped to the door track. This could be visually preferable to stapling to the wall.

Have you looked at the program summary page in the admin console. This shows last run time for each program. Perhaps one of the programs has a last run time corresponding to the time of the unexpected command of your scene.

I am with LeeG on this. I don't believe it is a programming issue. Look for link issues or communication issues or faulty devices. While in event viewer level three, turn your various devices on or off and see that you are getting these signals (you will see an event in the viewer). Also, from the admin panel, check the status of each of the devices to see if they are consistent with real world conditions. Additionally, try to control each of the three devices from the ISY. The point of this is to determine that you have good communication between the three devices in your progam, and the PLM. Look for evidence of errors or devices not responding or inconsistencies between the PLM status and device.

I suspect brad77 is correct about his observations about the triggerlinc. I have not used one, so I have no comment about that. I suggest avoiding this approach for different reasons. First, the wired sensor is not that hard to install. It is no more difficult than stapling a garage door button wire along the ceiling, which you have probably done. It probably takes less time than replacing a battery in a triggerlinc a few times. Second, the wired sensor can be placed high, also. Mine is near the top of the door. It works well. Third, the IOLinc has several modes, based upon sensor input. If you don't have a sensor, you may be limiting your options for garage door control. My suggestion is to go with the wired sensor that is part of the garage door kit.

This is my program, and it works great. Besides "or" versus "and", it is very similar to yours and the one I suggested earlier. My scene "bedroom control' has no device in it, other than the KPL button. The "if" condition is unaffected by execution of the "then" or "else" statements. I am looking forward to your response regarding the device content of your scene: "family-led"

I have a program that does this. I did not recall it being overly complicated. When I get the chance later today, I will post it. The only difference is that I have my KPL button on if at least one (as opposed to all) of the related devices is on. But wait....something just occured to me. (I should have asked this originally.) I am starting to think that the response (then or else) is affecting the conditions (if). Does the scene "family LED" include any of the devices in the "if" condition? That is, does this scene include any of: Family - front, family - main, or family - rear? If the scene includes these, then this could be forcing a re-evaluation of the conditions, restarting execution of the program.

Is it possible that the front switch is set as a controller in your scene "family-LED"? Make sure that the only controller is the keypad button. Those programs, by themselves, look reasonable to me. I wonder, however, if the two, together, are fighting each other. Instead of two, why don't you try one: If Status 'Family - Front' is not Off And Status 'Family - Main' is not Off And Status 'Family - Rear' is not Off Then Wait 3 seconds Set Scene 'Family - LED' On Else Wait 3 seconds Set Scene 'Family - LED' Off

If downstairs is already on, turning it on again will not hurt anything. No. For the same reason. Having said that, you did not specify if your intentions were also to turn them off after a certain period of time after sense of motion. If so, then there may be benefits to including one of those conditions in your program. Also, if someone has made a manual adjustment to the scene (dimmed, bright, etc...) then turning the scene "back on" will cause it to resort to the devault settings. This may or may not be a factor in your case.

Wow. You don't ask an easy question. Are you prepared to reset and reprogram devices? How many devices are we talking about? Do you have any plug-in modules? Do you know what access points are and do you have any? How old do you believe is this installation? Do you have any whole-house controller of any type?