[Nut-upsuser] Unitek UPS 1250xD - megatec_usb driver

[Arjen de Korte]

Carlos Rodrigues wrote:

> If the driver fails to get any data in the current polling cycle, it
> declares the data as stale until the next cycle. It tried to read the
> data, it got nothing, ergo the current data is stale.

That's a bit too harsh. Even serial communication is sometimes plagued
by communication errors (although probably not as often as the USB
devices seem to be for this class of UPS). Declaring the data stale on
the first failure is not a good idea, since this will trigger a lot of
actions in the server (and clients too) for no good reason at all. If
the communication is re-established within the next couple of polling
cycles, we don't want to hear about any problems.

> I don't agree
> the driver should systematically retry reading the status within a
> polling cycle.

You're absolutely right, it shouldn't! Instead, after a failure, it
should return from upsdrv_updateinfo() immediately and wait for the next
time it enters there. If after three tries, it still gets no data, it's
time to declare the data stale (but only then). By doing so you prevent
a lot of 'nuisance' tripping of the 'data stale' mechanism, while still
detecting reasonably fast that the UPS is gone.

In pseudo C code this looks as follows:

upsdrv_updateinfo()
{
	int		ret;
	static int	retry = 0;

	ret = status_poll();
	
	if (ret == failed) {
		
		ser_comm_fail("Oops! Poll failed!");

		if (retry < MAX_RETRIES) {
			retry++;
		} else {
			dstate_datastale();
		}

		return;
	}

	ser_comm_ok();

	retry = 0;

	/* parse the status */

	dstate_dataok();	/* this should come last! */
}

Note that this will mean that for the first couple of communication
errors, upsdrv_updateinfo() won't call dstate_datastale() nor
dstate_dataok(). That's OK. Only changes in the state will be sent to
the server, so as long as you don't intend to change the state, this is
not needed (it used to be, but that requirement has long gone).

> However, if communication failures are a systematic problem over USB,
> the USB layer should deal with it appropriately.

I don't think it can, unless it would repeat previous replies when
communication errors occur, until three consecutive failures. That's a
really bad idea.

Best regards, Arjen