Administrative use

In addition to providing plenty of useful information about your HiveMQ deployment, the HiveMQ Control Center also enables administrative functions. This chapter lists and explains these functions that can be useful to your operations team in a pinch.

Disconnect a Client

To disconnect a client, click on the Disconnect Client button in the right upper corner.

disconnect client with disconnect button
Figure 1. Disconnect client with disconnect button

A confirmation dialog opens, providing an option in form of a checkbox that determines, whether or not the last will and testament message for the client will be published upon disconnection. If the client did not set a last will and testament message upon connect, the option is disabled.

Disconnect client
Figure 2. Confirmation dialog


Remove Client Session

It is possible to remove the session of a persistent online/offline client.
By removing the session, all subscriptions, queued messages and session information of the client will be deleted.
When the client is connected, it will be disconnected first and the lwt will be published if available.
To remove the session of a client, click on the Remove Session button in the upper right corner.

remove client session
Figure 3. Remove client session

The session removal has to be confirmed in a dialog that opens.

Confirm remove session
Figure 4. Remove session confirmation


Manage Subscriptions

This section provides subscriptions management capabilities for this client.
Regular and shared subscriptions can be added after specifying a topic name and quality of service level.
Existing subscriptions are displayed with topic name and quality of service level and can be removed by unsubscribing.

Connection information
Please follow our MQTT topic best practises.


Audit Log

Administrative actions in the Control Center trigger log entries in the audit log. You can find more details about the audit log here.


MQTT Best Practises

Here is a list of best practises for MQTT deployments we identified over the years of supporting our customers.

Best Practice Reasoning

Don’t use a leading forward slash.

It is allowed to use a leading forward slash in MQTT. But that introduces a unnecessary topic level with a zero character at the front

Don’t use spaces in a topic.

A space often make it much harder to read and debug topics

Keep the topic short and concise.

Each topic will be included in every message it is used in, so you should think about making them short and concise

Use only ASCII characters.
Avoid non printable characters

Using non-ASCII UTF-8 character makes it really hard to find typos or issues related to the character set, because often they can not be displayed correctly

Embed a unique identifier or the ClientId into the topic

This helps identifying, who send the message. Another advantage is the enforcement of authorization, so that only a client with the same ClientId as contained in the topic is allowed to publish to that topic

Don’t subscribe to #

Sometimes it is necessary to subscribe to all messages, which are transferred over the broker. This should not be done by using a MQTT client and subscribing to the multi level wildcard. The reason is that often the subscribing client is not able to process the load of messages that is coming its way