PiSupply / PiJuice

Resources for PiJuice HAT for Raspberry Pi - use your Pi Anywhere

https://uk.pi-supply.com/collections/pijuice/products/pijuice-portable-power-raspberry-pi

GNU General Public License v3.0

438 stars 104 forks source link

Issues with “Wakeup” and with “Minimum charge threshold”. #623

Open FyHy opened 3 years ago

FyHy commented 3 years ago

Hello, I am refining a longstanding project by the introduction of a PiJuice. Briefly, the project is a system to monitor, remotely, the state of a pair of 12V batteries so that I can prevent them falling to an unacceptable/un-recoverable low state of charge. Presently, I have a Pi3B+ taking a serial input of various parameters from the batteries and saving them to an MSQL database. There is no Internet on site and so contact with the Pi is by way of SMS which has proved very successful in accessing the data and managing the Pi. Running this system continuously would be counter-productive as it would use more power from the batteries than would be helpful.

I am therefore looking at introducing the PiJuice to run the system at regular but infrequent times. Having reviewed the available paperwork, I have the PiJuice on test at home on a Pi3A+. When used, the power supply to the PiJuice is from an “official” power supply. The default addresses and drivers are being used and as I am simulating no Internet, the time in the Pi was copied to the RTC at the outset and the test program copies it back to the Pi on each reboot. This has only drifted 45 seconds in two weeks which is acceptable to me and in any case, I can correct it via an SMS. That seems to work fine. For test purposes, I have a wakeup alarm set for every 10 minutes and use the wakeup_enable.py from the software section of the manual. Other than the issues below, when it works, it works fine.

I have a simple piece of coding started by cron on reboot which logs the wakeup time, a mid-point time and a shutdown time to a text file. After 4 minutes it powers off. The system tasks are set to fully power off the Pi after a further 30 seconds.

The test code is: `#!/usr/bin/python3

from time import localtime, strftime, strptime, sleep import os import sys

while not os.path.exists('/dev/i2c-1'): time.sleep(0.1)

os.system("sudo hwclock -s")

print (strftime("%d:%m:%y %H:%M:%S", localtime()))

stringtime_WU = strftime("%d:%m:%y %H:%M:%S", localtime()) file_PJ = open('PJ_Actions.txt', 'a') Wake_up = ("Woken up at: " + stringtime_WU + '\n') file_PJ.write(Wake_up) file_PJ.close()

sleep(120)

stringtime_Mid = strftime("%d:%m:%y %H:%M:%S", localtime()) file_PJ = open('PJ_Actions.txt', 'a') Mid_Time = ("Mid Time at: " + stringtime_Mid+ '\n') file_PJ.write(Mid_Time) file_PJ.close()

sleep(120)

stringtime_SD = strftime("%d:%m:%y %H:%M:%S", localtime()) file_PJ = open('PJ_Actions.txt', 'a') Shut_Down = ("Shutting down at: " + stringtime_SD + '\n') file_PJ.write(Shut_Down) file_PJ.close()

os.system("sudo poweroff")`

The System Tasks are also enabled to ”Wakeup on charge” at 5% and “Minimum charge threshold” of 10%. The “Software Halt Power off” is set to 30 seconds as above. The “System task enabled” is checked and the settings “applied”.

The issues I have are: 1) If I unplug the power supply at source to simulate a power loss, everything is fine until I notice that it has passed the 10% threshold and it is still waking up the Pi every 10 minutes. This has been as low as 3% before I have stepped in to re-connect to save the RTC. It has never properly shutdown at 10%. 2) Having reconnected the power supply as at 1), the Pi is restarted at the next 10 minute scheduled time and switches off after the 4 minute “simulated work schedule”. After that nothing. There are no further wakeups. If I manually restart it, it does the 4 minute routine and then shuts down. After that there are still no further wakeups. If I manually restart things and then click on “Set Alarm” we are back cooking on gas. Do I have to add this to the end of the snippet as above. That rather defeats the whole idea of a wakeup system. 3) “Wakeup enabled” stays checked at all times but I have noticed that when things are running to schedule there is also a “Last enabled time” posted.

Summary: The PiJuice seems to ignore the Minimum charge threshold. The Wakeup Alarm seems not to function past a restoration of power to the PiJuice.

Have I missed something in the manual?

HyFy

tvoverbeek commented 3 years ago

@FyHy Need some additional info. What action have you connected to the low charge event (= the event which gets triggered when the min charge threshold is passed). See the System Events tab.

FyHy commented 3 years ago

Thanks for the prompt Ton. As I suggested, I guessed I had missed something. I had not not selected any option. I guess "Halt" is what I need. I had "ASSUME"d too much and that spells that it makes an A.. out of U and ME!! My error but thanks. FyHy

FyHy commented 3 years ago

OK I've unplugged it and we can await the correction working as I'm sure that it will. FyHy

tvoverbeek commented 3 years ago

I am afraid you might end up with a reboot loop, since the wakeup on charge level is lower than the minimum charge. If you shut down at min charge level 10% then I would put the wakeup on charge at e.g. 20%

FyHy commented 3 years ago

Thanks for that reply. The charge was already down to 19% and the Wakeup on charge would either take 10% or 100%. So for test I've dropped the Minimum charge to 5% and left the wakeup charge at 10%. After this cycle I will see if it will take 20 %.

FyHy

On Mon, 11 Jan 2021 at 12:30, Ton van Overbeek notifications@github.com wrote:

I am afraid you might end up with a reboot loop, since the wakeup on charge level is lower than the minimum charge. If yous hut down at min charge level 10% then I would put the wakeup on charge at e.g. 20%

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/PiSupply/PiJuice/issues/623#issuecomment-757921771, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEOI42ISOROQYAZSSRWA4R3SZLVPZANCNFSM4V4VCCKA .

FyHy commented 3 years ago

OK. I wasn't convinced that it shut down properly at 5 %.

I've re-charged it to 50% and have changed the wakeup charge to 20% and the minimum charge to 10%. I will await it dropping which probably won't be tonight although I've piled on WiFi etc to help it on its way.

FyHy

FyHy commented 3 years ago

By the way - thanks for your attention. FyHy

FyHy commented 3 years ago

The last test has run its course and it shut down at 10% charge. I restored the power supply and at 20% charge the PiJuice restarted the Pi which ran the 4 minute routine. But again as before the PiJuice did not wake up at the next 10 minute interval or subsequent intervals. I have manually restarted it this morning. Again the Pi ran the 4 minute routine but the PiJuice did not respond to the next wake up alarm. I have again manually restarted things and the Wakeup Alarm window is showing all of the correct settings including the Wakeup enabled check box. There is also the flag: "Last: (time of last manual restart)". I have clicked on "Set Alarm". Since this the system has behaved perfectly. I will re-read the manual to see if I have missed a confirmatory setting etc.

FyHy commented 3 years ago

Just to keep this live, I have had one shutdown on 10% and restart at 20% but the 4 minute routine every 10 minutes had to be manually restarted and the alarm manually re-set. I then had an inconclusive test. In order to speed up the testing I set the shutdown at 70% and the wakeup on charge at 80%. It passed the 70 % but then strangely rebooted every time interval but then immediately shutdown until it was at 51%. It did this for an hour before I stepped in to put it back on charge. It woke up at 80% charge but needed the alarm to be manually reset. I have returned the shutdown charge at 10% and the wakeup charge at 20%. It is presently discharging. I am hoping to be available when it gets to 10 %. The wakeup_enable.py is starting with cron as is the test routine. Are there any suggestions as to what I could be looking out for? The number of man hours that this de-bugging is taking may mean I seek another way of doing the monitoring job!!

FyHy

FyHy commented 3 years ago

Issue closed - lack of progress. I may re-open the issues individually when time allows. FyHy

tvoverbeek commented 3 years ago

Do not use the wakeup_enable.py at boot. I suppose your Pi has an internet connection (4G modem to send SMS). In that case if a systemctl-timesyncd time synchronization occurs the internal rtc-alarm wakeup will be cleared. Try adding the code from wakeup_enable.py at the end of your work script just before the shutdown:

....
stringtime_SD = strftime("%d:%m:%y %H:%M:%S", localtime())
file_PJ = open('PJ_Actions.txt', 'a')
Shut_Down = ("Shutting down at: " + stringtime_SD + '\n')
file_PJ.write(Shut_Down)
file_PJ.close()

pj = pijuice.PiJuice(1, 0x14)
pj.rtcAlarm.SetWakeupEnabled(True)

