search

nutdotnet / WinNUT-Client

WinForms-based client for monitoring your Uninterruptible Power Supply (UPS) connected to a Network UPS Tools (NUT) server.
GNU General Public License v3.0
186 stars 18 forks source link

CyberPower PR1500LCDN (RMCARD205) metrics incorrect #126

Closed ttmcmurry closed 6 months ago

ttmcmurry commented 6 months ago

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

image image

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 commented 6 months ago

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 https://github.com/nutdotnet/WinNUT-Client/issues/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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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.