[nut-Bugs][312364] Improvements for netvision mips (snmp-ups)

Fri Sep 17 21:56:30 UTC 2010

Bugs item #312364, was changed at 23/02/2010 18:06 by Arnaud Quette
You can respond by visiting: 
https://alioth.debian.org/tracker/?func=detail&atid=411542&aid=312364&group_id=30602

>Status: Pending
Priority: 3
Submitted By: Andrea Soster (sghebuz-guest)
>Assigned to: Arjen de Korte (adkorte-guest)
Summary: Improvements for netvision mips (snmp-ups) 
Category: Driver
Group: None
>Resolution: Fixed

Initial Comment:
Dear,
I'm testing a new ups (Sicom/Socomec MASTERSYS BC 15 KVA), and it works
with nut 2.4.1
After upgrading to 2.4.2/3 it's not working anymore: it's unable to see
the status. 

I fixed the driver making it work again with 2.4.3 and made some
improvements:

     1. The order of "netvision_output_info" is incorrect: fields with
        null value come before the "OL" one, excluding it from the
        lookup. For that reason nut was returning a blank status (and
        upsmon wasn't very happy)
     2. NETVISION_OID_BATTERYSTATUS was checked for
        "netvision_batt_info" and "netvision_output_info". Now
        "netvision_output_info" is checked on
        NETVISION_OID_OUTPUT_SOURCE
     3. If you start the shutdown procedure on the UPS, nut is not
        receiving anything (as the ups is still online) -> Now it checks
        alarm 50 - "UPS imminent stop" and send a FSD signal when
        present

best regards

Andrea Soster

----------------------------------------------------------------------

>Comment By: Arnaud Quette (aquette)
Date: 17/09/2010 23:56

Message:
This bug was fixed by Arjen, in svn commit r2367, and will be available in the next release.

----------------------------------------------------------------------

Comment By: Andrea Soster (sghebuz-guest)
Date: 24/02/2010 09:36

Message:
Uhm, sorry I've seen that battery depleted/bad would be handled by the battery status field, so ignore those 2 alarm request

----------------------------------------------------------------------

Comment By: Andrea Soster (sghebuz-guest)
Date: 24/02/2010 09:34

Message:
1. OK, so you just need to set them BLANK?
3. Why not? Why not adding some other alarms like:
*upsAlarmBatteryBad - "One or more batteries have been determined to require replacement."
*upsAlarmDepletedBattery - "The UPS will be unable to sustain the present load when and if the utility power is lost."
*upsAlarmShutdownPending - "A upsShutdownAfterDelay countdown is underway."
*upsAlarmShutdownImminent - "The UPS will turn off power to the load in less than
          5 seconds; this may be either a timed shutdown or a
          low battery shutdown."

In my setup it would be very nice if nut would respond to all the ups initiated shutdown and to have all the alarms recorded on the system logs.
If you don't want to map all the alarms, you can see them from the alarm table:
(this is the difference of output from snmpwalk between normal contition and forced shutdown)
-enterprises.4555.1.1.1.1.6.1.0 = INTEGER: 0
+enterprises.4555.1.1.1.1.6.1.0 = INTEGER: 1
+enterprises.4555.1.1.1.1.6.2.1.1.10 = INTEGER: 10
+enterprises.4555.1.1.1.1.6.2.1.2.10 = OID: enterprises.4555.1.1.1.1.6.3.50
+enterprises.4555.1.1.1.1.6.2.1.3.10 = Timeticks: (1616532) 4:29:25.32
+enterprises.4555.1.1.1.1.6.2.1.4.10 = STRING: "Imminent Stop"

Another OID to monitor could be the input/output frequency:
input.frequency*0.1  = enterprises.4555.1.1.1.1.3.2.0 (= INTEGER: 500)
output.frequency*0.1  = enterprises.4555.1.1.1.1.4.2.0 (= INTEGER: 500)

Do you have the complete MIB scheme? If you need it I have version 5.01-5.0x (2008-06-12)

best regards

----------------------------------------------------------------------

Comment By: Arjen de Korte (adkorte-guest)
Date: 23/02/2010 20:49

Message:
1. Close, but no cigar. The order of the items is supposed to be irrelevant. Usually we choose ascending order, but that's only because that is easier on our eyes. What's really wrong here, is that only the last entry in the list should be "NULL", since this is treated as the terminating entry.
2, Good to know. Thanks for the report.
3. We'll have to discuss this on the development mailing list. The procedure for now would be to issue 'upsmon -c fsd' to initiate a shutdown sequence before (manually) starting the shutdown sequence. This doesn't rely on the cooperation of the UPS and won't require us to track down all the possible flags and alarms that indicate the UPS is about to shutdown. I'm not to thrilled to add this.

----------------------------------------------------------------------

You can respond by visiting: 
https://alioth.debian.org/tracker/?func=detail&atid=411542&aid=312364&group_id=30602