[Nut-upsdev] instcmd "beeper.off "

[Peter Selinger]

Arjen de Korte wrote:
> 
> 
> >> 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). 

I have two such UPS, and the beeper.on command is not a no-op. It
undoes a previous beeper.mute command. 

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

The beeper.on command was always badly named, because of course it
does not turn the beeper on unless there is a reason to beep. It only
enables the beeper. 

How about three new commands:

beeper.enable
beeper.disable
beeper.mute

For backward compatibility, I would then also map beeper.on to
beeper.enable, and beeper.off to beeper.disable or beeper.mute as
appropriate for a given device.
 
> 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
>