os.system("sudo poweroff")`

Of course you need a import PiJuice at the top.

FyHy commented 3 years ago

Thank you for that reply Ton.

Re: The wakeup_enable.py not being used at boot. This seems to run contrary to the software section of the README, which of course I had noted and was using. But I accept your advice I must add though that the check mark on the wakeup window has always been checked when it has not woken up. Internet: No, as per my original outline of the project there is no usable Internet on site. The modem is a 2G/3G Huawei E303 dongle. This is strictly SMS and no data. That very successfully allows me to manage the Pi by sending pre-arranged commands and also to request data/have data passed to a MySQL database at "home" and thence to Highchart displays. I have been trying to keep things as simple as possible and as economical as possible on power - hence the PiJuice. I suspect from the issues I am having and the time it is taking to "try and test" I will be returning to a simple timer for booting once an hour from the main batteries. That has worked well in the past with none of the fine tuning matters that I am testing at the moment. The main batteries are very unlikely to cause a power interruption without me having days of notice. I know this sounds negative but testing is taking hours and hours of observations that I was not expecting from an "off the shelf" unit. I have reams of notes and I haven't started to comment on the issues with the low voltage "shutdown/halt" still running after 9 hours after the low charge was achieved and then when I restart it the wakeup alarm is not working until I start it myself. All in all... not quite what I expected at all. For the time being I am carrying on but not for long as I'm sure you will understand.

Do you want me to post the issues of the low charge over-running by hours everytime on this issue or should I raise another?

i will report on the results of your suggestions as to the wakeup_enable.py.

FyHy

On Thu, 14 Jan 2021 at 17:52, Ton van Overbeek notifications@github.com wrote:

Reopened #623 https://github.com/PiSupply/PiJuice/issues/623.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/PiSupply/PiJuice/issues/623#event-4207468258, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEOI42JVI6JBTOTTMDTTG2TSZ4VOLANCNFSM4V4VCCKA .

tvoverbeek commented 3 years ago

Googling a bit on Huawei E303 2G/3G modem shows that it does have data; GPRS+ on 2G and HSPA+ on 3G. Does ifconfig -a show internet interfaces other than lo0 and eth0 with assigned IP address? Regarding the other problems raise a new issue. If you can keep it simpler with your bigger batteries, just do it.

You might want to revisit the PiJuice when the 1.5 firmware is available. Lots of problems have been causes because the e.g. the wakeup on charge setting was not saved in non-volatile memory. In 1.5 there will be an option to save it in NV memory.

FyHy commented 3 years ago

Thanks for that Ton.

I will have to write a short piece coding to interrogate the if config via SMS and reply on the result!

I am having a problem with Minimum shut down %. I think that it acknowledges the "Halt" but then keeps rebooting at the 10 minute time period. Sometimes it gets as far as the GUI before shutting down but most often not. The text log just shows the "Woken up time". It keeps doing this for, in one test, 12 hours! When I restore the power supply it partly reboots to GUI before shutting down again. The "Pi light stays on. The PiJuice red light is on and the blue charging light is flashing. I am presently waiting for it to gat back to "wakeup on charge" of 80%. to be able to examine the log and see what happens to the Wakeup alarm.

I would immediately go for the simpler timed reboot but then I have this Eur60 PiJuice on hand!!

Thanks for your advice it is appreciated.

FyHy

On Thu, 14 Jan 2021 at 19:45, Ton van Overbeek notifications@github.com wrote:

Googling a bit on Huawei E303 2G/3G modem shows that it does have data; GPRS+ on 2G and HSPA+ on 3G. Does ifconfig -a show internet interfaces other than lo0 and eth0 with assigned IP address? Regarding the other problems raise a new issue. If you can keep it simpler with your bigger batteries, just do it.

You might want to revisit the PiJuice when the 1.5 firmware is available. Lots of problems have been causes because the e.g. the wakeup on charge setting was not saved in non-volatile memory. In 1.5 there will be an option to save it in NV memory.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/PiSupply/PiJuice/issues/623#issuecomment-760434283, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEOI42OMBV5C62JZFQ4KDUTSZ5CU7ANCNFSM4V4VCCKA .

FyHy commented 3 years ago

An update, Ton.

I referred to the 12 hour part booting after the minimum charge had been reached. I attach a text file produced by the Pi during that time. It shows that shortly after midnight it reached the 70% minimum charge when it failed to complete the routine and show a shut down time. From then on until 0750 it tried to start the routine without getting past the first write to the text file. Actually I wasn't able to attend to the Pi until about 0930 when it was still doing the same thing but not even reaching the GUI. I have no idea what the percentage charge was at that stage. I plugged in the power supply and it immediately tried to boot. I wasn't quick enough to to read the charge as it shut down almost immediately. I guess that the charge was in single figures. I let it recharge but it didn't wake up on reaching the 80% that I had set. By 1400 it was at full charge and I manually restarted the Pi. It shut down after the 4 minutes but didn't wake up as per the Wakeup Alarm settings. So it is acknowledging the Minimum Charge but not halting things as the System Event which is currently set at "SYS_OFF_HALT".

Surely this issue must have been raised elsewhere by someone. Would it be best to raise this as a new issue and also a second new issue about the failure to restart the routine at "Wakeup on charge". I note what you say about the new 1.5 Firmware.

I will have to take an image of the SD card as I am concerned that with all of these short cycles I will eventually corrupt the card.

...relying as always on your advice.

FyHy

Woken up at: 14:01:21 21:50:11 Mid Time at: 14:01:21 21:52:11 Shutting down at: 14:01:21 21:54:11 Woken up at: 14:01:21 22:00:12 Mid Time at: 14:01:21 22:02:12 Shutting down at: 14:01:21 22:04:12 Woken up at: 14:01:21 22:10:11 Mid Time at: 14:01:21 22:12:11 Shutting down at: 14:01:21 22:14:11 Woken up at: 14:01:21 22:20:12 Mid Time at: 14:01:21 22:22:12 Shutting down at: 14:01:21 22:24:12 Woken up at: 14:01:21 22:30:12 Mid Time at: 14:01:21 22:32:12 Shutting down at: 14:01:21 22:34:12 Woken up at: 14:01:21 22:40:11 Mid Time at: 14:01:21 22:42:11 Shutting down at: 14:01:21 22:44:11 Woken up at: 14:01:21 22:50:11 Mid Time at: 14:01:21 22:52:12 Shutting down at: 14:01:21 22:54:12 Woken up at: 14:01:21 23:00:11 Mid Time at: 14:01:21 23:02:12 Shutting down at: 14:01:21 23:04:12 Woken up at: 14:01:21 23:10:14 Mid Time at: 14:01:21 23:12:13 Shutting down at: 14:01:21 23:14:13 Woken up at: 14:01:21 23:20:14 Mid Time at: 14:01:21 23:22:13 Shutting down at: 14:01:21 23:24:13 Woken up at: 14:01:21 23:30:16 Mid Time at: 14:01:21 23:32:16 Shutting down at: 14:01:21 23:34:16 Woken up at: 14:01:21 23:40:12 Mid Time at: 14:01:21 23:42:12 Shutting down at: 14:01:21 23:44:12 Woken up at: 14:01:21 23:50:14 Mid Time at: 14:01:21 23:52:14 Shutting down at: 14:01:21 23:54:14 Woken up at: 15:01:21 00:00:15 Mid Time at: 15:01:21 00:02:15 Shutting down at: 15:01:21 00:04:15 Woken up at: 15:01:21 00:10:12 Mid Time at: 15:01:21 00:12:12 Woken up at: 15:01:21 00:20:12 Woken up at: 15:01:21 00:30:14 Woken up at: 15:01:21 00:40:12 Woken up at: 15:01:21 00:50:12 Woken up at: 15:01:21 01:00:13 Woken up at: 15:01:21 01:10:12 Woken up at: 15:01:21 01:20:12 Woken up at: 15:01:21 01:30:12 Woken up at: 15:01:21 01:40:13 Woken up at: 15:01:21 01:50:14 Woken up at: 15:01:21 02:00:12 Woken up at: 15:01:21 02:10:12 Woken up at: 15:01:21 02:20:12 Woken up at: 15:01:21 02:30:15 Woken up at: 15:01:21 02:40:14 Woken up at: 15:01:21 02:50:15 Woken up at: 15:01:21 03:00:11 Woken up at: 15:01:21 03:10:14 Woken up at: 15:01:21 03:20:12 Woken up at: 15:01:21 03:30:14 Woken up at: 15:01:21 03:40:12 Woken up at: 15:01:21 03:50:14 Woken up at: 15:01:21 04:00:14 Woken up at: 15:01:21 04:10:15 Woken up at: 15:01:21 04:20:15 Woken up at: 15:01:21 04:30:15 Woken up at: 15:01:21 04:40:14 Woken up at: 15:01:21 04:50:12 Woken up at: 15:01:21 05:00:12 Woken up at: 15:01:21 05:10:12 Woken up at: 15:01:21 05:20:12 Woken up at: 15:01:21 05:30:13 Woken up at: 15:01:21 05:40:11 Woken up at: 15:01:21 05:50:15 Woken up at: 15:01:21 06:00:14 Woken up at: 15:01:21 06:10:14 Woken up at: 15:01:21 06:20:13 Woken up at: 15:01:21 06:30:14 Woken up at: 15:01:21 06:40:13 Woken up at: 15:01:21 06:50:13 Woken up at: 15:01:21 07:00:12 Woken up at: 15:01:21 07:10:11 Woken up at: 15:01:21 07:20:14 Woken up at: 15:01:21 07:30:12 Woken up at: 15:01:21 07:40:11 Woken up at: 15:01:21 07:50:12

tvoverbeek commented 3 years ago

When the PiJuice shuts down because of low charge, the PiJuice RTC keeps on running. That is why it tries to reboot every 10 minutes. For the 'low charge' action I would write a user function which disables the RTC wakeup and then shuts down. Something like this:

#!/usr/bin/python3

from pijuice import PiJuice
import os

pj=PiJuice(1, 0x14)
pj.rtcAlarm.SetWakeupEnabled(False)
os.system("sudo poweroff")

This assumes you have enabled the 'Software Halt Power Off' on the System Task menu.

At the next reboot (due to charge level triggering wakeup on charge) your cron @reboot job will enable the RTC wakeup again.

FyHy commented 3 years ago

Thanks for that Ton.

My next task is to investigate why the PiJuice isn't starting the test routine at "Wakeup on charge". Well it may do but nothing is logged and it doesn't subsequently wake up every 10 minutes until I manually "Set Alarm".

I do hope the place in Holland from where this PiJuice was bought doesn't ask me for a "Rating". I suspect it's not going to be that great at the moment!! But at least it keeps me occupied during "Lockdown" in UK.

Thanks as always for your advice - without which...

FyHy

On Fri, 15 Jan 2021 at 15:34, Ton van Overbeek notifications@github.com wrote:

When the PiJuice shuts down because of low charge, the PiJuice RTC keeps on running. That is why it tries to reboot every 10 minutes. For the 'low charge' action I would write a user function which disables the RTC wakeup and then shuts down. Something like this:

!/usr/bin/python3

from pijuice import PiJuice import os

pj=PiJuice(1, 0x14) pj.rtcAlarm.SetWakeupEnabled(False) os.system("sudo poweroff")

This assumes you have enabled the 'Software Halt Power Off' on the System Task menu.

At the next reboot (due to charge level triggering wakeup on charge) your cron @reboot https://github.com/reboot job will enable the RTC wakeup again.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/PiSupply/PiJuice/issues/623#issuecomment-761011473, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEOI42OWCZLYQ5GVCZ65VWTS2BN75ANCNFSM4V4VCCKA .

tvoverbeek commented 3 years ago

A big problem in the current 1.4 and earlier firmwares is that the internal wakeup-on-charge in the firmware is cleared as soon as the RPi is woken up. You have to resend it before the shutdown. When you are using on of the SYS_HALT functions on the 'low charge' event the pijuice service (pijuice_sys.py) does this for you. If you use your own scriot you have to do this in the script. \ This was missing in my sample script above (https://github.com/PiSupply/PiJuice/issues/623#issuecomment-761011473). Sorry about this.

Here an updated example for a 'low charge' script:

#!/usr/bin/python3

from pijuice import PiJuice
import os

pj=PiJuice(1, 0x14)
pj.rtcAlarm.SetWakeupEnabled(False)
pj.power.SetWakeUpOnCharge(70)  # specify percentage level
os.system("sudo poweroff")

In the upcoming 1.5 firmware the wakeup-on-charge setting can be optionally stored in the MCUs non-volatile memory. This will avoid this problem.

FyHy commented 3 years ago

Thanks for that Ton. I am starting to get very confused! (Not difficult!) In System Events I have tried all three of the "SYS_FUNC_HALT", SYS_FUNC_HALT_POW_OFF, and SYS_FUNC_SYS_OFF_HALT. Unless I am missing the point of these settings, none of these have any effect on stopping the operation of the Pi nor the PiJuice. Unless power is restored in the short term the constant part rebooting will drain the battery to the point where the RTC will not hold it's value and will not restore it to the Pi at "Wakeup on charge". It may also screw up the SD Card. Sorry - that should be "corrupt the SD Card!" We seem to be having to set things twice. In actual fact at the moment and notwithstanding that issue, I can't actually get the PijUice to wake up the Pi at all on any charge previously set and "applied". It just doesn't boot up at ,say, 80% or whatever I have set (and "applied"). I am having to wait until it is "fully" charged and then manually start the Pi through the button on the PiJuice. It then runs the four minute routine. Even though we now have a pj.rtcAlarm.SetWakeupEnabled(True) in the routine, that is not having an effect in restarting the routine at the next time period. The check mark in the "Wakeup enabled" is always present and was before we added the two lines to re-enable things. The only way I can get it to wake up automatically is to click on "Set Alarm". I think that I am still "fighting" the two original issues of #635. I will try the low charge script you suggest and run the test again.

FyHy commented 3 years ago

Thanks for your help again Ton but I have given up on the PiJuice. Nothing we are doing seems to alter the fact that a) the pi keeps trying to reboot after " low charge power off" and b) will not automatically restart the routine on achieving "wake up on charge." Yesterday, I set up the "low charge" script and unplugged the power. It was set to "low charge" at 70% and to wake up on charge at 80%. It got down to 30% without even breaking stride. It ran the routine faultlessly all the way! Previously it had at least only partly rebooted after passing the "low charge". I plugged the power back in and again it charged all the way to 98% without breaking stride - i.e. passing 80% without waking up. I manually started things at 98% and it ran the 4 minute routine before powering off, i.e. the wakeup alarm did not function at all - again. Actually I don't think that it ever has restarted the automatic process after recharging. I just think that I am flogging a dead horse to use a graphical English expression. I am just not certain how I am going to tell my wife who chased around Europe to get this PiJuice for me after the English stockists had run out before Christmas. My impression at this stage is that things simply do not work "as they say on the box" and so should not be marketed as such without sorting things out or at least pointing out the shortcomings. I am disappointed that PiSupply have not contributed this issue #623 FyHy

tvoverbeek commented 3 years ago

i Have been testing your scenario on my PiJuice/RPI4 combo and for me it works fine.

low battery is set at 70%
wakeup-on-charge is set to 80%
rtc wakeup to every 4 minutes.
cron @reboot job runs for about 1 minute and then shuts down.

When running on battery > 70% it nicely runs every 4 minutes. When the charge drops below 70% Pi stays off Pi does not wake up every 4 minutes any more. After 20 minutes I applied power to the PiJuice. Pijuice started charging but Pi remained off. Pi booted when charge reached 80% After this the 4 minutes interval resumed.

WIll add some more logging and post log files and the scripts used (hopefully) tomorrow.

FyHy commented 3 years ago

Thanks for that Ton. Assuming there are no relevant differences between the Pi4 and the 3A+, then the only way forward I can see is to restart the whole process with a fresh os and a fresh PiJuice installation. But I have had to put it to one side as I have other matters to which to attend. It has taken a huge number of hours to reach where we are and I strongly maintain that there is either something wrong with the PiJuice or there are radical problems with the READme. It would appear that even though there are windows in which settings can be applied, they have to be supplemented by coding elsewhere to ensure that the original settings are working. You have kindly supplied me with extra lines of code to insert in various places but as far as I can see they are complimenting what the original setting should already be doing and so I stand by my review of the PiJuice. If you want to use it as a simple ups, it's great, but if you want to do something more complex it has issues which need extra bolts and braces not mentioned in the READme. I will try to find some time as soon as possible to test what I suggest and let you know the outcome. In the meantime matters horological are pressing. Thanks for your efforts on my behalf. Geoffrey

tvoverbeek commented 3 years ago

As promised here a working example. Relevant PiJuice settings in the following screenshots:

Above screenshot taken after the rest run. Note the 4 minute cycle is still active (Last: entry).

Note: the wakeup on charge setting is overridden by the lowcharge.py script.

The work script is executed by a cron job at boot triggered by the RTC wakeup every 4 minutes.. Crontab file:

@reboot sudo -u pi /home/pi/testscript.py

testscript.py:

#!/usr/bin/python3

from time import localtime, strftime, sleep
import pijuice
import os
import sys

while not os.path.exists('/dev/i2c-1'):
    time.sleep(0.1)

os.system("sudo hwclock -s")

pj = pijuice.PiJuice(1, 0x14)

chargelevel = pj.status.GetChargeLevel()['data']
stringtime_WU = strftime("%d-%m-%y %H:%M:%S", localtime())
with open('PJ_Actions.txt', 'a') as f:
    f.write('Woken up at:      ' + stringtime_WU + '\n')
    f.write('    Charge level: ' + str(chargelevel) + '\n')

sleep(30)

stringtime_Mid = strftime("%d-%m-%y %H:%M:%S", localtime())
with open('PJ_Actions.txt', 'a') as f:
    f.write('Mid Time at:      ' + stringtime_Mid+ '\n')

sleep(30)

stringtime_SD = strftime("%d-%m-%y %H:%M:%S", localtime())
with open('PJ_Actions.txt', 'a') as f:
    f.write('Shutting down at: ' + stringtime_SD + '\n\n')

# Ensure RTC wakeup is enabled in case it got reset (e.g. by timesyncd)
pj.rtcAlarm.SetWakeupEnabled(True)

os.system('sudo poweroff')

When the charge drops below 70% the lowcharge.py script is ececuted (See settings above). lowcharge.py:

#!/usr/bin/python3

from time import localtime, strftime
from pijuice import PiJuice
import os

WAKEUP_ON_CHARGE_LEVEL = 80

pj=PiJuice(1,0x14)

Charge_level = pj.status.GetChargeLevel()['data']
Time_LC = strftime("%d-%m-%y %H:%M:%S", localtime())
with open('/home/pi/Lowcharge.txt','a') as f:
    f.write('Charge Level = ' + str(Charge_level) + '\n')
    f.write('Low charge shutdown at: ' + Time_LC + '\n')

# Disable RTC wakeup until charge is above wakeup-on-charge level
# RTC wakeup is enabled again at the end of the cron @reboot job
pj.rtcAlarm.SetWakeupEnabled(False)
pj.power.SetWakeUpOnCharge(WAKEUP_ON_CHARGE_LEVEL)

os.system("sudo poweroff")

Here are the resulting log files: PJ_Actions.txt:

Woken up at:      18-01-21 18:17:25    <--- Manual start
    Charge level: 82
Mid Time at:      18-01-21 18:17:54
Shutting down at: 18-01-21 18:18:24

Woken up at:      18-01-21 18:20:19    <--- first wakeup on the 4 minute cycle
    Charge level: 81
Mid Time at:      18-01-21 18:20:48
Shutting down at: 18-01-21 18:21:18

Woken up at:      18-01-21 18:24:19
    Charge level: 80
Mid Time at:      18-01-21 18:24:48
Shutting down at: 18-01-21 18:25:18

Woken up at:      18-01-21 18:28:19
    Charge level: 79
Mid Time at:      18-01-21 18:28:48
Shutting down at: 18-01-21 18:29:18

Woken up at:      18-01-21 18:32:19
    Charge level: 77
Mid Time at:      18-01-21 18:32:48
Shutting down at: 18-01-21 18:33:18

Woken up at:      18-01-21 18:36:19
    Charge level: 76
Mid Time at:      18-01-21 18:36:48
Shutting down at: 18-01-21 18:37:18

Woken up at:      18-01-21 18:40:19
    Charge level: 75
Mid Time at:      18-01-21 18:40:48
Shutting down at: 18-01-21 18:41:18

Woken up at:      18-01-21 18:44:19
    Charge level: 74
Mid Time at:      18-01-21 18:44:48
Shutting down at: 18-01-21 18:45:18

Woken up at:      18-01-21 18:48:19
    Charge level: 72
Mid Time at:      18-01-21 18:48:48
Shutting down at: 18-01-21 18:49:18

Woken up at:      18-01-21 18:52:19
    Charge level: 71
Mid Time at:      18-01-21 18:52:48
Shutting down at: 18-01-21 18:53:18

Woken up at:      18-01-21 18:56:19
    Charge level: 69                <--- Low Charge Shutdown
                                         Started charging at 19:21
Woken up at:      18-01-21 19:48:22 <--- Restart when charge at 80%
    Charge level: 80
Mid Time at:      18-01-21 19:48:51
Shutting down at: 18-01-21 19:49:21

Woken up at:      18-01-21 19:52:20
    Charge level: 82
Mid Time at:      18-01-21 19:52:49
Shutting down at: 18-01-21 19:53:19

Woken up at:      18-01-21 19:56:20
    Charge level: 84
Mid Time at:      18-01-21 19:56:49
Shutting down at: 18-01-21 19:57:19

Woken up at:      18-01-21 20:00:20
    Charge level: 86
Mid Time at:      18-01-21 20:00:49
Shutting down at: 18-01-21 20:01:19

Woken up at:      18-01-21 20:04:20
    Charge level: 88
Mid Time at:      18-01-21 20:04:49
Shutting down at: 18-01-21 20:05:19

Woken up at:      18-01-21 20:08:20
    Charge level: 89
Mid Time at:      18-01-21 20:08:49
Shutting down at: 18-01-21 20:09:19

Woken up at:      18-01-21 20:12:19
    Charge level: 90
Mid Time at:      18-01-21 20:12:48
Shutting down at: 18-01-21 20:13:18

Woken up at:      18-01-21 20:16:19
    Charge level: 92
Mid Time at:      18-01-21 20:16:48
Shutting down at: 18-01-21 20:17:18

Woken up at:      18-01-21 20:20:20
    Charge level: 93
Mid Time at:      18-01-21 20:20:49
Shutting down at: 18-01-21 20:21:19

Lowcharge.txt:

Charge Level = 69
Low charge shutdown at: 18-01-21 18:56:36

Closing the issue now.

FyHy commented 3 years ago

Thanks for that Ton.

When time allows I will use a fresh "Stretch" and PiJuice installation and see if that makes a difference. I see little difference between what you have used and what I have been struggling with but I will try again and let you know. Geoffrey

On Mon, 18 Jan 2021 at 20:04, Ton van Overbeek notifications@github.com wrote:

As promised here a working example. Relevant PiJuice settings in the following screenshots: [image: Screenshot 2021-01-18 at 20 40 09] https://user-images.githubusercontent.com/1197294/104957231-09f33180-59ce-11eb-81a2-96905321ebb7.png Above screenshot taken after the rest run. Note the 4 minute cycle is still active (Last: entry). [image: Screenshot 2021-01-18 at 20 40 52] https://user-images.githubusercontent.com/1197294/104957244-11b2d600-59ce-11eb-8d8c-6354175d4df3.png Note: the wakeup on charge setting is overridden by the lowcharge.py script. [image: Screenshot 2021-01-18 at 20 41 25] https://user-images.githubusercontent.com/1197294/104957257-18d9e400-59ce-11eb-9310-137d301ee285.png [image: Screenshot 2021-01-18 at 20 42 09] https://user-images.githubusercontent.com/1197294/104957277-20998880-59ce-11eb-9d97-098b9ec70cd2.png

The work script is executed by a cron job at boot triggered by the RTC wakeup every 4 minutes.. Crontab file:

@reboot sudo -u pi /home/pi/testscript.py

testscript.py:

!/usr/bin/python3

from time import localtime, strftime, sleep import pijuice import os import sys

while not os.path.exists('/dev/i2c-1'): time.sleep(0.1)

os.system("sudo hwclock -s")

pj = pijuice.PiJuice(1, 0x14)

chargelevel = pj.status.GetChargeLevel()['data'] stringtime_WU = strftime("%d-%m-%y %H:%M:%S", localtime()) with open('PJ_Actions.txt', 'a') as f: f.write('Woken up at: ' + stringtime_WU + '\n') f.write(' Charge level: ' + str(chargelevel) + '\n')

sleep(30)

stringtime_Mid = strftime("%d-%m-%y %H:%M:%S", localtime()) with open('PJ_Actions.txt', 'a') as f: f.write('Mid Time at: ' + stringtime_Mid+ '\n')

sleep(30)

stringtime_SD = strftime("%d-%m-%y %H:%M:%S", localtime()) with open('PJ_Actions.txt', 'a') as f: f.write('Shutting down at: ' + stringtime_SD + '\n\n')

Ensure RTC wakeup is enabled in case it got reset (e.g. by timesyncd)

pj.rtcAlarm.SetWakeupEnabled(True)

os.system('sudo poweroff')

When the charge drops below 70% the lowcharge.py script is ececuted (See settings above). lowcharge.py:

!/usr/bin/python3

from time import localtime, strftime from pijuice import PiJuice import os

WAKEUP_ON_CHARGE_LEVEL = 80

pj=PiJuice(1,0x14)

Charge_level = pj.status.GetChargeLevel()['data'] Time_LC = strftime("%d-%m-%y %H:%M:%S", localtime()) with open('/home/pi/Lowcharge.txt','a') as f: f.write('Charge Level = ' + str(Charge_level) + '\n') f.write('Low charge shutdown at: ' + Time_LC + '\n')

Disable RTC wakeup until charge is above wakeup-on-charge level

RTC wakeup is enabled again at the end of the cron @reboot job

pj.rtcAlarm.SetWakeupEnabled(False) pj.power.SetWakeUpOnCharge(WAKEUP_ON_CHARGE_LEVEL)

os.system("sudo poweroff")

Here are the resulting log files: PJ_Actions.txt:

Woken up at: 18-01-21 18:17:25 <--- Manual start Charge level: 82 Mid Time at: 18-01-21 18:17:54 Shutting down at: 18-01-21 18:18:24

Woken up at: 18-01-21 18:20:19 <--- first wakeup on the 4 minute cycle Charge level: 81 Mid Time at: 18-01-21 18:20:48 Shutting down at: 18-01-21 18:21:18

Woken up at: 18-01-21 18:24:19 Charge level: 80 Mid Time at: 18-01-21 18:24:48 Shutting down at: 18-01-21 18:25:18

Woken up at: 18-01-21 18:28:19 Charge level: 79 Mid Time at: 18-01-21 18:28:48 Shutting down at: 18-01-21 18:29:18

Woken up at: 18-01-21 18:32:19 Charge level: 77 Mid Time at: 18-01-21 18:32:48 Shutting down at: 18-01-21 18:33:18

Woken up at: 18-01-21 18:36:19 Charge level: 76 Mid Time at: 18-01-21 18:36:48 Shutting down at: 18-01-21 18:37:18

Woken up at: 18-01-21 18:40:19 Charge level: 75 Mid Time at: 18-01-21 18:40:48 Shutting down at: 18-01-21 18:41:18

Woken up at: 18-01-21 18:44:19 Charge level: 74 Mid Time at: 18-01-21 18:44:48 Shutting down at: 18-01-21 18:45:18

Woken up at: 18-01-21 18:48:19 Charge level: 72 Mid Time at: 18-01-21 18:48:48 Shutting down at: 18-01-21 18:49:18

Woken up at: 18-01-21 18:52:19 Charge level: 71 Mid Time at: 18-01-21 18:52:48 Shutting down at: 18-01-21 18:53:18

Woken up at: 18-01-21 18:56:19 Charge level: 69 <--- Low Charge Shutdown Started charging at 19:21 Woken up at: 18-01-21 19:48:22 <--- Restart when charge at 80% Charge level: 80 Mid Time at: 18-01-21 19:48:51 Shutting down at: 18-01-21 19:49:21

Woken up at: 18-01-21 19:52:20 Charge level: 82 Mid Time at: 18-01-21 19:52:49 Shutting down at: 18-01-21 19:53:19

Woken up at: 18-01-21 19:56:20 Charge level: 84 Mid Time at: 18-01-21 19:56:49 Shutting down at: 18-01-21 19:57:19

Woken up at: 18-01-21 20:00:20 Charge level: 86 Mid Time at: 18-01-21 20:00:49 Shutting down at: 18-01-21 20:01:19

Woken up at: 18-01-21 20:04:20 Charge level: 88 Mid Time at: 18-01-21 20:04:49 Shutting down at: 18-01-21 20:05:19

Woken up at: 18-01-21 20:08:20 Charge level: 89 Mid Time at: 18-01-21 20:08:49 Shutting down at: 18-01-21 20:09:19

Woken up at: 18-01-21 20:12:19 Charge level: 90 Mid Time at: 18-01-21 20:12:48 Shutting down at: 18-01-21 20:13:18

Woken up at: 18-01-21 20:16:19 Charge level: 92 Mid Time at: 18-01-21 20:16:48 Shutting down at: 18-01-21 20:17:18

Woken up at: 18-01-21 20:20:20 Charge level: 93 Mid Time at: 18-01-21 20:20:49 Shutting down at: 18-01-21 20:21:19

Lowcharge.txt:

Charge Level = 69 Low charge shutdown at: 18-01-21 18:56:36

Closing the issue now.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/PiSupply/PiJuice/issues/623#issuecomment-762447536, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEOI42NFDI2WRPB7BJJ6CRDS2SH4NANCNFSM4V4VCCKA .

FyHy commented 3 years ago

Hello again Ton, I've run short of clock parts so ! have returned to the PiJuice. I used a fresh installation of Stretch in the Pi3A+ which is being used to test the PiJuice. I then carried out a default reset on the PiJuice and then I set up all of the extra coding that you used.

Putting it bluntly I have had no success. The process skates passed the low charge setting as before and when I manage to turn it around (unfortunately I can't stay watching it all the time) and restore the power it just runs right up to 97/98% without breaking a stride. The first test I ran was without the internet as that is all I have on site at the moment. The RTC survived. The second test was with the Internet connected but that got to 2% before I could restore the power. That seemed to have not kept the RTC running as after that test I found the "dev/rtc is not available" and i2cdetect -y 1 shows 68 not UU. The next run with the Internet was all over the place but with the same effect of not stopping after low charge and not waking up at the "wake up on charge" setting.

So I am no further forward.

By the way how do I get the "68" back to be "UU". I'm sure I had to do this when the PiJuice arrived but nothing I try now seems to work.

Has anyone at PiSupply actually run a 3A+ on this sort of process? I can't see why there should be a difference but neither can I see why, if it works with you on a "4" it should not work with me on a "3A+"

Geoffrey.

tvoverbeek commented 3 years ago

I do all my testing using Buster not Stretch. Any specific reason you are still on Stretch? I have one 3A+, but it is tied up in an other project (feeding flightradar24).

FyHy commented 3 years ago

OK I've loaded with Buster. But I still have 68 instead of "UU". Geoffrey

On Wed, 20 Jan 2021 at 21:37, Ton van Overbeek notifications@github.com wrote:

I do all my testing using Buster not Stretch. Any specific reason you are still on Stretch? I have one 3A+, but it is tied up in an other project (feeding flightradar24).

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/PiSupply/PiJuice/issues/623#issuecomment-763964547, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEOI42KRANCVONA565B5OM3S25EIJANCNFSM4V4VCCKA .

FyHy commented 3 years ago

I'm having difficulty with the RTC which hasn't behaved since it ran down to 2% after not powering off on low charge last time. i2cdetect -y 1 gives me "68" but if I change the /boot/config.txt to ds1307, I get the "UU" back but on reverting to ds1339 I get the "68" again. I recall having had this the first time I powered the PiJuice up 4 weeks ago. I can't recall how I got the "UU" back again. Any advice? Geoffrey

On Wed, 20 Jan 2021 at 23:04, Geoffrey Hyde Fynn < geoffrey.hyde.fynn@gmail.com> wrote:

OK I've loaded with Buster. But I still have 68 instead of "UU". Geoffrey

On Wed, 20 Jan 2021 at 21:37, Ton van Overbeek notifications@github.com wrote:

I do all my testing using Buster not Stretch. Any specific reason you are still on Stretch? I have one 3A+, but it is tied up in an other project (feeding flightradar24).

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/PiSupply/PiJuice/issues/623#issuecomment-763964547, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEOI42KRANCVONA565B5OM3S25EIJANCNFSM4V4VCCKA .

tvoverbeek commented 3 years ago

Assuming we are talking about the PiJuice HAT, not the PiJuice Zero.

With the HAT if you leave the ID EEPROM address at 0x50 (default value) then you do not need any rtc lines in /boot/config.txt. Raspberry PiOS reads the devicetree fragment for the RTC from the EEPROM. Only problem could be if the PiJuice MCU is completely off (battery completely empty) and you apply power via the RPi the RTC will probably be initialized too late by the PiJuice firmware for the OS to be recognized. Alternatively, if you set the ID_EEPROM address to 0x52, the EEPROM devicetree fragment will not be read and you need to specify the appropriate line (ds1339 or ds1307) in /boot/config.txt. Here the same problem exists when the MCU is off as in the first alternative.

FyHy commented 3 years ago

Thanks for that Ton.

I was under the impression that I should be getting "UU" in 68 spot. If I try to: "sudo hwclock -r" I get "hwclock: Cannot access the hardware clock via any known route."

But if that's fine I will fire off the test routine and hope we are OK now.

Thanks

Geoffrey

On Thu, 21 Jan 2021 at 15:03, Ton van Overbeek notifications@github.com wrote:

Assuming we are talking about the PiJuice HAT, not the PiJuice Zero.

With the HAT if you leave the ID EEPROM address at 0x50 (default value) then you do not need any rtc lines in /boot/config.txt. Raspberry PiOS reads the devicetree fragment for the RTC from the EEPROM. Only problem could be if the PiJuice MCU is completely off (battery completely empty) and you apply power via the RPi the RTC will probably be initialized too late by the PiJuice firmware for the OS to be recognized. Alternatively, if you set the ID_EEPROM address to 0x52, the EEPROM devicetree fragment will not be read and you need to specify the appropriate line (ds1339 or ds1307) in /boot/config.txt. Here the same problem exists when the MCU is off as in the first alternative.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/PiSupply/PiJuice/issues/623#issuecomment-764704710, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEOI42MCTO2FKWMTTHRH3L3S3A64LANCNFSM4V4VCCKA .

FyHy commented 3 years ago

Ton, I attach a log of events and would be interested in your view. This was run on BUSTER (with updates and upgrades) and the Pi3A+. Whilst I was using the GUI to set the parameters, I checked everything on the CLI as well. They matched yours exactly other than I was using 5 minute intervals ( I was coming and going and needed to know immediately when the next boot would be). It took ages to sort out the issues with the RTC and I had to review all of your previous to do that! But eventually I followed the one about the issues with BUSTER and got it working or so I had hoped. At least it responded to all of the commands at that stage. Is/was there an issue with Buster? The test referred to below was run without Internet as that is my goal. "sudo hwclock -s" was working on a command line so I assumed it would synchronise things when the routine was operating. I ran the routine with Low Charge at 20% and Wake up at 30%. I will leave you to review the log but it means nothing to me!! It just seems very erratic. I used both of your advised codings. with amended data as necessary. All other GUi settings were "applied" and the lowcharge.py was made executable etc. etc. This was not my first test with Buster. I won't distract you with the others but they equally didn't work as yours - with or without Internet. Geoffrey

On Thu, 21 Jan 2021 at 15:49, Geoffrey Hyde Fynn < geoffrey.hyde.fynn@gmail.com> wrote:

Thanks for that Ton.

I was under the impression that I should be getting "UU" in 68 spot. If I try to: "sudo hwclock -r" I get "hwclock: Cannot access the hardware clock via any known route."

But if that's fine I will fire off the test routine and hope we are OK now.

Thanks

Geoffrey

On Thu, 21 Jan 2021 at 15:03, Ton van Overbeek notifications@github.com wrote:

Assuming we are talking about the PiJuice HAT, not the PiJuice Zero.

With the HAT if you leave the ID EEPROM address at 0x50 (default value) then you do not need any rtc lines in /boot/config.txt. Raspberry PiOS reads the devicetree fragment for the RTC from the EEPROM. Only problem could be if the PiJuice MCU is completely off (battery completely empty) and you apply power via the RPi the RTC will probably be initialized too late by the PiJuice firmware for the OS to be recognized. Alternatively, if you set the ID_EEPROM address to 0x52, the EEPROM devicetree fragment will not be read and you need to specify the appropriate line (ds1339 or ds1307) in /boot/config.txt. Here the same problem exists when the MCU is off as in the first alternative.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/PiSupply/PiJuice/issues/623#issuecomment-764704710, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEOI42MCTO2FKWMTTHRH3L3S3A64LANCNFSM4V4VCCKA .

Woken up at: 22-01-21 13:51:14 <--Power off (every 5 mins-20% Lo & 30% Hi) Charge level: 27 Mid Time at: 22-01-21 13:52:14 Shutting down at: 22-01-21 13:53:14

Woken up at: 22-01-21 13:55:45 Charge level: 25 Mid Time at: 22-01-21 13:56:45 Shutting down at: 22-01-21 13:57:45

Woken up at: 22-01-21 14:11:27 <--Has the RTC not been synchronised? Charge level: 18 Mid Time at: 22-01-21 14:12:38 Shutting down at: 22-01-21 14:13:38

Woken up at: 22-01-21 14:14:45 <-- Ditto Charge level: 19 <-- But this is below the 20% Mid Time at: 22-01-21 14:15:44 Shutting down at: 22-01-21 14:16:44

Woken up at: 22-01-21 14:24:16 <-- Ditto Charge level: 24 <-- But this is above the 20% Mid Time at: 22-01-21 14:25:16 Shutting down at: 22-01-21 14:26:16

Woken up at: 22-01-21 14:30:17 <-- Ditto Charge level: 28 <-- Ditto Mid Time at: 22-01-21 14:31:16 Shutting down at: 22-01-21 14:32:16

Woken up at: 22-01-21 14:35:17 <-- At last it has Charge level: 31 <-- This is above the Wake up on charge bit not charge applied Mid Time at: 22-01-21 14:36:16 Shutting down at: 22-01-21 14:37:16

Woken up at: 22-01-21 14:40:16 <-- And again Charge level: 33 Mid Time at: 22-01-21 14:41:16 Shutting down at: 22-01-21 14:42:16

Woken up at: 22-01-21 14:45:17 Charge level: 32 Mid Time at: 22-01-21 14:46:16 Shutting down at: 22-01-21 14:47:16

Woken up at: 22-01-21 14:50:17 Charge level: 32 Mid Time at: 22-01-21 14:51:16 Shutting down at: 22-01-21 14:52:16

Woken up at: 22-01-21 14:55:16 Charge level: 31 Mid Time at: 22-01-21 14:56:15 Shutting down at: 22-01-21 14:57:15

Woken up at: 22-01-21 15:00:17 Charge level: 31 Mid Time at: 22-01-21 15:01:16 Shutting down at: 22-01-21 15:02:16

Woken up at: 22-01-21 15:05:20 Charge level: 15 <-- A 16% drop in charge in 5 minutes Mid Time at: 22-01-21 15:06:20 Shutting down at: 22-01-21 15:07:20

Woken up at: 22-01-21 15:10:18 Charge level: 15 Mid Time at: 22-01-21 15:11:17 Shutting down at: 22-01-21 15:12:17

Woken up at: 22-01-21 15:15:20 <--RTC "off on one again." Charge level: 15 Mid Time at: 22-01-21 15:16:19 Shutting down at: 22-01-21 15:17:19

Woken up at: 22-01-21 15:20:18 <-- Ditto Charge level: 15 Mid Time at: 22-01-21 15:21:18 Shutting down at: 22-01-21 15:22:18

Woken up at: 22-01-21 15:25:17 <-- RTC settled again. Charge level: 14 Mid Time at: 22-01-21 15:26:16 Shutting down at: 22-01-21 15:27:16

Woken up at: 22-01-21 15:30:17 Charge level: 14 Mid Time at: 22-01-21 15:31:16 Shutting down at: 22-01-21 15:32:16

Woken up at: 22-01-21 15:35:18 Charge level: 14 Mid Time at: 22-01-21 15:36:18 Shutting down at: 22-01-21 15:37:18

Woken up at: 22-01-21 15:40:17 Charge level: 13 Mid Time at: 22-01-21 15:41:16 Shutting down at: 22-01-21 15:42:16

Woken up at: 22-01-21 15:45:19 Charge level: 13 Mid Time at: 22-01-21 15:46:18 Shutting down at: 22-01-21 15:47:18

Woken up at: 22-01-21 15:50:18 Charge level: 12 Mid Time at: 22-01-21 15:51:17 Shutting down at: 22-01-21 15:52:17

Woken up at: 22-01-21 15:55:17 Charge level: 11 Mid Time at: 22-01-21 15:56:16 Shutting down at: 22-01-21 15:57:16

Woken up at: 22-01-21 16:00:17 Charge level: 11 Mid Time at: 22-01-21 16:01:16 Shutting down at: 22-01-21 16:02:16

Woken up at: 22-01-21 16:05:20 Charge level: 10 Mid Time at: 22-01-21 16:06:19 Shutting down at: 22-01-21 16:07:19

Woken up at: 22-01-21 16:10:20 Charge level: 4 Mid Time at: 22-01-21 16:11:20 Shutting down at: 22-01-21 16:12:20

Woken up at: 22-01-21 16:15:20 Charge level: 4 Mid Time at: 22-01-21 16:16:20 Shutting down at: 22-01-21 16:17:20

Woken up at: 22-01-21 16:20:19 Charge level: 4 Mid Time at: 22-01-21 16:21:18 Shutting down at: 22-01-21 16:22:18

Woken up at: 22-01-21 16:25:18 Charge level: 4 Mid Time at: 22-01-21 16:26:17 Shutting down at: 22-01-21 16:27:17

Woken up at: 22-01-21 16:30:20 Charge level: 4 Mid Time at: 22-01-21 16:31:20 Shutting down at: 22-01-21 16:32:20

Woken up at: 22-01-21 16:35:19 Charge level: 3 Woken up at: 22-01-21 16:40:19 <-- Not finishing routine Charge level: 4 Woken up at: 22-01-21 16:40:55 Charge level: 4 Mid Time at: 22-01-21 16:41:54 <-- Ditto Shutting down at: 22-01-21 16:42:54

Woken up at: 22-01-21 16:44:42 <-- I stepped in to stop the routine Charge level: 7 Mid Time at: 22-01-21 16:45:42 Shutting down at: 22-01-21 16:46:42

Woken up at: 22-01-21 16:47:33 Charge level: 9

tvoverbeek commented 3 years ago

From your log it seems the shutdown (and stopping the RTC wakeup) when the charge level goes below 20% is not working. Can you list your setup for the low charge event and the associated user function? Also log this low charge event to a different file. See lowcharge.py and the Lowcharge.txt log file in my example.

FyHy commented 3 years ago

Thanks for that.

I will get the full set up posted shortly The lowcharge.py and Lowcharge.txt is exactly as you advised and there is no log entry on the latter. On a previous test there were three consecutive log entries. They were four minutes apart and with an ascending charge level of 70 - 71 - 72 and then nothing. That tells me that the user function was working but not the Low Charge shutdown.

I have installed fresh Buster on a fresh A3+ and once I have got the regular Buster DNS problem sorted and can get it on the Internet I will find the set up on the PiJuice and post it.

But now I must do the "Housework"...

Geoffrey.

On Fri, 22 Jan 2021 at 20:10, Ton van Overbeek notifications@github.com wrote:

From your log it seems the shutdown (and stopping the RTC wakeup) when the charge level goes below 20% is not working. Can you list your setup for the low charge event and the associated user function? Also log this low charge event to a different file. See lowcharge.py and the Lowcharge.txt log file in my example.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/PiSupply/PiJuice/issues/623#issuecomment-765656357, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEOI42MLMH4W5VASDTSRL4TS3HLRTANCNFSM4V4VCCKA .

FyHy commented 3 years ago

OK. The Buster in the new 3A+ is now up and running properly. The RTC is now working and the DNS issue has been corrected.

I have copied both of your scripts to the /home/pi/ directory.

I attach screen shots of the 4 relevant screens of settings. The low charge is set at 80 and the wake up on charge is 90. The minute period is 5 minutes.

I have not as yet started things off.

On Sat, 23 Jan 2021 at 10:00, Geoffrey Hyde Fynn < geoffrey.hyde.fynn@gmail.com> wrote:

Thanks for that.

I will get the full set up posted shortly The lowcharge.py and Lowcharge.txt is exactly as you advised and there is no log entry on the latter. On a previous test there were three consecutive log entries. They were four minutes apart and with an ascending charge level of 70 - 71 - 72 and then nothing. That tells me that the user function was working but not the Low Charge shutdown.

I have installed fresh Buster on a fresh A3+ and once I have got the regular Buster DNS problem sorted and can get it on the Internet I will find the set up on the PiJuice and post it.

But now I must do the "Housework"...

Geoffrey.

On Fri, 22 Jan 2021 at 20:10, Ton van Overbeek notifications@github.com wrote:

From your log it seems the shutdown (and stopping the RTC wakeup) when the charge level goes below 20% is not working. Can you list your setup for the low charge event and the associated user function? Also log this low charge event to a different file. See lowcharge.py and the Lowcharge.txt log file in my example.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/PiSupply/PiJuice/issues/623#issuecomment-765656357, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEOI42MLMH4W5VASDTSRL4TS3HLRTANCNFSM4V4VCCKA .

FyHy commented 3 years ago

Hello again Ton.

I ran the routine overnight with the settings as in the previous message. The log was as PJ_Actions (1).txt below

There are some questions but basically the routine did not even pause in either direction. It's as if the PiJuice is not recognising some things from the System Task setup.

I ran another routine to record the charge every couple of minutes without anything else but it sailed straight past the low charge setting but all of the charge readings were regular, i.e. no big drops.

Is it possible to set the low charge level from within a script the same way that you can set the wake up on charge level? I had thought to try that. I can't actually see a way in the 'readme' to check what is the low charge level setting - let alone set one.

Other than that I can only surmise that there is something not compatible with PiJuice and what I am using. i.e. A3+ with Stretch or A3+ with Buster or there is something not quite right with my PiJuice.

Maybe I look at eliminating why it is not recognising the Low Charge setting before moving on.

Thanks Ton.

Geoffrey

On Sat, 23 Jan 2021 at 15:26, Geoffrey Hyde Fynn < geoffrey.hyde.fynn@gmail.com> wrote:

OK. The Buster in the new 3A+ is now up and running properly. The RTC is now working and the DNS issue has been corrected.

I have copied both of your scripts to the /home/pi/ directory.

I attach screen shots of the 4 relevant screens of settings. The low charge is set at 80 and the wake up on charge is 90. The minute period is 5 minutes.

I have not as yet started things off.

On Sat, 23 Jan 2021 at 10:00, Geoffrey Hyde Fynn < geoffrey.hyde.fynn@gmail.com> wrote:

Thanks for that.

I will get the full set up posted shortly The lowcharge.py and Lowcharge.txt is exactly as you advised and there is no log entry on the latter. On a previous test there were three consecutive log entries. They were four minutes apart and with an ascending charge level of 70 - 71 - 72 and then nothing. That tells me that the user function was working but not the Low Charge shutdown.

I have installed fresh Buster on a fresh A3+ and once I have got the regular Buster DNS problem sorted and can get it on the Internet I will find the set up on the PiJuice and post it.

But now I must do the "Housework"...

Geoffrey.

On Fri, 22 Jan 2021 at 20:10, Ton van Overbeek notifications@github.com wrote:

From your log it seems the shutdown (and stopping the RTC wakeup) when the charge level goes below 20% is not working. Can you list your setup for the low charge event and the associated user function? Also log this low charge event to a different file. See lowcharge.py and the Lowcharge.txt log file in my example.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/PiSupply/PiJuice/issues/623#issuecomment-765656357, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEOI42MLMH4W5VASDTSRL4TS3HLRTANCNFSM4V4VCCKA .

Woken up at: 23-01-21 21:10:21 Charge level: 85 Mid Time at: 23-01-21 21:11:21 Shutting down at: 23-01-21 21:12:21

Woken up at: 23-01-21 21:15:22 Charge level: 84 Mid Time at: 23-01-21 21:16:22 Shutting down at: 23-01-21 21:17:22

Woken up at: 23-01-21 21:20:21 Charge level: 83 Mid Time at: 23-01-21 21:21:21 Shutting down at: 23-01-21 21:22:21

Woken up at: 23-01-21 21:25:21 Charge level: 71 <-- 12% drop in charge Mid Time at: 23-01-21 21:26:21 Shutting down at: 23-01-21 21:27:21

Woken up at: 23-01-21 21:30:20 Charge level: 70 <-- Low charge level Mid Time at: 23-01-21 21:31:20 Shutting down at: 23-01-21 21:32:20

Woken up at: 23-01-21 21:35:22 Charge level: 70 Mid Time at: 23-01-21 21:36:22 Shutting down at: 23-01-21 21:37:22

Woken up at: 23-01-21 21:40:19 Charge level: 69 Mid Time at: 23-01-21 21:41:19 Shutting down at: 23-01-21 21:42:19

Woken up at: 23-01-21 21:45:22 Charge level: 69 Mid Time at: 23-01-21 21:46:22 Shutting down at: 23-01-21 21:47:22

Woken up at: 23-01-21 21:50:19 Charge level: 68 Mid Time at: 23-01-21 21:51:19 Shutting down at: 23-01-21 21:52:19

Woken up at: 23-01-21 21:55:20 Charge level: 50 <-- 18% drop in charge Mid Time at: 23-01-21 21:56:20 Shutting down at: 23-01-21 21:57:20 <-- Restored power Woken up at: 24-01-21 07:17:11 <-- Manual reboot Charge level: 97 Mid Time at: 24-01-21 07:18:11 Shutting down at: 24-01-21 07:19:11

tvoverbeek commented 3 years ago

Ir seems something is preventing the shutdown at low charge. Either your hardware setup or some combination of permissions and pijuice service (system task) not working/ being enabled. Nothing more I can do from here.

FyHy commented 3 years ago

OK. Thanks for that Ton.

When you say "or some combination of permissions and pijuice service (system task) not working/ being enabled." are you suggesting that there may be something wrong with the PiJuice I have or has there been an issue with the installation of the PiJuice on three different platforms one of which is brand new.

The latest efforts have been with a "latest Buster on a NEW A3+ platform" I have not altered any set up with regard to the Pi. That seems to eliminate part of your conjecture leaving the "and pijuice service (system task) not working/ being enabled." as being an issue. What suggestions do you have to be able to determine the issue? If none do I just "bin" the Pijuice as a useless Christmas present?

Is it known not to work with a 3A+? If that is not the case why does a fresh install on a new platform not work? If there is nothing more that you can do to help, to whom at PiSuppy should I turn for help? I am loath to write off €60+ as a loss without trying to make up for the hours and hours spent of your time and mine.

I look forward to your further advice on how to pursue this.

Geoffrey.

On Mon, 25 Jan 2021 at 15:51, Ton van Overbeek notifications@github.com wrote:

Ir seems something is preventing the shutdown at low charge. Either your hardware setup or some combination of permissions and pijuice service (system task) not working/ being enabled. Nothing more I can do from here.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/PiSupply/PiJuice/issues/623#issuecomment-766912063, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEOI42L4N7L3ES3ZQJJTBXDS3WHQLANCNFSM4V4VCCKA .

FyHy commented 3 years ago

Hello Ton,

I have approached PiSupply with a view to the person who gave me the item, returning the PiJuice either, to them directly, or to their agent in Holland from where it was purchased. She will no doubt incur customs charges now if they insist on the latter.

I have given up!! If the amount of time (both yours and mine) spent trying to get the thing to work on a brand new platform with the latest OS is an indication of something that is perfectly OK then I am a "Dutch Uncle" (another English saying).

If PiJuice choose to replace it then I will happily start again but if not I will resort to the "simple method" I mentioned before.

Thanks for all of your contributions.

Geoffrey. (FyHy)

On Mon, 25 Jan 2021 at 19:51, Geoffrey Hyde Fynn < geoffrey.hyde.fynn@gmail.com> wrote:

OK. Thanks for that Ton.

When you say "or some combination of permissions and pijuice service (system task) not working/ being enabled." are you suggesting that there may be something wrong with the PiJuice I have or has there been an issue with the installation of the PiJuice on three different platforms one of which is brand new.

The latest efforts have been with a "latest Buster on a NEW A3+ platform" I have not altered any set up with regard to the Pi. That seems to eliminate part of your conjecture leaving the "and pijuice service (system task) not working/ being enabled." as being an issue. What suggestions do you have to be able to determine the issue? If none do I just "bin" the Pijuice as a useless Christmas present?

Is it known not to work with a 3A+? If that is not the case why does a fresh install on a new platform not work? If there is nothing more that you can do to help, to whom at PiSuppy should I turn for help? I am loath to write off €60+ as a loss without trying to make up for the hours and hours spent of your time and mine.

I look forward to your further advice on how to pursue this.

Geoffrey.

On Mon, 25 Jan 2021 at 15:51, Ton van Overbeek notifications@github.com wrote:

Ir seems something is preventing the shutdown at low charge. Either your hardware setup or some combination of permissions and pijuice service (system task) not working/ being enabled. Nothing more I can do from here.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/PiSupply/PiJuice/issues/623#issuecomment-766912063, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEOI42L4N7L3ES3ZQJJTBXDS3WHQLANCNFSM4V4VCCKA .

ryanteck commented 3 years ago

@tvoverbeek Do we have an ETA on when V1.5 will come out?

FyHy commented 3 years ago

Hello again, I have restarted to try to solve the issues in which the PiJuice does not shut down at the set low charge and DID NOT wake-up on the charge threshold. This latter part seems to have been addressed in the updated firmware 1.5 but I have still been having issues with the PiJuice not acknowledging the low charge level set in either the GUI or the CLI. I am running a PiB4 with a fresh installation of both Buster and PiJuice. PiSupply kindly offered to replace my previous PiJuice BUT...

I have been using the following code (testscript.py) to run the test: testscript.py has the correct shebang. The system task box is "checked" in the GUI System Task settings.

`#!/usr/bin/python3

