MQTT Statestream example needed

Eltjo_de_Waard · October 23, 2018, 12:17pm

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

123 · October 23, 2018, 12:52pm

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).

Eltjo_de_Waard · October 23, 2018, 1:02pm

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 )

Eltjo_de_Waard · October 24, 2018, 12:40pm

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

letsoulfly · October 24, 2018, 1:02pm

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

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

keithh666 · October 24, 2018, 1:05pm

Just use whats in the docs…

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

mqtt_statestream:
  base_topic: homeassistant
  include:
    entities:
      - 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.

Eltjo_de_Waard · October 24, 2018, 1:29pm

So to follow your steps:

Install Mosquitto add-on on MASTER Hassio
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?

letsoulfly · October 24, 2018, 1:38pm

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

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"

keithh666 · October 24, 2018, 1:42pm

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

123 · October 25, 2018, 3:58am

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).

Eltjo_de_Waard · October 25, 2018, 5:38am

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

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

Eltjo_de_Waard · October 25, 2018, 6:04pm

Well ladies and gentlemen… I’ve got it!

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

Install Mosquitto
Set in MASTER HASSIO:

mqtt:
  broker: 192.168.1.111
  port: 1883
  client_id: hassiomaster
  keepalive: 60

mqtt_eventstream:
  subscribe_topic: slavetopic

Set in SLAVE HASSIO:

mqtt:
broker: 192.168.1.111
port: 1883
client_id: hassioslave
keepalive: 60

mqtt_eventstream:
publish_topic: slavetopic

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

But really, thank you

keithh666 · October 25, 2018, 6:42pm

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.

Eltjo_de_Waard · October 25, 2018, 7:53pm

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

Mariusthvdb · November 7, 2018, 10:33pm

looking for this!

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

mqtt_statestream:
  base_topic: homeassistant_master
  include:
    domains:
      - device_tracker
    entities:
      - 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'
    trigger:
      platform: state
      entity_id: device_tracker.telefoon_m_bt
    action:
      service: mqtt.publish
      data_template:
        topic: 'telefoon_m_bt'
        retain: true
        payload: >
          {{trigger.to_state.state}}

and created a sensor on the slave system:

homeassistent:
  customize:
    sensor.telefoon_m_mqtt_bt:
      show_last_changed: true
      templates:
        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:

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

123 · November 8, 2018, 12:39am

What about creating MQTT Device Trackers on the slave system?

If the master system is using MQTT Statestream like this:

mqtt_statestream:
  base_topic: hass_master
  include:
    domains:
      - device_tracker
    entities:
      - phone1
      - phone2

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

device_tracker:
  - platform: mqtt
    devices:
      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.

Mariusthvdb · November 8, 2018, 8:13am

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.

jimpower · November 8, 2018, 10:33am

@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.

Eltjo_de_Waard · November 8, 2018, 10:48am

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

jimpower · November 8, 2018, 10:59am

Start here https://diyfuturism.com/index.php/2018/01/18/going-further-with-home-automations-in-node-red/