[Nut-upsdev] Important regression in usbhid-ups (r1113)

[Arjen de Korte]

> I think one problem is that the APC does not implement an "ondelay" in
> any meaningful way.

...some APC units...

> You can set UPS.PowerSummary.DelayBeforeStartup, but it will not have any
> effect unless the UPS is already offline. And the only time it's going to
> be offline is if the user turned it off with the power button, because
> setting PowerSummary.DelayBeforeShutdown will always turn it off (after
> the specified delay) and then turn it back on after a fixed short delay
> or after AC power returns (whichever is later).

This probably depends on which version APC UPS you have. According to the
HID PCD, if the DelayBeforeShutdown countdown expires, it should not turn
the UPS back on. And if the DelayBeforeStartup countdown expires during a
utility failure, the startup shall not occur until the utility power is
restored.

What we used to have, left a complete datacenter powered with APC UPS'es
without power, because most drivers (except the 'mge-hid' one) would
effectively only send DelayBeforeShutdown, without ever restoring power
when the power returned.

> The BelkinUNV is even worse: if you set the startup delay, then the
> UPS will *definitely* come back on after the specified delay,
> regardless of whether the power has actually returned or not.

See above.

> This is almost never what one wants, and definitely not what the
> upsdrv_shutdown() should do.

I think the default behaviour should be to assume that the device follows
the HID PDC specification. If specific devices require something different
(ie, don't follow this specification), this must be handled on a VID:PID
specific basis, rather than for whole subdrivers. For both the 'apc-hid'
and 'belkin-hid' subdrivers, I have reports that what do now works, at
least for some models.

> Other UPSs behave yet differently. This was the reason to have
> device-specific shutdown routines.

Short of the mge-hid subdriver, none of the units implemented this in any
meaningful way until I submitted this patch (see above), they all had the
default code. So it was already broken for some devices, so if it is still
broken, we have neither gained nor lost something. One thing that really
bothers me here, is that it is so hard to get users to test this properly.
If this is a problem (and I take your word for it that it is for at least
some devices), we should have complaints rolling in, but we hardly ever
do.

> Also, in my opinion, a default offdelay of 20 seconds is useless.
> The default offdelay should be 0 seconds, because normally one shuts
> down the UPS as the last step in the computer's shutdown sequence.

This has been discussed to death long before. Summary is, that there are
worries that the hardware (disk drives mostly) may be damaged if you
suddenly remove power and it would be easier on the hardware if you allow
some time *after* sending the shutdown command to allow the attached
system to do it's system poweroff. Therefor, the delay should never be
zero by default (since that might be 'dangerous') and a delay of 20
seconds was chosen. If the UPS can't provide power long enough, nothing is
lost here, because the device was already going down anyway. If that's not
what you like, set 'offdelay = 0' in 'ups.conf'.

> If someone wants to send the UPS into a shutdown countdown while they
> are still continuing to boot down, then this is pretty risky, and in
> any case, 20 seconds will almost certainly be too short.

Sure, but this wasn't the reason to bump this to 20 seconds. And you can
also set that value higher if this is needed.

Best regards, Arjen