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

[Arjen de Korte]

> Author: aquette
> Date: Thu Jun 21 07:43:46 2007
> New Revision: 971
>
> Log:
> fix communication lost status handling
>
> Modified:
>    trunk/ChangeLog
>    trunk/drivers/usbhid-ups.c
>
> Modified: trunk/ChangeLog
> ==============================================================================
> --- trunk/ChangeLog	(original)
> +++ trunk/ChangeLog	Thu Jun 21 07:43:46 2007
> @@ -1,3 +1,8 @@
> +Thu Jun 21 07:07:25 UTC 2007 / Arnaud Quette <aquette.dev at gmail.com>
> +
> + - usbhid-ups: improve the handling and reporting of the communication
> +   lost status. Previously, these were not reported anymore.

Short of the problem with this patch I mentioned earlier today, I don't
see how it is going to improve the situation. You can call
dstate_datastale() as often as you like, as long as the status doesn't
change, the driver will not report this to the server. This leaves the bad
side effect that I mentioned earlier, the driver locks up until the
communication with the UPS is re-established. I fear that this will lead
to wrong conclusions, where people are looking for communication problems
between driver and server, where they are actually between UPS and driver.

As far as I can see, reconnect_ups() is called in two locations:

1) right after entering upsdrv_updateinfo() if 'hd' is found to be NULL

2) near the end of hid_ups_walk(), where 'hd' is made NULL just before
calling reconnect_ups()

Effectively, this means that as long as 'hd' stays NULL(), the
reconnect_ups() function as it was, would be called every time
upsdrv_updateinfo() runs. Typically, this will happen every two seconds,
the default interval for polling a UPS. Since 'hd' will only be assigned a
value in reconnect_ups() and upsdrv_initups(), this is the case, right? So
it would try to re-establish the connection every so often.

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