Problem statement
Our community encounters protocol names all over Home Assistant (integration setup, device pages, and now the Connectivity settings section) without any neutral, OHF-maintained explanation of what they mean. Protocol knowledge lives scattered across forums, blogs, and vendor marketing, and much of it is biased, outdated, or too technical for entry-level users. Since purchase decisions are effectively protocol decisions, people choosing between, say, a Zigbee and a Wi-Fi sensor have no trustworthy reference to consult.
At the same time, the Device Database Preview Edition already models devices by connectivity, but currently lacks the explanatory layer that turns that structured data into guidance.
Community signals
No response
Scope & Boundaries
In scope
- Foundation: protocol entity and content collection structure in the DDB frontend, page template rendering prose plus live data, stable slugs with a redirect commitment.
- Phase 1 content: the five Connectivity-section protocols (BLE, IR, RF, Serial, Modbus), plus links from the Connectivity panels and the HA docs landing page.
- Phase 2 content: purchase-decision protocols (Zigbee, Z-Wave, Thread, Matter, Wi-Fi/Ethernet), with cross-links from relevant integration docs.
- Later: extended coverage (MQTT, KNX, Zigbee Green Power, others) and optionally a
/api/protocols summary endpoint for HA surfaces.
Not in scope
- Replacing integration-specific documentation on home-assistant.io
- Ranking protocols or recommending vendors
- Developer-level protocol engineering documentation
Foreseen solution
Publish unbiased, user-facing protocol documentation with the Device Database as its origin and canonical home, at stable URLs such as /protocols/{slug}. Home Assistant links in rather than duplicating:
Hosting on the DDB makes "reference devices using this protocol" and "HA integrations using this protocol" live queries instead of hand-maintained lists, reuses the existing PR review and Lokalise translation pipelines, and turns the pages into SEO entry points for the DDB itself.
Each protocol page follows a shared layered template: plain-language introduction and decision guidance first, an at-a-glance fact box, balanced strengths and limitations, generated reference devices and integrations, with advanced technical material (topology, commissioning, security model) clearly separated further down.
Risks & open questions
No response
Appetite
Medium - 1-2 cycles
Execution issues
No response
Decision log
Problem statement
Our community encounters protocol names all over Home Assistant (integration setup, device pages, and now the Connectivity settings section) without any neutral, OHF-maintained explanation of what they mean. Protocol knowledge lives scattered across forums, blogs, and vendor marketing, and much of it is biased, outdated, or too technical for entry-level users. Since purchase decisions are effectively protocol decisions, people choosing between, say, a Zigbee and a Wi-Fi sensor have no trustworthy reference to consult.
At the same time, the Device Database Preview Edition already models devices by connectivity, but currently lacks the explanatory layer that turns that structured data into guidance.
Community signals
No response
Scope & Boundaries
In scope
/api/protocolssummary endpoint for HA surfaces.Not in scope
Foreseen solution
Publish unbiased, user-facing protocol documentation with the Device Database as its origin and canonical home, at stable URLs such as
/protocols/{slug}. Home Assistant links in rather than duplicating:Hosting on the DDB makes "reference devices using this protocol" and "HA integrations using this protocol" live queries instead of hand-maintained lists, reuses the existing PR review and Lokalise translation pipelines, and turns the pages into SEO entry points for the DDB itself.
Each protocol page follows a shared layered template: plain-language introduction and decision guidance first, an at-a-glance fact box, balanced strengths and limitations, generated reference devices and integrations, with advanced technical material (topology, commissioning, security model) clearly separated further down.
Risks & open questions
No response
Appetite
Medium - 1-2 cycles
Execution issues
No response
Decision log