1. Apple MacMini 2020 M1, so ARM 2. The driver is the one offered when you set up WeeWX for the first time. How do you select one for ARM vrs Intel?
On Wednesday, February 4, 2026 at 9:01:06 PM UTC-5 Susan Mackay wrote: > I've not read that waffle/AI slop (personal opinion!!!) nor do I have an > Acurite device but... > 1) Is the Mac Mini Intel or ARM? > 2) Is the Acurite driver the correct one for the architecture? > The reason many Intel apps that talk to hardware that are running under > Rosetta 2 on an Apple Silicon device is that the drivers cannot be emulated > and so you can install the app but cannot get it t run. > This may be way off in your situation but something to check. > > On Thursday, 5 February 2026 at 12:34:37 am UTC+11 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/960863b0-dcb7-4c89-86f7-9728b3437939n%40googlegroups.com.
