search

geeekpi / upsplus

UPS Plus is a new generation of UPS power management module. It is an improved version of the original UPS prototype. It has been fixed the bug that UPS could not charge and automatically power off during work time. It can not only perform good battery power management, but also provide stable voltage output and RTC functions. At the same time,it support for FCP, AFC, SFCP fast charge protocol, support BC1.2 charging protocol, support battery terminal current/voltage monitoring and support two-way monitoring of charge and discharge. It can provide programmable PVD function. Power Voltage Detector (PVD) can be used to detect if batteries voltage is below or above configured voltage. Once this function has been enabled, it will monitoring your batteries voltage, and you can control whether or not shut down Raspberry Pi via simple bash script or python script. This function will protect your batteries from damage caused by excessive discharge. It can provide Adjustable data sampling Rate. This function allows you to adjust the data sampling rate so that you can get more detailed battery information and also it will consume some power. The data sampling information can communicate with the upper computer device through the I2C protocol. UPS Plus supports the OTA firmware upgrade function. Once there is a new firmware update, it is very convenient for you to upgrade firmware for UPS Plus. The firmware upgrade can be completed only by connecting to the Internet,and execute a python script. Support battery temperature monitoring and power-down memory function. UPS Plus can be set to automatically start the Raspberry Pi after the external power comes on. The programmable shutdown and forced restart function will provide you with a remote power-off restart management method. That means you don’t need to go Unplug the power cable or press the power button to cut off the power again. You can set the program to disconnect the power supply after a few seconds after the Raspberry Pi is shut down properly. And you can also reconnect the power supply after a forced power failure to achieve a remote power-off and restart operation. Once it was setting up, you don't need to press power button to boot up your device which is very suitable for smart home application scenarios.
https://wiki.52pi.com/index.php?title=UPS_Plus_SKU:_EP-0136
MIT License
73 stars 25 forks source link

firmware version 8: shutdown countdown does not work any more #44

Closed frtz13 closed 2 years ago

frtz13 commented 3 years ago

using firmware v. 8 after starting a firmware shutdown i2cset -y 1 0x17 24 30 the UPSPlus goes into a buggy state:

nickfox-taterli commented 3 years ago

after checking, the problem exists, in the test we emptied the configuration area, so no problem was found, the actual reason is to find the information in the original configuration and the latest configuration there is a program can not deal with the part, the BKPT interruption occurred, now fixed, thank you for your attention to the latest firmware

ArjenR49 commented 3 years ago

upgraded to v.8 here, too, this afternoon. Went fine, as always.

I have two OS drives for the Pi/UPS: (1) one SSD with motioneye and no Home Assistant (2) the other SSD without motioneye, but an HA installation, which has worked nicely since this morning... (thanks to the help of Hellresistor)

With SSD (2) i2c is totally broken: timeouts all the time, the journalctl -f window is filling up with i2c errors. With SSD (1) i2c works normally as far as I have seen now.

frtz13 commented 3 years ago

@nickfox-taterli : we have to wait for a new firmware release ? something else: charging time continues to accumulate even with no charger connected.

@ArjenR49 : i2c works ok here, as long as I do not start a shutdown countdown.

ArjenR49 commented 3 years ago

"something else: charging time continues to accumulate even with no charger connected." I can confirm that.

Observed that accumulated running time, charging time and current up time aren't updated all at the same time.

ArjenR49 commented 3 years ago

After removing charger and batteries frtz13's script runs ok, and also my reporting program that reads all of the registers and prints info to the screen cause no i2c errors. However a program that sets both sampling interval and protection voltage level makes the UPS f/w(?) go crazy and apparently all i2c operations cause an error filling the journalctl screen with red text...

Disconnecting the charger and taking the batteries out solves this, and things look fine and dandy. However, it is to be expected that when the ups control script - whichever it may be - decides the Pi needs to be shut down and in preparation for this writes to an i2c register, things go badly wrong again. For now while waiting for a better f/w version it is probably better to not test any real UPS functionality.

nickfox-taterli commented 3 years ago

