Almost every compatibility list you will read is a list of names with ticks beside them. It cannot tell you the difference between a device somebody plugged in and watched work, and a device that appeared on a forum in 2021 and has been copied between websites ever since.
Those are very different claims and they get printed identically. So ours prints them differently, and this is what the labels mean.
Two questions, not one
A tick conflates two things that come apart constantly.
Can we read it at all? That is status, and it is either supported or candidate.
How do we know? That is verification, and it has four levels. This is the one nobody publishes, and it is the one that tells you how much to trust the first answer.
A device can be supported on weak evidence, or a candidate that we are fairly confident about. Printing only the first question hides that entirely.
The four levels, weakest evidence last
Live-verified against a real unit
Somebody bought one, put it in front of a hub, and confirmed the numbers coming out match the numbers on the device. The strongest claim available, and the rarest, because it costs money per device.
Five devices are at this level. Out of thirty-three. That ratio is the honest state of this industry and we would rather print it than round it up.
Decoded from the published spec
The format is documented, we implemented what the document says, and we tested against the document rather than against a device. Strong for open formats like BTHome v2, where the spec is the actual contract and any device claiming to speak it is claiming to match that document.
What it cannot tell you is whether a specific product implements its own spec correctly. Plenty do not.
Community-decoded, live confirmation pending
Somebody else worked out the format, published it, and enough independent implementations agree that it is almost certainly right. This is how most Bluetooth sensor support exists anywhere, including in products that would never admit it.
Twenty of our thirty-three sit here, and it is worth being blunt about what that means: the majority of what we support, we support on somebody else’s homework. It is good homework, and it is not the same as having held one.
Detected in the field, decode in progress
We can see the device. We know it is the device. We cannot yet turn what it sends into a reading.
Usually one of three reasons: the broadcast is encrypted and needs a key, the advertisement is a status frame with no measurements in it, or the readings only exist over a connection rather than a broadcast.
Why eight devices cannot be bought here
Twenty-five devices are supported. Eight are candidate, and none of those eight has a buy button anywhere on this site, even where we think they will probably work.
The reason is structural rather than principled, which is the version worth trusting. We earn a commission when you buy through a link here. So a link on a device we have not confirmed is a payment for sending you toward something that might do nothing, and the incentive runs exactly the wrong way: the cheapest thing we could do is list everything, tick everything, and let returns be your problem.
So candidates are blocked in the system rather than by good intentions. Publishing one requires confirming the device first. Nobody can do it by pasting a link, including us on a Friday afternoon.
A candidate is not a rejection. It means we expect it to work and have not proved it. Several will move to supported. The label is about our evidence, not about the product’s quality.
The thing a tick can never tell you
Supported does not mean we read everything the device measures. It means we read something, and the interesting question is always which something.
A battery monitor that reports voltage and nothing else is supported. So is one that reports voltage, current, consumed amp-hours and state of charge. Both get a tick on any normal list, and they are not remotely the same purchase.
That is why every device page lists the individual readings rather than a yes. If a device measures something we do not decode, the missing one is named. The gaps are written down rather than left for you to discover after buying.
How this changes
Verification is derived when the catalog is built, from where each decode rule actually came from. It is never typed in by hand, which matters: a field somebody can set is a field somebody will eventually set optimistically, at the exact moment it would be convenient.
Levels move up when the evidence does, and down if something we believed turns out to be wrong. A device dropping from supported to candidate is a thing that can happen here, and it should be.
What to do with this
Read the verification line on the device page before buying, and weight it by how much the reading matters to you.
For a cheap cupboard thermometer, community-decoded is plenty. For the sensor you are relying on to tell you the wet bay is freezing while you are four hundred miles away, prefer live-verified, and understand that you are trusting community work on most of the rest.
And if you own a candidate device and it works, tell us. That is precisely how something moves up a level, and it is the one part of this we cannot do without people who already bought the thing.
