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

[Arjen de Korte]

>> 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.
> It's after the 3phase stuff, but I reread it again (include some more
> of the previous sections) and I see that I was missing the "domain"
> part. Although I think the document should be tweaked to not have an
> unqualified name (e.g.) "frequency.nominal" when it should have an
> explicit example like "input.frequency.nominal".

See the EXAMPLES section mentioned a few lines down. I think the 3-phase
specification is quite clear as it is now, as long as one understands the
way of naming variables in DOMAIN.CONTEXT.SPEC as explained. So the
"frequency.nominal" part you mentioned above, is not an example for a
variable name, but of a SPEC. You can't use that without a DOMAIN (the
CONTEXT is explicitly not applicable in this case).

Note that I'm definitly not against allowing to change the variables from
"input.<whatever>"  to "output.<whatever>" if that makes sense in a
particular case. You've made perfectly clear that for the UPS you tested
with, this is more true (and it indicates that this device doesn't follow
the megatec protocol). But instead of just trowing the towel in the ring
and let the user (and all client applications) figure out what a
particular reading means, you could also make this configurable in the
driver through startup options (after all, that's the main purpose of the
drivers, make all UPS'es appear similar to the server/clients).

Two remarks here:

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).

Best regards, Arjen

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).