I have a new-ish APC Back-UPS XS 1500G connected via USB. It's giving me a "ups.alarm: No battery installed!" error. I also installed and configured apcupsd to give that a try and it's giving me the same error. 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. user at host>upsc UPS1 at localhost Init SSL without certificate database battery.charge: 100 battery.charge.low: 10 battery.charge.warning: 50 battery.date: 2001/09/25 battery.mfr.date: 2016/08/13 battery.runtime: 3345 battery.runtime.low: 120 battery.type: PbAc battery.voltage: 27.3 battery.voltage.nominal: 24.0 device.mfr: American Power Conversion device.model: Back-UPS XS 1500G device.serial: 3B1632X25318 device.type: ups driver.name: usbhid-ups driver.parameter.pollfreq: 5 driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.parameter.synchronous: no driver.version: 2.7.4 driver.version.data: APC HID 0.96 driver.version.internal: 0.41 input.sensitivity: medium input.transfer.high: 139 input.transfer.low: 88 input.voltage: 119.0 input.voltage.nominal: 120 ups.alarm: No battery installed! ups.beeper.status: disabled ups.delay.shutdown: 20 ups.firmware: 866.L8 .D ups.firmware.aux: L8 ups.load: 11 ups.mfr: American Power Conversion ups.mfr.date: 2016/08/13 ups.model: Back-UPS XS 1500G ups.productid: 0002 ups.realpower.nominal: 865 ups.serial: 3B1632X25318 ups.status: ALARM OL ups.test.result: No test initiated ups.timer.reboot: 0 ups.timer.shutdown: -1 ups.vendorid: 051d
On 11/05/17 19.51, Jesse Molina wrote:> > I have a new-ish APC Back-UPS XS 1500G connected via USB. It's giving me a > "ups.alarm: No battery installed!" error. I also installed and configured > apcupsd to give that a try and it's giving me the same error.I recently also had an strange error with a similar APC ups, but my battery was not 16 years old :-O> battery.date: 2001/09/25 > battery.mfr.date: 2016/08/13strange difference in battery dates.> battery.runtime: 3345I wonder if that is days?> ups.alarm: No battery installed!I got the same error message. Since my UPS was a decade old I ended up just buying a new. I choose Eaton because NUT+Eaton seems to be so well supported. When my UPS lost power, it would shut off instantly. JonB
Charles Lepple
2017-May-12 13:54 UTC
[Nut-upsuser] APC Back-UPS XS 1500G says "No battery"
On May 11, 2017, at 1:51 PM, Jesse Molina <jmolina at swoncology.net> 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 = 0Both 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 at 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 -0700The 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.
Thanks for all of the info and advice. I have someone scheduled to go out to the site next week and we will do a test and I will report back with the findings. On 5/12/2017 6:54 AM, Charles Lepple wrote:> 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.
Testing has indicated this UPS is indeed FUBAR/broken somehow. It's not showing any errors/issues on the front-panel, but it's not holding load when the cord is yanked. Disregard this entire thread. Thanks for reading! On 5/12/2017 6:54 AM, Charles Lepple wrote:> On May 11, 2017, at 1:51 PM, Jesse Molina <jmolina at swoncology.net> 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 at 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.