Yes it could be problem with some of the cells. I consider going to the
service, but I do not have another backup UPS and the service requires
leaving the UPS for at least 3 days (I presume, so they could perform
such tests). I'll try replacing the batteries and if it doesn't help,
then I'll go to the service.
Regards,
--
Georgi
On 27.1.2020 at 10:38, nicolae788 wrote:
Hello.
I sometimes encountered batteries that were ok, but at times one of
the cells would develop a random short/open, therefore reducing the
real capacity even if voltage reading was ok. In the absence of a
battery load tester i would suggest running multiple tests with a load
(car headlight bulb or similar) on the battery outside the ups. This
is to eliminate the suspicion of a software or UPS unit fault.
Alex.
On Mon, 27 Jan 2020, 02:53 Manuel Wolfshant, <wo...@nobugconsulting.ro
<mailto:wo...@nobugconsulting.ro>> wrote:
On 1/25/20 10:53 AM, Georgi D. Sotirov wrote:
OK, so yesterday evening I done a real test cutting of the power
to the UPS. And it went good... the UPS supported my server for
28:50 minutes (i.e. the expected runtime with this load), before
forcing shutdown. The batteries could still hold as charge was 30
% with about 15 minutes run time. And the UPS did hold for
another full 10 minutes before powering off. These are the
relevant lines from /var/log/ups:
20200124 201318 32 0.0 12 [OB] NA 0.0
20200124 201323 30 0.0 13 [ALARM OB LB] NA 0.0
20200124 201328 30 0.0 13 [FSD ALARM OB LB] NA 0.0
20200124 201333 30 0.0 13 [FSD ALARM OB LB] NA 0.0
20200124 201338 30 0.0 13 [FSD ALARM OB LB] NA 0.0
20200124 201340 30 0.0 13 [FSD ALARM OB LB] NA 0.0
that looks perfectly fine
The server was shutdown properly, but for some reason it did not
power off. I saw an error from umount about busy file system, but
I'm sure this doesn't always happen.
the error is related to your linux system, not to nut
With everything powered off, I extracted the original batteries
to check them and measure the voltage. The batteries are Leoch
DJW12-9.0 with one of them at 12.57 V and the other at 12.64 V
(measured without load after the discharge).
That's... surprisingly well, assuming your multimeter indicates
correct values. I would have expected values well below 12V
And this morning there was again a short power failure (not more
than 30 minutes, because the router connected to the battery
power from the UPS did hold up). With batteries charged up to 91%
the UPS supported the server for just 07:10 minutes and forced
shutdown with 69% battery charge and over 20 minutes of run time...
20200125 021123 70 0.0 16 [OB] NA 0.0
20200125 021128 69 0.0 16 [FSD ALARM OB LB] NA 0.0
20200125 021133 69 0.0 16 [FSD ALARM OB LB] NA 0.0
20200125 021138 69 0.0 16 [FSD ALARM OB LB] NA 0.0
20200125 021143 69 0.0 16 [FSD ALARM OB LB] NA 0.0
20200125 021148 69 0.0 16 [FSD ALARM OB LB] NA 0.0
20200125 021150 69 0.0 16 [FSD ALARM OB LB] NA 0.0
So, it seems to me that my UPS forces shutdown pretty randomly.
Why the UPS is not waiting for the preset low battery charge
value of 15%? What is actually driving this FSD ALARM and LB
signal when batteries for sure could hold up more?
Can you please show us all the configuration files ? I can only
suspect that there is something wrong there because (from a
hardware point of view) the UPS behaves very very well, according
to your tests and logs.
_______________________________________________
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
<mailto:Nut-upsuser@alioth-lists.debian.net>
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
_______________________________________________
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
_______________________________________________
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
