Define topics
Agree on device command and event topics, payload schema, QoS, and retention.
Guides
MDB to MQTT
MDB to MQTT gateway for vending and unattended machines.
Use QuLink when your backend or IoT platform speaks MQTT and the machine speaks MDB. QuLink translates commands and events without replacing the existing vending controller.
MQTT topicsMDB vendQoS and statusTelemetry
Part of Machine Data Upload IoT Board for Self-Service Equipment
Project fit
For MQTT platforms and MDB vending fleets
Buyer signals
- Your cloud or IoT platform already uses MQTT topics.
- The machine exposes an MDB cashless path or vending controller.
- You need vend commands, payment callbacks, and telemetry in one flow.
- You want to keep the existing cabinet and controller.
What to send first
- Machine photo or existing board photo
- Interface or wiring note if available
- Target action after API command or payment
- Whether telemetry or data upload is required
Not the right fit if
- You only need a pure payment acquiring account and no machine-side control.
- There is no physical machine action after payment, booking, or API approval.
- The project has no machine photo, board photo, wiring note, or interface clue yet.
Integration model
MQTT topics on one side, MDB behavior on the other
QuLink maps topic commands to MDB vend actions and publishes results, faults, and status back to your broker. Topic names and payloads are defined per project.
- Machine interface
- MDB cashless path, vending controller, optional relay or serial
- MQTT profile
- publish/subscribe, QoS, retained status, JSON payload (project-dependent)
- Commands
- dispense, query_status, start_session, cancel, relay trigger
- Events
- vend.result, payment reference, fault, heartbeat, online/offline
- Project mode
- MQTT pilot, fleet integration, edge gateway, OEM profile
Workflow
From machine interface to API-controlled result.
Map MDB actions
Confirm slot mapping, vend authorization, timeout, and failure behavior.
Connect the broker
Configure device identity, credentials, TLS, and reconnect behavior.
Test one machine
Verify command delivery, vend result, duplicate handling, and offline behavior.
API example
A clear server command or webhook for the machine-side action.
The exact command fields depend on machine interface, firmware profile, and whether payment or your own app triggers the action.
topic: qulink/devices/VEND-1049/commands
{
"command": "dispense",
"reference_id": "MQTT-ORDER-1049",
"machine_action": {
"interface": "mdb_cashless",
"slot": "A07"
}
}
Project RFQ
Send a machine photo. We help identify the board, interface, and next test step.
Send your MQTT topic schema, machine model, payment flow, expected events, and rollout quantity.
A good first message
If you are unsure about the exact interface, send what you have. Photos often answer more than a long spec.
- Machine type and target country
- Machine photo, board photo, or wiring photo
- Action after payment or API command
- Need data upload? expected quantity?
Fastest first step
- Send a machine photo
- Describe the action after API or payment
- Tell us if data upload is needed
FAQ
Questions buyers usually ask before a sample test.
Does QuLink support MQTT out of the box?
MQTT support depends on the board, firmware profile, and project requirements. Send your broker and topic design so we can confirm the right configuration.
Can we use TLS and authentication?
Yes, the project can include TLS, device credentials, and reconnect behavior. The exact options depend on the hardware profile.
Can it keep the existing vending controller?
Often yes when the machine exposes a compatible MDB cashless path. The sample test confirms the behavior.
Can it publish telemetry and faults?
Yes, when the machine exposes the relevant signals or controller events.
Related use cases