Rick, I don't think you'll find many users willing to go through a long LLM-generated output.
On Wed, Feb 4, 2026 at 4:36 AM Rick Knecht <[email protected]> wrote: > For some time (i think since i upgraded toto Sonoma) I have not be able to > connect my Acurite Weather station (06037MA1) to my mac. I recently > decided to try to spin it up again using a Raspberry PI, and went through > several days in trying to debug why the usb wasn't working, including > install several different versions of Ubuntu. > > Decided i wan life to run faster than a Pi, so i turned back to the Mac > Mini I have, since i was running successfully in the past. > > A couple more days of making best friends with ChatGPT and trying to get > to get the Acurite to play nicely with the Mac hasn't ended well, and I > wanted to check with you all to see to confirm the results it was telling > me. I went as far as totally erasing my mac to make sure all the OTHER > experiments i had done over the years through Xcode and homebrew hadn't > broke something. > > in a nutshell, it's telling me that the Mac and the Acurite are not > compatible: > > *macOS refuses to hand it to user-space software* > ⚠️ This is not a WeeWX problem > > This is a *macOS driver / entitlement issue*, and it’s subtle. > Why this happens > > Modern macOS (Ventura / Sonoma / Sequoia): > > - > > *Restricts USB HID access* > - > > Requires either: > - > > A signed DriverKit extension, *or* > - > > An application with explicit USB/HID entitlements > > WeeWX *does not have* those entitlements on macOS. > > On Linux → works > On Raspberry Pi → works > On older macOS → sometimes worked > On modern macOS → often fails exactly like this > > That explains why: > > “It worked briefly, then stopped” > “It works on the Pi but not on the Mac” > > And I really am not interested in the Pi any more. > > So my question is: Does WeeWX run under Tahoe with Acurite hardware? If, > why isn't it conversing with the Acurite? > > As background, here is my latest run, when ChatGPT is saying that because > of the USB HID interface isn't grabbable, it will not be able to connect > reliably to the Acurute. Any suggestions or guidance would be appreciated. > > =-=-=-=-=- > > OK, reset time. I have completely erased my mac. nothing is installed > except homebrew and xcode > > Got it 👍 > Clean slate is actually *perfect* here. > > We’re going to do this *slow, deterministic, one step at a time*, and > we’ll stop after each step to confirm reality before moving on. No leaps. > > Right now your goal is *not* “make WeeWX work”. > Your goal is *much smaller and correct*: > > *Can macOS see and expose the AcuRite USB device in a way user-space > software can access?* > > Everything else depends on that. > ------------------------------ > STEP 0 — Ground rules (important) > > - > > We will *not* install WeeWX yet > - > > We will *not* install Python packages yet > - > > We will *not* guess > - > > Every step answers exactly *one question* > > ------------------------------ > STEP 1 — Plug in the AcuRite (nothing else) > > Before running anything: > > - > > Plug the AcuRite USB directly into the Mac > (no hub for now) > - > > Wait 5–10 seconds > > When ready, run *exactly this*: > ioreg -p IOUSB | grep -i chaney > What this step tells us > > This answers *one question only*: > > Does the macOS USB stack enumerate the AcuRite at all? > > Expected outcomes > > *GOOD (continue):* > +-o Chaney Instrument@…… > > *BAD (stop):* > > - > > No output at all → cable, port, or device issue > > 👉 *Paste the output here and stop.* > Do *not* run anything else yet. > > We’ll move to Step 2 only after confirming this. > Last login: Tue Feb 3 21:52:31 on ttys001 datalore@Mac-mini ~ % ioreg -p > IOUSB | grep -i chaney +-o Chaney Instrument@02130000 <class > IOUSBHostDevice, id 0x100001e1f, registered, matched, active, busy 0 (15 > ms), retain 26> datalore@Mac-mini ~ % > > Perfect. ✅ > That is *exactly* what we wanted to see. > > *Conclusion from Step 1:* > macOS *does* see the AcuRite hardware at the USB level. The device is > enumerated, active, and stable. > > We’re done with Step 1. > ------------------------------ > STEP 2 — Identify the device (vendor/product IDs) > > Now we answer *one new question*: > > What exact USB device is macOS seeing (vendor ID, product ID, speed)? > > Run *only this*: > ioreg -p IOUSB -l | sed -n '/Chaney Instrument@/,/}/p' > What this step tells us > > This confirms: > > - > > Vendor ID (should be 0x24c0) > - > > Product ID (should be 0x0003) > - > > USB speed (low-speed HID vs something else) > > Paste the output here *verbatim* and stop. > > No next steps yet — we’ll interpret this before moving on. > Last login: Tue Feb 3 21:52:31 on ttys001 datalore@Mac-mini ~ % ioreg -p > IOUSB | grep -i chaney +-o Chaney Instrument@02130000 <class > IOUSBHostDevice, id 0x100001e1f, registered, matched, active, busy 0 (15 > ms), retain 26> datalore@Mac-mini ~ % ioreg -p IOUSB -l | sed -n '/Chaney > Instrument@/,/}/p' +-o Chaney Instrument@02130000 <class IOUSBHostDevice, > id 0x100001e1f, registered, matched, active, busy 0 (15 ms), retain 26> | { > | "sessionID" = 48213657614 | "USBSpeed" = 2 | "idProduct" = 3 | > "iManufacturer" = 0 | "bDeviceClass" = 0 | "IOPowerManagement" = > {"PowerOverrideOn"=Yes,"DevicePowerState"=2,"CurrentPowerState"=2,"CapabilityFlags"=32768,"MaxPowerState"=2,"DriverPowerState"=0} > datalore@Mac-mini ~ % > > Nice — we’ve confirmed a lot already. > What your output means (Step 2 result) > > - > > *macOS sees the device*: Chaney Instrument@02130000 is present and > *active*. > - > > *USB speed = 2*: that’s *USB 2.0 / full-speed (12 Mbps)*. That’s > totally normal for these consoles (often HID-class). > - > > *idProduct = 3*: matches what WeeWX’s AcuRite drivers often expect. > > *What’s missing:* idVendor (and a few other useful fields) didn’t show up > in that snippet, which usually just means the sed block you captured ended > early (it stopped at the first } it encountered, and ioreg trees can be > nested). > > So Step 2 is “mostly successful”, but we still need *vendor ID* to be > 100% sure we’re looking at the right thing and to confirm the exact USB > identity. > ------------------------------ > STEP 2b — get vendor + product IDs cleanly > > Run this: > ioreg -p IOUSB -l -w0 | sed -n '/Chaney Instrument@/,/^\s*}/p' | egrep -i > 'idVendor|idProduct|USB Vendor Name|USB Product Name|USBSpeed|locationID' > What we expect > > Ideally you’ll see something like: > > - > > idVendor = 9408 (that’s *0x24c0* in decimal) > - > > idProduct = 3 > > Paste that output and we’ll move to *Step 3: confirm macOS exposes it as > a HID device* (which is what WeeWX usually talks to for Chaney/AcuRite). > \\Last login: Tue Feb 3 21:52:31 on ttys001 datalore@Mac-mini ~ % ioreg > -p IOUSB | grep -i chaney +-o Chaney Instrument@02130000 <class > IOUSBHostDevice, id 0x100001e1f, registered, matched, active, busy 0 (15 > ms), retain 26> datalore@Mac-mini ~ % ioreg -p IOUSB -l | sed -n '/Chaney > Instrument@/,/}/p' +-o Chaney Instrument@02130000 <class IOUSBHostDevice, > id 0x100001e1f, registered, matched, active, busy 0 (15 ms), retain 26> | { > | "sessionID" = 48213657614 | "USBSpeed" = 2 | "idProduct" = 3 | > "iManufacturer" = 0 | "bDeviceClass" = 0 | "IOPowerManagement" = > {"PowerOverrideOn"=Yes,"DevicePowerState"=2,"CurrentPowerState"=2,"CapabilityFlags"=32768,"MaxPowerState"=2,"DriverPowerState"=0} > datalore@Mac-mini ~ % ioreg -p IOUSB -l -w0 | sed -n '/Chaney > Instrument@/,/^\s*}/p' > | egrep -i 'idVendor|idProduct|USB Vendor Name|USB Product > Name|USBSpeed|locationID' | "USBSpeed" = 2 | "idProduct" = 3 | "USB Product > Name" = "Chaney Instrument" | "locationID" = 34799616 | "idVendor" = 9408 | > "USBSpeed" = 3 | "idProduct" = 32783 | "USB Product Name" = "USB Flash > Disk" | "locationID" = 34668544 | "USB Vendor Name" = "General" | > "idVendor" = 34372 "USBSpeed" = 3 "idProduct" = 4660 "USB Product Name" = > "UDisk" "locationID" = 34734080 "USB Vendor Name" = "General" "idVendor" = > 43981 datalore@Mac-mini ~ % > > Perfect. This is exactly what we needed. 👍 > Let’s lock in what we now *know*, then move *one small step forward*. > ------------------------------ > ✅ Step 2 — CONFIRMED (USB visibility) > > From your last command, we have *clean confirmation*: > > *Chaney / AcuRite console* > > - > > *USB Product Name:* Chaney Instrument > - > > *idVendor:* *9408* → 0x24c0 ✅ > - > > *idProduct:* *3* → 0x0003 ✅ > - > > *USB speed:* 2 (USB 2.0 / Full-speed) > - > > *Device state:* registered, matched, active > > This is *exactly* what an AcuRite / Chaney USB console should look like. > > So at this point: > > ✅ macOS sees the device > ✅ Vendor & product IDs are correct > ❌ WeeWX *not* reading data yet (expected at this stage) > > Nothing is “wrong” yet. > ------------------------------ > 🧭 What matters next (and why) > > AcuRite USB consoles *do not present as serial devices*. > They talk over *USB HID* (Human Interface Device). > > So the *next* required check is: > > *Does macOS expose this device as a HID interface?* > > If HID is not present or blocked, WeeWX will *always* fail with > “Unable to find station on USB”. > ------------------------------ > 🔍 STEP 3 — Check HID exposure (ONE command) > > Run *exactly this*: > ioreg -p IOUSB -l -w0 | grep -A20 -i "Chaney Instrument" > What we’re looking for > > In the output *below* the Chaney Instrument node, we want to see: > > - > > IOHIDDevice > - > > or IOUSBHostInterface > - > > or anything mentioning *HID* > > If you *don’t* see HID-related entries, that tells us *why* WeeWX can’t > talk to it. > > Paste the output *as-is*, and we’ll take the *next single step* from > there. > datalore@Mac-mini ~ % ioreg -p IOUSB -l -w0 | grep -A20 -i "Chaney > Instrument" +-o Chaney Instrument@02130000 <class IOUSBHostDevice, id > 0x100001e1f, registered, matched, active, busy 0 (15 ms), retain 26> | { | > "sessionID" = 48213657614 | "USBSpeed" = 2 | "idProduct" = 3 | > "iManufacturer" = 0 | "bDeviceClass" = 0 | "IOPowerManagement" = > {"PowerOverrideOn"=Yes,"DevicePowerState"=2,"CurrentPowerState"=2,"CapabilityFlags"=32768,"MaxPowerState"=2,"DriverPowerState"=0} > | "bcdDevice" = 32 | "bMaxPacketSize0" = 8 | "iProduct" = 2 | > "iSerialNumber" = 0 | "bNumConfigurations" = 1 | "UsbDeviceSignature" = > <c02403002000000000030000> | "USB Product Name" = "Chaney Instrument" | > "locationID" = 34799616 | "bDeviceSubClass" = 0 | "bcdUSB" = 272 | "USB > Address" = 12 | "kUSBCurrentConfiguration" = 1 | "IOCFPlugInTypes" = > {"9dc7b780-9ec0-11d4-a54f-000a27052861"="IOUSBHostFamily.kext/Contents/PlugIns/IOUSBLib.bundle"} > | "bDeviceProtocol" = 0 | "USBPortType" = 0 | "IOServiceDEXTEntitlements" = > (("com.apple.developer.driverkit.transport.usb")) | "Device Speed" = 0 | > "idVendor" = 9408 | "kUSBProductString" = "Chaney Instrument" | > "kUSBAddress" = 12 | } | +-o USB Flash Disk@02110000 <class > IOUSBHostDevice, id 0x100001e2f, registered, matched, active, busy 0 (115 > ms), retain 25> | { | "sessionID" = 48220355780 | "USBSpeed" = 3 | > "idProduct" = 32783 | "iManufacturer" = 1 | "bDeviceClass" = 0 | > "IOPowerManagement" = > {"PowerOverrideOn"=Yes,"CapabilityFlags"=32768,"MaxPowerState"=2,"DevicePowerState"=2,"DriverPowerState"=0,"ChildrenPowerState"=2,"CurrentPowerState"=2} > | "bcdDevice" = 256 | "bMaxPacketSize0" = 64 | "iProduct" = 2 | > "iSerialNumber" = 3 | "bNumConfigurations" = 1 | "UsbDeviceSignature" = > <44860f80000130353230313730303030303031324137000000080650> | "USB Product > Name" = "USB Flash Disk" | "locationID" = 34668544 | "bDeviceSubClass" = 0 > datalore@Mac-mini ~ % > > Great — thank you for pasting the full output. This is *very clear*, and > we can now say something definitive. > ------------------------------ > ✅ What we now KNOW (important) > > Your Mac *does see* the AcuRite / Chaney device at the USB level: > > - > > Vendor ID *9408 (0x24c0)* ✅ > - > > Product ID *3 (0x0003)* ✅ > - > > Device is *active*, configured, powered > - > > USB enumeration is *clean* > > So this is *not* a cable, hub, or power problem. > ------------------------------ > ❌ What is MISSING (this is the blocker) > > There is *NO HID interface attached* to the device. > > Specifically, in your output we *do not see*: > > - > > IOHIDDevice > - > > IOUSBHostInterface > - > > Any child nodes under Chaney Instrument > > It stops at: > <class IOUSBHostDevice> > > That means: > > macOS sees the device > *but does not bind it to the HID subsystem* > > And that is *exactly why*: > > - > > weewxd says *“Unable to find station on USB”* > - > > Nothing shows up in /dev > - > > No HID reports can be read > - > > WeeWX cannot talk to it > > ------------------------------ > ⚠️ This is not a WeeWX problem > > This is a *macOS driver / entitlement issue*, and it’s subtle. > Why this happens > > Modern macOS (Ventura / Sonoma / Sequoia): > > - > > *Restricts USB HID access* > - > > Requires either: > - > > A signed DriverKit extension, *or* > - > > An application with explicit USB/HID entitlements > > WeeWX *does not have* those entitlements on macOS. > > On Linux → works > On Raspberry Pi → works > On older macOS → sometimes worked > On modern macOS → often fails exactly like this > > That explains why: > > “It worked briefly, then stopped” > “It works on the Pi but not on the Mac” > > ------------------------------ > 🔍 ONE MORE CONFIRMATION STEP (single command) > > Let’s conclusively prove macOS never created a HID interface. > > Run this: > ioreg -p IOHIDSystem | grep -i chaney > Expected result (and likely outcome) > > No output. > > Paste it anyway — but this will seal the diagnosis. > ------------------------------ > 🧭 Where this leaves us (no guessing) > > If HID never attaches, *WeeWX cannot be made to work on macOS* with this > hardware. > > Your *realistic options* will be: > > 1. > > ✅ *Run WeeWX on Linux / Raspberry Pi* (best, proven) > 2. > > ⚠️ Use macOS *only* as a data consumer (web UI, rsync, etc.) > 3. > > ❌ Hack around with unsigned kernel extensions (not recommended, breaks > OS security) > > But we are *not* there yet — first we finish this last confirmation step. > ------------------------------ > 👉 Next step (one command, then stop) > ioreg -p IOHIDSystem | grep -i chaney > > Paste the result, and I’ll give you a *clear yes/no conclusion* and the > *cleanest > path forward*. > datalore@Mac-mini ~ % ioreg -p IOHIDSystem | grep -i chaney > datalore@Mac-mini ~ % > > Perfect. That result actually tells us *everything* we needed to know. > ------------------------------ > ✅ Final, definitive diagnosis > > Your Mac *can see the AcuRite USB device electrically*, but *macOS is not > creating a HID interface for it*. > > In plain English: > > The device is plugged in > The USB bus sees it > *macOS refuses to hand it to user-space software* > > That is why: > > - > > ioreg -p IOUSB ✅ shows *Chaney Instrument* > - > > ioreg -p IOHIDSystem ❌ shows *nothing* > - > > weewxd ❌ says *“Unable to find station on USB”* > - > > This works on Linux / Raspberry Pi but not on macOS > > This is *not*: > > - > > a WeeWX bug > - > > a config problem > - > > a permissions issue > - > > a cable or hub issue > > This is a *macOS USB/HID policy limitation*. > ------------------------------ > 🧠 What’s actually happening (important context) > > Modern macOS (Ventura → Sonoma → Sequoia): > > - > > Uses *DriverKit* > - > > Locks down *raw USB + HID devices* > - > > Requires *signed drivers or entitlements* > - > > Blocks “generic HID” devices from userland access > > AcuRite devices: > > - > > Do *not* ship a macOS driver > - > > Are *not standard HID keyboards/mice* > - > > Depend on *libusb-style raw access* > > Linux allows that. > macOS does not. > ------------------------------ > 🧾 Why it “worked briefly” before > > This usually happens when: > > - > > The device enumerates during early boot > - > > macOS briefly exposes it > - > > Then policy enforcement kicks in > - > > The interface disappears > > This matches your experience *exactly*. > ------------------------------ > ✅ What WILL work (recommended) 🥇 Best option (rock solid) > > Run WeeWX on: > > - > > Raspberry Pi > - > > Any Linux box > - > > A small VM or container on Linux > > Then: > > - > > Serve the web UI > - > > Push data to your Mac via HTTP / rsync / SFTP > > This is what most AcuRite + WeeWX users end up doing. > ------------------------------ > 🥈 Acceptable workaround > > Use macOS *only* for: > > - > > Viewing reports > - > > Hosting graphs > - > > Development > - > > Not talking to the USB device directly > > ------------------------------ > ❌ What will NOT work (don’t waste time) > > - > > Reinstalling WeeWX > - > > Changing Python versions > - > > Running as root > - > > Homebrew permissions > - > > chmod, sudo, entitlements tricks > - > > Different USB hubs > > You already proved all of that. > ------------------------------ > 🧭 Clear recommendation > > *Stop fighting macOS for USB access.* > It’s not designed for this class of device anymore. > > If you want, I can help you: > > - > > Set up WeeWX cleanly on a Pi (step-by-step) > - > > Migrate your existing data > - > > Configure remote access from your Mac > - > > Make the Mac experience *better* than local USB ever was > > Just tell me which path you want to take 👍 > > > > > -- > 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/50977fff-22ae-4bac-823c-2bde9b3eaccen%40googlegroups.com > <https://groups.google.com/d/msgid/weewx-user/50977fff-22ae-4bac-823c-2bde9b3eaccen%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAPq0zEDCTfVZz8eyhTmLR1v6DNZ32C42ogxRAdDj37HsC%3DHbow%40mail.gmail.com.
