Raspbian people will not magically fix your issue if they don't know about it. You have to report this to them via their reporting mechanisms whatever they are. That said, they can't work it without a lot more very detailed info under the hood than you've provided. Even then they might not care to fix it.
At first glance, you doing the chgrp seems wrong to me. My somewhat older 22.04 LTS system has /dev/bus as user=root group=root. Sorry but I don't have a physical 24.04 system to compare it with. Comparing ubuntu with debian sometimes helps but not always. Ubuntu is definitely different now and then under the hood. I still think you have a permissions issue, but given you started with a working Odroid running Ubuntu (which worked) and you now have a pi running Ubuntu (which works), but raspi running Raspbian (debianish), maybe it is a ubuntu/debian difference. Can't really say without more info or hardware to mess around with. If you're gutsy try a native debian installation (https://raspi.debian.net/tested-images/) and see if it breaks, but their test notes are so skeletal personally I'd just skip it and run ubuntu if it's what you're familiar with and it works. At some point your time+labor is worth more than battling this kind of stuff. On Thursday, August 14, 2025 at 8:28:06 AM UTC-7 James J Dempsey wrote: > Just for completeness, it also worked with an up-to-date Ubuntu 25.04. I > hope Raspbian figures this out soon because I'd much rather run Raspbian > than Ubuntu right now. > > Also, an addendum to my Ubuntu instructions above: Step 5 should also > include adding user weewx to the usb group. > > Also, if using Raspberry Pi Imager tool, no need to uncompress the image: > The tool will do that automatically. Just select the .xz file in the tool. > > Presumably Raspbian people will fix this at some point. I'd love to hear > if anyone gets the Acurite driver working on the latest Raspbian. > > On Thursday, August 14, 2025 at 10:17:17 AM UTC-4 James J Dempsey wrote: > >> 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/31a61099-3ce5-405e-a4f3-2ea0d5c390c8n%40googlegroups.com.
