[Nut-upsdev] instcmd "beeper.off "

[Arjen de Korte]

>> Therefor (in due time), if a UPS doesn't have a true 'beeper.off'
>> command (one that will stick for at least as long as the UPS is on), we
>> should remove both the 'beeper.off' and 'beeper.on' command and only
>> have a 'beeper.mute' command.
> I disagree with this last proposal. We should make the UPS's
> functionality available to the user, regardless of whether we think it
> is useful or not.

We should map the functionality of UPS features to NUT variables and
commands, no argument about that. However, if it turns out that there is a
mismatch, this should be corrected.

As stated before, on a UPS that only supports muting the beeper (ie, that
has no command for permanently silencing it), the 'beeper.on' command is a
no-op (the beeper will always be enabled). Since having 'beeper.on'
suggests there is a 'beeper.off' command also (as you rightfully stated
before), I think that if 'beeper.off' is not available, 'beeper.on' should
not be listed either.

I have no intention to implement this change anytime soon. Users should be
given ample warning time that for some drivers, the 'beeper.off' command
is replaced by 'beeper.mute'. If nobody comes up with a real 'beeper.off'
command (either through a command to the UPS or by implementing something
in the driver with the same effect), no functionality will be lost by
removing 'beeper.off' and 'beeper.on'.

> Certainly we shouldn't remove existing features out of a desire to
> legislate.

This is not the background of this proposal and I certainly don't intend
to police what drivers can and can't do. :-(

> I agree with the rest of your proposals though.

Good. Since Arnaud is not around to stop us, I will commit my first shot
at the implementation of the renaming from 'beeper.off' to 'beeper.mute'
later today. :-)

Best regards, Arjen