MQTT Last Will in the Industrial Unified Namespace (UNS)

Stable and reliable communication is crucial for the secure transmission of data in an Industrial Unified Namspace(UNS). But what happens if a device unexpectedly loses the connection? This is where MQTT Last Will comes into play. The following article describes how this digital “farewell letter” works in the context of the Unified Namespace (UNS).

What is MQTT Last Will?

Within the MQTT protocol, an MQTT Last Will acts as a kind of safety net in the event that a client unintentionally loses the connection to the broker (disconnect). This is a special message that the client sends to the broker when the connection is established. You can find more information about MQTT Connection Settings here. If the client loses the connection unexpectedly, the broker assumes responsibility. The broker publishes the Last Will message on behalf of the client. In MQTT, unplanned disconnects are specified as follows:

1. I/O error or network error: The broker detects problems with the input/output or the network connection.
2. Failed communication within the keep-alive period: The client does not respond within the specified keep-alive period.
3. Client closes the connection without DISCONNECT: The client closes the network connection without sending a DISCONNECT packet.
4. Broker closes the connection due to a protocol error: The broker closes the network connection due to a protocol error.
5. DISCONNECT message with the return code “disconnect-with-will-message”: A client terminates the connection with a special last will message, only in MQTT v5.0.

How does MQTT Last Will work?

The distinction between expected and unexpected disconnects is made by the MQTT disconnect packet. A clean disconnect by the client contains this disconnect packet, while an unexpected disconnect does not. If an unexpected disconnect is detected, the broker sends the Last Will message to all subscribers. Thereby, the broker saves the MQTT Last Will of the client until the client disconnects in a planned manner.

This mechanism enables a clear distinction to be made between planned and unplanned disconnects. While a client can send a message on a specific topic to communicate its status in the event of a planned disconnect, the publication of the MQTT Last Will by the broker signals an unexpected failure. An MQTT Last Will is a regular message with all the usual attributes such as message, topic, QoS and retained flag.

Consistently map availability status

In order to map a complete status model, a client should actively send an “online” message to the same status topic when a connection is successfully established – ideally with retain=true. This ensures that other system components can always recognize the current availability status of the client. Only this interaction of “online” and “offline” messages creates a robust and permanently visible heartbeat model in the unified namespace.

Date of Last Will publication

When exactly the Last Will Message is published by the broker depends largely on the client’s keep-alive settings. When the connection is established, the MQTT client informs the broker at what interval it will send a sign of life (ping) – typically every 30 to 60 seconds. If this sign of life is not received, the broker waits a certain tolerance time (usually 1.5 times the keep-alive time) and then classifies the client as no longer accessible. Only then is the stored Last Will Message triggered and sent to all relevant subscribers. By selecting a suitable keep-alive value, it is possible to control how quickly a connection loss becomes visible in the system.

Structure and Behavior of Last Will

The MQTT Last Will Message consists of several components that significantly influence the behavior in the Unified Namespace. The most important attributes are explained below.

Last Will Message

The Last Will Message (LWT) is a normal MQTT message. The broker publishes this message on behalf of the client if its connection is unexpectedly interrupted. It usually contains a status such as “offline” or “disconnected” and is used to inform other participants in the unified namespace about the failure of a device. Due to its unique and automatically triggered publication, it makes a decisive contribution to the robustness of the overall system.

MQTT Last Will Topic

The topic of the Last Will Message determines the address at which the broker publishes the message. In an Industrial UNS, it is common to use a dedicated status topic for this, for example according to the pattern uns/<device-id>/status. A consistent topic structure facilitates monitoring and enables other system components to react specifically to status changes.

Last Will Quality of Service (QoS)

The Quality of Service (QoS) level determines the reliability with which the Last Will Message is delivered. Especially in industrial applications, QoS 1 (“at least once”) is recommended to ensure that the failure of a device reliably reaches the relevant subscribers.

Last Will Retained flag

If the Last Will Message is sent with the retained flag activated, it remains stored on the broker and is immediately delivered to new subscribers. This is particularly useful if the offline status of a device is to remain visible to subsequent subscribers – for example, for a central monitoring tool or for initializing dashboards.

MQTT Last Will in the Unified Namespace (UNS)

In the Industrial UNS, the Last Will Message is used to reliably map the status of connected systems – even in the event of unexpected failures. It enables a clear distinction to be made between a planned disconnect and a loss of connection. To ensure that communication in the UNS remains robust and evaluable, the Last Will Mechanics must be implemented consistently. The following best practices help to provide status information consistently:

Best Practices

To ensure that the Last Will mechanism works reliably in the Unified Namespace, you should note the following points:

1. Send “online” message: Actively send an “online” message to the same status topic when establishing a connection. Use retain=true for this. This is the only way for clients connected later to see the current status correctly.
2. Set retained flag: Set the retained flag for the last will message to true. The broker then saves the “offline” message and automatically sends it to new subscribers.
3. Choose QoS sensibly: Use at least QoS 1 so that the message arrives reliably. With QoS 0, it may be lost if there are connection problems.
4. Use a consistent topic structure: Stick to a consistent topic scheme, for example: factory1/lin2/device-id123/status. This makes monitoring, filtering and integration into other systems easier.
5. Set keep-alive correctly: Select the keep-alive value so that connection losses are detected quickly – but without putting unnecessary strain on the network. Values between 30 and 60 seconds are a good starting point.

Example of implementation in the UNS

A device with the ID device-42 is marked as “offline” if the connection is lost. This status message should be visible to everyone – including clients that connect later. The Last Will Message is registered when the connection is established. If device-42 fails later without a clean disconnect, “offline” is automatically sent on the defined topic. With retain=True, this message is retained on the broker so that new subscribers can immediately see the last known status.

Conclusion

MQTT Last Will is a powerful feature to ensure reliability and status tracking in MQTT-based systems. Especially in context of an Industrial Unified Namespace (UNS), it enables clear communication about the status of devices and components, even if they fail unexpectedly.