Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

CPS: "battery.mfr.date" value is bogus #437

Closed
clepple opened this issue Jun 4, 2017 · 19 comments · Fixed by #1645
Closed

CPS: "battery.mfr.date" value is bogus #437

clepple opened this issue Jun 4, 2017 · 19 comments · Fixed by #1645
Labels
bug CyberPower (CPS) USB

Comments

@clepple
Copy link
Member

clepple commented Jun 4, 2017

For Cyber Power Systems UPSes, battery.mfr.date is pulled from UPS.PowerSummary.iOEMInformation, and that is usually either CPS or Cyber Power Systems (according to the DDL entries we currently have).

http://lists.alioth.debian.org/pipermail/nut-upsuser/2017-May/010662.html among others.
@clepple clepple added the bug label Jun 4, 2017
@alexruffell
Copy link

This bug has been open since 2017... the problem persists as my CyberPower PR1000RTXL2U also shows:

battery.mfr.date: CPS

@flashydave
Copy link
Contributor

Also the same on CP900EPFCLCD
battery.mfr.date: CPS

@Brunty
Copy link

Brunty commented Sep 1, 2022

It's the same on my BR1000ELCD

@jimklimov
Copy link
Member

jimklimov commented Sep 2, 2022 •
edited
Loading

Looking at the spec https://www.usb.org/sites/default/files/pdcv11.pdf (page 38) it seems there is a field for what NUT would know as "UPS.Battery.ManufacturerDate" (according to the few precedents in NUT sources):

4.2.6 Battery Settings
ManufacturerDate The date the pack was manufactured in a packed integer. The date is packed in the following fashion: (year – 1980)*512 + month*32 + day.

Curiously, some drivers recognize further data like UPS Manufacture date (per PowerSummary), or battery replacement date (though probably a typo in powercom-hid.c), which is not readily apparent in that spec. As well as other drivers (openups) that use UPS.PowerSummary.iOEMInformation for battery.mfr.date.

I'll post a PR to prefer mapping that value if available - hoping you would be able to build NUT from that branch to see if it really works ;)

