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