[Nut-upsdev] an ideas for having additional parameters control UPS shutdown

Tue Mar 6 21:22:13 UTC 2012

This seems to be exactly what was intended in the 
recent discussion regarding "FSD".  I like the 
idea of having some alarm states that would be 
meaningful at to why FSD was set by the driver also.

Bill

At 02:49 PM 3/6/2012, Arnaud Quette wrote:
>Hi Greg,
>
>I'm just forwarding your msg to the developers list for now, which is
>the preferred address for posting.
>I've completely missed it until today for that reason.
>A proper answer will come later.
>
>Also note that apart from Michal and myself, other developers you
>tried to reach are now retired.
>
>cheers,
>Arno
>
>2012/2/29 Greg A. Woods <woods at planix.ca>:
> > Greetings!
> >
> > I've been tasked by a current client to add support to NUT to allow it
> > to manage system and network shutdown not just when power is lost, but
> > also when additional parameters such as temperature go out of an
> > acceptable range. Â (HVAC problems are apparently far more critical in
> > their environment than power stability problems, but the most obvious
> > path to managing a controlled safe shutdown is to monitor both
> > temperature and power through a single management tool that can affect
> > such a safe shutdown of a network of system and of course NUT came
> > immediately to mind as the obvious solution, albiet one that needed some
> > minor new features to make it all work.)
> >
> > I looked at the initial proposals and documentation suggesting that a
> > scriptable front-end to do this would be best but I thought this was
> > entirely backwards and that it would miss out on any number of possible
> > device-specific mechanisms for monitoring for critical conditions. Â The
> > other idea from the mailing list of faking OB+LB from a custom driver
> > that monitored some sensor also seemed far too hokey and hackish.
> >
> > Instead I came up with a very simple concept that a UPS could declare
> > itself to be dying (or "almost dead", or imminently about to die) for
> > some reason other than OB+LB. Â This makes it trivial to add additional
> > parameters and controls to any driver which the driver itself can then
> > use to make its own decisions about if or when the UPS needs to be shut
> > down for whatever reason.
> >
> > Ideally warning limits could be added as well to set ups.alarm states
> > prior to a final emergency power off because the UPS has reached a true
> > about-to-die state, but I haven't done that yet as neither apscmart nor
> > snmp-ups seem to support .
> >
> > Also ideally there would be a seperate "emergency power off" command
> > that could be sent to a driver such that it would turn off all load
> > outputs and ideally shut the whole UPS down as well, even though mains
> > power is still available, and to do so in such a fashion that direct
> > human intervention would be required to turn it back on again. Â (For now
> > I've left apcsmart to make the decision of how to shut down based on its
> > own state, and of course which kind of device it's controlling.)
> >
> > I've implemented the beginnings of this on the trunk (using a "git svn"
> > clone repository) for the apcsmart driver, with a few stabs at snmp-ups
> > and dummyups, and have begun testing. Â (I currently only have an old
> > SmartUPS with a AP9605 SNMP card to test with -- my servers run on a GE
> > GT3000 but of course there's no driver for that one and I've been unable
> > to find any documentation for its serial protocol, and indeed I've been
> > unable to elicit any sensible response from it via direct manual connect
> > -- I could probably make it work with genericups as a contact-closure
> > UPS, but that won't help with testing my new temperature monitoring
> > changes.)
> >
> > So far the changes are quite small and not too intrusive, though of
> > course they would expand if I were able to adapt more drivers to
> > implement this feature, and if I were to add ups.alarm support for
> > warning of impending doom.
> >
> > We would be able to maintain these changes ourselves going forward, but
> > ideally we'd like to push them back upstream, both to contribute back to
> > a project we're making use of, and also of course so that we don't have
> > to keep rebasing our changes onto new NUT releases.
> >
> > I was going to send this note to the developers list, but unfortunately
> > I'm (still) unable to interact with any lists at debian.org. Â The admins
> > there are still being stupid and naive about MX records and my mail
> > server requires that the domain names used in all sender addresses have
> > valid published MX records.
> >
> > So I'm sending you this message directly to ask if any of you would like
> > to have a look at my changes, and perhaps consider them for inclusion
> > into NUT. Â Please do let me know what you think of the basic ideas here.
> >
> > Perhaps I could send them to the developer's list as well, but unless
> > the Debian admins change their ways I'll be unable to subscribe and
> > participate in any discussion via the list.
> >
> > I was going to try to post some bugs to the bug tracker too, but as yet
> > I've been unable to register for it either. Â I may be able to use my
> > e-mail address at my client's domain, but for the moment I'm hoping to
> > avoid any copyright issues by keeping total control over the identity I
> > use to submit any changes.
> >
> > If I can figure out how to make a public git repository on my own
> > somewhat limited capability server that doesn't currently have git
> > installed I'll make my changes available that way (at minimum I could
> > easily put a bundle file and/or patch files up for grabs by HTTP or
> > FTP).
> >
> >
> > --
> > 
> Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â 
> Â  Â  Â  Â  Â  Â  Â  Â Greg A. Woods
> >
> > +1 250 762-7675 
> Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â RoboHack <woods at robohack.ca>
> > Planix, Inc. <woods at planix.com> Â  Â  Â 
> Secrets of the Weird <woods at weird.com>
>
>_______________________________________________
>Nut-upsdev mailing list
>Nut-upsdev at lists.alioth.debian.org
>http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20120306/535c71e6/attachment.html>