Best way to connect ZWave switches on second HA instance to main HA instance?

Configuration
,
1

Hi All

My goal is to control two ZWave switches connected to a 2nd remote instance of HA in the UI of the first HA instance.

To this end I have:
A “main” HA and a “remote” HA instance (ie master/slave).
Two ZWave switches connected to the remote HA. They are visible in the remote UI and working.
On the remote HA I have setup MQTT StateStream:

mqtt_statestream:
  base_topic: remote_ha
  publish_attributes: true
  publish_timestamps: true

I can see the MQTT messages on the MQTT broker.

On the main HA I created a MQTT switch:

- platform: mqtt
  name: "Tuinhuis binnen"
  state_topic: "remote_ha/switch/tuinhuis_binnen_switch/state"
  command_topic: "remote_ha/switch/tuinhuis_binnen_switch/command"
  qos: 1
  payload_on: "on"
  payload_off: "off"
  retain: true

The state_topic is what I see coming in on the MQTT broker. The switch state is correctly displayed in the main UI.
So far so good. Now I want to be able to control the switch through the main UI. My understanding is that StateStream is one way (ie to the MQTT broker, not listening to it), so I made up the command_topic.

Then on the remote HA I creation two automations:

- action:
  - data:
      entity_id: switch.tuinhuis_binnen_switch
    service: switch.turn_on
  alias: MQTT Tuinhuis binnen ON
  condition: []
  id: '1516791772654'
  trigger:
  - payload: 'on'
    platform: mqtt
    topic: remote_ha/switch/tuinhuis_binnen_switch/command
- action:
  - data:
      entity_id: switch.tuinhuis_binnen_switch
    service: switch.turn_off
  alias: MQTT Tuinhuis binnen OFF
  condition: []
  id: '1516792318849'
  trigger:
  - payload: 'off'
    platform: mqtt
    topic: remote_ha/switch/tuinhuis_binnen_switch/command

This is so that the button in the main UI sends an MQTT message that is picker up by the remote HA.

Result: it works (yeah!) but feels clunky. The button in the main UI toggles between on and off because it will only display the correct state after the MQTT round trip. Secondly, it seems like a lot of work just for 1 switch.

There must be a better way to two this. Suggestions Appreciated!

2

You need the state_stream on both, one as master and one as slave, nothing else needs to be done as the states etc will propagate between the two. At least that’s how I do mine as Win 10 can’t do zwave but my pi can :slight_smile:

Ahh sorry I’m using event_stream not state_stream :stuck_out_tongue: So ignore me :stuck_out_tongue:

3

I do pretty much the same thing with my zwave switches. Mine doesn’t have the issues with toggling like you’re describing. If you use a MQTT client and subscribe to those two topics, is there a delay for the messages coming up?

One thing I noticed that may be causing a slow down, is that you have attributes and timestamps on. Which means that there is a lot of extra information being sent that you don’t seem to be using. At least from what you’re saying here. You can also limit statestream to just the switches you’re using it for to cut down on that even more.

I’ll double check my config when I can to see if there’s anything different between our setups. That’s the only thing I can think of currently.

4

@aterox I’ve reduced the number of MQTT messages and , indeed, the toggling goes away. Thanks!

Still the solution of the Statestream going one way and MQTT commands going the other way and being picked up by the automation rules feels clunky. Fortunately I have only 2 switches.

@keithh666 how does it work with EventStream? In another thread it was mentioned that Statestream was preferred in some way.

5

I run win 10 HA as main and an RPI 3 as a slave (running hass.io) with my zwave and xiaomi gadgets on the slave as they don’t work on win 10. This all works well except that the states of everything is propagated to the slave as well, currently 7 times so everything on the slave is sent to the master and then sent back to the slave. So the frontend looks a complete mess on the slave, however it all works well in that I can control the RF Link on the master from hass.io and the master (win 10) can control the zwave and xiaomi devices on the slave. But if anyone can help on the frontend or suggest where I’m going wrong with the eventstream I’m all ears :slight_smile: What I think is happening is that when I restart the win 10 HA it propagates a new copy of the data from the slave thereby increasing the copies of the sensors etc. See pic below…

