Newbie question - how do I find the identity and topic for an mqtt message

[papasierra]

I’m trying to figure out how to get mqtt started.
I have two Rasberry Pi’s each with it’s own Hassbian installed. One runs in the main house (hassbian1). Hassbian1 has a Vera Plus attached to it and this runs all the z wave stuff in the main house.
The other (hassbian2) runs in a shed (too far away to connect directly to the Vera Plus) and has a z wave USB stick attached to it. This runs a couple of z wave switches.
The hassbian1 has mosquito set up on it. Both HA instances have the MQTT integration set up with the broker on hassbian1).
Hasbian1 configuration.yaml has the following:

mqtt_eventstream:
publish_topic: hassbian1/topic
subscribe_topic: slaves/#
Hassbian2 configuration.yaml has the following:
mqtt_eventstream:
publish_topic: slaves/hassbian2
subscribe_topic: hassbian1/topic

I want the main HA instance (on hassbian1) to be able to control a z wave switch on hassbian2. However because this runs some machinery that I don’t want to switch on and off while I practise how to work the MQTT, I am trying to set up a binary sensor on hassbian2 that monitors the state of a light switch in the main house.

This is the MQTT message I can see in the hassbian2 log when I switch on the Utility room light in the main house:

Apr 07 23:09:08 hassbian2 hass[561]: 2019-04-07 23:09:08 DEBUG (MainThread) [homeassistant.components.mqtt] Received message on hassbian1/topic: b’{“event_type”: “state_changed”, “event_data”: {“new_state”: {“context”: {“id”: “8a92e54df9c24180936a990dafb5bbea”, “user_id”: “823b2d1abc644f9db72cf476aff7d624”, “parent_id”: null}, “state”: “on”, “last_changed”: “2019-04-07T22:09:05.652604+00:00”, “attributes”: {“Vera Device Id”: 122, “supported_features”: 1, “friendly_name”: “Utility ceiling”, “current_power_w”: 20.9, “current_energy_kwh”: 8.96}, “entity_id”: “light.utility_ceiling_122”, “last_updated”: “2019-04-07T22:09:08.450368+00:00”}, “entity_id”: “light.utility_ceiling_122”, “old_state”: {“context”: {“id”: “8a92e54df9c24180936a990dafb5bbea”, “user_id”: “823b2d1abc644f9db72cf476aff7d624”, “parent_id”: null}, “state”: “on”, “last_changed”: “2019-04-07T22:09:05.652604+00:00”, “attributes”: {“Vera Device Id”: 122, “supported_features”: 1, “friendly_name”: “Utility ceiling”, “current_power_w”: 0.0, “current_energy_kwh”: 8.96}, “entity_id”: “light.utility_ceiling_122”, “last_updated”: “2019-04-07T22:09:05.652604+00:00”}}}’

I have added the binary_sensor as follows:

binary_sensor:

• platform: mqtt
  state_topic: “hassbian1/topic”
  name: Utility ceiling

Perhaps not surprisingly, nothing is happening when I switch on the Utility ceiling light.
My questions are:

1. How do I identify the correct name of the Utility ceiling to put in the name: part of the binary_sensor.
2. What is the correct name for the state_topic? Presumably “hassbian1/topic” can’t be correct because in the examples given on the HA website, each example has a different topic. For example:

state_topic: "home/bathroom/switch/button"

state_topic: "home-assistant/window/contact"

TIA - apologies for what is probably a really dumb set of questions. If there is a simple guide to this level of knowledge please let me know.

[jazzyisj (Jason)]

Ignore me.

[123 (Taras)]

Use an MQTT client, like MQTT Explorer, to display all of the topics being handled by the broker. It also lets you publish payloads to topics. It’s a useful tool when debugging, or experimenting with, MQTT.

You need to examine the payload being published to hassban1/topic. If it looks like what’s reported in the log, it’s no surprise your binary_sensor is not changing state.

The log shows a complex JSON payload. Your binary_sensor has no value_template so all it is expecting to receive is ON or OFF (see documentation).

[finity]

try this and see what you get:

binary_sensor:
  - platform: mqtt
    state_topic: "hassbian1/topic"
    name: Utility ceiling
    value_template: '{{ value.event_data.new_state.state }}'

that is assuming that the data you get back from the device is the info that you posted above after "b’ " is correctly formatted json.

[jazzyisj (Jason)]

So you can use a binary sensor with MQTT? Nice to know. I’ll delete my nonsense above. Was just a shot in the dark…

[gpbenton (Graham)]

@finity

value_template: ‘{{ value.event_data.new_state.state }}’

I think you meant

