oberkc

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?

Does the PLM have a factory reset function? If so, how about: 1) remove PLM from ISY 2) factory reset PLM 3) restore PLM on ISY

This is what I have now for the sunset/sunrise but it is not working for some reason. It comes on during the day. This looks correct to me. I expect this to work, also (although it is unclear to me how these lights turn off. Is the motion sensor part of your 'backyard lighting' scene?) Have you checked the time on your ISY? Is it possible that the system settings got messed up? I am a little concerned that your manual backyard enable program includes actions in the "else" section that may trigger a re-evaluation of your program conditions. This violates one of my personal general programming rules for the ISY. As for the motion control program, is this constrained by sunset or sunrise anywhere? Is this program enabled along with your sunset/sunrise program, above?

Don't hesitate to post back. Also, check the universal devices wiki. There is an excellent example there. Perform a search on garage, and IOLinc. You will find explanations about many of your questions.

Be advised that most on this forum are Users with no affilitation with Insteon (Smarthome). A few are from Universal devices. As advised by LeeG, I believe that this can be done. However, I question if this what you really want. It sounds as if you are using a keypad to control your garage door. Is this true? If so, do you want your keypad to display status of the garage door?If not, how do you know the status of the door? What if the garage door is stopped mid-way or moving? How do you want the door to respond to commands? If mid-way, this will only respond to one command, depending on how you wire and position your sensor. If your original aspirations ("on" opens when closed, "off" closes when open) then my experience is consistent with LeeG. Create a scene with the relay as responder and your controlling device (whatever insteon device you desire to use to send on and off commands) as controller. Set the relay to momentary "C" mode. Keep in mind, also, that the sensor can be wired such that a garage door closed would give either "on" or "off" status. Additionally, there is no way to distinguish between a door being fully open or partially open.

I am impressed by your ambition. How does your site differ, in purpose, from the wiki?

I use programs to turn off scenes (including those with controller devices) all the time, without issues that I know about. In fact, I thought the response to scene commands was more robust than the response to individual devices. Like Sub-routine and gviliunas, I am having trouble understanding why you think this is a bad idea. Consider me to have spoken up. I believe this is not correct.

Thanks for trying.

I think I would, then, perform an experiment. Remove one of your devices from the ISY. Re-add it, this time by automatically creating the link (choose the "start linking" button). Then see if you can get status. I'll bet that you can. My theory is based upon the possibility that the ISY does not accurately recognize the device sometimes when added manually. Furthermore, this can result in query and status problems. While I am not completely confident of this, it seems a simple enough experiment to try.