Tahoe/OSX/Acurite hardware
Rick Knecht
⚠️ This is not a WeeWX problem
This is a macOS driver / entitlement issue, and it’s subtle.
Why this happensModern 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”
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.
=-=-=-=-=-
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:
This answers one question only:
Expected outcomesDoes the macOS USB stack enumerate the AcuRite at all?
GOOD (continue):
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.
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:
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.
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:
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).
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:
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.
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:
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 happensModern 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:
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:
-
✅ Run WeeWX on Linux / Raspberry Pi (best, proven)
-
⚠️ Use macOS only as a data consumer (web UI, rsync, etc.)
-
❌ 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)
Paste the result, and I’ll give you a clear yes/no conclusion and the cleanest path forward.
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 👍
Tom Keffer
--
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 weewx-user+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/weewx-user/50977fff-22ae-4bac-823c-2bde9b3eaccen%40googlegroups.com.
Susan Mackay
Rick Knecht
Rick Knecht
Vince Skahan
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?