Support extending the list of known assistants

[gileswells]

Introduction

My goal is in theory simple but likely a larger undertaking than I am anticipating but I'm willing to do the code work for this.

I would like to extend the exposure system that is currently hard coded and includes Assist, Amazon Alexa, and Google Assistant to be able to include other platforms. In short, I would really love to be able to toggle on and off a device for integration with HomeKit just as easily as I can with Google Assistant.

But why?

My youngest child has started showing interest in home automation and I've given them admin access to Home Assistant (I confirmed that backups were enabled, running properly, and scaled them up a bit) so that they can explore and have fun. While I haven't been the biggest fan of how I need to manually expose entities and devices through the HomeKit Bridge integration, I've managed because that's how it needed to be done. Now that my kid is wanting to mess around with it, I'd love to be able to contribute and give them a similar path to making things and exposing them to our Apple Home ecosystem.

Possible paths forward

I see two distinct paths forward for this, both of which I feel are viable but only with signoff from the architecture team since they would require PRs to both the core and frontend repos plus would fundamentally change some existing design choices that have been made within Home Assistant.

HomeKit Bridge Integration

I think the best solution would be to incorporate the logic changes, beyond the necessary core/frontend updates, within the existing HomeKit Bridge integration that is sitting at a reported 17.4% install base. Currently, the integration does an include/exclude based on device types with the ability to more narrowly include and exclude specific devices on top of that. My hope would be to find a way to support this existing setup so that user wouldn't be forced to change their setup if they don't want to but I would also include the ability to list HomeKit under the Voice assistants section of the edit modal as well as the other locations the expose system is surfaced in the interface.

How to support both methods under the hood is still a problem I've yet to fully architect but with the blessing of @bdraco and @Jc2k I'd like to try. This path forward would allow for strictly sticking to a known list that would extend to include homekit, the other option is definitely more extensible but feels maybe a bit too open.

Externally Controlling the HomeKit Bridge Integration

If the ability to bake this into the existing integration isn't a workable solution, I'd instead want to create an integration, perhaps through HACS but preferably directly within the core integration system, that would listen to changes within the Expose flows and then use that to maintain a HomeKit Bridge instance through explicitly listing entities on behalf of the user. My goal here is not to recreate the amazing work done in the HomeKit Bridge integration but to layer on top of it an alternate method of how to manage what devices are specifically exposed through the same system that users are familiar with for Assist, Alexa, and Google Assistant.

Essentially the flow that I'd follow, including a debounce which would be especially useful for the expose tab under Voice Assistants, would essentially be to generate a HomeKit Bridge instance and name it something like "[DO NOT EDIT] HomeKit Bridge for Exposed Entities" and just hope that users understand not to mess with it and then all entities that are exposed through the Expose flows would get added to this integration and then I'd reload it when devices exposure is changed so the changes would be reflected in the Home app almost immediately. Knowing me, if it's possible to do so, I'd also probably incorporate the reverse logic so that even if people did modify the list of entities within that bridge instance I'd take that change and add / remove that device from the expose list so the data doesn't get out of sync. I'd likely also tie into the Repair system such that if they broke the controlled integration by changing settings that would make it incompatible I could surface the problem to them and provide guidance on how to resolve the issue.

The extensible part of this that would be required is that if this change isn't locked down to just adding homekit like the first path would allow, we'd have to allow for the list of KNOWN_ASSISTANTS to be extended by users. Essentially there'd have to be some form of structure that would allow an integration to add itself to the list of KNOWN_ASSISTANTS. This could be a big win as it could enable for hooks into platforms that haven't been explored or might be very niche that it would never have a chance being included as a core contribution but would be a massive win for smaller populations within the community. This of course doesn't come without risks and it could cause the Expose flow to get cluttered if integrations just started adding themselves to the list where they don't necessarily belong.

The UX Problem

Currently, the KNOWN_ASSISTANTS list is specifically for voice assistants. This is unfortunate because if this list was scoped more along the lines of Platform Connections I think it would be much easier to make the case for HomeKit as a platform connection rather than trying to shoehorn HomeKit into the existing list of known assistants where it really doesn't fit within that currently defined scope. Could this be branded as being a Siri voice assistant, I think so, but that doesn't really rub me the right way because at it's core it's not a "Siri" integration. It's a HomeKit integration.

Though, now that I've typed this out, the argument could be made that the same situation exists for Google Assistant as the main connection is getting the devices into the Google Home platform and then Google Assistant has access to them because they're listed in Google Home. Nope, this is wrong. I just confirmed that Google Assistant can access / make requests to a device that's exposed to Google Assistant but doesn't exist anywhere in Google Home. Exposing to Google Assistant is entirely separate from adopting a device to be shown in the Google Home app.

In Conclusion

I'm fully aware that this is a sizable feature / architecture proposal, but it is one that I'm willing to put in the time required to implement. I think that Home Assistant users that utilize the HomeKit Bridge integration would be massively benefitted by having an easier path to controlling what is and is not exposed to their Apple Home ecosystem and I know that my 14 year old would be much happier with this type of setup as well. If you made it all the way to here, thank you so very much for reading and I welcome your questions, comments, concerns, or anything else this discussion needs to come to its proper conclusion either in favor or against this change.