Environment

• Pi hardware version: <3b+...>
• OS version:
• Application version: <where do I find this???>

To Reproduce
Steps to reproduce the behavior:

1. Install pi sugar 2 pro
2. Install software as per doc on wiki and get the server running, all good.
3. Remove pi sugar 2 pro and replace by pi sugar 3 plus
4. Go directly to webUI (I did not find any specific softwate install instructions for this device)
5. Still see pi sugar pro 2 web UI, with no battery status update

Expected behavior
Pi sugar 3 plus webUI should work right of the bat no? Do I need special software for this hardware as opposed to pisugar pro 2?

Please guide me to specific software install instructions for pi sugar 3 plus. And if I need to uninstall pi sugar 2 pro software fist, let me know and tell me how please.
Thanks

PI3B with PiSugar Pro and Pisugar powermanager.

When rebooting Pi from terminal with 'reboot'-command the power to the Pi is cut off. The Pi needs to be restarted by pressing the activate button in the Pisugar.

Expected is that with a reboot command the Pi remains under power and can restart without further manual intervention.

Do i do something wrong why it is not working?

Log info:

{
     "auto_wake_time": "2020-10-14T18:40:30.579+08:00",
     "auto_wake_repeat": 127,
     "single_tap_enable": false,
     "single_tap_shell": "",
     "double_tap_enable": false,
     "double_tap_shell": "",
     "long_tap_enable": false,
     "long_tap_shell": "",
     "auto_shutdown_level": 5.0,
     "auto_shutdown_delay": 2.0,
     "auto_charging_range": [
       80.0,
       100.0
     ],
     "full_charge_duration": null
   }

full_charge_duration variable is always null, though unwrap_or() is used......

Environment

• Pi hardware version: <zero w/PiSugar2>
• OS version: <Pi OS/bullseye...>
• Application version: <1.6.4>

To Reproduce
Steps to reproduce the behavior:

1. Connect solar input to board pads provided
2. Power on with battery only
3. get battery_power_plugged
4. result: battery_power_plugged: false
5. get battery_v
6. result: battery_v: 2.5999992
7. When battery is arround 4,2 volts
8. get battery
9. result: battery: 0

Expected behavior
Get the battery data when solar panel is plugged

Add a -d option to enable debug log

Environment

• Pi hardware version: Rpi4
• OS version: Raspbian Lite BullsEye
• Application version: N/A

To Reproduce
Steps to reproduce the behavior:

• Execute the script found here: https://github.com/PiSugar/pisugar-power-manager-rs/blob/master/scripts/BootWatchdogPiSugar3.sh
• Reboot the Rpi4 with PiSugar 3 in an invalid state or without the SD card or properly booting the system without resetting the boot watchdog bit.

Expected behavior
I expect the PiSugar to power off and restart after a minute and a half, as described in the documentation.
But the system keeps running normally.

Environment

• Pi hardware version: zero w
• OS version: VERSION="10 (buster)"
• Application version: 1.7.4 for PiSugar 3

Additional context

1: I can't seem to get the UPS to work as expected. If I unplug the pi zerow, it reboots instead of the battery taking over to supply power. If I having it running on battery and plug it in, it also reboots. Is this normal? How do you test this if this isn't the way?

2: The settings in the server don't save after a reboot. I turn on battery input protection and after one of these reboots that spontaneously happens when trying to get the battery to failover in problem number 1 above, the settings is back to default.

3: I am not getting i2c to work either. When I run i2cdetect -y 1 I get the following:

pi@PiZeroW-1:~ $ sudo i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- 57 -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
pi@PiZeroW-1:~ $

sudo i2cdump -y 1 0x32 and sudo i2cdump -y 1 0x75 produce nothing but X's

4: The RTC clock will not sync and stays at the year 2020.

Any help would be definitely appreciated as I have spent quite a bit of time combing through the "documentation" with no success.

The problem:

