I'm trying to make a set of flows that work together, an "alarms on" with shortcut that sets date and time for alarm to go off (say june 11th, 12 pm, 1215 pm, 1225 pm) as globals, then a second flow that uses "condition" to check the globals, like.. "if current time = global_alarm1 " true then start alarm stuff (basically do other actions) . As my work schedule fluctuates, i wanted something easier to alter than having to change a bunch of time triggers and time range conditions..
so the help i'm looking for is..
How would i set date and time as globals i could easily alter?
How would i make a condition check that global against gettime() or such?
basically go "at the pre-defined date and time, start running other actions for alarm" and then do it at the next one, etc etc.
help with alarm flow.
Moderator: Martin
Re: help with alarm flow.
For the trigger, you need only one alarm: the next one to react to. A trigger exists, firing when date/time, stored in a global variable, is matched.
When an alarm is triggered, next alarm from a sorted list of alarms is copied to that global variable.
Maintaining your alarm list could be done by storing them as - indeed - a list, in another global variable, sorted. For editing, input dialogs for entering dates/times exist.
When an alarm is triggered, next alarm from a sorted list of alarms is copied to that global variable.
Maintaining your alarm list could be done by storing them as - indeed - a list, in another global variable, sorted. For editing, input dialogs for entering dates/times exist.
Re: help with alarm flow.
Yeah but see.. i try to make sure i'm on time. So i set 3 alarms per instance. One 30 minutes before the time i need, one 18 minutes before, and one 5 minutes before.. and at the moment i seem to have different scheduled times and days each week to work, so i wanted something i could quickly change day/time on for these points
Re: help with alarm flow.
Sorry, but I don't understand your "but" - even if you need 10 reminders, it will still be one alarm at a time. Once it triggers, the next alarms is moved in. In consequence, I fail to see the problem you envision. Maybe you think too complex, or maybe I think too simplistic - but my experience indicates that in first case, conceptual simplifying is desirable, and potentially beneficial, as a more satisfactory solution may result from that effort. For example, as you can express 2nd and 3rd alarm following 12 and 25 minutes after first alarm algorithmically, you're freed from entering those manually.
Last edited by Bushmills on 09 Jun 2016 21:39, edited 1 time in total.
Re: help with alarm flow.
Well, i'm still trying to figure out HOW to set these points.. and how to make the system read them.
Re: help with alarm flow.
How about using function addMinutes(), to derive second and third reminder from initial alarm time?
As format to keep date/time/interval related information, I tend to prefer epoche and (milli/micro/nano-)seconds, as these simplify operations like storing, swapping, comparing, calculating, sorting, and change representation only for I/O purposes, even if functions for working on dates/times expressed in a different format (as is the case with Automagic script language) exist. Internally will such data be kept in such a single integer format anyway, in most cases, so I can reap the benefits of such a representation myself.
Also, no need to make the alarm times known to "the system": it suffices to make next alarm time known to the Automagic time trigger (which is done through that mentioned global variable: You / a flow of your design writes alarm time to variable, and when that time is reached, that Automagic trigger fires, possibly causing a joyful noise experience or a less joyful bucket of water, lest interfaced accordingly, and also updates variable contents with next alarm)
As format to keep date/time/interval related information, I tend to prefer epoche and (milli/micro/nano-)seconds, as these simplify operations like storing, swapping, comparing, calculating, sorting, and change representation only for I/O purposes, even if functions for working on dates/times expressed in a different format (as is the case with Automagic script language) exist. Internally will such data be kept in such a single integer format anyway, in most cases, so I can reap the benefits of such a representation myself.
Also, no need to make the alarm times known to "the system": it suffices to make next alarm time known to the Automagic time trigger (which is done through that mentioned global variable: You / a flow of your design writes alarm time to variable, and when that time is reached, that Automagic trigger fires, possibly causing a joyful noise experience or a less joyful bucket of water, lest interfaced accordingly, and also updates variable contents with next alarm)