MQTT Statestream and MQTT Eventstream - pass back command

Configuration
#4

Not really. One publishes all state-changes whereas the other publishes all events. For most purposes, state-changes are sufficient (entities turning on/off, temperature values increasing/decreasing, etc).

If you search for statestream you’ll find many examples of how to use it. I like the following one because the author uses an automation in a way that makes the entities discoverable via MQTT Discovery.

In other words, MQTT Statestream runs on the primary machine and the automation makes the desired entities discoverable by the secondary machine.

#5

Thank you for this. When I read the article you sent me, it says:

use MQTT statestream to stream the states of its sensors / switches to its MQTT broker

It will populate states from discovered MQTT devices. It does not say anything about pushing changes back. This was my question, how could I push it back? I want to be able to turn on and off Z-Wave devices from my primary HA.

#6

Read this post where I describe the process of using Statestream and to provide a bi-directional connection between two machines.

Yo may also wish to consider using a custom component called home-assistant-remote. It uses Websockets instead of MQTT to create a bi-directional connection between two instances of Home Assistant.

1 Like
#7

Great, I will try it. Thank you for your help.

#8

It works, thank you for your help.

#9

Sorry, I spoke too soon. In my example, the haspbian2 has zwave switches. I want to receive updates and manage switches from haspbian1. I receiving updates to haspbian1, but I cannot manage switches from haspbian1.

The haspbian1 is the new hass.io that I am testing. I enabled Mosquitto Broker in add-ons store. Haspbian2 is not hass.io (I will set it up as hass.io when everything works) On haspbian2 I changed mqtt setup and pointed to haspbian1.

This is my setup, please let me know if you see where the problem is:

Haspbian1:
switch.yaml file:

- platform: mqtt
  name: "Entry Light"
  state_topic: "homeassistant/switch/entry_light/state"
  command_topic: "homeassistant/switch/entry_light/set"
  value_template: "{{ value | upper }}"

- platform: mqtt
  name: "Garage Light"
  state_topic: "homeassistant/switch/garage_light/state"
  command_topic: "homeassistant/switch/garage_light/set"
  value_template: "{{ value | upper }}"

Haspbian2:
configuration.yaml:

mqtt_statestream:
  base_topic: homeassistant
  include:
    entities:
      - switch.entry_light
      - switch.garage_light

automations.yaml:

- alias: control_entry_light
  trigger:
    - platform: mqtt
      topic: "homeassistant/switch/entry_light/set"
  action:
    - service_template: "switch.turn_{{trigger.payload | lower}}"
      entity_id: switch.entry_light

- alias: control_garage_light
  trigger:
    - platform: mqtt
      topic: "homeassistant/switch/garage_light/set"
  action:
    - service_template: "switch.turn_{{trigger.payload | lower}}"
      data:
        entity_id: switch.garage_light
#10

Are these the entity_ids of the two zwave lights controlled by Haspbian2?

      - switch.entry_light
      - switch.garage_light
Repalcing DELTA DORE by HA on a SBC
#11

Yes, this is another automation that I use for one of the switches in the haspbian2 and it works. Entity_id here is switch.entry_light:

- action:
  - entity_id: switch.entry_light
    service: homeassistant.turn_off
  alias: Turn Off the Entry Light in 10 minutes
  id: '1499707625051'
  trigger:
  - entity_id: switch.entry_light
    for:
      minutes: 10
    platform: state
    to: 'on'
#12

When you turn on switch.entry_light on Haspbian1 it will publish on to the topic:
homeassistant/switch/entry_light/set

Haspbian2 uses an automation to subscribe to this topic. The received payload is used to control its instance of switch.entry_light (the zwave device).

If you cannot use Haspbian1 to control switch.entry_light on Haspbian2 then confirm the following:

  1. The topic homeassistant/switch/entry_light/set is receiving the published payload (use an MQTT client to observe the published payload).
  2. The state of this automation is on: automation.control_entry_light (use the States page to confirm it is on).
#13

I am not sure if this helps but I created an automation to control the HA with the original entities.

#########################################################################################
automation mqtt_command_switch:
  alias: mqtt_command_switch
  trigger:
    - platform: mqtt
      topic: 'homeassistant/switch/#'
    - platform: mqtt
      topic: 'homeassistant/light/#'
  condition:
    condition: template
    value_template:  "{{ trigger.topic.split('/')[3] == 'set' }}"
  action:
    - service_template: "{{ trigger.topic.split('/')[1] }}.turn_{{trigger.payload | lower }}"
      data_template:
        entity_id: "{{ trigger.topic.split('/')[1] }}.{{ trigger.topic.split('/')[2] }}"
```
#14

Thank you both of you for your replies. My automation is turned on, but the problem that I see is the haspbian2 does not receive anything from haspbian1.

If I run the following on haspbean2 and change switch on haspbian1, the haspbean2 does not receive anything.

mosquitto_sub -h has2IPaddress -v -t "#" -u mqttuser -P mqttpassword

If I run the following on haspbian1, I see that haspbian2 receives it, but switch does not change:

mosquitto_pub -h has2IPaddress -u mqttuser -P mqttpassword -t "homeassistant/switch/entry_light/state" -m on

Am I doing something wrong to test it? If not, it tells me that I have two problems: haspbian2 does not receive anything and even if it receives it, the automation does not work.

#15

I would start by fixing this. Perhaps try removing the filter from statestream and make sure both are using the same broker.


mqtt:
  broker: has2IPaddress
  client_id: 1212
mqtt_statestream:
  base_topic: homeassistant
  publish_attributes: true
  publish_timestamps: true
#16

Thank you for your reply, I just want to confirm. I have switches on haspbian2 and I set it up to use haspbian1 as a broker. Both of them use haspbian1 as a broker because I want haspbian1 to receive updates and to manage switches on haspbian2.

Do you want me to change it? Should both of them use haspbian2 as a broker? What will happen with all other devices that use haspbian1 to send notifications?

Do you want to to try to remove include section from statestream or should I keep it and add publish attributes to existing statestream?

#17

What he means is to ensure they’re using the same MQTT broker and pointing at the same base topic so that they are seeing each other’s messages.

The device-hosting instance will publish states to homeassistant/domain/ID/state and the controlling instance will publish requests to homeassistant/domain/ID/set. The automation on the device-hosting instance should be able to watch homeassistant/+/+/set and then perform the action.

#18

I added

  publish_attributes: true
  publish_timestamps: true

and everything works. Thank you for your help everyone.

#19 
  publish_attributes: true
  publish_timestamps: true

These two parameters are optional and, even if included, have no bearing on whether or not an entity’s state is transmitted. I’ve successfully used MQTT Statestream without them. They’re only needed if you plan to use them on the secondary machine. The automations you have on the secondary machine (Haspbian2) don’t use them.

#20

Strange, but this was the only change.

This was my test environment. Now I am moving it to real place. I hope that everything works after I configure new hass.io systems.

#21

You also restarted Home Assistant in order to have it accept the changes. Restarting can sometimes have a curative effect for other problems. I can’t say for sure it was the cure in this case but it’s more plausible than introducing attributes and timestamps that aren’t used by any of the automations.

#22

You could be right. I also rebooted devices instead of restarting HA from Configuration page.

#23

reading is gives me the impression that you store account information of the instances in plain text, is that correct?