[Nut-upsdev] some megatec-usb issues

[Arjen de Korte]

Peter Selinger wrote:

> I think the issue at hand is device specific. Somehow, to get the
> data, one has to ask several times without intermittent delay. It does
> not seem to be a question of staleness, but rather a question of how
> to coax data from this (buggy, buggy!) device.

I'll trust you on this, I only superficially went through the last week
and a half of posts. Lets forget about this particular device and come
back to the suggestion of an automatic timeout for the
dstate_dataok/datastale() mechanism as proposed. Would this be useful or
not?

In case of parsing replies from a UPS where the useful info is embedded
in a lot of cruft we're not really interested in, calling
dstate_dataok() only when we've found something useful and ignoring the
rest might be easier than figuring out that the device is not responding
and calling dstate_datastale(). I recall the problems with the
repetitive data stale/data ok messages on the newhidups driver we saw
two weeks ago.

Another thing is what to do with occasional hiccups in the communication
with the UPS. The serial UPS'es I have here occasionally (once or twice
a week) miss a status poll. While this isn't really much of a problem, I
don't think that calling dstate_datastale() immediately after a single
failed status poll is appropriate either. I know a fix for this this can
be coded quite easily into the driver itself, however I can imagine that
other drivers may 'suffer' from the same problem. It might make sense to
add this to the common code for all drivers. See attachment.

Best regards, Arjen
-- 
Eindhoven - The Netherlands
Key fingerprint - 66 4E 03 2C 9D B5 CB 9B  7A FE 7E C1 EE 88 BC 57
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dstate_dead.diff
Type: text/x-patch
Size: 4189 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20070210/9766b3c2/dstate_dead.bin