Hi Maverick
thank you for our reply.
As I mentioned, I am new to MQTT, so I probably do not know how to best implement MQTT in our project.
The set up I was hoping to achieve was that all the voucher information would be stored in the broker, and that the back-end application would only have to connect to the broker infrequently (once an hour, or once a day).
This is my understanding of the implications of using a common topic, e.g. my-project/voucher-info, with the voucher ID in the message content:
First, the back-end application couldn’t store all the vouchers in the broker, as it could only publish one message to that topic – or maybe I am wrong – maybe it can publish 100,000 messages to that topic.
Second, when a device connects to the broker, because a user has entered a voucher ID, it couldn’t subscribe to the individual voucher topic anymore, and it couldn’t subscribe to the common topic, as it would then et all the 100,000 messages.
So, to use a common topic, it seems to me that the back-end application might have to be permanently connected to the broker, and subscribe to the common voucher-info topic, so that it could respond quickly to a device communicating with the broker.
For further information on what I am trying to achieve, I had snet an email earlier to someone else about it - so I will copy and paste it here.
Thanks,
Garrett
Project Overview
Our customer will have about 1,000 devices in the field – each device has a user interface (screen / keypad etc.).
To use the device, customers first purchase one or more “use once” vouchers.
Each voucher has a unique ID/code – let’s say 12 digits.
The customer enters the voucher number at the device keypad.
The device contacts a TCP server, grabs the voucher information, and determines if it user can use the device or not.
Later, the device will then send more information back to the server.
Currently, there are about 100 devices in the field, and these device communicate with a dedicated TCP server. We are looking to upgrade the systems and use an MQTT broker instead.
Existing System – description
- The TCP server connects to a database which stores information all vouchers and all kiosks.
- To use a service, a user purchases a voucher, and then enters the voucher number at a device keypad.
- The device connects to the server and requests the voucher information.
- Based on this information, the device either grants or denies the user access to a service.
- Once the user has finished, the device again communicates with the server to update the status of the voucher (e.g. state change from “ready to use” to “used”).
Proposed System – description
- A back-end application, acting as an MQTT Client, pre-populates (creates/publishes) one topic for each voucher in the MQTT Broker.
- Let’s say there will be 100,000 vouchers used in a year – so these could all be created/published at the start, or in batches every month or so.
- e.g. my-project/voucher-info/123456789012/payload
- where payload might include the following:
- voucher-state
- voucher-type
- publish-date-time
- used-date-time
- expire-date-time
- device-used
- When a device first powers up in the field, it would publish its status
- e.g. my-project/ device-info/5454865/payload
- where payload might include the following:
- When a user enters a voucher number at a device, the device establishes communication with the MQTT Broker, and subscribes to the voucher topic, according to its unique ID
- e.g. my-project/voucher-info/123456789012/payload
- If this voucher/topic exists, the device will receive a message from the broker, with the latest message/payload, which could include:
- voucher-state = “ready to use”
- The device then grants the user access to a service.
- When the user is finished, the device modifies the data received in the voucher payload, including the voucher-state (which is now “Used”) and the device-used fields, and then publishes back to this same voucher-info topic.
- This would be a persistent message, so that the broker always holds the last received message per topic.
- If a user was to enter this same voucher code at the same, or another device, the device would again subscribe to this voucher topic, the broker would send the topic message and payload to the device, and the device would see that the vouch-state is already “Used”, and therefore deny the user access to the service.
- At some stage, e.g. once a day, the back end application can connect with the broker. The back application can subscribe to all voucher and device events
- e.g.
- my-project/voucher-info/#
- my-project/device-info/#
- In this way, the back-end application would receive one message for every device and voucher whose state has changed
- Also, at some stage, the back-end application would probably want to remove the “used” vouchers from the broker – perhaps it has to publish an empty payload to the associated voucher topics