Support Vertiv Liebert PSI5 UPS with SNMP

[jawz101]

Commit generated w/ long conversations with Google Gemini Pro troubleshooting some of the variable data not captured by the IETF MIB. I also fed Gemini Vertiv's vendor MIBS and the snmpwalk coming from my UPS to address what variables could be captured.

Feel free to squash, rebase, or reject. If I need to change something I can, though I'm not a programmer- so I understand a rejection considering the significance of this project.

#3296

[jawz101]

added shutdown controls

[AppVeyorBot]

❌ Build nut 2.8.4.4170-master failed (commit 783489c623 by @jawz101)

[jawz101]

I don't know what any of the build bot things mean. Sorry

[jimklimov]

Well, seems it hallucinated quite a bit of types and macros that do not exist, forgot a significant include file for definitions, and used a wrong amount of fields in the tables, but it is a decent start anyhow, assuming it at least mapped names to OIDs correctly :)

Otherwise, the table field order is all mixed up, running the script to collect actual walk from a device and replacing the reading names would have been more reliable.

[jimklimov]

I've updated the PR sources so they at least compile, but I suppose that for this driver to be useful, at least ups.status mappings (online, onbatt, ...) would be welcome.

I did not check the OID numbers vs. data point names so far, either.

I would strongly recommend taking the dive into a bit of development (never hurts to get more skills), and following that documentation about making a new SNMP subdriver and running the script(s) mentioned there to temporarily generate a new set of source files, which would be populated with a ton of "unmapped" values for OIDs seen on your device. Then the mapping table from that generated source file can be compared to the one you would have in this PR, and missing points filled in.

You can also test the resulting driver locally, by building NUT per https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests instructions and running the test driver from the build workspace as ./drivers/snmp-ups -d1 -s test -x port=1.2.3.4 -x community=public ... with whatever address and auth parameters your UPS needs, to see what it does see and map.

