Boot sequence hangs until MQTT client component connects

[Alphaemef]

The problem

If MQTT client is configured but can not connect to the server, components that load with a boot priority lower than the MQTT Component do not start up.

I.e: If both API and MQTT are connected, and MQTT disconnects API continues to work until the reboot teimout. At which point the ESP will startup without API. Once the MQTT connects, the API will connect.

If API setup_priority is changed to 201, this alleviates the issue. Other components with lower priority do not load either, i.e modbus

Which version of ESPHome has the issue?

2024.8.3

What type of installation are you using?

Home Assistant Add-on

Which version of Home Assistant has the issue?

No response

What platform are you using?

ESP32-IDF

Board

esp32

Component causing the issue

MQTT Client Component

Example YAML snippet

mqtt:
  broker: ${broker}
  port: ${port}
  username: ${name}
  password: ${pass}
  discovery_unique_id_generator: mac
  id: mqtt_client
  skip_cert_cn_check: false
  idf_send_async: false
  certificate_authority:  | 
    -----BEGIN CERTIFICATE-----
    -----END CERTIFICATE-----

esphome:
  name: ${name}
  friendly_name: ${name}
  on_boot: 
    - priority: 600
      then:
        - output.turn_on: ${pin1}
    - priority: -100
      then:
        - lambda: |-
              id(fw_version).publish_state("${flashfile}_${version}");
        # - lambda: |-
        #       ESP_LOGD("mqtt_subscribe", "The value of the global variable at boot is: %s", id(next_sub_charge_value).c_str());
        - lambda: |-
              id(next_sub_charge).publish_state(id(next_value).c_str());
    - priority: -500
      then:
        - if:
            condition: 
              number.in_range:
                id: boot_script_counter
                below: 3
            then: 
              - script.execute: boot_settings
              - number.increment:
                  id: boot_script_counter
              - logger.log: "boot script initiated"
            else:
              - logger.log:
                  format: "The boot script counter was %.1f, and boot script was NOT initiated"
                  args: [ 'id(boot_script_counter).state' ]
        - if:
            condition:
              not:
                mqtt.connected:
            then:
                - lambda: |-
                          id(reboots_mqtt_disc) += 1;
                          ESP_LOGD("reboots", "Reboots due to MQTT disconnection: %d", id(reboots_mqtt_disc));
                - if: 
                    condition: 
                      lambda: "return id(reboots_mqtt_disc) == 4;"
                    then: 
                        - script.execute: default_settings

Anything in the logs that might be useful for us?

No response

Additional information

No response

[victorclaessen]

I figured out later that my problem in #4875 partly had the same cause. (MQTT could not connect because I had a wrong configuration of the wireguard component. Therefore the API port also did not open.)

One would really hope that these things would become independent.

[Alphaemef]

I figured out later that my problem in #4875 partly had the same cause. (MQTT could not connect because I had a wrong configuration of the wireguard component. Therefore the API port also did not open.)

One would really hope that these things would become independent.

yes, it shouldn't wait for "ok" from MQTT before proceeding with loading components with a lower priority.

[victorclaessen]

I think your suggestion to increase the priority makes sense. If this line is changed to float MQTTClientComponent::get_setup_priority() const { return setup_priority::AFTER_WIFI + 1; } ---- then the problem is likely to be solved.

[ssieb]

How would that help? That would only make things worse if anything.

[victorclaessen]

Could you explain why? Our assumption is that this would make the mqtt component start after the api component. Is that not correct?

[victorclaessen]

Ah, right, it should be - 1. Good catch.

[Alphaemef]

Ah, right, it should be - 1. Good catch.

While you are right, this doesn't actually solve the issue. Say some other component is loaded at priority -10, if MQTT doesn't connect immediately anything downstream does not work, which makes no sense since API for instance could be running, og if its an operation that doesn't even need MQTT / API.

[victorclaessen]

You're right; but it would at least allow the API to start (I suppose), so you could interact with the device remotely?