networkupstools / nut

The Network UPS Tools repository. UPS management protocol Informational RFC 9271 published by IETF at https://www.rfc-editor.org/info/rfc9271 Please star NUT on GitHub, this helps with sponsorships!
https://networkupstools.org/
Other
1.92k stars 346 forks source link

[HCL] GE Critical Power - VH Series UL - supported by snmp-ups (mib = ietf) #2429

Open PatrickDittrich opened 4 months ago

PatrickDittrich commented 4 months ago

I am using NUT 2.8.2 on Windows with the following UPS: GE Critical Power, Model VH2000 UL

When I have mibs = auto in ups.conf I receive the following message when running .\nut.exe -N

No matching MIB found for sysOID '.1.3.6.1.2.1.33.2'!
Please report it to NUT developers, with an 'upsc' output for your device.
Going back to the classic MIB detection method.

In the HCL list, there are two devices listed under "GE Digital Energy". "GE Digital Energy" "ups" "2" "EP Series" "USB" "blazer_usb" "GE Digital Energy" "ups" "2" "GT Series 1000/1500/2000/3000 VA Rack/Tower" "UL-version" "blazer_ser"

GE Digital Energy was rebranded to GE Critical Power and then later acquired by ABB https://electrification.us.abb.com/products/uninterruptible-power-supplies-ups/vh-series-ups-ul-listed-700va-3kva-previous-generation

General information about the UPS GE VH Series UPS: https://library.industrialsolutions.abb.com/publibrary/checkout/GEA-D1057?TNR=Brochures%7CGEA-D1057%7CPDF&filename=VCL-UL-VH-UL-brochure-GEA-D1057-GB-y15m12d09-mr.pdf Technical Data Sheet: https://library.industrialsolutions.abb.com/publibrary/checkout/OPM_VHU0K73K0XU?TNR=Installation%20and%20Instruction%7COPM_VHU0K73K0XU%7CPDF&filename=GE_UPS_OPM_VHU_0K7_3K0_XUS_V011.pdf SNMP Card: https://library.industrialsolutions.abb.com/publibrary/checkout/GE_UPS_OPM_CNT_SNM_BAS_CRD_1GB_V022?TNR=Software%7CGE_UPS_OPM_CNT_SNM_BAS_CRD_1GB_V022%7CPDF&filename=GE_UPS_OPM_CNT_SNM_BAS_CRD_1GB_V022.pdf MIB file: https://www.circitor.fr/Mibs/Mib/G/GESINGLEUPS-MIB.mib

I have successfully tested a shutdown sequence with the UPS.

upsc output with mibs = ietf

PS C:\Program Files (x86)\NUT\bin> .\upsc.exe -V
Network UPS Tools upsc 2.8.2-6-g3656fde64

PS C:\Program Files (x86)\NUT\bin> .\upsc.exe testlab_ups
battery.charge: 100
battery.charge.low: 30
battery.current: 0
battery.runtime: 59280
battery.runtime.low: 600
battery.temperature: 60
battery.voltage: 79.70
device.contact: TestLab ABC 012 345 67 89
device.description: GEDE UPS SNMP/Web Interface
device.location: -TESTLAB-
device.mfr: GE
device.model: VH Series
device.type: ups
driver.debug: 6
driver.flag.allow_killpower: 0
driver.flag.ignorelb: enabled
driver.name: snmp-ups
driver.parameter.mibs: ietf
driver.parameter.override.battery.charge.low: 30
driver.parameter.override.battery.runtime.low: 600
driver.parameter.pollinterval: 2
driver.parameter.port: ups.testlab.local
driver.parameter.snmp_version: v1
driver.parameter.synchronous: auto
driver.state: quiet
driver.version: 2.8.2-6-g3656fde64
driver.version.data: ietf MIB 1.55
driver.version.internal: 1.31
input.bypass.current: 0
input.bypass.frequency: 50
input.bypass.L1-N.voltage: 238
input.bypass.L1.current: 0
input.bypass.L1.realpower: 0
input.bypass.phases: 1
input.bypass.realpower: 0
input.bypass.voltage: 238
input.current: 0.10
input.frequency: 50
input.frequency.nominal: 50
input.phases: 1
input.realpower: 40
input.transfer.high: 264
input.transfer.low: 204
input.voltage: 238
input.voltage.nominal: 240
output.current: 0
output.frequency: 50
output.frequency.nominal: 50
output.phases: 1
output.power.nominal: 2000
output.realpower: 0
output.realpower.nominal: 1400
output.voltage: 240
output.voltage.nominal: 240
ups.beeper.status: muted
ups.firmware: V6R14
ups.firmware.aux: version: 6.30E, Apr 18, 2007
ups.load: 0
ups.mfr: GE
ups.model: VH Series
ups.start.auto: yes
ups.status: OL
ups.test.result: no test initiated
ups.timer.reboot: -1
ups.timer.shutdown: -1
ups.timer.start: -1

upscmd output with mibs = ietf

PS C:\Program Files (x86)\NUT\bin> .\upscmd.exe -l testlab_ups
Instant commands supported on UPS [testlab_ups]:

beeper.disable - Disable the UPS beeper
beeper.enable - Enable the UPS beeper
beeper.mute - Temporarily mute the UPS beeper
driver.killpower - Tell the driver daemon to initiate UPS shutdown; should be unlocked with driver.flag.allow_killpower option or variable setting
load.off - Turn off the load immediately
load.on - Turn on the load immediately
test.battery.start - Start a battery test
test.battery.start.deep - Start a deep battery test
test.battery.start.quick - Start a quick battery test
test.battery.stop - Stop the battery test

upsrw output with mibs = ietf

