Tripplite Smart UPS: A Review

My experience with Tripplite Smart UPSes has not been very positive, yet I’m required to manage and monitor six of them to prop up our entire IT and broadcast infrastructure. I know these units are rather old, but I want to share my thoughts about them to demonstrate that the old tricks are often still the best tricks.

I’ve been operating Tripplite Smart UPSes for the last seven years. In general, I consider these devices to be reliable because they have never failed to deliver backup power when they were supposed to. If I could go back in time, though, I would never install these units again. Back in 2012, when I was tasked with replacing our aging APC UPSes, Tripplite offered competitive pricing and desirable features. I contemplated using newer APC units, but my budget couldn’t handle premium prices, so I bought what I could afford: Tripplite.

Over these last seven years, I’ve installed three different models of Tripplite Smart UPSes. Each has slightly different features but the overall functionality remains the same. The models I manage are:

  • One SMART1500RMXL – 1.5KVA
  • Four SMART2600RM2U – 2.6KVA
  • One SU8000RT4U – 8KVA (2x 4KVA)

For the first three years, I fought on and off with monitoring and data collection via the built-in USB port and Tripplite’s PowerAlert software. PowerAlert was supposed to provide all the management features I wanted (monitoring, alerting, scheduling, and accounting), but reality was a different story. The software was buggy at best and unusable at worst; not only was it bloated and written with Java 6, it crashed often and ultimately failed at providing notifications when things went wrong. What’s more, each UPS needed to be hardwired to a workstation that ran the PowerAlert service. For a rack full of UPSes, this wasn’t a scalable solution.

Things improved a little once I upgraded each UPS with an SNMPWebCard that provided a dedicated network interface. I connected these interfaces to an isolated VLAN reserved for necessary but insecure services. While still buggy, outdated, and under-powered, the WebCards offered a few more features I was looking forward to having:

  • Remote access via SSH
  • Remote syslog support
  • Remote administration via SNMP

SSH was the first of these to disappoint me. The service was considerably old as it only supported SHA1 key exchange, a deprecated and insecure hash. It also lacked public key authentication support, meaning I had to manage service account passwords instead of SSH keys. Definitely less than ideal, but better than nothing.

Next, I configured logging to our centralized syslog collector. Again, I was disappointed to find that logging worked unreliably. Some events, like UPS activation and failed battery tests, don’t always generate a log message. Occasionally, syslog breaks completely and spams the syslog server with garbage; the card must to be re-seated (effectively hard rebooting it) to restore operation. It didn’t take me long to abandon syslog completely and move on to SNMP.

The SNMPWebCard’s SNMP agent works fairly well to this day. Only MD5/DES auth/priv encryption is supported, but that’s still better than most SNMP agents I’ve worked with. The agent can be overwhelmed by too many SNMP requests, so care must be taken not to saturate its limit with frequent queries. Still, I can poll the devices periodically and reliably, making the SNMP implementation the best thing about these devices.

I was able to find Tripplite’s SNMP MIB files, so I built a list of OIDs that I might want to monitor:

SNMPv2-SMI::mib- Battery Status, 2 = Normal
SNMPv2-SMI::mib- on battery
SNMPv2-SMI::mib- Runtime remaining in minutes
SNMPv2-SMI::mib- Charge Remaining percent
SNMPv2-SMI::mib- Voltage (missing decimal after first digit)
SNMPv2-SMI::mib- Current
SNMPv2-SMI::mib- Temperature (C)
SNMPv2-SMI::mib- of Input Lines
SNMPv2-SMI::mib- Line X Index
SNMPv2-SMI::mib- Frequency (missing decimal after first digit) Line X
SNMPv2-SMI::mib- Voltage Line X
SNMPv2-SMI::mib- Current Line X
SNMPv2-SMI::mib- TruePower Line X
SNMPv2-SMI::mib- mode, 3 = Utility, 5 = On Battery
SNMPv2-SMI::mib- frequency (missing decimal after first digit)
SNMPv2-SMI::mib- of Output Lines
SNMPv2-SMI::mib- Line X Index
SNMPv2-SMI::mib- Voltage Line X
SNMPv2-SMI::mib- current (missing decimal after first digit) Line X
SNMPv2-SMI::mib- load percent Line X
SNMPv2-SMI::mib- present (1 = true, 0 = false)
SNMPv2-SMI::mib- input voltage
SNMPv2-SMI::mib- Audible Status (2 = audible)
SNMPv2-SMI::mib- Voltage Transfer Threshold
SNMPv2-SMI::mib- Voltage Transfer Threshold

Using this chart as a guide, I constructed some Nagios checks for UPS status and health. I defined two primary checks:

  • A “priority alert” check on the UPS “operating mode.” Anything aside from a value of “3” generates an alert, indicating the UPS is not on utility power, meaning the backup generator failed to activate and that intervention is required.
  • A “metrics only” check on several key indicators of UPS health: Alarm presence, Charge %, Load %, Temperature, Battery Health, and Battery Runtime. This check is used for troubleshooting; I get an overview of the health of the UPS by looking at the Nagios dashboard.

Thanks to the undying power of SNMP, these underwhelming units are still useful. I can reliably monitor them and leverage their solid power delivery while mostly sidestepping the poorly implemented features. Still, there are a few gotchas that make these UPSes a non-starter for any modern facility:

  • No IPv6 support
  • No modern SSH ciphers
  • Non-functioning web interface
  • Weak SNMP auth/priv algorithms

Still, I must admit that the most fundamental feature of these UPSes remains their only saving grace: they provide power when I need it. For plants on a shoestring budget, that’s probably good enough, provided there’s a well-designed infrastructure (VLANs, firewalls, monitoring) to prop up poorly designed devices.