v1.5.0-beta.3 is up

[darrylmorley]

@jimmyorz @aguilaair @cannotcollide @Caruso8677 @Mostxlnt @aldobalducci @themadturk7 @official-Cromatin @dino2895

New beta is up: v1.5.0-beta.3. Download WhatCable.zip from the release, unzip, and drag it into /Applications over your existing copy. Your normal Pro licence keeps working.

This is the last one you have to fetch by hand. Settings has a new Updates section with an "Include beta versions" switch. Turn it on and the next pre-release turns up in the normal update prompt. Several of you asked for this, sorry it took a while.

Two things it deliberately does not do, and I would like to know if either reads wrong:

• Turning the switch back off stops future betas but does not move you off a beta you are already running. The next stable release does that. The caption says so, but tell me if that is unclear.
• If you installed WhatCable with Homebrew you get a warning, because brew upgrade can quietly put the stable back over a beta.

The other big change: devices behind older docks and displays are attributed to a port again. TB3-era hardware (LG UltraFine 5K, CalDigit TS3+, that generation) carries its own PCIe USB controller rather than tunnelling USB the way a modern dock does. WhatCable was filing everything behind them as tunnelled with no port, so with two Thunderbolt things connected, your dock's devices vanished off the port card entirely.

@official-Cromatin, your Lenovo ThinkPad TB3 dock is exactly the case this fixes, and you are also the only Sequoia machine on the list, so you are testing two things nobody else can. @dino2895, the QNAP TB3 adapter is the other one I would love a look at.

Also changed:

• Plugging in a charger-only cable no longer flashes a phantom "10 Gbps" before settling. Settled readings are unchanged.
• The popup closes when you tell it to. That was a regression I introduced in beta.2, so worth a poke if you run with the watts readout on.
• Disconnect notifications now name what left, instead of just "USB device disconnected".
• Numbers follow your region, so 81,8% rather than 81.8% where that is how you write it.
• Pro: the charging resistance estimate is visible on the contracted port card, which is the one it actually applies to. Still experimental, still no good/bad verdict.
• The terms no longer read as a ban on sharing WhatCable output with a supplier or customer. They never meant that.
• Italian has had a thorough pass from @bovirus, and Traditional Chinese another round from @jimmyorz.

Reply here with what you see, "looks fine on my setup" very much included. Anything that looks like a real bug I will split into its own issue.

Thanks all.

[official-Cromatin]

Have discovered a couple of bugs while testing. I also have submitted the diagnostics with both my available docks attached on separate ports.

Regarding the attribution of devices behind docks (my Lenovo ThinkPad TB3 specifically), I have done some testing and can confirm that it’s working as expected.
Devices connected to the Lenovo ThinkPad TB3 dock are now correctly reported as devices associated directly to the port, instead of being listed under otherUSBDevices.

As I thought it might (somehow) prove useful to you, and as it was no additional work for me, I have attached the JSON files of the six raw exports I did.

Lenovo ThinkPad TB3 and DIGITUS on seperate ports	Lenovo ThinkPad TB3 alone	DIGITUS daisy chained after Lenovo ThinkPad TB3
v1.4.0	v1.4.0	v1.4.0
v1.5.0-beta.2	v1.5.0-beta.2	v1.5.0-beta.2
v1.5.0-beta.3	v1.5.0-beta.3	v1.5.0-beta.3

---

Prior to this release I have not used the notifications feature, but upon testing with my DIGITUS dock I have noticed the following: There is a big inconsistency of what device WhatCable reports to be connected or disconnected. To put the tests in relation, this is the tree of connected devices shown by the CLI tool in the current beta.

Connected devices:
  • USB2.0 Hub (VIA Labs, Inc.) - High Speed (480 Mbps)
    ↳ USB2.0 Hub (VIA Labs, Inc.) - High Speed (480 Mbps)
    ↳ Keyboard Hub (Apple, Inc.) - High Speed (480 Mbps) <- One and the same device, as the keyboard functions as a USB 2.0 hub
      ↳ Apple Keyboard - Low Speed (1.5 Mbps)
    ↳ USB-C PD3.0 Device (VLI Inc.) - Full Speed (12 Mbps)
  • USB3.0 Hub (VIA Labs, Inc.) - Super Speed (5 Gbps)
    ↳ USB3.0 Hub (VIA Labs, Inc.) - Super Speed (5 Gbps)
      ↳ USB 10_100_1000 LAN (Realtek) - Super Speed (5 Gbps)
    ↳ Mass Storage Device (Generic) - Super Speed (5 Gbps)