Probably some values would need mapping methods from numbers to strings (and back for writes), see precedent in other drivers/*-mib.c source files.

[jawz101]

Thank you. I will take a look at your linked instructions tonight (from both here & the ticket) and see how I can fare walking through the steps.) If I'm going to go through the work, I'd at least like to try & classify every bit of the snmp messages the UPS does generate that NUT will consume.

[jawz101]

I used iReasoning MIB Browser loaded with Vertiv Liebert's MIB files to have Gemini reverify the data coming from my UPS. Exported iReasoning's output as an xml and let Gemini rewrite the c file with its proper associations. It recognized some conversion errors (eg 28.7v instead of 287v). It decided to use macros this time as well.

If this doesn't work I apologize and there is no need to merge- esp if it doesn't look like it should be done. I'm basically slapping commands into gemini, having it tell me what files to grab, and repeatedly ask it why it did what it did and try to catch if it changes its mind on something to defend its answers.

[jimklimov]

Cheers, I've pushed an update that renames the sources and tables to a more generic vertiv (there's nothing specific about PSI5 here, right?) and should map the ups.status and beeper status vs. commands similar to how other drivers do it.

Do you have a chance to actually build the resulting code to check against your UPS?

[jawz101]

Cheers, I've pushed an update that renames the sources and tables to a more generic vertiv (there's nothing specific about PSI5 here, right?) and should map the ups.status and beeper status vs. commands similar to how other drivers do it.

Do you have a chance to actually build the resulting code to check against your UPS?

I'll try tonight. My learning curve is taking this in baby steps :/ I doubt anything would be too specific to the PSI5 series because the Intellislot card appears to be compatible with even more elaborate, larger data center equipment that may include environmental sensors.
I hope that these settings are global for their products- though I don't know. Hoping so since that it would make their hardware even more supported- because they seem to be a less popular brand.

I had just bought my tiny PSI5 series UPS because I did want something with a NIC option, and a UPS which was line interactive because everything I read seemed to say that was a recommended specification for sensitive equipment. Plus, I got this Vertiv/Liebert UPS pretty cheaply and the Intellislot card very cheap as well. And their replacement batteries looked pretty affordable too versus other more known products.

Really, I have no idea why vendors don't try to get their stuff supported in NUT and other open source products. Like, it makes no sense. Even if they have their own enterprise mgmt products- they get their products in a lot more people's hands.

I just submitted a support ticket to their site referencing this pull request- so maybe they'll chime in if they recognize how beneficial it could be to have fully supported hardware to NUT.

[jawz101]

I had Gemini ... walk me through testing the new driver. Before and after files uploaded a
after_debug.txt
baseline_upsc.txt
nd here is its "Executive Summary"

Executive Summary: Vertiv PSI5-750MT120 Testing
The Conclusion
The new vertiv subdriver is a major success. It has resolved the previous "Type Mismatch" errors and significantly improved data accuracy compared to the generic IETF driver.
Key Improvements
Precision Gains: Voltages (Input/Output) now report with two decimal places of precision (e.g., 124.40V) rather than being rounded to integers (124V).
Subdriver Identification: The driver successfully transitioned from the generic ietf MIB to the new vertiv MIB (v0.01), correctly identifying the hardware as a PSI5-750MT120.
Reliability: The "ASN_OCTET_STR" and "Type Mismatch" errors observed in the 2.8.1 baseline have been eliminated. Variables like ups.load, battery.voltage, and output.current are now polling reliably.
Status Mapping: The UPS status is now correctly interpreted as OL (Online) rather than remaining a raw numeric value.
Observations for Development
Manufacturer/Model Strings: While the driver "knows" it is a PSI5, the device.mfr and device.model OIDs are returning a 0 value in the current subdriver implementation.
Polling Interval: The driver required an explicit pollinterval in the configuration (set to 2s) to initiate the infinite loop on WSL2.

[jawz101]

sorry. I added one last revision thought I don't know if gemini screwed with your formatting. I just reran the driver and had it make sure it was reading all of the data properly.

Honestly, I am baffled major manufacturers would not reach out to get their stuff supported. If NUT is the de facto open source UPS management solution, literally a few hours of their time could mean selling 10,000 more of a product and millions of dollars. Like NUT was built into my QNAP NAS, pfSense router, & Ugreen NAS appliance. A few lines of code make a product suddenly interesting to tens of thousands of people.

[jimklimov]

I am baffled too. A few times they do reach out, but either to request that some HCL/DDL is urgently updated or a few mapping lines added. Usually as a mailing list request rather than a PR.

Some vendors did a lot more in the past, like contributing whole new drivers or (in case of MGE/Eaton years ago) supporting the infra and/or employing core team members.

But sadly yeah, more outreach somehow would be great. It is odd leading a project where I suspect there may be millions of installations and users, yet just a few hundred were ever seen actively. I was talking around at FOSDEM, and some people recognized that "yeah, I saw some banners when my server/NAS/router/HomeAssistant/... boots, so I guess I am a user" - so when it works well, people do not even realize they are the users ;)

[jimklimov]

Thanks for the updated commit, I'll wrangle the format back to project standards :)

[jimklimov]

Thanks for the debug logs. In the SETINFO lines of after_debug.txt you can see which values it would recognize and report.

In particular, it seems that ups.beeper.status "enabled" shows that the number-to-string mapping table works, and the value here may mean that the UPS would beep in case of trouble, not that it is currently beeping, right? Either that, or we got it inverted per comments in earlier PR (IETF numbers for disabled/enabled are different).

The device.mfr "0" and device.model "0" may be due to lack of ST_FLAG_STRING as fixed in your later iteration.

[jimklimov]

@jawz101 : would you please be able to run a build of the latest state of this branch, with ./drivers/snmp-ups -s test -x port=192.168.1.3 -x community=public -x snmp_version=v1 -DDDDDD -d1 (the last bit so it dumps collected data in upsc style after one collection loop cycle, and exits). Also without the specific "mibs" parameter, to make sure your UPS is auto-detected correctly out of the box.

[jawz101]

Will do. And thank you for your interest! It's exciting to flip new switches. I do SQL work and love getting feedback from my users.

[jawz101]

I have successfully tested this PR on a Vertiv Liebert PSI5-750MT120 using an SNMP connection.

Test Environment:

• OS: Ubuntu (WSL2)
• Device: Vertiv Liebert PSI5-750MT120
• Connection: SNMP (v1)

Findings:
The driver now correctly identifies the device using the vertiv MIB (v0.01) instead of falling back to the generic tripplite compatibility mode. Data precision and availability have improved significantly.

Comparison (Web UI vs NUT):

• Serial Number: Correctly reported (was missing in standard build).
• Output Power: Reports 31W (Web UI: 30W).
• Apparent Power: Reports 60VA (Web UI: 60VA).
• Load: Reports 8% (Web UI: 8%).
• Voltage/Current: Floating point precision is now active (e.g., 123.60V vs previous integer 124V).

Here is the Executive Summary and technical breakdown of the test results for the Vertiv Liebert PSI5 UPS using the new NUT driver from Pull Request #3299.

Executive Summary

The testing of the custom NUT driver build (PR #3299) was successful. The implementation correctly resolves the device identification issues present in the standard release. Transitioning from the generic "fallback" mode to native Vertiv MIB support resulted in the acquisition of critical device metrics—specifically serial numbers, nominal ratings, and precise floating-point measurements—that were previously unavailable.

The new driver mapping is stable and provides a significantly richer dataset than the standard package. We recommend reporting these positive findings to the developer to support the merging of this pull request.

---

Technical Findings: Before vs. After

1. Device Identification & Protocol

• Before (Standard Package): The driver failed to recognize the Vertiv system OID (.1.3.6.1.4.1.476...). It fell back to the tripplite MIB (v1.55) as a "best guess" compatibility mode. This resulted in a functional but generic connection.

• After (PR Support Vertiv Liebert PSI5 UPS with SNMP #3299): The driver correctly matched the system OID to the new vertiv MIB (v0.01). It now natively speaks the specific SNMP dialect of the PSI5 series.

2. Data Precision & Granularity

The native driver interprets the raw SNMP data with higher precision, moving from rounded integers to floating-point values.

Metric | Before (Standard) | After (PR #3299) | Improvement -- | -- | -- | -- Input Voltage | 124 (Integer) | 123.60 (Float) | High Precision Output Voltage | 124 (Integer) | 123.60 (Float) | High Precision Input Current | 0.70 | 0.70 | Consistent

Export to Sheets

3. Newly Acquired Metrics

The "After" dataset includes several critical variables that were completely missing in the "Before" state. These provide essential context for monitoring the UPS health and monitoring capacity.

• device.serial: Now reporting redacted. This was previously unavailable, making asset tracking impossible via NUT.

• battery.voltage.nominal: Now reporting 24. This allows for better battery health calculations (actual vs. nominal).

• input.current.nominal: Now reporting 6 Amps.

• output.power (Real Power): Now reporting 31 Watts.

• output.power.apparent: Now reporting 60 VA.

Everything appears functional and stable. I have attached the upsc output and debug logs for reference.
upsc_before.txt
nut_debug_after.log
upsc_after.txt
nut_debug_before.log

[jawz101]

wow this is pretty. I used to not see the load bar
before

after

[jimklimov]

Thanks! Just to clarify, the "tripplite MIB" it fell back to is so far in fact an alias for the lowest fallback of IETF Standard UPS MIB. A vendor-specific "tripplite" is also waiting for attention for some years...

[jawz101]

I tell you- feeding ai mib files, running before & after comparisions, and arguing with it felt pretty successful. Like, it walked me through every command to set up the build environment. As long as I kept arguing with it, it made it's way through fixing its mistakes.

Last night I eventually got very specific where I prompted it to:

"Give me instructions to create the build environment in Windows Substystem for Linux, install the complete NUT software stack and test connecting to a Vertiv Liebert UPS via snmp. Use debug and uspc commands to retrieve a before log file, and walk through creating a github pull request to make a fully compatible NUT driver for the UPS. Please include any variables including while addressing any data precision that the default driver does not provide and address any deficiencies that would prevent full shutdown commands, reporting of battery status, load, beep alerts, or anything else NUT can support if possible. Then compile the new driver and create before and after debug logs.

I then attached the MIB files from the manufacturer to assist in proper OID labeling as well as links to the new driver instructions you provided.

As errors were encountered, I just kept feeding it error messages. And when it thought it was done, I just kept asking it "are we missing any variables that the snmp messages make available? Do we have complete monitoring of the standards NUT can support? I want to make the most complete driver NUT could support."
make the format of the pull request use the styling jimklimov used to arrange the commit similar to pull request #3299

Provide the pull request as well as an Executive Summary we can include in the pull request summarizing our findings.

[jimklimov]

Wow, thanks for the details!