[Nut-upsdev] [nut-commits] svn commit r1204 - in trunk: . drivers

[Carlos Rodrigues]

On Dec 30, 2007 6:02 PM, Arjen de Korte <nut+devel at de-korte.org> wrote:
> 1) From a user perspective, it would be nice if the correct settings could
> be autodetected (like setting the correct battery levels based on readings
> from the UPS).
>
> 2) Where the above fails (or we simply don't know what to do since we have
> no information available), the driver should default to the 'old'
> (existing) variables.
>
> Especially #1 probably means a lot of additional work, since there is a
> wide variety of UPS'es out there and we might need entries for *all* of
> them. Ouch, that will probably lead to an endless amount of updates for
> this driver (and lots of work for you).

And we couldn't even do this, because most UPSes implementing the
megatec protocol provide no information whatsoever about themselves
(other than the voltage/frequency/load ratings). No vendor info, no
model info, nothing.

> PS  A quick and dirty method would be to use 'input.frequency' and set it
> to zero when we have detected that the input power is lost. In most cases,
> only when the system is running on mains the value of the frequency is
> relevant (indeed to monitor the quality of the mains). You could go out of
> your head and let the driver figure out what the parameter means by
> setting 'output.frequency' if it still has a reading during a power
> failure. In that case (for the duration of the time the driver is
> running), you could change over to 'output.frequency' and no longer use
> 'input.frequency' (dstate_delinfo() it).

Changing from "input.frequency" to "output.frequency" isn't something
that I like very much. Besides during a power failure there's still a
residual reading on input.voltage too... For the time being, it will
stay like before (input).


-- 
Carlos Rodrigues