Supported devices vs best-effort behavior

[grave bridge]

Quick design/review question.

My preference is to keep docs and setup behavior tightly aligned:
if something is documented as supported, setup should be allowed and it should work in the way a user would reasonably expect.

If something is not validated or tested well enough yet, I’d rather not allow setup than expose users to a partially working integration and a bad experience. That seems aligned with the intent of the supported/unsupported devices guidance:
https://developers.home-assistant.io/docs/core/integration-quality-scale/rules/docs-supported-devices/

Would that be considered an acceptable line in core, or is the expectation more to document the limits, but otherwise keep things best effort, even if the resulting experience is only partially functional?

In my case, the API supports multiple devices (7), but I have only validated part of that surface so far. Allowing setup without limitation would expose unsupported models to an integration that is, at best, only partially functional.

[still harness]

It often happens that new integrations get merged but subsequent PRs don't make it in time into the next release. It takes several releases until everything is fully supported and even then, sometimes there's still more that can be improved. Home Assistant is not a commercial product, integrations don't have to be perfect from the beginning, you can iterate. People should also be accustomed that new integrations lack features at the beginning, although some aren't patient enough and will still raise issues or complain that features are missing.

[grave bridge]

Makes sense. I think my question is slightly narrower: how does core generally look at unvalidated device models behind an otherwise supported API? Would restricting setup to the validated subset be acceptable, or is the expectation to allow them and document the limitations until support is filled out?

[still harness]

as long as it doesn't break the integration, I would allow it. I had for example some unsupported ZigBee devices that only showed a sensor for link quality and nothing else and that happens pretty often. You will probably get feature requests to support device X or Y. That might help prioritize into what devices you want to look into next

[grave bridge]

Although I can see the value in "allow unless it breaks the integration," my personal preference is still to use a clearer support matrix where possible. It gives users a more predictable experience and makes expectations explicit. Many Home Assistant users are not developers, so they depend on the integration to communicate those boundaries clearly. If I know one subset is validated and another is not, I’d rather enforce that boundary than allow setup into a state that is only partially functional or ambiguous. As a secondary benefit, that also reduces issues and feature requests for hardware that is not actually supported yet.