[SOLVED] After rebuilding a Pi4 with bookworm, PiJuice events stopped working ... #1080

ArjenR49 · 2024-05-22T13:12:40Z

ArjenR49
May 22, 2024

Now that RealVNC is going to pull the plug on us Home subscription users on June 17th, I made a move to install bookworm from scratch on one of my Pi4's with PiJuice HAT.
Most of the PiJuice settings were still there, but the system events table was empty. Before it had mostly simple user functions for a large number of events. Mostly just writing a logging message to a file. This used to work fine.
Now on the new installation I had to re-enter the user functions (python scripts) in the table.
The pijuice GUI program doesn't work with wayland (which I need for TigerVNC & Pi Connect), so I have to use pijuice_cli, which is fine.

Now the system events don't trigger any of the functions any longer.
However, when I run such a python user function script, it does what it used to do and is supposed to do.

How can I make the system events trigger the user functions like they used to?

Apart from the scripts that just log the event, two of the user functions take care of power loss and shutdown events. They're quite important to me, since I am sometimes away from this site for many months and power and/or internet outages tend to happen at this location.
I have just a few weeks to have this Pi4 server resurrected before I leave again ... It is my entry point to the LAN ...

Answered by tvoverbeek

May 25, 2024

home directories get default protection 0700 (rwx------) in bookworm
Under bullseye and earlier it was 0755 (rwxr-xr-x).
Compare these 2 manpages:
https://manpages.debian.org/bullseye/adduser/adduser.conf.5 and
https://manpages.debian.org/bookworm/adduser/adduser.conf.5

You found out the hard way.
Anyway I need to modify the install script to give user pijuice recursive read access to the default user (uid 1000) home directory
Need to look into the use of ACLs

View full answer

tvoverbeek · 2024-05-22T13:36:12Z

tvoverbeek
May 22, 2024
Maintainer

System events are handled by the pijuice service.
Is the service running? Check with systemctl status pijuice
Are you using a 32-bit or 64-bit OS?
Did yiu reinstall the pijuice-base package?
There is an issue with the install script which does not detect a 32-bit installation properly.
See e.g. Issue #1000.
For a Pi4 use the 64-bit OS.

Regarding RealVnc, the RealVNC viewer works fine with the vnc server in wayland.
pijuice_gui does not work under wayland, since it relies on Tk (Tk has no wayland support, only X11)

0 replies

ArjenR49 · 2024-05-22T13:58:46Z

ArjenR49
May 22, 2024
Author

Thanks for helping, Tom! 'Long time, no see'

pi@RPI-HUB:~ $ systemctl status pijuice
â�� pijuice.service - PiJuice status service
     Loaded: loaded (/lib/systemd/system/pijuice.service; enabled; preset: enabled)
     Active: active (running) since Wed 2024-05-22 02:50:37 CEST; 12h ago
   Main PID: 601 (pijuice_sys.py)
      Tasks: 1 (limit: 3909)
        CPU: 1min 7.772s
     CGroup: /system.slice/pijuice.service
             â��â��601 /usr/bin/python3 /usr/bin/pijuice_sys.py

mei 22 02:50:37 RPI-HUB systemd[1]: Started pijuice.service - PiJuice status service.
mei 22 02:50:45 RPI-HUB pijuice_sys.py[601]: RTC os-support OK
pi@RPI-HUB:~ $

The OS is 64 bit and I installed it from zero, so I had to re-install the pijuice software, too.
2:50 is reboot time per crontab. It should produce several lines in the log, but no.
PiJuice firmware is the latest (1.6).

