Is it a bad design? using wakeups

I have implemented a feature to do future ON for my device.
because i wanted to take into account extreme cases where it might shut down unexpectedly, i have this mechanism:

  1. get a command to turn on in 2 hours
  2. every minute, advance a counter by 1 (till it reaches 120)
  3. every minute, update server permanent table with values

i also have a counter to avoid multiple wakeups (so that it will be cancellable), so each minute i check that the counter variable is the same as the one I have (the 1 minute callback contains the value i started with)
the thing is, it causes alot of ugly code…and too many variables imo
I could just do imp.wakeup(12060, onfunction) but in case server crashes, thats a problem.
I could also do var = 120, imp.wakeup(120
60, onfunction) and every minute do var-- , which is a little easier.
Is there a way to save wakeup callbacks (its like a stack, isnt it?) and just backup/restore to/from server?

All timers maximum value is less than 24 hours, which is a bug i noticed here in forums
This approach is mainly because I wish to be able to cancel those scheduled wakeups, so I use counter to see if its still relevant…because i cant cancel a wakeup

imp.wakeup() is totally local. The server going away/coming back will not affect a queued wakeup, because they don’t force the squirrel to be restarted.

There’s currently no way to cancel pending wakeups, but it has been requested before.

I see. So the only wakeup killers are restarts to imp by downloading new software?

Some mechanism where you have a stack and imp. Wakeup returns an id so you can search with it later could be a good idea

Thanks :slight_smile:

Yeah, that would be the idea, imp.wakeup would return a handle which you could use to modify or cancel the wakeup at a future time.