CyberPower PR1500LCDN (RMCARD205) metrics incorrect

[ttmcmurry]

Please make sure to fill out this form completely, and attach your program logs (set to Debug setting). You can delete this line.

WinNUT Version: 2.2.8719.24624
Windows OS Version: Server 2019 Datacenter

Describe the bug
Some metrics are incorrect. These values cannot be calibrated under Settings. The data is not UPS-specific as much as it is NMC-specific - the RMCARD205 is used in many network-capable CyberPower UPS systems. See images below.

Voltage Input: WinNUT reports 220v all the time, should be closer to 120, and specifically 115.7 when the screenshot was taken
Voltage Output: WinNUT reports 220v all the time, should be closer to 120, and specifically 115.7 when the screenshot was taken
UPS Load: Shows no wattage load (zero watts), load should have been 240 watts when the screenshot was taken
UPS Battery Low: Always stays on

To Reproduce
Steps to reproduce the behavior:

1. Connect to a CyberPower PR1500LCDN
2. Observe the values, they are incorrectly measured

Expected behavior
The measured values should make sense.

Additional context
SNMPWalk below. I removed line items related to the network interface, for brevity. After downloading and reviewing the CPS 2.11 MIB, it does not explain the 2.33.1 values so there's not an easily visible means to determine their value past the obvious ones with text strings. I have filed a ticket with CyberPower to see if they could explain the 2.33.1 OID tree values.

