CyberPower, transfer.high and transfer.low Both Zero

[arrmo]

Hi,

I have several CyberPower UPS's, and they all work fine ... and so does my new one (SX650G), with the slight exception that both input.transfer.high and input.transfer.low are zero. I'm thinking this is perhaps driver related (but I could be wrong!). I did try setting the values, using upsrw ... and the response is "OK", but they are not set. I did confirm with CyberPower, these values are fixed and not changeable.

This shows up in the cgi-bin programs, as it uses them to flag the input voltage ... which is fine, but is being shows in red as a result.

Thoughts?

Thanks!

[clepple]

CyberPower has had many issues with their HID descriptors, so there is a chance that the high and low transfer numbers are divided by 1,000,000, or something similar.

Can you stop the driver, and restart it with several -D options? (The exact command line will depend on your distribution, but you should see it in the ps listing before stopping it.)

If you don't want to debug this, you could also set them manually using the override.input.transfer.* syntax in ups.conf: http://networkupstools.org/docs/man/ups.conf.html (which should fix the CGI display)

[arrmo]

Yep, I see it there ... data below (and it's all 0). For whatever reason, not reporting back correctly (could be NUT, could be the UPS itself).

0.092741     Path: UPS.Input.Voltage, Type: Feature, ReportID: 0x0f, Offset: 0, Size: 16, Value: 121
0.092814     Path: UPS.Input.LowVoltageTransfer, Type: Feature, ReportID: 0x10, Offset: 0, Size: 16, Value: 0
0.092879     Path: UPS.Input.HighVoltageTransfer, Type: Feature, ReportID: 0x10, Offset: 16, Size: 16, Value: 0
0.092952     Path: UPS.Output.Voltage, Type: Feature, ReportID: 0x12, Offset: 0, Size: 16, Value: 122

Your fix works awesome though - thanks so much for the pointer!

[clepple]

The Value: 0 part is a little misleading. The raw value might be 120, but after being divided by a large number and converted to an int (newer versions of NUT print it as floating point in the debug messages, IIRC), it would still show as zero here. If you add a few more "-D" flags, you will see the raw bytes.

Actually, if you don't mind, could you run the driver in debug mode for ~ 30 seconds, and post the output as an attachment here? If you want to mask out the serial number, it probably shows up about 2-3 times. Can't promise when we'll get time to fix the underlying problem with the CPS firmware, but this will help. Feel free to close this ticket if the override fix is sufficient.

[arrmo]

Sure, NP at all - glad to help out if I can! File is attached, just yell if I can do anything else.
sx650g.txt

[clepple]

So many chores to do, yet this is far more interesting :-)

   0.066143	Report[get]: (5 bytes) => 10 60 00 8c 00
   0.066183	Path: UPS.Input.LowVoltageTransfer, Type: Feature, ReportID: 0x10, Offset: 0, Size: 16, Value: 0
   0.066209	Report[buf]: (5 bytes) => 10 60 00 8c 00
   0.066236	Path: UPS.Input.HighVoltageTransfer, Type: Feature, ReportID: 0x10, Offset: 16, Size: 16, Value: 0

Looks like the low/high transfer limits are 96V (0x60) and 140V (0x8c). I'll check for the scale factor later, but this looks consistent with other CPS HID issues.

[arrmo]

LMAO - I hear you there! Yep, and those values match to what the gent from CyberPower told me. So seems it is reporting it correctly.

Thanks!

[jimklimov]

PR #2718 is presumed to have fixed the broken CPS input/output voltage reports mentioned in this issue (although the ones posted here seemed to be good already).

PR #1245 is presumed to have fixed the broken CPS transfer voltage reports discussed in this issue, at least the high one. Both values were reported reasonable in #1512 and #2718 testing, though possibly on models too different to this issue?...