Natively Supported vs Bridge Needed: What Our Verdicts Mean

"Works with Home Assistant" on a product page can mean three very different things: the platform speaks to the device directly, or it works after a configuration step, or it works only through a vendor hub you also have to buy. Every one of the 177 pairings in this index carries exactly one of three verdicts so those cases cannot hide behind the same phrase. This guide is the long form of what each verdict commits you to.

Natively Supported (18 of 177)

The platform communicates with the device directly over the stated protocol — no vendor hub, no translation layer. Once the protocol's own infrastructure exists (a Zigbee coordinator, a Thread border router), pairing is discovery rather than integration work. This is also the verdict that ages best: there is no vendor bridge whose cloud service can be discontinued out from under you.

Example: Apollo Apollo Automation AIR-1 Sensor Node with Home Assistant (ESPHome).

Compatible (Manual Config Required) (157 of 177)

The pairing works and is documented, but entities do not appear until you complete a configuration step: writing ESPHome YAML for a wired sensor, installing an integration, flashing firmware. This is the largest group in the index, mostly because wired sensors on ESP32 boards are inherently configuration-driven — the firmware cannot discover what you soldered to which pin. The device page's setup complexity rating (Plug-and-Play through Advanced YAML) tells you how much of an evening the step costs.

Example: Inovelli 2-in-1 Switch Blue Series with Home Assistant (Zigbee2MQTT).

Bridge Needed (2 of 177)

The platform never talks to the device. A vendor hub sits in between, speaking a proprietary protocol on one side and the platform's language on the other. Before buying, price in three things: the bridge itself if you do not own it; whether the bridge needs the vendor's cloud to function, which ties your device to the vendor's service staying alive; and that the bridge is a single point of failure for every device behind it.

Example: Tuya 16A Smart Energy Plug with Apple HomeKit (via Homebridge/Z2M).

How verdicts are assigned

Verdicts are derived from the documented pairing — protocol, bridge requirement and configuration path — as recorded in the dataset, which is compiled from manufacturer documentation and community reports rather than lab testing. The derivation is code, not editorial judgement per page, so the same facts always produce the same verdict. If a device's documentation changes — a firmware update adds Matter support, say — the record changes and the verdict follows. Spotted one that is wrong? Tell us.

Reading a device page with this in mind

• The verdict badge answers "will it work?" — the rest of the page answers "what will it cost me in hardware and time?".
• Check Bridge Required and Border Router Needed rows together: "no bridge" can still mean "needs a border router you do not own".
• Setup complexity rates the documented path, not your skill level — "Advanced YAML" is genuinely an evening if you have never written an ESPHome config.