[Nut-upsuser] Liebert GXT4

[Charles Lepple]

On Mar 3, 2021, at 7:43 AM, Matthew Rivett via Nut-upsuser <nut-upsuser at alioth-lists.debian.net> wrote:
> 
> Charles,
> 
> Being me I'd love to have all the data but that shouldn't be necessary.  :)

That's fair :-)

> What got me interested is that the frequency is shown on the UPS and I was curious what was going on when the power issues around President's Day.  I wondered if I could capture that output from the UPS.

The short answer is that there isn't anything that looks like low-hanging fruit for frequency. If an UPS includes a frequency Usage ID in its HID Report Descriptor, NUT can usually pick that up (even if it gets the value wrong), and I'm not seeing something that maps to input.frequency.

If you wanted to log values over time, there are a bunch of "UPS.PowerSummary.Undefined" lines, and the bytes before them are candidates for frequency.

Here's a simple example for a value that seems to be working:

   0.113694     [D3] Report[get]: (2 bytes) => 13 14
   0.113860     [D1] Path: UPS.PowerSummary.RemainingCapacityLimit, Type: Feature, ReportID: 0x13, Offset: 0, Size: 8, Value: 20

The first line with the hex bytes is the raw data coming back from the UPS. First byte (0x13) is the report ID, which you can see listed on the next line. The Path is the list of HID Usage IDs that are accumulated while NUT parses the Report Descriptor. They generally map 1:1 with NUT variables, so ...RemainingCapacityLimit is "battery.charge.low".

The Offset and Size fields tell NUT how to carve up the bits after the ReportID. Offset and Size are in bits, so the 8 bits after 0x13 are 0x14, which is 20.

Frequency is a little more complicated. You probably want more precision than just 59 or 60 Hz, so it is typically multiplied by some scaling factor so that integers can represent e.g. 59.9 Hz with a scale factor of 10. Unless it's a small scale factor (under 5), the scaled value won't fit into a single byte (0-255). HID reports are little-endian, so for a 16-bit value, you would need to add two contiguous bytes, and multiply the second byte by 256.

There are a lot of potential factors, but I don't see any likely candidates at the moment. You'd probably want to collect a lot of data, and grab a few readings from the front panel to correlate.

I'm not sure what to make of the other values.

   0.208056     [D3] Report[buf]: (5 bytes) => 05 36 00 30 00
   0.208187     [D2] Path: UPS.PowerSummary.Voltage, Type: Feature, ReportID: 0x05, Offset: 0, Size: 16, Value: 0
   0.208311     LineVoltage exponent looks wrong, but not correcting.
   0.208463     [D3] Report[buf]: (5 bytes) => 05 36 00 30 00
   0.208593     [D2] Path: UPS.PowerSummary.ConfigVoltage, Type: Feature, ReportID: 0x05, Offset: 16, Size: 16, Value: 0
   0.208718     ConfigVoltage exponent looks wrong, but not correcting.

Those lines talk about LineVoltage and ConfigVoltage, which usually refer to AC voltages when taken together, but the values in the descriptor (54 and 48 decimal, from 0x0036 and 0x0030) seem like they could be DC battery voltage, and nominal battery voltage. (The correction refers to backing out an errant exponent which forces the values to be very close to zero.)

> I guess whatever the minimum data to have nut work properly.  I wouldn't mind using this to shutdown multiple computers in the event of a power outage.  

This one's a little easier - you just need working OL/OB and LB bits in ups.status, plus a working shutdown command. There are potential timing gotchas (I don't see shutdown delay values in upsc output, so hopefully there are fixed delays that are long enough), but you'll want to make sure you can do the simple stuff first, and the best way to be sure about that is to test. There are suggestions in the NUT documentation about using dummy loads, etc.