What is MQTT's Last Will and Testament (LWT)? How to use it?

MQTT's Last Will and Testament (LWT) is an important mechanism for notifying other clients when a client disconnects abnormally.

Concept of Last Will and Testament

Definition

The Last Will is a message pre-configured by the client when connecting. When the client disconnects abnormally, the Broker automatically publishes this message to a specified topic.

Purpose

• Anomaly Detection: Notify other clients that a device has gone offline
• Status Notification: Publish device offline status
• Fault Alerting: Trigger alert mechanisms
• Resource Cleanup: Notify the system to clean up related resources

How Last Will Works

Setting Last Will

The client sets Last Will parameters when sending a CONNECT packet:

shell
CONNECT Packet Parameters:
- Will Flag: true (enable Last Will)
- Will Topic: Topic for Last Will message
- Will Message: Content of Last Will message
- Will QoS: QoS level for Last Will message
- Will Retain: Whether to retain Last Will message

Trigger Conditions

Last Will is triggered in the following situations:

1. Abnormal Client Disconnection

   • Network failure
   • Device power loss
   • Program crash
   • Connection timeout

2. Broker Detects Disconnection

   • Keep Alive timeout
   • TCP connection lost
   • Heartbeat detection failure

Non-Trigger Situations

Last Will is NOT triggered in the following situations:

1. Normal Disconnection

   • Client sends DISCONNECT packet
   • Normal connection closure

2. Connection Not Established

   • CONNECT packet send failure
   • Connection refused

Last Will Parameters

Will Flag

• Purpose: Indicates whether Last Will is enabled
• Value: true/false
• Required: Must be true when enabling Last Will

Will Topic

• Purpose: Specifies the topic for Last Will message
• Format: Standard MQTT topic string
• Example: device/123/status
• Required: Must be set

Will Message

• Purpose: Actual content of Last Will message
• Format: Binary data
• Example: offline or {"status":"offline","timestamp":1234567890}
• Required: Must be set

Will QoS

• Purpose: Specifies QoS level for Last Will message
• Value: 0/1/2
• Default: 0
• Selection Recommendations:
  • QoS 0: General status notification
  • QoS 1: Important status notification
  • QoS 2: Critical status notification

Will Retain

• Purpose: Specifies whether to retain Last Will message
• Value: true/false
• Default: false
• Impact:
  • true: New subscribers receive Last Will message
  • false: Only online subscribers receive Last Will message

Use Cases

1. Device Online Status Monitoring

shell
Device Online:
- Publish "online" to device/123/status

Device Offline (Normal):
- Publish "offline" to device/123/status

Device Offline (Abnormal):
- Last Will message "offline" published to device/123/status

2. Fault Alerting

shell
Last Will Topic: alert/device/123
Last Will Message: {"type":"offline","device":"123","timestamp":1234567890}

Monitoring system subscribes to alert/device/123
Triggers alert upon receiving Last Will message

3. Resource Cleanup

shell
Last Will Topic: cleanup/device/123
Last Will Message: {"device":"123","action":"cleanup"}

Cleanup service subscribes to cleanup/device/123
Cleans up related resources upon receiving Last Will message

4. Load Balancing

shell
Last Will Topic: worker/offline
Last Will Message: {"worker":"worker1"}

Load balancer subscribes to worker/offline
Redistributes tasks upon receiving Last Will message

Code Examples

Python (paho-mqtt)

python
import paho.mqtt.client as mqtt
import json
import time

def on_connect(client, userdata, flags, rc):
    print(f"Connected with result code {rc}")
    client.subscribe("device/+/status")

def on_message(client, userdata, msg):
    print(f"Received: {msg.topic} - {msg.payload.decode()}")

client = mqtt.Client()

# Set Last Will message
will_topic = "device/123/status"
will_message = json.dumps({"status": "offline", "timestamp": int(time.time())})
client.will_set(will_topic, will_message, qos=1, retain=True)

client.on_connect = on_connect
client.on_message = on_message

client.connect("broker.example.com", 1883, 60)

# Publish online status
client.publish("device/123/status", json.dumps({"status": "online"}))

client.loop_forever()

JavaScript (MQTT.js)

javascript
const mqtt = require('mqtt');

const client = mqtt.connect('mqtt://broker.example.com', {
    will: {
        topic: 'device/123/status',
        payload: JSON.stringify({ status: 'offline', timestamp: Date.now() }),
        qos: 1,
        retain: true
    }
});

client.on('connect', () => {
    console.log('Connected');
    
    // Publish online status
    client.publish('device/123/status', JSON.stringify({ status: 'online' }));
    
    // Subscribe to status topic
    client.subscribe('device/+/status');
});

client.on('message', (topic, message) => {
    console.log(`Received: ${topic} - ${message.toString()}`);
});

Best Practices

1. Last Will Message Design

• Clear and Concise: Message content should be concise and easy to parse
• Include Timestamp: Facilitates tracking offline time
• Device Identification: Clearly identify which device
• Status Information: Include detailed offline reasons

2. Topic Naming Conventions

shell
Recommended Format:
- device/{device_id}/status
- alert/{device_id}/offline
- cleanup/{device_id}

Avoid Using:
- Wildcards as Last Will topics
- Overly complex topic structures

3. QoS Selection

• General Devices: QoS 0
• Important Devices: QoS 1
• Critical Devices: QoS 2

4. Retain Setting

• Status Monitoring: Recommended to set to true
• Alert Notifications: Recommended to set to false
• Resource Cleanup: Set based on requirements

5. Last Will Message Handling

• Timely Processing: Process Last Will messages promptly upon receipt
• Avoid Duplication: Prevent duplicate processing of offline events for the same device
• Log Recording: Record offline events for troubleshooting

Considerations

1. Normal Disconnection: When disconnecting normally, send DISCONNECT packet first to avoid triggering Last Will

2. Last Will Update: Last Will message content can be updated when reconnecting

3. Broker Limitations: Some Brokers may have size limitations for Last Will messages

4. Network Latency: Network latency may cause delayed sending of Last Will messages

5. Multi-Device Scenarios: In multi-device scenarios, clearly distinguish Last Will messages from different devices

Limitations of Last Will

1. Cannot Identify Offline Reason: Last Will message does not include specific offline reasons
2. Possible False Positives: Network jitter may cause false alarms
3. Processing Delay: There may be delay from offline to sending Last Will message
4. Depends on Broker: Completely relies on Broker reliability

MQTT Last Will is a very important mechanism in IoT applications. Proper use can effectively monitor device status and improve system reliability and maintainability.