`usbhid-ups` generally: apply disable_fix_report_desc…; `cps-hid`: fix mismatched LogMax between input/output voltages (bad encoding) by jimklimov · Pull Request #2718 · networkupstools/nut

jimklimov · 2024-12-12T16:36:47Z

…interruptsize and interruptonly before comm_driver->open_dev() [#1512, #1575]

Follows up from PR #1245 that addressed #439 and a ton of related issues.

jimklimov · 2024-12-13T11:59:12Z

Awaiting end-user testing with a custom build of NUT from this PR branch, as detailed in #1512 (comment) - namely, to test for voltage fix-ups, you can install the prerequisites for your platform as listed in links from the wiki article https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests e.g. at https://networkupstools.org/docs/user-manual.chunked/_build_prerequisites_to_make_nut_from_scratch_on_various_operating_systems.html, and build the PR source branch:

:; git clone https://github.com/jimklimov/nut -b issue-1575 nut-issue-1575
:; cd nut-issue-1575
:; BUILD_TYPE=inplace ./ci_build.sh

and then stop your current NUT driver service, and run sudo ./drivers/usbhid-ups -DDDDDD -d1 -a YourUpsName for a single (-d1) data-collection pass and dump, and post the results.

Remember you would need to comment away disable_fix_report_desc from ups.conf if it is there :)

CC @AlexJakeGreen @Timi7007

Also CC @nbriggs @flashydave : does the change make sense?

