On Wednesday, November 23, 2016 at 8:58:03 AM UTC-5, Cameron D wrote:
>
> More pain...
>>
>
> When I start usb capture and directly run either v0.9 or the v0.15rc3 I
> get the same immediate crash
> The last lines of the stack trace are
> File "weewx/drivers/wmr300-v09.py", line 1045, in read
> if not e.args[0].find('No data available'):
> AttributeError: 'int' object has no attribute 'find'
>
>
> This happens on the very first read.
>
when pyusb creates a USBError, it puts the libusb errno and strerror into
an args member of the USBError exception. so our initial implementations
used the args member to figure out what kind of USBError was being raised.
apparently the use of args changed at some point - i'm not sure whether the
change was due to pyusb or libusb.
so i modified the weewx usb drivers to use repr instead - that stringifies
the USBError in a way that seems to have worked across pyusb and libusb
versions.
you can see the difference in 3 places in 0.15rc3 where the USBError is
handled.
i am confused by the reports that say "weewx 3.6.2 with driver 0.9 works,
but weewx 3.6.2 with driver 0.15rc2 does not work". afaict, that should
not be possible.
> If I precede that line by "print e" I get: "[Errno 110] Operation timed
> out"
>
> The only other thing I noticed in the capture was a control packet :
> USBHID SET_IDLE request
> and an acknowledgement that it was successful.
> This only happens the first time - when the kernel detach succeeds.
> However, I have sometimes seen it on a windows capture as well, so I don't
> think it is significant.
>
the timeouts seem to happen when the station has stopped spewing on the
usb. if that is the root cause of timeouts, then the question is "how do
we get it to start spewing again?" i have only seen the timeout when
starting weewx. starting weewx a second time resulted in normal behavior.
so using loop_on_init is a workaround for that, but it does not tell us
what part of the driver initialization causes the station to start usb
spewage. more significantly, there might be cases where someone is getting
timeouts, and multiple attempts at starting weewx does not make the
timeouts go away.
localization comes into play in the detection of the USBError type. when
we get a 'no data available' or 'no error' USBError, we ignore them. these
are not really errors (especially not the 'no error' "error"), so we do not
want to raise exceptions. when localization changes the string from 'No
data available' to the equivalent in de, es, or fr, an exception is raised
instead of being ignored.
so there are two things to sort out:
1) how to determine the USBError type without:
a) using the member args, which is dependent on libusb/pyusb version
b) parsing for a 'no data available' string that depends on locale
2) how to get the station to start jabbering (assuming that the timeouts
are because the station is not jabbering). of course, this might be more
complicated if the root cause is a more subtle usb comm issue rather than
just getting the station to start talking.
so what do we do?
- for each test, we need to know:
- what version of libusb
- what version of pyusb
- what version of weewx
- what version of wmr300
- test the following:
- start up weewx
- test permutations
- weewx versions: 3.5.0, 3.6.2
- wmr300 versions: 0.9, 0.15rc2, 0.15rc3
- libusb versions: 1.0.x, 0.1.x
- pyusb versions: 0.4, 1.0
the number of different libusb and pyusb versions is bigger. for example,
i have seen a significant differences between libusb 1.0.11, libusb 1.0.19,
and libusb 1.0.20.
we should be able to prune the number of permutations if we could get a
report of exactly what is working and what is not working to this point.
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.