image
image1306×600 60 KB

So the above shows that I’ve restarted the win 10 master 7 times so far as all of the xiaomi sensors are replicated 7 times in hass.io :stuck_out_tongue:

6

I currently do it with ~10 switches. I agree it’s not the most ideal method, a component to do this would be ideal.

I used to use eventstream, but didn’t like how there’s no way to filter the events and that the devices will disappear off the main instance’s front end after a while of not being updated.That’s why I prefer the roundabout method with statestream.

7

You could always set a default view with only the devices you want to show up, which should get rid of the automatically propagated ones.
Are you restarting the main instance with the button in the ui or manually? If you restart it through the ui, eventstream will also restart the slave instance, which may help get rid of the devices

8

Yep I noticed that if I restart hass.io they go away until I restart the win 10 end. Thanks for the pointer, I have default view on the win 10 end, but forgot to set it up for the hass.io end :stuck_out_tongue: I did start looking at statestream but felt it was too much work with all the devices I have, maybe I should have kept going with it :slight_smile:

9

No problem. Hopefully eventstream continues to work for you. Have you had any issues with the slave’s devices disappearing off the main’s front end?

10

Yep sometimes they do disappear which can be a PIA as it’s usually just as I’m going to bed and want to turn off the lights :stuck_out_tongue:

11

That’s the same issue I was having. I ended up getting tired of it and doing the extra work to setup statestream.

1 Like
12

OK, you convinced me to give statestream a go, tho’ it’s all your fault if I keep coming back to ask questions :wink:

13

It’s worth the effort IMO. At least with MQTT switches/sensors on the main instance, they don’t disappear

14

Agreed that is a big plus :), I’ll have to give it a try :slight_smile:

15

I’ve now opened a pull request, which implements an alternative to mqtt_eventstream and mqtt_statestream by directly using the Websocket API, please have a look here: https://github.com/home-assistant/home-assistant/pull/13876

Would be happy to hear feedback.

2 Likes
16

That looks very useful indeed, great work :slight_smile:

17

MQTT EventStream + Automaton templates makes it a little less clunky.

e.g. Switch, Light + Brightness

- id: "1"
  alias: "Switch Command"
  trigger:
    - platform: mqtt
      topic: "remote_ha/switch/+/command"
  action:
    service_template: "switch.turn_{{trigger.payload}}"
    data_template:
      entity_id: "{{trigger.topic|replace('remote_ha/', '')|replace('/command','')|replace('/', '.')}}"

- id: "2"
  alias: "Light Command"
  trigger:
    - platform: mqtt
      topic: "remote_ha/light/+/command"
  action:
    service_template: "light.turn_{{trigger.payload}}"
    data_template:
      entity_id: "{{trigger.topic|replace('remote_ha/', '')|replace('/command','')|replace('/', '.')}}"

- id: "3"
  alias: "Light Brightness (On) Command"
  trigger:
    - platform: mqtt
      topic: "remote_ha/light/+/brightness/command"
  condition:
    - condition: template
      value_template: "{{ trigger.payload != '0' }}"
  action:
    service: "light.turn_on"
    data_template:
      brightness: "{{trigger.payload if trigger.payload != '0' else ''}}"
      entity_id: "{{trigger.topic|replace('remote_ha/', '')|replace('/brightness/command','')|replace('/', '.')}}"

- id: "4"
  alias: "Light Brightness (Off) Command"
  trigger:
    - platform: mqtt
      topic: "remote_ha/light/+/brightness/command"
  condition:
    - condition: template
      value_template: "{{ trigger.payload == '0' }}"
  action:
    service: "light.turn_off"
    data_template:
      entity_id: "{{trigger.topic|replace('remote_ha/', '')|replace('/brightness/command','')|replace('/', '.')}}"
18

Did you publish a custom component after your PR was rejected? I find the existing MQTT approach to be so complex and unreliable to the point of uselessness. Would be interested in using a custom component for websocket communication.

19

Hi, Is this broken on version 0.77.0?