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/0af7b58f-e347-4c4f-b8d5-7daaafaf745en%40googlegroups.com.
