Multi-Site Home Assistant Overview
There are a number of reasons why you might want more than one instance of Home Assistant. Whatever the reason, sometimes you want complete separation (an isolated "test" system for example) but often you might want some degree of connection between them. This post looks at ways to connect separate systems together, share state data between them and even trigger actions in one system from another.
If you have more than one running instance of Home Assistant (HASS for short), there are some cases where you don’t have to care. For example, if you have Philips Hue in your Smart Home, then you’ll find each HASS instance which can see the Hue bridge on your network will suggest you “configure” the Hue integration, and you’ll then see the state of all the Hue devices on both/each HASS instance in its Hue Integration devices list.
This works for any integration whose data source can handle multiple connections. If your data sources, like Hue, are designed to handle, for example, a mobile app on several family members’ phones, the HASS integration will more than likely be able to connect to those services from more than one HASS instance.
But what about when that isn’t the case?
Some data sources, such as addons from the addon store are separate docker containers connected to an internal docker network which can only reach their local HASS instance. If you hack at the configs, or run standalone docker, you might be able to expose a source outside of its local HASS instance, but some, like Zigbee2MQTT are only designed to send data to a single destination.
Then, there are cases where the data source is rate-limited, and doubling or tripling the number of polling requests when adding more HASS instances all polling away may work, but may exceed a limit and stop returning data or kick off charging of overages. Or, as is the case with polling data from EVs (and some ICE cars too), waking the device from low-power sleep causes an excessive battery train which may be an issue.
Multiple Home Assistant - Approaches
In the introduction we noted that “completely separate” is a valid approach when you have more than one HASS instance. So is connecting multiple instances to the same data sources (that support that approach). Let’s see what other options we can come up with!
Hint
None of these approaches are better or worse than the others, but some may be more suitable for the outcome you want to achieve.
HACS “Remote Home Assistant” integration
Let's start with the simplest approach. If you want to see everything from a remote HASS instance in a local one, the remote_homeassistant HACS Integration by Lukas Hetzenecker (and contributors) brings all the states it can poll, from the remote instance, into the local one, with optional entity and friendly-name prefixes.
This is perfect if you wanted to scale a single “logical” instance by adding multiple separate instances together. This could be ideal if you wanted a single dashboard view of multiple HASS instances. The integration also takes care of removing all the “remote” entities if the link to the remote HASS instance is lost.
N.B.
I haven’t used this integration, and although I have absolutely no reason to doubt it, without testing, it’s hard to say how well it works. It has plenty of configuration flexibility, and is, at the time of writing, being updated regularly. The Github readme suggests it also includes a service proxy to pass Service calls (now Actions) to the remote instance which is pretty cool and completes the “collect states” / “control entities” picture.
If we connect two large HASS instances, the main site will have to handle a lot of extra entities, events and state changes. This might impact processing on the instance, particularly if it’s running on a low power SBC like an older Raspberry Pi. Also, while removing entities if communication with the remote site is lost is arguably better than leaving “stale” data behind, any automations or dashboard displays, which rely on that data, will need a way to show an appropriate message or value in place of the missing data.
If the end goal is to create a single “instance” this approach works well, particularly if there is one obvious “hub” instance and one or more “satellite” instances covering say, different locations, or floors, or to add multiple instance of an addon or integration where each HASS instance only supports one. But, if you have multiple HASS instances, say in different locations, which are each the “main” instance for their location, but also want to pull into them, some information from the “other” locations, things get complicated. This integration would need to be installed in each HASS instance, and then each of them would have all the states etc. for all the sites. It might also require careful configuration to ensure remote data isn’t shared back to its source site and then back again, creating an endless loop of replication.
Home Assistant and MQTT
This approach uses the interconnection capability of MQTT. Originally the Message Queuing Telemetry Transport (protocol) 1 2 which is a lightweight Publish/Subscribe system which allows sources to “publish” messages without knowing or caring who can receive them, and recipients to “subscribe” to messages without knowing who can send them.