oberkc

This looks about right to me. Does it work? If your keypadlinc is a dimmer version, I wonder whether there might be complications if less than fully ON (100%). I forget whether secondary buttons can have a status of something other than OFF or ON, but this would be easy enough to check, if you are so inclined.

Obvious things to look for: a) have you saved the changes to your program? Do you see little green arrows in your program listing? do you, or do you not, see in the event viewer, the command to turn on the kitchen door light? c) can you turn on the kitchen light from the admin panel? d) is the program disabled? Is the program in a folder that is disabled? e) what is the status (true or false) of the program? When was it last run? Is this the same time as receipt of the motion sensor signal? There is little to go wrong with the program, itself. There is something else in play here.

Yes, that is exactly what I meant. Perhaps a combination of two (aligned in such a way that only a car could block both, with some ISY program logic requiring both, along with a continuous minute, as you suggest. I don't think these are very expensive. Other topic has explored the use of a cell phone as a surrogate for the car. Perhaps some type of logic such if cell phone connected to the wifi and garage sensor gizmo activated and second garage sensor gizmo activated then do whateve

Maybe I misunderstood, but I thought the original request was to detect whether the vehicle was IN the garage, not whether it is coming or leaving. Still, if the sensor was off and suddenly turned on, I think one could reasonably infer that the car just arrived. Obviously, a combination of sensors and logic would be required to ensure that it was a car, and not a lawnmower (or a person), but this is an issue not necessarily unique to this particular solution.

I wonder if one of those garage door opener safety sensors, in conjuction with an IOLinc and power supply, could be adapted for this purpose?

My gut reaction is to solve the communication problem. Absent of that, I would try to understand the communication problem a little better. It is possible, in my mind, that the reason that your keypads are missing the programs is because the control/status signals are not getting TO the ISY. If this is the case, no amount of programming (short of a query) will solve this problem. I thought filterlincs were plug-in devices. I am curious what you mean when you say you have one "at the panel". Are you saying that your keypads are on filtered power!? This could impact communication. I just ran out of time, but I thought I would offer a few thoughts.

There is no "flash" command in insteon, so the only way I know to do this is through a program. I forget the exact program language, but it is something like: repeat three times turn light on wait x seconds turn light off

I would take a slightly diffent allocation of tasks, triggers, and programs: If Control 'Main: Trigger Drive-Opened' is switched On then Resource 'Driveway Alarm Beep' Send Notification to 'Rich Email' content 'Driveway Alarm Alert' Run driveway alarm (if path) else Modify your driveway alarm code, and disable this program: If From 6:35:00PM To 6:35:00AM (next day) Then Set Scene 'Outside' On Wait 5 seconds Set Scene 'Outside' On Wait 25 minutes Set Scene 'Outside' Off Wait 5 seconds Set Scene 'Outside' Off Else - No Actions - (To add one, press 'Action')

Is the keypad main button also in this scene, as a controller?

If the leds on the IOLincs are not responding to a change in sensor state, then I would begin to suspect a hardware issue. It could be wiring. It could be the relay itself. It could be the IOLinc. You could eliminate the iolinc from consideration by shorting the sensor terminals and see if the iolinc led changes state. I am finding it hard to believe that this happened simutaneoulsy on three iolincs. Any electrical storms lately?

Is the LED showing sensor state still reponding as you expect? The ability to talk to the relay does not, in my mind, guarantee the ability to hear the sensor. There are only a couple of things that I can think that might cause this problem...a communication problem, or a hardware failure. I suppose it may be possible that a corrupt link database may be a possible cause, so it may not hurt anything to perform a "restore device" from this ISY.

I believe it represents a communication problem with that device. Have you tried to make any changes to the device? Scenes? Links? If so, try again to write those changes.

Try something like (syntax not exact): If Status of IOLinc is on Then Wait 10 minutes Send sms notification Else

Your program will trigger upon any change of state of your sensor, regardless of the variable. Whether it triggers off the variable depends on whether it is a state or integer,

I still think device malfunction is a posssibility.

Program looks good to me. I would consider other possible causes. Symptom suggest THEN path cause change in status of one of your conditions. Do you have any x10 addresses in use? Are any of these devices in other programs? Perhaps watching the event viewer when you trigger one of your problem devices would yield a clue.

While I read that you had installed a new paddle, the though did not cross my mind that this could be a potential cause of your problems. Good catch. Hopefully, that is the source of your problems and that it is easily remedied.

. Oftentimes, when manual scene commands work but programs or commands from ISY or mobilinc don't, it is because of problems communicating with the PLM. I would consider this possibility first. This sounds to me like either a wiring problem, or a device failure. Don't assume that a professional electrician understand how to wire insteon switches. I don't know how comfortable you are with electrical wiring, but I would be pulling that particular paddle out and checking wiring.

In addition. Any light, keypad button (load controlling or otherwise) , or module that you want to go on or off in response to your ALL scene should be included as responders. Yes, exactly. I tend to agree with this, which is why I recommended looking at causes other than scene definition.

first, no more "mashing". All scene creation should be done via ISY admin panel. Once created, just use the switches to turn off/on the scenes. Create one more scene...the two KPL main buttons would be controllers. All other devices you want to come on (including other KPL buttons) in response to the KPL main buttons would be added as responders.

I thought I would post a quick reply, without spending a lot of time studying your post... I don't think one can create conflicting scenes. If a device is already a controller of one scene, the ISY will not let you add it as a controller in a second scene. Devices can be responder to many scenes, but this would not create the symptoms you describe. I would be considering the following possibilities: a) is the load on the various switchlincs causing a problem? Are these loads something other than a simple incandescent light, operating on 120VAC? possible wiring problems? c) communication problems. d) do you have any programs involving these devices?

I have not used the IR portion of the ISY-994 (however I have used the IRLinc). For this reason I was hesitant to respond to this question. Unfortunately, I see others were equally hesitant, so I will not let ignorance get in the way in this case. Does not the ISY IR capability let you add a device command like a learning remote? How many buttons do you need the ISY to recognize in order to give you the control you need? Half a dozen? Would it be a simple matter to train the ISY for the specific buttons you wish to use for lighting control?

I normally associate this "croos link" expression to the manual (using button or paddle presses) process of linking devices to each other. To be sure, have you define a scene in the ISY including the button and microlinc as "controller"? If you cross-linked these manually, then you need to clear this and create the ISY scene. I cannot help with the REST interface, but suspect the concepts are the same as that for the admin panel. When you want multiple devices in a scene to track the same status, one must send commands to the scene, rather than to a device in the scene (even if that device is a controller). From the admin panel, choose the scene in which you created (or should have created...see response, above) to cross-link the devices. Turn that scene on/off. Observe KPL status following microlinc.

Your originally-stated problem was that one of your lights "turns on at other times". The problem quoted above is a different problem, possibly from a different cause. Are you still getting the one light turning on at other times?

On this point, I have the understanding that these CAN coexist. Whether there is a single controller that speaks all four "languages" is another issue.