Using Event Stream to link two Home Assistants

Configuration
1

TL;DR: Don’t do it.

ZWave makes Home Assistant VERY slow to shut down. Unbearable. I’ve seen some talk going around about how it might be a good idea to run ZWave stuff in one Home Assistant… and everything else in another… and then link the two using eventstream.

Here’s the problem… you need state_change events to flow from the ZWave HASS to the Master HASS, or you won’t see your devices in the Master HASS. And you need service_call events to flow from the Master HASS to the ZWave HASS or you won’t be able to run automations that control any of the zwave devices.

I turned off discovery on the ZWave HASS… because I only need ZWave. But, there must be service_call events that make it go anyway, because the ZWave HASS error logs were filled with messages about how it’s trying to connect to various services but doesn’t have the credentials to do so.

The Master HASS was mostly okay. Except, none of the zwave devices worked because the ZWave HASS eventually gave up on everything. It was even complaining that it couldn’t find the input_boolean.turn_on service.

If I run either of them alone, it runs fine (except for the automations that don’t work because none of the zwave devices are present). But… both at the same time… no. Just don’t do it.

2

Looks like your post may have saved me some trouble as I was just about to do something similar. I still might, though, since my goals are a little different.

I wanted a few components (mostly media players) on a separate instance. I’m going to control them via AppDaemon, so setting up automation across multiple instances should (hopefully) not be an issue. But I still wanted to see (and preferably control) those devices in the main frontend. Is that possible? Or do they only show up as sensors?

3

They will show up as devices.

Say you have MASTER-HASS… And you have MEDIA-HASS…

Each of them has an mqtt event stream it can publish to. All events get published. You can ignore entire classes of events, but there are only two: state_changed, and call_service. And, as I’ll point out, you’re going to need both.

So, you want the devices in MEDIA-HASS to show up in MASTER-HASS. That means you’ll need MEDIA-HASS to publish state_changed events, and you’ll need MASTER-HASS to subscribe to them. Easy. Now your devices show up in MASTER-HASS. But, you can only look at them. You can’t change them in any way because changing them is a “call_service” event. So… you need MASTER-HASS to publish call_service events and MEDIA-HASS to subscribe to them.

This will basically do what you want. MEDIA-HASS however, is going to see ALL services called on MASTER-HASS. So, when you turn on a light, MEDIA-HASS will hear about it. It’ll ignore it, because the device doesn’t exist over there. But it’ll still see it. Sun events, for instance, will be pushed to MEDIA-HASS, so make sure you turn off the “sun” component on MEDIA-HASS or you’ll be getting events from both systems on MEDIA-HASS. “Discovery” should be turned off on MEDIA-HASS too, or else it’ll discover the same things MASTER-HASS does, and things will break.

If you’re careful, you can make it work like this.

BUT… for instance, mqtt.publish events are sent across the eventstream. It’s smart enough to ignore the event where it’s publishing the event (or there’d be an infinite loop) but, if you use the mqtt.publish action anywhere in an automation, it’ll be published twice. Because you can’t disable MQTT on MEDIA-HASS since it’s needs it to do eventstream.

So, to sum up, if you want this to work…

configure like this:

MASTER_HASS
---
mqtt_eventstream:
  publish_topic: hass/eventstream/master
  subscribe_topic: hass/eventstream/media
  ignore_event:
    - state_changed

MEDIA HASS
---
mqtt_eventstream:
  publish_topic: hass/eventstream/media
  subscribe_topic: hass/eventstream/master
  ignore_event:
    - call_service

Then, turn off EVERYTHING on MEDIA-HASS. No discovery. No sun. No weather. Etc.

Also, if you’re trying to use TTS to your media devices… I don’t know how well that’ll work across the link. So you might have to turn TTS on ONLY on MEDIA-HASS. I’m not sure.

It’s a weird feature, not well implemented, and with very little example configuration offered.

4

I went down this route with my 3 instances you can use statestream & eventstream however I ended up ditching this approach and used node-red to link my instances its the invisible bridge you’re looking for :wink:

There are some examples of those who have used the above method to successfully run 2 instances of HA.

5

This is likely the way to go, as you’ll have much more control over what gets passed to each instance of Home Assistant.

6

I ended up creating the zwave switches as mqtt switches in the main instance and in the slave instance an automation for each switch turn them on and off.

7

How did you create a zwave switch as an mqtt switch?

8

@swiftlyfalling, thank you so much! This is much more thorough than I was expecting, but much appreciated. Guess I’ll try to set things up this weekend and see how it goes.

And that’s a great point about TTS. I do use TTS in my automation but, thankfully, not on any of those devices.

Out of curiousity, has anyone tried using the API to connect instances? Supposedly, /api/event_forwarding can be used to forward events from one instance to another, but I couldn’t get this working at all. I have the API enabled on both instances, but got a 404 error every time I tried to forward. Documentation is pretty sparse for this, too, so it’s possible I simply wasn’t making the call properly.

1 Like
9

This is good in my case that i have only a few zwave devices.

Main instance:
switches.yaml

- platform: mqtt
  name: "Cafetera"
  command_topic: "zwave/cafetera/set"  
  state_topic: "zwave/cafetera/status"
  qos: 0
  payload_on: "ON"
  payload_off: "OFF"
  retain: false

Slave instance:
autoamtions.yaml

 - id: cafetera_on
  alias: Cafetera ON MQTT
  hide_entity: true
  trigger:
  - platform: mqtt
    topic: zwave/cafetera/set
    payload: 'ON'
  - platform: state
    entity_id: switch.switch_2
    to: 'on'    
  action:
  - service: switch.turn_on
    entity_id: switch.switch_2 
  - service: mqtt.publish
    data:
      topic: 'zwave/cafetera/status' 
      payload: 'ON'
        
- id: cafetera_off
  alias: Cafetera OFF MQTT
  hide_entity: true
  trigger:
  - platform: mqtt
    topic: zwave/cafetera/set
    payload: 'OFF'
  - platform: state
    entity_id: switch.switch_2
    to: 'off'
  action:
  - service: switch.turn_off
    entity_id: switch.switch_2 
  - service: mqtt.publish
    data:
      topic: 'zwave/cafetera/status' 
      payload: 'OFF'
2 Likes
10

combining

and the statement around it says that there is not a possibility to fine filtering, you can only filter on top-level, so you switch on MQTT on demand but what is the purposes of