oberkc

I suspect this is your likely end state, yes. If you prefer an independent check, take a short piece of wire and quickly touch the to opener terminals together (simulating a momentary contact switch). Does the door open or close? If yes, then I would further consider the possibility that there is a problem in the configuration of your IOLinc or connections. If no, then you will likely have to wire directly to the wall switch. I don't know whether my chamberlain is a "myQ" system. It does NOT connect to the internet, but it does have motion sensor and separate switches for the lights. Yes, I can control the opener with an IOLinc connected to the opener, itself. Also, when my opener lights flash, it is an indication that the safety sensors are not seeing each other.

To which I add that the points made about triggers, evaluation state, status, and control are all applicable to a temperature sensor when part of a program condition. I found apostalakisl comments quite relevent to this case. What did I miss?

OK. Yes, you can get rid of your first program. You are correct that for your program to trigger at all times, the omission of a time constraint is the best way to specify this. A couple of things to watch out for in this: a) yes, control and status are different in subtle ways. I recall that the wiki described this, and suggest you check it out for your own edification. In this case, I believe "control" is a better option the motion sensors, themselves, configurable by combinations of internal switches, and software such as the ISY. I think you have to configure switch 5 to enable software control. From there, check out the ISY-based options, looking for the "occupancy" mode (I think). This will allow the sensor to send ON commands each time motion is sensed, without the need to wait for a time-out period. Once done, you should be able to handle this with a single program if timeout periods for door and motion are the same, or two programs if different. Consider: if control motion sensorA is set on or control motion sensorB is set on or control motion sensorC is set on or control doorsensor is set on then turn on light wait a few minutes turn off light else nothing

I am curious as to your intentions here with program 1 compared to program 2. Also, why did you choose "status" rather than "control" in program 1? Also, 12AM to 12AM (next day) sounds a lot like "anytime". Did you intend to say 12PM (next day)? Program 1 will turn on the light any time the door sensor changes from OFF to ON. That seems fine to me. But, program 2 will do the same thing, then turn it off 2 minutes later. It seems that program 1 is redundant. Program 3, on the other hand, has the potential to cause the light to come on and stay on indefinitely. Is this what you want?

I have not performed any controlled tests. I also have seen no reason to doubt the specifications mentioned by stusviews and agree that the range can have a LARGE variability based on installation factors. Based upon what I read around here, it seems that range can also vary by device, and even among multiple copies of similar devices. I have a general perception that, all other things being equal, the "range extenders" have as good of range as any device. My best guess would be that I see the most complaints about shortness of range in regards to the insteon bulb. In my own experience, I have motion sensors removed up to 30 feet (with a wall in between) from the nearest dual-band device (a range extender) and it seems to work reliably. I tend to view the RF as a "backup" to the wire communication path, best when one has many RF-enabled devices communicating amongst themselves. I would be very hesitant to rely solely on the RF side of insteon for communication among devices.

ONe thing that seems to trip some folks up is that the relay device status is not to be used as a reflection of garage door status. Make sure you are using the sensor. (from your program, I could not tell which you were using...sorry) Another possibility, beyond those already suggested, is that it is possible that there are differences between responses to scene commands and direct commands. Perhaps creation of a scene with the relay included only, and having the program activating the scene, rather than directly addressing the relay, would help. Check, also, the mode of the relay. Is this in momentary mode?

You may also consider creating a scene in the ISY-994 (with the relay only) and controlling the scene from the mobilinc.

My initial guesses are - for some reason, the KPL OFF signal is not getting to all the devices. Do you have a confirmed communication path between the legs of your electrical system? How did you confirm this? - is you KPL in non-toggle mode, only sending ON commands? Just to confirm...you have a single scene with (about) ten KPLs and two othe devices that power the outside lights. All KPLs are controllers, the two light devices are responders. Correct? Is the non-response consistent for all ten KPLs?

If you think that this could be solved by adding a time-out period (perhaps a little longer than the overall typical cycle time) in your program, you could try something like: if control sump is switched on and status ON program is false then run ON program (then path) else nothing ON program: if nothing then send notification wait 3 minutes<<<adjust time period to suit, currently assuming the sump pit is cleared in less than three minutes run ON program (else path) else nothing A similar thought process could be used to send the OFF notification

Homeseer, I thought, required a computer to be running for it to work. ISY-994 does not. The other thing that concerns me about generic home control software like this is how well it supports a given protocol. If you have decided (besides door locks) that you will be using insteon, then I can vouch for the ISY-994 being near certain to support it. If you want to use homeseer and have no problem leaving a computer running, make sure it has broad support for all the various insteon devices.

You are welcome so much. That type of question is, possibly, the most common, typically associated with triggers from motion sensors rather than from garage doors or security sensors. Still, the solution is the same, and seems to be the one used by many who post here regularly. I contine to be concerned about the way the elk condition behaves. If like a status condition, you may find the kitchen lights coming on at sunset for a couple of minutes. Keep an eye on things to make sure there are no surprises lurking.