• RTC clocks should be set to UTC time on Linux systems (https://tldp.org/HOWTO/Clock-2.html). Currently, the web interface sets the RTC value to local time, which breaks things.
• Not only that, it sets the clock to write-protected afterwards, which caused me some confusion (should I open a separate issue for allowing the user to enable or disable write protection from the UI?)
• After manually setting the write protection bits to off with i2cset and updating the clock to UTC time, I notice that the web interface displays the UTC value but has my timezone offset labeled next to it. This is confusing.

Ideally, I believe it should function like this:

• Syncing the time to the RTC should set UTC. The user should configure their timezone as part of the system setup, which will handle DST or any other mechanisms.
• The local time should be displayed on the web interface. Perhaps there could also be an option to view the set UTC time (raw value of the RTC).

I wasn't sure if I should report this issue to cargo-aur, but other crates (i.e. sharkdp/bat) handled it fine, so I decided it was a problem specific to this crate.

Is Problem

:: Error: missing field `package` at line 9 column 1

As it turns out, I'm getting this error and cannot generate a PKGBUILD.

I decided to use PiSuger 2 Pro to build my own computer set with Rasbarry Pi 3 to do programming exercises and research for college. I have chosen the Manjaro Gnome to run satisfactorily on the inefficient Pi 3.
However, since Manjaro is an Arch system, and not any other RPM or APT system, it is not possible to use the ( #26 (comment) ) I took the choice. This is because a modern graphical interface is essential for the exercise.

Please let us have an ArchLinux package as soon as possible.
Thank you very much.

Environment

• Pi hardware version: Raspberry Pi Zero W Rev 1.1
• OS version: Raspbian GNU/Linux 11 (bullseye) (debian 11.4)
• Application version: 1.7.1
• PiSugar 3 firmware version: 1.2.6

When doing the firmware update of my PiSugar 3 board with curl https://cdn.pisugar.com/release/PiSugarUpdate.sh | sudo bash you should be asked the to confirm that the following is true:

WARNING:
1. PLEASE CONFIRM THAT THE BATTERY IS FULLY CHARGED
2. SYSTEMD SERVICE pisugar-server MUST BE STOPPED
OTHERWISE UPGRADE MAY NOT SUCCEED!!!
CONFIRM? (y or n):

However, the script just flies past this point and continues without any input. Then at the end, few seconds after the update is completed as successful with the following message:

Upgrade finished!
Wait 1s, PiSugar will jump to application soon!
Wait for five seconds
Starting pisugar-server...
Upgrade complete!
If you need help, visit https://github.com/PiSugar/

You get the following message to the terminal Low battery, will power off after 16 seconds and soon thereafter everything powers off.

The PiSugar logs are the following:

Aug 15 16:43:27 rolete systemd[1]: Stopping pisugar-server...
Aug 15 16:43:28 rolete systemd[1]: pisugar-server.service: Succeeded.
Aug 15 16:43:28 rolete systemd[1]: Stopped pisugar-server.
Aug 15 16:43:28 rolete systemd[1]: pisugar-server.service: Consumed 3.056s CPU time.
Aug 15 16:44:01 rolete systemd[1]: Started pisugar-server.
Aug 15 16:44:01 rolete pisugar-server[548]: [2022-08-15T14:44:01Z INFO  pisugar_core::pisugar3] PiSugar3 battery bus: 0x01 addr: 0x57
Aug 15 16:44:01 rolete pisugar-server[548]: [2022-08-15T14:44:01Z INFO  pisugar_server] TCP listening...
Aug 15 16:44:01 rolete pisugar-server[548]: [2022-08-15T14:44:01Z INFO  pisugar_server] WS listening...
Aug 15 16:44:01 rolete pisugar-server[548]: [2022-08-15T14:44:01Z INFO  pisugar_server] UDS listening...
Aug 15 16:44:01 rolete pisugar-server[548]: [2022-08-15T14:44:01Z INFO  pisugar_server] Http web server listening...
Aug 15 16:44:01 rolete pisugar-server[548]: [2022-08-15T14:44:01Z INFO  pisugar_core] Init rtc...
Aug 15 16:44:01 rolete pisugar-server[548]: [2022-08-15T14:44:01Z INFO  pisugar_core] Init battery...
Aug 15 16:44:07 rolete pisugar-server[548]: [2022-08-15T14:44:07Z WARN  pisugar_server] Battery low: 0
Aug 15 16:44:07 rolete pisugar-server[548]: [2022-08-15T14:44:07Z WARN  pisugar_server] Low battery, will power off after 16 seconds
Aug 15 16:44:07 rolete pisugar-server[548]: [2022-08-15T14:44:07Z WARN  pisugar_server] Battery low: 0
Aug 15 16:44:07 rolete pisugar-server[555]: Shutdown scheduled for Mon 2022-08-15 16:44:07 CEST, use 'shutdown -c' to cancel.
Aug 15 16:44:07 rolete pisugar-server[548]: [2022-08-15T14:44:07Z WARN  pisugar_server] Battery low: 0
Aug 15 16:44:07 rolete pisugar-server[559]: Shutdown scheduled for Mon 2022-08-15 16:44:07 CEST, use 'shutdown -c' to cancel.
Aug 15 16:44:07 rolete pisugar-server[548]: [2022-08-15T14:44:07Z WARN  pisugar_server] Battery low: 0
Aug 15 16:44:07 rolete pisugar-server[561]: Shutdown scheduled for Mon 2022-08-15 16:44:07 CEST, use 'shutdown -c' to cancel.
Aug 15 16:44:07 rolete pisugar-server[548]: [2022-08-15T14:44:07Z WARN  pisugar_server] Battery low: 0
Aug 15 16:44:08 rolete systemd[1]: Stopping pisugar-server...
Aug 15 16:44:10 rolete systemd[1]: pisugar-server.service: Succeeded.
Aug 15 16:44:10 rolete systemd[1]: pisugar-server.service: Unit process 562 (sh) remains running after unit stopped.
Aug 15 16:44:10 rolete systemd[1]: pisugar-server.service: Unit process 563 (shutdown) remains running after unit stopped.
Aug 15 16:44:10 rolete systemd[1]: Stopped pisugar-server.
Aug 15 16:44:10 rolete pisugar-server[563]: Failed to call ScheduleShutdown in logind, no action will be taken: Message recipient disconnected from message bus without replying

The first four lines are for shutting the server down by the firmware update script. Then update happens, and afterwards the pisugar-server is started again with the fifth line.

Using newser PiSugar(2) with Pi-4B with the official Pi-4 PSU, and getting 'false' with
get battery_power_plugged

Either:

1. I have a faulty PiSugar board, or

2. the PiSugar (by design) does not normally recharge when plugged into the mains and the Pi-4B - this is not how it was advertised and defeats the purpose of a UPS......in which case the name "battery power plugged" name is misleading - perahaps call it "battery_recharging" instead? or

3. the 'battery_power_plugged' query is not sourcing the correct value when querying the PiSugar, and should be "true" when PiSugar is plugged into the mains powering the Pi-4B.

it appears that;

• when the PiSugar is plugged into the mains, and the Pi-4B is not, then 'battery_power_plugged' = false. This implies the PiSugar is not recharging, but only providing power to the Pi-4B
• when only powering the RPi-4 via a PSU and not the UPS (unplugged from the mains), then 'get battery_power_plugged' = true. This implies the UPS is being recharged by the Pi-4B's power.
• when powering both the Pi-4B and the PiSugar with 2 PSU's, then 'get battery_power_plugged' = true. This implies the PiSugar re-charges with its own PSU and when the Pi-4 does not require power from it.

Also the charge % does not seem to change from 'get battery' in any case, so there's no way to know if the PiSugar is actually recharging or not.

Environment

• Pi hardware version: 4b
• OS version: Pi Desktop
• Application version: 1.7.4

To Reproduce
Steps to reproduce the behavior:

1. Set the soft poweroff level to 30
2. Soft poweroff shell: sudo shutdown -h now
3. Power stays on when battery goes below 30%

Expected behavior
Expected to shutdown when battery goes below 30%

Screenshots

I did some debugging in 'pisugar-core.rs' and 'ip5902.rs' and found that this code block seems to be the problem. If I swap the two gpio_value &... lines, the button began to work. I don' know if the 'if statement' itself is at fault, or the return values are in the wrong place..., but something is swapped.

Version: v1.4.3 and nightly v1.4.4 ( ee6c902 )

If /etc/pisugar-server/config.json has a bad value in auto_wake_time (like null), pisugar-core will fail to load.

Also, for some reason null is the default value after installing.

Somehow I managed to get a value that it liked in there and got it to load for one pi, but not the second.

Environment

• Pi hardware version: 4
• OS version: Pi OS Lite

To Reproduce
Steps to reproduce the behavior:

1. Set the 0x09 register to 30
2. Set the bit 5 of 0x02 address to 1

Expected behavior
The PiSugar should cut the power output after waiting for 30 seconds as specified in 0x09. But instead it cuts the power immediately.

• Pi hardware version: zero WH

Steps to reproduce the behavior:

1. Install Power Manager

After installing the Power Manager using "curl http://cdn.pisugar.com/release/pisugar-power-manager.sh | sudo bash," the Raspberry Pi Zero turns off. When I try to turn it back on, it shuts down after a few seconds. When I attempted to manually install version 1.7.5, everything seemed fine, but after trying to turn it back on, the power LED remains on, but it seems like the Pi is off because it's not recognized as being on by the PC. Is the armhf version the correct one for the Pi Zero WH?

Hi *!

/etc/debian_version
10.11

cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
(...)

cat /proc/cpuinfo
(...)
Hardware        : BCM2835
Revision        : 902120
Serial          : 000000004e3758e2
Model           : Raspberry Pi Zero 2 Rev 1.0

I wanted to ask, if someone can fix this:

Condition:

• PiSugar3 on Pi0-2W is set to "On Power Restore".
• Safe Shutdown on 30% battery-level is set, delay shutdown is set to 30 sec.

Behavior:
When power restorred on USB-C, still the battery has the level of <=30% (or below due to temperature drop...) and after booting up the "Safe Shutdown on 30% (or below)" cuts in resulting in a looping of permant rebooting.

Please add some kind of conditional check for this situation, so it does not shut down, when power is plugged.

is_battery_power_plugged = true on adequate points in code to circumvent this "looping".

Please execute safe shutdown in case of

if is_battery_power_plugged = false
or ( is_battery_power_plugged = true
AND USB-port is not delivering enough power (<200mA)
to charge the battery AND power the Pi0 same time to prevent deep discharge of the battery.

Thank you!
Best Regards!

Is your feature request related to a problem? Please describe.
Im doing a small project building and audio-streamer into a retro speaker. It contains a rpi zero with a justboom dac and a small amplifier. The speaker will have an on/off switch which will cut the power coming in. I have a relay which will make a gpio pin high when power is switched off, triggering a shutdown.I have ordered a PiSugar (2) to power the rpi while shutting down. This part works great. However when turning the switch on and supplying power back, the PiSugar does not automatically turn back on. I will have to turn the on/off switch off then on in order for it to start. This will be difficult since everything is inside a box.

Describe the solution you'd like
When power is re-supplied to the PiSugar, automatically turn back on.

Describe alternatives you've considered
I don't see any alternatives, but if there are any I would love to hear them.

Additional context

I want to run my PiSugar2 on a software emulated i2c bus (number 2), but the pisugar server does not connect.
I tried to change the Rust code to use 'with_bus(2)' instead if 'new()' and compiled it under linux.
But on the Raspberry Pi Zero W the systemd service constantly fails to start up:

pi@raspberrypi:/etc/pisugar-server$ sudo systemctl status pisugar-server.service
pisugar-server.service - pisugar-server
Loaded: loaded (/lib/systemd/system/pisugar-server.service; enabled; vendor preset: enabled)
Active: activating (auto-restart) (Result: signal) since Tue 2021-06-15 15:34:41 UTC; 6s ago
Process: 3902 ExecStart=/usr/bin/pisugar-server $OPTS (code=killed, signal=ILL)
Process: 3903 ExecStopPost=/bin/rm -f /tmp/pisugar-server.sock (code=exited, status=0/SUCCESS)
Main PID: 3902 (code=killed, signal=ILL)

Btw.: I can see the Pisugar2 using i2cdetect -y 2 ...

When I try to run the install pisugar power manager script :
curl http://cdn.pisugar.com/release/pisugar-power-manager.sh | sudo bash
it asks me to select the pisugar model but it doesn't respond. This is the configuring pisugar-server part of the script. Any ideas?

Environment

• Pi hardware version: Raspberry Pi Zero W Rev 1.1
• OS version: Raspbian GNU/Linux 11 (bullseye) (debian 11.4)
• Application version: 1.7.1
• PiSugar 3 firmware version: 1.2.6

The PiSugar3 board is connected to my pi zero w and is constantly charging through its USB-C port. It is running more or less normally -- apart from the same RTC problems as described in issue #74. However, I am constantly getting Read soft poweroff flag error warning in PiSugar logs (accessible through journalctl -u pisugar-server). The examples of warnings are:

1. Aug 16 07:03:38 rolete pisugar-server[262]: [2022-08-16T05:03:38Z WARN pisugar_core::pisugar3] Read soft poweroff flag error: I/O error: Remote I/O error (os error 121)
2. Aug 16 08:32:51 rolete pisugar-server[262]: [2022-08-16T06:32:51Z WARN pisugar_core::pisugar3] Read soft poweroff flag error: ctr2 changed during reading

The first warning is happening multiple times per hour and the second one multiple times per day. So they have a very different frequency.

Can someone explain what is the meaning behind those warnings? What should I do to prevent them?

UPDATE: There was an additional error that only occurred once so far:
3) Aug 17 10:21:23 rolete pisugar-server[262]: [2022-08-17T08:21:23Z ERROR pisugar_server] I/O error: Remote I/O error (os error 121)

What is this one about?

Checked on firefox and chrome as well as windows and os x to be sure, but I just see "...%" on the manager page.

I'm 95% that I have the 2 LED version (I'm assuming thats referring to the 2 blue led's on either side of the board - the amazon page wasn't very specific). Its definitely the 1200mAh battery for the Pi Zero. I've got some questions about cmd line usage but I'll save those for later.

Environment

• Pi hardware version: Pisugar2 Pro Portable 5000 mAh UPS + Raspberry Pi Zero 2 W
• OS version: Latest Raspian Buster and Raspian Bullseye as og 22th of Sep 2022
• Application version: 1.7.4

To Reproduce
Steps to reproduce the behavior:
Install using instructions https://github.com/PiSugar/pisugar-power-manager-rs and choose PiSugar 2 Pro or PPiSugar 2 (2-LEDs).

Choosing

• PiSugar 2 Pro leads to shutdowns within 1 minute
• PiSugar 2 (2-LEDs) leads to broken software and battery responds with constant 26%

Both issues are well known, see PiSugar/PiSugar#67 and PiSugar/PiSugar#51 without a reproducable solution or explanation.

Expected behavior
There is no hint why the Raspberry Pi Zero 2 W and other Raspberry Pi Zero models are not officially supported using the bigger UPS with 5000mah. The hardware itself seems to juice the Raspberry Pi Zero 2 W itself well so the software should follow too.

Screenshots

Additional context

I am currently using a PiSugar 2 Pro on a Raspberry Pi 4 running Manjaro.

I would like to be able to use the software here. I managed to successfully compile the server, however I don't know Rust enough to make a package correctly for Arch.

Hi sorry if this is not the correct place to ask but i couldn't discern what you meant by if your running 64x you need to manually install the pisugars software, what do i need to install? Thanks for any help, if its not painfully obvious im new at all this.

On a side note did you guys fix the issue with the sense hat conflicting with your battery? The other post about the issue said it would be fixed in rev3 but rev3 of what?

Does this new feature allow us to not have to press the "activate" button if the battery is disconnected or loses all charge?

PiZero W reboot loop when load pisugar-poweroff.service on boot process. How can I stop that service if i can't boot the PiZero?

Is there a simple command to immediately update the date on a Pi Zero from the Sugar2 RTC on boot?
At present I have a script that runs on boot (within crontab, @reboot...):

• take a camera snapshot using datetime as name;
• sends to FTP server;
• resets next wake time, either next hour or next day;
• shutdown.
  But it seems when Pi Zero first starts ,the internal clock is still set to time at last shutdown so files are being mis-named. Is there a way to add a step to immediately update date from the RTC? Date seems to auto update from board after a few minutes (although that could be purely due to being on wifi internet when testing), but need to do it earlier. Do I need to remove fake-hwclock app from Pi as you do when adding an external RTC board?

I am generating an sdcard image for my project using QEMU.
(https://wiki.debian.org/RaspberryPi/qemu-user-static)

It seems your deb packages fail to install

• mktemp
• TEMP_DEB=/tmp/tmp.kpff6YLkzb.deb
• wget -O /tmp/tmp.kpff6YLkzb.deb http://cdn.pisugar.com/release/pisugar-poweroff_1.4.9_armhf.deb
  --2021-03-27 22:03:23-- http://cdn.pisugar.com/release/pisugar-poweroff_1.4.9_armhf.deb
  Resolving cdn.pisugar.com (cdn.pisugar.com)... 47.246.22.184
  Connecting to cdn.pisugar.com (cdn.pisugar.com)|47.246.22.184|:80... connected.
  HTTP request sent, awaiting response... 200 OK
  Length: 276934 (270K) [application/x-debian-package]
  Saving to: ‘/tmp/tmp.kpff6YLkzb.deb’

/tmp/tmp.kpff6YLkzb.deb 100%[====================================>] 270.44K 672KB/s in 0.4s

2021-03-27 22:03:24 (672 KB/s) - ‘/tmp/tmp.kpff6YLkzb.deb’ saved [276934/276934]

• dpkg -i /tmp/tmp.kpff6YLkzb.deb
  Selecting previously unselected package pisugar-poweroff.
  (Reading database ... 95882 files and directories currently installed.)
  Preparing to unpack /tmp/tmp.kpff6YLkzb.deb ...
  Running in chroot, ignoring request: daemon-reload
  Unpacking pisugar-poweroff (1.4.9) ...
  Setting up pisugar-poweroff (1.4.9) ...
  mount: /config/device-tree: mount point does not exist.

• Failed to mount configfs - 2
  modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file '/lib/modules/5.4.0-70-generic/modules.dep.bin'
  modprobe: FATAL: Module i2c-dev not found in directory /lib/modules/5.4.0-70-generic
  mount: /config/device-tree: mount point does not exist.
• Failed to mount configfs - 2
  modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file '/lib/modules/5.4.0-70-generic/modules.dep.bin'
  modprobe: FATAL: Module i2c-dev not found in directory /lib/modules/5.4.0-70-generic
  Created symlink /etc/systemd/system/shutdown.target.wants/pisugar-poweroff.service → /lib/systemd/system/pisugar-poweroff.service.

• rm -f /tmp/tmp.kpff6YLkzb.deb

• mktemp

• TEMP_DEB=/tmp/tmp.kpff6YLkzb.deb

• wget -O /tmp/tmp.kpff6YLkzb.deb http://cdn.pisugar.com/release/pisugar-poweroff_1.4.9_armhf.deb
  --2021-03-27 22:03:23-- http://cdn.pisugar.com/release/pisugar-poweroff_1.4.9_armhf.deb
  Resolving cdn.pisugar.com (cdn.pisugar.com)... 47.246.22.184
  Connecting to cdn.pisugar.com (cdn.pisugar.com)|47.246.22.184|:80... connected.
  HTTP request sent, awaiting response... 200 OK
  Length: 276934 (270K) [application/x-debian-package]
  Saving to: ‘/tmp/tmp.kpff6YLkzb.deb’

/tmp/tmp.kpff6YLkzb.deb 100%[====================================>] 270.44K 672KB/s in 0.4s

2021-03-27 22:03:24 (672 KB/s) - ‘/tmp/tmp.kpff6YLkzb.deb’ saved [276934/276934]

• dpkg -i /tmp/tmp.kpff6YLkzb.deb
  Selecting previously unselected package pisugar-poweroff.
  (Reading database ... 95882 files and directories currently installed.)
  Preparing to unpack /tmp/tmp.kpff6YLkzb.deb ...
  Running in chroot, ignoring request: daemon-reload
  Unpacking pisugar-poweroff (1.4.9) ...
  Setting up pisugar-poweroff (1.4.9) ...
  mount: /config/device-tree: mount point does not exist.

• Failed to mount configfs - 2
  modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file '/lib/modules/5.4.0-70-generic/modules.dep.bin'
  modprobe: FATAL: Module i2c-dev not found in directory /lib/modules/5.4.0-70-generic
  mount: /config/device-tree: mount point does not exist.
• Failed to mount configfs - 2
  modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file '/lib/modules/5.4.0-70-generic/modules.dep.bin'
  modprobe: FATAL: Module i2c-dev not found in directory /lib/modules/5.4.0-70-generic
  Created symlink /etc/systemd/system/shutdown.target.wants/pisugar-poweroff.service → /lib/systemd/system/pisugar-poweroff.service.

• rm -f /tmp/tmp.kpff6YLkzb.deb

Is your feature request related to a problem? Please describe.
I'm trying to script a .sh or .py script that will flash the PiSugar 2 Pro LED based on the current batter life (0-19% 1 flash, 20-39% 2 flash, ... , 79-100% OR charging=true is 5 flashes.

Shown below is the code I'm trying to execute on "single button click" but it's not getting me very far. I'm almost positive it's because it has no idea what to do with "flash_led" command--I'm just using it as a placeholder at the moment.

Best I can tell from reverse-engineering a little bit, I'm going to have to send signals or breaks to the GPIO that controls the LED? Any input would be appreciated.

#!/bin/bash

flash_led() {
    for ((i=0; i<$1; i++)); do
        sudo python3 /path/to/flash_led.sh
    done
}

check_battery_status() {
    battery_output=$(echo "get battery" | nc -U /tmp/pisugar-server.sock)
    charging_output=$(echo "get battery_charging" | nc -U /tmp/pisugar-server.sock)

    battery_percentage=$(echo "$battery_output" | tr -d '\r' | awk '{print $1}')
    is_charging=$(echo "$charging_output" | tr -d '\r' | awk '{print tolower($1)}')

    if [[ $battery_percentage -ge 0 && $battery_percentage -le 19 ]]; then
        flash_led 1
    elif [[ $battery_percentage -ge 21 && $battery_percentage -le 39 ]]; then
        flash_led 2
    elif [[ $battery_percentage -ge 40 && $battery_percentage -le 59 ]]; then
        flash_led 3
    elif [[ $battery_percentage -ge 60 && $battery_percentage -le 79 ]]; then
        flash_led 4
    elif [[ $battery_percentage -ge 80 || $is_charging == "true" ]]; then
        flash_led 5
    fi
}

check_battery_status

Environment

• Pi hardware version: Zero 2
• OS version: Pi OS lite Buster
• Application version: 1.5.0
• Should note that doing everything through ssh

To Reproduce
Steps to reproduce the behavior:
After installing 1.5.0 of piserver using curl http://cdn.pisugar.com/release/Pisugar-power-manager.sh | sudo bash
The battery seems to communicated fine with raspberry pi, can request any battery flag using nc -U /tmp/pisugar-server.sock and then typing in a request. But the RTC return nothing but Invalid request.

Expected behavior
Should be able to request data from RTC

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
I2C tools shows both i2c addresses.

pi@DropCam:~ $ sudo nc -U /tmp/pisugar-server.sock
get model
model: PiSugar 2 (2-LEDs)
get rtc_alarm_time
Invalid request.
get rtc_time
Invalid request.
get battery_i
battery_i: -0.17294818

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- 32 -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- 75 -- --

pi@DropCam:~ $ i2cdump -y 1 0x32
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 13 38 a1 01 20 12 21 00 13 21 7f 20 12 21 00 00    ?8?? ?!.?!? ?!..
10: 52 0b 00 00 93 79 bf bf 02 be fb eb fe df eb ff    R?..?y?????????.
20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
80: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
90: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
a0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
b0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
c0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
d0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
e0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
f0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX

 i2cdump -y 1 0x75
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: ea fe 7b 68 37 00 9d 00 00 04 7e 62 4b 00 00 00    ??{h7.?..?~bK...
10: d9 ba 01 00 80 33 00 84 00 00 00 00 00 00 00 00    ???.?3.?........
20: fa 2e 52 48 85 d7 b0 93 00 00 00 00 00 00 00 00    ?.RH????........
30: fe b4 52 ab 9c 9d 85 4a fd 6d 14 00 00 00 00 00    ??R????J?m?.....
40: 51 0a 11 23 d5 00 00 00 00 00 1f 55 01 00 00 00    Q??#?.....?U?...
50: 05 14 04 12 04 00 00 00 00 00 00 00 00 00 00 00    ?????...........
60: 00 00 00 00 00 00 ff 00 00 00 00 00 00 00 00 00    ................
70: 25 00 1c e0 1b 00 0c 01 00 00 01 70 03 06 00 11    %.???.??..?p??.?
80: 53 66 86 af 5a 72 a4 5f 91 00 00 00 00 00 00 00    Sf??Zr?_?.......
90: 7f 8c a6 d0 84 97 c4 87 b0 00 00 00 00 00 00 00    ?????????.......
a0: 99 0f 07 14 cc 3e 44 2c fa 13 10 12 0d 1a 00 00    ?????>D,??????..
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................

I tried using all the different versions of PiSugar server/power manager from 1.5.0 to 1.6.3, they all gave different results, I could almost make it work with 1.6.3, but I would have to go back and manually configure /etc/defaults/pisugar-server, and /etc/pisugar-server/config.json, as the default file was messed up because of the OSD menu(not actually sure what it is called, but it's the blue screen) that asks about the type of PiSugar, and the login for the config.json was messed up, the user would say OK, I'm thinking its becasue of the OSD menu. But when I did this I could communicate with the RTC, but the behaviour wasn't right either. When setting the alarm the time would populate correctly but the date would always have the year 2020 or 1999. I also tried installing 1.6.3 then down grading to 1.5, and it would work better the dates would still be messed up.

Not sure what is causing the breakdown, In the meantime ive gone back to using a Pi Zero. I would love to be able to use my Pi Zero 2 as it is much faster, although a little more power hungry. But for my application which is a long duration timelapse, I need to be able to boot fast take a picture and and shutdown fast. then wait until the next photo to start the cycle again.

Update:
I started a new install of Buster on the Zero 2, and installed PiSugar software using :
wget http://cdn.pisugar.com/release/pisugar-power-manager.sh
sudo bash pisugar-power-manager.sh -c release

Installed version 1.6.3, like I stated earlier it would mess up the config.json and deafult/pisugar-server file. Below is what it reports:

Config.JSON - think it's pulling info from the OSD for the auth. I usually change it back to admin, admin. Or as you see later I'll just disabled it.

{
  "digest_auth": [
    "ok",
    "admin"
  ],
  "i2c_bus": 1,
  "auto_wake_time": null,
  "auto_wake_repeat": 0,
  "single_tap_enable": false,
  "single_tap_shell": "",
  "double_tap_enable": false,
  "double_tap_shell": "",
  "long_tap_enable": false,
  "long_tap_shell": "",
  "auto_shutdown_level": 0,
  "auto_shutdown_delay": 0,
  "auto_charging_range": [
    80,
    100
  ],
  "full_charge_duration": null,
  "auto_power_on": false,
  "auto_rtc_sync": false
}

This is the contents of the /etc/default.pisugar-server file

OPTS=--config config.json --model '20 Unsupported command "/usr/bin/raspi-config" (full line was "/usr/bin/raspi-config") received from confmodule.' --tcp PiSugar 2 (2-LEDs):8423 --uds /tmp/pisugar-server.sock

So I cahnged it to:

OPTS="--model 'PiSugar 2 (2-LEDs)' --syslog --config config.json --uds /tmp/pisugar-server.sock --tcp 0.0.0.0:8423 --ws 0.0.0.0:8422 --web /usr/share/pisugar-server/web --http 0.0.0.0:8421"

After fixing up these files I'll send the following to disable the auth :
echo "set_auth" | nc -q 0 127.0.0.1 8423

And as you can see it is working. Well mostly, there seems to be an issue with the alarm date, but the RTC will communicate now.

Here you can see that the alarm set is accepted but when reported back the date is wrong:

pi@DropCam:~ $ sudo nc -U /tmp/pisugar-server.sock
get battery
battery: 95.91772
get model
model: PiSugar 2 (2-LEDs)
rtc_alarm_set 2021-12-20T17:00:00-07:00 127
rtc_alarm_set: done
get rtc_alarm_time
rtc_alarm_time: 1999-12-31T17:00:00-07:00
get rtc_time
rtc_time: 2021-12-20T16:54:14-07:00
rtc_web
rtc_web: done
get rtc_time
rtc_time: 2021-12-20T16:54:26-07:00
get rtc_alarm_enabled
rtc_alarm_enabled: true

Hope this helps you guys!

I'm seeing hundreds of messages that presumably the pisugar-server issues to the journal when the pisugar is not present? Shouldn't the server recognize lack of the sugar and go to standby mode? Or do I need to run a script on startup that looks for it and then disable/enable the server?

Oct 20 13:42:56 raspberrypi pisugar-server[345]: [2023-10-20T17:42:56Z INFO  pisugar_core] Init rtc...
Oct 20 13:42:56 raspberrypi pisugar-server[345]: [2023-10-20T17:42:56Z INFO  pisugar_core] Init rtc...
Oct 20 13:42:56 raspberrypi pisugar-server[345]: [2023-10-20T17:42:56Z INFO  pisugar_core] Init rtc...
Oct 20 13:42:56 raspberrypi pisugar-server[345]: [2023-10-20T17:42:56Z INFO  pisugar_core] Init rtc...
Oct 20 13:42:56 raspberrypi pisugar-server[345]: [2023-10-20T17:42:56Z INFO  pisugar_core] Init rtc...
Oct 20 13:42:56 raspberrypi pisugar-server[345]: [2023-10-20T17:42:56Z INFO  pisugar_core] Init rtc...
Oct 20 13:42:56 raspberrypi pisugar-server[345]: [2023-10-20T17:42:56Z INFO  pisugar_core] Init rtc...

Hi,

I am monitoring the battery by rpimonitor which sends get* to the server pisugar-server each 10sec.

pisugar-server logs each access to /var/log/syslog, saturating the log.

I tried preventing the server from loging to syslog, but cant find an option. My server is launched with the default options (from /etc/default/pisugar-server) :

OPTS=--config config.json --model 'PiSugar 2 Pro' --web /usr/share/pisugar-server/web --http 0.0.0.0:8421 --ws 0.0.0.0:8422 --tcp 0.0.0.0:8423 --uds /tmp/pisugar-server.sock

I tried the -s option, but it does not change anything.

Is it possible to add an argument to -s to give a specific log file ? I can then pit /dev/null, or add an option to prevent from logging each access to the server ? or the ones from localhost ?

Thx !

L

Jan 8 15:31:55 pi4 pisugar-server[341]: [2021-01-08T14:31:55Z INFO pisugar_server] Incoming tcp connection from: 127.0.0.1:46092
Jan 8 15:31:55 pi4 pisugar-server[341]: [2021-01-08T14:31:55Z INFO pisugar_server] Incoming tcp connection from: 127.0.0.1:46094
Jan 8 15:31:55 pi4 pisugar-server[341]: [2021-01-08T14:31:55Z INFO pisugar_server] Incoming tcp connection from: 127.0.0.1:46096
Jan 8 15:32:05 pi4 pisugar-server[341]: [2021-01-08T14:32:05Z INFO pisugar_server] Incoming tcp connection from: 127.0.0.1:46098
Jan 8 15:32:05 pi4 pisugar-server[341]: [2021-01-08T14:32:05Z INFO pisugar_server] Incoming tcp connection from: 127.0.0.1:46100
Jan 8 15:32:05 pi4 pisugar-server[341]: [2021-01-08T14:32:05Z INFO pisugar_server] Incoming tcp connection from: 127.0.0.1:46102
Jan 8 15:32:05 pi4 pisugar-server[341]: [2021-01-08T14:32:05Z INFO pisugar_server] Incoming tcp connection from: 127.0.0.1:46104
Jan 8 15:32:06 pi4 pisugar-server[341]: [2021-01-08T14:32:06Z INFO pisugar_server] Incoming tcp connection from: 127.0.0.1:46106
Jan 8 15:32:06 pi4 pisugar-server[341]: [2021-01-08T14:32:06Z INFO pisugar_server] Incoming tcp connection from: 127.0.0.1:46108
Jan 8 15:32:06 pi4 pisugar-server[341]: [2021-01-08T14:32:06Z INFO pisugar_server] Incoming tcp connection from: 127.0.0.1:46110
Jan 8 15:32:06 pi4 pisugar-server[341]: [2021-01-08T14:32:06Z INFO pisugar_server] Incoming tcp connection from: 127.0.0.1:46112
Jan 8 15:32:06 pi4 pisugar-server[341]: [2021-01-08T14:32:06Z INFO pisugar_server] Incoming tcp connection from: 127.0.0.1:46114

I probably need to file this bug with rppal, but I'll post it here in case anyone else runs into it...

I've got a system that runs the Debian kernel as opposed to raspbian kernel, and after probing i2c-dev and i2c-bcm2835, the pisugar 2 pro is on i2c-3 and not i2c-0 or i2c-1 like is expected.

~/git/pisugar-power-manager-rs] # i2cdump -y -a 3 0x32
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 10 57 98 06 03 04 21 00 00 00 00 00 00 00 00 00    ?W????!.........
10: 10 00 00 00 00 00 2b 00 82 00 e0 3e 00 00 03 4f    ?.....+.?.?>..?O
20: 54 24 02 17 07 01 01 27 00 08 07 01 56 32 2e 30    T$?????'.???V2.0
30: 50 69 53 75 67 61 72 20 54 65 61 6d 20 20 20 20    PiSugar Team
40: 4d 61 64 65 20 62 79 20 68 75 6d 61 6e 20 6f 6e    Made by human on
50: 65 61 72 74 68 2e 20 20 20 20 20 20 20 20 20 20    earth.
60: 77 77 77 2e 50 69 53 75 67 61 72 2e 63 6f 6d 20    www.PiSugar.com
70: 20 20 17 11 09 39 17 34 11 86 ff ff ff ff ff ff      ???9?4??......
80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................

What I had to do was fork the rppal repo, and modify the line that sets the bus from 1 to 3, and then modified the pisugar-core cargo toml to point to my local checkout that has the info in there. Once I did this, I was able to use the manager correctly.

Right now, installing the package requires the user to manually select the PiSugar 2 Pro version.

Is it possible to modify the installation script to provide an installation without any user interaction? I am planning on using this on a large scale development

Environment

• Pi hardware version: <4,8gb>
• OS version: <UbuntuMate 64x>
• Application version: <1.5.0/1.5.1...>

To Reproduce
Steps to reproduce the behavior:
Just use you wget command to download and install your software.

Expected behavior
I was hoping to install the safe shutdown

Additional context
I have enabled 12c on my pi and can use
Ls /dev/i2c*
It returns:
/dev/i2c-1

Your wget still returns:
Open I2C Interface
Sudo: raspi-config: command not found

I have looked online but not found answers, is it checking if i2c is enabled or is it checking an rpi specific file to see if it should be enabled? Is there a way to fix this?

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Is there a way to turn off the blue LED lights?

Describe the solution you'd like
A clear and concise description of what you want to happen.
Need to turn off the blue LED lights

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
None

Additional context
Add any other context or screenshots about the feature request here.

Add exit command, make it easier when programming in shell script with nc

Hi,
i've recently buyed a Pisugar 3, for using it with a Raspberry PI Zero W and the Pwnagotchi image.
I need to use the hardware RTC onboard, but unfortunately there's no way to make it work. Before buiyng the Pisugar, the Raspberry was equipped with a hardware rtc from Adafruit and it worked like a charm. I uninstalled it before installing the Pisugar, and started with a fresh os image.
With the i2cdetect -y 1 command I correctly see the 0x68 address, but I don't find any overlay or config to make it work. I've also tried this guide whit no luck https://learn.adafruit.com/adding-a-real-time-clock-to-raspberry-pi/set-rtc-time

Anyone has some info or solution, or knows the precise model of the RTC on board of Pisugar 3?

Thanks

My pi setup requires a specific shutdown command.

I saw that there is a wall announcement made to all logged in users if there is a delay set, however I wish to be able to run a command before shutdown or ideally use a custom shutdown command.

AFAIK, I can't observe wall messages programatically and react to it. The machine runs headless, so it doesn't always have a user logged in.

Broadcast a meesage to all user when PiSugar has low battery, and then we could save all works before system shutdown.

installing component 'rustc'
31.1 MiB / 49.3 MiB ( 63 %) 1.2 MiB/s in 38s ETA: 14smemory allocation of 146176856 bytes failedAborted

SOLUTION:
rust-lang/rustup#2128

This is using a raspberry pi 4 with the hyperpixel 4.0 touchscreen ( the wide one.. - https://shop.pimoroni.com/products/hyperpixel-4?variant=12569485443155 )

I had followed directions on the main github page and it installed 1.4.4 today, which refused to start saying it could not load configuration. Saw there was 1.4.5 release, installed that.

Now I can get the webUI but it does not show battery percentage. Trying the commands to the API socket, I get 'invalid request' from everything that would need to reach the hardware , such as 'get battery'.

syslog has error messages - ERROR pisugar_server] Invalid slave address : 117

ls /dev/i2c* shows I have only a /dev/i2c-11

The hyperpixel connects to the Pi and takes over most of the GPIO pins, but it does break out i2c on its board. I am not familiar with this level of hardware at all, is why I bought the Pi was to learn about it and play retro arcade games, but would be more than happy to get you any logs or test something for you, just let me know what you might need.

I'm unsure how difficult a feature this would be to implement, but it would be nice to have the option of using HTTPS. I reverse proxy all my network services in order to use my domain's SSL certificate, but can't do that for the pisugar interface because it loads an insecure websocket.

Keep track of PiSugar/PiSugar#12

Is your feature request related to a problem? Please describe.
users right now have to

1. press a button my pi device to shut down the application and the raspberry pi.
2. then Wait till the green light finishes processing - 10s?
3. THEN they have to flip the pi-sugar switch to turn it off.

Describe the solution you'd like
I want my users to flip the switch to turn it on,
and flip the switch to turn the unit off (not have to press a button to shutdown the raspberry pi and program first). The switch would shutdown raspberrypi program and raspbian first then stop feeding power for a completely safe shutdown process.

having trouble figuring out what i need to download for my S plus to shutdown the pi when the power is low or when I pres the button. I saw the PiSugarSButtonActive.sh but i'm unsure what it does and how to use it properly.

Environment

• Pi hardware version: Zero 2 W
• OS version: arch linux (PiKVM) Linux pikvm 5.10.52-14-ARCH #1 SMP Thu Dec 2 10:51:34 MSK 2021 armv7l GNU/Linux
• Application version: 1.6.4-1

Screenshots
the pisugar-archlinux_1.6.4_all.tar.gz doesn't include a folder for the armv7h architecture

==> Making package: pisugar-bin 1.6.4-1 (Sat Feb 19 16:57:28 2022)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
-> Found pisugar-bin_1.6.4_all.tar.gz
==> Validating source files with sha256sums...
pisugar-bin_1.6.4_all.tar.gz ... Passed
==> Extracting sources...
-> Extracting pisugar-bin_1.6.4_all.tar.gz with bsdtar
==> Removing existing $pkgdir/ directory...
==> Entering fakeroot environment...
==> Starting package()...
/home/pisugar/pisugar-archlinux/PKGBUILD: line 24: cd: armv7h: No such file or d irectory
==> ERROR: A failure occurred in package().
Aborting...

Additional context
after changing the line 24 on PKGBUILD from : cd "$CARCH" to cd armhf
the installation proceed :
==> Making package: pisugar-bin 1.6.4-1 (Sat Feb 19 17:05:22 2022)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
-> Found pisugar-bin_1.6.4_all.tar.gz
==> Validating source files with sha256sums...
pisugar-bin_1.6.4_all.tar.gz ... Passed
==> Extracting sources...
-> Extracting pisugar-bin_1.6.4_all.tar.gz with bsdtar
==> Removing existing $pkgdir/ directory...
==> Entering fakeroot environment...
==> Starting package()...
==> Tidying install...
-> Removing libtool files...
-> Purging unwanted files...
-> Removing static library files...
-> Stripping unneeded symbols from binaries and libraries...
-> Compressing man and info pages...
==> Checking for packaging issues...
==> Creating package "pisugar-bin"...
-> Generating .PKGINFO file...
-> Generating .BUILDINFO file...
-> Adding install file...
-> Generating .MTREE file...
-> Compressing package...
==> Leaving fakeroot environment.
==> Finished making: pisugar-bin 1.6.4-1 (Sat Feb 19 17:05:50 2022)
==> Installing package pisugar-bin with pacman -U...

but ultimately fail to launch the service :
PiSugar hardware model:

1. PiSugar 3 3) PiSugar 2 (2-LEDs)
2. PiSugar 2 Pro 4) PiSugar 2 (4-LEDs)
   #? 3
   Model: PiSugar 2 (2-LEDs)
   Created symlink /etc/systemd/system/multi-user.target.wants/pisugar-server.servi ce -> /usr/lib/systemd/system/pisugar-server.service.
   Job for pisugar-server.service failed because of unavailable resources or anothe r system error.
   See "systemctl status pisugar-server.service" and "journalctl -xeu pisugar-serve r.service" for details.

here is the output of "journalctl -xeu pisugar-server.service" :

Feb 19 18:08:11 pikvmz2.anytrack.me systemd[1]: pisugar-server.service: Scheduled restart job, restart counter is at 260.
Feb 19 18:08:11 pikvmz2.anytrack.me systemd[1]: Stopped pisugar-server.
Feb 19 18:08:11 pikvmz2.anytrack.me systemd[1]: pisugar-server.service: Failed to load environment files: No such file or directory
Feb 19 18:08:11 pikvmz2.anytrack.me systemd[1]: pisugar-server.service: Failed to run 'start' task: No such file or directory
Feb 19 18:08:11 pikvmz2.anytrack.me systemd[1]: pisugar-server.service: Failed to load environment files: No such file or directory
Feb 19 18:08:11 pikvmz2.anytrack.me systemd[1]: pisugar-server.service: Failed to run 'stop-post' task: No such file or directory
Feb 19 18:08:11 pikvmz2.anytrack.me systemd[1]: pisugar-server.service: Failed with result 'resources'.
Feb 19 18:08:11 pikvmz2.anytrack.me systemd[1]: Failed to start pisugar-server.

I2C module is enabled here is the output of "ls -al /dev/i2c*" :

crw------- 1 root root 89, 0 Feb 10 22:20 /dev/i2c-0
crw------- 1 root root 89, 1 Feb 10 22:20 /dev/i2c-1
crw------- 1 root root 89, 10 Feb 10 22:20 /dev/i2c-10
crw------- 1 root root 89, 11 Feb 10 22:20 /dev/i2c-11

Environment

• Pi hardware version: Raspberry Pi Model 3 A+
• PiSugar hardware version: PiSugar 2 Plus
• OS version: Linux raspberrypi 5.15.61-v7+
• Application version:

pisugar-programmer --version
pisugar-programmer 1.7.4

To Reproduce

$ echo "get rtc_time" | nc -q 0 127.0.0.1 8423
rtc_time: 2022-12-12T20:40:37.000-05:00
$ echo "rtc_alarm_set 2022-12-12T21:00:00-05:00 127" | nc -q 0 127.0.0.1 8423
rtc_alarm_set: done
$ echo "get rtc_alarm_time" | nc -q 0 127.0.0.1 8423
rtc_alarm_time: 1999-12-31T21:00:00.000-05:00
$ echo "get rtc_alarm_enabled" | nc -q 0 127.0.0.1 8423
rtc_alarm_enabled: true
$ sudo pisugar-poweroff --model "PiSugar 2 Pro"                      
3 2 1 0...

Expected behavior

Approx. 20 minutes later at 21:00 I thought the Raspberry Pi would reboot; but it did not.