Here’s a topic that was discussed on a discord channel back in 2021 and what I proposed to that discussion — what are your options when a publisher (say in a factory/plant) had to change the topic?
The reasons could be many, one of which, is that their current topic namespaces are starting to conflict when they started adding more devices to the plant floor or that it is not unique enough to distinguish them from other devices on other plants (either causing duplicate data or worse, wrong data).
Diagram
Note that the broker I used in my diagram is mosquitto, but it could be different from what you’re using. I have also removed some of the details so I can just focus on the minimum required components involved in this.
Current Situation
You got a device on the floor that publishes to a topic that (currently) has many subscribers. As stated earlier, for whatever reason, this existing and used topic needs to be changed, so the problem now is how to ensure that existing subscribers don’t lose the notification — ideally without rewriting any of them or even their configurations.
Option A. Notification Event
One approach is for the publisher to send a “topic has changed” event to another namespace (ex. */update) to let existing subscribers make the necessary changes.
The obvious problem with this, is that it assumes the subscribers are aware of this mechanism and knows how to react to them.
This is fine if you’re on the initial stages of development and can make this change to the subscribers, but this isn’t the normal case when things like these happen, so let’s look at another option.
Option B. Man-in-the-middle
A more realistic approach is just spawn a new subscriber for the new topic and let this one distribute (redirect) the information to the existing subscribers.
This approach makes the change transparent to both publisher and subscribers.
The Catch
Although this is probably the quickest, easiest and realistic approach, the new subscriber could easily become a bottleneck later on unless you have a plan for that scenario as well.
One initial solution is make the message forwarding asynchronous from the get-go.
You might also consider or study setting the Retention Flag to True and QoS to 2. Just also consider the downside to these before implementing.
Extra: Visualization Videos related to MQTT
Related only to MQTT (and not the challenge or topic in this blog), these are some of the videos I uploaded some time ago where I used PyGame to visualize MQTT data:
Related Topic (MQTT)
Here’s my Introductory blog on MQTT (in case you have not seen it yet)