Nice, that MIB fills in a few details.
.1.3.6.1.4.1.232.165 is cpqPower.
.1.3.6.1.4.1.232.165.3 is cpqPower.ups.
On Jul 16, 2013, at 10:25 PM, Charles Lepple wrote:
> Here's the first update of ups.status:
>
> 0.102449 getting data: ups.status (.1.3.6.1.4.1.232.165.3.4.5.0)
> 0.102546 su_ups_get: ups.status .1.3.6.1.4.1.232.165.3.4.5.0
> 0.102646 nut_snmp_get(.1.3.6.1.4.1.232.165.3.4.5.0)
> 0.104539 SNMP UPS driver : entering su_status_set()
> 0.104641 su_find_infoval: found OL (value: 3)
> 0.104730 => value: 3
>
> 0.104823 getting data: ups.status (.1.3.6.1.4.1.232.165.3.2.5.0)
> 0.104919 su_ups_get: ups.status .1.3.6.1.4.1.232.165.3.2.5.0
> 0.105028 nut_snmp_get(.1.3.6.1.4.1.232.165.3.2.5.0)
> 0.107134 SNMP UPS driver : entering su_status_set()
> 0.107231 su_find_infoval: found DISCHRG (value: 2)
> 0.107319 => value: 2
>
> 0.107412 getting data: ups.status (.1.3.6.1.4.1.232.165.3.7.3.0)
> 0.107507 su_ups_get: ups.status .1.3.6.1.4.1.232.165.3.7.3.0
> 0.107616 nut_snmp_get(.1.3.6.1.4.1.232.165.3.7.3.0)
> 0.109529 SNMP UPS driver : entering su_status_set()
> 0.109630 su_find_infoval: found OB (value: 1)
> 0.109720 => value: 1
>
> The first one (...3.4.5.0) is labeled in the driver as
> CPQPOWER_OID_POWER_STATUS. I checked around for this, and didn't find a good
> definition, but that seems to match the OL state.
Confirmed by the MIB:
upsOutputSource OBJECT-TYPE
SYNTAX INTEGER {
other(1),
none(2),
normal(3), -- normal, single UPS module output
bypass(4),
battery(5),
booster(6), -- Single or Double Boost,
line-interactive UPSs only
reducer(7), -- Buck, line-interactive UPSs only
parallelCapacity(8), -- normal enhanced by Parallel for
Capacity operation
parallelRedundant(9), -- normal enhanced by Redundant
Parallel operation
highEfficiencyMode(10) -- normal enhanced by High Efficiency
mode
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The present source of output power. The enumeration
none(2) indicates that there is no source of output
power (and therefore no output power), for example,
the system has opened the output breaker."
::= { upsOutput 5 }
> The second one seems specific to the battery:
>
> static info_lkp_t cpqpower_battery_abm_status[] = {
> { 1, "CHRG" },
> { 2, "DISCHRG" },
> /* { 3, "Floating" }, */
> /* { 4, "Resting" }, */
> /* { 5, "Unknown" }, */
> { 0, "NULL" }
> } ;
>
> I could see the battery monitoring circuit discharging the battery
> occasionally for maintenance, but is there a separate front-panel indicator
> for this mode?
The MIB suggests that the "discharge" state is part of normal battery
management:
upsBatteryAbmStatus OBJECT-TYPE
SYNTAX INTEGER {
batteryCharging(1),
batteryDischarging(2),
batteryFloating(3),
batteryResting(4),
unknown(5)
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Gives the status of the Advanced Battery Management;
batteryFloating(3) status means that the charger is temporarily
charging the battery to its float voltage; batteryResting(4) is the
state when the battery is fully charged and none of the other actions
(charging/discharging/floating) is being done."
::= { upsBattery 5 }
> The third one is CPQPOWER_OID_ALARM_OB. This definitely doesn't make sense,
> since things with "alarm" in the name are usually pretty direct.
I looked up the third OID, and it does not seem to map to that alarm status.
Instead, it is "upsTestTrap" and while the MIB calls it read-write, the only
defined action is for writing a startTestTrap to start a test.
Arnaud: the CPQPOWER_OID_ALARM_OB entry looks like it was a guess [*]. Do you
know of any units which require this? Otherwise, I think we should take it out.
[*]
https://github.com/networkupstools/nut/commit/c1b83e7d40083263719de13e631a72dfc96961a9
--
Charles Lepple
clepple@gmail
_______________________________________________
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
