[Nut-upsdev] CPQPOWER-MIB - nearly there

Fri Jan 29 16:34:19 UTC 2010

Sussed it. It was my knowledge of snmp that was lacking. An snmpget
looking for 1.3.6.1.4.1.232.165.3.3.4.1.2.1 resulted in:

Error in packet
Reason: (noSuchName) There is no such variable name in this MIB.
Failed object: CPQPOWER-MIB::upsInputVoltage.1

While getting 1.3.6.1.4.1.232.165.3.3.4.1.2 revealed:

CPQPOWER-MIB::upsInputVoltage.1 = INTEGER: 247

So all I had to do in the code was NOT tag ".1" onto the oid and now
input and output voltages are showing.

I'll get the code tidied up then send it in as a contribution along with
patches for snmp-ups.c and .h to include it.

Regards,

-  
Philip Ward
Unix Systems Administrator
Ext 7274

On Fri, 2010-01-29 at 15:08 +0000, Philip Ward wrote:
> 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.