from time import localtime, strftime, sleep import pijuice import os import sys

while not os.path.exists('/dev/i2c-1'): time.sleep(0.1)

os.system("sudo hwclock -s")

pj = pijuice.PiJuice(1, 0x14)

chargelevel = pj.status.GetChargeLevel()['data'] stringtime_WU = strftime("%d-%m-%y %H:%M:%S", localtime()) with open('PJ_Actions.txt', 'a') as f: f.write('Woken up at: ' + stringtime_WU + '\n') f.write(' Charge level: ' + str(chargelevel) + '\n')

sleep(30)

stringtime_Mid = strftime("%d-%m-%y %H:%M:%S", localtime()) with open('PJ_Actions.txt', 'a') as f: f.write('Mid Time at: ' + stringtime_Mid+ '\n')

sleep(30)

stringtime_SD = strftime("%d-%m-%y %H:%M:%S", localtime()) with open('PJ_Actions.txt', 'a') as f: f.write('Shutting down at: ' + stringtime_SD + '\n\n')

pj.rtcAlarm.SetWakeupEnabled(True)

os.system('sudo poweroff') `

...and at the low charge charge threshold, lowcharge.py runs to set the wake-up level: lowcharge.py is executable and pi is in the pijuice usergroup. lowcharge.py has the correct shebang line.

`#!/usr/bin/python3

