Witty Pi’s software/firmware does not do the DST switching (to adjust the RTC time 1 hour forward/backward). This is the case for Witty Pi 1, 2, 3 and 4.
However the runScript.sh programme is actually aware of the DST. This is due to the usage of the “date” command in runScript.sh.
In the runScript.sh file, you can find the extract_timestamp() function, which is used to get the timestamp from the BEGIN and END time.
extract_timestamp() { IFS=' ' read -r point date timestr <<< $1 local date_reg='(20[1-9][0-9])-([0-9][0-9])-([0-3][0-9])' local time_reg='([0-2][0-9]):([0-5][0-9]):([0-5][0-9])' if [[ $date =~ $date_reg ]] && [[ $timestr =~ $time_reg ]] ; then echo $(date -d "$date $timestr" +%s) else echo 0 fi }
The “date” command is used to convert the time string to a timestamp. The timestamp is timezone independent and it always references the GMT, however the input time string represents a local time, which may have DST applied already. As a result, when DST switching happens, the BEGIN time of the schedule script will shift one hour forward/backward in the day, which will cause the scheduled startup/shutdown shifting accordingly.
This is more like an unfinished feature than a bug to us: the software knows about DST, but it doesn’t adjust the clock when DST switching happens. If we adjust the clock (manually or with a programme) during the DST switching, the schedule script should work as expected and it will fully support DST.
It is straightforward to think that we should include the DST clock adjusting into the software to have DST fully supported. This will be however more complicated because it involves when, and how to adjust the clock.
The suggested workaround is to write your own script to adjust the clock accordingly, at a proper moment that before the DST switching.
Hi,
is
The suggested workaround is to write your own script to adjust the clock accordingly
the script syncTime.sh as you suggested for synchronising time/date at boot
@katoendds-nl No, that script has nothing to do with adjusting time/date for DST.
@admin Ok... I think my lack of understanding DST and timesynchronisation sys and RTC gives me a big questionmark 😎 .
But perhaps with explaining what I want will get an answer I understand better . I have trouble changing the schedules around DST-changing.
I want to measure temperature twice a day, just before sunrise ("coldest" moment) and somewhere midday ("hottest" moment). That times varies throughout the year, but I'm satisfied by doing it 2 times a year, around changing DST.
So my script for the winter is to measure at 7 and 13 o'clock:
# Wintertime schedule 7 and 13 o'clock. BEGIN 2023-10-29 07:00:00 END 2026-07-31 23:59:59 ON M5 # keep ON state for 5 minutes OFF H5 M55 # keep OFF state for 5 uur 55 minutes ON M5 # keep ON state for 5 minuten OFF H17 M55 # keep OFF state fo 17 uur 55 minutes
In summertime a like to measure at 6 and 15 o'clock, schedule like this:
# summertime schedule at 6 and 15 o'clock BEGIN 2024-03-31 06:00:00 END 2026-07-31 23:59:59 ON M5 # keep ON state for 5 minutes OFF H8 M55 # keep OFF state for 8 hours 55 minutes ON M5 # keep ON state for 5 minutes OFF H14 M55 # keep OFF state for 14 hours 55 minutes
Through a python-script I let copy these schedules to the schedule.wpi file, for instants just by " sudo cp /home/pi/wittypi/schedule.wpw /home/pi/wittypi/schedule.wpi".
When I do that on the (satur)day before the DST-change, I get strange startup times for sunday, after the DST-change. Can show wittyPi.log later this month.
My other option is to let start the new schedule 1-2 days after DST-change. Will it than automatically take DST-change into account?
Greets,
Bart.
Hi guys,
First, I want to apologize to you for blaming the wittyPi 3 mini not to handle the DST-change well. But it did!!!! Now that I was able to examine my project, somewhere in France, I could see that all the measurements were done well. The only thing that happened was a coincidental lack of internet, so I didn’t get results on my website from the 29th and didn’t see them.
The only strange thing is that on the 29th he only started up once at 11.58.
Date/time |
Temp in C |
stoptime |
starttime |
27-10-2023 06:00 |
16.9 |
27 06:03 |
27 14:58 |
27-10-2023 15:00 |
17.0 |
27 15:03 |
28 05:58 |
28-10-2023 06:00 |
17.2 |
28 06:03 |
28 14:58 |
28-10-2023 15:00 |
16.4 |
29 06:03 |
29 11:58 |
29-10-2023 12:00 |
16.5 |
29 13:03 |
30 06:58 |
30-10-2023 07:00 |
16.5 |
30 07:03 |
30 12:58 |
30-10-2023 12:59 |
16.4 |
30 13:03 |
31 06:58 |
31-10-2023 07:00 |
15.4 |
31 07:03 |
31 12:58 |
31-10-2023 12:59 |
15.2 |
31 13:03 |
01 06:58 |
So, no problems, have a good new year!!!
Best regards,
Bart.