Nut upsdev - Mar 2012 - an ideas for having additional parameters control UPS shutdown

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>

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>