การเชื่อมต่อ MQTT & API

การเชื่อมต่อ MQTT และ API สำหรับควบคุมฝั่งเครื่อง

คู่มือเส้นทางระหว่าง backend, ตัวควบคุม QuLink และเครื่อง vending หรือ self-service endpoint, topic, authentication และ payload จะยืนยันตาม firmware

HTTPS APIMQTT topicsIdempotent commandsEvent callbacks
QuLink MQTT and API controller board for vending machines

Transport choice

HTTPS or MQTT?

Both can exist in one project. The choice depends on whether you need a response now or a stream of events.

Use caseHTTPS APIMQTT
Backend sends a commandRequest / responsePublish to command topic
Backend receives eventsWebhook or pollingSubscribe to event topic
Best fitServer-triggered actionsReal-time status and telemetry
Failure handlingHTTP status + retryQoS + reconnect + idempotency

The exact transport available on a machine depends on the controller, firmware, and network path.

ความเหมาะสมของโปรเจกต์

สำหรับทีมที่เชื่อมเครื่องกับ backend ของตัวเอง

สัญญาณความต้องการ

  • Your backend or app needs to trigger a vend, relay, pulse, unlock, or timed session.
  • Your platform uses HTTPS, webhooks, or MQTT and wants the machine-side contract in one place.
  • You need event identity, retries, and offline behavior defined before a sample.
  • You want to keep your own payment provider, schema, and dashboard.

ข้อมูลที่ควรส่ง

  • รูปเครื่องหรือบอร์ดปัจจุบัน
  • หมายเหตุ interface หรือ wiring
  • การทำงานที่ต้องการหลัง API หรือการชำระเงิน
  • ต้องการ upload data หรือไม่

ไม่เหมาะหาก

  • You need payment acquiring, settlement, or wallet balance.
  • The machine has no controllable interface or usable event source.
  • You need a fixed API contract before the controller and firmware are confirmed.

รูปแบบการเชื่อมต่อ

สัญญาเดียว สอง transport

HTTPS สำหรับคำสั่งและ response, MQTT สำหรับ event แบบเรียลไทม์ identity, topic, authentication และ QoS ยืนยันตามโครงการ

API transport
HTTPS REST; JSON request and response
MQTT transport
MQTT 3.1.1 over TLS 1.2; QoS 1; keepalive 60s
Device identity
Project-issued device_id
Command reference
reference_id is used for idempotency
Event identity
event_id, occurred_at, device_id, result
Authentication
HTTPS Bearer token; optional HMAC-SHA256
Error model
unauthorized, device_offline, timeout, invalid_command, machine_fault

ขั้นตอนการทำงาน

จาก interface ของเครื่องไปสู่ผลลัพธ์ที่ควบคุมผ่าน API

Confirm the machine interface

Send the controller label, wiring photos, and the action the machine must perform.

Define the command contract

Confirm command names, slot or channel mapping, timeout, and result fields.

Connect the transport

Issue device identity, token, topic prefix, TLS mode, and QoS for the project.

Test one machine

Validate command, machine action, event identity, retry, and reconnect on a sample.

ตัวอย่าง API

ตัวอย่างคำสั่ง server หรือ webhook สำหรับการทำงานฝั่งเครื่อง

ฟิลด์คำสั่งขึ้นอยู่กับ interface ของเครื่อง, firmware profile และว่าการชำระเงินหรือแอปของคุณเป็นตัว trigger

POST /v1/devices/{device_id}/commands
Authorization: Bearer 
Content-Type: application/json

{
  "command": "vend",
  "slot": "B04",
  "reference_id": "ORDER-1001",
  "timeout_ms": 15000
}

# MQTT topic map
devices/{device_id}/commands
devices/{device_id}/events

Project RFQ

บอกเราว่าเครื่องต้อง ทำอะไร ส่งอะไร หรือรายงานอะไร

ส่งรุ่นเครื่อง, interface controller, การทำงานที่ต้องการ และฟิลด์ข้อมูล เราจะยืนยันสัญญา API/MQTT และการทดสอบตัวอย่าง

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
ตัวเลือก: บริษัท จำนวน อินเทอร์เฟซ และความต้องการข้อมูล

ข้อความสั้นๆ ก็พอ โดยปกติเราตอบกลับภายใน 24 ชั่วโมง

มีรูปเครื่องหรือบอร์ด? ส่งทาง WhatsApp — เรามักดูรูปก่อน

FAQ

คำถามที่มักเกิดขึ้นก่อนการทดสอบตัวอย่าง

Do you support MQTT?

MQTT 3.1.1 over TLS 1.2 with QoS 1 is the baseline. Broker, topic prefix, and authentication are confirmed per firmware profile.

Can we use our own backend?

Yes. The controller can deliver commands and events to your own API, webhook, or broker. The exact flow is confirmed on a sample.

How do you prevent duplicate commands?

The contract uses reference_id and event_id. Retry and deduplication behavior is confirmed in the firmware profile and tested on one machine.

What happens when the network is offline?

Event buffering and retry are part of the integration plan. Capacity, power-cycle retention, and backfill behavior must be tested before making a persistent-cache claim.

ส่งรูปเครื่อง ส่งคำขอโครงการ