Beeminding a daily event in order to do it earlier

Hi folks! Got a bit of a stumper here.

I’ve written an integration for tying something I do everyday to Beeminder. I’m trying to think of how to actually structure the data and the goal. I have premium, so I can set the aggday, and I am writing the integration, so I can do whatever I want over there.

I would like to do this thing earlier in the day, or even the night before. Ideally, it’s done before I go to bed, but there’s absolutely no value in doing it any earlier if it’s done the day before… but if it’s done the day of, the earlier the better. I am usually asleep across midnight, so setting the floor at midnight seems reasonable.

I want the graph to mostly make sense, and be able to tell if I’m trending earlier or later… or am being inconsistent.

Because I want to do the thing earlier in the morning, I am thinking of doing it as a Do Less goal, even though I don’t really do those in general.

One option (a poor one, but an ok example) is to have my integration report 0 if it’s been done, and 1 if it hasn’t. As Beeminder pokes the integration, the goal will get a series of 1s and then 0s. I could set the aggday to sum, and days with higher values, in general, correspond to days where I did it later. This isn’t very good though, because if I hit Refresh on a goal a bunch of times, it will add a bunch of datapoints. Also, Beeminder’s schedule is kinda complicated, and isn’t really linear.

Another option is to have my integration report the time (in hours since midnight) that the event occurred at if it happened already, otherwise… what, not add a datapoint? Then the aggday could be “last”, maybe? The bummer here is that my integration would have to have state, but that isn’t an insurmountable task.

Another option is that I put a bunch of smarts in my integration, and I handle all the “aggday” stuff in my integration. The integration would store the time that the event happened for the day, and it would only add one datapoint per day.

Thoughts? Has anyone successfully or unsuccessfully Beeminded doing something earlier in the day? What worked or didn’t work for you?

1 Like

I’ve been trying to do something like that to get to work earlier and get to bed earlier.

If the ideal is to do it at, say, 9pm, why don’t you set your deadline at 9pm and use aggday = first to count the number of minutes after 9pm you first do the thing, and then you try to keep the total number of minutes below a threshold?

Like I have a DoLess goal that allows me 40 minutes a day, where the units are “minutes past 1am I go to bed.” So going to bed at 1:40 am each night keeps me level. If I go to bed later, I’ll have to make up for it by going to bed earlier the next day, if I have enough slack.


I find that goals structured like that don’t work very well for me. I’ve done that before, also with sleep. I didn’t end up liking how it worked out for me at the end, since it coupled my current desired bedtime to both my datapoints and my road.

I am making progress on this integration, and I think I’m going somewhat toward the second option, where I am posting time in HH:MM since midnight, and I use the road to establish my goal, and the datapoints are relatively agnostic.

If I post a zero to the goal when I have no Overdue but Undone tasks (OBUTs), I think my biggest issue would be days when I never ever do this task–then the goal would have a 0 value. If I post a 23:59 to the goal when I have no OBUTs, and post the current time once I succeed, then I overshoot. I was initially against the overshoot, but I think it might be OK.

I am super, super open to feedback. I used to have a lot of goals like this, but I didn’t really like how they were built at the time. I know other people still have things like this, so I’m hoping someone else has advanced the state of the art here :slight_smile:

1 Like

Can you explain what you mean by this? I don’t understand how it’s coupled to anything. With the setup I described, my current desired bedtime is always 1am and that’s uncoupled.

Here are a couple other ideas for you:

  • give yourself 2 points if you do it before bed the previous day and 1 point if you do it before 2pm that day, and you need to get, say 5 points a week
  • set up one goal to do it every day (7/wk), one goal to do it before noon (4/wk), and one goal to do it before bed the previous day (2/wk)

I don’t understand why you would post the time since midnight - makes more sense to post the number of minutes after 9pm the previous night, and have a separate goal for whether you did it at all.

If you change your desired bedtime to 12:30, what do you do to all your old datapoints? Add minutes to them? That’s what I mean by the goal (go to bed by 1 AM) being coupled with the datapoints.

For this goal, by putting in hours after midnight, I get easy to read datapoints… If my integration breaks, and I get the Marvin task done by 9:43 AM, I enter a datapoint of 9:43. I can start out with a goal of doing them by noon, setting my road to 12 hours/day (corresponding to "get it done by noon on average), and as I get good at that, I can change my road to 9 hours/day (corresponding to “get it done by 9AM on average”), and all my old datapoints are still reasonable. Hours past midnight is kinda slick because if I get close to the edge of the road, and have to get my task done by 8:30 AM, the deadline text will tell me I have 8:30 remaining.

I’m not advocating the hours past midnight for every timey-wimey goal or anything, but I think it has a lot of UI upsides that come “for free” for this.

I know a lot of people do the points thing to great success, but this is replacing a points-y goal that wasn’t working well for me.

I coded it up and set it up on Glitch yesterday, so we will see how it goes :slight_smile:


I may not be completely understanding the goal’s structure here, but if I am, I’d probably do something like:
aggday: min
cumulative: no:
good side: below
direction: down
plot all: no
and I’d log the time and set the slope however you’d like so you’re doing it earlier and earlier.

I’d set the deadline to the time past which you never want to go on a given day (for that day), and before which you’re very unlikely to / it’s useless to do it for the next day.

Then I’d have it log the time at which it gets done, and whenever it’s done the day before (if after the deadline), I’d enter a negative datapoint that represents hours before midnight. If you do it on the 17th at 8:00am, you’d have a datapoint of 8.00 and if you did it the night before, on the 16th at 10:30 pm, you’d have a datapoint of -1.5. (I’m presuming that 10:30 PM would be after the deadline, so both scenarios would be recorded for the instance meant for the 17th.)

Then, if the integration keeps sending datapoints after you first get it done, they’ll be recorded but not on the graph.

That way the graph is always linear and meaningful, and it would be trivial to fiddle with the CSV to give you the actual pre-midnight times if you ever wanted them. You could even keep bringing the road down until it was in the negatives, eventually forcing it to be done the day before.

Does that help, or did I completely miss what you were after?

FWIW, I have the same goal as @zedmango (except at midnight instead of 1am), and if I was ever in a position to move it earlier, I would just redefine the new datapoints as being “minutes past 11:30” instead of the current “minutes past midnight”. The previous datapoints would still indicate how well I did at sticking to my intended bedtime, as would the current ones, which would be entirely sufficient for my purposes.

Curious to see how your planned method works!

I must be missing something - why on Earth would I change my old data points?

Lanthala’s approach makes sense, but the way I set up my goal, if I were to change my desired bedtime, I would do it by changing the SLOPE.

Remember, in my plan, my desired bedtime is 1:40pm, the units are minutes past 1 am, and so the slope is 40.

If I changed my desired bedtime to 12:30 because I suddenly lived in a dream world where I could fall asleep that early (if only!), I would implement that by changing the slope to -30.

1 Like