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:
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
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.
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 https://diyfuturism.com/index.php/2018/01/18/going-further-with-home-automations-in-node-red/
1 Like
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.
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
includedirective 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/statehass_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.
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 
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 ? 