PS C:\Program Files (x86)\NUT\bin> .\upsrw.exe -l testlab_ups
[device.contact]
Description unavailable
Type: STRING
Maximum length: 128
Value: TestLab ABC 012 345 67 89

[device.description]
Description unavailable
Type: STRING
Maximum length: 128
Value: GEDE UPS SNMP/Web Interface

[device.location]
Description unavailable
Type: STRING
Maximum length: 128
Value: -TESTLAB-

[driver.debug]
Current debug verbosity level of the driver program
Type: NUMBER
Value: 6

[driver.flag.allow_killpower]
Safety flip-switch to allow the driver daemon to send UPS shutdown command (accessible via driver.killpower)
Type: NUMBER
Value: 0

[ups.timer.reboot]
Time before the load will be rebooted (seconds)
Type: STRING
Maximum length: 8
Value: -1

[ups.timer.shutdown]
Time before the load will be shutdown (seconds)
Type: STRING
Maximum length: 8
Value: -1

[ups.timer.start]
Time before the load will be started (seconds)
Type: STRING
Maximum length: 8
Value: -1
jimklimov commented 4 months ago

Thanks a lot for this report, more so with the twist of running on Windows.

Did you build your own, or use the tarballs auto-made by NUT recipes on AppVeyor CI?

Got any hints to share for others who would endeavour with the revived NUT for Windows effort - e.g. how did you register the service(s) so an OS shutdown is actually handled?

Did any of the known-incomplete bits (quite a long list can be seen in the project) bite you in practice of this use-case?

Also, I'd expect the default mibs=auto to maybe complain but eventually find a suitable MIB, e.g. ietf as the last fallback. Did that also work for you, was some mapping discovered despite the "noise"?

IiRC the message itself is about trying a query for SysOID (in the IETF namespace) for a redirection to vendor-defined data (if any), and that OID was not served.

PatrickDittrich commented 4 months ago

I am using the executables from the AppVeyor CI generated 7z artifact (https://ci.appveyor.com/project/nut-travis/nut/history) and wrote a PowerShell script to register nut.exe as a Windows service. Beside the NUT executables I also needed the openSSL binaries (openssl-1.1.1w-win64.zip from https://wiki.overbyte.eu/wiki/index.php/ICS_Download) to be present in the sbin folder and had to copy everything from sbin to bin as well. I can document this under https://github.com/networkupstools/nut/wiki/NUT-for-Windows if you want.

I was not hindered by any of the known-incomplete bits, but the information on running it on Windows is quite scattered around. Also, there are a few things that changed between the old 2.6.5 Windows release and now. For example I needed to run the command shell as admin in order to be able to create the \\.\pipe\snmp-ups-* pipe (was working as normal user under 2.6.5). Also the binaries are quite big (each is around 5-60 MB) resulting in more than 1 GB used for NUT. Further I am unable to run a configuration with snmp_version = v1 and snmp_version = v3 at the same time as there seams to be different versions of openSSL used resulting in a conflict (I needed also to log out and back in after a switch from one version to the other).

When using the default mibs = auto, NUT was settling down to tripplite, so I set it to mibs = ietf myself. I guess it would work as well as it is state here: https://networkupstools.org/docs/man/snmp-ups.html TrippLite UPSes; at this time this is the IETF MIB mapping with just the Tripplite entry point OID to verify the device vendor.

About the OID, see http://oid-info.com/cgi-bin/display?oid=1.3.6.1.4.1.818.1.1&a=display and chapter "4 SNMP AGENT" of the SNMP Card manual https://library.industrialsolutions.abb.com/publibrary/checkout/GE_UPS_OPM_CNT_SNM_BAS_CRD_1GB_V022?TNR=Software%7CGE_UPS_OPM_CNT_SNM_BAS_CRD_1GB_V022%7CPDF&filename=GE_UPS_OPM_CNT_SNM_BAS_CRD_1GB_V022.pdf#page=38. I can try to get a SnmpWalk output next week.

jimklimov commented 4 months ago

Thanks for the insights! Probably, a practical chapter in the Wiki (or a new page) would be useful - thanks in advance :)

As for service registration, allegedly the bin/nut.exe program (coming from scripts/Windows/wininit.c in sources) should handle the service registration and un-registration and start-up. At least, so the sources say. Not sure quickly whether/how well it is documented. Some command-line help/usage is sorely missing, made a bit of sense of it from sources though - and found that my attempts to start did log Event Viewer messages :

...
The following information was included with the event: 

StartServiceCtrlDispatcher failed : exiting, this is a Windows service which can't be run as a regular application by default. 
Try -N to start it as a regular application.
...

No comments at the moment about pipe creation - not sure if it really requires privileges or something else was at play... I can only guess that the driver running as a Windows service would be sufficiently privileged. Otherwise, the Windows-side code of NUT did not change very much as part of the revival from 2.6.5-based branch. Was your earlier easier experience with same version/instance of Windows itself - maybe it is the OS that changed in some important aspect?

Regarding OpenSSL libraries - were there any particular complaints? I see that the libssl* and libcrypto* DLLs are present in the tarballed bin directory, so should have been found by the driver and tools. At least, if the exact file naming fits the expectations. If there is indeed some problem with the bundle, it would be great to find a way to reproduce it (like, were you in the relevant directory as "current working directory" when running the program, or did you use relative filenames - stuff like that might be important).

In fact, did the snmp-ups driver complain, or was it the nut-scanner tool (it has a separate routine for dynamic discovery and loading of shared objects/DLLs - and maybe it tries some wrong wordings)?

Finally, re-checked the note about file sizes, and agree that they seem excessive. At the moment (per share/config.nut_report_feature.log file) I can guess this is due to debug build being in effect for CI testing builds (so added symbols, little optimization). Allegedly this can help troubleshoot deployments made from the tarballs on early-bird systems like yours :D