After removing charger and batteries frtz13's script runs ok, and also my reporting program that reads all of the registers and prints info to the screen cause no i2c errors. However a program that sets both sampling interval and protection voltage level makes the UPS f/w(?) go crazy and apparently all i2c operations cause an error filling the journalctl screen with red text...

Disconnecting the charger and taking the batteries out solves this, and things look fine and dandy. However, it is to be expected that when the ups control script - whichever it may be - decides the Pi needs to be shut down and in preparation for this writes to an i2c register, things go badly wrong again. For now while waiting for a better f/w version it is probably better to not test any real UPS functionality.

We have improved the internal CI test according to @frtz13 , I2C read/write will not be a problem in our test, regardless of whether the original configuration exists or not, in addition, part of the configuration will exist in the EEPROM, the firmware functionality is constantly optimized, we are also trying a downgradeable method.

ArjenR49 commented 3 years ago

CI as in confidence interval?

There are many things great in @frtz13's approach, but the most essential is using exception handling on all i2c operations, IMO. Not in all circumstances will there be i2c timing errors from the UPS control scripts, it seems, so you may not see them during testing in a bare Pi installation. My first installation SSD with MotionEye running, however, had regular I2C timeout errors, which were eventually well handled in @frtz13's script.

The purpose of my second test installation SSD was to get Home Assistant and MQTT working on the Pi/UPS combo. That was a success, in the end, and on that installation I have had no i2c timeouts at all. Until f/w 8 came along a few hours later ...

All in all I am convinced it would be wise to prepare for i2c timeouts in GeekPi's scripts, too, and add exception handling to all i2c and INA operations. When not handled the script crashes and the results thereof are unexpected as I experienced when I first started testing this UPS.

frtz13 commented 3 years ago

@nickfox-taterli with firmware version 8 I left the UPS running since yesterday. i2c traffic is still normal (I did NOT start a shutdown sequence). however, after about 6 hours of operation battery temperature, charging port status and running times are no longer updated by the firmware, like previously reported for firmware version 7 in issue #28 .

nickfox-taterli commented 3 years ago

@nickfox-taterli with firmware version 8 I left the UPS running since yesterday. i2c traffic is still normal (I did NOT start a shutdown sequence). however, after about 6 hours of operation battery temperature, charging port status and running times are no longer updated by the firmware, like previously reported for firmware version 7 in issue #28 .

We are still investigating this, as you can see from this page, sometimes he freezes, but not always, and more problematically, sometimes it freezes after a week, and some people have been running for 50 days with no problems at all, and we initially intended to track the whole process of the program, but in fact there is no useful information at all when it freezes. If this issue is resolved, it will be released in a firmware update.

The second trouble is, in order to solve this problem, we will continue to test each product for seven days after mass, no problems were found in the test, but there are still a small number of customers, such as you have encountered this problem, we guess can be solved by modifying the firmware, and are working on this matter.

Finally, if you need accurate battery and Raspberry Pi voltage and current information, you can get it by sampling the INA219.

ArjenR49 commented 3 years ago

I haven't seen anything like @frtz13 described. Not on f/w 8 and not before either. Maybe just lucky, then. Just the charging time is updated on f/w 8 even when it is not connected, as noted before.

Mine has now been running for over 730 minutes on @frtz13's control script after the last reset. There have been regular i2c errors on this SSD installation as before, but they are all handled by the script as I can see from the journalctl -f output. (This installation runs MotionEye with a camera and motion detection) I just ran my report script twice in a row. The first time the UPS was apparently sampling battery characteristics and therefore discharging the battery. The charger supplied around 5 V according to that report. On the second run the charger was back at around 9V as can be seen in the next report:

pi@RPI-HUB:~ $ python3 $HOME/UPS+MQTT/UPS_report_for_UPSPlus_mqtt.py
-------             01-06-2021 11:15:18              -------

*** Data from INA219 at 0x40:
Raspberry Pi supply voltage:                         4.900 V
Raspberry Pi current consumption:                    1.120 A
Raspberry Pi power consumption:                      5.500 W

