[Nut-upsdev] [Nut-upsuser] Powerware 9155 with SNMP card

[Arjen de Korte]

[...]

>> Apparently, the autodetection failed here and it selects the default
>> ietf
>> MIB, where these are not set. This will probably be fixed by adding
>>
>> 	mibs = pw
>>
>> to the ups.conf entry for these devices (to select the data from pwmib.h
>> file). See also 'man snmp-ups' for an example.
> Na, I already run the pw mib... The ietf mib didn't even so more than a
> single
> imput phase... The above should be hidden inside the XUPS.mib I guess.

My bad. The UPS probably doesn't support these variables.

>> You'll probably want to add the folliwing to "pwmib.h" (I'm not in favor
>> of adding ups.status words):
>>
>> info_lkp_t pw_pwr_info[] = {
>> 	{ 1, ""       /* other */ },
>> 	{ 2, "OFF"    /* none */ },
>> 	{ 3, "OL"     /* normal */ },
>> 	{ 4, "BYPASS" /* bypass */ },
>> 	{ 5, "OB"     /* battery */ },
>> 	{ 6, "OL BOOST"  /* booster */ },
>> 	{ 7, "OL TRIM"   /* reducer */ },
>> 	{ 8, "OL"   /* parallel capacity */ },
>> 	{ 9, "OL"   /* parallel redundancy */ },
>> 	{10, "OL"   /* high efficiancy */ },
>> 	{ 0, "NULL" }
>> };
> Agreed. But I would suggest to add PCAP, PRED or anything along those
> lines to the OL so one knows that we are running in parallel mode.

Euhm, no. That's not what 'ups.status' is for.

> I don't know whether this status changes if the other UPS goes down for
> some reason. So it would be handy if on could differentiate those.

I prefer to put this in 'ups.type' which is an opaque string that can be
filled with just about anything. Adding the following might work, provided
that the UPS is running online when the driver is started.

info_lkp_t pw_mode_info[] = {
	{ 1, ""  },
	{ 2, ""  },
	{ 3, "normal" },
	{ 4, "" },
	{ 5, "" },
	{ 6, "" },
	{ 7, "" },
	{ 8, "parallel capacity" },
	{ 9, "parallel redundancy" },
	{10, "high efficiency" },
	{ 0, "NULL" }
};

{ "ups.type", ST_FLAG_STRING, SU_INFOSIZE, PW_OID_POWER_STATUS, "",
 SU_FLAG_STATIC | SU_FLAG_OK, &pw_mode_info[0] },

Beware, I'm just typing along, so be prepared. I don't have an SNMP
capable UPS either (Arnaud? :-) ), so I'm not too familiar with this
particular driver. From a quick glance at this driver, it looks that
multiple "ups.status" entries in the manufacturer specific MIB may lead to
the driver overwriting status bits (each one is parsed immediately, so for
each update the previous state is cleared).

Best regards, Arjen
-- 
Eindhoven - The Netherlands
Key fingerprint - 66 4E 03 2C 9D B5 CB 9B  7A FE 7E C1 EE 88 BC 57