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.

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

CPS HID: Some devices report output.voltage values too high #2728

Open
jimklimov opened this issue Dec 18, 2024 · 5 comments
Open

CPS HID: Some devices report output.voltage values too high #2728

jimklimov opened this issue Dec 18, 2024 · 5 comments
Labels
CyberPower (CPS) Incorrect or missing readings On some devices driver-reported values are systemically off (e.g. x10, x0.1, const+Value, etc.) need testing Code looks reasonable, but the feature would better be tested against hardware or OSes Synology Issues related to NUT integration in Synology storage platform USB
Milestone

Comments

@jimklimov
Copy link
Member

Much higher than input.voltage, often similar (not always equal) to High Transfer Voltage values where available. In many examples it is stuck at 265.0, regardless of inputs being in 120V or 220-240V ranges.

While the issue was seen on some devices with NUT v2.7.4, it is possible that USB descriptor fix-ups introduced in #1245 (released in NUT v2.8.0) and updated by #2718 (to be released in NUT v2.8.3, currently requires custom builds to test or take advantage of) fixed some issues for one set of models/firmwares, and broke the behaviors for others that were good out of the box. This aspect can now be easily verified by use of disable_fix_report_desc setting for usbhid-ups driver.

It is however possible that those devices are botched in some other way that we still mis-interpret (do not compensate for vendor errors), or that the devices just lie to us and confuse the values internally. Comparative tests with older NUT releases (2.7.4, 2.8.0, current) would be helpful.

Per #1338 (comment) :

0.009244     [D1] Path: UPS.Output.LowVoltageTransfer, Type: Feature, ReportID: 0x10, Offset: 0, Size: 16, Value: 207
0.009253     [D1] Path: UPS.Output.LowVoltageTransfer, Type: Input, ReportID: 0x10, Offset: 0, Size: 16, Value: 207
0.009258     [D1] Path: UPS.Output.HighVoltageTransfer, Type: Feature, ReportID: 0x10, Offset: 16, Size: 16, Value: 253
0.009261     [D1] Path: UPS.**Output.HighVoltageTransfer**, Type: Input, **ReportID: 0x10, Offset: 16**, Size: 16, Value: **253**
0.009452     [D1] Path: UPS.**Output.Voltage**, Type: Feature, **ReportID: 0x12, Offset: 0**, Size: 16, Value: **253**

On line 4, there is ReportID 0x10 offset 16 - HighVoltageTransfer 253
On line 5, ReportID 12, offset 0, Output Voltage 253
Based on the debug - I'm not sure what ReportID exactly is, does NUT really read diferrent data and UPS reports the same value 253 or NUT actually reads the same data? Or ReportID 0x10 offset 16 is the same part of data as ReportID 12 offset 0 ?

Per #982 (comment) this looks like something #2718 and/or #1245 already could have fixed along the way:

NOTE Hex 0x74 is 116 not 140

8.350308 Report[buf]: (3 bytes) => 12 74 00
8.350325 PhyMax = 0, PhyMin = 0, LogMax = 142, LogMin = 136
8.350342 Unit = 00f0d121, UnitExp = 7
8.350359 Exponent = 0
8.350377 Path: UPS.Output.Voltage, Type: Feature, ReportID: 0x12, Offset: 0, Size: 16, Value: 140
8.350396 send_to_all: SETINFO output.voltage "140.0"

Likewise for #982 (comment) :

Hex 7c = 124 but the value reported is 140.

0.653344 Entering libusb_get_report
0.654006 Report[get]: (3 bytes) => 12 7c 00
0.654049 PhyMax = 0, PhyMin = 0, LogMax = 142, LogMin = 136
0.654091 Unit = 00f0d121, UnitExp = 7
0.654125 Exponent = 0
0.654295 Path: UPS.Output.Voltage, Type: Feature, ReportID: 0x12, Offset: 0, Size: 16, Value: 140

Or #581 (comment) which has same raw readings but may have different LogMin/LogMax (addressed by the PRs above later):

my CP900EPFCLCD reports the output voltage as being between 260 and 270 - though it sits at 260 most of the time. The input voltage averages around 240 as would be expected. I'm not entirely sure what to make of this, though it would appear that ef (239) is somehow being interpreted as 260?

