On May 11, 2017, at 1:51 PM, Jesse Molina <[email protected]> wrote:
I suspect this is a driver problem because while NUT claims the battery isn't
plugged in, it's giving me battery runtime/charge info. Both can't be valid at
the same time.
I am at a remote location from the computer and UPS, so I can't physically go
over and check. I asked a remote person to physically look at it and they said
there were no unusual blinking lights or anything alarming.
I send this message previously with debugging output inline, but apparently
this mailing list only allows messages lesser than 40Kb in size, and the
message was rejected by whoever the admin is.
I'll admit that I hit the reject button. Nothing personal - let me explain.
The NUT mailing lists get a fair amount of spam that we manually filter out
before it hits the archives. If you have ever had to sift through a bunch of
spam messages, you'll know that it is not exactly a relaxing task. Large
messages also end up in that holding area.
I have not personally tried to adjust the 40KB limit, but other seemingly
simple tasks like adjusting the HTML on the list info page have resulted in
tickets that languish for months or years on the Alioth issue tracker. Sure, we
could try to find another place to host the email lists, and deal with the
troubles of moving, but there is a simpler solution.
The recommended maximum debug level for initial bug reports is "-DDD" or "-DD", depending
on where you look in the documentation. The usbhid-ups driver is fairly verbose, so "-DD" is
usually good enough for a first pass.
I usually ask users to compress logs with gzip, and send as an attachment. This lets me
do a "zgrep" on previous logs to find similarities. If logs come in as Zip
files, or inline, it certainly isn't the end of the world, but it lengthens the search.
</soapbox>
This seems to be the source of the "no battery" alarm:
0.571436 hid_lookup_path: 00840004 -> UPS
0.571438 hid_lookup_path: 00840024 -> PowerSummary
0.571440 hid_lookup_path: 00840002 -> PresentStatus
0.571443 hid_lookup_path: 008500d1 -> BatteryPresent
0.571446 Path: UPS.PowerSummary.PresentStatus.BatteryPresent, Type:
Input, ReportID: 0x16, Offset: 3, Size: 1, Value: 0
0.571449 Report[buf]: (5 bytes) => 16 04 00 00 00
0.571451 PhyMax = 0, PhyMin = 0, LogMax = 1, LogMin = 0
0.571453 Unit = 00000000, UnitExp = 0
0.571455 Exponent = 0
0.571457 hid_lookup_path: 00840004 -> UPS
0.571459 hid_lookup_path: 00840024 -> PowerSummary
0.571461 hid_lookup_path: 00840002 -> PresentStatus
0.571463 hid_lookup_path: 008500d1 -> BatteryPresent
0.571466 Path: UPS.PowerSummary.PresentStatus.BatteryPresent, Type:
Feature, ReportID: 0x16, Offset: 3, Size: 1, Value: 0
0.571468 Report[buf]: (5 bytes) => 16 04 00 00 00
0.571471 PhyMax = 0, PhyMin = 0, LogMax = 1, LogMin = 0
0.571473 Unit = 00000000, UnitExp = 0
0.571475 Exponent = 0
Both the Input and Feature seem to agree that the battery is not present. (0x04 -> 0000 0100
corresponds to "Offset: 2" and the "AC Present" bit; all others are zero.
user@host>apcaccess
APC : 001,036,0870
DATE : 2017-05-08 23:44:14 -0700
HOSTNAME : myhost
VERSION : 3.14.14 (31 May 2016) debian
UPSNAME : myups
CABLE : USB Cable
DRIVER : USB UPS Driver
UPSMODE : Stand Alone
STARTTIME: 2017-05-08 23:32:58 -0700
MODEL : Back-UPS XS 1500G
STATUS : ONLINE NOBATT
LINEV : 120.0 Volts
LOADPCT : 11.0 Percent
BCHARGE : 100.0 Percent
TIMELEFT : 55.8 Minutes
MBATTCHG : 15 Percent
MINTIMEL : 3 Minutes
MAXTIME : 0 Seconds
SENSE : Medium
LOTRANS : 88.0 Volts
HITRANS : 139.0 Volts
ALARMDEL : No alarm
BATTV : 27.3 Volts
LASTXFER : No transfers since turnon
NUMXFERS : 0
TONBATT : 0 Seconds
CUMONBATT: 0 Seconds
XOFFBATT : N/A
SELFTEST : NO
STATFLAG : 0x01000008
SERIALNO : 3B1632X25318
BATTDATE : 2016-08-13
NOMINV : 120 Volts
NOMBATTV : 24.0 Volts
NOMPOWER : 865 Watts
FIRMWARE : 866.L8 .D USB FW:L8
END APC : 2017-05-08 23:44:15 -0700
The apcupsd team is generally quicker to respond to quirks in the APC UPS protocols, and
if their latest development version of the code still says NOBATT, it would seem to me
that nobody has found a better place to look for the "battery present" status.
We try not to create complicated rules to override some values based on others - it tends
to be difficult to debug, and often users are not interested in regression-testing
updated drivers against other models ("if it ain't broke, don't fix it",
perhaps).
I would first try to schedule an extended selftest (not sure what is available on this
model; "upscmd -l" will show possibilities) during a maintenance window to see
if the alarm goes away.
