Nut upsuser - Feb 2015 - netvision-mib driver

Hi Henning,

note that I've cc'ed the NUT users list for info.

2015-02-04 13:47 GMT+01:00 Henning Fehrmann <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]
> 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]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.

in light of this:
- it's a kinda-boolean (0/1, ok/not ok)
- I've committed the fix
https://github.com/networkupstools/nut/commit/4552d14162086a280445efc5331a8e6ad7b1c3a4

> >
> >    Last question: would you be able to test a patch or a github branch
> (i.e.
> >    needs recompilation)?
>
> Yes, we can do it and we can grant you access, or both, as you wish.
>
please be my guest and test the result ;)


> >    I'm in the process of releasing 2.7.3, so that would be the
best to
> have
> >    your patch in and tested...
>
> We'll watch for new pushes.
>
> Thank you and cheers,
> Henning
>

cheers,
Arno
--
NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150204/260422bc/attachment.html>

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