bug in the timealarm library

I have run from 1971 to 2021 without any errors. Are you running the version that increments the time to just below the next trigger or the one that increments by 55 seconds?

Anyway, running in one of your real apps would be a good test.

What I guess I'm asking is not to lose any of the features that have come about because someone needed them

What I was trying to say in my previous post is that a few people needing a feature is not it itself a justification for adding complexity to the API.

I think simplicity is more important than rich functionality

This is the part I prefer I fully agree with you on this and having a two stage complexity that your propose is a very good idea.

I am already using the readType and free method extensively, and will continue to propose/implement myself other feature If I think I need them.

The new version is perfectly woking on my side without issue.

Going a bit further I have an issue with the time_t TimeAlarmsClass::read(AlarmID_t ID) the fact that is returns 01 when failing is a bit strange because if someone set and alarm to 1 seconde after mignight it wont be able to distinguish an error from a real alarm.

unfortunately, I have no answer other than some hackery (for exemple using 111111111 ie 07 / 09 / 73 @ 7:11:51pm EST) which is probably a lot less used than 1 seconde after midnight (but still not the right way of doing it)

This issue is not a big deal for me and I personaly don't care (because user can only set minute precise alarm) but I wanted to share this with you in case you have a better Idea.

Best regards

Vincent

Actually, I've run both. The tests that exceeded the upper limits were the just before trigger time ones. I haven't gotten past 2014 on the 55 second tests. I haven't done any real time testing since it takes so darn long. I have it running right now in a real device, but the first alarm is not for several hours. The timers seem to work fine in it though, I have a lot of them running in it.

Regarding complexity, I can't disagree, but it would be sad to lose working changes that other's might need and subsequently have to reinvent.

Y'know, if you were to post a note in the forum under 'project guidance' I bet a bunch of people would chime in for opinions. Those folks don't seem reluctant to sound off. However, they can be unkind as well at times.

viknet:
Going a bit further I have an issue with the time_t TimeAlarmsClass::read(AlarmID_t ID) the fact that is returns 01 when failing is a bit strange because if someone set and alarm to 1 seconde after mignight it wont be able to distinguish an error from a real alarm.

it returns 0l (thats 0 as a long) not 01

In fact, I have already made a change to define the following in TimeAlarms.h
#define dtINVALID_TIME 0L
my latest version of read returns this constant. Because 0l (0) is not an a valid alarm value it can be distinguished from a real alarm

draythomp:
Regarding complexity, I can't disagree, but it would be sad to lose working changes that other's might need and subsequently have to reinvent.

Perhaps we will have to agree to disagree on this point. I believe that keeping things simple is more important than satisfying every demand.

my mistake...............

sorry for misreading your code , one more question so: could we then setup a daily midnight alarm (AFAIK time goes from 23:59:59 to 0:0:0)

regards

Viknet

viknet:
one more question so: could we then setup a daily midnight alarm (AFAIK time goes from 23:59:59 to 0:0:0)

regards

Viknet

The following will set an alarm to trigger every day at midnight:
Alarm.alarmRepeat(24,0,0, MidnightAlarm);

this will trigger each day at 0:0:0