SNMPWalk of the NMC
SNMPv2-MIB::sysDescr.0 = STRING: UPS SNMP Card
SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.3808.1.1.1
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (122800) 0:20:28.00
SNMPv2-MIB::sysContact.0 = STRING: (redacted)
SNMPv2-MIB::sysName.0 = STRING: pf1500lcdn
SNMPv2-MIB::sysLocation.0 = STRING: (redacted)
SNMPv2-MIB::sysServices.0 = INTEGER: 72
....
SNMPv2-SMI::mib-2.33.1.1.1.0 = STRING: "CPS"
SNMPv2-SMI::mib-2.33.1.1.2.0 = STRING: "PR1500LCD"
SNMPv2-SMI::mib-2.33.1.1.3.0 = STRING: "CR01203J9O1"
SNMPv2-SMI::mib-2.33.1.1.5.0 = STRING: "pf1500lcdn"
SNMPv2-SMI::mib-2.33.1.2.1.0 = INTEGER: 2
SNMPv2-SMI::mib-2.33.1.2.2.0 = INTEGER: 0
SNMPv2-SMI::mib-2.33.1.2.3.0 = INTEGER: 22
SNMPv2-SMI::mib-2.33.1.2.4.0 = INTEGER: 25
SNMPv2-SMI::mib-2.33.1.2.5.0 = INTEGER: 242
SNMPv2-SMI::mib-2.33.1.2.7.0 = INTEGER: 40
SNMPv2-SMI::mib-2.33.1.3.2.0 = INTEGER: 1
SNMPv2-SMI::mib-2.33.1.3.3.1.1.1 = INTEGER: 1
SNMPv2-SMI::mib-2.33.1.3.3.1.2.1 = INTEGER: 600
SNMPv2-SMI::mib-2.33.1.3.3.1.3.1 = INTEGER: 115
SNMPv2-SMI::mib-2.33.1.3.3.1.4.1 = INTEGER: 0
SNMPv2-SMI::mib-2.33.1.3.3.1.5.1 = INTEGER: 0
SNMPv2-SMI::mib-2.33.1.4.1.0 = INTEGER: 3
SNMPv2-SMI::mib-2.33.1.4.2.0 = INTEGER: 600
SNMPv2-SMI::mib-2.33.1.4.3.0 = INTEGER: 1
SNMPv2-SMI::mib-2.33.1.4.4.1.1.1 = INTEGER: 1
SNMPv2-SMI::mib-2.33.1.4.4.1.2.1 = INTEGER: 115
SNMPv2-SMI::mib-2.33.1.4.4.1.3.1 = INTEGER: 0
SNMPv2-SMI::mib-2.33.1.4.4.1.4.1 = INTEGER: 0
SNMPv2-SMI::mib-2.33.1.4.4.1.5.1 = INTEGER: 15
SNMPv2-SMI::mib-2.33.1.5.1.0 = INTEGER: 600
SNMPv2-SMI::mib-2.33.1.5.2.0 = INTEGER: 1
SNMPv2-SMI::mib-2.33.1.5.3.1.1.1 = INTEGER: 1
SNMPv2-SMI::mib-2.33.1.5.3.1.2.1 = INTEGER: 0
SNMPv2-SMI::mib-2.33.1.5.3.1.3.1 = INTEGER: 0
SNMPv2-SMI::mib-2.33.1.5.3.1.4.1 = INTEGER: 0
SNMPv2-SMI::mib-2.33.1.6.1.0 = Gauge32: 0
SNMPv2-SMI::mib-2.33.1.7.1.0 = OID: SNMPv2-SMI::mib-2.33.1.7.7.4
SNMPv2-SMI::mib-2.33.1.7.2.0 = INTEGER: 0
SNMPv2-SMI::mib-2.33.1.7.3.0 = INTEGER: 1
SNMPv2-SMI::mib-2.33.1.7.4.0 = ""
SNMPv2-SMI::mib-2.33.1.7.5.0 = Timeticks: (0) 0:00:00.00
SNMPv2-SMI::mib-2.33.1.7.6.0 = INTEGER: 0
SNMPv2-SMI::mib-2.33.1.8.1.0 = INTEGER: 2
SNMPv2-SMI::mib-2.33.1.8.2.0 = INTEGER: -1
SNMPv2-SMI::mib-2.33.1.8.3.0 = INTEGER: -1
SNMPv2-SMI::mib-2.33.1.8.4.0 = INTEGER: -1
SNMPv2-SMI::mib-2.33.1.8.5.0 = INTEGER: 2
SNMPv2-SMI::mib-2.33.1.9.2.0 = INTEGER: 600
SNMPv2-SMI::mib-2.33.1.9.3.0 = INTEGER: 115
SNMPv2-SMI::mib-2.33.1.9.4.0 = INTEGER: 600
SNMPv2-SMI::mib-2.33.1.9.5.0 = INTEGER: 0
SNMPv2-SMI::mib-2.33.1.9.6.0 = INTEGER: 0
SNMPv2-SMI::mib-2.33.1.9.8.0 = INTEGER: 1
SNMPv2-SMI::mib-2.33.1.9.9.0 = INTEGER: 106
SNMPv2-SMI::mib-2.33.1.9.10.0 = INTEGER: 130

[gbakeman]

Hi @ttmcmurry ,

I'm not very familiar with SNMP or network management cards, so unfortunately the output here isn't terribly useful to me. WinNUT is talking directly to a NUT server which is then interfacing with some kind of serial management device on the UPS (like your NMC probably), so to better understand what's going on, we need to see what the NUT server is reporting to WinNUT. For that, you can find a variable explorer and output window by going to File -> UPS Variable. Feel free to walk through the tree yourself if you want to look, but otherwise please copy and paste the output into your issue here.

Even before that happens, I think what's going on here is related to #116. WinNUT will substitute in a default value when it receives an error while querying for a specific UPS variable from the NUT server. Since the program is by default calibrated for non-North America electrical grids, I think that's why you're seeing 220V reports. It is strange that some values appear to be legitimate, such as the frequency and battery voltage. To explain why you're seeing so many erroneous values, and why other devices seem to be working fine for you, I think the NUT server is the culprit. I've infrequently seen the NUT server enter into an error state and require being killed and restarted to begin updating values correctly from the UPS.

After you've had a chance to grab the variable output (uploading most recent WinNUT log file would be helpful, too), I think you should try rebooting the NUT daemon at the service you're connecting to and see if that doesn't resolve things. Thank you for writing this report!

[ttmcmurry]

Okay, I believe I follow you.

