If Home Assistant implements crucial automation functions, relying on a single instance isn’t good. With inexpensive devices like the Raspberry Pi it is relatively cheap to use multiple HA instances.
I know that there is already a master/slave setup, but it would be good to have a master/master setup where multiple instances just exchange their messages and synchronize their states.
I’m willing to contribute to this, but I don’t want to start working on something before the target architecture is defined. Any comments?
Great idea, this sounds great! +1
Can this not be accomplished with MQTT messages in current build?
What about MQTT Eventstream component?
I did not know this. This might be an option for this use case.
finally got chance to try this out and works great.
HASS Master on Synology Docker image
HASS Slave on RasPI with GPIO connected zwave, motion, magnetic(door) and temperature sensors
I can walk past motion and it instantly show OPEN on Docker HASS.
temp and zwave show on Master GUI
In case you set this up, be aware that you will not see sensor appear until after 1st mqtt report.
The OP request sounds like he wants an exact duplication, so that if one device goes down, the other one will be able to fulfill all of the same automation tasks, etc.
Although this works great if all of your “devices” and “services” are virtual, cloud based or independent of a host/parent attachment, it doesn’t work so well for hardware that is either tied to GPIO or even Z-wave networks, as they are specifically parented to a host system or controller.
Other than that, there is no real reason to recode anything on the HASS side, because HASS, by design, is a universal communicator to all IoT devices and services, including another HASS installation by monitoring the streams or via any number of messaging protocols (ie MQTT) or directly through the RESTful API
Some of this sounds like obvious duplication to what was already discussed, but I just thought it would be more clear for others that stumble across this thread that if they are using Z-Wave or GPIO, there is no way to have true duplication across RPi devices, as there will always be a single point of failure at the host RPi.
Then again, I’m not quite sure what type of “failure” you are afraid of occurring by using a single RPi. If your house burns down, both the primary and secondary RPi will all burn down together. If you are afraid of data corruption on the SD card, well, having a robust set of backup scripts is your best bet. I have a Micro SD card reader plugged in the back that keeps a bootable backup of the primary SD card. At midnight, all changes to the primary SD are synced to the secondary bootable SD card. That way if the primary fails, I simply pop the secondary in and it boots right back up.