Best Data model/Concept to Store Multi-Day Alarm for clock?

Question

I'm writing a multiday day alarm program for a project.

I'm not sure how I want to store the format of each of 10 alarms....I need to store it...in SPIFFS retrieve it(at boot) and then compare it to the current day of the week and time so as to fire off the alarm..I was thinking of storing it in a 10 member array.

First alarm would be every day at 2PM and the second is turned off but would be Mon tues Thursday at 10AM. was going to use strtok_r to extract all of the pieces and compare them every minutte to see if an alarm is needed.

Every minute

{"1|M|T|W|T|F|S|S|14|00","0|M|T||T|||S|10|00"}

Answer 1

I would suggest a bit field for storing the days of the week when the alarm is supposed to fire:

• bit 0: fire on Sundays
• bit 1: fire on Mondays
• ...

This numbering is meant to match the one of DateTime::dayOfTheWeek().

Pack this, together with the hour and minute of the alarm, in a struct (or a class if you prefer). Maybe add a boolean to tell whether the alarm is active. For example:

struct Alarm {
    bool is_on;
    uint8_t days;  // bitfield: 0 = Sunday
    uint8_t hour;
    uint8_t minute;
    bool matches(DateTime) const;
};

bool Alarm::matches(DateTime t) const {
    bool day_matches = days & (1 << t.dayOfTheWeek());
    return day_matches && t.hour() == hour && t.minute() == minute;
}

Then if (alarm.is_on && alarm.matches(rtc.now())), the alarm fires.

Answer 2

That would work. Though I feel like your solution isn't easily readable by humans, and also not easily readable by machines.

Removing the |s, making the data a fixed length, and putting each alarm on separate line, would help with both. You'd get something like

ON  MTWTFSS 14:00
OFF MT T  S 10:00

Because the data-string is of a fixed length, you know where the data you want is inside the string. So your code can, for example, check the 7th character, to see if it needs to turn on/off on Wednesday. Or check the 13th and 14th character to get the hour. And so on.

But you'd have to decide what's important to you. Human readability, machine parseability, compactness (storing it as binary data, like Edgar said), standardized format (Cron-style), Extensibility (for example the option to add seconds, somewhere in the future), ease of implementing.