Re RealVNC: I got an email from RealVNC that on June 17th they're dropping the Home subscription such as came with Raspberry PI's. Earlier they had conviced me to start using 2FA with Authy. (I had three Pi's in their cloud system for external access)
However, after changing to a new phone, the Authy codes it produced for RealVNC were not accepted any longer and the backup codes were lost - probably because you see them only once when taking 2FA into use and they disappeared from the screen when a window was closed ... One could argue that I locked myself out :-( No real support from RealVNC for Home users, so here I am.

It is unclear to me if RealVNC viewers and servers with direct connections on a LAN will continue to work after june 17th. The whole situation around RealVNC is quite muddled (as I find usual in this business, except for Linux, probably).
When I had to change to a new desktop last year, I already had much more trouble getting RealVNC to work for me than years earlier.
Also I read somewhere that all RealVNC connections will run or do run via their cloud servers already now. That would mean they can just totally inhibit my VNC infrastructure.
I hope I am poorly informed about this. I am now using Pi Connect on one Pi4, which already had bookworm on it, but most of my Pi's run older OS's. Pi Connect works.
TigerVNC doesn't properly recognize 'dead' keys as I have them on my Finnish keyboard. Like I cannot type ~, which is not helpful.
I can live with the shortcomings. They'll be ironed out. As long as I can access my LAN from WAN in a safe way (double firewall) and survive power outages somehow.

Should I take the battery out of the HAT and reconnect it? Could that help to make system events work again?
(it's a bit troublesome to do that, live Li battery wires etc.)

5 replies

tvoverbeek May 22, 2024
Maintainer

Can you run pijuice_cli in a terminal window and check the system events and user functions?
Maybe list a simple user function triggered by a system event, Then I can check why it does not work.

ArjenR49 May 22, 2024
Author

I can and I did. See attached screenshots.

pi@RPI-HUB:~/PiJuiceUPS $ ls -la
totaal 168
drwxr-xr-x  5 pi pi   4096 20 mei 23:57 .
drwx------ 28 pi pi   4096 22 mei 15:37 ..
-rwxr-xr-x  1 pi pi    424 20 mei 23:57 LogButtonPowerOffEvent.py
-rwxr-xr-x  1 pi pi    415 20 mei 23:57 LogPowerPresentEvent.py
-rwxr-xr-x  1 pi pi    935 20 mei 23:57 LogSystemStartEvent.py
-rwxr-xr-x  1 pi pi    425 20 mei 23:57 LogSystemStopEvent.py
-rwxr-xr-x  1 pi pi    420 20 mei 23:57 LogWatchdogWasActivatedEvent.py
drwxr-xr-x  2 pi pi   4096 20 mei 23:57 NietInGebruik
-rw-r--r--  1 pi pi 121877 21 mei 11:23 PiJuiceStatus.log
-rwxr-xr-x  1 pi pi   1162 20 mei 23:57 PiJuiceSystemTaskInducedShutdown.py
-rwxr-xr-x  1 pi pi   1738 20 mei 23:57 PowerLossShutdown.py
drwxr-xr-x  2 pi pi   4096 20 mei 23:57 Settings
drwxr-xr-x  2 pi pi   4096 20 mei 23:57 Utilities
pi@RPI-HUB:~/PiJuiceUPS $ cat PowerLossShutdown.py

<code redacted, not a secret, but not part of the events I try to show>

pi@RPI-HUB:~/PiJuiceUPS $ python3 LogSystemStopEvent.py
pi@RPI-HUB:~/PiJuiceUPS $ tail -n 20 PiJuiceStatus.log
18/05/2024 02:50:07 PiJuice System Stop Event ...
18/05/2024 02:51:01 Set RTC wakeup function to be re-enabled after startup ...
18/05/2024 02:51:01 PiJuice System Start Event ... Pi OS starting up ...
18/05/2024 17:03:22 PiJuice System Stop Event ...
21/05/2024 10:37:58 PiJuice System Stop Event ...
21/05/2024 10:39:01 PiJuice System Stop Event ...
21/05/2024 10:39:20 PiJuice System Stop Event ...
21/05/2024 10:39:28 PiJuice System Stop Event ...
21/05/2024 11:04:59 PiJuice Button Press Power Off Event ...
21/05/2024 11:05:39 PiJuice Power Present Event ...
21/05/2024 11:05:48 Set RTC wakeup function to be re-enabled after startup ...
21/05/2024 11:05:48 PiJuice System Start Event ... Pi OS starting up ...
21/05/2024 11:05:56 PiJuice System Stop Event ...
21/05/2024 11:06:01 PiJuice Watchdog Activated Event ...
21/05/2024 11:10:59 AC power loss -> initiating shutdown in 30 seconds ...
21/05/2024 11:10:59 Pi will auto-restart following return of AC power.
21/05/2024 11:10:59 Blink LED and wait 30 seconds before issuing shutdown command...
21/05/2024 11:11:29 Shutdown imminent ...
21/05/2024 11:23:57 PiJuice Button Press Power Off Event ...
22/05/2024 17:07:45 PiJuice System Stop Event ...


pi@RPI-HUB:~/PiJuiceUPS $ pijuice_cli
pi@RPI-HUB:~/PiJuiceUPS $ ls -la
totaal 168
drwxr-xr-x  5 pi pi   4096 20 mei 23:57 .
drwx------ 28 pi pi   4096 22 mei 15:37 ..
-rwxr-xr-x  1 pi pi    424 20 mei 23:57 LogButtonPowerOffEvent.py
-rwxr-xr-x  1 pi pi    415 20 mei 23:57 LogPowerPresentEvent.py
-rwxr-xr-x  1 pi pi    935 20 mei 23:57 LogSystemStartEvent.py
-rwxr-xr-x  1 pi pi    425 20 mei 23:57 LogSystemStopEvent.py
-rwxr-xr-x  1 pi pi    420 20 mei 23:57 LogWatchdogWasActivatedEvent.py
drwxr-xr-x  2 pi pi   4096 20 mei 23:57 NietInGebruik
-rw-r--r--  1 pi pi 121877 21 mei 11:23 PiJuiceStatus.log
-rwxr-xr-x  1 pi pi   1162 20 mei 23:57 PiJuiceSystemTaskInducedShutdown.py
-rwxr-xr-x  1 pi pi   1738 20 mei 23:57 PowerLossShutdown.py
drwxr-xr-x  2 pi pi   4096 20 mei 23:57 Settings
drwxr-xr-x  2 pi pi   4096 20 mei 23:57 Utilities
pi@RPI-HUB:~/PiJuiceUPS $

The first three lines in the tail of PiJuiceStatus.log are from when the machine still ran on Bullseye and booted at 2.50h.
The last line is from when I ran the script in a terminal as shown above. It runs and writes to the log,
but at night at 2:50 it doesn't run. On 18-05-2024 on the previous OS it ran as can be seen in the above as well.
The lines from 18-05 17hrs forward are from running scripts in a terminal, not triggered by events, to prove that they are OK as far as the code is concerned.

When I run e.g. PowerLossShutdown, it will execute and eventually shut the PI down, as that is what it was written to do, when AC power is removed.
After reconnecting power the Pi doesn't start up as it should and run user function 3 which is LogPowerPresentEvent.py. This simple script just prints a message:

 pi@RPI-HUB:~/PiJuiceUPS $ cat LogPowerPresentEvent.py
#!/usr/bin/python3

# See https://raspberrypi-guide.github.io/other/boot-automation-pijuice
# Modified by ar: 24-03-2023, 16-05-2023, 18-05-2023

import logging

logging.basicConfig(
    filename = '/home/pi/PiJuiceUPS/PiJuiceStatus.log',
    level = logging.DEBUG,
    format = '%(asctime)s %(message)s',
    datefmt = '%d/%m/%Y %H:%M:%S')

# Write statement to log
logging.info('PiJuice Power Present Event ...')
pi@RPI-HUB:~/PiJuiceUPS $

When I cut AC power, pijuice_cli shows this OK, but the script corresponding to the power loss event doesn't get triggered.

Also the Pi boots at 2.50h, but nothing in the log like before.

ArjenR49 May 22, 2024
Author

So cutting AC power doesn't cause the corresponding script to run, but when I run it in a terminal, it will flash the LED, write to the log and eventually shut the Pi down, just as it is supposed to.
Restoring AC doesn't start the Pi. It remains unreachable to ping and I have to press SW1 to get it running again.

The PowerLossShutdown.py script:

#!/usr/bin/python3

# See: https://learn.pi-supply.com/make/how-to-run-a-user-script-with-the-pijuice-power-events/
# ar - 24-03-2023, 15-04-2023, 20-04-2023, 18-05-2023, 13-06-2023, 14-06-2023, 20.11.2023, 24-02-2024

import os
import logging
from time import sleep
from pijuice import PiJuice

logging.basicConfig(
    filename = '/home/pi/PiJuiceUPS/PiJuiceStatus.log',
    level = logging.DEBUG,
    format = '%(asctime)s %(message)s',
    datefmt = '%d/%m/%Y %H:%M:%S')

pijuice = PiJuice(1, 0x14)
# Time in seconds to keep running on battery before shutting down Pi.
ShutdownDelay = 30

# Make sure PiJuice status is OK.
pjOK = False
while pjOK == False:
    stat = pijuice.status.GetStatus()
    if stat['error'] == 'NO_ERROR':
        pjOK = True
    else:
        sleep(0.1)

# Write message to log file
logging.info('AC power loss -> initiating shutdown in ' + str(ShutdownDelay) + ' seconds ...')
logging.info('Pi will auto-restart following return of AC power.')

# Remove power to PiJuice VSYS output (for peripherals)
pijuice.power.SetSystemPowerSwitch(0)

# Make sure wakeup_enabled and wakeup_on_charge have the correct values
pijuice.rtcAlarm.SetWakeupEnabled(True)
pijuice.power.SetWakeUpOnCharge(50)

# Remove 5V power to RPi 90 seconds later than?
pijuice.power.SetPowerOff(90)

# Show custom script runs by blinking user LED in red 10x
logging.info('Blink LED and wait ' + str(ShutdownDelay) + ' seconds before issuing shutdown command...')
pijuice.status.SetLedBlink('D2', 10, [200,0,0], 100, [0, 200, 0], 100)
sleep(ShutdownDelay)

# Now blink LEDs again & shut down
logging.info('Shutdown imminent ...')
pijuice.status.SetLedBlink('D2', 10, [200,0,0], 25, [0, 0, 0], 25)
sleep(3)
os.system("sudo shutdown -h now")

It writes these lines to the log:


22/05/2024 17:32:54 AC power loss -> initiating shutdown in 30 seconds ...
22/05/2024 17:32:54 Pi will auto-restart following return of AC power.
22/05/2024 17:32:54 Blink LED and wait 30 seconds before issuing shutdown command...
22/05/2024 17:33:24 Shutdown imminent ...

ArjenR49 May 22, 2024
Author

I noticed i2c was off. I am not sure now what it should be, but I enabled it and it doesn't look like it is making a difference.

ArjenR49 May 22, 2024
Author

This is from LogSystemStartEvent:

...
# Set wakeup_enabled (requires 'dtoverlay=i2c-rtc,ds1307=1' in config.txt)
pj.rtcAlarm.SetWakeupEnabled(True)
logging.info('Set RTC wakeup function to be re-enabled after startup ...')
...

I do not think the current config.txt has the line as in the comment ...
I did see some discussion about the RTC settings ...
I'll add it.

tvoverbeek · 2024-05-22T18:30:46Z

tvoverbeek
May 22, 2024
Maintainer

Yes, add the dtoverlay=i2c-rtc,ds1307=1 to config.txt
Also set the Pijuice EEPROM address to 52 instead of 50.
This will prevent the loading of the ds1339 overlay at boot as specified in the HAT eeprom.
With the ds1339 module the linux kernel can control the rtc alarm function.
if you are connected to the internet, every time timesyncd syncs the time to the rtc it will also
clear an existing rtc wakeup alarm.
By preventing the loading of the overlay specified in the HAT eeprom and forcing the use of
the ds1307 it should work much better.
This has been discussed several times in the past years.

1 reply

ArjenR49 May 22, 2024
Author

True, I remember discussions about EEPROM addresses and RTC settings. Too much time has passed, it seems.
The screenshots I made before the installation of bookworm OS show the EEPROM address as 50, but the line for the RTC in config.txt I had indeed forgotten to add to the new config.txt. I have another (working) Pi4 with bookworm, but it has config.txt in a different folder, the old way, and the difference had me wondering and checking for documentation and then I forgot the rtc settings for PiJuice in the process.

After installation at one time I remember seeing i2cdetect -y 1 already producing 14 and UU at 68.
However i2c was disabled when I looked today. So, I have enabled it, again.

After installation of the new OS, all user function settings for the system events and all X marks in that table had disappeared, as had all USER_FUNC = settings. I have not removed the battery during that process nor afterwards. I checked and re-entered as in my screenshots. Most settings were still there, however.

It's been a long time since f/w 1.6 was published. For a while, I was expecting an update, but it seems to have since become pretty quiet around the PiJuice HAT. They are not in stock and I was afraid it had been abandoned. It was good to see that this forum is still operational and you are also still at it. Thanks!
(A lot of UPS projects seems to go belly up, or never deliver what was promised/possible. At least two other UPS products that I have bought and used a lot of effort to get working properly, which I have had to drop because of no support.)

I'm going to leave the HAT alone for half a day and wait for the reboot at 2.50h per crontab and check the log tomorrow morning.

ArjenR49 · 2024-05-24T11:24:36Z

ArjenR49
May 24, 2024
Author

Event triggering hasn't started working after the previous changes.

Since that time I was able to claim my email address back from RealVNC (since AUTHY had stopped working for RealVNC) and was then able to register a Lite subscription instead of the previous plan that will end on June 17th (Home & whatever). This move allowed reverting from Wayland to X11 and therefore I could get PiJuice GUI back, which is nicer to work with.
Also I got the RealVNC server icon back. Things are now as before, except it is on Bookworm and ... event triggering is still not working (it did until May 18th, when the Pi was on Bullseye).

So, as a last resort, I removed the battery from the PiJuice HAT for a short while after shutting down the Pi (SW1, SYS_FUNC_HALT_POWER_OFF) and then cut AC from the power supply.

After reconnecting the battery and the power supply the Pi started up OK. The Wakeup Alarm settings were gone, however. Re-entered settings and pressed Apply.

That didn't help, either ... still no event triggering. When I cut power to the Pi, a Python user script should be run and it should execute a shutdown command in the last line. It has worked before on the same Pi on Bullseye.

What I did next, is pulling the power from a second Pi4 (still on Bullseye), which also has a PiJuice HAT and has had the same settings and scripts for a long time. It does have BTRFS disks attached, which do not have UPS, so I just pulled the USB power supply of the Pi itself.
It worked perfectly. The Pi down after a minute or so and upon restoring power it started up again, like it is supposed to. The events that this triggered ran the corresponding scripts which wrote messages to the log file:

24/05/2024 11:40:08 PiJuice System Stop Event ...
24/05/2024 11:40:58 Set RTC wakeup function to be re-enabled after startup ...
24/05/2024 11:40:58 PiJuice System Start Event ... Pi OS starting up ...
24/05/2024 13:14:31 AC power loss -> initiating shutdown in 30 seconds ...
24/05/2024 13:14:31 Pi will auto-restart following return of AC power.
24/05/2024 13:14:31 Blink LED and wait 30 seconds before issuing shutdown command...
24/05/2024 13:15:01 Shutdown imminent ...
24/05/2024 13:15:10 PiJuice System Stop Event ...
24/05/2024 13:16:59 Set RTC wakeup function to be re-enabled after startup ...
24/05/2024 13:16:59 PiJuice System Start Event ... Pi OS starting up ...

At 11:40 cron rebooted the Pi as it does every Friday. At 13.14 I pulled the power from the Pi and restored it a minute or so later, which caused the last two lines.
I think this provides proof that all in all my setup does work, on Bullseye ... something bad happened to the other Pi4+HAT in connection with bookworm installation. Before removing the battery today, I haven't even touched the hardware at all. Just changed the SSD drive to an identical one in the same USB enclosure with 64-bit Bookworm.

0 replies

tvoverbeek · 2024-05-24T13:28:45Z

tvoverbeek
May 24, 2024
Maintainer

I believe your problem is the use of SetWakeUpOnCharge.
Since the 1.6 firmware there is an option to store the setting in non-volatile memory, which makes it more reliable (not relying on saving and restoring the setting manually).
Try changing pijuice.power.SetWakeUpOnCharge(50)to pijuice.power.SetWakeUpOnCharge(50, non_volatile=True) in your script.
The firmware can get confused if you mix the use of the old method with the non-volatile storage one

3 replies

ArjenR49 May 24, 2024
Author

OK. I changed the script which is supposed to be triggered by AC power loss.
Are there other commands where I should use non_volatile=True?

This particular script should have written to the log already before it executes the pijuice.power.SetWakeUpOnCharge(50, non_volatile=True), but the script doesn't write to the log, which means it doesn't run, and the Pi continues to run for the time being, on battery power. The script runs fine when I execute it in a terminal window, and the Pi shuts down ..

This is the code:

#!/usr/bin/python3

# See: https://learn.pi-supply.com/make/how-to-run-a-user-script-with-the-pijuice-power-events/
# ar - 24-03-2023, 15-04-2023, 20-04-2023, 18-05-2023, 13-06-2023, 14-06-2023, 20.11.2023, 24-02-2024,
#      24-05-2024

import os
import logging
from time import sleep
from pijuice import PiJuice

logging.basicConfig(
    filename = '/home/pi/PiJuiceUPS/PiJuiceStatus.log',
    level = logging.DEBUG,
    format = '%(asctime)s %(message)s',
    datefmt = '%d/%m/%Y %H:%M:%S')

pijuice = PiJuice(1, 0x14)
# Time in seconds to keep running on battery before shutting down Pi.
ShutdownDelay = 30

# Make sure PiJuice status is OK.
pjOK = False
while pjOK == False:
    stat = pijuice.status.GetStatus()
    if stat['error'] == 'NO_ERROR':
        pjOK = True
    else:
        sleep(0.1)

# Write message to log file
logging.info('AC power loss -> initiating shutdown in ' + str(ShutdownDelay) + ' seconds ...')
logging.info('Pi will auto-restart following return of AC power.')

# Remove power to PiJuice VSYS output (for peripherals)
pijuice.power.SetSystemPowerSwitch(0)

# Make sure wakeup_enabled and wakeup_on_charge have the correct values
pijuice.rtcAlarm.SetWakeupEnabled(True)
#pijuice.power.SetWakeUpOnCharge(50)
pijuice.power.SetWakeUpOnCharge(50, non_volatile=True)

# Remove 5V power to RPi 90 seconds later than?
pijuice.power.SetPowerOff(90)

# Show custom script runs by blinking user LED in red 10x
logging.info('Blink LED and wait ' + str(ShutdownDelay) + ' seconds before issuing shutdown command...')
pijuice.status.SetLedBlink('D2', 10, [200,0,0], 100, [0, 200, 0], 100)
sleep(ShutdownDelay)

# Now blink LEDs again & shut down
logging.info('Shutdown imminent ...')
pijuice.status.SetLedBlink('D2', 10, [200,0,0], 25, [0, 0, 0], 25)
sleep(3)
os.system("sudo shutdown -h now")

ArjenR49 May 24, 2024
Author

Made the same change on the other Pi4+PiJuice HAT as a check. That Pi4 on bullseye behaved as it should on power loss. It shuts down soon after AC power loss as intended. And starts up again when power comes back. And leaves messages in the log.
I haven't noticed the wakeuponcharge 50 disappearing from the settings. Maybe it was like that long ago, but the power loss script has been setting it to 50.

Maybe I should reset the PiJuice to defaults and re-enter all settings? (Just the script names are a bore, last time I had to redo them, I couldn't paste them. That was in pijuice_cli, though.

ArjenR49 May 24, 2024
Author

I let the misbehaving Pi+PiJuice run on battery (no AC power) until both (1) low battery and (2) low charge % were reached (since it doesn't run the designated script and shutdown upon loss of AC). Didn't want to wait for the battery to drain too much.
None of those two events (1) and (2) that should have triggered did anything.
It is probably fair to expect that none of the 8 enabled events trigger the scripts set for the event in the current situation of the HAT.

Next step is resetting the HAT to defaults and entering all settings from scratch ...

tvoverbeek · 2024-05-24T18:15:48Z

tvoverbeek
May 24, 2024
Maintainer

Low battery, low charge, power avaiable and no power events are not triggered by the Pijuice firmware, but detected by the pijuice service. Are you sure you are running the correct version of pijuice_sys.py?
Running some older version by chance?
Look e.g. at the EvalPowerInputs function (lines 188-208 in pijuice_sys.py (https://github.com/PiSupply/PiJuice/blob/master/Software/Source/src/pijuice_sys.py)
Suggest to add some debug printouts to your /usr/bin/pijuice_sys.py function to see if the function is called.
The output will show when you do systemctl status pijuice
Altrnatively use the logging mechanism.

1 reply

ArjenR49 May 24, 2024
Author

You could be on to something here ...
I have installed Bookworm 64 bit to a 'new' SSD by running Raspberry Pi Imager on my Linux desktop on May 18th.
After that I have installed the pijuice software as per the instructions (I hope):

pi@RPI-HUB:~ $ history | grep install
   ...
   48  sudo apt-get install pijuice-gui
...
  494  sudo apt-get install pijuice-gui
  498  sudo apt-get install pijuice-base
  499  sudo apt-get install pijuice-gui
...
  853  sudo apt-get install pijuice-gui
  866  history | grep install
pi@RPI-HUB:~ $

When I found out that in the situation at that time (Wayland) I couldn't run pijuice_gui, I removed it with sudo dpkg -r pijuice-gui.
After getting a RealVNC Lite account, I reverted to X11 and installed pijuice_gui again. So far, so good.

Pijuice_sys.py at the site your link points to a page where it says that pijuice_sys.py is 7 months old and the last commit #1019 is from last October 2023. OK.

Now comes the HOWEVER part, though.
On the SSD that I installed Bookworm to, and from which the Pi is running, the file /usr/bin/pijuice_sys.py is from 2022:

pi@RPI-HUB:~ $ sudo ls -la /usr/bin/pijuice*
lrwxrwxrwx 1 root    root        22 18 mei 18:12 /usr/bin/pijuiceboot -> /usr/bin/pijuiceboot64
-rwxr-xr-x 1 root    root     22732 29 jan  2022 /usr/bin/pijuiceboot32
-rwxr-xr-x 1 root    root     23904 30 jan  2022 /usr/bin/pijuiceboot64
lrwxrwxrwx 1 root    root        22 18 mei 18:12 /usr/bin/pijuice_cli -> /usr/bin/pijuice_cli64
-rwsr-xr-x 1 pijuice pijuice   9096 17 dec  2018 /usr/bin/pijuice_cli32
-rwsr-xr-x 1 pijuice pijuice  14872 30 jan  2022 /usr/bin/pijuice_cli64
-rw-r--r-- 1 pijuice pijuice 101552 16 mei  2021 /usr/bin/pijuice_cli.py
lrwxrwxrwx 1 root    root        22 24 mei 09:42 /usr/bin/pijuice_gui -> /usr/bin/pijuice_gui64
-rwsr-xr-x 1 pijuice pijuice   9096 17 dec  2018 /usr/bin/pijuice_gui32
-rwsr-xr-x 1 pijuice pijuice  14872 30 jan  2022 /usr/bin/pijuice_gui64
-rw-r--r-- 1 pijuice pijuice 105446 16 mei  2021 /usr/bin/pijuice_gui.py
-rwxr-xr-x 1 root    root     11275 30 jan  2022 /usr/bin/pijuice_log.py
-rwxr-xr-x 1 root    root     15664 30 jan  2022 /usr/bin/pijuice_sys.py
-rwxr-xr-x 1 root    root      6205 30 jan  2022 /usr/bin/pijuice_tray.py
pi@RPI-HUB:~ $

All actual files are several years old.
Things are as they were installed, but the 64 bit OS is probably not as old as the *64 files on my SSD.

The other two dates for this file are apparently the install date/time and the other something else was done to it a few days later in 2024.

The file pijuice_sys.py itself doesn't seem have a date stamp e.g. in a comment.

I don't quite know what to make of this ...

tvoverbeek · 2024-05-24T20:50:16Z

tvoverbeek
May 24, 2024
Maintainer

Please list the output from sudo cat /var/lib/pijuice/pijuice_config.JSON
and the output from cat /etc/group | grep pijuice
This to check if pijuice_sys.py gets the right configuration.
Also user scripts are only executed by pijuice_sys if the script owner is not root and belongs to the pijuice group.

It looks like you have the right version of pijuice_sys.py.
So maybe this is some permission problem on your bookworm pi

4 replies

ArjenR49 May 25, 2024
Author

pi@RPI-HUB:~ $ sudo cat /var/lib/pijuice/pijuice_config.JSON
{
  "system_task": {
    "enabled": true,
    "watchdog": {
      "enabled": true,
      "period": "10"
    },
    "wakeup_on_charge": {
      "enabled": true,
      "trigger_level": "50"
    },
    "min_charge": {
      "enabled": true,
      "threshold": "40"
    },
    "min_bat_voltage": {
      "enabled": true,
      "threshold": "3.6"
    },
    "ext_halt_power_off": {
      "enabled": true,
      "period": "60"
    }
  },
  "user_functions": {
    "USER_FUNC1": "/home/pi/PiJuiceUPS/PiJuiceSystemTaskInducedShutDown.py",
    "USER_FUNC2": "/home/pi/PiJuiceUPS/PowerLossShutdown.py",
    "USER_FUNC3": "/home/pi/PiJuiceUPS/LogPowerPresentEvent.py",
    "USER_FUNC4": "/home/pi/PiJUiceUPS/LogWatchdogWasActivatedEvent.py",
    "USER_FUNC5": "/home/pi/PiJuice/LogButtonPowerOffEvent.py",
    "USER_FUNC6": "/home/pi/PiJuice/LogSystemStartEvent.py",
    "USER_FUNC7": "/home/pi/PiJuice/LogSystemStopEvent.py",
    "USER_FUNC8": "",
    "USER_FUNC9": "",
    "USER_FUNC10": "",
    "USER_FUNC11": "",
    "USER_FUNC12": "",
    "USER_FUNC13": "",
    "USER_FUNC14": "",
    "USER_FUNC15": ""
  },
  "system_events": {
    "low_charge": {
      "enabled": true,
      "function": "USER_FUNC1"
    },
    "low_battery_voltage": {
      "enabled": true,
      "function": "USER_FUNC1"
    },
    "no_power": {
      "enabled": true,
      "function": "USER_FUNC2"
    },
    "power": {
      "enabled": true,
      "function": "USER_FUNC3"
    },
    "watchdog_reset": {
      "enabled": true,
      "function": "USER_FUNC4"
    },
    "button_power_off": {
      "enabled": true,
      "function": "USER_FUNC5"
    },
    "forced_power_off": {
      "enabled": false,
      "function": "NO_FUNC"
    },
    "forced_sys_power_off": {
      "enabled": false,
      "function": "NO_FUNC"
    },
    "sys_start": {
      "enabled": true,
      "function": "USER_FUNC6"
    },
    "sys_stop": {
      "enabled": true,
      "function": "USER_FUNC7"
    }
  }
}pi@RPI-HUB:~ $

pi@RPI-HUB:~ $ cat /etc/group | grep pijuice
users:x:100:pi,pijuice
i2c:x:994:pi,pijuice
pijuice:x:1001:pi
pi@RPI-HUB:~ $


pi@RPI-HUB:~ $ ls -la ~/PiJuiceUPS/*.py
-rwxr-xr-x 1 pi pi  460 24 mei 21:18 /home/pi/PiJuiceUPS/LogButtonPowerOffEvent.py
-rwxr-xr-x 1 pi pi  451 24 mei 21:21 /home/pi/PiJuiceUPS/LogPowerPresentEvent.py
-rwxr-xr-x 1 pi pi  971 24 mei 21:21 /home/pi/PiJuiceUPS/LogSystemStartEvent.py
-rwxr-xr-x 1 pi pi  461 24 mei 21:21 /home/pi/PiJuiceUPS/LogSystemStopEvent.py
-rwxr-xr-x 1 pi pi  456 24 mei 21:21 /home/pi/PiJuiceUPS/LogWatchdogWasActivatedEvent.py
-rwxr-xr-x 1 pi pi 1250 24 mei 21:17 /home/pi/PiJuiceUPS/PiJuiceSystemTaskInducedShutdown.py
-rwxr-xr-x 1 pi pi 1838 24 mei 21:17 /home/pi/PiJuiceUPS/PowerLossShutdown.py
pi@RPI-HUB:~ $

A typo in a script name: "/home/pi/PiJUiceUPS/LogWatchdogWasActivatedEvent.py",
but that is for an event which I didn't test. Corrected it.
Also three typos in the directory name, but for not for the PowerLoss script, which is the one I tested.

However .. now that I have the GUI back, I happened to try the three dots after one of the file names and the result was totally not as expected, and not as in the other Pi+PiJuice still on Bullseye. I set the HAT up using pijuice_cli, which doesn't have that functionality, of course ... (which explains the typos, too)

In the OS's file manager window I can access that directory just fine.

On the misbehaving Pi4+PiJuice permissions for /home/pi are wacky:

pi@RPI-HUB:~ $ ls -la /home
totaal 12
drwxr-xr-x  3 root root 4096 18 mei 17:09 .
drwxr-xr-x 20 root root 4096 24 mei 09:00 ..
drwx------ 29 pi   pi   4096 25 mei 02:51 pi
pi@RPI-HUB:~ $

On the good Pi4+PiJuice, though, permissions for /home/pi are as expected:

pi@RPI-NAS:~ $ ls -la /home
totaal 12
drwxr-xr-x  3 root root 4096  3 mei  2023 .
drwxr-xr-x 19 root root 4096 17 mei  2023 ..
drwxr-xr-x 30 pi   pi   4096 24 mei 16:20 pi
pi@RPI-NAS:~ $

How on earth did the permissions for /home/pi end up like that on RPI-HUB, i.e. the bad one?

I checked a few other Pi's and they have the permissions for /home/pi like RPI-NAS, as it should be.

So here it is, the source of the whole discussion.

The question remains, how did this come about?
I've installed other stuff on that Pi, but it's the same stuff as I 'always' do.
There are no chmod commands in the history and I can't imagine I'd do something like that in the filemanager GUI.
I did copy some stuff to /home/pi from the old SSD which was mounted on my Linux desktop, which doesn't have a user named pi. I didn't copy all of /home/pi. I used scp for the copying. Also copied over some files that were to go to /etc via /home/pi, since scp cannot copy elsewhere on the target machine.

I've installed TimeShift and BackInTime. Perhaps there's something to be seen there. I also made a clone of the system with rpi-clone and saved a few of those.
It's too late to check those sources of information now.

ArjenR49 May 25, 2024
Author

Now it works ... I manually rebooted and of course now the event scripts ran OK:

25/05/2024 05:28:08 PiJuice System Stop Event ...
25/05/2024 05:28:52 Set RTC wakeup function to be re-enabled after startup ...
25/05/2024 05:28:52 PiJuice System Start Event ... Pi OS starting up ...

Wonderful!

ArjenR49 May 25, 2024
Author

It looks like you have the right version of pijuice_sys.py.

Apparently development of the software has not stopped. Is there any advantage for an ordinary user in getting those more recent versions?

ArjenR49 May 25, 2024
Author

I was able to open a disk image made for system backup purposes on May 20th, soon after installing Bookworm. Only a few additional applications had been installed at that time; pijuice_cli among them. At that time it was on Wayland and remote access was not by RealVNC.

The permissions for /home/pi as seen on the desktop machine show that they were already wacky by that time:


arjen@NUC10i5:/media/arjen/RPI-HUB/home$ ls -la
totaal 12
drwxr-xr-x  3 root  root  4096 18 mei 17:09 .
drwxr-xr-x 19 root  root  4096 20 mei 16:55 ..
drwx------ 21 arjen arjen 4096 20 mei 16:55 pi
arjen@NUC10i5:/media/arjen/RPI-HUB/home$

Later that evening I made the first timeshift snapshot, which shows the same:

root@RPI-HUB:/run/timeshift/15094/backup/timeshift/snapshots/2024-05-20_23-51-42/localhost/home# ls -la
total 12
drwxr-xr-x  3 root root 4096 May 18 17:09 .
drwxr-xr-x 18 root root 4096 May 20 23:51 ..
drwx------  2 pi   pi   4096 May 20 23:33 pi
root@RPI-HUB:/run/timeshift/15094/backup/timeshift/snapshots/2024-05-20_23-51-42/localhost/home#

No proof of what changed the permissions, but it happened in the first two days of the process (started on May 18th), when there were all sorts of problems related to the changeover to Wayland and the sudden lack of RealVNC access.
For all I now know it may have been a short circuit in my heated head that changed the permissions ...

Those wacky permissions must have caused some kind of error message in some log, but most logs have always looked like a jungle to me (which is probably why my own PiJuice event scripts all write their messages to a log that's easy to interpret.)

tvoverbeek · 2024-05-25T18:17:29Z

tvoverbeek
May 25, 2024
Maintainer

home directories get default protection 0700 (rwx------) in bookworm
Under bullseye and earlier it was 0755 (rwxr-xr-x).
Compare these 2 manpages:
https://manpages.debian.org/bullseye/adduser/adduser.conf.5 and
https://manpages.debian.org/bookworm/adduser/adduser.conf.5

You found out the hard way.
Anyway I need to modify the install script to give user pijuice recursive read access to the default user (uid 1000) home directory
Need to look into the use of ACLs

0 replies

ArjenR49 · 2024-05-26T13:24:33Z

ArjenR49
May 26, 2024
Author

Thanks for letting me off the hook, Tom. Quite a surprising change. I haven’t yet read any warnings about what it can cause. I only know what ACL is short for. Windows has those, too, but I never needed to use them. In July and later on this year will have physical access to the machine that now has bookworm installed and be able to help with testing. For the time being the home directory permissions are as they used to be, which defeats the change, of course. I assume there must be a sound reason for it. Op za 25 mei 2024 om 20:17 schreef Ton van Overbeek < ***@***.***>

…

home directories get default protection 0700 (rwx------) in bookworm Under bullseye and earlier it was 0755 (rwxr-xr-x). Compare these 2 manpages: https://manpages.debian.org/bullseye/adduser/adduser.conf.5 and https://manpages.debian.org/bookworm/adduser/adduser.conf.5 You found out the hard way. Anyway I need to modify the install script to give user pijuice recursive read access to the default user (uid 1000) home directory Need to look into the use of ACLs — Reply to this email directly, view it on GitHub <#1080 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANCBKNUOG6MMVFR7CX2KHWDZEDIU5AVCNFSM6AAAAABIDT7ISGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TKNJXGQYDM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

0 replies

[SOLVED] After rebuilding a Pi4 with bookworm, PiJuice events stopped working ... #1080

ArjenR49 May 22, 2024

Replies: 9 comments · 14 replies

tvoverbeek May 22, 2024 Maintainer

ArjenR49 May 22, 2024 Author

tvoverbeek May 22, 2024 Maintainer

ArjenR49 May 22, 2024 Author

ArjenR49 May 22, 2024 Author

ArjenR49 May 22, 2024 Author

ArjenR49 May 22, 2024 Author

tvoverbeek May 22, 2024 Maintainer

ArjenR49 May 22, 2024 Author

ArjenR49 May 24, 2024 Author

tvoverbeek May 24, 2024 Maintainer

ArjenR49 May 24, 2024 Author

ArjenR49 May 24, 2024 Author

ArjenR49 May 24, 2024 Author

tvoverbeek May 24, 2024 Maintainer

ArjenR49 May 24, 2024 Author

tvoverbeek May 24, 2024 Maintainer

ArjenR49 May 25, 2024 Author

ArjenR49 May 25, 2024 Author

ArjenR49 May 25, 2024 Author

ArjenR49 May 25, 2024 Author

tvoverbeek May 25, 2024 Maintainer

ArjenR49 May 26, 2024 Author

ArjenR49
May 22, 2024

Replies: 9 comments 14 replies

tvoverbeek
May 22, 2024
Maintainer

ArjenR49
May 22, 2024
Author

tvoverbeek May 22, 2024
Maintainer

ArjenR49 May 22, 2024
Author

ArjenR49 May 22, 2024
Author

ArjenR49 May 22, 2024
Author

ArjenR49 May 22, 2024
Author

tvoverbeek
May 22, 2024
Maintainer

ArjenR49 May 22, 2024
Author

ArjenR49
May 24, 2024
Author

tvoverbeek
May 24, 2024
Maintainer

ArjenR49 May 24, 2024
Author

ArjenR49 May 24, 2024
Author

ArjenR49 May 24, 2024
Author

tvoverbeek
May 24, 2024
Maintainer

ArjenR49 May 24, 2024
Author

tvoverbeek
May 24, 2024
Maintainer

ArjenR49 May 25, 2024
Author

ArjenR49 May 25, 2024
Author

ArjenR49 May 25, 2024
Author

ArjenR49 May 25, 2024
Author

tvoverbeek
May 25, 2024
Maintainer

ArjenR49
May 26, 2024
Author