0.010678 Report[get]: (3 bytes) => 0f ef 00
0.010687 Path: UPS.Input.Voltage, Type: Feature, ReportID: 0x0f, Offset: 0, Size: 16, Value: 239
...
0.011178 Report[get]: (3 bytes) => 12 ef 00
0.011188 Path: UPS.Output.Voltage, Type: Feature, ReportID: 0x12, Offset: 0, Size: 16, Value: 260

This issue follows up from earlier reports, some closed over time, to track the problem with this specific reading:

driver.version: 20220328-3481-gccbf3eb6c6
driver.version.data: CyberPower HID 0.6
driver.version.internal: 0.47
input.voltage: 236.0
input.voltage.nominal: 230
output.voltage: 265.0    #BAD: expected near 236
driver.version: 2.7.4
driver.version.data: CyberPower HID 0.4
driver.version.internal: 0.41
input.voltage: 121.0
input.voltage.nominal: 120
output.voltage: 265.0    #BAD: expected near 120
driver.version: 2.7.4
driver.version.data: CyberPower HID 0.4
driver.version.internal: 0.41
input.transfer.high: 139
input.transfer.low: 88
input.voltage: 116.0
input.voltage.nominal: 120
output.voltage: 140.0    #BAD: expected near 120
driver.version: 2.7.4
driver.version.data: CyberPower HID 0.4
driver.version.internal: 0.41
input.voltage: 231.0
input.voltage.nominal: 230
output.voltage: 263.0    #BAD: expected near 230 (note not 265.0 either)
### Version 2.7.4-5004-g1f143e5e (month before 2.8.0)
input.voltage: 232.0
input.voltage.nominal: 230
output.voltage: 253.0    #BAD: The value 253 in output.voltage is actually high transfer value. Probably easy to fix.
driver.version: 2.8.0-rc2-109-gbce1d5201
driver.version.data: CyberPower HID 0.6
driver.version.internal: 0.47
driver.version.usb: libusb-1.0.24 (API: 0x1000108)
input.voltage: 230.0
input.voltage.nominal: 230
output.voltage: 253.0
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: 136.0    #BAD: expected near 120
driver.version: 2.7.4
driver.version.data: CyberPower HID 0.4
driver.version.internal: 0.41
input.voltage: 118.0
input.voltage.nominal: 120
output.voltage: 135.0
driver.version: 2.7.4
driver.version.data: CyberPower HID 0.4
driver.version.internal: 0.41
input.voltage: 116.0
input.voltage.nominal: 120
output.voltage: 140.0
input.voltage: 122.0
input.voltage.nominal: 120
output.voltage: 253.0

