Explain better how dependencies work with mqtt example

docs/creating_integration_manifest.md

@@ -92,7 +92,7 @@ If this integration is being submitted for inclusion in Home Assistant, it shoul
 
 ## Dependencies
 
-Dependencies are other Home Assistant integrations that you want Home Assistant to set up successfully prior to the integration being loaded. This can be necessary in case you want to offer functionality from that other integration, like using webhooks or an MQTT connection.
+Dependencies are other Home Assistant integrations that you want Home Assistant to set up successfully prior to the integration being loaded. This can be necessary in case you want to offer functionality from that other integration, like using webhooks or a MQTT connection. Adding an integration to dependencies will ensure the depending integration is loaded before setup, but it does not guarantee all configuration entries have been set up. See the [MQTT section](#mqtt) for more details on handling this for MQTT.
 
 Built-in integrations shall only specify other built-in integrations in `dependencies`. Custom integrations may specify both built-in and custom integrations in `dependencies`.
 
@@ -294,6 +294,9 @@ MQTT discovery works by subscribing to MQTT topics specified in the manifest.jso
 }
 ```
 
+If your integration requires `mqtt`, make sure it is added to the [dependencies](#dependencies).
+The MQTT integration for example does not implement `async_setup` and the config entry is set up via `async_setup_entry`. This also applies for integrations that depend on MQTT and that have implemented a platform setup only via `async_setup_platform`. Depending integrations should wait using `await mqtt.async_wait_for_mqtt_client(hass)` for the MQTT client to become available before they can subscribe. The `async_wait_for_mqtt_client` method will block and return `True` till the MQTT client is available. If a dependency is optional but not critical, then adding an [after dependency](#after-dependencies) might be a better alternative.
+
 ## DHCP
 
 If your integration supports discovery via dhcp, you can add the type to your manifest. If the user has the `dhcp` integration loaded, it will load the `dhcp` step of your integration's config flow when it is discovered. We support passively listening for DHCP discovery by the `hostname` and [OUI](https://en.wikipedia.org/wiki/Organizationally_unique_identifier), or matching device registry mac address when `registered_devices` is set to `true`. The manifest value is a list of matcher dictionaries, your integration is discovered if all items of any of the specified matchers are found in the DHCP data. It's up to your config flow to filter out duplicates.