*** Data from INA219 at 0x45:
Battery voltage:                                     4.200 V
Battery current (charging):                          0.273 A
Power supplied to the batteries:                     1.150 W

*** Remainder of report is based on data collected
*** by the UPS f/w and read from memory at 0x17

UPS board MCU voltage:                               3.280 V
Voltage at Pi GPIO header pins:                      4.910 V
USB type C port input voltage:                       9.140 V
Micro USB port input voltage:                        0.000 V

Battery temperature (estimate):                         48°C
Automatic detection of battery type                    yes
Batteries fully charged at (learned value):          4.320 V
Current voltage at battery terminals:                4.240 V
Batteries fully discharged at (partially learned):   3.200 V
Battery discharge limit for UPS is set at:           3.200 V
Remaining battery capacity:                             98 %
Battery sampling ('blue LEDs off') interval:             2 min

Current power state: normal

External power is connected to the USB type C input.

Should the external power be interrupted long enough        
to cause the battery voltage to drop below 3.400 V          
the Pi will be halted & the UPS will power it down.

Current values of the UPS power control registers:
0x18=0 / 0x19=0 / 0x1A=0
Explanation:
0x18 - Power off timer (no restart)   - not set.
0x19 - Automatic restart upon return of external power: no
0x1A - Power off timer (with restart) - not set.

Accumulated running time:                              736 min
Accumulated charging time:                             736 min
Current up time:                                       736 min
F/W version: 8
Serial Number:  ....

pi@RPI-HUB:~ $

The report script uses my modified (higher) values for the INA shunts to get readings more in the line of a power balance (as per measured USB input voltage and current).

ArjenR49 commented 3 years ago

HOWEVER, .... changing a parameter by writing to the correspondent registers does make the UPS f/w go totally berserk. It causes a constantly growing list of i2c errors in the journalctl terminal (control script is running).

After you then shutdown the PI via the GUI, the UPS will not switch off power when the button is pressed like it normally should do. The only way to get out of this lockup is removing external power and the batteries...

How is work proceeding on a f/w that at least doesn't go berserk when writing to an I2C register? Something like 'back to version 7' would be nice.

nickfox-taterli commented 3 years ago

The version upgrade does not change the I2C communication, because the I2C communication is implemented through Bootloader, if the I2C communication fails, then the OTA will also fail.

ArjenR49 commented 3 years ago

I have succesfully updated to version 8 when it came out. There was never a failure on OTA update that I could see.

Since then I have been having the problems during normal use of the UPS which I described above, and they have to do with i2c communications on write as I have seen from messages in the the journalctl -f log.

yoyojacky commented 3 years ago

After removing charger and batteries frtz13's script runs ok, and also my reporting program that reads all of the registers and prints info to the screen cause no i2c errors. However a program that sets both sampling interval and protection voltage level makes the UPS f/w(?) go crazy and apparently all i2c operations cause an error filling the journalctl screen with red text...

Disconnecting the charger and taking the batteries out solves this, and things look fine and dandy. However, it is to be expected that when the ups control script - whichever it may be - decides the Pi needs to be shut down and in preparation for this writes to an i2c register, things go badly wrong again. For now while waiting for a better f/w version it is probably better to not test any real UPS functionality.

I also tried to use UPS PLUS to connect to 4B and run it for more than 6 weeks. It has been connected to an external power supply, and 4B provides a mkdocs server website for my colleagues to use every day, and I did not encounter the problems you encountered. Have you tried to refresh the system and try again? In addition, if you read the I2C device information too frequently, it will also cause some problems. Linux is not a real-time system, and the time slice switch polling may cause some problems due to the delay. This has nothing to do with the firmware.

yoyojacky commented 3 years ago

ring normal use of the UPS which I described above, and they have to do with i2c communications on write as I have seen from messages in the the journalctl -f log.

Why write information to the register address frequently? You only need to read it, monitor it instead of frequently modifying its status. If you need to count down the power off, you only need to send a message to the register of your device.