The culprit would likely be the Synology NUT implementation in DSM 7.2

When I list the variables, there are none for input and output voltages or load. Though I can't determine what "ups battery low" is mapped to. There doesn't seem to be a value that drives it in the UPS variables, yet it eventually cleared. I tried altering the min/max in calibration options, but that didn't trip the "battery low" indicator.

Perhaps if the NUT server isn't reporting those data elements, the UI is rendering some default value? Might it make sense if that happens, to grey out the indicators?

ups (CYBERPOWER/PR1500LCD/CR01203J9O1)
battery.charge (Description unavailable) : 61.00
battery.runtime (Description unavailable) : 3540.00
battery.runtime.elapsed (Description unavailable) : 0.00
battery.voltage (Description unavailable) : 25.80
device.mfr (Description unavailable) : CYBERPOWER
device.model (Description unavailable) : PR1500LCD
device.serial (Description unavailable) : PY7NS2000200
device.type (Description unavailable) : ups
driver.name (Description unavailable) : snmp-ups
driver.parameter.authProtocol (Description unavailable) : MD5
driver.parameter.mibs (Description unavailable) : auto
driver.parameter.pollinterval (Description unavailable) : 5
driver.parameter.port (Description unavailable) : 10.255.255.9
driver.parameter.privProtocol (Description unavailable) : DES
driver.parameter.secLevel (Description unavailable) : noAuthNoPriv
driver.parameter.snmp_version (Description unavailable) : v3
driver.parameter.synchronous (Description unavailable) : no
driver.version (Description unavailable) : DSM7-2-1-NewModel-repack-64570-230831
driver.version.data (Description unavailable) : cyberpower MIB 0.1
driver.version.internal (Description unavailable) : 0.97
ups.firmware (Description unavailable) : CR01203J9O1
ups.mfr (Description unavailable) : CYBERPOWER
ups.model (Description unavailable) : PR1500LCD
ups.serial (Description unavailable) : PY7NS2000200
ups.status (Description unavailable) : OL

[gbakeman]

The culprit would likely be the Synology NUT implementation in DSM 7.2

That sounds about right, Synology's NUT server seems to act the strangest.

When I list the variables, there are none for input and output voltages or load. Though I can't determine what "ups battery low" is mapped to. There doesn't seem to be a value that drives it in the UPS variables, yet it eventually cleared. I tried altering the min/max in calibration options, but that didn't trip the "battery low" indicator.

The indicator/status lights are driven purely by the ups.status variable, which provides one or more flags. The calibration tab controls the gauge displays, and perhaps a functionality or two of WinNUT.

Perhaps if the NUT server isn't reporting those data elements, the UI is rendering some default value? Might it make sense if that happens, to grey out the indicators?

That's exactly what's happening. I think your idea of greying out the appropriate gauge when a variable is unavailable is a great idea. I also want to leave an indicator on the gauge its self that tells the user what's wrong, although I think that may depend on some other structural changes I want to do.

Was this able to solve most of the issue for you, at least pending the previous issue for fixing variable errors?

[ttmcmurry]

That sounds about right, Synology's NUT server seems to act the strangest.

Don't get me started about Syno's NUT. I've opened a ticket to no avail, they have little interest in fixing it. This also raises an issue where the Syno sees a low battery flag, knows it's low battery, and in testing, the Syno did not shut down before battery hit zero percent. It's configured to shut down on low battery. I'll have to find another way, perhaps my own NUT server.

I think your idea of greying out the appropriate gauge when a variable is unavailable is a great idea. I also want to leave an indicator on the gauge its self that tells the user what's wrong, although I think that may depend on some other structural changes I want to do.

That seems like the best way to handle this. I like your idea of indicating why the panel would be greyed out.

Was this able to solve most of the issue for you, at least pending the previous issue for fixing variable errors?

Appreciate your time here. I'm resolved now.

[gbakeman]

Excellent, thank you for the feedback and information. I'm going to close this issue then, go ahead and follow #116 for updates regarding missing variable handling.