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

[Arjen de Korte]

> On Dec 29, 2007 9:44 PM, Arjen de Korte <nut+devel at de-korte.org> wrote:
>> If the specification says 'input frequency', that's what it is. If some
>> vendors don't follow this, that's their problem. In any case I'm very
>> much against breaking the NUT variable naming convention for something
>> like this.
>
> According to "new-drivers.txt", I'm not breaking the variable
> convention at all.

This variable is not in 'new-names.txt' and it mentions that before
creating new variables, you need to consult with the list. I can't find
the section in 'new-drivers.txt' where it says you can create new
variables at will.

> And it was after reading that part of the
> documentation that I thought this might make sense instead of keep
> providing a variable with dubious/false meaning.

This is wrong. Remember that the drivers are only a small part of the
whole thing we call NUT (and all external helper programs that have been
based on it). So all variations in naming schemes have to be coordinated
in order to make the changes useful for all. What you've done now, is
effectively removing this variable from view of all backend programs and
frankly, I don't think you're providing a service to anyone with that.

> The problem with the specs, is that the only ones available seem to be
> from specific vendors, so there isn't actually a "right" or "wrong".

The standard is 'new-names.txt' and if you feel the need to differ from
that, this needs to be discussed on the development list first.

> There is no standard (see the problem with some models having the OFF
> flag enabled).

Standards evolve over time. What we thought was a good idea five years
ago, may have changed in the mean time. Unfortunately, many drivers are
currently not maintained by active developers and are slowly rotting in
the tree. This will be dealt with in due time, but that doesn't mean we
shouldn't try to keep a uniform interface/bahaviour for drivers that *are*
maintained.

>> If this really is a consern (which I very much doubt), I suggest to
>> either drop this variable completely or reverse this change and put a
>> note in the man page that some devices don't follow the specification
>> here.
>
> Dropping this variable is not very nice, since the frequency is a very
> good indicator of power quality. And there's something more to this
> than a reverse of meaning from some vendors. My UPS (a standby model)
> seems to be showing input frequency while there is line power, but
> then it keeps showing a value even on battery.

That's entirely possible, since it is probably showing you the output
frequency. On mains this will be the same as the input frequency for
standby models. It will be different for double conversion models though,
although I very much doubt that we will see many of those.

> If you think about it,
> it actually makes (some) sense. While on line power this is the
> frequency directly from the input, but while on battery it is the
> output frequency from the inverter. Ratings information also avoids
> defining nominal frequency and voltage as either input or output.

Indeed, so it probably makes more sense to either change the variable to
'output.frequency' or leave it as 'input.frequency' and set it to zero
when we are running on battery. It can be solved easily in the driver, not
in the backend programs.

> Again, I'd like to hear from whomever wrote that bit in
> new-drivers.txt what the intention was. If I'm interpreting it wrong,
> I'll do the appropriate changes, no problems whatsoever.

Which part are you referring to? Chances are that person is no longer
involved with NUT. And yes I know the documentation needs rework, but
there is only so much I can do.

Best regards, Arjen