For my home setup, I use mosquitto as the MQTT broker. It works fine, delivering typical MQTT services.

There are two functionalities which are missing:

  • log all messages which were sent to the broker (with a timestamp)
  • expire retained messages after some time

The first one is doable by writing a helper (example of code to do this) which would collect all messages (by subscribing to #) and log them on its own. Having this built-in would be nice, though.

The second one must be implemented on the server itself as it is the only one who knows that a message had the retain flag set. I know that I saw this ability in the description of a server but I cannot find it anymore (from memory, there was a warning that this is non-standard behaviour and that the TTL could be set for days, weeks, months or years)

  1. HiveMQ offers a logging plugin iirc and implementing it using a callback in Mosca should be trivial.

  2. Mosca has support for ttl on it's memory/levelup persistence layer


In addition to hardillb's suggestion of Mosca, HiveMQ 3.3+ lists TTL as a feature:

HiveMQ introduces Time to Live (TTL) on various levels of the MQTT lifecycle. Automatic cleanup of expired messages is as well supported as the wiping of abandoned persistent MQTT sessions. In particular, version 3.3 implements the following TTL features:

  • MQTT client session expiration
  • Retained Message expiration
  • MQTT PUBLISH message expiration

I believe the new MQTT 5 specification is also designed to support message expiry with the Message Expiry Interval property on PUBLISH packets.

If present, the Four Byte value is the lifetime of the Application Message in seconds. If the Message Expiry Interval has passed and the Server has not managed to start onward delivery to a matching subscriber, then it MUST delete the copy of the message for that subscriber [MQTT-3.3.2-5].

In section (RETAIN) it is stated that:

If the current retained message for a Topic expires, it is discarded and there will be no retained message for that topic.

From this description, it sounds like MQTT 5 will support retained message expiry. MQTT 5 brokers aren't as mature as the current MQTT 3.1.1 brokers, but in a few months you should certainly be able to find a MQTT 5 broker which will support TTL in a standards-compliant way (rather than a proprietary extension). In the mean time (or if you're stuck with MQTT 3.1.1), you'll need to look into the other suggestions.

  • 1
    Just wanted to add VerneMQ to the list of brokers which support MQTT 5.0 and hence also expiration of (retained) messages. – Lars Hesel Christensen Sep 17 '18 at 10:57

flespi MQTT broker supports MQTT 5.0 and retained messages expiration timeout as part of it.

At the same time according to first part of your question, flespi broker adds special timestamp attribute to each message it received. It means that if you are using any kind of MQTT 5.0 enabled client (mqtt.js for javascript and gmqtt for python are in production already), after subscribing it to '#' you can store exact time of messages publication as broker sees it in your own database. And this also will work if a message is published using MQTT 3.X protocol, but received via 5.0.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.