value_template: '{{ value_json.event_data.new_state.state }}'

[finity]

of course i did…

thanks for the catch.

[papasierra]

Thank you very much for your advice on this. Unfortunately the value_template didn’t work. However I now have a better understanding of how the topics work. I also came across mqtt_statestream and I am hoping this will provide a solution to being able to see the state of a switch connected to the secondary controller in the primary controller’s list of switches, and to be able to turn it on from the primary controller.
If you don’t think this is possible, please let me know!
By the way, thank you 123 for the suggestion about MQTT Explorer. It has helped me read what the broker is pumping out.

[finity]

@papasierra

Unfortunately the value_template didn’t work.

what didn’t work about it?

[papasierra]

@finity

what didn’t work about it?

I added the following to the config file. Just to complicate things I had to change the z-wave module in the Utility ceiling light so it has changed to “utility_light_306”.
Also using MQTT Explore I could see that the topic was “hassbian1/light/utility_light_306/”.
binary_sensor:
- platform: mqtt
state_topic: “hassbian1/light/utility_light_306/”
name: Utility binary_sensor
value_template: ‘{{ value.event_data.new_state.state }}’

The button does not switch to “on” when the Utility light is turned on. I have also tried the topic “hassbian1/light/utility_light_306/state” because that shows up on MQTT Explore as well.
However, I have also noticed that in all the rebooting, hassbian2 is showing on the States list, lots of hassbian1’s entities. This includes " light.utility_light_306" and when I add this to Lovelace it shows the standard light entity display and whether the light is on or off. Or at least it does for a period of time. I’m not sure why but after a period of time the card showing the lights states it can’t find it. Then when I turn on the Utility light the card is updated and shows the state.
Now that I can see whether the light is on or off, I would like to be able to control it from hassbian2. The light is not currently controllable using the entity state showing on the card. Is there a way of controlling an entity in hassbian1 (the Utility light) from hassbian2?
Thank you for your help.

[finity]

can you post a screen shot of the mqtt explorer including the topic and payload when you switch on the light from hassbian1?

yes you can control all entities from both locations.

to do that you will need to create a light or switch in hassbian2 that publishes the correct payload to the light topic. tho im not sure why you can’t already control the light if it’s working correctly in hassbian1 and also shows up as a light in hassbian2.

maybe seeing the topics/payloads for operating the light/switch from both instances might be able to sort it out.

[papasierra]

Unfortunately I am continuing to feel completely lost with MQTT and being able to control a switch on my secondary Home Assistant controller.
To summarise:
Hassbian is a Raspberry Pi 3 running HA on Hassbian and is called hassbian1. This runs the automation in my house. It has a Vera Plus connected to it and the Vera Plus runs the Z wave set up with about 50 Z wave lights and switches.
Hassbian2 is a Raspberry Pi 3 running HA on Hassbian and is called hassbian2. This has an Aeotec Z wave USB stick and runs some Z wave switches in a shed too far away from the house to connect to the Vera Plus.
Both hassbians are running on the same network.
I would like to control the Z wave switches in the shed from hassbian1 (so that I can control remotely using the Cloud subscription to hassbian1).
The two switches are:
switch.fibaro_system_fgs213_switch_switch_2 (friendly_name: Pool pump)
switch.fibaro_system_fgs213_switch_switch_4 (friendly_name: In-pool light)

In hassbian1 I have the MQTT integration set up with the MQTT running on hassbian1. In configuration.yaml I have:

mqtt_eventstream:
  publish_topic: hassbian1
  subscribe_topic: slaves/#

In hassbian2 I have the MQTT integration set up with the MQTT running on hassbian1. In configuration.yaml I have:

mqtt_eventstream:
  publish_topic: slaves/hassbian2
  subscribe_topic: hassbian1

Using the logger in HA with the following setting:

logger:
  default: error
  logs:
    homeassistant.components.mqtt: debug

The log shows lines and lines of mqtt stuff so both hassbian1 and hassbian2 are successfully publishing.

In hassbian1 I can see the hassbian2 switches. For example in hassbian1 States:

And using this I can include this switch in an entity card:

And this correctly shows when the In-pool light is on or off (when I am toggling the switch in hassbian2).
But toggling the switch in hassbian1 does not control the In-pool light.

As you can see from previous correspondence in this trail I have tried setting up a binary_sensor, mqtt_statestream (sorry to confuse things, but the example used higher up this trail I was experimenting using a light in hassbian1 called Utility light and trying to control it from hassbian2. I am now using switches in hassbian2 and trying to control them from hassbian1).

@finity has been kindly giving advice. He suggested I create a light or switch.
I have tried putting this into hassbian1 configuration.yaml:

