oberkc

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?

Have you tried a different light level to see if it better matches your expectaions?

I remain a little uncertain how this all works together, but suspect your issue is a failre to use a scene command to control the IOLinc. Try creating a scene, adding the IOLinc relay as responder. From the admin panel, does issuing scene commands solve your problem?

Outstanding!

There is an additional possibility, albeit unlikely. Perhaps there was an X-10 address somehow assigned to both buttons. A factory reset and restore would take care of this, also. I was hoping the compare device links would reveal a problem. Too bad. I hope this is not a failed device.

If the main button is not shown as controller of anything, and is not a part of some program as a condition, then the likeliest cause in my mind (short of device failure or some sort of communication gremlin) is that there are links in this keypad unknown to the ISY. Right click on the device, and choose "show device links". Then choose "compare". Does it show any mismatces? If so, you may want to perform a factory reset on the keypad and restore it from the ISY.

It sounds as if you are well on your way. The only thing I would offer at this point is to further refine your thought process and requirements. What do you want to happen if you turn the switch on while the light are currently OFF? Is this different than what you want to happen if you turn the switch on while the lights are currently ON? How does this affect your program?

I am back. With regards to your second program (the one with the 30 second wait period), I continue to suspect the problem was not a programming issue, but a motion sensor configuration issue. From the ISY, select the motion sensor in question. Select "options". You may need to now put the motion sensor in linking mode. Notice there are a couple of options with regards to sensitivity and continuous ON commands. Make sure the continuous ON commands are checked, or that you select a timeout period much less than 30 seconds. Note, too, that the physical jumper 5 must be set to allow for software control of the motion sensor. (This is described in the manual for the motion sensor.) "this program" would be whatever was the name you gave for that program itself. Regardless, clearly the two programs you tried originally had no relationship to each other. One incremented and cleared the value of a variable. The other responded to a motion sensor without regards to the value of the variable. In your original post, I was under the impression that you had an idea what you wanted to do with the variable and how to do it. Your only question, I thought was simply how to clear the variable after 30 minutes. That was the question to which I was responding. If you want some thoughts on how to use a variable to vary the response to the motion sensor, I may be able to offer some ideas.

My original program suggestion was in response only to the only question that I noticed: "I'm not sure how to do it but I want to set that variable so that it gets reset to zero when the motion sensor has not sent the ON command on anything over 30 minutes." I should have been more clear as to the request to which I was responding and the limit of scope I was offering. That is exactly what that program should do, unless you get another ON signal from the motion sensor within the 30-second wait period. I don't have a lot of time right now to offer deeper suggestions, but I would start by checking the configuration of your motion sensor. In it is a setting that defines how long to wait until re-enabling the sensor. If that is higher than 30 seconds, then there is no way for the sensor to send ON commands quicker than the program wait period, thus the program will always turn off the light. If you don't get additional suggestions, I will be checking back and offer more.