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 <[email protected]>:
> 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 <[email protected]>
> Planix, Inc. <[email protected]> Â Â Â
Secrets of the Weird <[email protected]>
_______________________________________________
Nut-upsdev mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
_______________________________________________
Nut-upsdev mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