The dominating idea in those discussions is that for whatever reason NUT reads the output value as whatever is in that byte + 32 (may be or not be the value of some other HID report, especially one of not-yet-decoded ones), and then constrained by LogMin/LogMax values (which may be reported same as High (and maybe Low) Voltage Transfer's LogMin/LogMax values. This is directly the focus of #439 and #1245 (so really wondering if the problem is still seen on devices where the descriptor fix now does happen, especially with current master-branch NUT code base).

@jimklimov jimklimov added need testing Code looks reasonable, but the feature would better be tested against hardware or OSes CyberPower (CPS) USB Incorrect or missing readings On some devices driver-reported values are systemically off (e.g. x10, x0.1, const+Value, etc.) labels Dec 18, 2024
@jimklimov jimklimov added this to the 2.8.4 milestone Dec 18, 2024
@jimklimov
Copy link
Member Author

jimklimov commented Dec 18, 2024

Loosely related to #1535 which has a similar issue with another HID subdriver.
And to #2717 where CPS HID is off by 10x in a frequency reading.

@WillyTP
Copy link

WillyTP commented Jan 15, 2025

CP1500EPFCLCD, with NUT running on a Synology Diskstation with DSM 7.2, shows incorrect output voltage (too high)

battery.charge:`3
battery.charge.low: 10
battery.charge.warning: 20
battery.mfr.date: CPS
battery.runtime: 77
battery.runtime.low: 300
battery.type: PbAcid
battery.voltage: 24.0
battery.voltage.nominal: 24
device.mfr: CPS
device.model: CP1500EPFCLCD
device.serial: CRMMxxx
device.type: ups
driver.name: usbhid-ups
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 5
driver.parameter.port: auto
driver.parameter.synchronous: no
driver.version: DSM7-2-1-69057-NM-nano-4-C1-240105
driver.version.data: CyberPower HID 0.4
driver.version.internal: 0.41
input.transfer.high: 260
input.transfer.low: 170
input.voltage: 230.0
input.voltage.nominal: 230
output.voltage: 262.0
ups.beeper.status: enabled
ups.delay.shutdown: 20
ups.delay.start: 30
ups.load: 12
ups.mfr: CPS
ups.model: CP1500EPFCLCD
ups.productid: 0501
ups.realpower.nominal: 900
ups.serial: CRMMY2000017
ups.status: OL CHRG LB
ups.test.result: Done and warning
ups.timer.shutdown: -60
ups.timer.start: -60
ups.vendorid: 0764

@jimklimov
Copy link
Member Author

@WillyTP : Thanks, FWIW that seems to be NUT v2.7.4, 9 years old soon. You may want to poke the vendor to update their OS sometimes.

@jimklimov jimklimov added the Synology Issues related to NUT integration in Synology storage platform label Jan 15, 2025
@jimklimov
Copy link
Member Author

@WillyTP : Are you in position to try a custom build of current NUT codebase (perhaps with some other computer/VM that this UPS can be attached to temporarily for testing)? See https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests for technical details.

With #1512 solved recently, a possibly same or different issue with output voltage should no longer happen. I wonder if that solution does impact devices that expose the behavior seen here, or it is a different issue after all?..

@MilhouseVH
Copy link

CP1500EPFCLCD, UK (240v/50Hz), input and output voltages look OK.

Master build (commit 6ae5fea, 18 Dec 2024).

battery.charge: 100
battery.charge.low: 3
battery.charge.warning: 20
battery.mfr.date: 2023-03-28
battery.runtime: 3270
battery.runtime.low: 180
battery.status: 100%
battery.type: PbAcid
battery.voltage: 24.0
battery.voltage.nominal: 24
device.mfr: CPS
device.model: CP1500EPFCLCD
device.serial: CRXLX2000266
device.type: ups
driver.debug: 0
driver.flag.allow_killpower: 0
driver.flag.ignorelb: enabled
driver.name: usbhid-ups
driver.parameter.interrupt_pipe_no_events_tolerance: -1
driver.parameter.override.battery.charge.low: 3
driver.parameter.override.battery.mfr.date: 2023-03-28
driver.parameter.override.battery.runtime.low: 180
driver.parameter.override.ups.mfr.date: 2023-03-28
driver.parameter.pollfreq: 12
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.productid: 0501
driver.parameter.synchronous: auto
driver.parameter.vendorid: 0764
driver.state: quiet
driver.version: 2.8.2.1751-1751-g6ae5fead6
driver.version.data: CyberPower HID 0.82
driver.version.internal: 0.60
driver.version.usb: libusb-1.0.22 (API: 0x1000106)
input.sensitivity: normal
input.transfer.high: 260
input.transfer.low: 170
input.voltage: 238.0
input.voltage.nominal: 230
output.voltage: 238.0
ups.beeper.status: enabled
ups.delay.shutdown: 60
ups.delay.start: 120
ups.firmware: CR01505B4
ups.load: 9
ups.mfr: CPS
ups.mfr.date: 2023-03-28
ups.model: CP1500EPFCLCD
ups.productid: 0501
ups.realpower.nominal: 900
ups.serial: CRXLX2000266
ups.status: OL
ups.test.result: No test initiated
ups.timer.shutdown: -60
ups.timer.start: -60
ups.vendorid: 0764

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CyberPower (CPS) Incorrect or missing readings On some devices driver-reported values are systemically off (e.g. x10, x0.1, const+Value, etc.) need testing Code looks reasonable, but the feature would better be tested against hardware or OSes Synology Issues related to NUT integration in Synology storage platform USB
Projects
Status: Todo
Development

No branches or pull requests

3 participants