command "upsc [ups]" returns battery.runtime -1

[ITaluone]

UPS: APC Smart-UPS C 1000VA 2U SmartConnect, USB (creation date 2019-05-21) (Rackmount)

Software: Raspbian Stretch NUT (v2.7.4-5) driver: usbhid-ups

I have another APC UPS (same as above, but creation date 2018-02-14) working perfectly.

Is there a known issue about that?

[clepple]

Have you run a self-test on this UPS since it was last plugged in?

[ITaluone]

Hi, Sorry for the delay..

Yes i have done a self-test, but nothing had changed that behavior.

Meanwhile, I've installed another two UPS with identical behavior. (All three are rack-mount, if that information is necessary).

[arnekaulfuss]

Same behaviour here with newer Smart-UPS 1500 (RM) - older device works fine on same server. Also only a few variables are supported compared to the predecessor. Input and output variables for example are missing completely.

battery.charge: 100
battery.charge.low: 10
battery.charge.warning: 50
battery.runtime: -1
battery.runtime.low: 150
battery.type: PbAc
battery.voltage: 26.4
battery.voltage.nominal: 24.0
device.mfr: American Power Conversion
device.model: Smart-UPS_1500
device.serial: AS20xxxxxxxx
device.type: ups
driver.name: usbhid-ups
driver.parameter.pollfreq: 30
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
ups.beeper.status: enabled
ups.delay.shutdown: 20
ups.firmware: UPS 03.5 / ID=1015
ups.mfr: American Power Conversion
ups.mfr.date: 2020/03/15
ups.model: Smart-UPS_1500
ups.productid: 0003
ups.serial: AS20xxxxxxxx
ups.status: OL
ups.timer.reboot: -1
ups.timer.shutdown: 65535
ups.vendorid: 051d

@ITaluone are your newer devices ones with already integrated ethernet-port (apc cloud-support)?

For me it seems they changed sth. on these newer Models. I had also problems with apcupsd and these devices.

[clepple]

@arnekaulfuss I hope you don't mind - I edited your upsc output to preserve line endings, so that it is easier to compare with other DDL entries.

@ITaluone as Arne mentioned, it may be something different in the newer devices. What does ups.firmware show for your old and new devices?

[ITaluone]

@ITaluone are your newer devices ones with already integrated ethernet-port (apc cloud-support)?

Yes, all of them supporting apc cloud.

@clepple The Firmware is: UPS 10.0 / ID=1005 (Note: the same fw for "tower" and rackmount). The fw for the newer ones: UPS 03.5 / ID=1018

[dstewen]

Same here:

pi@pi3b:~ $ upsc myups@localhost Init SSL without certificate database battery.charge: 100 battery.charge.low: 10 battery.charge.warning: 50 battery.runtime: -1 battery.runtime.low: 150 battery.type: PbAc battery.voltage: 26.2 battery.voltage.nominal: 24.0 device.mfr: American Power Conversion device.model: Smart-UPS_1500 device.serial: AS20XXXXXXXX device.type: ups driver.flag.pollonly: enabled driver.name: usbhid-ups driver.parameter.pollfreq: 30 driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.parameter.synchronous: no driver.parameter.vendorid: 051d driver.version: 2.7.4 driver.version.data: APC HID 0.96 driver.version.internal: 0.41 ups.beeper.status: enabled ups.delay.shutdown: 20 ups.firmware: UPS 03.5 / ID=1018 ups.mfr: American Power Conversion ups.mfr.date: 2020/11/11 ups.model: Smart-UPS_1500 ups.productid: 0003 ups.serial: AS20XXXXXXXX ups.status: OL ups.timer.reboot: -1 ups.timer.shutdown: 65535 ups.vendorid: 051d pi@pi3b:~ $

[arnekaulfuss]

@clepple - what kind of information would be helpful?

I'm able to do some tracing/debugging tasks or whatever, if you give me a hint to what's needed. Don't need explicit explanation - just a starting pointer as I'm not really used to nut.

[jeffgoh]

Turns out I have a few APC under my care that have this niggling bug:

# upsc apc@localhost | egrep '(runtime|firmware|model)' Init SSL without certificate database battery.runtime: 0 battery.runtime.low: 150 device.model: Smart-UPS_1500 ups.firmware: UPS 03.5 / ID=1015 ups.model: Smart-UPS_1500

# upsc apc@localhost | egrep '(runtime|firmware)' Init SSL without certificate database battery.runtime: -1 battery.runtime.low: 150 ups.firmware: UPS 03.8 / ID=1015

But on another machine that has both USB (apc2) and NMC (apc) - the first shows runtime -1 but the latter shows a reasonably legit number.

