Open Home Foundation ‐ Device database
Here we are sharing our joint vision, goals and progress for the 
Open Home Foundation device database.
At its heart, our vision is simple:
Become a real-world, open & unbiased list of smart home devices – to enable informed decisions, for everyone.
A community-powered resource built from anonymized data shared by
Home Assistant users around the world to give everyone the information they need to benefit from privacy, choice, and sustainability in their smart homes.
We have also published a blog post to outline how we'll build the device database together.
We aim to work on it based on some guiding principles:
-
A communal effort: The database is envisioned as a living project, built by and for the community. We will develop simple and effective validation and contribution systems to encourage broad participation. We invite everyone to help enrich the database, guiding its growth into the foundational resource for the smart home ecosystem and source of truth.
-
Striving for a source of truth: The device database will be built as an unbiased and trusted repository for smart home devices. It will strive for comprehensiveness and aim to be evergreen, accurately reflecting the evolving smart home ecosystem. We are committed to a process of continuous improvement on its journey to ultimately becoming the single source of truth. We are aware this is not an easy endeavor but are committed to learning and improving along the way.
-
Enabling informed choice: The device database will be designed to empower users by surfacing all relevant variables for a decision. It will always aim for objectivity, presenting facts without judgment. Our guiding philosophy is that there are no "good" or "bad" devices — only different capabilities, compatibilities, trade-offs, and requirements for users to evaluate in order to take an informed decision.
-
Human-Centric & meaningful: This device database is being built by and for people like you, not just as a mere collection of manufacturer specifications. What we consider "meaningful" is not carved in stone; it is an evolving concept that will be shaped by community feedback and real-world needs. We will prioritize capturing user-relevant information, starting with concepts like privacy implications, long-term battery performance, and the level of home access a device requires.
-
Sustainable & principled: We will build the database to be scalable and sustainable, operating efficiently within the
Open Home Foundation's resources and our thriving community. Its integrity is a foundational commitment: core principles will not be compromised, and the data will always remain independent of commercial influence.
Want to engage in more detail or share your feedback?
Join our
It's not just for developers; it's open to anyone curious about our work, eager to follow along, or excited to share feedback. To have access to this channel, you need a specific role. To enable it, select "I want to contribute developer skills" or "I want to contribute design skills" in the Channels & Roles settings in Discord.
We are taking an iterative approach for launching the device database. This means that the final product will be shaped and refined as we build and progress. While this emergent process means we don't have a final blueprint, we have established a clear target and a phased roadmap. The following milestones detail the objectives for each phase:
Note
- We have shipped this iteration with the Home Assistant 2026.2 release.
- Here is the blog post for more information about it: https://www.home-assistant.io/blog/2026/02/02/about-device-database/
This initial phase is focused on building and validating the core foundation. While gathering and structuring initial device data from our consenting users it allows us to stress-test, uncover first edge cases and further refine before heading towards public-facing interfaces, i.e. releasing the device database to everyone for consumption and further enrichment.
2. MVP
Note
This is what we are currently working on. Engage with us on Discord!
Leveraging the insights from the Foundational MVP, this phase will focus on launching the first public, consumable version of the device database. The primary goals are to deliver initial value to our users and further establishing a feedback loop. While the final scope of the initial release is flexible, it will be defined by a minimum viable set of device information and ways to interact with it. A core objective for this MVP is to also include an initial system that allows everyone to begin validating data and contributing to the database, including you 🥇
| The MVP should | Why? |
|---|---|
| Have a public consumable interface for the database. | We need to share the device information collected as soon as possible to create value for our community and public audience. |
| Have first 2-3 metrics we believe are going to be useful for consumption. | It will show the guiding principle of how the device database will be oriented going further. |
| Have a way to make the database economically sustainable. | To remain sustainable we need to evaluate measures in place to make that happen. For now, (optional) affiliate links displayed on the public device page might be an option. |
| Allow everyone to validate the information submitted about any device | We need to avoid a funnel for moderation, plus the bias that comes with it. We need to find a way to allow people to e.g. +1 and -1 to the information provided or provide more context. |
| Allow everyone to enrich the information by e.g. proposing changes or adding missing information | In addition to having valid data we also aim to have it appealing for consumption. This includes for instance having a nice product image. |
For now, our focus is on releasing and analyzing the results of the Foundational MVP as a baseline for the initial MVP thereafter. The insights we gather, coupled with continuous community feedback, will directly inform and guide the further development.
-
To have some basic guardrails and to guide further discussions we have prepared our thoughts on collaboration and general flows. The document by no means "final" but more to be treated as a living guidance.
-
Contributing by sharing your (anonymous)
Home Assistant device data is key - as this is a basis for your device database to flourish. So, be sure to participate in sharing your device data. Take a look at the submission protocol and our Data Use Statement for more information of what device data is being submitted and how it's aggregated before being openly shared with everyone. Rest assured, you can opt out again at any time. -
Apart from sharing your (anonymous)
Home Assistant device data contributing to the device database is the next step. Which is something we are jointly working on together with you to find the best experience. Join us on our Discord project channel to get further involved in the discussions. -
Have a feature requests? Great! Head over to the Discussions to engage with the community.
The device database implementation is available here.
By enabling "Device Analytics", your Home Assistant instance will automatically collect anonymous device analytics "snapshots" and upload them once a day to the device database.
For reference, this is what a snapshot contains:
For each device:
- Integration domain
- Manufacturer, model name, model ID
- Hardware and software version
- Whether the device has a configuration URL
- Device hierarchy information (via_device relationships)
For each entity belonging to a device:
- Entity domain (light, sensor, switch, etc.)
- Entity category (config, diagnostic, or none)
- Original device class (temperature, humidity, etc.)
- Unit of measurement
- Whether it uses has_entity_name
- Whether it has an assumed state
Device snapshots do not include device names, entity names, entity IDs, state values, unique identifiers (MAC addresses, serial numbers), IP addresses, or any personally identifiable information. Device IDs are anonymized using integration-scoped indices.
To ensure data quality specifically during this early phase, please note the following limitations:
- We only include integrations with integration_type explictly set
- We only include integrations with integration_type of device and hub
- We include device-type devices within hub integrations (devices with entry_type of DeviceEntryType.DEVICE) that may have both device types present
- We ignore service-type devices (devices with entry_type of DeviceEntryType.SERVICE)
- We ignore custom integrations
Note
For integration owners: To ensure that your integration is included in the device database submission please set the integration_type explicitly and refer to the limitations.