Sorry, i though i twas displaying due diligence. What would the best way to showing i tried following all the directions on the site but am not able to connect to the Acurite?
On Wednesday, February 4, 2026 at 8:34:37 AM UTC-5 Tom Keffer wrote: > 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/a9a0f894-1e12-4d78-b88d-235950c5f53bn%40googlegroups.com.
