MQTT Cover and/or binary sensor don't check actual state on HA startup

Configuration
1

My garage door uses a Sonoff SV that I have set up as an MQTT cover in HA. I’ve hooked up a reed switch to a separate GPIO on the board, and have it configured as the open/closed sensor.

It works pretty well, no issues opening and closing the door or sensing its position. However, whenever I restart HA, it always reports the cover as having a state of ‘unknown’. I tried hooking up a binary_sensor with the same MQTT options, and on restart it always shows as ‘closed’ whether or not it is actually closed. Is this a configuration detail that I’ve missed or is this a bug? I’m using the builtin MQTT broker and Tasmota 5.12 on the sonoff.

Here’s my YAML:

cover:
  - platform: mqtt
    name: garagedoor
    command_topic: "cmnd/GarageDoor/POWER"
    payload_open: "ON"
    payload_close: "ON"
    payload_stop: "ON"
    state_topic: "cmnd/GarageDoor/POWER2"
    state_open: "ON"
    state_closed: "OFF"
    optimistic: false
    retain: false

binary_sensor:
  - platform: mqtt
    name: garagedoor_state
    device_class: garage_door
    state_topic: "cmnd/GarageDoor/POWER2"
    payload_on: "ON"
    payload_off: "OFF"

I know it looks weird to have “ON” as the payload for both open and close, but it’s a dumb garage door opener, and I just have to close the circuit to have it toggle. The sonoff itself is configured to turn the relay off again after 1 second. But again, the real problem is the opened/closed sensor, not the open/close commands.

2

HA is just reading the state, if the MQTT server does not have a value yet, then it wont work.

If you are using the internal HA mqtt server, you are loosing the MQTT states on restart. I moved to mosquitto server and turned on persistence (the values are stored on service stop, and restored after) for this reason.

3

Ok. I guess I’ll try out mosquito. Thanks!

4

Ok. I have everything working with mosquitto, but unfortunately, I’m seeing exactly the same behaviour as before: i.e., I restart HA (but not mosquitto) and my garage door shows as ‘unknown’ regardless of the actual state. Below is my mosquitto.conf. Is there anything different about yours?

# Place your local configuration in /etc/mosquitto/conf.d/
#
# A full description of the configuration file is at
# /usr/share/doc/mosquitto/examples/mosquitto.conf.example

pid_file /var/run/mosquitto.pid

password_file /etc/mosquitto/passwd
allow_anonymous false

persistence true
persistence_location /var/lib/mosquitto/

log_dest file /var/log/mosquitto/mosquitto.log

include_dir /etc/mosquitto/conf.d
5

Just to confirm you’ve pointed HA to the mosquitto server?

e.g.

mqtt:
  broker: 192.168....
  port: 1883
  username: !secret mqtt_username
  password: !secret mqtt_password
  client_id: home-assistant-1
  keepalive: 60
  protocol: 3.1

To account for restarts of the server, you’ll also likely want to use the following to start HA after mosquitto.

If you are using systemctl to start/stop, /etc/systemd/system/homeassistant.service

[Unit]
Description=Home Assistant
After=network-online.target mosquitto.service

This is my mosquitto.conf, looks pretty much the same except for the secure port being enabled,

listener 1883 192.168.10.7

listener 8883
tls_version tlsv1.2
cafile /etc/mosquitto/ca_certificates//ca.crt
certfile /etc/mosquitto/certs//raspberrypi.crt
keyfile /etc/mosquitto/certs//raspberrypi.key
require_certificate true

persistence true
persistence_location /var/lib/mosquitto/
persistence_file mosquitto.db

log_dest syslog
log_dest stdout
log_dest file /var/log/mosquitto/mosquitto.log
log_type error
log_type warning
log_type notice
log_type information
log_type subscribe
log_type unsubscribe

connection_messages true
log_timestamp true
allow_anonymous false
autosave_interval 1800
password_file /etc/mosquitto/pwfile
user mosquitto
6

It’s for sure using the correct mqtt broker. I can see connections coming in on my mosquitto log file. MOsquitto is running on the same port (1883) on the same machine as HA, so they’d conflict if they were both running.

When I run

mosquitto_sub -h localhost -p 1883 -t cmnd/GarageDoor/POWER

I don’t get a response of “ON” or “OFF” like I do for all my MQTT light switches. I now think this might be an configuration issue with this instance of TASMOTA, but I don’t know what :frowning:

7

Do you see the subscription updates when you toggle that device?

8

Yes. I see updates when the relay is toggled. But I don’t seem to be able to query for the current state via MQTT. I can see it accurately on the TASMOTA web page for the device.

9

From what is now coming back to me, when publishing a message to MQTT, you need to set the ‘retained message flag’ which will follow the expected behaviour.

If this is not set, you wont get a subscription update until a new message is published.

http://www.steves-internet-guide.com/mqtt-retained-messages-example/

This device obviously doesnt do that.

10