viknet and draythomp, I made some improvements to the TimeAlarms.cpp to remove some code (the new enumeration was duplicating information in some of the old flags in the data structure. The high level logic should be the same as the last code posted but this version will need a sanity check. You can find the new code here.

Note the Time.h header file has changed so copy that into your Time library directory
Copy the TimeAlarms/beta directory into the TimeAlarms library folder.

If you both get this running ok then I will open it up for wider inspection.

Michael

Uh, kinda make it hard to test

TimeAlarmsTest.cpp: In function 'void onAlarm()':
TimeAlarmsTest:37: error: 'class TimeAlarmsClass' has no member named 'getTriggeredAlarmId'
TimeAlarmsTest:51: error: 'class TimeAlarmsClass' has no member named 'free'
TimeAlarmsTest.cpp: In function 'void loop()':
TimeAlarmsTest:137: error: 'class TimeAlarmsClass' has no member named 'getNextTrigger'

Oh, nevermind, found it.

same issue, had to find the beta directory first :slight_smile:

missing
void TimeAlarmsClass::write(AlarmID_t ID, time_t value,dtAlarmPeriod_t period)
that I added immediatly,

The new isallocated function make code easier to read, but for the sake of my own knowledge, why a function instead of a macro ?

testing tonight and tommorow evening will send you result then.

regards

It is leaking,

I have to see if it is your base code or my modification (new write function)

regards

-------------------------------
Updated:
the dtNBR_ALARMS was back to 6 (from the 8 I am currently using) and that triggered some memory leak, it was there with the previous version and I am not at all sure It come from your sketch, it is probably my code So no issue there, I restart my tests this morning without a memory leak.

perfectly working on my side :slight_smile:

what about you ?

I've had it going in a random fashion from a couple of years back to 5 years forward, starting over when it goes past the upper. Both timers and alarms have been working fine. I also ran it once to failure in the future and no problem came up.

I suggest publishing it and let other folk play with it as much as they want to.

Thanks for the feedback.

I will create a new zip with the directories in the expected places so its less confusing to install and publish tomorrow for wider testing

Here is a link to the beta Library that fixes the weekly alarm problem. The only change from the code I posted above is the directory structure now matches the old library so the contents can be directly copied into the libraries folder. I also added this text in a release note:

Changes made July 5 2011:

This is a beta test version of the libraries that provides a fix for
recurring weekly alarms.

TheTime library is unchanged except for fixes to a macro in Time.h that
converts the number of days to elapsed seconds and the macros that are used
to calculate weekly alarms.

The functionality of the TimeAlarms library has changed slightly in order to
make the library easier to maintain and enhance.

In short, if your application used an Alarm method to create weekly
alarms then you should change your sketch to use the methods that take the
explicit DayOfWeek parameter. Only the Alarm methods are affected,
Timer methods are as before.

Here are the details:
The previous version could set weekly alarms by calling the AlarmOnce method
with a value greater than one day to indicate the day and time of the weekly
alarm. This has changed and explicit calls to set weekly alarms must be used
when setting weekly alarms. If you were setting weekly alarms by calling either
Alarm.alarmRepeat(weeklyValue, AlarmFunction);
then you need to change this to:
arm.alarmRepeat(DayOfWeek, Hour, Minute, Second, AlarmFunction);

Also the clock must be set to a time on or after Jan1 1971 when using the Alarm methods.
Timer methods are unchanged and will function even if the clock has not been set

Lets see how this goes for a day or so and then I will circulate this more widely

Michael

p.s. viknet, note that I did not add in the enhanced write method. As explained in my earlier post, I think the library is better suited for its intended purpose without it so will need to add into your version.

I posted info on the update in a new thread so people would not need to read through the seven pages of background to get to the information on the beta release.

Michael

First, i am noob in arduino and just tinkering arduino.

i make a clock using :

  1. Arduino UNO
  2. RTC DS1307
  3. LCD 16*2

this is how it is work:
==> Visual Basic set RTC time
==> Visual Basic set the Alarm and Save to Arduino EEPROM

and this is the problem that I got:
I have an interval mode alarm, this mode have value to start the alarm, end the alarm, and interval value.
when i compare RTC time and EEPROM value and start the alarm, alarm time is late.
example:
I set the alarm :

  • start time : 13.00 pm
  • end time : 14.00 pm
  • interval : 5 minute

the alarm should 'sound' at 13.05.00 pm (HH.MM.SS), but i get the alarm sound at 13.05.30 and will continue till 14.05.30 pm.

the code is below this post:

:drooling_face: sorry for my english:drooling_face:

the code:

deleted
junk detected

copet_pitik, this thread was reporting a specific issue with the Library so this is not the best place for discussions on help using the library.

I have created a thread for that purpose here and I suggest the we move this discussion there. Can you post a shorter version of your sketch that illustrates the problem so its easer to see if your problem is with Alarms or delays in your code to write to eeprom. It would be easier to help if you can translate comments into english so I can understand the purpose of each of you functions. A summary of the purpose of your sketch and overview of the logic you used to implement it would also help in understanding what your sketch is doing.

Michael