PowerWalker VI 2200 STL (PR1500LCDRT2U) Wrong output voltage

[murdock62]

Hello With Version 2.7.4 of nut on ubuntu all is fine. (the output voltage is added to to the default.output.voltage.nominal)
But with version 2.8.0 on debian only the output voltage is returned.
UPSC output :

Init SSL without certificate database
battery.charge: 100
battery.charge.low: 10
battery.charge.warning: 20
battery.mfr.date: 1
battery.runtime: 1140
battery.runtime.low: 300
battery.type: PbAcid
battery.voltage: 27.1
battery.voltage.nominal: 24
device.mfr: 1
device.model: 2200
device.serial: 000000000000
device.type: ups
driver.name: usbhid-ups
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.synchronous: auto
driver.version: 2.8.0
driver.version.data: CyberPower HID 0.6
driver.version.internal: 0.47
driver.version.usb: libusb-1.0.26 (API: 0x1000109)
input.frequency: 49.9
input.transfer.high: 290
input.transfer.low: 162
input.voltage: 233.0
input.voltage.nominal: 230.0
output.frequency: 49.9
output.voltage: 2.6
output.voltage.nominal: 230.0
ups.beeper.status: disabled
ups.delay.shutdown: 20
ups.delay.start: 30
ups.load: 22
ups.mfr: 1
ups.model: 2200
ups.productid: 0601
ups.realpower.nominal: 1320
ups.serial: 000000000000
ups.status: OL
ups.timer.shutdown: -60
ups.timer.start: -60
ups.vendorid: 0764
root@neutrino:~# upsdrvctl stop
Network UPS Tools - UPS driver controller 2.8.0

Many thanks for your help.
Bests regards.

[jimklimov]

Hello, that rings a bell... Just in case: can you re-verify with current NUT code base - see https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests about building and testing from the build workspace, to check if this was not resolved in later releases (or upcoming 2.8.3)?

[jimklimov]

Also, what was this phrase supposed to mean? :)

the output voltage is added to to the default.output.voltage.nominal

Did you have a setting in ups.conf on 2.7.4 that reads e.g. default.output.voltage.nominal = 230 which you do not have in 2.8.0 ups.conf?

FWIW, the default.* settings initialize NUT readings until a value is served by the device (if ever); the override.* settings get it to ignore readings from lying devices and always report what you told it to.

[jimklimov]

And also, "nominal" is what the device (input, output, battery...) is rated for. It is not a momentary reading. Internally, devices often serve them with different precision, e.g. battery.voltage.nominal may be an integer "12" and battery.voltage is a floating-point with 6-7 digit precision (formally, one or two digits populated after the dot is more likely).

[murdock62]

Hello Jim and many thanks for your fast response.
And sorry for my bad english !

Also, what was this phrase supposed to mean? :)

the output voltage is added to to the default.output.voltage.nominal #

Yes, I realize this sentence is quite obscure. It was late, and English is not my "native" language, so I wasn't very clear.

I meant that with 2.7.4 initially I had the same problem as with 2.8.0 (i.e. an output voltage of a few volts.)
But after adding default.output.voltage.nominal = 230 in ups.conf the output value was correct (around 230 to 235V).
The driver adds the y value to the output voltage it reads from the UPS and returns this addition, which is completely consistent with reality.
But with 2.8.0, whether default.output.voltage.nominal = 230 is present in ups.conf or not, the output voltage remains at only a few volts. It no longer seems to perform the addition.

And also, "nominal" is what the device (input, output, battery...) is rated for. It is not a momentary reading. Internally, devices often serve them with different precision, e.g. battery.voltage.nominal may be an integer "12" and battery.voltage is a floating-point with 6-7 digit precision (formally, one or two digits populated after the dot is more likely).

Hmmm if I understand your suggestion correctly you would mean that since I am providing an integer value as a nominal value and the output
value read by the driver is probably a decimal there would potentially be a cast issue when adding ?

However, I confirm that I understood correctly that the "nominal" value was a reference value defined by the manufacturer to indicate the expected
output voltage by default. This is why the inverter only provides a sort of offset from this voltage and the sum of the two gives the actual output voltage.

I'll try to provide the nominal voltage with a decimal value. I don't have much faith in it, but it's important to try everything.

Hello, that rings a bell... Just in case: can you re-verify with current NUT code base - see https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests about building and testing from the build workspace, to check if this was not resolved in later releases (or upcoming 2.8.3)?

I'll try to find some time tonight or tomorrow night to do the test. Unfortunately, I'm working on a C# project for work, and like everyone else, I don't have time for my personal projects. But I'll do it as quickly as possible and keep you posted.

Thank you again for your work, your speed, and your kindness.
(And sorry again for my poor English!)

Best regards.

[jimklimov]

Interesting point about offsets, but at least in usbhid-ups the devices are expected to report complete values in protocol queries.

So there are two separate readings for everything significant - a more or less hardcoded (in firmware) nominal value for that reading, and a variable momentary value. There were many problems addressed in and since NUT v2.8.0 about devices that do not correctly encode USB data. Someone did not read the spec and bits are wrong. NUT v2.7.4 and before turned a blind eye, v2.8.0 did not, and later releases began adding fix-up methods to deliberately correct known issues on known device models rather than trusting any garbage that comes in. That's why I hope current NUT code base has that fixed (or we would discover it is a new case different from those seen before).