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 .... On Monday, October 6, 2025 at 2:48:57 PM UTC-7 [email protected] wrote: > 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? > > On Wednesday, September 24, 2025 at 8:12:29 AM UTC-7 James J Dempsey wrote: > >> 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. >> >> On Monday, August 18, 2025 at 6:56:50 AM UTC-4 James J Dempsey wrote: >> >>> 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. >>> >>> On Sunday, August 17, 2025 at 10:16:21 AM UTC-4 Ryan wrote: >>> >>>> 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! >>>> >>>> On Friday, July 18, 2025 at 2:56:09 PM UTC-5 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/c9119b06-4b13-4c89-b52d-195b8169e44fn%40googlegroups.com.
