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][email protected]>: > > 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 _______________________________________________ Nut-upsuser mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