If Elk Zone "Garage Door" is voilated And from Sunset - 30 minutes To Sunrise + 30 minutes (next day) And status kitchen light is off Then Run second,progrm (then path) Second program: If Then Set "Kitchen LIght" On Wait 2 minutes Set "Kitchen Light" Off I assume (no first hand experience) that the elk condition behaves as a "control" rather than "status". Otherwise, this program may turn into the equivalent of an infinite do loop.

I would think one of the insteon IRLincs could be useful here, as well, depending on your intentions.

What else is on the circuit containing the keypad? I have a troublesome keypad also, but different kinds of troubles than yours. Mine seems to have trouble with writing changes from the ISY. Interestingly, it otherwise seems to work. I began to wonder of the kinds of failure modes that these things can have. Perhaps the troubles you are seeing is indicative of a faulty device? The only way that I can think to test would be to take it out and temporarily wire it to an extension cord, then plug it into the same outlet as the PLM. You asked earlier about a query. Do you still have the standard 3:00am query program? I still consider this a kluge, but it may get you by. I just depends on how important is a quick response to your button press.

I would , then, temporarily run an extension cord from another circuit in another room, into which I would plug the PLM. Once done, I would see if the comm problems are solved. If so, I would put all that other computer equipment on a filter. It is also worth rechecking the access points, in my mind. Is this keypad the only device that appears to be having trouble communicating with the ISY?

While, theoretically, you could query a device, I suspect you will not get good results without correcting your communications issues. With that in mind, do you have two dual band devices confirmed (by tesing using the methods in the manual)? Access points? Is your PLM on a power strip or ups? Is the plm on a circuit with lots of other computer equipment?

I assume the mobilinc connect message is in reference to the paid service one can use with mobilinc to simplify your router setup and deal with ever-changing IP addresses. If you did not sign up for mobilinc connect, it seems that one should not install such an add-on. If I didn't know any better, I would suspect that this ISY is somehow identified with a different user.

I am unfamiliar with these particular messages, but I understand x-10 works without the module still. You may need to adjust some programs to send specific commands, rather than device names, however. The message WRT to mobilinc connect suggests that you have signed up for the service. Is this true?

OK. There are a couple of things to look for to isolate the cause. Make sure that the ISY accurately reflects keypad status. When the entry lights are off, does the ISY show it OFF in the device list? If not, perhaps you have a communication problem. If the ISY shows entry lights status as off, and the folder condition still true, I have no clue what would cause that.

In which case, I wholly agree with xathros.

I don't use the lite version on android, but was afraid of this. Based upon the lite version in iOS, I was concerned that one could access only devices or scenes, and not programs. To access a device or scene from the lite version (iOS), it must be at the top two in your ISY device listing. I assume the same for android. You will likely have to assign it a name that puts it at the top alphabetically. My initial thoughts on this was similar to mwareman: create a disabled program that only would be used by your daughter. Unfortunately, if you have confirmed that the lite version cannot access programs, this is not an option. Interestingly enough, the description on the play store says that the lite version DOES have access to programs. How confident are you that you don't have access to programs? Your idea about an unused device as a unique trigger has merit, in my mind. Did it not work?

First, create a scene. I recall a couple of ways to do this, but it sounds as if you have figured that part out. Second, add any devices to the scene. You can click-and-drag a device to the scene icon. You can right-click a device, choosing the option to "add to scene". Pick one. When adding to a scene, you must choose as a "controller" or "responder". If you don't know what the implications are with these two options, post back.

You can try "is not off" status? Is the keypad a dimmer? (I am unsure and have never checked if secondary buttons on a dimmer keypad have status other than zero or 100%, but I have always assumed so.)

I am not sure that I understand the expression "signal stream", but this sound correct to me. What do you want to happen if the door closes (sensor OFF), then opens back in less than three minutes? Do you want the program timer to continue or be halted? I think that is the crux of the issue. Do you want the light to stay in indefinitely when the door is open? If you want the timer to be halted, use STATUS. If you want the timer to continue, use CONTROL. I have no idea why this is/was happening, but the font sizes seem to change when I put them in quotes and at other times. I was too lazy to go back and manually change the font size back to the original. I must admit that sensor bounce is not something with which I deal. I agree that either should work in most cases, but I still suspect there will be different behavior between status and control if the door goes from closed (off) to open (on) while the program is executing the wait statement.

With a certain level of anxiety about offering advice different from xathros, I must admit that I would have offered a little different opinion. I think "control" is the better solution here. My concern with the use of "status" is what happens when the sensor status changes to OFF during the wait period? Would not the program halt, and the power of the ceiling light not cycle? Would this be a problem?