from time import localtime, strftime from pijuice import PiJuice import os

WAKEUP_ON_CHARGE_LEVEL = 80

pj=PiJuice(1,0x14)

Charge_level = pj.status.GetChargeLevel()['data'] Time_LC = strftime("%d-%m-%y %H:%M:%S", localtime()) with open('/home/pi/Lowcharge.txt','a') as f: f.write('Charge Level = ' + str(Charge_level) + '\n') f.write('Low charge shutdown at: ' + Time_LC + '\n')

pj.rtcAlarm.SetWakeupEnabled(False) pj.power.SetWakeUpOnCharge(WAKEUP_ON_CHARGE_LEVEL)

os.system("sudo poweroff") `

This code produces the following output text file (PJ_Actions_A.txt) with the low charge set using the GUI at 70% and the wake-up charge at 80%.

`Woken up at: 29-05-21 20:50:21 <<< Start testscript.py on reboot. No power to PiJuice. Charge level: 99 Mid Time at: 29-05-21 20:50:50 Shutting down at: 29-05-21 20:51:20

Woken up at: 29-05-21 20:55:21 Charge level: 98 Mid Time at: 29-05-21 20:55:50 Shutting down at: 29-05-21 20:56:20

Woken up at: 29-05-21 21:00:21 Charge level: 96 Mid Time at: 29-05-21 21:00:50 Shutting down at: 29-05-21 21:01:20

