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.
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.
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.
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'
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.
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.
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.
First, i am noob in arduino and just tinkering arduino.
i make a clock using :
Arduino UNO
RTC DS1307
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.
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.