Wake up alarm
Pep_SD
Posts: 106
I'm sure a few people came up with solutions to provide users with a Wake up alarm instead of the regular iphone, clock alarm.
What is your choice of implementation between a full home grown solution and using i!Scheduler?
My main question is how to get a portion of code executing at the time entered by the user...
Besides i!Scheduler, is there any trick to compare against current system time?
Thanks a bunch!
What is your choice of implementation between a full home grown solution and using i!Scheduler?
My main question is how to get a portion of code executing at the time entered by the user...
Besides i!Scheduler, is there any trick to compare against current system time?
Thanks a bunch!
0
Comments
I have set them up to do more than just beep to wake you up. You can set up a whole scene of lights coming on, TVs turning on, music, etc.
And for what it's worth, my wife and I have our own NXT-CV10s that have been our alarm clocks for over 10 years very reliably.
That is exactly what I want to do, turning music or tv on with your favorite channel, lights, shades etc.
I would use the TP just to select the time and actions to perform, not to actually wake up.
My question is around the mechanism to use to fire these actions.
Do you use i!Scheduler or something else of your own?
My main chalenge is to monitor the time and check it against what. The user selected as a time to wake up.
I tought about mainline or timeline and did some test with mainline but cannot get the event firing exactly at the second - it reacts kind of wierd... Any recommendation you can share?
Having said that, I used to include i-Schedule in every project, but found it so clunky to use and so resource intensive, I gave up on it. I wound up writing my own, and the gist of it is a once-a-second timeline that checks the current date and time on each iteration. I then run that through my list of events, and fire them off according to whatever criteria I coded in, which includes one-time events, once-a day events, etc., and the appropriate resets (for example, clearing a "triggered" flag when the date changes if it's a daily event).
Some of the things I've done with timed events are thermostat setbacks, panel pop-ups, and wake-up calls via a modem on the phone system. But I am finding the need for this kind of thing less and less prevalent, as people have so many other apps and options.
I wrote myown. I convert time to digital. Basically seconds since Jan 1. 2000. Then each event is time stamped. From there it's pretty easy to check and see if you need to do something. I will tell you my time stamp checker only checks for minutes first. Then when it hits on something in a minute it granulated to seconds. Thant way I'm not checking every second. In theory, the processor can easily do seconds but I still like to keep things running efficiently as I can.
I didn't even try to do anything accurate to the second, in fact, the module does time checks with a 20 second repeating timeline (checks at least 2 times a minute) and is only settable for day, hour, and minute on the triggers.
DEFINE_VARIABLE Volatile Long lTimes[1] Volatile Integer nPresetTriggered DEFINE_START lTimes[1] = 20000 Timeline_Create(TL_CHECK,lTimes,1,Timeline_Relative,Timeline_Repeat) DEFINE_EVENT Timeline_Event[TL_CHECK] { Stack_Var Integer nPulseTime Stack_Var Sinteger snToday,snThisHour,snThisMinute // To ensure this event only happens one time during the minute If(!nPresetTriggered) { nPulseTime = GET_PULSE_TIME Set_Pulse_Time(600) Pulse[nPresetTriggered] Set_Pulse_Time(nPulseTime) //... do stuff here with the time information snToday = Day_Of_Week(LDATE) snThisHour = Time_to_Hour(TIME) snThisMinute = Time_to_Minute(TIME) If((snThisHour=8) AND (snThisMinute=0) AND (snToday = 2)) { // trigger 8am alarm actions for Monday } } }And I definitely concur with Eric's suggestion that wifi panels not be used as alarm output (like beeping the panel or something). It's ok to have the UI for setting the alarm on a wifi panel as long as it is doing something else like house audio for the waking sounds.
I'm sorry but I utterly disagree with this statement. To the second timing is easy if you use Mainline. Mainline runs hundreds to thousands of times a second, there was a thread about this awhile back. I use mainline for scheduled events whenever I need to do them, it works great. Here is a pseudo code example of how I do it.
DEFINE_PROGRAM if (Scheduled_Events_Enabled) { WAIT 3 { Check_Second = TIME_TO_SECOND(TIME) if (Current_Second <> Check_Second) { Current_Second = Check_Second Check_Minute = TIME_TO_MINUTE(TIME) if (Current_Minute <> Check_Minute) { Current_Minute == Check_Minute //and so on } } //Check for Scheduled events Here using Current_Second, Current_Minute, etc. } } //END of MainlineThis code will execute approx. 3 times a second, and it will only check against the schedule once a second. There are no guarantees but in my experience it has never failed to run very accurately. I have used this code on many projects including extremely large projects with very demanding clients.
I have had issues with long running timelines in the past, and they don't work exactly the way they should. In particular I am referring to the inability to use arrays of timelines in the timeline event, the fact that timeline events have to be the last code in your DEFINE_EVENTS section or none of the code after them runs, and the erratic behavior when using variables for TIMELINE_IDs. I will use them on occasion but only when they don't run for extended amounts of time or they are re-created every time they need to be used. I much prefer using GET_TIMER, adding an offset in 1/10 seconds and checking against it in mainline, much more accurate and reliable in my experience than timelines.
DEFINE_VARIABLE volatile char cVstatReInitTime[8] = '03:23:0?' DEFINE_PROGRAM wait 45 'vstat_time_compare_wait' { IF (compare_string(time, cVstatReInitTime)) { CANCEL_WAIT 'REINIT VSTATS' WAIT 50 'REINIT VSTATS' { HVAC_Auto_Refresh() } } }I don't use mainline, all my code is event driven. So if long running timeline events didn't work in a predictable manner, then my way of doing feedback could not have served me very well for the past 10 or so years. I use a permanently running timeline for feedback, and add another copy of the timeline event directly after every button event that needs feedback.
DEFINE_START lTimes[1]=200 TImeline_Start(TL_FEEDBACK,lTimes,1,TIMELINE_RELATIVE,TIMELINE_REPEAT) DEFINE_EVENT Button_Event[tvTP,1] { Push: nVal1=!nVal1 } Timeline_Event[TL_FEEDBACK] { [tvTP,1] = nVal1 } Button_Event[tvTP,2] { Push: nVal2=!nVal2 } Timeline_Event[TL_FEEDBACK] { [tvTP,2] = nVal2 }I'm not happy about the arrays of timelines thing, but either sequential constants or an indexing array lookup can work around that.
I personally don't use it and prefer event driven programming. I use timelines all the time, both long running, repeating, etc... And have never had an issue with them. For the most part if I find an issue it ends up being in the handling of them which is not an issue of the timelines themselves. I would also note that I usually don't use the timeline event handlers and prefer to do that kind of thing myself. ( things like timeline.sequence and so forth). I find that if I just use a timeline to count time I avoid a lot f the strangeness we see sometimes.
Even though there's nothing 'wrong' with mainline I don't think it's necessary to check the time or some condition 5000+ times a second to see if I can do something. If you're going to do that then why not just run a timeline checking twice or three times a second. You'll get the granularity you need to stay right on the second tick without a whole lot of overhead.
But like I said, there is nothing really wrong with it.
If you actually look at the code you will see that it only checks if the second value has changed 3 times a second. Time comparisons only happen once a second. Not to mention that this is a purely hypothetical instance where Pep_SD asked about the possibility of second accuracy, which is clearly not only possible but easy to accomplish in several ways. Except for a rare exception I don't see the need to schedule anything to second accuracy.
Different strokes for different folks. The way I code for AMX is based on an extensive amount of experimentation and experience. I use what I've found to work well. I was on the "Event driven" thing for awhile, but personally I felt it was limiting.
The point is that we have presented several different options for Pep_SD to try, and he can pick what he likes best, or come up with his own way to do it.
well, I actually did look at the code.
DEFINE_PROGRAM if (Scheduled_Events_Enabled) { WAIT 3 {it checks for the value of Scheduled_Events_Enabled every pass through mainline. Then it checks to see of the wait is done. That's two things to check each pass. It's the stuff inside the barces that enclose the code within the wait that don't fire each pass.
I use this code regularly, it has no significant effect on execution speed. There are many correct ways to do the same thing. Use timelines if that is what you like, it won't bother me. I personally use a different method. There is no harm in keeping an open mind and exploring other solutions, if you feel that your AMX processor is to important to be bothered with checking the state of a variable or two when it has nothing else to do, so be it.
I'm not calling your method into question. I believe you'll see that I made the very point you're clearly being so defensive about. There's nothing wrong with your methhod. Have a nice time on the forum.