MQTT sensor with availability topic - how to update?

Configuration
1

Hi Everyone,

I have a mqtt binary sensor as follows:

#Virgil-Remote Garage Side Door MQTT Sensor
 - platform: mqtt
   name: "Remote Garage Side Door"
   state_topic: "/remote/garagesidedoor"
   payload_on: "ON"
   payload_off: "OFF"
   availability_topic: "/remote/garagesidedoor/availability"
   payload_available: "online"
   payload_not_available: "offline"
   qos: 0
   device_class: door

I am trying to update the sensor as follows:
image

However, this does not update the sensor at all.

image

If I remove the following lines, the sensor updates properly.

   availability_topic: "/remote/garagesidedoor/availability"
   payload_available: "online"
   payload_not_available: "offline"

What mqtt.publish data do I need to send to update if i have the payload_available information?

2

First you need to send :

payload: "online"
retain: true
topic: /remote/garagesidedoor/availability

Then you can send

image

3

@francisp, thank you very much!!! this worked. I started looking into mqtt eventstream but for 3 sensors. it is overkill. I will use automtion to keep these updated between my master and slave instance…that was the main reason for doing this.

4

If your device isn’t programmed to send a “last will & testament” (availability topic) then how does it help you to force the availability to always be “online”? what happens if your device actually goes offline? How will you know if it’s actually online or offline if you have forced it online?

5

Very good point @finity…however, I am at a loss on how to implement this properly. Here is my scenario. I have a hass.io vm on my server that is my primary. It has a wyze hub (usb) and a bunch of sensors connect to it. I really like the wyze products. Now my garage is out of range for this hub. So I bought a second wyze hub and connected it to a raspberry pi hass.io instance that sits close to the garage for the further away sensors. This is my second or slave instance of hass.io. I have tried a few things so far but with very limited reliability. I tried the HACS Remote which keeps losing connectivity to the Slave instance. I have also tried connecting node red with a Slave instance as a second server but that also didn’t get the state change reliably. Hence I am now experimenting with the MQTT publish approach.

So in my current setup I have setup automations that sends the availability and state on every state change.

image
image657Ă—555 30.3 KB

  alias: Side Door (Garage) - Open
  description: ''
  trigger:
  - entity_id: binary_sensor.wyze_garage_side_door
    from: 'off'
    platform: state
    to: 'on'
  condition: []
  action:
  - data:
      payload: online
      retain: true
      topic: /remote/garagesidedoor/availability
    service: mqtt.publish
  - data:
      payload: 'ON'
      retain: true
      topic: /remote/garagesidedoor
    service: mqtt.publish

And in my Primary instance I have the corresponding MQTT Binary Sensors that are updated based on these automation in the Slave.

Now I did venture a bit in the MQTT Eventstream but couldn’t figure out how to connect the MQTT subscribed topic to the MQTT Binary Sensors I created in the Primary instance. If this is the right approach, would you be able to help me set it up?..I am constantly learning when I try to solve something with HA.

6

I tried to use mqtt_eventstream once a while back and found it too complicated for my use.

I ended up using mqtt_statestream since it seemed to be more “entity specific”.

But I’m not sure how it handles the availability topic of the statestream publishing device or if it does at all.

7

Everything you have tried has failed for the same reason: poor network connectivity. MQTT will suffer the same fate. Use of the availability topic isn’t going to improve anything (especially not the way you’re using it).

Fix your network.

8

I will look into the network issue. but all of these are connected via LAN. I have a wired hub in between. Also I have the pi restart every 6 hours.

9

@finity, in the Statestream approach, do you still have to do the automation part to publish the state change or does it do that automatically?

10

Statestream publishes the state information for each entity as the changes happen. you can also set it to update the attributes as well. It will publish all of that info to the broker to be available for other clients to consume. You can set up statestream to publish thew states of all entities or just a select few.

then in your main HA you will need to configure an MQTT binary sensor to react to changes in the MQTT message from the original sensor.

11

would you kindly post the code for the Main HA binary sensor code for an example? That is where I got stuck last time.

12

I’m going to assume you followed the docs to get statestream running on your “slave” HA config?

here is my config (I only have one entity shared since I only used it for testing):

mqtt_statestream:
  base_topic: hass
  publish_attributes: true
  publish_timestamps: true
  include:
    entities:
      - switch.comp_room_light_sw

So in my case I used “hass” as the base topic. then the details of my switch are published to the topic “hass/switch/comp_room_light_sw/…” including all of the entity’s attributes.

In your case (if using the same base topic) the binary sensor would publish it’s state on the topic “hass/binary_sensor/your_device_id/state”

Then you would create an mqtt binary sensor in your “master” HA that listens for changes on that topic.:

binary_sensor:
  - platform: mqtt
    state_topic: "hass/binary_sensor/your_device_id/state"
    payload_on: "on"
    payload_off: 'off"
1 Like