MQTT Statestream example needed

Hi all,

Well basically the title says it all, I’ve read through a lot of topics, but I can’t figure it out.

Is someone willing to make (or point me to) an example of the MQTT Statestream?

For instance I have a second Hassio PI3 with a sensor and I want to see the value of that sensor on my main Hassio PI3 (put is in the influxDB)

  • What do I put in configuration.yaml of primary PI
  • What do I put in configuration.yaml of secondary PI

Hope someone can help me out! If you have any questions, please feel free to ask.

Kind regards, Eltjo

1 Like

First a disclaimer, I have no hands-on experience with MQTT Statestream. What I’m about to share is based on my interpretation of the documentation.

It publishes all of Home Assistants events as MQTT topics. So if some component changes state, it gets published.

If your use-case is just one sensor then Statestream is the proverbial A-bomb to kill a fly. You don’t need Home Assistant publishing state-changes for all components just for one sensor. For one sensor, I’d probably investigate using an automation to publish the sensor’s state-changes to an MQTT topic. Have the other instance of Home Assistant subscribed to the topic (i.e. the other instance uses an MQTT Sensor).

Oh the other hand, if you want to subscribe to state-changes for all components than Statestream is probably the way to go.

FWIW, I’ve been using another Home Automation software since 2008 (Premise Home Control; development for it ended in 2006). It works great, I know it inside out, and have written several drivers for it. However, its frontend is based on antiquated technologies and its user-base is now microscopically small. So I developed the equivalent of MQTT Statestream for it. Home Assistant is subscribed to all of Premise’s topics and now serves as the frontend.

I recently added the Homekit component and it was a treat to have Siri activate a UPB light, controlled by Premise, all through the magic of the component and MQTT (miracle glue for Home Automation).

Thanks for your reply.

I’ve read the documentation, but for me it’s not clear. Off topic, I think a lot of the documentation will benefit if there were realistic examples.

In my use-case it states one sensor, but that’s for the example. I’m getting a P1 cable to get data from my smart meter (electricity and gas), so the number of data will increase. But that would cloud the example (I think :slight_smile:)

Does no one has a small example of the code they use?

Its pretty easy…
I configured a Mosquitto instance and have three Hass instances. In every instance I wrote in config:

  broker: <IP of Mosquitto (in my case equal to my main Hass instance)>
  port: 1883
  client_id: <UNIQUE_NAME>
  keepalive: 60
  base_topic: <UNIQUE_NAME>

Just use whats in the docs…

For the pi with the sensor (you have to have MQTT setup) you want in the main pi

  base_topic: homeassistant
      - sensor.your_sensor_id

For the main pi you have to have MQTT setup, the statestream MQTT events should then automatically setup a sensor - look in <> to find it, it should have the same entity id as the remote pi. At least that’s my memory of how to set it up ymmv.

So to follow your steps:

  1. Install Mosquitto add-on on MASTER Hassio

  2. Write in both config.yaml with MASTER Hassio
    client_id: masterhassio
    base_topic: mastertopic

    and SLAVE Hassio
    client_id: slavehassio
    base_topic: slavetopic

And then it should work?

Looks fine…
Afterwards all states are accessible via e.g.
masterhassio/sensor/cpu_temperature/state or

The client ID is only needed for Mosquitto internals, the important thing is base_topic

Example in my master Hass sensor.yaml (for my nextcloudPi Hass instance):

  - platform: mqtt
    state_topic: "nextcloudpi/sensor/cpu_temperature/state"
    unit_of_measurement: "°C"
    icon: mdi:thermometer
    name: nextcloudpi_cpu_temperature
    friendly_name: "Nextcloud CPU Temp"

I don’t have a slave setup anymore as it’s not reliable imho.

I’ve read your replies to the explanations provided to you in this thread and in the one you created in r/homeassistant. I believe your confusion is due to unfamiliarity with MQTT.

I highly recommend you read HiveMQ’s MQTT Essentials. It helped me gain a better understanding of the subject matter.

MQTT Statestream isn’t at all complicated to configure and use but not having an understanding of MQTT can certainly make it seem complicated. If terms like topics, root topic, publishing, subscribing, retain, qos, etc are unclear then do yourself a favor and read MQTT Essentials (or some other introductory reference).

Hi 123,

I’m afraid you’re correct. Since I need it for a one time job I was hoping to get it done with some trial and error… will read the MQTT Essentials and try again :slight_smile:

If for some reason I won’t get it to work, are you then willing to help me out?

Well ladies and gentlemen… I’ve got it!

Just as stated above, just read through it. Here’s what I’ve done:

  1. Install Mosquitto
  2. Set in MASTER HASSIO:
  port: 1883
  client_id: hassiomaster
  keepalive: 60

  subscribe_topic: slavetopic
  1. Set in SLAVE HASSIO:

    port: 1883
    client_id: hassioslave
    keepalive: 60

    publish_topic: slavetopic

Thank you all for the tips and pointing to the right direction (READ, READ, READ).

But really, thank you

Hmm that’s eventstream not statestream so you will get all sensors, switches, lights, etc being propagated between both pi’s bit of an overkill imho.

True, but for now it is a basis to work from.

looking for this!

only need to publish the device_trackers on the Master to my Slave instance.
Id try:

  base_topic: homeassistant_master
      - device_tracker
      - phone1
      - phone2 


but now how to subscribe to those on the Slave system, and show them as device_trackers.?

Ive got 1 device_tracker now published via an automation:

  - alias: 'Telefoon M BT'
    id: 'Telefoon M BT'
      platform: state
      entity_id: device_tracker.telefoon_m_bt
      service: mqtt.publish
        topic: 'telefoon_m_bt'
        retain: true
        payload: >

and created a sensor on the slave system:

      show_last_changed: true
        icon: >
          if (state === 'home') return 'mdi:bluetooth';
          return 'mdi:bluetooth-off';
        icon_color: >
          if (state === 'home') return 'blue';
          return 'grey';
        _stateDisplay: >
          if (state === 'home') return 'Connected';
          return 'Not connected';

and finally the sensor:

  - platform: mqtt
    name: Telefoon M Mqtt Bt
    state_topic: 'telefoon_m_bt'

which works fine (creating a device_tracker in the slave didn’t btw…)

hoping that using state stream allows for not having to create automations for each device_tracker…

I can confirm all topics are created and I can see them in the Mqtt inspector (FX in my case), but, I am afraid I can only create sensors of these? I would have hoped to create device_trackers though, so please have a thought about that

What about creating MQTT Device Trackers on the slave system?

If the master system is using MQTT Statestream like this:

  base_topic: hass_master
      - device_tracker
      - phone1
      - phone2 

Then I believe you want the slave system configured like this:

  - platform: mqtt
      phone1: 'hass_master/device_tracker/phone1/state'
      phone2: 'hass_master/device_tracker/phone2/state'

Only thing I’m not sure about is if the last part of the MQTT topic is state or something else for device_trackers.

1 Like

thank you!
working nicely indeed. with /state btw, because that’s the only topic published

now I can use BT trackers, and not burden the main system with it. very nice.

@Mariusthvdb why don’t you just use the restful sensor to pull sensor state from remote instances? Or better yet use Node-RED I don’t even bother with statestream any more as Node-RED can be the bridge required. I run 3 main instances and another 3 slaves and Node-RED handles the interaction between them.

Is there an easy to read tutorial (or example) explaining Node-RED?

Start here

1 Like