[Nut-upsdev] CPQPOWER-MIB - nearly there

Fri Jan 29 15:08:16 UTC 2010

Hi Charles,

Thanks for getting back to me.
> 
> In the cpqpower_mib array, the #define'd names for the voltage and
> current OIDs are listed with a ".1", ".2" and ".3" suffix for each of
> the three phases. Is your UPS a 3-phase unit? The URL for the MIB
> shows CPQPOWER_OID_IN_VOLTAGE as a leaf.
> 

These UPSs support 3-phase, but the power in our server rooms is split
up so that only one phase is sent to any one rack.
You are right about the leaf. Here's a snippet from an snmpwalk (firstly
with numerical OIDs, then descriptive OIDs):

.1.3.6.1.4.1.232.165.3.3.3.0 = INTEGER: 1
.1.3.6.1.4.1.232.165.3.3.4.1.1.1 = INTEGER: 1
.1.3.6.1.4.1.232.165.3.3.4.1.1.2 = INTEGER: 2
.1.3.6.1.4.1.232.165.3.3.4.1.1.3 = INTEGER: 3
.1.3.6.1.4.1.232.165.3.3.4.1.2.1 = INTEGER: 247
.1.3.6.1.4.1.232.165.3.3.4.1.2.2 = INTEGER: 0
.1.3.6.1.4.1.232.165.3.3.4.1.2.3 = INTEGER: 0
.1.3.6.1.4.1.232.165.3.3.4.1.3.1 = INTEGER: 9
.1.3.6.1.4.1.232.165.3.3.4.1.3.2 = INTEGER: 0
.1.3.6.1.4.1.232.165.3.3.4.1.3.3 = INTEGER: 0
.1.3.6.1.4.1.232.165.3.3.4.1.4.1 = INTEGER: 0
.1.3.6.1.4.1.232.165.3.3.4.1.4.2 = INTEGER: 0
.1.3.6.1.4.1.232.165.3.3.4.1.4.3 = INTEGER: 0
.1.3.6.1.4.1.232.165.3.3.5.0 = INTEGER: fuelcell(8)
.1.3.6.1.4.1.232.165.3.4.1.0 = INTEGER: 29
.1.3.6.1.4.1.232.165.3.4.2.0 = INTEGER: 500
.1.3.6.1.4.1.232.165.3.4.3.0 = INTEGER: 1
.1.3.6.1.4.1.232.165.3.4.4.1.1.1 = INTEGER: 1
.1.3.6.1.4.1.232.165.3.4.4.1.1.2 = INTEGER: 2
.1.3.6.1.4.1.232.165.3.4.4.1.1.3 = INTEGER: 3
.1.3.6.1.4.1.232.165.3.4.4.1.2.1 = INTEGER: 225
.1.3.6.1.4.1.232.165.3.4.4.1.2.2 = INTEGER: 0
.1.3.6.1.4.1.232.165.3.4.4.1.2.3 = INTEGER: 0
.1.3.6.1.4.1.232.165.3.4.4.1.3.1 = INTEGER: 8
.1.3.6.1.4.1.232.165.3.4.4.1.3.2 = INTEGER: 0
.1.3.6.1.4.1.232.165.3.4.4.1.3.3 = INTEGER: 0
.1.3.6.1.4.1.232.165.3.4.4.1.4.1 = INTEGER: 1600
.1.3.6.1.4.1.232.165.3.4.4.1.4.2 = INTEGER: 0
.1.3.6.1.4.1.232.165.3.4.4.1.4.3 = INTEGER: 0
.1.3.6.1.4.1.232.165.3.4.5.0 = INTEGER: normal(3)
.1.3.6.1.4.1.232.165.3.5.1.0 = INTEGER: 0
.1.3.6.1.4.1.232.165.3.5.2.0 = INTEGER: 0

upsInputNumPhases.0 = INTEGER: 1
upsInputPhase.1 = INTEGER: 1
upsInputPhase.2 = INTEGER: 2
upsInputPhase.3 = INTEGER: 3
upsInputVoltage.1 = INTEGER: 247
upsInputVoltage.2 = INTEGER: 0
upsInputVoltage.3 = INTEGER: 0
upsInputCurrent.1 = INTEGER: 9
upsInputCurrent.2 = INTEGER: 0
upsInputCurrent.3 = INTEGER: 0
upsInputWatts.1 = INTEGER: 0
upsInputWatts.2 = INTEGER: 0
upsInputWatts.3 = INTEGER: 0
upsInputSource.0 = INTEGER: fuelcell(8)
upsOutputLoad.0 = INTEGER: 29
upsOutputFrequency.0 = INTEGER: 500
upsOutputNumPhases.0 = INTEGER: 1
upsOutputPhase.1 = INTEGER: 1
upsOutputPhase.2 = INTEGER: 2
upsOutputPhase.3 = INTEGER: 3
upsOutputVoltage.1 = INTEGER: 225
upsOutputVoltage.2 = INTEGER: 0
upsOutputVoltage.3 = INTEGER: 0
upsOutputCurrent.1 = INTEGER: 8
upsOutputCurrent.2 = INTEGER: 0
upsOutputCurrent.3 = INTEGER: 0
upsOutputWatts.1 = INTEGER: 1608
upsOutputWatts.2 = INTEGER: 0
upsOutputWatts.3 = INTEGER: 0
upsOutputSource.0 = INTEGER: normal(3)
upsBypassFrequency.0 = INTEGER: 0
upsBypassNumPhases.0 = INTEGER: 0

For starters upsInputNumPhases.0 is one, so I take it to mean that
values with flags of SU_INPUT_1 will be used.
CPQPOWER_OID_IN_VOLTAGE is set to "1.3.6.1.4.1.232.165.3.3.4.1.2" and in
the cpqpower_mib table I add ".1" to it thus:

{ "input.voltage", 0, 1.0, CPQPOWER_OID_IN_VOLTAGE ".1", "",
                SU_INPUT_1, NULL },

Which gives an OID of 1.3.6.1.4.1.232.165.3.3.4.1.2.1
Above you'll see that this oid gives a value of 247, but upsc ( and by
extension the upsstats cgi ) shows a blank.
I'm wondering if there is something else I'm missing, such as not fully
understanding how the flags work, or how the driver handles leaves.

> Not sure if snmp-ups has this as well, but the usbhid-ups code allows
> you to specify mapping functions. Maybe one of the other developers
> has worked with this on and can comment further.

I'll have a look at usbhid-ups. If I can come up with a method that is
cleaner than a 100 element array then I'll put it in.

> We do have a separate ambient.temperature variable. That said, what is
> your best guess as to the origin of that temperature value? If it is
> mislabeled as an internal temperature (that is, somewhat hotter than
> ambient), then "ups.temperature" might be a better name (probably with
> a comment in the code in case someone runs across a different version
> of the firmware). If it does look like ambient temperature,
> ambient.temperature is the better variable name.

I'm fairly sure that it is the environmental temperature. It's reporting
between 20 and 25 celsius. Our air conditioners are set to try and
maintain 21 celsius, so the figure probably belongs in
ambient.temperature.
Hey, I could probably use this to monitor our server rooms via nut and
nagios since we don't have any proper environmental sensors that can
alert us.

Thanks for your help,

Philip Ward.

-- 
The Sunday Times Scottish University of the Year 2009/2010
The University of Stirling is a charity registered in Scotland, 
 number SC 011159.