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.
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.
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.
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:
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:
The topic homeassistant/switch/entry_light/set is receiving the published payload (use an MQTT client to observe the published payload).
The state of this automation is on: automation.control_entry_light (use the States page to confirm it is on).
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.
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.
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?
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.
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.
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.