How do I differentiate between MQTT Publish events originating from Users vs internal messages meant to broadcast only

0
votes

I am using mosquitto mqtt client.

For example, you have users that publish and subscribe to topics. The topic actually correlates to a REsT endpoint.

Scenario 1 (typical pub/sub usage)

  1. UserA subscribes to topic /device/123/meta
  2. UserB publishes some data to topic /device/123/meta
    • by definition, this publish is broadcasted out to the subscribers
    • we have a script subscribed to /devices/# which knows how to save the payload for the topic /device/123/meta when it receives publish'ed data. This data is saved to the database.

Scenario 2

  1. Someone updates data /device/123/meta via a ReST interface (or a direct DB update, the key is it's not a MQTT publish).
    • database is updated
    • a publish message is sent to the MQTT broker so that all subscribers get the updates as a payload

Scenario 2 is what I'm trying to wrap my head around. This creates a nasty feedback loop. When internal messages are broadcasted out, my script to deal with publish events from users can't differentiate between publish events originating from a 3rd party user or an internal publish event only meant to broadcast out some data (with no saving of data needed).

How should I handle this? The MQTT message is very simplistic and I'm not finding anything I can base logic off of. I'm trying to explore using the origin somehow, but no luck this far. I realize I can write plugins, but this is quite the task for mosquitto.

1
mqttmosquitto

1 Answers

2
votes

There is no way to distinguish where a message originated from the subscriber at a pure MQTT protocol level. Part of the point of a pub/sub protocol is to decouple publishers from subscribers.

The most portable way to do this would be to add a flag to the actual message payload to indicate that message originated from somewhere other than the actual device.

Or assuming the message is being published as a result a trigger in the database have the trigger check if the incoming message actually changed the database stored value, if the incoming messages matches the existing state of the DB then there is no need to republish it.

Mosquitto's plugin mechanism is currently only for writing authentication and authorisation solutions, but the JavaScript mosca or Java HiveMQ brokers support plugins that may be able to do what you want.