I installed Ubuntu 24.04.3 on the Pi 5 and then installed latest weewx and everything worked fine, so this is a Raspbian software issue.
Just for completeness, I'll try installing latest Ubuntu 25.04 and try again just to see if the latest packages don't work. For reference, here are the steps I followed. Note that I installed package python3-usb and not python3-usb1. Install ubuntu 24.04.3 LTS for ARM https://cdimage.ubuntu.com/releases/25.04/release/ubuntu-25.04-desktop-arm64.iso 1. (download ubuntu, unxz, use Raspberry Pi Iimager tool to put .img on microsd card) 2. sudo apt install lighttpd 3. sudo apt install python3-usb 4. Follow weewx install instructions incl 'sudo apt install weewx'. 5. Create group called 'usb' 6. sudo chgrp -R usb /dev/bus/usb 7. sudo systemctl restart weewx On Monday, August 11, 2025 at 10:22:50 AM UTC-4 James J Dempsey wrote: > Sadly, bullseye Raspbian doesn't support the Pi 5 hardware. Perhaps I'll > try Ubuntu. > > On Monday, August 11, 2025 at 9:53:22 AM UTC-4 James J Dempsey wrote: > >> Justin - it does sound as if your problem is very similar if not >> identical. >> >> I tried installing libusb-0.1-4 and rebooting which didn't fix anything, >> though a good suggestion. >> >> I tried removing libusb-1.0-0, but as a side effect it wanted to remove a >> bunch of other important packages (including weewx!) so I was unwilling to >> do that. >> >> On other suggestions: I tried removing all other USB devices and moving >> the acurite to both the USB 3.0 ports and the 2.0 ports. Neither made a >> difference. >> >> I tried using a powered USB hub (no difference) and high-powered usb-c >> power supply for the Pi 5 from a laptop (no difference). >> >> I could try installing a bullseye version of raspbian to see if that made >> a difference, but I'm not excited about reimaging my card. Still, I might >> try this, though it's not a great long term solution since it's ill advised >> to run old software after the security updates cease. >> >> I'd love to hear if anyone else has EVER had success with Raspbian >> bookworm on a Pi with acurite. >> >> Thanks for all the suggestions. >> >> --Jim-- >> >> On Monday, July 21, 2025 at 10:08:04 PM UTC-4 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/3dfb4f52-43af-45f2-8dc4-0e68a7e74ea1n%40googlegroups.com.
