The client supports version 3.1 and 3.1.1 of the [MQTT](https://en.wikipedia.org/wiki/MQTT) protocol. Make sure that the correct version is set with `make menuconfig` -> "Component config" -> "ESP-MQTT Configurations" -> "Enable MQTT protocol 3.1.1".
In reality, the connected function should do something useful!
This is the description of how the `autoreconnect` functionality may (or may not) work.
> When `autoreconnect` is set, then the connection will be re-established when it breaks. No error indication will be given (but all the
> subscriptions may be lost if `cleansession` is true). However, if the
> very first connection fails, then no reconnect attempt is made, and the error is signalled through the callback (if any). The first connection
> is considered a success if the client connects to a server and gets back a good response packet in response to its MQTT connection request.
> This implies (for example) that the username and password are correct.
## mqtt.client:lwt()
Setup [Last Will and Testament](http://www.hivemq.com/blog/mqtt-essentials-part-9-last-will-and-testament) (optional). A broker will publish a message with qos = 0, retain = 0, data = "offline" to topic "/lwt" if client does not send keepalive packet.
As the last will is sent to the broker when connecting, `lwt()` must be called BEFORE calling `connect()`.
The broker will publish a client's last will message once he NOTICES that the connection to the client is broken. The broker will notice this when:
- The client fails to send a keepalive packet for as long as specified in `mqtt.Client()`
- The tcp-connection is properly closed (without closing the mqtt-connection before)
- The broker tries to send data to the client and fails to do so, because the tcp-connection is not longer open.
This means if you specified 120 as keepalive timer, just turn off the client device and the broker does not send any data to the client, the last will message will be published 120s after turning off the device.
#### Syntax
`mqtt:lwt(topic, message[, qos[, retain]])`
#### Parameters
-`topic` the topic to publish to (string)
-`message` the message to publish, (buffer or string)
-`function(client[, topic[, message]])` callback function. The first parameter is the client. If event is "message", the 2nd and 3rd param are received topic and message (strings).
-`function(client)` optional callback fired when PUBACK received. NOTE: When calling publish() more than once, the last callback function defined will be called for ALL publish commands.
#### Returns
`true` on success, `false` otherwise
## mqtt.client:subscribe()
Subscribes to one or several topics.
#### Syntax
`mqtt:subscribe(topic, qos[, function(client)])`
#### Parameters
-`topic` a [topic string](http://www.hivemq.com/blog/mqtt-essentials-part-5-mqtt-topics-best-practices)
-`qos` QoS subscription level, default 0
-`function(client)` optional callback fired when subscription(s) succeeded. NOTE: When calling subscribe() more than once, the last callback function defined will be called for ALL subscribe commands.
Rather than calling `subscribe` multiple times in a row, you should call the next `subscribe` from within the callback of the previous. A generic example is provided in [mqtt_helpers.lua](../../lua_examples/mqtt/mqtt_helpers.lua).
-`topic` a [topic string](http://www.hivemq.com/blog/mqtt-essentials-part-5-mqtt-topics-best-practices)
-`function(client)` optional callback fired when unsubscription(s) succeeded. NOTE: When calling unsubscribe() more than once, the last callback function defined will be called for ALL unsubscribe commands.
Rather than calling `unsubscribe` multiple times in a row, you should call the next `unsubscribe` from within the callback of the previous. A generic example is provided in [mqtt_helpers.lua](../../lua_examples/mqtt/mqtt_helpers.lua).
