MQTT Statestream example needed

If you’re using node-red-contrib-home-assistant within Node-Red, to create the master/slave connections, it uses REST. In other words, Node-Red communicates the same was as a RESTful sensor (but with the added infrastructure of Node-Red itself).

FWIW, there’s an alternative version called node-red-contrib-home-assistant-websocket, created by @Kermit that addresses some of the shortcomings of using REST (by employing websockets). You can learn more about it here

There are many articles explaining the pros and cons of REST vs MQTT. Here’s one. Basically, if the need is to simply serve as a robust communications channel, MQTT is the better choice.

@Eltjo_de_Waard

For the purposes of this discussion:

  • If you want a basic master/slave system with the least amount of additional infrastructure, then go with @jimpower suggestion and use a RESTful sensor.

  • If you want to use a better communications technology, install an MQTT Broker and use MQTT Statestream (see my device_tracker example above). Use the include directive to specify only what is needed to be shared with the slave system.

  • If you also want to transform or manipulate the data sent between master and slave, then install Node-Red and node-red-contrib-home-assistant-websocket. Proceed to create a flow that connects the master to the slave and manipulates the payload. If you do not intend to alter the payload, then Node-Red only serves to provide a visual representation of the master-slave connection.

I use an MQTT Broker and Node-Red to interconnect three Home Automation systems (Premise Home Control, Home Assistant, and openHAB). Home Assistant and openHAB talk directly to the MQTT Broker whereas Premise Home Control relies on a Node-Red flow to convert its data from a TCP channel to MQTT (and vice-versa).

1 Like

trying to keep the setup as lightweight as possible, for 6 device_trackers, the state_stream should be enough…

but it isn’t very stable. the host seems not to act upon the settings as reliably as desired. have entities configured, and the slave finds these without issue. If and when the Host publishes them. I can spot with MQTT FX that that isn’t always the case, and many other device_trackers are published but not the desired configured ones… ??

which causes frontend errors/log writes on the slave, because I have these entities customized on state, and when no state is received that causes the front-end to be reachable and the system useless.

according to the docs, one should be able to only specify entities, but as I experience now, these aren’t published always. Rebooting now to see if adding the domains: device_tracker will help.
I’ll be back…

Perhaps the Statestream component doesn’t handle things correctly when the entity to be included is also part of the domain to be included? It so, that’s a bug. Maybe specify domains or entities, for include, but not both?

that’s what I tried, only entities (device_trackers) but it showed many device_trackers, alas not the ones specified…

I now have the domains: device_tracker included, and the same entities and of course it shows all device_trackers, so that’s not very useful…

btw, if I specify device_tracker.device1, (and have it publish the attributes) it creates about 5 or 6 topics for each attribute, and not 1 device_tracker with the attributes connected under it. Could have just called it a sensor for that matter… also not very intuitive like this . for example, if ones clicks the state topic in the slave’s frontend, it shows source being gps, while I would have hoped it t show bluetooth. have to reconsider if this is the way to proceed, to propagate Bluetooth devices form 1 instance to the other.

I’m using version 0.80.0. I don’t have any device_tracker entities for testing so I tried this:

mqtt_statestream:
  base_topic: hass_master
  include:
    entities:
      - sensor.indoor_temperature
      - light.kitchen

Using MQTT.fx, I subscribed to hass_master/# and it resulted in precisely two topics:

  • hass_master/sensor/indoor_temperature/state
  • hass_master/light/kitchen/state

Using the Frontend UI, I toggled the kitchen light and the state-changes appeared immediately in MQTT.fx.

It seems to work as documented so I’m not sure why it is misbehaving with device_tracker on your system. Possibly a bug?

As per the documentation, you could try a combination of include and exclude:

mqtt_statestream:
  base_topic: homeassistant
  include:
    domains:
      - device_tracker
  exclude:
    entities:
      - device_tracker.phone3
      - device_tracker.phone4

Hi @123, what is the MQTT web client you are using here? Looks great.

That one is MQTT.fx.

I also use MQTT-Spy.

Both are open-source, Java-based, MQTT clients.

Hi.
For what I’m understanding with the MQTT statestream is possible to connect two instances of Hass.io. Can they be on different networks?
For example: Master is 192.168.1.101 and slave is 192.168.2.101

