On Tuesday, February 14, 2017 at 8:08:15 PM UTC-5, Cameron D wrote:
>
> On Monday, 13 February 2017 03:26:27 UTC+10, Miguel Iniesta wrote:
>>
>> feb 12 18:20:39 raspberrypi weewx[4058]: wmr300: e.errno=None
>> e.strerror=None e.message=could not detach kernel driver from interface 0:
>> No data available repr=USBError('could not detach kernel driver from
>> interface 0: No data available',)
>> feb 12 18:20:39 raspberrypi weewx[4058]: wmr300: e.errno=None
>> e.strerror=None e.message=could not detach kernel driver from interface 0:
>> No data available repr=USBError('could not detach kernel driver from
>> interface 0: No data available',)
>> ...
>>
>
>
> This is actually an error in libusb0. From my testing, the error message
> about "could not detach..." is never cleared from the error string buffer
> because the condition "no data available" is not regarded as an error
> condition at some level.
>
agreed - i have seen this behavior with many different usb devices, not
just the wmr300. instead of returning an empty buffer, libusb0 raises an
'error' that simply says 'no data available'. btw, 'no data available' is
a localized string in libusb, and the pyusb bindings do not provide a code
to distinguish the type.
i am pretty sure that not every version of libusb behaves this way. even
more problematic is that there is no way to know the libusb version from
python (at least for older versions of pyusb), even if someone figured out
exactly which versions of libusb have this behavior and which do not.
as i understand it, the algorithm for wmr300:
- must not fail on 'no data available' "errors",
- must not fail on the first usb timeout,
- must fail on any usb timeouts after communication has been established,
- must fail on other usb errors
it must do this with every libusb version, or we need to figure out which
libusb version(s) are immune to this and only support those.
> The first time you run weewx after plugging the USB device in, the kernel
> automatically attaches it (at least it does on my system) and the weewx
> driver has to detach it to access it in a different mode.
> The next time (and subsequent times) weewx is run, the detach operation
> fails because it is no longer attached. This is OK, except for the spurious
> error message.
>
> You *should* still be getting data occasionally - if not then the wmr300
> console has gotten itself tied up in knots and you need to disconnect the
> USB and start again.
>
when the firmware is wedged, there is not much we can do.
it would be nice if there were a way to re-establish the communication with
the wmr300 *without* having to unplug/replug the usb. usb reset does not
do it. hubs with power control could be an option, but then the weather
station must have no batteries, must be bus-powered, and must retain logger
data through a power cycle.
m
--
You received this message because you are subscribed to the Google Groups
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
