Hello,
I’m having an issue with my Witty Pi 4 Mini where, as you can see in the video, when I press the power button the system turns on briefly and then immediately shuts down again. So it’s not completely dead, but it cannot stay powered. I actually have two different Witty Pi 4 Mini boards showing the exact same behavior.
Before this happened, I was using a schedule like this (as far as I remember, not 100% sure) :
BEGIN 2026-03-31 00:00:00
END 2036-03-31 00:00:00
ON M4 S55
OFF S5
My suspicion is that the board is somehow stuck in a state where it immediately triggers a shutdown, for a reason I don’t fully understand. It really looks like some kind of internal dead lock or alarm state that never gets cleared.
I doubt this is a hardware issue since I ended up in the same situation with two different Witty Pi 4 Mini boards. At this point, I’m not only trying to recover the boards, but also to understand what exactly causes this behavior so I can avoid it in the future.
Is there any way to perform a hard reset on the Witty Pi 4 Mini (considering I cannot get the Raspberry Pi to stay powered long enough to interact with it)?
Also, when I boot the Raspberry Pi directly (without the Witty Pi), I checked the points mentioned in the documentation: the I2C interface is enabled, the Serial Port is enabled, the 1-Wire interface is disabled, and the GPIO pins are in the expected states.
For reference, I am using a headless Raspberry Pi OS (Raspbian Bookworm) on a Raspberry Pi Zero W. Here is my system configuration:
===== SYSTEM ===== Linux xxx 6.12.47+rpt-rpi-v6 #1 Raspbian 1:6.12.47-1+rpt1~bookworm (2025-09-16) armv6l GNU/Linux ===== OS ===== PRETTY_NAME="Raspbian GNU/Linux 12 (bookworm)" NAME="Raspbian GNU/Linux" VERSION_ID="12" VERSION="12 (bookworm)" VERSION_CODENAME=bookworm ID=raspbian ===== KERNEL CMDLINE ===== console=tty1 root=PARTUUID=1aa24f6e-02 rootfstype=ext4 fsck.repair=yes rootwait cfg80211.ieee80211_regdom=CH ===== CONFIG.TXT (filtered) ===== dtparam=i2c_arm=on dtparam=spi=on dtparam=audio=on dtoverlay=vc4-kms-v3d dtoverlay=dwc2,dr_mode=host dtparam=i2c1=on dtoverlay=miniuart-bt enable_uart=1 ===== I2C DEVICES ===== /dev/i2c-1 /dev/i2c-2 ===== I2C SCAN ===== 00: 08 -- -- -- -- -- -- -- ===== GPIO STATE ===== GPIO2 (SDA1): high GPIO3 (SCL1): high GPIO14 (TXD0): high GPIO15 (RXD0): high ===== LOADED MODULES ===== i2c_dev i2c_bcm2708 i2c_bcm2835 ===== THROTTLING ===== throttled=0x0 ===== DMESG ===== i2c_dev: i2c /dev entries driver
Also I tried various power supplies, but my main one should be more than sufficient (lab power supply set to 5V 6A). I also tested without the relay, with different wires, etc., and nothing has helped so far. The setup had been working perfectly for a while before this issue appeared.
Thanks for your help.
Yann
UPDATE : As an additional update, I finally managed to power it on properly by manually shorting the SW / SWITCH and GND pins. I’m not entirely sure why it worked this time, but it allowed the system to stay on long enough to access it. Once I had access, I was able to synchronize the time and load a new schedule, and now everything is working again.
One more detail that might be relevant: I had previously modified the "power cut delay after shutdown" setting and set it to 0 seconds, because I was trying to minimize how long the system stays powered on. I have now set it back to the default value of 7 seconds. I’m not sure if this could have contributed to the issue, but it might be worth mentioning.
UPDATE2 : I finally found the root cause while trying to recover my second board.
The issue was actually coming from the “power cut delay after shutdown” setting. It works fine if I set it to 1 second (or higher), but as soon as I set it to 0, I end up in a situation where I can no longer boot the board using the button — it powers on briefly and then immediately cuts off.
So it looks like setting the delay to 0 makes the board think the system is already off right at startup, which causes it to cut the power instantly.
Just sharing this in case it helps someone else running into the same issue.