The configuration is made by setting fields in ``esp_mqtt_client_config_t`` struct. The configuration struct has the following sub structs to configure different aspects of the client operation.
*:cpp:member:`broker<esp_mqtt_client_config::broker>` - Allow to set address and security verification.
*:cpp:member:`credentials<esp_mqtt_client_config::credentials>` - Client credentials for authentication.
*:cpp:member:`session<esp_mqtt_client_config::session>` - Configuration for MQTT session aspects.
*:cpp:member:`network<esp_mqtt_client_config::network>` - Networking related configuration.
*:cpp:member:`task<esp_mqtt_client_config::task>` - Allow to configure FreeRTOS task.
*:cpp:member:`buffer<esp_mqtt_client_config::buffer>` - Buffer size for input and output.
In the following session the most common aspects are detailed.
Broker
^^^^^^^^^^^
===========
Address
===========
Broker address can be set by usage of ``broker.address`` struct. The configuration can be made by usage of ``uri`` field
or the combination of ``hostname``, ``transport`` and ``port``. Optionally, `path` could be set, this field is useful in
websocket connections.
The ``uri`` field is used in the following format ``scheme://hostname:port/path``.
For MQTT session related configurations ``section`` fields should be used.
=======================
Last Will and Testament
=======================
MQTT allows for a last will and testament (LWT) message to notify other clients when a client ungracefully disconnects. This is configured by the following fields
in the ``esp_mqtt_client_config_t.session.last_will``-struct.
*``topic``: pointer to the LWT message topic
*``msg``: pointer to the LWT message
*``msg_len``: length of the LWT message, required if ``msg`` is not null-terminated
*``qos``: quality of service for the LWT message
*``retain``: specifies the retain flag of the LWT message
-:ref:`CONFIG_MQTT_TRANSPORT_SSL`, :ref:`CONFIG_MQTT_TRANSPORT_WEBSOCKET`: Enables specific MQTT transport layer, such as SSL, WEBSOCKET, WEBSOCKET_SECURE
The following events may be posted by the MQTT client:
*``MQTT_EVENT_BEFORE_CONNECT``: The client is initialized and about to start connecting to the broker.
*``MQTT_EVENT_CONNECTED``: The client has successfully established a connection to the broker. The client is now ready to send and receive data.
*``MQTT_EVENT_DISCONNECTED``: The client has aborted the connection due to being unable to read or write data, e.g. because the server is unavailable.
*``MQTT_EVENT_SUBSCRIBED``: The broker has acknowledged the client's subscribe request. The event data will contain the message ID of the subscribe message.
*``MQTT_EVENT_UNSUBSCRIBED``: The broker has acknowledged the client's unsubscribe request. The event data will contain the message ID of the unsubscribe message.
*``MQTT_EVENT_PUBLISHED``: The broker has acknowledged the client's publish message. This will only be posted for Quality of Service level 1 and 2, as level 0 does not use acknowledgements. The event data will contain the message ID of the publish message.
*``MQTT_EVENT_DATA``: The client has received a publish message. The event data contains: message ID, name of the topic it was published to, received data and its length. For data that exceeds the internal buffer multiple `MQTT_EVENT_DATA` will be posted and `current_data_offset` and `total_data_len` from event data updated to keep track of the fragmented message.
*``MQTT_EVENT_ERROR``: The client has encountered an error. `esp_mqtt_error_type_t` from `error_handle` in the event data can be used to further determine the type of the error. The type of error will determine which parts of the `error_handle` struct is filled.