Woken up at: 29-05-21 21:05:20 Charge level: 93 Mid Time at: 29-05-21 21:05:49 Shutting down at: 29-05-21 21:06:19

Woken up at: 29-05-21 21:10:21 Charge level: 90 Mid Time at: 29-05-21 21:10:51 Shutting down at: 29-05-21 21:11:21

Woken up at: 29-05-21 21:15:21 Charge level: 86 Mid Time at: 29-05-21 21:15:50 Shutting down at: 29-05-21 21:16:20

Woken up at: 29-05-21 21:20:21 Charge level: 82 Mid Time at: 29-05-21 21:20:50 Shutting down at: 29-05-21 21:21:20

Woken up at: 29-05-21 21:25:21 Charge level: 78 Mid Time at: 29-05-21 21:25:50 Shutting down at: 29-05-21 21:26:20

Woken up at: 29-05-21 21:30:21 Charge level: 73 Mid Time at: 29-05-21 21:30:50 Shutting down at: 29-05-21 21:31:20

Woken up at: 29-05-21 21:35:21 Charge level: 69 Mid Time at: 29-05-21 21:35:50 Shutting down at: 29-05-21 21:36:20 <<< "Sails" passed the Low Charge shutdown level of 70%. Woken up at: 29-05-21 21:40:21 Charge level: 63 Mid Time at: 29-05-21 21:40:50 Shutting down at: 29-05-21 21:41:20

