MQTT Sensor default value on startup ot after a periof of time

Hi,
I have created a garage opener using a a PICO-W, that sends its status to HA on a change of state or every 5 minutes.

I display the status in my HA dashboard alongside buttons to open & close the door.
I want to put up a status of unknown if HA hasn’t received a message from the PICO-W either on startup or after a period of more than the 5 minutes when it should send an update.

I have this in configuration,yaml.

mqtt:
sensor:
- name: “PICO-W Door”
state_topic: “picow/shortresponse”

How would I set a ‘unknown’ message, and also how would I change the message if I don’t receive an MQTT message for a period of time. ie the PICOW goes offline?

Thanks
Paul

Send an mqtt last will and testament message from your door opener.

https://www.hivemq.com/blog/mqtt-essentials-part-9-last-will-and-testament/

Set the keeepalive time to longer than 5 minutes.

In home assistant this can be monitored by the availability options, https://www.home-assistant.io/integrations/cover.mqtt/#availability

You should also combine your “buttons” and sensor into a ‘cover’ device.

Tom,

Thanks, I was not aware of mqtt last will and testament, I set that in the library on the PICOW and now I get the unavailable message when I disconnect the PICOW from power or wifi.

Is there a need for keepalive at all?

I also had not seen the ‘cover’ type, I’ll look into that, it looks perfect!

Many thanks
Paul

It will generate an unavailable state if your door opener stays connected to the broker but stops sending messages for some reason.

Ok thanks.

So now I’m playing with the ‘cover’ and have it basically working, but have a few more questions, sorry!

My configuration.yaml config is below.

cover: # turn garage door into a single entity
- name: "Cover Garage Door"
  command_topic: "garage_door/set"
  state_topic: "garage_door/state"
  availability:
    - topic: "garage_door/availability"
  qos: 0
  retain: true
  payload_open: "OPEN"
  payload_close: "CLOSE"
  payload_stop: ""
  state_open: "open"
  state_opening: "opening"
  state_closed: "closed"
  state_closing: "closing"
  payload_available: "online"
  payload_not_available: "offline"
  optimistic: false
  value_template: "{{ value.x }}" 

What do I send on what channel to tell HA it’s available, ie to set the state? I assumed it was to send ‘online’ to the topic under availability, but that seems not to work

Also, I have seen I can show the controller with a mushroom card, but my door opens sideways, si it possible to change the arrows to be open & close or left & right?

Many thanks
Paul

The defaults are listed next to the options (MQTT Cover - Home Assistant)

online / offline

The docs are confusing. The availability payloads are listed in the main options and under the availability option but the examples show both being used together. Try it like this:

I don’t know anything about mushroom cards sorry, but these are the available cover device classes that determine how the icon appears: https://www.home-assistant.io/integrations/cover/#device-class

Tom,

Thanks for all the help, but I’m still struggling to get availability through.

I am publishing ‘online’ to the availability topic on app startup, and see it being sent, but HA still thinks the device is unavailable.
availability_topic: “garage_door/availability”

I also see the offline message being sent on device removal using the last will and testament message, so that’s great.

Any clues, I do find the docs a struggle to interpret!

cheers
Paul

When you publish the availability message are you setting the retained flag?

You need to.

Yes I am, it’s set to 1.

mqttClient.publish(AVAILABILITY_TOPIC,“online”,1)

Does anyone know of an example app for the garage door device, that send the MQTT messages to HA, so I can look and see what it does differently? Might help me identify what I’m doing wrong.
Thanks
Paul

I have noticed something, the state changes to unavailable a while after I unplug it, so the last will and testament must be doing something, but when it’s actually online & communicating it shows unknown.

Here’s the configuration.yaml, shouldn’t the state be offline, not unavailable?

cover: # turn garage door into a single entity
- name: "Cover Garage Door"
  command_topic: "garage_door/set"
  state_topic: "garage_door/state"
  availability_topic: "garage_door/availability"
  qos: 0
  retain: true
  payload_open: "OPEN"
  payload_close: "CLOSE"
  payload_stop: null
  state_open: "open"
  state_opening: "opening"
  state_closed: "closed"
  state_closing: "closing"
  payload_available: "online"
  payload_not_available: "offline"
  optimistic: false
  value_template: "{{ value.x }}"

What happens (for testing) if you remove the availability topic and payloads?

Once I cleared out the state manually, and it doesn’t get set to unknown, but also nothing gets set on power down of the Picow.

So I put the availability topic back after manually clearing the state, and it does go back to Unknown as before. I’m guessing state should show the open or closed message, or offline

Also, can I ask something else. If the last payload from the HA is CLOSE, and I power cycle the PICOW, is it normal for the HA to send another CLOSE request on startup (& visa versa)?

Not sure what you mean by that. Does the state show correctly when you open and close the cover when you have no availability topic?

Nope, nothing at all.

Then it is not receiving the state correctly. Sort that out first, before trying to add availability.

Do the open and close commands work?

Yes, I get the commands, and the relay is triggered.

So just to double check, to garage_door/state I should just publish one of the following, right?
“open”
“opening”
“closed”
“closing”

They are definitely being sent, I can see them in MQTT_Explorer.

Yes, as you are using this config;

It is case sensitive.

Try removing this (it is optional);

 payload_stop: ""

Well then, I’m even more confused, as that’s what I do. Removed payload_stop, no change!

I had better get this work finished & will look tomorrow, Thanks for all your guidance Tom, but it’s starting to drive me nuts!