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/ca2a1ad7-7ccd-4bfe-8e64-0323700a755en%40googlegroups.com.