Adding pings for other related issues, to see if they can get closed by this (or earlier e.g. #1040, #1245) development, primarily on CPS Vendor ID 0x0764 devices with Product IDs 0x0501 and 0x0601. There seems to be quiet a list of CPS users bit by this, even though maybe I've missed some:

...and that there is no new regression for closed cases at (note the voltage data in some of the DDL dumps there seemed wrong, may be better now):

[HCL] Cyber Power Systems CP1500PFCLCD supported by usbhid #520 CC @webtroter @ShahimEssaid @misiektoja @stompro
[HCL] <Cyber Power Systems> <PR1500RT2U> supported by <usbhid-ups> #1191 CC @Brandoskey
[Cyberpower PR1500ELCD] Various regression with latest updates #1969 CC @sblantipodi @ingcicala @KameDomotics
[HCL] Cyber Power System UT1050EG supported by usbhid-ups #2717 CC @strainu

AlexJakeGreen · 2024-12-16T12:12:07Z

I guess I collected observations properly ↓↓↓↓

Built from

git checkout issue-1575
   repository:               https://github.com/jimklimov/nut.git
   at the commit:            68bbe9cec2ae66c1c4d625d7429381013d46ce0f

Result of /lib64/nut/usbhid-ups -DDDDDD -d1 -a ups:
usbhid-ups_DDDDDD_d1_a_ups.txt.gz

Both input and output are wrong (expected somewhere between 230...232):

$ zgrep -E '(input|output).voltage:' usbhid-ups_DDDDDD_d1_a_ups.txt.gz 
input.voltage: 0.7
output.voltage: 0.7

Result of /lib64/nut/usbhid-ups -DDDDDD -d1 -x disable_fix_report_desc -a ups:
usbhid-ups_DDDDDD_d1_a_ups_x_disable_fix_report_desc.txt.gz
input is correct, output is wrong:

$ zgrep -E '(input|output).voltage:' usbhid-ups_DDDDDD_d1_a_ups_x_disable_fix_report_desc.txt.gz 
input.voltage: 225.4
output.voltage: 20.6

Real values for input and output are the same, but measurement difference is 2254 - 206 = 2048

ups.conf:
ups.conf.gz

jimklimov · 2024-12-16T15:18:27Z

Thanks @AlexJakeGreen! This couple of data-dumps (and their comparison) looks most helpful. Reports differ in one byte (note 0xc7 vs. 0xce) and resulting "Value", reviewing if the byte-difference is due to our fixup.

Note that we see readings and conversions twice - in initial discovery and attempt to parse the HID report there, and (after Detected a UPS line) the "subsequent update" just before the driver's first data processing loop.

on one side I see the logic firing, even if not too correct-looking:

   0.011435	Using subdriver: CyberPower HID 0.82
   0.011454	[D3] Attempting Report Descriptor fix for UPS: Vendor: 0764, Product: 0601
   0.011468	[D4] Original Report Descriptor: output LogMin: 0 LogMax: 255 (assumed: yes)
   0.011479	[D4] Original Report Descriptor: input LogMin: 0 LogMax: 65535 (assumed: yes)
   0.011489	[D3] Fixing Report Descriptor: set Input Voltage LogMax = 12
   0.011499	[D3] Fixing Report Descriptor: set Output Voltage LogMax = 12
   0.011508	[D2] Report Descriptor Fixed
   0.011519	[D1] 73 HID objects found
...
### Initial data walk, Report 0x0f with fixup
   0.019406	[D4] Entering libusb_get_report
   0.019580	[D3] Report[get]: (3 bytes) => 0f c7 08
   0.019602	[D5] PhyMax = 0, PhyMin = 0, LogMax = 12, LogMin = 0
   0.019614	[D5] Unit = 00f0d121, UnitExp = 6
   0.019624	[D5] Exponent = -1
   0.019635	[D5] hid_lookup_path: 00840004 -> UPS
   0.019647	[D5] hid_lookup_path: 0084001a -> Input
   0.019658	[D5] hid_lookup_path: 00840030 -> Voltage
   0.019672	[D1] Path: UPS.Input.Voltage, Type: Feature, ReportID: 0x0f, Offset: 0, Size: 16, Value: 0.7
...
### Initial data walk, Report 0x12 with fixup
   0.020846	[D4] Entering libusb_get_report
   0.021078	[D3] Report[get]: (3 bytes) => 12 c7 08
   0.021100	[D5] PhyMax = 0, PhyMin = 0, LogMax = 12, LogMin = 0
   0.021113	[D5] Unit = 00f0d121, UnitExp = 6
   0.021123	[D5] Exponent = -1
   0.021134	[D5] hid_lookup_path: 00840004 -> UPS
   0.021146	[D5] hid_lookup_path: 0084001c -> Output
   0.021157	[D5] hid_lookup_path: 00840030 -> Voltage
   0.021171	[D1] Path: UPS.Output.Voltage, Type: Feature, ReportID: 0x12, Offset: 0, Size: 16, Value: 0.7
...
### Subsequent (first) update, Report 0x0f with fixup
   0.242479	[D5] hid_lookup_usage: UPS -> 00840004
   0.242494	[D5] hid_lookup_usage: Input -> 0084001a
   0.242515	[D5] hid_lookup_usage: Voltage -> 00840030
   0.242527	[D4] string_to_path: depth = 3
   0.242545	[D3] Report[buf]: (3 bytes) => 0f c7 08
   0.242557	[D5] PhyMax = 0, PhyMin = 0, LogMax = 12, LogMin = 0
   0.242568	[D5] Unit = 00f0d121, UnitExp = 6
   0.242578	[D5] Exponent = -1
   0.242592	[D2] Path: UPS.Input.Voltage, Type: Feature, ReportID: 0x0f, Offset: 0, Size: 16, Value: 0.7
   0.242611	[D5] send_to_all: SETINFO input.voltage "0.7"
...
### Subsequent (first) update, Report 0x12 with fixup
   0.243298	[D5] hid_lookup_usage: UPS -> 00840004
   0.243313	[D5] hid_lookup_usage: Output -> 0084001c
   0.243327	[D5] hid_lookup_usage: Voltage -> 00840030
   0.243339	[D4] string_to_path: depth = 3
   0.243355	[D3] Report[buf]: (3 bytes) => 12 c7 08
   0.243368	[D5] PhyMax = 0, PhyMin = 0, LogMax = 12, LogMin = 0
   0.243378	[D5] Unit = 00f0d121, UnitExp = 6
   0.243388	[D5] Exponent = -1
   0.243402	[D2] Path: UPS.Output.Voltage, Type: Feature, ReportID: 0x12, Offset: 0, Size: 16, Value: 0.7
   0.243420	[D5] send_to_all: SETINFO output.voltage "0.7"
...

for the other contender, the flag is now honoured (at least that fix works):

   0.000282	[D3] main_arg: var='disable_fix_report_desc' val='<null>'
   0.000303	[D5] send_to_all: SETINFO driver.flag.disable_fix_report_desc "enabled"
...
   0.010850	Using subdriver: CyberPower HID 0.82
   0.010864	[D3] NOT Attempting Report Descriptor fix for UPS: Vendor: 0764, Product: 0601 (got disable_fix_report_desc in config)
   0.010878	[D1] 73 HID objects found
...
### Initial data walk, Report 0x0f without fixup
   0.020566	[D4] Entering libusb_get_report
   0.020728	[D3] Report[get]: (3 bytes) => 0f ce 08
   0.020745	[D5] PhyMax = 0, PhyMin = 0, LogMax = 65535, LogMin = 0
   0.020757	[D5] Unit = 00f0d121, UnitExp = 6
   0.020768	[D5] Exponent = -1
   0.020778	[D5] hid_lookup_path: 00840004 -> UPS
   0.020789	[D5] hid_lookup_path: 0084001a -> Input
   0.020801	[D5] hid_lookup_path: 00840030 -> Voltage
   0.020817	[D1] Path: UPS.Input.Voltage, Type: Feature, ReportID: 0x0f, Offset: 0, Size: 16, Value: 225.4
...
### Initial data walk, Report 0x12 without fixup
   0.021614	[D4] Entering libusb_get_report
   0.021805	[D3] Report[get]: (3 bytes) => 12 ce 08
   0.021823	[D5] PhyMax = 0, PhyMin = 0, LogMax = 255, LogMin = 0
   0.021835	[D5] Unit = 00f0d121, UnitExp = 6
   0.021845	[D5] Exponent = -1
   0.021856	[D5] hid_lookup_path: 00840004 -> UPS
   0.021867	[D5] hid_lookup_path: 0084001c -> Output
   0.021879	[D5] hid_lookup_path: 00840030 -> Voltage
   0.021894	[D1] Path: UPS.Output.Voltage, Type: Feature, ReportID: 0x12, Offset: 0, Size: 16, Value: 20.6
...
### Subsequent (first) update, Report 0x0f without fixup
   0.241426	[D5] hid_lookup_usage: UPS -> 00840004
   0.241440	[D5] hid_lookup_usage: Input -> 0084001a
   0.241454	[D5] hid_lookup_usage: Voltage -> 00840030
   0.241465	[D4] string_to_path: depth = 3
   0.241481	[D3] Report[buf]: (3 bytes) => 0f ce 08
   0.241493	[D5] PhyMax = 0, PhyMin = 0, LogMax = 65535, LogMin = 0
   0.241504	[D5] Unit = 00f0d121, UnitExp = 6
   0.241514	[D5] Exponent = -1
   0.241529	[D2] Path: UPS.Input.Voltage, Type: Feature, ReportID: 0x0f, Offset: 0, Size: 16, Value: 225.4
   0.241567	[D5] send_to_all: SETINFO input.voltage "225.4"
...
### Subsequent (first) update, Report 0x12 without fixup
   0.242283	[D5] hid_lookup_usage: UPS -> 00840004
   0.242298	[D5] hid_lookup_usage: Output -> 0084001c
   0.242313	[D5] hid_lookup_usage: Voltage -> 00840030
   0.242324	[D4] string_to_path: depth = 3
   0.242340	[D3] Report[buf]: (3 bytes) => 12 ce 08
   0.242353	[D5] PhyMax = 0, PhyMin = 0, LogMax = 255, LogMin = 0
   0.242363	[D5] Unit = 00f0d121, UnitExp = 6
   0.242373	[D5] Exponent = -1
   0.242388	[D2] Path: UPS.Output.Voltage, Type: Feature, ReportID: 0x12, Offset: 0, Size: 16, Value: 20.6
   0.242406	[D5] send_to_all: SETINFO output.voltage "20.6"
...

I am not sure if the fixup is related to issues occasionally seen after upsdrv_updateinfo line (happened in both cases at different times), or if it is the firmware acting up:

first couple:

### with fixup
   0.254606	[D1] upsdrv_updateinfo...
   1.005307	[D2] nut_libusb_get_interrupt: Connection timed out
   1.005338	[D1] Got 0 HID objects (1 times in a row, tolerance is -1)...
   1.005354	[D1] Quick update...
...

### without fixup:
   0.246060	[D1] upsdrv_updateinfo...
   0.357154	[D3] Report[int]: (6 bytes) => 08 64 60 09 2c 01
   0.357187	[D1] Got 3 HID objects...
...

second couple:

### with fixup
   1.005866	[D1] upsdrv_updateinfo...
   1.756564	[D2] nut_libusb_get_interrupt: Connection timed out
   1.756596	[D1] Got 0 HID objects (2 times in a row, tolerance is -1)...
   1.756612	[D1] Quick update...
   1.756625	[D4] Entering libusb_get_report
   1.757708	[D2] nut_libusb_get_report: Overflow
   1.757745	[D1] Can't retrieve Report 16: Success
   1.757760	[D4] Entering libusb_get_report
   1.758624	[D2] nut_libusb_get_report: Overflow
   1.758644	[D1] Can't retrieve Report 15: Success
   1.758658	[D4] Entering libusb_get_report
   1.759170	[D2] nut_libusb_get_report: Overflow
   1.759195	[D1] Can't retrieve Report 0b: Success
   1.759209	[D4] Entering libusb_get_report
   1.759596	[D2] nut_libusb_get_report: Overflow
   1.759616	[D1] Can't retrieve Report 0b: Success
   1.759628	[D4] Entering libusb_get_report
   1.760082	[D2] nut_libusb_get_report: Overflow
   1.760102	[D1] Can't retrieve Report 0b: Success
   1.760114	[D4] Entering libusb_get_report
   1.760563	[D2] nut_libusb_get_report: Overflow
   1.760591	[D1] Can't retrieve Report 0b: Success
   1.760620	[D5] send_to_all: SETINFO driver.state "quiet"
   1.760641	[D5] send_to_all: SETINFO driver.state "dumping"
...

### without fixup:
   0.358019	[D1] upsdrv_updateinfo...
   1.108485	[D2] nut_libusb_get_interrupt: Connection timed out
   1.108516	[D1] Got 0 HID objects (1 times in a row, tolerance is -1)...
   1.108532	[D1] Quick update...
   1.108548	[D3] Report[buf]: (3 bytes) => 16 ff ff
   1.108561	[D5] PhyMax = 1966020, PhyMin = -60, LogMax = 32767, LogMin = -1
   1.108572	[D5] Unit = 00001001, UnitExp = 0
   1.108582	[D5] Exponent = 0
   1.108598	[D2] Path: UPS.Output.DelayBeforeStartup, Type: Feature, ReportID: 0x16, Offset: 0, Size: 16, Value: -60
   1.108618	[D3] Report[buf]: (3 bytes) => 15 ff ff
   1.108630	[D5] PhyMax = 1966020, PhyMin = -60, LogMax = 32767, LogMin = -1
   1.108641	[D5] Unit = 00001001, UnitExp = 0
   1.108651	[D5] Exponent = 0
   1.108664	[D2] Path: UPS.Output.DelayBeforeShutdown, Type: Feature, ReportID: 0x15, Offset: 0, Size: 16, Value: -60
   1.108682	[D3] Report[buf]: (2 bytes) => 0b 13
   1.108694	[D5] PhyMax = 0, PhyMin = 0, LogMax = 1, LogMin = 0
   1.108705	[D5] Unit = 00000000, UnitExp = 0
   1.108714	[D5] Exponent = 0
   1.108728	[D2] Path: UPS.PowerSummary.PresentStatus.ACPresent, Type: Feature, ReportID: 0x0b, Offset: 0, Size: 1, Value: 1
   1.108738	[D5] hu_find_infoval: found online (value: 1)
   1.108749	[D5] process_boolean_info: online
   1.108761	[D3] Report[buf]: (2 bytes) => 0b 13
   1.108773	[D5] PhyMax = 0, PhyMin = 0, LogMax = 1, LogMin = 0
   1.108784	[D5] Unit = 00000000, UnitExp = 0
   1.108793	[D5] Exponent = 0
   1.108806	[D2] Path: UPS.PowerSummary.PresentStatus.Charging, Type: Feature, ReportID: 0x0b, Offset: 1, Size: 1, Value: 1
   1.108816	[D5] hu_find_infoval: found chrg (value: 1)
   1.108826	[D5] process_boolean_info: chrg
   1.108839	[D3] Report[buf]: (2 bytes) => 0b 13
   1.108851	[D5] PhyMax = 0, PhyMin = 0, LogMax = 1, LogMin = 0
   1.108861	[D5] Unit = 00000000, UnitExp = 0
   1.108871	[D5] Exponent = 0
   1.108884	[D2] Path: UPS.PowerSummary.PresentStatus.Discharging, Type: Feature, ReportID: 0x0b, Offset: 2, Size: 1, Value: 0
   1.108894	[D5] hu_find_infoval: found !dischrg (value: 0)
   1.108904	[D5] process_boolean_info: !dischrg
   1.108917	[D3] Report[buf]: (2 bytes) => 0b 13
   1.108928	[D5] PhyMax = 0, PhyMin = 0, LogMax = 1, LogMin = 0
   1.108939	[D5] Unit = 00000000, UnitExp = 0
   1.108949	[D5] Exponent = 0
   1.108961	[D2] Path: UPS.PowerSummary.PresentStatus.BelowRemainingCapacityLimit, Type: Feature, ReportID: 0x0b, Offset: 3, Size: 1, Value: 0
   1.108975	[D5] hu_find_infoval: found !lowbatt (value: 0)
   1.108985	[D5] process_boolean_info: !lowbatt
   1.109009	[D5] send_to_all: SETINFO driver.state "quiet"
   1.109024	[D5] send_to_all: SETINFO driver.state "dumping"
...

Seemingly more offtopic right now: there are also quite a few entries (for different Reports) like:

   0.030167	[D4] Entering libusb_get_report
   0.030435	[D2] nut_libusb_get_report: Overflow
   0.030456	[D1] Can't retrieve Report 2d: Success
   0.030469	[D5] hid_lookup_path: 00840004 -> UPS
   0.030482	[D5] hid_lookup_path: ff01001d -> not found in lookup table
   0.030494	[D5] hid_lookup_path: ff01001b -> not found in lookup table
   0.030506	[D5] hid_lookup_path: ff01001f -> not found in lookup table
   0.030518	[D1] Path: UPS.ff01001d.ff01001b.ff01001f, Type: Feature, ReportID: 0x2d, Offset: 2, Size: 1

...where on one hand, we do not even know the mapping of numeric HID path components to their logical roles/names, and on another - something overflows. I did not investigate what happens, but we might expect a number by default and get a string (too large for a buffer) or something else - just guessing based on it being an unknown report, and that we SETINFO strings (mfr, model, etc.) just after those.

Also more specifically about string fetches (which I think #2604 should have solved, unless this dialog is broken in some other way):

   0.032835	[D2] Path: UPS.PowerSummary.iDeviceChemistry, Type: Feature, ReportID: 0x04, Offset: 0, Size: 8, Value: 4
   0.033137	[D1] nut_usb_get_string_descriptor: string descriptor 0 request failed, retrying...
   0.084018	[D1] nut_usb_get_string_descriptor: string descriptor 0 request failed, retrying...
   0.134874	[D2] nut_libusb_get_string: Overflow
   0.134914	[D5] send_to_all: SETINFO battery.type ""
...

   0.135121	[D2] Path: UPS.PowerSummary.iOEMInformation, Type: Feature, ReportID: 0x03, Offset: 0, Size: 8, Value: 3
   0.136103	[D1] nut_usb_get_string_descriptor: string descriptor 0 request failed, retrying...
   0.187014	[D1] nut_usb_get_string_descriptor: string descriptor 0 request failed, retrying...
   0.237877	[D2] nut_libusb_get_string: Overflow
   0.237918	[D5] send_to_all: SETINFO battery.mfr.date ""

…ruptsize and interruptonly before comm_driver->open_dev() [networkupstools#1512, networkupstools#1575] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>

…debug prints Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>

…ortIDs Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>

…k, to be clear in troubleshooting Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>

… assumed_LogMax [networkupstools#1512] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>

… Input Voltage" for a fix [networkupstools#1245] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>

…ed LogMax for input/output voltages [networkupstools#1512] Note: not bumping version, as it was done in another commit of same PR networkupstools#2718 Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>

…rkupstools#2718] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>

…orkupstools#2718] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>

jimklimov · 2024-12-16T17:12:57Z

@AlexJakeGreen: thanks again for the logs, I caught the bug I think (got distracted and mixed up the languages, mindlessly used ^ as power-of operator when it was not). Now the code should limit LogMax=32767 for the 16-bit signed value (CC @nbriggs - I hope this is the most correct guess when we imagine things in lieu of a good statement in device reports, e.g. 65535 would be wrong, right?)

Can you please re-check with the descriptor fix-up?

Please note that I had to force-push the changes after an update from master branch, so you'd likely need to remove and recreate the build workspace, fetching the new state of the PR source branch.

Or if you're comfortable with git, try something like this to change the workspace files "in place":

:; git fetch --all && git reset origin/issue-1575 && git checkout -f

…rkupstools#2718] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>

…orkupstools#2718] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>

…riginal error was caught [networkupstools#2718] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>

Timi7007 · 2024-12-17T13:02:35Z

As for 327V... maybe 3-phase devices can claim 420V. I guess we'd see if there are any practical bug reports against 32767 (or their makers get specs right).

In the 60Hz part of the world it's a different story and I'm not an expert, but in our European 50Hz grid single phase is 230 V ± 10%/23 V so between 207V and 253V. Three-phase used to be 380V and 415V, they now met in the middle at 400V ± 10% setting the maximum to 440V.
Since the UPS should kick in even if the grid values are violated (e.g. overloaded generator) everything lower than these should also be functional. This coincidentally includes the 120V single-phase three-leg 60Hz US-power and it's three-phase potentials of 208V and 415V. Even the lowest international grid voltage of Japan's 100V.

That's just power theory though and I don't have a clue about USB drivers.

jimklimov · 2024-12-17T13:07:23Z

Ok, so to err on the safe side, I'll assume 65535 for the 16-bit maximum (=>655V)?

Or... wait... with Exponent = -1 we count in 0.1V not 0.01V - so a 32767 value is 3276,7V anyway? Did someone up in the thread try to confuse me? ;p

Timi7007 · 2024-12-17T13:20:26Z

I know of industrial setups with 690V three-phase power with 400V on each phase but haven't heard of UPSes for those and would assume anything that high would be over-voltage for everything used in IT.
I also don't know how NUT handles three-phase UPSes. Realistically measuring each phase and calculating total voltage from that would work just fine and may be somewhat more useful for diagnostics. So again no idea if 65535 would be required, I was just trying to say that 420V might not be unrealistic.

…workupstools#2718] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>

Timi7007 · 2024-12-17T13:56:24Z

My test was successful: #1512 (comment)

…workupstools#2718] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>

…p for input_logmin/input_logmax vs. high voltage transfer [#1245, #2718] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>

jimklimov added this to the 2.8.3 milestone Dec 12, 2024

jimklimov added need testing Code looks reasonable, but the feature would better be tested against hardware or OSes CyberPower (CPS) labels Dec 13, 2024

jimklimov changed the title ~~drivers/usbhid-ups.c, NEWS.adoc: apply disable_fix_report_desc…~~ usbhid-ups generally: apply disable_fix_report_desc…; cps-hid: fix mismatched LogMax between input/output voltages (bad encoding) Dec 13, 2024

jimklimov added the Incorrect or missing readings On some devices driver-reported values are systemically off (e.g. x10, x0.1, const+Value, etc.) label Dec 16, 2024

This was referenced Dec 16, 2024

OpenUPS v1.9 firmware reports wrong battery current #516

Open

[Legrand Keor SP 1000] Incorrect output voltage shown #1535

Open

[HCL] Cyber Power System UT1050EG supported by usbhid-ups #2717

Closed

jimklimov added 7 commits December 16, 2024 17:30

drivers/usbhid-ups.c, NEWS.adoc: apply disable_fix_report_desc, inter…

fc4602b

…ruptsize and interruptonly before comm_driver->open_dev() [networkupstools#1512, networkupstools#1575] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>

drivers/cps-hid.c: cps_fix_report_desc(): line-wrap big comments and …

732af11

…debug prints Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>

drivers/cps-hid.c: cps_fix_report_desc(): comment HEX variants of Rep…

3de756d

…ortIDs Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>

drivers/cps-hid.c: cps_fix_report_desc(): debug-log if we skipped wor…

9bc391e

…k, to be clear in troubleshooting Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>

drivers/hidparser.c, drivers/hidtypes.h, NEWS.adoc: track the fact of…

f3a9bcc

… assumed_LogMax [networkupstools#1512] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>

drivers/cps-hid.c, NEWS.adoc: cps_fix_report_desc(): do actually "set…

f98c8e5

… Input Voltage" for a fix [networkupstools#1245] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>

drivers/cps-hid.c, NEWS.adoc: cps_fix_report_desc(): address mismatch…

94d65f6

…ed LogMax for input/output voltages [networkupstools#1512] Note: not bumping version, as it was done in another commit of same PR networkupstools#2718 Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>

jimklimov force-pushed the issue-1575 branch from 68bbe9c to e5fb936 Compare December 16, 2024 17:08

jimklimov added a commit to jimklimov/nut that referenced this pull request Dec 16, 2024

drivers/cps-hid.c: cps_fix_report_desc(): update debug-logging [netwo…

9d86d5f

…rkupstools#2718] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>

jimklimov added a commit to jimklimov/nut that referenced this pull request Dec 16, 2024

drivers/cps-hid.c: cps_fix_report_desc(): fix powers of 2 maths [netw…

e5fb936

…orkupstools#2718] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>

jimklimov added 2 commits December 16, 2024 18:18

drivers/cps-hid.c: cps_fix_report_desc(): update debug-logging [netwo…

da1b608

…rkupstools#2718] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>

drivers/cps-hid.c: cps_fix_report_desc(): fix powers of 2 maths [netw…

cff8cfd

…orkupstools#2718] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>

drivers/cps-hid.c: cps_fix_report_desc(): simplify sizeMax now that o…

b249c99

…riginal error was caught [networkupstools#2718] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>

Timi7007 mentioned this pull request Dec 17, 2024

PowerWalker VI 500 R1U miscalculating output voltage after driver update #1512

Closed

jimklimov added a commit to jimklimov/nut that referenced this pull request Dec 17, 2024

drivers/cps-hid.c: cps_fix_report_desc(): take the higher ground [net…

0745058

…workupstools#2718] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>

drivers/cps-hid.c: cps_fix_report_desc(): take the higher ground [net…

315a183

…workupstools#2718] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>

jimklimov force-pushed the issue-1575 branch from 0745058 to 315a183 Compare December 17, 2024 16:30

jimklimov merged commit 38b7051 into networkupstools:master Dec 18, 2024

jimklimov deleted the issue-1575 branch December 18, 2024 11:44

jimklimov added a commit that referenced this pull request Dec 18, 2024

drivers/cps-hid.c: cps_fix_report_desc(): complete the original fix-u…

006e879

…p for input_logmin/input_logmax vs. high voltage transfer [#1245, #2718] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>

This was referenced Dec 18, 2024

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

Open

CPS HID: Many unknown readings #2729

Open

CPS wrong output voltage nutdotnet/WinNUT-Client#101

Closed

jimklimov restored the issue-1575 branch April 15, 2025 09:45

jimklimov deleted the issue-1575 branch April 15, 2025 10:49

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

`usbhid-ups` generally: apply disable_fix_report_desc…; `cps-hid`: fix mismatched LogMax between input/output voltages (bad encoding)#2718

`usbhid-ups` generally: apply disable_fix_report_desc…; `cps-hid`: fix mismatched LogMax between input/output voltages (bad encoding)#2718
jimklimov merged 12 commits intonetworkupstools:masterfrom
jimklimov:issue-1575

jimklimov commented Dec 12, 2024 •

edited

Loading

Uh oh!

jimklimov commented Dec 13, 2024 •

edited

Loading

Uh oh!

AlexJakeGreen commented Dec 16, 2024 •

edited

Loading

Uh oh!

jimklimov commented Dec 16, 2024

Uh oh!

jimklimov commented Dec 16, 2024 •

edited

Loading

Uh oh!

Timi7007 commented Dec 17, 2024

Uh oh!

jimklimov commented Dec 17, 2024

Uh oh!

Timi7007 commented Dec 17, 2024 •

edited

Loading

Uh oh!

Timi7007 commented Dec 17, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Conversation

jimklimov commented Dec 12, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jimklimov commented Dec 13, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

AlexJakeGreen commented Dec 16, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jimklimov commented Dec 16, 2024

Uh oh!

jimklimov commented Dec 16, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Timi7007 commented Dec 17, 2024

Uh oh!

jimklimov commented Dec 17, 2024

Uh oh!

Timi7007 commented Dec 17, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Timi7007 commented Dec 17, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

jimklimov commented Dec 12, 2024 •

edited

Loading

jimklimov commented Dec 13, 2024 •

edited

Loading

AlexJakeGreen commented Dec 16, 2024 •

edited

Loading

jimklimov commented Dec 16, 2024 •

edited

Loading

Timi7007 commented Dec 17, 2024 •

edited

Loading