Re: [Nut-upsdev] New snmp-ups subdriver for Huawei
On Mar 31, 2015, at 3:20 AM, Arnaud Quette aquette@gmail.com wrote: first comment: it would have been great if you used the SNMP subdriver generator [1] It creates a dump of the whole structure pointed by the sysOID, and help to track the remaining unimplemented features... ... [1] http://www.networkupstools.org/docs/developer-guide.chunked/ar01s04.html#snmp-subdrivers https://github.com/networkupstools/nut/blob/master/scripts/subdriver/gen-snmp-subdriver.sh Arnaud, although I agree this would be useful for a later revision, I went ahead and merged the current patch. [2] http://www.networkupstools.org/ups-protocols.html Stuart, if we add the copy of the MIB to that protocols page, do you have a source link? Thanks, -- Charles Lepple clepple@gmail ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] New snmp-ups subdriver for Huawei
Hi Stuart, Charles and the list, 2015-03-29 14:17 GMT+02:00 Stuart Henderson s...@spacehopper.org: On 2015/03/28 20:02, Charles Lepple wrote: On Mar 25, 2015, at 9:21 PM, Stuart Henderson s...@spacehopper.org wrote: Hi, the diff inline below adds a new subdriver for snmp-ups to support Huawei UPS, based on an observed walk from a UPS5000-E with a few bits filled in from the MIBs (copy at http://junkpile.org/HUAWEI_UPS_MIB/). Sample output from upsc follows the diff. Hi Stuart, Thanks for the patch. It builds cleanly for me, so I have no problems merging it. The only two things that jump out at me could probably be addressed with documentation. Is there a low battery alarm? If not, we should probably mention somewhere that people will need to either synthesize a LB status with one or both of 'override.battery.charge.low' and 'override.battery.runtime.low'. I didn't notice anything that looks like a low battery alarm in the Huawei MIB, though it does also return a value in UPS-MIB::upsBatteryStatus.0 so perhaps a LB alarm will be signalled there; I see that in mge-mib.c the status appears to be generated from a combination of ietf and private MIB but there is a comment FIXME: the below may introduce status redundancy, that needs to be * adressed by the driver, as for usbhid-ups! so I wasn't sure the best approach here. Unfortunately it isn't really possible to test low battery in my environment, I'd need to override the generator autostart/ATS which I don't think I'd get approval for (my main aim with this UPS is to use NUT to act as an abstraction layer so that it can be monitored alongside a couple of more normal UPS, rather than specifically to trigger shutdowns). first comment: it would have been great if you used the SNMP subdriver generator [1] It creates a dump of the whole structure pointed by the sysOID, and help to track the remaining unimplemented features... (Or they can shut down when it first transfers to battery, but this sounds like the sort of UPS that would keep going for a while.) Indeed, it is a bit larger than anything I've dealt with before, you may have noticed the battery V in my sample output ;-) There also seem to be a few commands in the MIB, but none are implemented here. The only ones that people might be expecting are the shutdown.reboot and shutdown.stayoff, although I haven't used the SNMP driver to see how well those work in general. Not strictly necessary to implement, but we should probably take this opportunity to point out in the snmp-ups man page that if there are no shutdown.* commands listed in the upscmd output, there is a potential for a race condition if the power comes back early. There's a hwUpsCtrlPowerOff command and a RW hwUpsCtrlPowerOffDelay variable, but the mib isn't clear about whether this would be shutdown.stayoff or shutdown.return, I'll see if I can find more information about this in the manuals. I don't see a power-on delay in the vendor mib so I think shutdown.reboot may not be possible. There is also a battery test command, which would be a bit easier for me to test, I'll try and look at that sometime. also, would be great if you could post (either public/private, but compressed) or point to the MIB file, for putting on the Protocols page [2] Arnaud, as maintainer of snmp-ups, any thoughts here? Thanks for the review Charles, and I'd be interested to hear any comments from Arnaud. this version of the SNMP driver is getting too old and not flexible enough. Keep in mind that there is a rewrite scheduled [3] However, for now, you may want to have a look at [4]. This implementation is not perfect, but will give you some ideas. I still have to find a better way to link and use the commands with the matching delays. But it's generally a default behavior of SNMP agent (i.e. first set the delay, then execute the command) Thanks for your contribution, cheers, Arno -- [1] http://www.networkupstools.org/docs/developer-guide.chunked/ar01s04.html#snmp-subdrivers https://github.com/networkupstools/nut/blob/master/scripts/subdriver/gen-snmp-subdriver.sh [2] http://www.networkupstools.org/ups-protocols.html [3] https://github.com/networkupstools/nut/issues/20 [4] https://github.com/networkupstools/nut/blob/master/drivers/powerware-mib.c#L314 -- Eaton Data Center Automation - Opensource Leader NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org Debian Developer - http://www.debian.org Free Software Developer - http://arnaud.quette.fr ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] New snmp-ups subdriver for Huawei
On 2015/03/28 20:02, Charles Lepple wrote: On Mar 25, 2015, at 9:21 PM, Stuart Henderson s...@spacehopper.org wrote: Hi, the diff inline below adds a new subdriver for snmp-ups to support Huawei UPS, based on an observed walk from a UPS5000-E with a few bits filled in from the MIBs (copy at http://junkpile.org/HUAWEI_UPS_MIB/). Sample output from upsc follows the diff. Hi Stuart, Thanks for the patch. It builds cleanly for me, so I have no problems merging it. The only two things that jump out at me could probably be addressed with documentation. Is there a low battery alarm? If not, we should probably mention somewhere that people will need to either synthesize a LB status with one or both of 'override.battery.charge.low' and 'override.battery.runtime.low'. I didn't notice anything that looks like a low battery alarm in the Huawei MIB, though it does also return a value in UPS-MIB::upsBatteryStatus.0 so perhaps a LB alarm will be signalled there; I see that in mge-mib.c the status appears to be generated from a combination of ietf and private MIB but there is a comment FIXME: the below may introduce status redundancy, that needs to be * adressed by the driver, as for usbhid-ups! so I wasn't sure the best approach here. Unfortunately it isn't really possible to test low battery in my environment, I'd need to override the generator autostart/ATS which I don't think I'd get approval for (my main aim with this UPS is to use NUT to act as an abstraction layer so that it can be monitored alongside a couple of more normal UPS, rather than specifically to trigger shutdowns). (Or they can shut down when it first transfers to battery, but this sounds like the sort of UPS that would keep going for a while.) Indeed, it is a bit larger than anything I've dealt with before, you may have noticed the battery V in my sample output ;-) There also seem to be a few commands in the MIB, but none are implemented here. The only ones that people might be expecting are the shutdown.reboot and shutdown.stayoff, although I haven't used the SNMP driver to see how well those work in general. Not strictly necessary to implement, but we should probably take this opportunity to point out in the snmp-ups man page that if there are no shutdown.* commands listed in the upscmd output, there is a potential for a race condition if the power comes back early. There's a hwUpsCtrlPowerOff command and a RW hwUpsCtrlPowerOffDelay variable, but the mib isn't clear about whether this would be shutdown.stayoff or shutdown.return, I'll see if I can find more information about this in the manuals. I don't see a power-on delay in the vendor mib so I think shutdown.reboot may not be possible. There is also a battery test command, which would be a bit easier for me to test, I'll try and look at that sometime. Arnaud, as maintainer of snmp-ups, any thoughts here? Thanks for the review Charles, and I'd be interested to hear any comments from Arnaud. Stuart ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] New snmp-ups subdriver for Huawei
On Mar 25, 2015, at 9:21 PM, Stuart Henderson s...@spacehopper.org wrote: Hi, the diff inline below adds a new subdriver for snmp-ups to support Huawei UPS, based on an observed walk from a UPS5000-E with a few bits filled in from the MIBs (copy at http://junkpile.org/HUAWEI_UPS_MIB/). Sample output from upsc follows the diff. Hi Stuart, Thanks for the patch. It builds cleanly for me, so I have no problems merging it. The only two things that jump out at me could probably be addressed with documentation. Is there a low battery alarm? If not, we should probably mention somewhere that people will need to either synthesize a LB status with one or both of 'override.battery.charge.low' and 'override.battery.runtime.low'. (Or they can shut down when it first transfers to battery, but this sounds like the sort of UPS that would keep going for a while.) There also seem to be a few commands in the MIB, but none are implemented here. The only ones that people might be expecting are the shutdown.reboot and shutdown.stayoff, although I haven't used the SNMP driver to see how well those work in general. Not strictly necessary to implement, but we should probably take this opportunity to point out in the snmp-ups man page that if there are no shutdown.* commands listed in the upscmd output, there is a potential for a race condition if the power comes back early. Arnaud, as maintainer of snmp-ups, any thoughts here? Thanks again, -- Charles Lepple clepple@gmail ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
