I have got a problem that the WittyPi 5 on a RPi 5 stops waking up the Raspberry Pi after a couple of days without any problems.
Configuration:
ON for 75 seconds
OFF for 13 minutes and 45 seconds
Making it a 15-minute cycle
First on at 17:45:00
End at 05:16:15
OFF for the rest of the day
Making it a 24-hour cycle in total.
Start again at 17:45:00
Running for 35 days
I have checked that all preconditions (e.g. file size, number of permitted on/off states, number of lines are within the specified limits.)
Latest Witty Software
Firmware at 1.5
Here are cuts from the firmware log:
- When everything is working fine:
…
[09-12 16:44:59.757] External I2C slave address: 0x51
[09-12 16:44:59.760] Woke up by RTC alarm.
[09-12 16:44:59.761] Will startup in 0 second.
[09-12 16:44:59.761] Scheduled startup is due.
[09-12 16:44:59.762] Switch to STARTING state.
[09-12 16:44:59.771] Raspberry Pi is powered by Vin (13266mV).
[09-12 16:44:59.773] Raspberry Pi is starting up.
[09-12 16:44:59.774] Found future actions from /schedule/schedule.skd
[09-12 16:44:59.775] Shutdown is scheduled to: 2026-09-12 16:46:15
[09-12 16:45:00.018] Set Alarm2 to 12 16:46
[09-12 16:45:04.587] Eject USB MSC device.
[09-12 16:45:05.463] conf file info updated.
[09-12 16:45:15.949] Switch to ON state.
[09-12 16:45:58.053] Will shutdown in 15 second.
[09-12 16:46:13.995] Scheduled shutdown is due.
[09-12 16:46:13.995] Switch to STOPPING state.
[09-12 16:46:13.997] Raspberry Pi is shutting down.
[09-12 16:46:13.998] Found future actions from /schedule/schedule.skd
[09-12 16:46:13.999] Startup is scheduled to: 2026-09-12 17:00:00
[09-12 16:46:14.159] Set Alarm1 to 12 17:00
[09-12 16:46:14.868] conf file info updated.
[09-12 16:46:28.065] Cut Raspberry Pi's power.
[09-12 16:46:28.065] Switch to OFF state.
[09-12 16:46:28.066] Entering hibernation...
[09-12 16:46:40.209] External I2C slave address: 0x51
….
And this is the last entry before the Witty freezes and did not start the RPi from then on:
…
[09-16 04:44:58.234] External I2C slave address: 0x51
[09-16 04:44:59.019] Eject USB MSC device.
[09-16 04:44:59.195] Will startup in 0 second.
[09-16 04:44:59.196] Scheduled startup is due.
[09-16 04:44:59.197] Switch to STARTING state.
[09-16 04:44:59.206] Raspberry Pi is powered by Vin (12938mV).
[09-16 04:44:59.208] Raspberry Pi is starting up.
[09-16 04:44:59.223] Found future actions from /schedule/schedule.skd
[09-16 04:44:59.224] Shutdown is scheduled to: 2026-09-16 04:46:15
* [09-16 04:44:59.510] Failed to re-enter hibernation after pulse wake: -14
* [09-16 04:44:59.512] Set Alarm2 to 16 04:46
[09-16 04:45:04.291] conf file info updated.
[09-16 04:45:14.961] Switch to ON state.
[09-16 04:45:59.290] Will shutdown in 15 second.
[09-16 04:46:13.241] Scheduled shutdown is due.
[09-16 04:46:13.241] Switch to STOPPING state.
[09-16 04:46:13.243] Raspberry Pi is shutting down.
[09-16 04:46:13.258] Found future actions from /schedule/schedule.skd
[09-16 04:46:13.260] Startup is scheduled to: 2026-09-16 05:00:00
[09-16 04:46:13.431] Set Alarm1 to 16 05:00
[09-16 04:46:14.138] conf file info updated.
[09-16 04:46:29.291] Cut Raspberry Pi's power.
[09-16 04:46:29.291] Switch to OFF state.
[09-16 04:46:29.450] Entering hibernation...
[09-16 04:46:39.738] External I2C slave address: 0x51
…
The lines marked with an * were not there before when everything was working fine.
- So, what does the line “Failed to re-enter hibernation after pulse wake: -14” mean? Is there any clue telling us what has happened here?
About half a dozen OFF states before, those messages start to appear (sometimes with : -12 as opposed to :-14 are shown). If possible, I shall add the entire log to this post.
- Is it possible that the observed effect may have gone after installing the1.6 version of the firmware, what I have done meanwhile? But I have not run any test after that yet.
- When discussing this with AI, the bot insisted that this would be an effect of the Witty writing into its own log file while already shutting down the system and thus causing a crash. I was strongly advised to disable Witty creating the firmware log.
Now, I don’t trust AI from here to around the next corner, so what is your opinion on this explanation?
- Why are there so many […] External I2C slave address: 0x51 entries in the log, is that normal?
Thank you for any help you may be able to provide.
I have tried to attach the entire log file but despite that it is only about 2.7 MByte the forum systems says it is too big. Will try to attach the zipped log, as it is much smaller then.
And this is the script file, which was in use. Also zipped because the forum SW does not allow *.wpi files.
Had the same problem again last night after updating to Firmware 1.6: The system was halted by the Witty after 2 hours as planned, but never activated again. The white LED was still flashing this morning. No Log this time, since I had turned it off. Since that does not make a difference I will activate it again the coming night. All I have done is resetting the Witty and turning the Log back on.
When I un-powered the system this morning and turned the power back on then the system came up and the Witty was accessible and showed the correct time as well as the next coming event. That looked all good except that it did not come back on last night.
Thanks for reporting this, and especially for providing the complete log. I have been investigating it over the past couple of days and I believe I have found the cause.
There is a race condition between the periodic low-power wake-up used by Witty Pi 5 and the RTC alarm.
When Witty Pi 5 is OFF, the RP2350 periodically wakes up briefly to perform some background checks and then goes back into hibernation. In a very narrow timing window, the RTC alarm can occur while the RP2350 is still initializing after one of these periodic wake-ups.
The firmware was clearing the RX8025 RTC alarm flag during RTC initialization, before the alarm event had necessarily been processed. If the RTC alarm happened in exactly this window, the alarm flag could be cleared and the interrupt released before the firmware handled it. The scheduled startup would then be missed, while the RP2350 itself continued to wake periodically. This matches the behavior seen near the end of your log.
I was able to reproduce this issue locally by deliberately enlarging that timing window. With the original logic, the scheduled startup was lost. I then modified the firmware so that a pending RTC alarm is preserved and handled even if another wake source woke the RP2350 first.
I have also tested the fix with the timing window deliberately enlarged. The problematic condition was triggered multiple times during the test, and each time the pending RTC alarm was detected and the Raspberry Pi started normally.
So the fix looks promising. I still want to clean up the test instrumentation and do some additional regression testing before finalizing it. I plan to commit the patch to the GitHub repository once that is done.
A new firmware release may come a little later, since I would like to give the change some additional testing before publishing a new version.
Thanks again for reporting this issue and for the detailed logs — they were very helpful in tracking this down.
Hello,
We have been experiencing the exact same issue. The system has stopped activating without any apparent reason.
Would it be possible for us to unofficially receive the new patch so that we can deploy it on our unit?
We are currently conducting R&D activities and need to deploy the unit as soon as possible, so we would greatly appreciate any support that could help us proceed without further delay.
Thank you so much for attending to this problem so quickly and finding a solution :-).
Since we are also about to deploy our systems as part of a research project, which will be sampling data over a 35 day- period in the middle of the four seasons over an entire year. If we miss our first deployment, we will have a 3 month-delay in our planned schedule. Since these systems are out in the Australian bush more than 500 km from base it is not possible to frequently check the status while recording.
So, we are also extremely keen to get a working solution, which would allow us to perform the regression testing of our own stuff and deploy the systems as planned. We have the same wish as expressed by Nikolas. Can we have a preliminary fix even if you keep testing? I am happy to keep reporting the results when continuing our own tests.
Alfred
The fixing for this issue has been commited to GitHub this morning:
https://github.com/uugear/Witty-Pi-5-Firmware/commit/795da21306f4d056f89d573228eb39da5ef5c90c
I have installed the missing tools on my RPI and then the Build was successful. Meanwhile I have installed the updated firmware on the WittyPi.
Thanks again for this quick fix.