[Nut-upsuser] netvision-mib driver

[Henning Fehrmann]

Hi Arnaud,

thank you the last update.

> 
>    note that I've cc'ed the NUT users list for info.
>    2015-02-04 13:47 GMT+01:00 Henning Fehrmann
>    <[1]henning.fehrmann at aei.mpg.de>:
> 
>      Hi Arnaud,
>      >    the best to process the value would be to have the MIB definition
>      for
>      >    upsAlarmOnBattery, as for example:
>      >   
>      [1][2]https://github.com/networkupstools/nut/blob/master/drivers/eaton-mib.c#L108
> 
>      Yea, I looked into netvision-mib.c but I was afraid that patching it
>      would break more than it helps. We still can try it ......
>      >
>      >    You should request these info to Socomec, or better, ask them to
>      send the
>      >    updated Netvision MIB (v6) to the project (or /me) for publishing
>      on NUT
>      >    protocols library:
>      >    [2][3]http://www.networkupstools.org/ups-protocols.html
> 
>      I attach the Netvision MIB I got recently from the Socomec side.
> 
>    thx. I will publish it along with the 2.7.3 release.

The versions seems to work. I still have to do a final test and
disconnect the UPS from the external power supply.

I observed an issues, probably not related to the driver development:

a make install produces:

:
make[3]: Entering directory '/root/sfehrmann/NUT/nut/docs/man'
make[3]: Nothing to be done for 'install-exec-am'.
Using existing nut.conf.5 manual page, since 'asciidoc', 'xmllint' or 'xsltproc' were not found.
Using existing ups.conf.5 manual page, since 'asciidoc', 'xmllint' or 'xsltproc' were not found.
Using existing upsd.conf.5 manual page, since 'asciidoc', 'xmllint' or 'xsltproc' were not found.
Using existing upsd.users.5 manual page, since 'asciidoc', 'xmllint' or 'xsltproc' were not found.
Using existing upsmon.conf.5 manual page, since 'asciidoc', 'xmllint' or 'xsltproc' were not found.
Using existing upssched.conf.5 manual page, since 'asciidoc', 'xmllint' or 'xsltproc' were not found.
 /bin/mkdir -p '/srv/nut/share/man/man5'
 /usr/bin/install -c -m 644 ./nut.conf.5 ./ups.conf.5 ./upsd.conf.5 ./upsd.users.5 ./upsmon.conf.5 ./upssched.conf.5 '/srv/nut/share/man/man5'
/usr/bin/install: cannot stat ‘./nut.conf.5’: No such file or directory
/usr/bin/install: cannot stat ‘./ups.conf.5’: No such file or directory
/usr/bin/install: cannot stat ‘./upsd.conf.5’: No such file or directory
/usr/bin/install: cannot stat ‘./upsd.users.5’: No such file or directory
/usr/bin/install: cannot stat ‘./upsmon.conf.5’: No such file or directory
/usr/bin/install: cannot stat ‘./upssched.conf.5’: No such file or directory
Makefile:1021: recipe for target 'install-man5' failed
make[3]: Leaving directory '/root/sfehrmann/NUT/nut/docs/man'
make[3]: *** [install-man5] Error 1
Makefile:1152: recipe for target 'install-am' failed
make[2]: Leaving directory '/root/sfehrmann/NUT/nut/docs/man'
make[2]: *** [install-am] Error 2
Makefile:516: recipe for target 'install-recursive' failed
make[1]: Leaving directory '/root/sfehrmann/NUT/nut/docs'
make[1]: *** [install-recursive] Error 1
Makefile:513: recipe for target 'install-recursive' failed
make: *** [install-recursive] Error 1
: 

But this is not a show stopper.


More critical is probably the fact that the communication with the UPS does not
work always properly. I'll ask the Socomec people.

I found this in the logs

:
Feb  5 17:26:30 config snmp-ups[13468]: [socomec] snmp_ups_walk: data resumed for ups.status
Feb  5 17:26:30 config snmp-ups[13468]: [socomec] snmp_ups_walk: data resumed for input.phases
Feb  5 17:26:30 config snmp-ups[13468]: [socomec] snmp_ups_walk: data resumed for input.frequency
Feb  5 17:26:30 config snmp-ups[13468]: [socomec] snmp_ups_walk: data resumed for input.L1-N.voltage
Feb  5 17:26:30 config snmp-ups[13468]: [socomec] snmp_ups_walk: data resumed for input.L1.current
Feb  5 17:26:30 config snmp-ups[13468]: [socomec] snmp_ups_walk: data resumed for input.L2-N.voltage
Feb  5 17:26:30 config snmp-ups[13468]: [socomec] snmp_ups_walk: data resumed for input.L2.current
Feb  5 17:26:30 config snmp-ups[13468]: [socomec] snmp_ups_walk: data resumed for input.L3-N.voltage
Feb  5 17:26:30 config snmp-ups[13468]: [socomec] snmp_ups_walk: data resumed for input.L3.current
Feb  5 17:26:30 config snmp-ups[13468]: [socomec] snmp_ups_walk: data resumed for output.phases
Feb  5 17:26:30 config snmp-ups[13468]: [socomec] snmp_ups_walk: data resumed for output.frequency
Feb  5 17:26:30 config snmp-ups[13468]: [socomec] snmp_ups_walk: data resumed for output.L1-N.voltage
Feb  5 17:26:30 config snmp-ups[13468]: [socomec] snmp_ups_walk: data resumed for output.L1.current
Feb  5 17:26:30 config snmp-ups[13468]: [socomec] snmp_ups_walk: data resumed for output.L1.power.percent
Feb  5 17:26:30 config snmp-ups[13468]: [socomec] snmp_ups_walk: data resumed for output.L2-N.voltage
Feb  5 17:26:30 config snmp-ups[13468]: [socomec] snmp_ups_walk: data resumed for output.L2.current
Feb  5 17:26:30 config snmp-ups[13468]: [socomec] snmp_ups_walk: data resumed for output.L2.power.percent
Feb  5 17:27:51 config snmp-ups[13468]: [socomec] snmp_ups_walk: data stale for ups.status
Feb  5 17:27:51 config upsd[13608]: Data for UPS [socomec] is stale - check driver
Feb  5 17:27:51 config upsd[13608]: UPS [socomec] data is no longer stale
Feb  5 17:28:31 config snmp-ups[13468]: [socomec] snmp_ups_walk: data stale for ups.status
Feb  5 17:28:31 config upsd[13608]: Data for UPS [socomec] is stale - check driver
:

One of the critical requests is the ups.status which is the last one. If the
UPS network card problem is being triggered by a snmpwalk the first requests
are being answered but not the status.

Would it be possible (and wise) to put the ups.status request right in the beginning?


Thank you and cheers,
Henning