oberkc

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.

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.