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/b165ef54-4450-4e8a-82d9-8014d55087c7n%40googlegroups.com.