Woken up at: 29-05-21 21:45:21 Charge level: 58 Mid Time at: 29-05-21 21:45:51 Shutting down at: 29-05-21 21:46:21

Woken up at: 29-05-21 21:50:21 Charge level: 53 Mid Time at: 29-05-21 21:50:50 Shutting down at: 29-05-21 21:51:20

Woken up at: 29-05-21 21:55:21 Charge level: 47 Mid Time at: 29-05-21 21:55:50 Shutting down at: 29-05-21 21:56:20

Woken up at: 29-05-21 22:00:24 Charge level: 41 Mid Time at: 29-05-21 22:00:53 Shutting down at: 29-05-21 22:01:23 <<< testscript.py stopped manually. `

As can be seen the PiJuice "sails" passed the 70% low charge setting without missing a beat.

From the above entries, you can see that I have tried to use the PiJuice settings to sort this problem for some months and have even introduced another piece of hardware to run the actual project but it has limitations.

I have therefore now SOLVED the problem but sidestepping the PiJuice settings and have simply added some code to testscript.py to make use of the charge levels being read and once the low level is achieved, lowcharge.py is called and the routine is stopped after setting the wake-up level:

This is testscript_lp.py:

`#!/usr/bin/python3

from time import localtime, strftime, sleep import logging import pijuice import os import sys

