[Mark Solved / Archieved] Witty Pi 4 L3V7 schedule revising after interruption

It seems to be a combination of multiple possible issues here.

What kind of battery are you using? What is its capaicity? Does the device have USB-C power connected all the time?

For the 1st case, it is likely that the runScript.sh hang when accessing the I2C interface, and hence nothing output. However hanging on I2C communication is rather rare, and it occurs usually due to other problems (e.g. low voltage, abnormal I2C device behavior).

The 2nd case is very strange, because when the script said it was revising the schedule, it then made a totally "normal" schedule. I do not see how this could be possible yet. Please provide the schedule script you are using, and hopefully there is something that can explain this.

The "interruption" is just to check the current time against the schedule, and update the schedule if necessary. It really should not bring the whole device into an unknown state.

The unknown state (Red LED is ON, all other LEDs are OFF, makes a weird buzzing sound) seems like the battery is out and the whole device is underpowered. Have you measured the battery voltage at this state? Do you have a video that shows how it behaves in such state?

Hello 

For the battery we are using the voltaic75 always power bank with a 8800mAh lithium DC battery. 

We have figured out the issue for the first case.

For the second one:

We have our own schedule other then the witty pi software, the file schedule.sh:

#!/bin/bash
#schedule.sh
export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
source "$SCRIPT_DIR/../shared/utilities.sh"
source "$SCRIPT_DIR/../.env"

MODULE="schedule"

schedule()
{
  log INFO "Start scheduler..."
  # If 5V connected, schedule normal active hours
  battery_mode=$(get_battery_mode)
  if [ $battery_mode -eq 1 ] || [ $battery_mode -eq 2 ]; then
    log INFO "5V power connected, schedule daily active hours..."
    CONTENT=$(cat <<EOF
BEGIN   2026-04-01 08:00:00
END     2036-12-31 23:59:59

ON      H12
OFF     H12
EOF
    )
    generate_schedule_script "$CONTENT"
    sync_scheduler
  fi

  # Monitor 5V in the background
  log INFO "Start monitoring 5V power..."
  while true; do
    # Check state every X seconds
    if [ $DEBUG = "True" ]; then
      sleep 3
    else
      sleep "$CHECK_STATE_INTERVAL"
    fi
    # Check if data is being uploaded to remote
    if [ -f "$UPLOAD_FLAG" ]; then
      continue
    fi
    # Monitor 5V
    battery_mode=$(get_battery_mode)
    if [ $battery_mode -eq 0 ] || [ $battery_mode -eq 3 ]; then
      log INFO "5V power disconnected, shutdown..."
      BEGIN=$(date +"%Y-%m-%d %H:%M:%S")
      if [ $DEBUG = "True" ]; then
        END=$(date -d "2 minutes" +"%Y-%m-%d %H:%M:%S")
      else
        END=$(date -d "3 days 08:00:00" +"%Y-%m-%d %H:%M:%S")
      fi
      # time that system is actually OFF
      SEC_BEGIN=$(date -d "$BEGIN" +%s)
      SEC_END=$(date -d "$END" +%s)
      DELTA_SECONDS=$(( SEC_END - SEC_BEGIN - DELAY_SHUTDOWN))
      days=$(( DELTA_SECONDS / 86400 ))
      hours=$(( (DELTA_SECONDS % 86400) / 3600 ))
      minutes=$(( (DELTA_SECONDS % 3600) / 60 ))
      seconds=$(( DELTA_SECONDS % 60 ))

      CONTENT=$(cat <<EOF
BEGIN   $BEGIN
END     $END

ON      S$DELAY_SHUTDOWN
OFF	D$days H$hours M$minutes S$seconds
EOF
      )
      generate_schedule_script "$CONTENT"
      sync_scheduler
      touch "$SHUTDOWN_FLAG"
      break
    fi
  done
}

schedule

For the unknown state, after reviewing the attached video, we noticed that the battery LED was ON, so we believe it was not a power supply issue. However, after the shutdown occurred at around 8:00 PM, the red LED remained ON and there was a buzzing noise continued even when the scheduled startup time arrived at around 8:00 AM. Then the system didn't startup so we pressed the button, and the white LED started blinking, but the Raspberry Pi did not turn on.

As a final attempt, we unplugged and plugged the system back in, and after that, the logs starting at 9:18 AM appeared, and the system regained normal functionality.

Regarding the interruption handling, the shutdown seems to complete successfully, but during the scheduling process, we are not sure whether the script might be getting stuck in an infinite loop within the while statement, or what exactly is happening afterward. We are considering adding multiple debugging logs inside that while loop to better understand which execution path is being taken.

Also, since interruptions are not really a case we need to handle in our code, do you think it would be acceptable to comment out the schedule_script_interrupted() functionality and keep only the return 1? This might help us avoid this issue entirely.

Our main question is: why did the system successfully process the shutdown and power off correctly, but then get stuck during startup?

@thienhoangphuongdung 

Based on the information you provided, this is no longer a standard Witty Pi software setup. Your own schedule.sh generates schedule.wpi and calls sync_scheduler, so it directly modifies Witty Pi’s scheduling data and alarm settings. This could explain why you see the “schedule is interrupted” message followed by what looks like a normal schedule: your custom scheduler and Witty Pi’s own runScript.sh may be updating or reading the schedule/alarm state at around the same time.

The while true loop in your script can only run while Raspberry Pi is ON. After Witty Pi cuts power to Raspberry Pi, no Bash script is running anymore. Therefore, that loop cannot directly explain why the scheduled startup did not happen. The "not startup as planned" behavor is usually due to power source lost/low voltage, or the scheduled alarm gets lost.

The red LED + buzzing noise + button not being able to power on Raspberry Pi still looks more like a power-source or power-path abnormal state than a schedule-script issue. The power bank LED being on does not prove that Witty Pi has stable usable 5V input or that VOUT can rise properly.

Disabling schedule_script_interrupted() may be used as your own experiment if you do not need interruption recovery, but it should not be considered a fix for the failed startup. It only disables one part of the schedule revision logic and does not address the red LED / buzzing / unable-to-power-on state.

At this point our support is limited, because the behavior depends on your custom integration. If you would like to suggest this as an issue in our firmware/software, you will need to reproduce the issue with (only) our firmware/software.

Thank you for your response, we will revise the code seperately.

As for the power supply issue, we are using the Voltaic V75 solar power bank that was recommended on this forum post: https://www.uugear.com/forums/technial-support-discussion/power-bank-for-rp3b-and-witty-pi-4-mini/#post-190
So is the issue power bank related that is providing unstable power or a witty pi electronic circuit instability or sensibility to power banks? 

@thienhoangphuongdung We do not know if this is a power issue. In order to confirm this, the output voltage of power bank needs to be monitored during the issue happening.

The only reason that we suggested V75 power bank, is the fact that it provides the "always on" mode, which do not need the "dummy load" trick to keep power bank on. We are not cooperating with Voltaic and we do not know their products better than you do.