Switched acurite to new Pi 5, doesn't seem to find station

[James J Dempsey]

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.

[p q]

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.

--
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 weewx-user+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/weewx-user/7320df74-6865-45b9-939f-6752bc72ba2cn%40googlegroups.com.

--

Peter Quinn
(415)794-2264

[James J Dempsey]

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--

[vince]

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.

[James J Dempsey]

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--

[vince]

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.

[James J Dempsey]

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.  

[vince]

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

[Justin Wilczek]

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
```

[vince]

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.

[Justin Wilczek]

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.

[James J Dempsey]

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--

[James J Dempsey]

Sadly, bullseye Raspbian doesn't support the Pi 5 hardware.  Perhaps I'll try Ubuntu.

[James J Dempsey]

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

[James J Dempsey]

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.

[vince]

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.

[Ryan]

FWIW, the same problem appeared for me when I updated the Pi to 6.12.34+rpt-rpi-v6 from 6.6.20+rpt-rpi-v6. It's now working for me on 6.6.20, but when I have time in a few weeks, I may step up the kernel release by release until it breaks and report it to the kernel/pi devs and post back here. 

For me, the "fix" was to simply copy /boot/vmlinuz-6.6.20+rpt-rpi-v6 to /boot/firmware/kernel.img and /boot/initrd.img-6.6.20+rpt-rpi-v6 to initramfs since the old version was still on the Pi. 

Thanks for your troubleshooting, it pointed me in the right direction!

[James J Dempsey]

That's awesome Ryan.  I'm not physically near my pi/acurite right now, but the next time I am I'm going to try this approach.  Thanks for posting.

[James J Dempsey]

Well, I tried to follow Ryan's advice above, but it was a little tricky:  For the Raspberry Pi 5, instead of kernel.img and initramfs, it uses kernel_2712.img and initramfs_2712.

I installed the 6.6.20 2712 version of the kernel using apt and then copied as Ryan suggests, but to the Pi 5 filenames.

It didn't boot.  Why?  The Raspberry Pi 5 hardware doesn't support any kernel prior to 6.12.

So I guess my choices are to find a Raspberry Pi 4 or earlier, or perhaps use Ubuntu which seems to work just fine as I mentioned above.

Thanks everyone for your help suggestions.

[peterq...@gmail.com]

I think I also have this problem. 

The driver is giving a [Errno 32] Pipe error and it started doing this a day or so ago. I thought it was a dead weak/dead battery in the outdoor sensor.

The system has been running for many years under Ubuntu 22.04.5 LTS on a Raspberry PI 3b.

Is there a reasonable fix, or should I punt and rebuild my Raspi with a newer OS?

[James J Dempsey]

Peter,

I can't be sure, but this doesn't feel like the same problem due to the fact that I switched from Raspbian on my Pi 5 to Ubuntu in order to solve the problem!  [I could not find a Raspbian kernel that worked both with Pi 5 but was old enough to not have the problem.]

At least under 25.04 Plucky Puffin, the Acurite driver is working just fine for me.

It is pretty easy to get a spare microSD card and install whatever OS you like + weewx to see if something will work without touching your existing system.  If I were you I would start by creating an SD card with fresh Ubuntu 22.04.5 LTS, add weewx and see if that works.  If it does, then it's probably something in your specific installation.  If it doesn't, then try the same with either 25.04 or perhaps 24.04.3 LTS if you prefer LTS releases.

[vince]

The driver doesn't know the clock struck midnight a few days ago, so there has to be something that changed in the underlying os.  If you have automatic updates enabled you might check your /var/log/dpkg logs to see which packages were updated in that time period.

FWIW - on a x86_64 vm that I have, I see what looks like kernel updates on Oct-2

Try:

   grep "status installed" /var/log/dpkg.log

And if it logrotated on you, check dpkg.log.1 and so on to look for updates around the date when things went bad ....

[p q]

There was an update that exactly matches the time when my system stopped working properly. Looks like: libusb-1.0-0:armhf 2:1.0.25-1ubuntu2 is the culprit, though there were several updates.

I'm not sure how to fix it or roll it back, so I'm going to do what James suggested - take a spare SD card and rebuild my system using Ubuntu 24.04. I've been wanting to upgrade for a while now and this is a good excuse. Hopefully this version works.

--

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 weewx-user+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/weewx-user/c9119b06-4b13-4c89-b52d-195b8169e44fn%40googlegroups.com.

--

Peter Quinn
(415)794-2264

[James J Dempsey]

My solution to this was to change from Raspberry Pi OS to Ubuntu 25.04.  Things worked fine for several months, but after an update that provided a newer linux kernel yesterday  (linux-image-raspi:arm64 6.14.0-1019.19), I'm seeing exactly the same Acurite driver problem on Ubuntu.  I guess unless there's a driver update, I'll have to go back to an older version of the kernel or ubuntu.

[Craig (craiger)]

Confirming Acurite USBHID device appears and enumerates properly with 6.12.73 kernel, I started a new thread if anyone wants the details,

https://groups.google.com/g/weewx-user/c/NFUoueN1oK8/m/JynFqvaxAwAJ

sudo rpi-update 

<reboot>

uname -a

Linux raspberrypi 6.12.73-v8-16k+ #1947 SMP PREEMPT Thu Feb 19 12:33:11 GMT 2026 aarch64 GNU/Linux

lsusb

Bus 001 Device 002: ID 24c0:0003 Chaney Instrument Model 01036 weather center

dmesg

[    4.095533] usbhid 1-2:1.0: fixing wrong optional hid class descriptors count
[    4.118501] hid-generic 0003:24C0:0003.0006: input,hidraw5: USB HID v1.11 Device [Chaney Instrument] on usb-xhci-hcd.0-2/input0

I don't know how much other wreckage the newer kernel cause, but if you only use your Pi5 for Weewx, you're probably in business here.

fyi,

-edfardos

[Craig (craiger)]

I spoke too soon, unfortunately when weewx starts, the kernel removes the device and udev removes /dev/hidraw0 .

udev monitoring as weewx starts,

KERNEL[390.848490] remove   /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3/1-1.3:1.0/0003:24C0:0003.0002/input/input5/event0 (input)

UDEV  [390.858575] remove   /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3/1-1.3:1.0/0003:24C0:0003.0002/input/input5/event0 (input)

KERNEL[390.868245] remove   /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3/1-1.3:1.0/0003:24C0:0003.0002/input/input5 (input)

KERNEL[390.871672] remove   /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3/1-1.3:1.0/0003:24C0:0003.0002/hidraw/hidraw0 (hidraw)

UDEV  [390.871846] remove   /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3/1-1.3:1.0/0003:24C0:0003.0002/input/input5 (input)

KERNEL[390.871901] unbind   /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3/1-1.3:1.0/0003:24C0:0003.0002 (hid)

KERNEL[390.871951] remove   /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3/1-1.3:1.0/0003:24C0:0003.0002 (hid)

KERNEL[390.871997] unbind   /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3/1-1.3:1.0 (usb)

UDEV  [390.874902] remove   /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3/1-1.3:1.0/0003:24C0:0003.0002/hidraw/hidraw0 (hidraw)

UDEV  [390.877827] unbind   /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3/1-1.3:1.0/0003:24C0:0003.0002 (hid)

UDEV  [390.880311] remove   /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3/1-1.3:1.0/0003:24C0:0003.0002 (hid)

UDEV  [390.883777] unbind   /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3/1-1.3:1.0 (usb)

KERNEL[441.956780] remove   /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3/1-1.3:1.0 (usb)

KERNEL[441.957706] unbind   /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3 (usb)

KERNEL[441.957889] remove   /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3 (usb)

UDEV  [441.974605] remove   /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3/1-1.3:1.0 (usb)

UDEV  [441.982280] unbind   /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3 (usb)

UDEV  [441.986219] remove   /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3 (usb)

[Craig (craiger)]

... and weewx debug reports,

Mar 01 09:40:14 raspberrypi weewxd[1458]: INFO weewx.manager: Daily summaries up to date

Mar 01 09:40:14 raspberrypi weewxd[1458]: INFO weewx.engine: Starting main packet loop.

Mar 01 09:40:14 raspberrypi weewxd[1458]: DEBUG weewx.drivers.acurite: Found station at bus= device=

Mar 01 09:40:14 raspberrypi weewxd[1458]: DEBUG weewx.drivers.acurite: next read in 18 seconds

Mar 01 09:40:32 raspberrypi weewxd[1458]: DEBUG weewx.drivers.acurite: Found station at bus= device=

Mar 01 09:40:32 raspberrypi weewxd[1458]: DEBUG weewx.drivers.acurite: next read in 18 seconds

Mar 01 09:40:50 raspberrypi weewxd[1458]: DEBUG weewx.drivers.acurite: Found station at bus= device=

Mar 01 09:40:50 raspberrypi weewxd[1458]: DEBUG weewx.drivers.acurite: next read in 18 seconds

Mar 01 09:41:08 raspberrypi weewxd[1458]: DEBUG weewx.drivers.acurite: Found station at bus= device=

Mar 01 09:41:08 raspberrypi weewxd[1458]: DEBUG weewx.drivers.acurite: next read in 6 seconds

[Craig (craiger)]

Disregard, I take that back, the hidraw0 device is supposed to be removed as weewx picks up the usbdriver.  It's working fine after running rpi-update  (6.12.73 kernel) on a raspberry Pi5 running trixie.

This debug line in weewx is normal evidently: