I was just thinking about HA for larger homes, and how it might make sense to have an architecture that allows for one piece of hardware running HA to be deployed to each room in the home - all of which report back to a Master HA instance.
Doing this type of (optional) decentralization might help with:
Overall resilience (replacing an RPi in the dining room doesn’t bring everything else in the home down)
Context for commands (“Hey Ada, turn it down” in a room that only has dimmable lighting - as opposed to lighting and music speakers and/or TV - would no longer be ambiguous)
Now there’s hardware that I can plug things into in each room for any purpose that I’d like (microphone/speakers for voice command interaction, maybe a zigbee/zwave stick, etc)
Presence detection would be easier (especially the bluetooth method that folks are playing with)
Locking down control by room could be a lot easier because you could literally associate device control with a dedicated piece of hardware for that room
That’s just one particular addon that handles Presence Detection that can be deployed to multiple pieces of hardware throughout the home.
I’m talking about having multiple HA instances (one per room) coordinating with a Master HA instance for the home.
So, for example, if you’d like to use Room Assistant, you could tell the Master HA instance to tell all other HA instances throughout the home to install the Room Assistant addon, making Room Assistant a lot easier to setup.
API and I think room assistant also allow this setup.
I’ve been doing this almost since HA started. Currently I have HA on server and (3) pi at remote spots around home where wifi/zwave was not reliable for critical function.
Eventstream/Statestream is just for controlling/managing devices through MQTT communication. They won’t help you deploy different addons throughout the home or manage config changes unique to the different HA instances.
Also, in my suggested architecture, it might be cool to have each HA instance keep snapshots of every other node, so that any HA instance is capable of restoring any other HA instance in the home.
Another use case I just thought of: All HA instances could be logged into Nabu Casa using an account assigned to that home, so that even if one HA instance goes down, I’d still have remote access. No more single point of failure.
i think this is a too specific usecase to integrate this into Home Assistant. I assume there are only a small number of people who need this kind of feature and I think most of the people that need something like this are able to do this themselves or solve it in some other way (I don’t see why I would need a HA instance in every room when I can get the data to the Main inatance through other means such as MQTT etc.). For a failure of HA instance you can create a Kubernetes Cluster or something similar (I didn’t have any HA downtime in over 2 years, expect for when I was migrating the server to new hardware) and even if it fails it doesn’t take long to get back up from a snapshot.
There are plenty of large homes out there owned by people who don’t want to bother spending time figuring out how to implement this type of functionality themselves.
Redundancy, flexibility, stability, reliability, context for certain commands that would be considered ambiguous otherwise. See my earlier bullet points. And in the context of larger homes, the added cost for hardware would be negligible.
If we’re trying to get HA into the hands of non-technical users, I really don’t think that relying on the homeowner to implement Kubernetes should be a suggested solution. If the devs want to implement Kubernetes as a solution on the backend and just float certain controls to the GUI, then that’s a different story.