logging.basicConfig(format='%(levelname)s: %(messages)s', level=logging.DEBUG)

lowcharge = 70

while not os.path.exists('/dev/i2c-1'): time.sleep(0.1)

os.system("sudo hwclock -s")

pj = pijuice.PiJuice(1, 0x14)

chargelevel = pj.status.GetChargeLevel()['data'] stringtime_WU = strftime("%d-%m-%y %H:%M:%S", localtime())

with open('PJ_Actions.txt', 'a') as f: f.write('Woken up at: ' + stringtime_WU + '\n') f.write(' Charge level: ' + str(chargelevel) + '\n') if chargelevel <= lowcharge: os.system('sudo python3 /home/pi/lowcharge.py')

sleep(30)

stringtime_Mid = strftime("%d-%m-%y %H:%M:%S", localtime()) with open('PJ_Actions.txt', 'a') as f: f.write('Mid Time at: ' + stringtime_Mid+ '\n')

sleep(30)

stringtime_SD = strftime("%d-%m-%y %H:%M:%S", localtime()) with open('PJ_Actions.txt', 'a') as f: f.write('Shutting down at: ' + stringtime_SD + '\n\n')

pj.rtcAlarm.SetWakeupEnabled(True)

os.system('sudo poweroff') `

The text output, PJ_Actions_B show that the routine stops at 66%:

`Woken up at: 30-05-21 18:31:44 <<< Started testscript_lp.py on reboot. Charge level: 99 Mid Time at: 30-05-21 18:32:14 Shutting down at: 30-05-21 18:32:44

