Interruption Notification

(Toejough) #1

Has anyone successfully created an app that senses interruptions and then ceases its behavior?

For instance, I would like to alter the “Gentle WakeUp” app, which gradually increases the light level on a dimmer switch. I would like to modify it so that if I use the app or actually get out of bed and manually hit the switch on the wall, the app will stop controlling the light.

I have tried to detect such a change via checking the switch state (is it in the previous state or the state I just set it to? No? Then we got interrupted), but the scheduling functions don’t take arguments or closures, and I’ve shown that the state between scheduler and schedulee is inconsistent, so I’m presently at a loss.

Some sort of “manual-override”, at least, should be easy, but it doesn’t seem to be.

Has anyone figured this out?

(Im Brian) #2

Yeah, you have to create a timer and a state variable. Example here:

If my front door opens, it triggers an alarm. It sets a state.triggerMode variable then executes “fireAlarm” to execute a predetermined amount of time later. In fireAlarm, it checks it’s current mode against the one stored in the state variable. If they are different, then I’ve probably come home so it can be ignored.

(Toejough) #3

Thanks for the response. I have had trouble with exactly that methodology (see the code in the linked forum post). There seems to be a lower bound on the time for state consistency. In the code I wrote, the state in the fired event’s context would frequently lag the state in the code which scheduled the event.

Have you had trouble with this? The source you linked indicates a default of 15s…if that’s consistently working for you, then that’s awesome.

I worked on my code, isolating and testing for hours…when I convinced myself that the state inconsistency issue was real, I stopped, pinged support, made a forum post, and moved on to other things. Given that 15s is working for you, I’ll go back to my code and see if I can isolate an upper bound to the consistency issue.

(Toejough) #4

well, I’ll try again another time, perhaps. This particular evening, my runIn(15, callback) calls are running in 60+ seconds. If I am able to narrow down the times for state consistency I’ll post here with my findings.