switch:
  - platform: mqtt
    state_topic: "slaves/hassbian2/switch.fibaro_system_fgs213_switch_switch_4"
    command_topic: "slaves/hassbian2/switch.fibaro_system_fgs213_switch_switch_4/service"
    name: "Pool light"
    payload_on: "turn_on"
    payload_off: "turn_off"

This shows up in hassbian1 States:

I didn’t know what to put in as the state_topic or command_topic, so not surprisingly it neither shows the correct state of the pool light nor does it control it.

@finity asked me to show what MQTT Explorer showed when I toggled the switch. Unfortunately the lines scroll so fast I can’t copy the first message that is published (is there a way of slowing this down, or a way to recall messages that have been published in the past?).
However in the HA log I can see the following in hassbian2 when I turn the In-pool light (switch.fibaro_system_fgs213_switch_switch_4) switch on:

2019-04-21 22:55:46 DEBUG (MainThread) [homeassistant.components.mqtt] Transmitting message on slaves/hassbian2: {"event_type": "call_service", "event_data": {"domain": "switch", "service": "turn_on", "service_data": {"entity_id": "switch.fibaro_system_fgs213_switch_switch_4"}}}

And in hassbian1 I can see:

2019-04-21 22:55:46 DEBUG (MainThread) [homeassistant.components.mqtt] Received message on slaves/hassbian2: b'{"event_type": "call_service", "event_data": {"domain": "switch", "service": "turn_on", "service_data": {"entity_id": "switch.fibaro_system_fgs213_switch_switch_4"}}}'

I have spent hours trying to get this to work with no success so any help is very much appreciated.
TIA

[finity]

I don’t understand how you are seeing the switches from hassbian2 on your hassbian1 system since they aren’t linked.

but…

I’ve never used mqtt_eventsteam so i’ve now set it up on my main and test servers to see how it works. as soon as i figure out what’s what with it i’ll come back and see if i can help you work things out.

I will let you know that the first thing you’re going to need to help get this working is an MQTT sniffer. there are two good ones I use on my windows pc - MQTTFx and MQTT Explorer. I recommend that you install both as they both have their strengths and weaknesses.

[123 (Taras)]

Why did you choose mqtt_eventstream instead of mqtt_statestream?

[finity]

@123 that’s a good question…

I just tried out both and I think mqtt_statestream would likely be the better option since there’s going to be way less templating involved in extracting the states and publishing commands.

[papasierra]

Thank you @finity for looking into this I appreciate your help.

@123 I did try mqtt_statestream but it only seemed to show whether an entity was on or off and didn’t appear to help with actually turning the hassbian2 Fibaro switch on or off using hassbian1.

But I am happy try again if this is a more effective way of both showing the state and being able to switch the Fibaro on and off.

Just in case you haven’t realised, I am very much an amateur with this, and have no programming experience!

[papasierra]

I have added to the MQTT configuration in hassbian1 with:

mqtt_statestream:
  base_topic: slaves/hassbian2
  publish_attributes: true
  publish_timestamps: true
  include:
    entities:
      - switch.fibaro_system_fgs213_switch_switch_2
      - switch.fibaro_system_fgs213_switch_switch_4

[papasierra]

Should I remove or leave the following from hassbian1:

mqtt_eventstream:
  publish_topic: hassbian1
  subscribe_topic: slaves/#

I also had the following in hassbian1. It was just a guess on what might work regarding the state and command topics. It didn’t work.

switch:
  - platform: mqtt
    state_topic: "slaves/hassbian2/switch.fibaro_system_fgs213_switch_switch_4"
    command_topic: "slaves/hassbian2/switch.fibaro_system_fgs213_switch_switch_4/service"
    name: "Pool light"
    payload_on: "turn_on"
    payload_off: "turn_off"

[RobDYI]

Did you see this?

Automating the sharing of sensors and switches between HA's using MQTT Discovery and Statestream

I use several HA’s on the same network and want to share the sensor / switch state between HA’s. I use MQTT statestream to stream the states of its sensors / switches to its MQTT broker. I put this automation below to allow other HA’s to use MQTT discovery which automatically create’s all the sensors for it’s use. It will populate all the sensors / switches config data on restart (and on every state change). automation mqtt_discovery_config_post: alias: mqtt_discovery_config_post trigger…

[papasierra]

Hi @RobDYI, I’ve taken a quick look at your link and the programming you have shown looks very complicated, but if it works on my system that would be awesome. It’s 10 mins to midnight where I am so I will try to add it to my HA tomorrow.
Thanks again for everyone’s contribution. Fantastic support!