9

Currently in my project in which the controller(client) sends sensor data to the server and receives feedback from the server with some additional data, uses MQTT protocol for communication. It has 2 separate topics for client and server.

For Example:

Topic1 - Client(SUBSCRIBES), Server(PUBLISHES)
Topic2 - Client(PUBLISHES), Server(SUBSCRIBES)

But if this project is a use case of a larger application, let's say some 5000 devices need to be installed somewhere.

So, will it be needed to create 5000 different topics for both client and server? Or with lesser topics it can be done and how?

  • 1
    Why do you think it's a problem to have a lot of topics? – hardillb Sep 27 '18 at 9:19
  • 1
    Probably because the software would have to manage them all. – Mawg Sep 27 '18 at 10:33
  • 1
    @hardillb It's not a problem ... just was curious ... but can an MQTT topic have a sub-topic? – ron123456 Sep 27 '18 at 11:18
  • 2
    Sure, topics are hierarchical, so any scheme can be devised. Sparkplug s3.amazonaws.com/cirrus-link-com/… has a couple of topics per edge node and device behind edge node. – Gambit Support Sep 27 '18 at 11:35
  • have a look at this shiftr.io/shiftr-io/demo – jsotola Oct 8 '18 at 1:05
5

From client to server you may pack client-id into payload, e.g. if it is JSON, one of the keys can have client-id value.

Response from server to client should contain client-id in order to broker to not to broadcast message, but to send it directly to one connected client.

At the same time you may subscribe your server to something like: "requests/+" and each client will publish to "request/{client-id-1}", "request/{client-id-2}", and server will receive both with just one subscription.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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