Woken up at: 30-05-21 18:44:16 Charge level: 99 Mid Time at: 30-05-21 18:44:45 Shutting down at: 30-05-21 18:45:15

Woken up at: 30-05-21 18:50:21 <<< Disconnected power to PiJuice. Charge level: 99 Mid Time at: 30-05-21 18:50:50 Shutting down at: 30-05-21 18:51:20

Woken up at: 30-05-21 18:55:21 Charge level: 98 Mid Time at: 30-05-21 18:55:50 Shutting down at: 30-05-21 18:56:20

Woken up at: 30-05-21 19:00:22 Charge level: 95 Mid Time at: 30-05-21 19:00:51 Shutting down at: 30-05-21 19:01:21

Woken up at: 30-05-21 19:05:21 Charge level: 92 Mid Time at: 30-05-21 19:05:50 Shutting down at: 30-05-21 19:06:20

Woken up at: 30-05-21 19:10:21 Charge level: 89 Mid Time at: 30-05-21 19:10:50 Shutting down at: 30-05-21 19:11:20

Woken up at: 30-05-21 19:15:22 Charge level: 85 Mid Time at: 30-05-21 19:15:51 Shutting down at: 30-05-21 19:16:21

Woken up at: 30-05-21 19:20:21 Charge level: 80 Mid Time at: 30-05-21 19:20:50 Shutting down at: 30-05-21 19:21:20

Woken up at: 30-05-21 19:25:21 Charge level: 76 Mid Time at: 30-05-21 19:25:51 Shutting down at: 30-05-21 19:26:21

Woken up at: 30-05-21 19:30:21 Charge level: 71 Mid Time at: 30-05-21 19:30:50 Shutting down at: 30-05-21 19:31:20

Woken up at: 30-05-21 19:35:23 Charge level: 66 <<< See Lowcharge.txt

Woken up at: 30-05-21 20:12:41 <<< Woke up at charge level 80% Charge level: 80 Mid Time at: 30-05-21 20:13:10 Shutting down at: 30-05-21 20:13:40

Woken up at: 30-05-21 20:15:21 Charge level: 86 Mid Time at: 30-05-21 20:15:50 Shutting down at: 30-05-21 20:16:20

Woken up at: 30-05-21 20:20:21 Charge level: 94 Mid Time at: 30-05-21 20:20:50 Shutting down at: 30-05-21 20:21:20

Woken up at: 30-05-21 20:25:22 Charge level: 99 Mid Time at: 30-05-21 20:25:51 Shutting down at: 30-05-21 20:26:21

Woken up at: 30-05-21 20:30:21 Charge level: 99 Mid Time at: 30-05-21 20:30:50 Shutting down at: 30-05-21 20:31:20 <<< Stopped testscript_lp.py manually `

...and then the lowcharge.py is called and Lowcharge.txt simply records the Low Charge shutdown date and time:

Charge Level = 66 Low charge shutdown at: 30-05-21 19:35:23

If someone else solves his issue by using the GUI or CLI settings I would be interested to hear but in the meantime the project will be using this method as it WORKS!! Maybe whatever was sorted in Firmware 1.5 to get the problems with the Wake-up corrected could be applied to the low charge shutdown.

In the meantime thanks for all of your help and tolerance.

Depending on any response(s) I will close the issue as SOLVED at least from my point of view in couple of days.

Geoffrey