-
-
Notifications
You must be signed in to change notification settings - Fork 361
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
Comments
CP1500EPFCLCD, with NUT running on a Synology Diskstation with DSM 7.2, shows incorrect output voltage (too high)
|
@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. |
@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?.. |
CP1500EPFCLCD, UK (240v/50Hz), input and output voltages look OK. Master build (commit 6ae5fea, 18 Dec 2024).
|
Much higher than
input.voltage
, often similar (not always equal) to High Transfer Voltage values where available. In many examples it is stuck at265.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 forusbhid-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) :
Per #982 (comment) this looks like something #2718 and/or #1245 already could have fixed along the way:
Likewise for #982 (comment) :
Or #581 (comment) which has same raw readings but may have different LogMin/LogMax (addressed by the PRs above later):
This issue follows up from earlier reports, some closed over time, to track the problem with this specific reading:
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).
The text was updated successfully, but these errors were encountered: