figure out how to reset usb from software to fix acurite console flakiness about weewx HOT 5 CLOSED

something similar happens with the te923 driver as well. during startup, the te923 driver sometimes encounters random/leftover data on the usb. the driver ignores the data, but sometimes it fails multiple times before the buffer is flushed, sometimes resulting in weewx failing to start up.

this also happens with the wmr300 driver.

need to figure out how to flush the usb to get it into a known/synchronized state.

from weewx.

no resolution yet for this, but i do have more data points and guidelines.

• when you do a usb reset, do it after you open the device (duh) but before you claim the interface. if you do a reset after you claim the interface, then you must re-claim the interface, otherwise you'll get 'no permission' or 'attempt to use device without claiming the interface'
• on fine offset ws2300 hardware, a reset is only required if you bodge the usb comms. for example, if you do a read or write with bogus preamble (in the case of this hardware, the first two bytes), the firmware gets confused and will not respond until you wait awhile or do a reset. sometimes waiting awhile does not work. so it is possible to un-wedge a ws2300 by doing a usb reset, unlike the 10xx/20xx/30xx which only un-wedge by doing a power cycle.
• behavior of the acurite hardware is not as consistent (also, i have only one model on which to test, and apparently there is significant difference in firmware between the 0103x, 02032, and 02064 models). usb reset seems to help with the 01036, but seems to cause problems with the 02032. no data yet for the 02064.
• the te932 seems to be fairly robust/repeatable wrt usb initialization. it consistently fails the first attempt to read data (the driver misses the first byte). but then works flawlessly. reset is not required, and does not eliminate the first bad read. (the te923tool seems to not have the first read problem. not sure about wview - too much overhead and complexity to test it.)
• the reset seems to make no difference on the wmr300, but that is based on a very tiny sample size - only a few days of testing, and no extensive testing of getting the firmware to lock up.
• beware of different library versions. the significant differences are in pyusb (0.4.3 vs 1.0.0) and libusb (0.x vs 1.x). my dev and testing is mostly on pyusb 0.4.3. pyusb is supposed to transparently handle differences between libusb versions, but i'm not sure that it actually does. i have only anecdotal results for this, and no comprehensive coverage of the different combinations of operating systems and library versions.
• beware localization. some of the drivers test for the 'no data' string from libusb. that code will not work as designed on systems where the libusb strings have been translated.
• there is some usb wierdness in recent versions of redhat derivatives, including fedora and centos. they do not report the usb device or bus in the driver's 'find' code, yet they seem to function properly.

unfortunately i have not yet found a solution that works across all types of hardware.

from weewx.

Sounds like we may need to write a usb shim, much like weedb, that takes care of the different versions of pyusb and acts as a repository of different reset strategies.

from weewx.

pywws has such a shim implementation. the pywws distribution includes usb implementations for ctypes_hidapi, cython_hidapi, libusb1, pyusb, and pyusb1.

in this case, the shim is more important for dealing with HID issues; a usb shim is necessary for macos, since on macos there is no reliable way to prevent the kernel from claiming HID devices.

we might be able to generalize a weeusb shim to address both the reset issues and the hid issues.

we have a bunch of working implementations for a wide variety of hardware, so that should help with the shim design :)

from weewx.

resets have no effect.

from weewx.