MQTT Statestream for connecting 2 HA instances

Issue to solve. I will get a new HA instance, just a small setup on a RPI. It will be behind a double NAT with no public internet address. It will have a few sensors I would like to propagate to my main HA instance.

My idea was to use MQTT Statestream on the remote HA and using exclude/include to control the few sensor I would like to replicate to the main HA.

It look super simple in the documentation. However, I have got a initial problem.

For MQTT Statestream to work it needs a MQTT integration on the remote HA. When I setup this, I point it to the Mosquitto broker on my main instance (easy now as they are on same network, will solve the security part later).

When I do this, it will discover all the Z2M and HAAS agent devices, which was not the intention, as I only setup MQTT integration for MQTT Statestream to send statechanges for a few sensors…

The solution should be to disable “discovery” on the MQTT integration, however I can not figure out to do this during initial setup. The possibility does not show during initial setup by the GUI, only later in the configuration. At this time all the MQTT devices are already discovered, and they are not removed again when I chose “do not discover”. They show up, however is not actually working.

Im also in doubt about the base tropic, should I leave this as “homeassistant”

I have been looking for examples for MQTT Statestream, however not found any good examples in the community forum.

Have you already looked at remote home assistant? that may enable what you want much simpler.

I have looked at remote HA. Problem for “remote HA” is the way the connection is created. The “host” is initiating the connection and not the remote HA. As I cannot get to the remote HA from outside (there is no IP address), this is not an option.

This is why statestream seems better, as the remote devices are initiating the TCP connection.

An alternative I can look into is creating a VPN with a WLAN, However seem a lot of work for something small.

This is what I have:

  base_topic: statestream
  publish_attributes: true
  publish_timestamps: true  
      - light.smart_plaffoniere
1 Like

Hi Francis, seems right.

How did you setup the MQTT integration on the HA instance. I read it as a pre requisite, for statestream to work…
When I setup MQTT integration, it discovers all devices from the MQTT Broker. I would like to avoid the secondary HA instance have the devices detected. Did you do something special?

No, but for me I wanted them.

You could set up the mqtt integration on another broker, disable discovery, and change back to the original broker

Or setup a mqtt bridge en filter discovery messages.

Francis, Might not be a straight forward solution, however works:-).

For others finding this thread. This works perfect.

For entity creation and working both directions, have a look at this nice writeup from Taras, which helped me a lot.

my 2 cents in this discussion:
Until april 2024, i was using REMOTE-HA integration to connect a master HA instance and a slave one.
Since Core-2024.4.x calling a remote script makes the script runs several times… (and it’s random ! not each time…). Restoring Core-2024.3.x solved the problem.
I made a post on the dev github page of remote-ha but for sure i won’t get any answer… looks like it’s not maintained anymore :roll_eyes:
So i’m in the process of migrating from remote-ha to MQTT with statestream and also with MQTT Sensor and Switch integrations.
About 80% already done :slight_smile:
I found that for some specific switches (GPIO 2 special relay circuit on the slave instance that only accepts an “on” event to trigger and automaticaly comes back to “off”), i had to use the exact same topic for the command and the state otherwise the relay is triggered with a simple topic refresh… (sometime a simple ha reboot has caused a trigger) Just because with the classic “2 topics”; one for command and the other for state, the command stays “on” while the topic is well returned to “off”…
Using the same topic for both, makes (of course) the command return to “off” and does not trigger accidentaly anymore :grinning:

Before MQTT was moved to UI setup it was possible to configure MQTT without discovery being enabled. Since the move to UI setup you have to disable discovery after setup. The only way around this that I found was to initially connect to a ‘dummy’ MQTT server and then point to the correct server as part of reconfiguration.

It is a pain and you should really be able to disable discovery as part of the Initial UI setup process.