I have tested repeatedly unplugging the Keyboard Hub and plugging it back in. WhatCable correctly notified me that both the hub and device have been plugged in, but only notifies me that the Apple Keyboard has been disconnected, not that the Keyboard Hub (Apple, Inc.) has been disconnected as well.

When doing the same with the entire DIGITUS dock (with the Apple keyboard plugged in), the reports of what devices connected and disconnected according to WhatCable vary. Though never during my testing has WhatCable notified me of each hub and device in the chain.

For this, I have created an issue (#551) with more thorough testing and some screen captures.

In regard to the notifications, I have created a feature request (#550) to be able to independently of the "Notify on cable changes" toggle be able to enable "Notify on app updates".

---

Everything else works as expected. Hope this helps

[darrylmorley]

@aldobalducci thanks, it really does help!

[cannotcollide]

Looks good!

However, I am experiencing a weird issue where my Anker 160W charger doesn't present the e-marker chip on my cable, even when above 3A. Issue persists when unplugging and replugging. This is separate from my docking setup; it's my Anker Prime 160W Wall Charger that I use on-the-go. Now, I don't know if it's an issue caused by WhatCable, since I've only ever experienced it with this charger. Thought it's worth reporting anyway, though.

The cable resistance measurement is cool, and a great feature. Big fan! Reading seems to be corroborated by a cable resistance reader I have, too.

[darrylmorley]

Hi @cannotcollide, I've split your 160W e-marker report into its own issue: #554.

Very nice, on the resistance! Thanks for testing.

[jimmyorz]

Looks fine on my Mac mini M4 and Macbook Air M1.

And regarding @cannotcollide’s issue, I think I may have a related explanation, or at least another data point that could help narrow this down.

In your screenshot, the Anker Prime 160W charger is exposed to macOS as a PD partner/device:
Connected device: Power Brick, Anker Innovations Limited (0x291A) (PD 3.0)

I happen to have a different Anker Prime Charger 100W, so I tried comparing two connection paths using the same charger and cable.

With:Charger → Cable → Mac

The cable’s e-marker is detected and read normally.

But with:Charger → Cable → Mini dock → Mac

Power delivery still works normally — the Mac negotiates 92W through the dock — but the e-marker information for the charger-to-dock cable is no longer shown. Instead, macOS sees the mini dock as the connected PD device:
Connected device: Alternate Mode Adapter, VIA Labs, Inc. (0x2109) (PD 3.0)

My suspicion is that once there is another device between the Mac and the cable being queried, the Mac can no longer directly read that cable’s e-marker information, even though high-power PD can still be negotiated and passed through normally. In this case, the cable is on the charger-to-dock side of the connection rather than directly attached to the Mac.

Your case is obviously different because the cable is directly connected between the charger and the Mac. However, the fact that this particular Anker Prime 160W is identified as a Power Brick, while WhatCable reports the cable as “Present, but not read on this connection,” makes me wonder whether this charger has an unusual internal PD implementation or topology that affects how cable identity information is exposed to macOS.

Since the connection is negotiating above 3A, the cable still has to be e-marked. So this may be less about WhatCable failing to recognize the e-marker and more about macOS not exposing the full e-marker data for this particular connection.

I’m not sure whether the underlying cause is actually the same, but the comparison might be useful for narrowing it down.

[jimmyorz]

I have another possible clue: the issue may be related to Anker chargers with a Smart Display.

I have an Anker 45W charger with a display. Using the same TB4 cable, it negotiates 20V / 2.25A and charges normally at 45W, but WhatCable does not show the e-marker information.

What makes this more interesting is that I also have a regular Anker 40W charger. With the same TB4 cable, it negotiates 20V / 2A and the e-marker information is shown normally. So this does not appear to be simply related to whether the current exceeds 3A.

@cannotcollide’s Anker charger also has a Smart Display and shows a similar e-marker read issue. That makes me wonder whether these Smart Display models use a different internal PD controller, MCU, or PD topology that affects how the cable’s SOP′ identity is exposed to macOS.

I’m not necessarily suggesting that the display itself is literally blocking the e-marker communication. The display may simply be an indication that these models use a more complex internal architecture than Anker’s regular chargers.

At this point, the common pattern seems interesting enough that the Smart Display models may be worth investigating separately.

[cannotcollide]

This is really interesting, thank you! I definitely think this has something to do with how Anker exposes e-marker information on specific Smart Display chargers. Might be a physical limitation of how Anker does things, rather than anything WhatCable is reading incorrectly. Interesting nonetheless, and definitely worth looking into. Thanks!

[jimmyorz]

@darrylmorley I did a bit more testing, and I think these cases may be worth considering for the e-marker read-state wording.

I now have three different cases:

1. 100W charger without a display, with a hub/dock in between

   The connection shows:
   No e-marker. This cable doesn't advertise its capabilities.

   In this case, the charger-side cable is known to have an e-marker, but once the hub/dock is inserted between it and the Mac, macOS can no longer see that cable's e-marker information. Power delivery still works normally.

2. 160W charger with a Smart Display (from cannotcollide), directly connected with no hub/dock

   This shows:
   Present, but not read on this connection. Try reconnecting the cable.

   So macOS appears to know that an e-marker is present, but does not expose the actual e-marker data.

3. 45W charger with a Smart Display, directly connected with no hub/dock

   Using the same TB4 and non-Thunderbolt cable, both negotiate 20V / 2.25A and show:
   No e-marker read. The cable may have one; macOS only reads it above 3A or over Thunderbolt.

   However, I also tested a regular Anker 40W charger without a display. With the same TB4 cable, it negotiates only 20V / 2A, but the e-marker is read normally. I also repeated the test with the same non-Thunderbolt cable that has an e-marker, and its e-marker information is shown normally as well.

   So I think the current wording is a little too absolute. The above-3A and Thunderbolt conditions are still useful to mention, but these 20V / 2A tests show that macOS can sometimes read an e-marker below 3A even without a Thunderbolt connection. Changing only reads to something less definitive would better reflect the observed behavior.

The other interesting common factor is that both direct-connect cases where the e-marker data cannot be read involve Anker chargers with a Smart Display. That still doesn't prove the display itself is responsible, but it makes me wonder whether those models use a different PD controller, MCU, or internal PD topology that affects how cable identity information is exposed to macOS.

Because of these cases, I wonder if the wording could be made a little less definitive.

For example:
Present, but not read on this connection. A hub, dock, or some chargers may prevent macOS from reading the cable's e-marker information.

And instead of:
No e-marker. This cable doesn't advertise its capabilities.
perhaps something closer to:
No e-marker data is available on this connection. The cable may still have an e-marker.

For the below-3A case, perhaps:
No e-marker read. The cable may have one; macOS may read it above 3A or over Thunderbolt, but a hub, dock, or some chargers may prevent the data from being exposed.

This would preserve the existing above-3A and Thunderbolt guidance, while also accounting for cases where macOS can read an e-marker below 3A without Thunderbolt, and cases where another device or charger implementation prevents the e-marker data from being exposed.

[aldobalducci]

here's my Mac mini and my MacBook connected to a Philips display

[aldobalducci]

[darrylmorley]

Hi @cannotcollide, I've split your 160W report into its own issue: #554.

Short version: the raw data macOS publishes in these sessions is genuinely empty, so WhatCable is reporting what the OS gives it. The same pattern shows up across most chip generations and on macOS 15 through 27 in the diagnostic data I hold, so it isn't something this beta broke.

@jimmyorz's testing narrows it usefully: both direct-connect failures so far are Anker Smart Display models, while his plain 40W reads the e-marker fine at 2A with the same cable. That last result also shows the app's "only above 3A or Thunderbolt" wording is too absolute, which I'll fold into #413.

One thing would move #554 forward: run the test kit (Settings, Community, Contribute Diagnostic Data) while the 160W is plugged in and charging. The probes capture what's on the ports at that moment, so the charger needs to be connected when it runs.

[dino2895]

Hi @darrylmorley
Sorry I missed this earlier. I’ll re-check the QNAP Thunderbolt 3 10GbE adapter using the current beta rather than beta 3.

I’ll focus on whether the adapter and its associated devices are attributed to the correct physical port. If the topology still looks wrong, I’ll submit a diagnostic report while it is connected.