My “slave” HA has to be configured with the same broker ip of the master one or they can have two different IP address?
For example: Master is 192.168.1.102 and slave is 192.168.2.102

If I want to control my second Hass.io with my master one, can I use a configuration like this:

light:
- platform: mqtt
name: “Room lights”
state_topic: “master/light/room/state”
command_topic: " "
qos: 1
payload_on: “ON”
payload_off: “OFF”

And what if I want to control the light? What command topic I have to use?

Thanks

If you can’t figure it out from this, please let me know.

Can you explain me better? I’m not familiar with value template and I cannot understand fully your automation.

How many devices to you want to control? If its just one light, its easier to manually set that up, if you want all the switches and light, then try this. (I am not sure this can be done in hassio as this is in HA in the configuration.yaml

###in main HA####

mqtt:
  broker: 192.168.2.12
  client_id: 3333
  discovery: true
  discovery_prefix: rpi1

###in sensor HA ##

mqtt:
  broker: 192.168.2.12
  client_id: 4444


mqtt_statestream:
  base_topic: rpi1
  publish_attributes: true
  publish_timestamps: true
  include:
    domains:
      - switch
      - light
automation mqtt_config_entity_creator_switch_light:
  alias: mqtt_config_entity_creator_switch
  trigger:
    - platform: mqtt
      topic: 'rpi1/switch/#'
    - platform: mqtt
      topic: 'rpi1/light/#'
  condition:
    condition: template
    value_template:  "{{ trigger.topic.split('/')[3] == 'state' }}"   
  action:
    - service: mqtt.publish
      data_template:
        topic: "rpi1/{{ trigger.topic.split('/')[1] }}/{{ trigger.topic.split('/')[2] }}/config"
#        payload: ""        
        payload: "{\"name\": \"{{ trigger.topic.split('/')[2]| replace('_', ' ') | title }}\",  \"pl_off\":\"off\", \"pl_on\":\"on\",  \"command_topic\": \"rpi1/{{ trigger.topic.split('/')[1] }}/{{ trigger.topic.split('/')[2] }}/set\",\"state_topic\": \"rpi1/{{ trigger.topic.split('/')[1] }}/{{ trigger.topic.split('/')[2] }}/state\" }"
        retain: true
    - service: mqtt.publish
      data_template:
        topic: "homeassistant/{{ trigger.topic.split('/')[1] }}/{{ trigger.topic.split('/')[2] }}/config"
#        payload: ""        
        payload: "{\"name\": \"{{ trigger.topic.split('/')[2]| replace('_', ' ') | title }}\",  \"pl_off\":\"off\", \"pl_on\":\"on\",  \"command_topic\": \"rpi1/{{ trigger.topic.split('/')[1] }}/{{ trigger.topic.split('/')[2] }}/set\",\"state_topic\": \"rpi1/{{ trigger.topic.split('/')[1] }}/{{ trigger.topic.split('/')[2] }}/state\" }"
        retain: true
#########################################################################################
#########################################################################################
automation mqtt_command_switch:
  alias: mqtt_command_switch
  trigger:
    - platform: mqtt
      topic: 'rpi1/switch/#'
    - platform: mqtt
      topic: 'rpi1/light/#'
  condition:
    condition: template
    value_template:  "{{ trigger.topic.split('/')[3] == 'set' }}"
  action:
    - service_template: "{{ trigger.topic.split('/')[1] }}.turn_{{trigger.payload | lower }}"
      data_template:
        entity_id: "{{ trigger.topic.split('/')[1] }}.{{ trigger.topic.split('/')[2] }}"

#########################################################################################
#########################################################################################

1 Like

Ok thanks, I will try :smile:

I’m working on states stream. I’m on Hassio with add-on mosquito broker.
I tried your automation code but it told me there is error in the code.

So I guess we have to set all the entities we want to share with platform mqtt right ?

I manage to publish every entity events to mqtt with that code :

mqtt_statestream:
base_topic: homeassistant
publish_attributes: true
publish_timestamps: true

And it seems to work because on MQTTFX I can see events in logs when I turn on/off a light.
BUT I don’t know how to publish a message to turn on/off my light…

EDIT : Well if I’m right we can just send the state of entities but cannot SET their state right ? :frowning: