Mqtt entity availability option for new mqtt format

Configuration
1

While rewriting mqtt based entities from old to new format I found after reloading entities that all of them with the availability option configured are unavailable. Obviously, if I comment out availability, those became available.

Found that it doesn’t matter I use old or new availability format.
Not sure if HA restart may turn them available. But from experience collected so far multiple reloading of mqtt entities doesn’t help.

Is it a known issue? By quick glance I didn’t find anything related open in Github.
I have Home Assistant Core 2022.6.7

Example of the code (note, those are snippets come from packages so lacks top-level attributes those are members of)

      - name: "Hall Floor 0"
        command_topic: "shellies/shelly1-hall0/relay/0/command"
        state_topic: "shellies/shelly1-hall0/relay/0"
        availability_topic: "shellies/shelly1-hall0/online"
        payload_available: "true"
        payload_not_available: "false"
        qos: 1
        retain: false
        payload_on: "on"
        payload_off: "off"
        optimistic: false

or

      - name: 'Kitchen Worktop Right'
        schema: template
        command_topic: 'shellies/light-kitchen-worktop-r/color/0/set'
        state_topic: 'shellies/light-kitchen-worktop-r/color/0/status'
        availability:
          topic: 'shellies/light-kitchen-worktop-r/online'
          payload_available: "true"
          payload_not_available: "false"
        retain: false
        qos: 1
        command_on_template: >
          {'turn': 'on'
            {%- if brightness is defined -%}
            , 'gain': {{ brightness | float | multiply(0.3922) | round(0) }}
            {%- endif -%}
            {%- if color_temp is defined -%}
            , 'red': {{ ( (color_temp | float ) - 153 ) | multiply(0.734870317) | round(0) }}
            , 'green': {{ ( 500 - (color_temp | float ) ) | multiply(0.734870317) | round(0) }}
            , 'blue': 0
            {%- endif -%}
          }
        command_off_template: '{"turn":"off"}'
        state_template: '{% if value_json.ison %}on{% else %}off{% endif %}'
        brightness_template: '{{ value_json.gain | float | multiply(2.55) | round(0) }}'
        color_temp_template: '{{ ( ( value_json.red | float | multiply(1.36078431373) ) + 153 ) | round(0) }}'
2

It seems that only mqtt light is affected.
At least sensors behaves correctly.

3

I can confirm the thing is broken.

I did a comparison between entities declared in a different way (old way, new way, with and without availability).
Ones without an availability option set, obviously work immediately after entities reload or HA restart.
After system restart both, old and new ones with availability option, recover after some additional time (a minute or so after HA reports restart is finished)

However, reloading manually configured entities, causes entities declared with the new format (in domain mqtt) never recover. Even a change of tracked mqtt topic doesn’t change their state.

reported to github: Availability option breaks light entity (new format) · Issue #74019 · home-assistant/core · GitHub

4

According to Make Your Own Smart Garage Door Opener for $15 - HomeTechHacker
It seems the Shelly relays don’t always send or retain the message that indicates to Home Assistant that they are available. Thus, when Home Assistant restarts, it doesn’t always mark the cover (garage door control) as available. To fix this we force the Shelly relays to announce themselves using the automation below:

(I have this code in automations.yaml and availability works for me.)

- id: mqtt_shelly_announce
  alias: Shelly Sync at HA Start
  trigger:
  - platform: homeassistant
    event: start
  action:
  - delay: 00:00:20
  - service: mqtt.publish
    data:
      topic: shellies/command
      payload: announce
5

I do that. in addition I execute this automation on mqtt entities reload

trigger:
  - platform: event
    event_type: event_mqtt_reloaded
6

Based on your github code post, it does not appear you have a delay. You may need to give the Shellys a little time after those events.

7

maybe.
But the point of my report is, that old format doesn’t cause the problem. it has been introduced with new format.

Regarding the delay, the event is published after the reloading is completed. So what further delay should be good for?

8

The MQTT component owner instantly found and fixed the issue. The fix will be likely merged to 2022.7

Indeed it is related to event_mqtt_reloaded event which is kicked before the new MQTT integration has finished.
Until the fix release release, the workaround is to add delay to the automation mentioned in my previous posts