oberkc

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?

I suspect this can be done with a single program through brute force, but it would get ugly quick if the number of devices gets much beyond three or four. if (A and B is on) or (A or C is on) or (B or C is on) or ..... then do something As the number of devices grow, the approach proposed by bleepborp may become relatively more efficient.

That sounds right, to me also. Things have changed, it seems. The big point is to understand what ON means in programs, versus NOT OFF, OFF versus NOT ON, etc.... Is 50%/10%/90% on or off? Things like that.

If I understand correctly, I believe the status ON and OFF are limited to relay devices and percentages are for dimmer devices. "ON" would equate to 100%..."Not OFF" would equate to anything over zero....etc. It is important to pay strict attention to the way percentages work versus ON and OFF.

I am a little fuzzy as to what you are trying to achieve. Are you trying to create a program that watches for when the button is manually turned on? Then when turned on, it activates a scene and turns off the button? First thing I would check is that the ISY status is accurately showing the button status.

Yes, I do have an idea. I suspect that the lighting levevs continue to change over the morning (and evenings). Each change triggers the program. In your case it was last triggered at 12:30. The status was likely already false, so the program probably sent an OFF command to lights that were already off. That sort of thing probably happens several times each morning, and each night.

Ah! So it is actually PASSING sunrise and waiting until the light level kicks in? I can see why your program does this. BOTH conditions (time and dark) must be FALSE for the program to be false. If time is sunrise-30 while it is still dark, the program will remain TRUE. Without thinking too much about this, you may need to break into two programs If time is sunset or it is dark then turn lights on if time is sunrise or it is light then turn lights off

Our message timing makes me suspect you missed my suggestion.

How do you set your location? Lat/long?