It might be cold comfort but my Garage Door’s config is effectively identical to yours but I don’t get ‘Unknown’ after a restart.

I suspect the difference is that the device I use that actually operates the garage door publishes the state topic with retain=true. Effectively, it’s telling the MQTT broker (mosquitto) to store the topic’s value and report it to any subscriber that connects to it later. “Later” as when Home Assistant reboots and re-subscribes to all MQTT topics, such as the garage door’s state. If that topic’s value is not retained by the MQTT broker, Home Assistant receives no value from the broker and reports it’s unknown. It’ll become known the next time the garage door changes state.

Effectively, “retain” is a form of persistence on the MQTT broker. Without it, the only subscribers who know what’s changing are the ones connected at the time of the change. Subscribers who arrive later, get no “meeting notes” and don’t know the current state of any topic.

11

This might be my problem. I had to disable the ‘retain’ setting because my garage door opener is far enough away from my router that it occasionally disconnects. Because opening or closing the door is the same MQTT command, whenever TASMOTA reconnected, it would toggle the door opening. I’m sure you can appreciate that this is a non-starter.

I only really need it to retain the setting for the sensor, not the setting of the relay. Is there any way I can configure it to do that? Otherwise, I guess I might have to live with this issue.

12

Depends on how much of a kludge you want. You could write a bash listener, and republish the message straight after with the retain set.

device -> mqtt “cmnd/GarageDoor/POWER_temp” -> bash listener
bash publisher -> mqtt “cmnd/GarageDoor/POWER” -retain

If you are just wanting to keep the sensor state, what about storing it as a boolean or input_select?

Use MQTT to update this instead?

13

Storing as an input_boolean is a possibility. I’ll have to look into that.

I’m envisioning an automation to set the state of the input_boolean based on the states of the garage door that are actually reported. Then the state of the input_boolean will get persisted across restarts.

The part I’m not sure about is how to make the state of the garage door in HA accurately reflect the value of the input_boolean on HA startup without actually triggering the door to open or close.

14

You mean if the door state changes whilst HA is not running it could get out of sync?

Edit or now thinking about it, you mean when you detect it’s open, you now toggle the input_boolean. The input_boolean then treats the to “on” change as an indication of the switch being toggled, therefore it sends a command to open the door. And then it loops because that would close the door.

Mmmm could be interesting.

15

No, I mean that the cover’s state will be ‘unknown’ when HA restarts. I’ll want to set it to the appropriate ‘closed’ or ‘open’ based on the value of the input_boolean. I don’t want to call one of the cover services because that would actually open or close the door. I just want to set the state like you can in the ‘States’ developer tool in the UI.

16

Ideally, yes. A command topic is only relevant at the moment it’s issued. There’s no need to retain it for use by other subscribers at a later time (unless there’s a special use-case and a garage-door opener ain’t it).

In contrast, a state topic is often relevant to future subscribers (like Home Assistant after a reboot) and so should be retained. Having said that, there are exceptions but, in my experience, I haven’t run into them.

Which part of your system is publishing this state topic:

cmnd/GarageDoor/POWER2

Because that’s the only one that should be using retain=true. Unless I’ve misunderstood your system, I believe it’s the Sonoff switch. Home Assistant publishes the command topic and so the cover’s retain flag should be false.

If your mosquitto broker is currently retaining the value for the command topic (cmnd/GarageDoor/POWER2) you should purge it. To purge a retained topic value you must publish an empty string to it.

17

For reference, this is how I configured the Sonoff with Tasmota to control my garage door:

You’re right on all counts. I just don’t know how to make the switch state get retained when the relay state isn’t. Can I do this via configuration in Tasmota? I had to remove the “retain: true” line in the HA cover config because that was giving me issues previously. I’m not sure what that line does behind the scenes. Those problems were all when I was using the embedded MQTT broker, however.

18

I have no hands-on experience with replacement firmware, like Tasmota, ESPurna, ESPeasy, etc, only ‘book learning’ so take what I say next with a grain of salt.

I scanned the list of MQTT-specific Tasmota commands and it appears to provide fine-grained control of what it does and does not publish with the retain flag.

Specifically, there’s ButtonRetain, PowerRetain, and SensorRetain. I’m going to take a wild guess and say SensorRetain might represent the garage-door sensor you hooked up. That would be the parameter I’d set retain=true and the other two to retain=false (but I could be wrong).

Again, before tweaking anything, be sure to purge the darn command topic so the broker is no longer holding on to a value. Otherwise, this “pre-condition” might goof up all your experiments to make this work the way you want.

19

I’ve fixed my problem by adding a small program that hits the web API to retrieve the existing state information for my garage door object and then changes the state to the appropriate value based on the input_boolean that is storing the current state of the garage door. I then set up an automation that runs 15 seconds after HA boots to run this shell_command.

Seems like a lot of running around to get a simple task accomplished, but now it’s done :slight_smile:

20

Could show us your code