Hello, I connected two HAs using MQTT Statestream and MQTT Eventstream. I want to have Z-Wave devices on my secondary HA.
I have two issues. First, I specified two devices only, but I can see more. The second problem that I have is that I cannot manage Z-Wave devices from my primary HA. It displays the status and changes if the status changed on the secondary HA, but I cannot change it from my primary HA.
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.
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:
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.