@jimklimov jimklimov mentioned this issue Sep 2, 2022
Closed
jimklimov added a commit to jimklimov/nut that referenced this issue Sep 2, 2022
@jimklimov
drivers/cps-hid.c: prefer mapping battery.mfr.date from UPS.Battery.M…
9127e41 
…anufacturerDate if available [networkupstools#437]
@jimklimov jimklimov mentioned this issue Sep 2, 2022
Merged
@jimklimov jimklimov added the USB label Sep 5, 2022
@jimklimov
Copy link
Member

@Brunty ? @flashydave ? @alexruffell ? Can someone of you please build https://github.com/jimklimov/nut/tree/issue-437 and run ./usbhid-ups -a yourupsname -d1 (with main driver service stopped) to see if it picks up a reasonable date value?

@alexruffell
Copy link

@jimklimov unfortunately I do not know how to do that

@flashydave
Copy link
Contributor

flashydave commented Sep 5, 2022 via email

@flashydave
Copy link
Contributor

flashydave commented Sep 6, 2022 via email

@jimklimov
Copy link
Member

@alexruffell : For a quick test, without installing the custom build into your OS, it may suffice that you:

:; git clone -b issue-437 https://github.com/jimklimov/nut
:; cd nut
:; ./ci_build.sh
# ...wait some time for build/test to complete...

# Stop existing NUT driver
# Get a data dump from new driver build:
:; ./drivers/usbhid-ups -a yourupsname -d1
# ...or if it complains about access:
:; sudo ./drivers/usbhid-ups -a yourupsname -d1 -x user=root

To perform the build, you may need to install tools and/or prerequisites (notably libusb-devel) as listed in docs/config-prereqs.txt for your OS type.

@jimklimov
Copy link
Member

jimklimov commented Sep 6, 2022 •
edited
Loading

@flashydave : thanks! Can you also run the driver with debug (IIRC level 2 would suffice, -DD) to print out the data it sees in the Report Descriptor for your device?

In a different issue #1512 and short how-to in #1618 there was a troubleshooting session for another CPS issue with output.voltage (curiously yours seems to be in the okay ballpark), where the HEX printout of the USB HID Report Descriptor (debug level 3) is parsed and interpreted by tools in detail. In that discussion, the device does not report any ManufacturerDate it seems, but it also reports some non-standard values encoded like UPS.ff010004.ff010024.ff0100d0 which the driver (and external parsers) apparently do not know (yet) how to interpret. Maybe one of those hides the battery date?.. FWIW, their Manufacturer Name (and battery date per this issue) is just 1 :)

@jimklimov jimklimov mentioned this issue Sep 6, 2022
Closed
@flashydave
Copy link
Contributor

flashydave commented Sep 6, 2022 via email

@alexruffell
Copy link

alexruffell commented Sep 6, 2022 •
edited
Loading

@jimklimov Thank you for the instructions. I cloned my VM as I would not know how to revert back, and followed your instructions. I got to the point of getting the dump but it complains about there not being and file called usbhid-hid

./drivers/usbhid-ups -a cyberpower_rack_ups -d1
-bash: ./drivers/usbhid-ups: No such file or directory
alex@ubuntu-server-nut:~/nut$ ls ./drivers/usb*
./drivers/usb-common.c  ./drivers/usb-common.h  ./drivers/usbhid-ups.c  ./drivers/usbhid-ups.h
alex@ubuntu-server-nut:~/nut$

Before doing the above I got this output, which I wanted to compare to the output of the patched driver so I'll add it here for reference later:

alex@ubuntu-server-nut:~/nut$ upsc cyberpower_rack_ups@localhost
Init SSL without certificate database
battery.charge: 100
battery.charge.low: 0
battery.charge.warning: 35
battery.mfr.date: CPS
battery.runtime: 2052
battery.runtime.low: 300
battery.type: PbAcid
battery.voltage: 3.5
battery.voltage.nominal: 22
device.mfr: CPS
device.model: PR1000RTXL2U
device.serial: xxxxxxxxxxxx
device.type: ups
driver.name: usbhid-ups
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 1
driver.parameter.port: auto
driver.parameter.productid: 0601
driver.parameter.synchronous: no
driver.parameter.vendorid: 0764
driver.version: 2.7.4
driver.version.data: CyberPower HID 0.4
driver.version.internal: 0.41
input.voltage: 120.0
input.voltage.nominal: 120
output.voltage: 264.0
ups.beeper.status: disabled
ups.delay.shutdown: 20
ups.delay.start: 30
ups.load: 32
ups.mfr: CPS
ups.model: PR1000RTXL2U
ups.productid: 0601
ups.realpower.nominal: 1000
ups.serial: xxxxxxxxxxxx
ups.status: OL
ups.test.result: No test initiated
ups.timer.shutdown: 0
ups.timer.start: 0
ups.vendorid: 0764
alex@ubuntu-server-nut:~/nut$

Date and output voltage are off as discussed above.

@jimklimov
Copy link
Member

@alexruffell : that looks like it did not actually succeed configuring or compiling NUT when you ran ./ci_build.sh

@jimklimov
Copy link
Member

Also, just to not mix threads - here we try to figure out if dates are served in CPS USB HID payload, not the voltages (there's e.g. #1512 for that). There are several "vendor-extension" usages (not mapped from HEX to names) in the report above; I did not find what they may mean. Maybe they carry additional data, maybe not.

Perhaps some USB sniffer to catch traffic from their Windows programs (if any) can help make sense of this data, or asking the company by mail for a spec (and whether it may be published)...

@jimklimov
Copy link
Member

jimklimov commented Sep 9, 2022 •
edited
Loading

Regarding the original issue, with battery.mfr.date, one big question is if the UPS serves it at all.

As the mailing list thread linked from original post suggests, "exploring" the HID UPS device with the usbhid-ups driver might help. See also https://networkupstools.org/docs/developer-guide.chunked/ar01s04.html#_writing_a_subdriver suggestions and a bit later about "Updating a subdriver" to see what reports your device model actually gives which might not be covered by existing mappings.

Same discussion actually also touches on bogus output.voltage (e.g. input.voltage: 120.0 vs output.voltage: 264.0 in NUT v2.7.4 based report above) - this is hopefully fixed in current NUT codebase, with #439 having been resolved.

@flashydave
Copy link
Contributor

flashydave commented Sep 9, 2022 via email

@alexruffell
Copy link

alexruffell commented Sep 11, 2022 •
edited
Loading

I was wondering that too as the batteries do not have any smarts so it would be impossible to know when they were manufactured. My UPS allows me to keep track of when the batteries were installed in the web interface but I don't see the date in the data I posted above. So, I wonder whether the mfg date is actually the install date, or the data point is simply missing.

image

@jimklimov
Copy link
Member

jimklimov commented Sep 20, 2022 •
edited
Loading

Well, I did the best I could for now for remote investigation, code-digging and improvement on at least some rough edges (PR merged).

If someone comes up with discoveries where the CPS devices report e.g. battery's last-replacement date via USB HID protocol (note there are unnamed report branches we did not look into), feel free and welcome to open a new ticket/PR and reference this one for context.

@jimklimov
Copy link
Member

@alexruffell : since your UPS has web-management access, did you check if snmp-ups handles it, as an alternative possibly suitable driver?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug CyberPower (CPS) USB
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fixes to "battery.mfr.date" (cps-hid, powercom-hid) jimklimov/nut
5 participants
@clepple @Brunty @jimklimov @flashydave @alexruffell