WittyPi L3V7 auto startup fails unpredictably

Pi Zero 2 W like yours. Same OS, newer kernel. Same daemon v4.21. Same firmware 0x77, same f/w revision 0x07.

I have a USB 5V power supply connected, and a Li polymer cell connected all the time (unless in a blackout, which is when the Pi will be gracefully shut down immediately because of the low voltage setting of 4,2 V).

The lines with '>>> ' after the time stamp in the log excerpt below originate from my afterstartup script, which re-enables and starts chrony and then waits for the Pi's system clock to be synced with the internet (as per parsed timedatectl output) before writing the system time to the RTC. They have no relation to the problem discussed here.

I don't see any 'Current Vin=...' in my log. How is this possible?

In your log the 'Schedule next' line are present two times. How come? (My Pi runs all day every day, except for two minutes from 2.28 to 2.30.)

Are you perhaps running your Pi on battery only? Your Pi's battery may be running low after 100 startups and have too low current supply capacity? However the Vin= is generated, the value in your log is close to the 3,1 V that is the default low voltage.

[xxxx-xx-xx xx:xx:xx] Witty Pi daemon (v4.21) is started.
[xxxx-xx-xx xx:xx:xx] System: Raspbian GNU/Linux 12 (bookworm), Kernel: Linux 6.12.20+rpt-rpi-v7, Architecture: armhf
[xxxx-xx-xx xx:xx:xx] Running on Raspberry Pi Zero 2 W Rev 1.0
[xxxx-xx-xx xx:xx:xx] RTC offset register has value 0x77
[xxxx-xx-xx xx:xx:xx] Seems RTC has good time, write RTC time into system
[xxxx-xx-xx xx:xx:xx] Writing RTC time to system...
[2025-04-11 02:30:21] Done :-)
[2025-04-11 02:30:21] Firmware ID: 0x37
[2025-04-11 02:30:21] Firmware revision: 0x07
[2025-04-11 02:30:21] Current Vout=5.19V, Iout=0.25A
[2025-04-11 02:30:21] System starts up because scheduled startup is due.
[2025-04-11 02:30:26] >>> Executing afterStartup.sh
[2025-04-11 02:30:26] >>> Re-enable chrony service after start-up
[2025-04-11 02:30:26] >>> as Witty Pi disables NTP service ...
Synchronizing state of chrony.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable chrony
[2025-04-11 02:30:27] Schedule next shutdown at: 2025-04-12 02:28:00
[2025-04-11 02:30:27] Schedule next startup at: 2025-04-12 02:30:00
Created symlink /etc/systemd/system/chronyd.service → /lib/systemd/system/chrony.service.
Created symlink /etc/systemd/system/multi-user.target.wants/chrony.service → /lib/systemd/system/chrony.service.
[2025-04-11 02:30:46] Writing system time to RTC...
<2025-04-11 02:30:47> Done :-)
[2025-04-11 02:30:47] Send out the SYS_UP signal via GPIO-17 pin.
[2025-04-11 02:30:47] Pending for incoming shutdown command...

Posted by: @electrobee

↑

What could be potential sources of error?

With only the logs, it would be difficult to locate the problem, because many important information are missing:

• Did the device shutdown properly as scheduled?
• Was there ever any failure on power supply?
• Did the MCU get reset due to power interference or electromagnetic interference?

Information like this will need you to observe the device closely, and get help from monitoring tools. With just logs we can only see what happened after the device is properly boot up.

Posted by: @electrobee

↑

Halting all processes and then shutdown Raspberry Pi...

Why this line (without any time information) got printed everytime you run your own script for configurating the schedule? Did your script actually shut down the device after the configuration? Also why your script schedules the startup and shutdown twice?

@arjenr

Posted by: @arjenr

↑

I don't see any 'Current Vin=...' in my log. How is this possible?

It is because your always connect 5V to the USB-C connector. The Vin gets printed when only battery is connected to the device.

Posted by: @arjenr

↑

Your Pi's battery may be running low after 100 startups and have too low current supply capacity? However the Vin= is generated, the value in your log is close to the 3,1 V that is the default low voltage.

@arjenr Yes, that is indeed possible.

Thank you for your replies.

A scanning device is attached to my Pi's USB hub. Once the Witty triggers startup, the Pi's 5V are powered which causes the scanner to perform initialization (moving its head, activating lights, searching the head's start position). This is controlled by the scanner's internals every time it receives 5V (independent from data signal). This extra power consumption during the Pi's boot phase causes the boot to interrupt and the Pi is knocked out before the scheduleScript can be run -> it stays off forever.

What irritates me is that when (after some hours) I start the Pi by clicking the button, it does can perform more scans without dying. Maybe the battery "recovered" after some waiting?

Would it be possible to just skip a schedule and resume with the next one to get to the last drop of juice in the battery? (Probably not?)

Other work arounds (but not part of this forum): Is there a way to delay the 5V power on of the Pi's USB port? Or to delay /skip the scanners initialisation?

EDIT:

RPi Zero 2W has its USB 5V connected to its input 5V, decoupling them in any way cannot work, unfortunately...

However: How does the WittyPi's under-voltage detection work exactly? Anytime the input voltage drops, it simply kills the Pi? Does it check before boot? During boot? Or only when the Pi is running? Can I see in the logs (which logs) if under voltage was the problem and not powering on was Witty's decision and not "nature's decision"?

The reason I run scheduleScript twice is simple: The first run ensures that the next startup is scheduled. The second one checks/waits for a USB stick to be mounted. If there is a new startup interval in a user updated config file, its read and I run scheduleScript again. This ensures that it keeps powering even if users forget to attach a new USB with their favourite config.

Posted by: @electrobee

↑

How does the WittyPi's under-voltage detection work exactly?

It depends on your Pi's state as well as how quick the input voltage drops.

If your Pi is running and the input voltage drops under the limit (but still good enough to keep Pi running), Witty Pi's firmware will detect it and trigger a shutdown by emulating a quick press on the button. However if the voltage drops too quick and too much, there may be no time for that and the Pi could just got power cut directly.

If your Pi is off, and the input voltage is under the limit, the expected startup will not happen. Even pressing the button would not start your Pi.

Witty Pi's firmware can only see voltage, and it is difficult to figure out when there is the last drop of juice in the battery: batteries behave differently. The best bet is to always keep enough energy in the battery and try not to push the limit. When the battery is not deliverying enough current, the voltage may change according to the load, and the result will be random: sometimes it boots well, and sometimes not.

Posted by: @electrobee

↑

Is there a way to delay the 5V power on of the Pi's USB port?

You may achieve this by making a special USB extension cable, which always delay the Vusb on the other end for some time. A delay switching circuit should be implemented there.