I will try to see if installing that libusb package works on the busted install tomorrow (if I don't forget).
I managed to work my way into a functional install on bookworm this evening by doing an (unsupported, not recommended) in-place upgrade starting from my working Bullseye install. Maybe something was installed with bullseye that was not included with bookworm, and then kept when i did the upgrade/dist-upgrade. No clue, kinda beyond my skills to guess. On Monday, July 21, 2025 at 9:47:25 PM UTC-5 vince wrote: > Wild guess here - can you see if you can install the libusb-0.1 package on > your broken card ? (https://packages.debian.org/stable/libusb-0.1-udeb) > > sudo apt search libusb # then look for the versions there > sudo apt-get install libusb-0.1-4 # my zerow running raspios bookworm > had this available > > My zerow running raspios bookworm 'did' install the older version ok, but > I can't really test it here since I don't have your hardware. But the > older library does install. Maybe that'll help. > > I also found some old threads suggesting sometimes plugging a low-speed > USB device into a high-speed port can cause issues, but if sd-card-A works > and sd-card-B does not work, assuming you didn't change what USB devices > were plugged in where, then it has to be something in the versions of the > underlying usb libs or python modules. > > Other than quantifying which usb packages and python modules a working > system has vs. what a non-working system has installed, I can't think of > much more to try other than adding the older libs ala the above commands, > (possibly) doing the unplug/poweroff/powerup/plug-in thing and trying weewx > again interactively and seeing if that helps. > > On Monday, July 21, 2025 at 7:08:04 PM UTC-7 Justin Wilczek wrote: > >> I think I have been fighting the same/similar issue with a fresh install >> of Raspbian Bookworm on a Pi 2. >> >> I was running weewx on a Pi OS Buster install for a long while (actually >> Openhabian). Long story short I ran into some dependency issues with python >> package versions that weren't available on Buster, so I decided to just >> wipe and go with a clean install of Bookworm. >> >> Re-imaged the card with Bookworm, installed Weewx, copied over my backed >> up config and database, and installed nginx. Looked like everything was OK >> because it went fast enough I didn't notice anything missing on the web >> page. Couple days later I noticed it was not updating, and checked the logs >> to see errors. >> >> My dmesg output on the Bookworm install looked similar to yours. >> What stood out to me were the " usbhid 3-1:1.0: can't add hid device: -22" >> and " usbhid 3-1:1.0: probe with driver usbhid failed with error -22" >> >> I also had *similar* but not quite identical messages from weewx. >> However instead of "Input/Output error" or "Operation timed out" I had >> "Pipe Errors". >> >> So I decided to just image a spare card back to Buster and try again. >> Haven't copied over my database backup yet, but the station worked right >> away. >> >> The dmesg output was also missing those usbhid errors. So I suspect some >> deeper issues with the device being set up. >> >> ```dmesg >> [ 2432.286803] usb 1-1.3: USB disconnect, device number 4 >> [ 2433.864896] usb 1-1.3: new low-speed USB device number 5 using dwc_otg >> [ 2434.003001] usb 1-1.3: New USB device found, idVendor=24c0, >> idProduct=0003, bcdDevice= 0.20 >> [ 2434.003048] usb 1-1.3: New USB device strings: Mfr=0, Product=2, >> SerialNumber=0 >> [ 2434.003071] usb 1-1.3: Product: Chaney Instrument >> [ 2434.016564] input: Chaney Instrument as >> /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/0003:24C0:0003.0002/input/input2 >> [ 2434.017242] hid-generic 0003:24C0:0003.0002: input,hidraw0: USB HID >> v1.11 Device [Chaney Instrument] on usb-3f980000.usb-1.3/input0 >> ``` >> >> >> On Saturday, July 19, 2025 at 3:32:47 PM UTC-5 vince wrote: >> >>> I would try doing a venv (pip) installation since everything weewx and >>> python will be all self-contained in the venv tree. You can’t break it if >>> it doesn’t work anyway >>> >>> On Saturday, July 19, 2025 at 12:09:37 PM UTC-7 James J Dempsey wrote: >>> >>>> I think I have narrowed this down. I'm now thinking the problem is >>>> that when finding the USB device, the code is returning a >>>> usb.legacy.Device when (maybe?) it should be getting a usb.Device. >>>> >>>> I'm thinking this because where the acurite driver code logs: >>>> >>>> log.debug('Found station at bus=%s device=%s' % >>>> (bus.dirname, dev.filename)) >>>> >>>> It's actually logging: "Found station at bus= device=" with no values. >>>> This implies that the code thinks the bus id is stored in bus.dirname >>>> and the device id is stored in dev.filename. >>>> >>>> However, the device I'm finding is of class usb.legacy.device where >>>> the bus id is stored in bus.location and the device id is stored in >>>> dev.devnum. >>>> >>>> I wrote this script to show this. (Be kind, I'm not generally a python >>>> programmer.) >>>> >>>> import os >>>> import usb >>>> >>>> vendor_id = 0x24c0 >>>> product_id = 0x0003 >>>> device_id = None >>>> >>>> bus='' >>>> dev='' >>>> >>>> command="lsusb | egrep weather" >>>> print("Output of '%s':" % (command)) >>>> os.system(command) >>>> print("") >>>> >>>> print("Searching for vendor_id = %s, product_id = %s" % >>>> (hex(vendor_id), hex(product_id))) >>>> >>>> # This code mimics the code in the acurite driver for finding the >>>> weather station device >>>> for thisbus in usb.busses(): >>>> for thisdev in thisbus.devices: >>>> if thisdev.idVendor == vendor_id and thisdev.idProduct == >>>> product_id: >>>> if device_id is None or thisdev.filename == device_id: >>>> print('Acurite driver code logs: Found station at >>>> bus=%s device=%s' % >>>> (thisbus.dirname, thisdev.filename)) >>>> bus=thisbus >>>> dev=thisdev >>>> >>>> >>>> print("class of dev is %s" % (type(dev))) >>>> print("") >>>> print("dev.idVendor is %s" % (hex(dev.idVendor))) >>>> print("dev.idProduct is %s" % (hex(dev.idProduct))) >>>> print("") >>>> print("acurite driver code logs:") >>>> print("bus.dirname is '%s'" % (bus.dirname)) >>>> print("dev.filename is '%s'" % (dev.filename)) >>>> print("") >>>> print("but values are actually stored as:") >>>> print("bus.location is '%s'" % (bus.location)) >>>> print("dev.devnum is '%s'" % (dev.devnum)) >>>> >>>> exit() >>>> >>>> On the Raspberry Pi 5, the output of this is: >>>> >>>> Output of 'lsusb | egrep weather': >>>> Bus 003 Device 004: ID 24c0:0003 Chaney Instrument Model 01036 weather >>>> center >>>> >>>> Searching for vendor_id = 0x24c0, product_id = 0x3 >>>> Acurite driver code logs: Found station at bus= device= >>>> class of dev is <class 'usb.legacy.Device'> >>>> >>>> dev.idVendor is 0x24c0 >>>> dev.idProduct is 0x3 >>>> >>>> acurite driver code logs: >>>> bus.dirname is '' >>>> dev.filename is '' >>>> >>>> but values are actually stored as: >>>> bus.location is '3' >>>> dev.devnum is '4' >>>> >>>> Reading about the pyusb library, it says that if your code is getting >>>> usb.legacy.device, it's because: >>>> >>>> "The appearance of usb.legacy.device in your Python application using >>>> pyusb and libusb indicates that your code or the underlying pyusb library >>>> is interacting with the older libusb-0.1 API, often referred to as the >>>> "legacy" interface, and not libusb-1.0." >>>> >>>> Looking on my device, I don't even have libusb-0.1 -- only libusb-1.0. >>>> >>>> $ dpkg -l | egrep libusb >>>> ii libgusb2:arm64 0.3.10-1 >>>> arm64 GLib wrapper around libusb1 >>>> ii libusb-1.0-0:arm64 2:1.0.26-1 >>>> arm64 userspace USB programming library >>>> ii libusbmuxd6:arm64 2.0.2-3 >>>> arm64 USB multiplexor daemon for iPhone and iPod Touch >>>> devices - library >>>> $ >>>> >>>> Yet, somehow I'm getting a usb.legacy.Device and not a usb.Device. >>>> >>>> This information might also be useful: >>>> $ pip freeze | egrep usb >>>> pyusb==1.2.1.post2 >>>> $ >>>> >>>> I presume that the usb.legacy.Device is somehow incompatible with the >>>> rest of the acurite driver, just as it was incompatible with printing out >>>> the bus and device ids. >>>> >>>> I also presume the fix for this is likely in some sort of python >>>> library configuration/installation, but I'm not sure how to do that. >>>> >>>> On Friday, July 18, 2025 at 4:29:59 PM UTC-4 vince wrote: >>>> >>>>> The driver hard-codes the usb vendor/product it's looking for so if >>>>> you have only the station plugged in (after a power cycle), it hopefully >>>>> will find it. Being able to ssh into the pi from your LAN, at least >>>>> temporarily, would possibly help get down to some stable setup. I know >>>>> in >>>>> the past when I did things like move which port things were attached to >>>>> the >>>>> devices it resulted in moved around. FWIW - always plug stuff into the >>>>> same port if you can't use udev rules. >>>>> >>>>> On Friday, July 18, 2025 at 12:56:09 PM UTC-7 James J Dempsey wrote: >>>>> >>>>>> Thank you, vince, for your reply. It's very helpful. >>>>>> >>>>>> The OS I'm running is "Linux 6.12.34+rpt-rpi-2712 #1 SMP PREEMPT >>>>>> Debian 1:6.12.34-1+rpt1~bookworm (2025-06-26) aarch64 GNU/Linux" >>>>>> according >>>>>> to raspinfo. >>>>>> >>>>>> It's connected to the local network via Ethernet. There's a monitor >>>>>> connected via HDMI. >>>>>> >>>>>> On USB, it has the Acurite weather station (model 01536), a Microsoft >>>>>> Intellimouse, a Macally Small USB Wired Keyboard that reports itself >>>>>> as >>>>>> "GASIA USB KB V11" and a CyberPower CP1500PFCLCD UPS. Perhaps I should >>>>>> try >>>>>> removing some devices or switching the kbd/mouse to see if makes a >>>>>> difference. >>>>>> >>>>>> I will try the python USB test code you mention and maybe I'll try to >>>>>> modify the acurite driver to hardwire the device ids just as a test. >>>>>> >>>>>> Thank you again, >>>>>> >>>>>> --Jim-- >>>>>> >>>>>> >>>>>> On Friday, July 18, 2025 at 1:06:14 PM UTC-4 vince wrote: >>>>>> >>>>>>> What precise os are you running on the pi ? What exactly is >>>>>>> connected to the pi and how ? >>>>>>> >>>>>>> I might add that plugging/unplugging stuff in can 'really' confuse a >>>>>>> pi. Suggest you power down, unplug the station, power up, and plug >>>>>>> the >>>>>>> station in and then don't touch things connected to USB. >>>>>>> >>>>>>> (disclaimer - not an acurite user but....) >>>>>>> >>>>>>> The acurite driver doesn't seem to accept an option telling it which >>>>>>> /dev device to use, so I'm wondering whether a udev rule does/doesn't >>>>>>> even >>>>>>> help, but regardless take a look around line 920 or so in the driver >>>>>>> /usr/share/weewx/weewx/drivers/acurite.py and perhaps add some more >>>>>>> debugging info there before it returns None >>>>>>> >>>>>>> The driver uses the usb python module to figure out what's connected >>>>>>> to the usb busses. I found a script in >>>>>>> https://stackoverflow.com/questions/8110310/simple-way-to-query-connected-usb-devices-info-in-python >>>>>>> >>>>>>> that should return the same info the driver is parsing. I've appended >>>>>>> the >>>>>>> 'code updated for python3' answer from that person below, with the last >>>>>>> two >>>>>>> lines added below for readability in its output. >>>>>>> >>>>>>> import re >>>>>>> import subprocess >>>>>>> device_re = >>>>>>> re.compile(b"Bus\s+(?P<bus>\d+)\s+Device\s+(?P<device>\d+).+ID\s(?P<id>\w+:\w+)\s(?P<tag>.+)$", >>>>>>> >>>>>>> re.I) >>>>>>> df = subprocess.check_output("lsusb") >>>>>>> devices = [] >>>>>>> for i in df.split(b'\n'): >>>>>>> if i: >>>>>>> info = device_re.match(i) >>>>>>> if info: >>>>>>> dinfo = info.groupdict() >>>>>>> dinfo['device'] = '/dev/bus/usb/%s/%s' % >>>>>>> (dinfo.pop('bus'), dinfo.pop('device')) >>>>>>> devices.append(dinfo) >>>>>>> >>>>>>> for dev in devices: >>>>>>> print(dev) >>>>>>> >>>>>>> Just as an example - my pi4 returns: >>>>>>> {'id': b'1d6b:0003', 'tag': b'Linux Foundation 3.0 root hub', >>>>>>> 'device': "/dev/bus/usb/b'002'/b'001'"} >>>>>>> {'id': b'067b:2303', 'tag': b'Prolific Technology, Inc. PL2303 >>>>>>> Serial Port / Mobile Action MA-8910P', 'device': >>>>>>> "/dev/bus/usb/b'001'/b'003'"} >>>>>>> {'id': b'2109:3431', 'tag': b'VIA Labs, Inc. Hub', 'device': >>>>>>> "/dev/bus/usb/b'001'/b'002'"} >>>>>>> {'id': b'1d6b:0002', 'tag': b'Linux Foundation 2.0 root hub', >>>>>>> 'device': "/dev/bus/usb/b'001'/b'001'"} >>>>>>> >>>>>>> and lsusb returns: >>>>>>> Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub >>>>>>> Bus 001 Device 003: ID 067b:2303 Prolific Technology, Inc. PL2303 >>>>>>> Serial Port / Mobile Action MA-8910P >>>>>>> Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub >>>>>>> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >>>>>>> >>>>>>> So they match, FWIW, although dmesg returns a value that is offset >>>>>>> by one (count from zero vs. count from one inconsistency maybe) >>>>>>> usb 1-1.2: pl2303 converter now attached to ttyUSB0 >>>>>>> >>>>>>> So for me on a Vantage which 'does' support the port=/dev/whatever >>>>>>> option, I fortunately can just say /dev/ttyUSB0. Acurite doesn't seem >>>>>>> to >>>>>>> be so flexible unfortunately. >>>>>>> >>>>>>> The acurite driver commentary and lots of weewx threads here suggest >>>>>>> acurite hardware can get funky when powered up/down too, but I'm not an >>>>>>> acurite user so I can't say more there. See the driver commentary for >>>>>>> more >>>>>>> info than my brain can parse this morning. >>>>>>> >>>>>>> Hope this helps. >>>>>>> >>>>>>> On Friday, July 18, 2025 at 7:54:01 AM UTC-7 James J Dempsey wrote: >>>>>>> >>>>>>>> Peter Quinn (p q) suggests that maybe the problem with weewx not >>>>>>>> finding the Acurite station might be permissions. >>>>>>>> >>>>>>>> That's a great suggestion, but I don't think it is permissions. >>>>>>>> >>>>>>>> I have added user weewx to all the groups I'm in: >>>>>>>> dialout,cdrom,sudo,audio,video,plugdev,games,users,input,render,netdev,spi,i2c,gpio >>>>>>>> >>>>>>>> and weewx (just to be sure). >>>>>>>> I also tried running weewx from the command line as root with the >>>>>>>> same result of not finding the device. >>>>>>>> >>>>>>>> I'm starting to think it's a problem of USB device numbering w.r.t. >>>>>>>> whatever strategy weewx is using vs. the Raspberry Pi 5. >>>>>>>> >>>>>>>> It makes me ask the question: Is anyone out there using an Acurite >>>>>>>> station with weewx on a Raspberry Pi 5 successfully? (I would expect >>>>>>>> the >>>>>>>> answer is yes, but I want to be sure.) >>>>>>>> >>>>>>>> More details follow: >>>>>>>> >>>>>>>> To try to understand this, I ran weewx under strace. >>>>>>>> >>>>>>>> Currently, lsusb shows: (I've been trying different ports) >>>>>>>> Bus 003 Device 003: ID 045e:001e Microsoft Corp. IntelliMouse >>>>>>>> Explorer >>>>>>>> >>>>>>>> Bus 003 Device 002: ID 24c0:0003 Chaney Instrument Model 01036 >>>>>>>> weather >>>>>>>> center >>>>>>>> >>>>>>>> Here is some strace output. >>>>>>>> >>>>>>>> openat(AT_FDCWD, "/sys/bus/usb/devices/usb4/descriptors", >>>>>>>> O_RDONLY|O_CLOEXEC) = 9 >>>>>>>> read(9, >>>>>>>> "\22\1\0\3\t\0\3\tk\35\3\0\22\6\3\2\1\1\t\2\37\0\1\1\0\340\0\t\4\0\0\1"..., >>>>>>>> >>>>>>>> 256) = 49 >>>>>>>> close(9) = 0 >>>>>>>> recvfrom(7, NULL, 0, MSG_PEEK|MSG_TRUNC, NULL, NULL) = -1 EAGAIN >>>>>>>> (Resource temporarily unavailable) >>>>>>>> mmap(NULL, 1048576, PROT_READ|PROT_WRITE, >>>>>>>> MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ffece280000 >>>>>>>> getpid() = 2492 >>>>>>>> >>>>>>>> This next line is where it puts this in the log: >>>>>>>> Jul 15 20:01:12 capecod weewxd[2969]: DEBUG weewx.drivers.acurite: >>>>>>>> Found station at bus= device= >>>>>>>> (where bus= and device= indicate it hasn't found the port of the >>>>>>>> acurite properly) >>>>>>>> >>>>>>>> sendto(3, "<15>weewxd[2492]: DEBUG weewx.dr"..., 77, 0, NULL, 0) = >>>>>>>> 77 >>>>>>>> >>>>>>>> Then it tries to open /dev/bus/usb/003/002 which seems like it >>>>>>>> maybe (?) matches the lsusb output above. However, when I cat >>>>>>>> /sys/bus/usb/devices/3-2/product the result is "Microsoft >>>>>>>> IntelliMouse® >>>>>>>> Explorer" which seems wrong. If it's opening the wrong usb device, >>>>>>>> it's >>>>>>>> not surprise it isn't working. >>>>>>>> >>>>>>>> openat(AT_FDCWD, "/dev/bus/usb/003/002", O_RDWR|O_CLOEXEC) = 9 >>>>>>>> >>>>>>>> Then it tries to do a bunch of ioctls on that device, most of which >>>>>>>> seem to fail. >>>>>>>> >>>>>>>> ioctl(9, USBDEVFS_GET_CAPABILITIES, 0x1a4cdb84) = 0 >>>>>>>> ioctl(9, USBDEVFS_GETDRIVER, 0x7fffd72b96b0) = -1 ENODATA (No data >>>>>>>> available) >>>>>>>> ioctl(9, USBDEVFS_IOCTL, 0x7fffd72b96a0) = -1 ENODATA (No data >>>>>>>> available) >>>>>>>> ioctl(9, USBDEVFS_SETCONFIGURATION, 0x7fffd72b960c) = -1 EPROTO >>>>>>>> (Protocol error) >>>>>>>> ioctl(9, USBDEVFS_CLAIMINTERFACE, 0x7fffd72b95d4) = 0 >>>>>>>> openat(AT_FDCWD, "/sys/bus/usb/devices/3-1/bConfigurationValue", >>>>>>>> O_RDONLY|O_CLOEXEC) = 10 >>>>>>>> read(10, "1\n", 19) = 2 >>>>>>>> close(10) = 0 >>>>>>>> ioctl(9, USBDEVFS_SETINTERFACE, 0x7fffd72b95b0) = -1 EPROTO >>>>>>>> (Protocol error) >>>>>>>> timerfd_settime(6, TFD_TIMER_ABSTIME, {it_interval={tv_sec=0, >>>>>>>> tv_nsec=0}, it_value={tv_sec=200, tv_nsec=288749571}}, NULL) = 0 >>>>>>>> ioctl(9, USBDEVFS_SUBMITURB, 0x1a49efd0) = 0 >>>>>>>> read(5, "\1\0\0\0\0\0\0\0", 8) = 8 >>>>>>>> ppoll([{fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=9, >>>>>>>> events=POLLOUT}], 3, {tv_sec=60, tv_nsec=0}, NULL, 0) = 1 ([{fd=9, >>>>>>>> revents=POLLOUT}], left {tv_sec=59, tv_nsec=997897751}) >>>>>>>> ioctl(9, USBDEVFS_REAPURBNDELAY, 0x7fffd72b95b0) = 0 >>>>>>>> timerfd_settime(6, 0, {it_interval={tv_sec=0, tv_nsec=0}, >>>>>>>> it_value={tv_sec=0, tv_nsec=0}}, NULL) = 0 >>>>>>>> ioctl(9, USBDEVFS_REAPURBNDELAY, 0x7fffd72b95b0) = -1 EAGAIN >>>>>>>> (Resource temporarily unavailable) >>>>>>>> ioctl(9, USBDEVFS_RELEASEINTERFACE, 0x7fffd72b9534) = 0 >>>>>>>> getpid() = 2492 >>>>>>>> sendto(3, "<11>weewxd[2492]: ERROR weewx.dr"..., 117, 0, NULL, 0) = >>>>>>>> 117 >>>>>>>> clock_nanosleep(CLOCK_MONOTONIC, TIMER_ABSTIME, {tv_sec=229, >>>>>>>> tv_nsec=291213340}, >>>>>>>> >>>>>>>> It feels to me like it's somehow getting confused about the >>>>>>>> bus/device/port numbers. >>>>>>>> >>>>>>>> Not sure how to proceed. I would have thought that lots of people >>>>>>>> would have already run weeewx on pi 5, so I would be surprised if this >>>>>>>> were >>>>>>>> a software bug. >>>>>>>> >>>>>>>> --Jim-- >>>>>>>> >>>>>>>> On Tuesday, July 15, 2025 at 4:53:52 PM UTC-4 p q wrote: >>>>>>>> >>>>>>>> The code in question is: >>>>>>>> >>>>>>>> def _find_dev(vendor_id, product_id, device_id=None): >>>>>>>> """Find the vendor and product ID on the USB.""" >>>>>>>> for bus in usb.busses(): >>>>>>>> for dev in bus.devices: >>>>>>>> if dev.idVendor == vendor_id and dev.idProduct == >>>>>>>> product_id: >>>>>>>> if device_id is None or dev.filename == >>>>>>>> device_id: >>>>>>>> log.debug('Found station at bus=%s >>>>>>>> device=%s' % >>>>>>>> (bus.dirname, dev.filename)) >>>>>>>> return dev >>>>>>>> return None >>>>>>>> >>>>>>>> So, it's failing to find your station on USB. Could it be security? >>>>>>>> Does the user running Weewx have permissions to read the USB? >>>>>>>> >>>>>>>> You might try to run Weewx from the command line and see what it >>>>>>>> says. If my guess about permissions is correct, it will run. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Jul 15, 2025 at 1:29 PM James J Dempsey wrote: >>>>>>>> >>>>>>>> I was running my Acurite station on an ODroid N2 and have switched >>>>>>>> to a Raspberry Pi 5. The ODroid was running 5.1.0 on Ubuntu Lite. It >>>>>>>> worked fine on the ODroid (for years) and I can't get it working on >>>>>>>> the Pi >>>>>>>> 5. >>>>>>>> >>>>>>>> I installed weewx 5.1.0 fresh on the Pi 5, following the weewx >>>>>>>> instructions for debian. I moved my config file and sqlite database >>>>>>>> from >>>>>>>> the old system to the new system. >>>>>>>> >>>>>>>> It appears that weewx can't find the station on the Pi 5 -- I see >>>>>>>> this in the log: >>>>>>>> >>>>>>>> DEBUG weewx.drivers.acurite: Found station at bus= device= >>>>>>>> >>>>>>>> I assume there should be values after the = signs. lsusb shows: >>>>>>>> >>>>>>>> Bus 003 Device 002: ID 24c0:0003 Chaney Instrument Model 01036 >>>>>>>> weather center >>>>>>>> >>>>>>>> and raspinfo reports: >>>>>>>> >>>>>>>> /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/2p, 480M >>>>>>>> |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=, >>>>>>>> 1.5M >>>>>>>> |__ Port 2: Dev 3, If 0, Class=Human Interface Device, >>>>>>>> Driver=usbhid, 1.5M >>>>>>>> >>>>>>>> I see this in dmesg output: >>>>>>>> [ 0.969754] usb 3-1: New USB device found, idVendor=24c0, >>>>>>>> idProduct=0003, bcdDevice= 0.20 >>>>>>>> [ 0.969758] usb 3-1: New USB device strings: Mfr=0, Product=2, >>>>>>>> SerialNumber=0 >>>>>>>> [ 0.969760] usb 3-1: Product: Chaney Instrument >>>>>>>> [ 0.984789] usbhid 3-1:1.0: can't add hid device: -22 >>>>>>>> [ 0.989868] usbhid 3-1:1.0: probe with driver usbhid failed with >>>>>>>> error -22 >>>>>>>> >>>>>>>> The model of the Acurite device is ostensibly 01536. Since the >>>>>>>> lsusb output shows 01036, I also tried setting that in the config with >>>>>>>> no >>>>>>>> difference. I have tried multiple USB ports. >>>>>>>> >>>>>>>> Any suggestions would be appreciated. More details appended at the >>>>>>>> end. >>>>>>>> >>>>>>>> Thank you. >>>>>>>> >>>>>>>> --Jim-- >>>>>>>> >>>>>>>> ***** Portion of weewx.conf ***** >>>>>>>> >>>>>>>> # This section is for information about the station. >>>>>>>> >>>>>>>> [Station] >>>>>>>> >>>>>>>> # Description of the station location, such as your town. >>>>>>>> location = "Where I live" >>>>>>>> >>>>>>>> ... >>>>>>>> >>>>>>>> # Set to type of station hardware. There must be a >>>>>>>> corresponding stanza >>>>>>>> # in this file, which includes a value for the 'driver' option. >>>>>>>> station_type = AcuRite >>>>>>>> >>>>>>>> ... >>>>>>>> >>>>>>>> >>>>>>>> ############################################################################## >>>>>>>> >>>>>>>> [AcuRite] >>>>>>>> # This section is for AcuRite weather stations. >>>>>>>> >>>>>>>> # The station model, e.g., 'AcuRite 01025' or 'AcuRite 02032C' >>>>>>>> # (I also tried AcuRite 01536) >>>>>>>> model = AcuRite 01036 >>>>>>>> >>>>>>>> # The driver to use: >>>>>>>> driver = weewx.drivers.acurite >>>>>>>> >>>>>>>> ***** Section of log file ***** >>>>>>>> >>>>>>>> Jul 15 11:50:10 capecod weewxd[3985]: DEBUG weewx.engine: Finished >>>>>>>> loading service weewx.engine.StdReport >>>>>>>> Jul 15 11:50:10 capecod weewxd[3985]: INFO __main__: Starting up >>>>>>>> weewx version 5.1.0 >>>>>>>> Jul 15 11:50:10 capecod weewxd[3985]: DEBUG weewx.engine: Station >>>>>>>> does not support reading the time >>>>>>>> Jul 15 11:50:10 capecod weewxd[3985]: INFO weewx.engine: Using >>>>>>>> binding 'wx_binding' to database 'weewx.sdb' >>>>>>>> Jul 15 11:50:10 capecod weewxd[3985]: INFO weewx.manager: Starting >>>>>>>> backfill of daily summaries >>>>>>>> Jul 15 11:50:10 capecod weewxd[3985]: INFO weewx.manager: Daily >>>>>>>> summaries up to date >>>>>>>> Jul 15 11:50:10 capecod weewxd[3985]: INFO weewx.engine: Starting >>>>>>>> main packet loop. >>>>>>>> Jul 15 11:50:10 capecod weewxd[3985]: DEBUG weewx.drivers.acurite: >>>>>>>> Found station at bus= device= >>>>>>>> Jul 15 11:50:10 capecod weewxd[3985]: ERROR weewx.drivers.acurite: >>>>>>>> Failed attempt 1 of 10 to get LOOP data: [Errno 5] Input/Output Error >>>>>>>> Jul 15 11:50:40 capecod weewxd[3985]: DEBUG weewx.drivers.acurite: >>>>>>>> Found station at bus= device= >>>>>>>> Jul 15 11:50:41 capecod weewxd[3985]: ERROR weewx.drivers.acurite: >>>>>>>> Failed attempt 2 of 10 to get LOOP data: [Errno 110] Operation timed >>>>>>>> out >>>>>>>> (this repeats for 10 attempts and then stops the service and then >>>>>>>> restarts) >>>>>>>> >>>>>>>> ***** Hardware / Software ***** >>>>>>>> >>>>>>>> The Acurite is model 01536 (but lsusb reports 01036). >>>>>>>> >>>>>>>> The Raspberry Pi is is a Pi 5 Model B Rev 1.1. >>>>>>>> >>>>>>>> It is running Raspbian bookworm and is up to date as of today. >>>>>>>> >>>>>>>> -- 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]. To view this discussion visit https://groups.google.com/d/msgid/weewx-user/8d1d176e-ad77-42c0-98e2-3f5a4f28b9f6n%40googlegroups.com.
