[Nut-upsdev] some megatec-usb issues

[Arjen de Korte]

>> 2. "UPS No Ack" problem.
>>
>> I also have a solution for the problem of the "UPS No Ack" answers.
>
> This is a driver-internal problem, as it does not require any other
> NUT files to be modified. You should implement the solution that works
> best for your device, and does not harm to any other devices. I think
> it would be reasonable to retry a failed request, say, up to N times,
> where N is some preset value (perhaps even user configurable). (You
> should not retry it an infinite number of times, because that could
> cause the driver to hang.

I think that we can solve this in a similar (broader) way as in the
server. That is, dstate_dataok() records the last time it was called and
we compare this time to the current time in the driver/main.c. If this is
more than maxage seconds ago (similar to the MAXAGE value defined in
upsd.conf, but now in ups.conf), dstate_datastale() will be called.

In many cases it is much easier to determine that a status poll was
successful, rather than determining the reason why it wasn't (timeout,
communication failure, UPS disconnected). If drivers no longer *must* call
dstate_datastale(), but by letting dstate_dataok() timeout automatically
if it hasn't been called recently, this will provide a more uniform
mechanism among different drivers. You'd only have to call dstate_dataok()
if you decoded a reply from the UPS successfully and do nothing if you
were not.

Of course, if a driver is able to unambiguously determine that a UPS is no
longer available, it would still be possible to call dstate_datastale(),
so the impact to existing drivers should be minimal. The only thing we
need to make sure that no driver is using an internal mechanism that only
calls dstate_dataok() once when coming from a dstate_datastale() situation
(which is not how dstate_dataok/datastale() was intended to be used
anyway).

Best regards, Arjen
-- 
Eindhoven - The Netherlands
Key fingerprint - 66 4E 03 2C 9D B5 CB 9B  7A FE 7E C1 EE 88 BC 57