# upsc apc2@localhost | egrep '(runtime|firmware|model)' battery.runtime: -1 battery.runtime.low: -9 device.model: Smart-UPS SRT 5000 ups.firmware: UPS 04.7 / ID=1013 ups.model: Smart-UPS SRT_500

# upsc apc@localhost | egrep '(runtime|firmware|model)' Init SSL without certificate database battery.runtime: 2702.00 battery.runtime.low: 120 device.model: Smart-UPS SRT 5000 ups.firmware: UPS 04.7 (ID1013) ups.model: Smart-UPS SRT 5000

Has anyone tested the runtime on different firmware/model to narrow down what works and what doesn't ?

I would say that from my testing, UPS 03.5 and 03.8 on ID1015 as well as UPS 04.7 on ID1013 still does not work.

It's worth noting that NMC works but is an expensive solution to a simple problem.

[jimklimov]

It seems mappings used for seeing the value are wrong for these models.

Can you please check if the https://github.com/networkupstools/nut/blob/master/scripts/subdriver/gen-usbhid-subdriver.sh script would find interesting values on your device, which are absent in https://github.com/networkupstools/nut/blob/67c6cd5be78f3f0739569e45548b93b555c20be2/drivers/apc-hid.c#L322 table?

There are already 2 mappings for each of these values at least (first hit wins; maybe one serves bogus data on your box, or none is served)...

[ITaluone]

Can you please check if the https://github.com/networkupstools/nut/blob/master/scripts/subdriver/gen-usbhid-subdriver.sh script

Could you please explain how to get the "driver walk" working?

Thanks

[jimklimov]

Did you look at the script? It has short comments and refers to the more detailed document :)

[ITaluone]

Yes I do :)

But I don't see how to execute this line (from the comments):

# drivers/usbhid-ups -s ups -DD -u root -x explore -x vendorid=XXXX -x productid=XXXX -x port=auto -d1 > debuginfo 2>&1

Where does the "drivers/usbhid-ups" resides? I am sure that I am missing something :)

[jimklimov]

Did you build NUT from the sources? :)

Tech for generation of a subdriver source somehow implies building the project sometime around that ;)

Probably as a first shot, even a sufficiently recent version of packaged NUT would include a usbhid-ups driver in a location divined by packagers (e.g. /lib/nut on Debian-derived systems) and you could use that for the walk.

However since the scope of the question deals with extending an existing HID sub-driver to locate and try to make use of missing data points, rather than making a new sub-driver from scratch, at some point soon afterwards you would need those NUT sources, a diff tool to compare and edit the files (IDEs or meld are decent choices) to port new lines into existing subdriver, and a way to build it and test-run against your device.

[tfvlrue]

I noticed this same problem on a Synology device which uses an outdated version of NUT under the hood. It's connected to an APC SMT1500RM2UC, which looks like the same model mentioned above:

VendorID: 051d
ProductID: 0003
Manufacturer: American Power Conversion 
Product: Smart-UPS_1500 FW:UPS 03.5 / ID=1015

Using the built-in version, upsc reports

battery.runtime: -1

I built the latest version from source and copied it onto the Synology. It reports

battery.runtime: 0

All the other reported parameters look correct (and are identical between the old and new versions of upsc).

Looking at apc-hid.c, I see there are two paths used for battery.runtime

  { "battery.runtime", 0, 0, "UPS.Battery.RunTimeToEmpty", NULL, "%.0f", 0, NULL },
  { "battery.runtime", 0, 0, "UPS.PowerSummary.RunTimeToEmpty", NULL, "%.0f", 0, NULL },

When I ran the aforementioned scripts, it generated this line

	{ "unmapped.ups.powersummary.runtimetoempty", 0, 0, "UPS.PowerSummary.RunTimeToEmpty", NULL, "%.0f", 0, NULL },

and indeed the HID object list indicated this value is present:

Path: UPS.PowerSummary.RunTimeToEmpty, Type: Input, ReportID: 0x0d, Offset: 0, Size: 32, Value: 0
Path: UPS.PowerSummary.RunTimeToEmpty, Type: Feature, ReportID: 0x0d, Offset: 0, Size: 32, Value: 0

I'm guessing perhaps the Synology version of the driver doesn't include the "UPS.PowerSummary.RunTimeToEmpty" entry, and is relying on "UPS.Battery.RunTimeToEmpty" which doesn't exist for this model. But, even with the correct mapping, the UPS returns 0 for this value, despite being charged (battery.charge: 98). This suggests maybe a firmware bug in the UPS itself? There is an update available, so I can try to do that the next time I'm at the site.

I'll attach the generated files for posterity.

debuginfo.zip