Notifications
Clear all
Topic starter
Hi guys,
I'm running a weather project on a Raspberry Pi Zero W v1.1 and battery with a WittyPi Mini 4 on top for on/off scheduling. The project is running somewhere else remote....
To save the battery in case something goes wrong (in script or scheduling/shutting down RasPi), I built in a failsafe(?) of some sort in afterStartup.sh:
#!/bin/bash # file: afterStartup.sh # # This script will be executed in background after Witty Pi 3 gets initialized. # If you want to run your commands after boot, you can place them here. # sudo /home/bart/env/bin/python3 /home/bart/time.py & # 35 sec for wifi startup etc. # sleep 35 sudo /home/bart/env/bin/python3 /home/bart/rosans.py # doing weather measurements sudo /home/bart/env/bin/python3 /home/bart/time2.py # sleep 300 sec; if everything is allright, wittyPi turns Raspi off during this pause/sleep. # sleep 300 # If something is wrong, schedule-script is rerun, wittyPi.log is logged and Raspi shutdown by itself. sudo bash /home/bart/wittypi/runScript.sh sudo /home/bart/env/bin/python3 /home/bart/wittypi_log.py # logging wittyPi.log last 35 lines sudo shutdown now # RasPi is shutoff by himself.
schedule.wpi is (for now in experimental surroundings):
BEGIN 2023-10-29 07:00:00 END 2026-07-31 23:59:59 ON M5 # keep ON state for 5 minutes OFF M10 # keep OFF state for 10 minutes
So how I want it to work (and did with the WittyPi mini 3) is as follows.
00:00 Startup by wittyPi.
00:02 Weather measurements are done roughly by that time.
00:02 time2.py starts with time.sleep(300)
00:05 WittyPi shuts down RasPi if there are no problems and let is start 10 min later as scheduled.
If something goes wrong and WittyPi doesn't shutdown for whatever reason, the time2.py-script runs around 2 more minutes.
00:07 runScript.sh is run for new schedule in hope for a good start in the future.
00:07 wittypi_log.py logs wittyPi.log to a MariaDB-database and website (so I can read it also when RasPi is shutdown).
00:07 RasPi is shutdown by shutdown command.
What happens when I run the afterStartup.sh as shown the wittyPi won't shutdown the RasPi at 00:05 and always all the scripts in afterStartup.sh are run.
When I put a & after the time2.py command also all the command-lines in afterStartup.sh are run, but earlier at 00:02.
NB1: as you see I tried also direct sleep-commands in afterStartup.sh, but with the same results.
NB2: I didn't put any commands in beforeShutdown.sh, because if schedule get mixed up, RasPi won't shutdown and battery is drained........
I attached part of the wittyPi.log.
SO:
- Does anyone have a solution to this?
- Or does anyone know an other failsafe to not let run out my battery of power!
Best Regards,
Bart.
Posted : 22/11/2023 11:35 am
I am not sure if this causes the problem, but you need to use absolute path for each command in afterStartup.sh, otherwise that command may not run because of not being found.
In the afterStartup.sh file you provided, you have these commands without absolute path:
- sleep (although it is commented out)
- bash
- shutdown
Posted : 22/11/2023 11:45 am
Topic starter
I am not sure if this causes the problem, but you need to use absolute path for each command in afterStartup.sh, otherwise that command may not run because of not being found.
In the afterStartup.sh file you provided, you have these commands without absolute path:
- sleep (although it is commented out)
- bash
- shutdown
I don't think either lacking the absolute path is causing the problem
- sleep: when I use it uncommented I get the same behaviour as running the time.py and time2.py, and that means that the sleep commands work and for time2.py the wittyPi won't be shutdown as scheduled.
- bash: as you can see in the attached wittyPi_log_example.txt file, the runScript.sh is run, no problem.
- shutdown: also run.
Looks like, in contrary to the wittyPi3-software, the shutdown as scheduled is halted by the sleep-command (directly or in python-script).
Strange (or wittyPi3 software is not behaving as it should 😀 )....
Posted : 22/11/2023 1:08 pm
Usually absolute path is required, but if the correct paths has been exported before, the command could be found and run without specifying absolute path.
Now I review your question again, the result you observed is actually expected.
For example, if you put two commands there:
sleep 35 sudo shutdown now
The shutdown command will not execute until the sleep command exits, which would be after 35 seconds.
If you don't want the first command to be blocking, you may add '&' at the end of that command, like:
sleep 35 &
Posted : 22/11/2023 1:41 pm
Topic starter
@admin Pff, explaining things through text or mail is sometimes difficult 😀 !
What you say is to be expected.
But what I want is that during a time.sleep(300) (in time2.py), so 5 minutes, the WittyPi will still shut down as scheduled the Raspberry Pi, like it was with the wittyPi3 mini and likewise software.
I made a picture in the hope it will explain what I want and what worked with the WittyPi3 mini. It is attached.
The above part are the events and scripts that have to take place when wittyPi an Raspberry pi function properly.
The beneath part is when WittyPi or Raspberry Pi aren't functioning properly and Raspi isn't shutdown. But with the wittyPi 4 mini it is running all the time all these scripts...
Blue are the same events and scripts that are running, red when something is wrong and the wittypi isn't properly shutting down the Raspi.
I hope all is clearer now what my problem is.....
Posted : 22/11/2023 3:11 pm
@katoendds-nl Thanks for the explaination and now I understand your question.
Witty Pi's software (daemon.sh) listens to GPIO-4 and calls shutdown command when GPIO-4 is pulled down. The GPIO-4 could be pulled down by the button on Witty Pi, or it could be pulled down by the firmware (via a pin in ATtiny841). When a scheduled shutdown is due, the firmware will pull down GPIO-4, which has the same result as you manually tap the button.
However, listening to GPIO-4 happens AFTER calling the afterStartup.sh script. That means if your afterStartup.sh script blocks too long, and the scheduled shutdown is due, even though firmware already pulled down GPIO-4, the daemon.sh script doesn't know about it -- because it is still blocked by afterStartup.sh and hasn't started to monitor GPIO-4 yet.
So the result you got is understandable. In your WittyPi.log file, I can see this line comes after the scheduled shutdown:
[2023-11-22 10:07:41] Pending for incoming shutdown command...
This message indicates that daemon.sh starts to monitor GPIO-4, but unfortunately it was too late.
In order to achieve what you want, you need to make a script (e.g. named watchdog.sh) that does the following:
- Wait for some time
- runScript.sh is run for new schedule in hope for a good start in the future.
- wittypi_log.py logs wittyPi.log to a MariaDB-database and website (so you can read it also when RasPi is shutdown).
- RasPi is shutdown by shutdown command.
You call this script in afterStartup.sh and make it unblocking (appending & at the end). So this script will not block daemon.sh, but it will run in the background and do all those you planed. Because daemon.sh will not be blocked, it will immediately start monitoring GPIO-4, so it will not miss the scheduled shutdown.
Posted : 22/11/2023 3:46 pm
Topic starter
@admin Thanks again for elaborate and clear answer. I know what to do now. The followup of events is in the manual, but I doubt that I had realised the consequences 😆 . But it's solved by now.
At the same time it is clear to me why my stuff worked with WittyPi3 deamon. There you let run afterStartup.sh in the background. What is the reason that you changed that for the WittyPi4 deamon?
Thanks again for all your work!
Posted : 23/11/2023 5:30 pm
@katoendds-nl If we put afterStartup.sh in background (like we did in Witty Pi 3's software), there is no way the user can block daemon.sh. In Witty Pi 4's software, we let the users to decide whether to block the daemon.sh, in some cases it is needed.
Posted : 23/11/2023 5:40 pm