Batching Messages With MQTT

  • I would have multiple devices flagged as being “inactive”
  • Devices could go inactive at anytime but I don’t want to action them unless they have been inactive for between 45–60mins
  • Once I’ve actioned a device I don’t want to action it again unless it goes quite for another 45–60mins
  • I can only have one message per topic when using Quality of Service (QoS) 0
  • If a client is connected and subscribed to a topic any messages sent are immediately received
  • Retained messages will always be picked up unless the they are cleared from a topic
  • Quality of Service (QoS) level 2 makes sure that only one copy of a message is received but requires a durable subscription tied to a client id (which is done in by setting the “clean session” flag to false).
  • Where a durable subscription is in place, when the client with the associated client id reconnects held messages will flow.
  1. Use “retained” messages and QoS 0 for the publication of the “inactive” device and in the message processor clear the message once it had been received.
  2. Use QoS 2 and use distinct client id’s to allow messages for a given time period to be retrieved.
/reengage/<client id>/<time period>
  • So that I could use security features on my broker (I am using IBM Message Gateway) to lock down the ability to publish to the topic.
  • To support a device removing an inactive message should it become active of its own accord
Device Simulation Flow
{
"reengage": true,
"client": <client_id>
}
Set topic to hold “inactive” message
  1. Connect to MQTT Broker
  2. Subscribe to topic /reengage/+/<time period>
  3. For each received valid message take action to “shoulder tap”, publish null message to topic
  4. Unsubscribe from topic
  5. Disconnect from MQTT Broker
QoS 0 sweeper
Setting the sweeper topic
/reengage/+/0
/reengage/+/1
/reengage/+/2
/reengage/+/3
QoS 2 sweeper flow
Durable subscriptions
  1. Connect to MQTT Broker with client id used to subscribe to the time period to “sweep”
  2. For each received valid message take action to “shoulder tap”
  3. Disconnect from MQTT Broker

Summary

I had a LOT of fun digging around this challenge and have learn a lot more about MQTT and in particular QoS 2. Based on my experience I would say that for my use case the best option is to use the QoS 0 and retained message route. This adds some complexity around clearing the retained messages but simplifies the “clearing” of a message should a device reactivate its self before the “sweeper” kicks in.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Tony Hickman

Tony Hickman

I‘ve worked for IBM all of my career and am an avid technologist who is keen to get his hands dirty. My role affords me this opportunity and I share what I can