Turn off the system's battery item and put this in its place. It is the same battery, drawn to the same proportions, in the same corner — except that it also tells you what the machine is drawing, switches Low Power Mode, and opens onto everything below.
One item instead of two is worth real estate on a 13" menu bar.
The same item, opened. 45.28 W coming in on a 20 V contract, 38.4 W of it going
into the cell, 55 W the charger still has spare — and the brick's own account of
itself underneath.
Wattson reads the SMC and the IORegistry directly. system_profiler SPUSBDataType
returns an empty list on recent macOS, so nothing here depends on it.
From a clone of this repo:
./build.sh --installCompiles in release, assembles Wattson.app, signs it ad-hoc, copies it to
/Applications and launches it. Drop --install to just build into build/.
Needs an Apple silicon Mac running macOS 13 or later, and a Swift 5.9 toolchain.
Tip
The build is signed ad-hoc, so Gatekeeper will refuse the first launch. Right-click
the app in /Applications and choose Open once, and it will start normally after that.
To use it as your battery item, set Menu Bar in Settings to Level and wattage, then turn the system's own battery off in System Settings › Control Center › Battery.
-
A battery drawn from the real figure. SF Symbols ships battery art in five steps — 0, 25, 50, 75, 100 — so a symbol can only ever round 61% to the nearest quarter. This one is drawn, at the proportions of the battery macOS puts in its own menu bar, with the charging bolt cut through the charge the way Apple's is, and it turns yellow in Low Power Mode exactly as the system's does.
-
A wattage beside the percentage, which is the part the system item has never told you. Level and wattage reads
78% 45.3 Won a charger — what is arriving from the wall — and falls back to the cell's own flow once you unplug. Level and flow reads78% +38.4 Winstead, always signed, for what the battery itself is doing. Or Battery level for the plain percentage, and Icon only for nothing but the battery.Every mode previews what it would actually put up there, live — the labels
alone never told you what you would get. -
Low Power Mode, switched from the panel. macOS exposes no API for it at all — not in IOKit's headers, not in the PowerManagement plists — so
pmsetis the only way in and only root may write it. The first use offers to install/etc/sudoers.d/wattson, granting your account one command with two exact argument lists and nothing else. It is checked withvisudobefore it goes in and again once it is there, removed again if that second check fails, and revocable from Settings.Low Power Mode on. The item goes yellow, the way the system's own battery does.
-
The charge again in the panel, at a size you can read across a desk, next to what is flowing and which way.
On battery: what is leaving the cell, and the last four minutes of it.
- Where that power goes — a single stacked bar splitting the Mac's own draw, attached accessories, and charge going into the battery, sized against what the charger can actually supply.
- What this Mac will take, so you can tell whether the charger is the thing holding you back or the machine is.
- Which charger it is. The brick's own name, who made it, its firmware and serial — with an Apple mark on the card when the adapter reports Apple as its manufacturer.
- A warning when the battery is going down on a charger, which is the one charging fault nothing else on the machine will tell you about. It reports measured facts only — what is coming in against what the Mac is drawing — and says nothing about what a bigger charger could have delivered: a small brick holding a machine level is doing its job.
- One card per physical connection. A port and the device on the end of it are the same cable, so they get one card: what it is, which port, what is flowing and in which direction. Expand a card for the PD contract, the voltage ladder, how the cable is wired, and what it is certified to carry.
- Cable diagnostics — whether a cable has SuperSpeed lanes and sideband pins at all, which is usually the answer to "why is this drive slow".
- How the port's two high-speed lanes are actually assigned, which is the real answer to "why is the dock's ethernet crawling when the monitor is plugged in". DisplayPort alt mode takes lanes; take both and USB 3 has no wires left, so everything on that connector drops to USB 2.0 whether or not it is capable of more. The port still advertises USB 3 as supported the whole time, because the port is still capable of it — nothing else on the Mac tells you this.
- Whether the picture is being compressed. When a display's mode needs more bandwidth uncompressed than the link it negotiated can carry, and it is being displayed anyway, it is being compressed. That inference only runs one way: the figure Wattson computes is a floor — real timings need more — so exceeding it proves the mode does not fit, while coming in under it proves nothing. It will tell you a link is demonstrably too narrow. It will never tell you one is adequate.
- Liquid in a connector. Every USB-C port has a detection circuit, and macOS shows its own alert the moment it fires and nothing afterwards — so a port that has quietly stopped charging leaves nothing to go and look at. Wattson says which port, and keeps saying it while the condition holds.
- What the Thunderbolt controller behind each port is, and what the link actually came up at when one is running. The port's transport list says what a port is capable of and reads the same whether it is empty or carrying a dock; this is the controller's own account — its generation, how many lanes it has, and what it settled on. An achieved link is only ever reported when the port says Thunderbolt is genuinely running, because an idle port reports a convincing-looking link with nothing attached at all.
- What the cable's own chip says it can carry — its speed, its current and voltage ratings, and who made it. This is read from the cable's e-marker over SOP', which is what separates a 3 A cable from one rated for 5 A. A cable idling with nothing on its far end is never interrogated and gets no rating; neither does one whose chip answers with nothing. In those cases the panel falls back to what the hardware actually negotiated through the cable, and says which of the two you are looking at rather than blurring them together.
- What each device is. Click any device in the tree for its power allocation in mA as well as watts, its link speed, vendor, VID/PID and serial number.
- Volumes. A drive mounted from a USB device is listed under it with its free space, a Show in Finder button, and an eject that unmounts the whole disk rather than one partition of a two-partition stick.
- Connection history, and search once the tree is long enough to need it.
A port and everything behind it, with what each one is drawing.
Off by default, switched on by kind in Settings: chargers, drives and cards, or everything else that plugs in. Each notice carries what is worth knowing rather than just a name — a drive's free space and link speed, a charger's rating, the contract it agreed and what it is actually delivering.
Nothing waits and nothing is announced twice: a drive's notice appears the moment it is on the bus and fills in its size in place when the volume mounts. They show beside the menu bar, in Notification Center, or both.
What was plugged in, and the part of it worth knowing: a charger's contract and
what it is delivering, a drive's free space and how fast the link came up.
Clicking a device in the tree expands it where it sits: what the bus granted it, how fast the link
actually came up, who made it and what its serial is, anything it has mounted, and when it last
came and went.
About 12 MB sitting in the menu bar, and about 28 MB once the panel has been opened — where it stays, however many times you open it again.
The panel is not kept between openings: its contents are built when you open it and given back when you close it, and only the popover and its one window live in between. Keeping the whole thing alive is the ordinary thing to do, and it cost more than everything else in the app put together — the surfaces behind a window are charged to the process whether or not anything is on screen, so every opening added to the total and none of it came back.
The binary lives inside the bundle:
/Applications/Wattson.app/Contents/MacOS/Wattson --dump| Flag | |
|---|---|
--dump |
Prints one reading — power, ports, devices — as plain text, and exits. |
--json |
The same reading as JSON, for anything that has to read it rather than look at it. |
--watch |
Prints the input / load / battery line once a second until interrupted. |
--selftest |
Replays recorded hardware captures through the readers and reports what broke. Touches no hardware. |
--capture "name" |
Writes a raw hardware capture to the working directory and prints its path. |
--capture is the one to reach for when something unfamiliar is plugged in and
you have thirty seconds. It records the unparsed sources — the whole IOKit
service plane, every SMC key the controller admits to, the USB BOS descriptors
that no ioreg invocation can produce, every display mode CoreGraphics offers
— and none of Wattson's own conclusions about them. That is the point: it is
the evidence, so a reading can be worked out afterwards from a capture instead
of from the hardware.
Several sections are empty unless something is attached, and say so where they are. A cable's e-marker only answers when there is something at the far end; a port's DisplayPort and USB3 transport nodes exist only while those transports are up; an idle port's lanes are parked. A capture taken with the dock running is worth a dozen taken idle.
Warning
A capture carries serial numbers — the Mac's, the battery's, and every attached device's. Read it before sending it to anyone.
Note
Port positions are guesswork. Port numbering says nothing about physical position, so the mapping from port number to "front" and "rear" was established by hand on one machine and may not match yours. The controller-to-port map used to attribute measured power to a specific device re-learns itself at runtime whenever exactly one port is occupied.
Maximum charging wattage is the one figure here not read from the hardware. macOS publishes a great deal about the adapter attached to a Mac and nothing at all about what the Mac itself will accept, so that number is a table of Apple's published ratings keyed on the model identifier. A model missing from the table reports nothing rather than a guess.
The battery's condition comes from the pack's own gauge: capacity against
design, cycles against the rating for the chemistry, and the temperature it is
sitting at. Capacity is shown clamped to 100% because a pack fresh from the
factory genuinely holds a little more than its design figure — that number is a
floor the cells are built to clear, not an average — and --json reports it
unclamped. "Service recommended" appears only when the gauge has latched a real
fault; wear is not a fault, and a pack at 79% is working as designed.
History keys on the serial number, so it survives the device being moved to another port. Plenty of hubs and card readers report no serial at all; theirs keys on the port instead, and the panel says so rather than implying a history it cannot stand behind. Nothing is recorded while Wattson is not running.








