RTC alarm IRQ's


I am porting an old project which I wrote for a STM32L152 to the Particle Photon and I have some questions.

First I will describe the current project. I am using a STM32 Discovery board, a DCF77 time receiver and a stepper motor controller. With the DCF77 I receive the current time, I am calculating the sunset time per day, and at sunset time, I close the door of my chickenhouse :slight_smile: Everyday at 8.30 in the morning, Door is open.

Now, I planned to use the SparkTime library from @bko because of the DST integration. But I also would like to use RTC alarms. The Timealarms library is written for the internal time library and that library is not able to use the automatic DST.

Previously, I have used the SetAlarmIT functions on my STM32L152 board. Is this also an option to use on the Photon?

Or how is it possible to use RTC alarms and the time function with DST?

As a complete alternative… Have you considered using an online service for getting those times? Using IFTTT with the Weather Underground applet would allow you to get the sunrise/set times very easily.
You might be able to get the times directly with a webhook as well.

I haven’t, but have you checked whether the automatic DST adjustment in that lib is compatible with CET/CEST?

I have written my own isDST() function for this time zone and I hope that Particle will rather sooner than later come up with a proper DST feature in their Time class.
But till then, I regularly call this in my time dependent projects

  Time.zone(isDST() ? +2.00 : +1.00);

And then you can use Time just fine.
SparkTime is a well written lib and was required in the early days when Time wasn’t very useful, but nowadays I see little benefit in using it for just the DST feature alone.

BTW, your topic title talks about RTC IRQs, but neither TimeAlarm nor SparkTime seem to use RTC interrupts. Do you actually intend to use interrupts or would polling do too?

There is a function isEuroDST() but as it seems that’s not for CET/CEST but for WET/WEST (GMT/BST)

bool SparkTime::isEuroDST(uint32_t tnow) {
  // 1am last Sunday in March to 1am on last Sunday October
  // can't use offset here 

this should be 2am for CET/CEST


Yes, I have considered the online alternative, but I don’t want to be fully dependend on my WiFi. When using the RTC and calculating the sunset time everyday, I only need a RTC update once a day or maybe once a week since the time accuracy is not an issue in this application.

Indeed, I need the CET/CEST. But when using a time server with the WET/WEST time and always add 1 extra hour, this library would work also. for my application i guess.

How is your isDST function look like?

I see that the TimeAlarms library is not using IRQ’s. Polling would work as well since my code is doing only a sunset calculation and open/close a door once a day.
But I was used to use the SetAlarmIT function in the STM32L1 so I would like to use it again.

Thanks for you replies

This is my function

bool isDST()
{ // Central European Summer Timer calculation
  int dayOfMonth = Time.day();
  int month = Time.month();
  int dayOfWeek = Time.weekday() - 1; // make Sunday 0 .. Saturday 6

  if (4 <= month && month <= 9)
  { // month between April and September definetly DST
    return true;
  else if (month < 3 || 10 < month)
  { // before March or after October is definetly normal time
    return false;

  // March and October need deeper examination
  boolean lastSundayOrAfter = (dayOfMonth - dayOfWeek > 24);
  if (!lastSundayOrAfter)
  { // before switching Sunday
    return (month == 10); // October DST will be true, March not

  if (dayOfWeek)
  { // AFTER the switching Sunday
    return (month == 3); // for March DST is true, for October not

  int secSinceMidnightUTC = Time.now() % 86400;
  boolean dayStartedAs = (month == 10); // DST in October, in March not
                                        // on switching Sunday we need to consider the time
  if (secSinceMidnightUTC >= 1 * 3600)
  { // 1:00 UTC (=2:00 CET/3:00 CEST)
    return !dayStartedAs;

  return dayStartedAs;

This might seem clumsier than the one used by @bko, but this doesn’t use a list of predefined switching dates and should (in principle) work beyond 2036

1 Like

Thank you, I will try to implement this one and figure out how to use the RTC IRQ’s. In the meanwhile use polling…