Retrieve "Sender" ClientID when subscribe Topic

[Riccardo Zamana]

Hi everybody, I'd like to know if there is some trick in order to get the clientId which sent a message to a topic, when i try to subscribe that topic.
I mean:

1. many devices, that publish messages to a "GPS_POINTS" topic.
2. one subscriber to GPS_POINT topic that must store payloads to different MongoDB Collections, one per Device.

I've tried to put the deviceName in the variable Header of Publisher, but (in Paho Java client implementation) I can't find any strategy in order to retrieve headers.
I would like to use the unique clientID (which identifies the publisher) as a sort of "dispatch variable" when I read payloads using the subscriber.

kind regards
Riccardo

[ನಾಗೇಶ್ ಸುಬ್ರಹ್ಮಣ್ಯ (Nagesh S)]

Decoupling the sender and receiver is core to pub-sub paradigm or as in this case MQTT. So, I don't think, MQTT would allow you to such a differentiation.

However, you could add the deviceName in the payload or in the topic string itself. Then, have your subscribing client differentiate accordingly.

--
To learn more about MQTT please visit http://mqtt.org
---
You received this message because you are subscribed to the Google Groups "MQTT" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mqtt+uns...@googlegroups.com.
To post to this group, send email to mq...@googlegroups.com.
Visit this group at http://groups.google.com/group/mqtt.
For more options, visit https://groups.google.com/d/optout.

[Riccardo Zamana]

Was the first obvious solution, but I've to solve this problem, also: devices to ActiveMQ bandwidth. including the ID in every payload could make a lot of redundant byte traffic. 

Last night i was thinking to working on topic trees:

- on the publish side (for example: topic "position/myDeviceId") and 

 - on regExp by subscriber (in other words, by connect to a topic position/# as a wildcard)

What do you think about?

[ನಾಗೇಶ್ ಸುಬ್ರಹ್ಮಣ್ಯ (Nagesh S)]

Putting the deviceId in topic string was the second option I mentioned.

Yes, it is a good choice as it can also serve the purpose of 'load balancing', for e.g. publications on topic string position/myDevice1 handled by subscribing application 1, etc.

[Christian Götz]

Hi,

in general it is a known pattern to put the deviceId into the topic, so subscribers can get the data of the device (topic example: deviceId/position) or of all devices with a wildcard ( +/position ).

When your use case is to save MQTT messages into any database, you could also write a custom plugin for the HiveMQ broker. If you implement the OnPublishCallback [1] you get a Publish object and a client object, which you can use to save the data into Mongo DB according to the ClientID. More details about the HiveMQ plugin system can be found in the documentation [2].

Cheers,
Christian

[1] http://www.hivemq.com/docs/plugins/2.0.1/#onPublish-callback
[2] http://www.hivemq.com/docs/plugins/2.0.1