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