ApiGear over MQTT
MQTT is a lightweight publish/subscribe messaging protocol widely used for IoT, telemetry, and many-to-many communication. ApiGear generates client and service adapter code that exposes your ObjectAPI interfaces over an MQTT broker, so an interface's properties, signals, and operations flow between any MQTT-speaking peers — C++, Qt, Python, Rust, Unreal Engine, web dashboards, or embedded devices.
This page describes the wire protocol: how an interface maps onto MQTT topics and payloads. It is the same across every template, so a service generated for one language interoperates with a client generated for another. For the language-specific generated classes and usage, see the per-template pages linked below.
Unlike OLink (point-to-point), MQTT routes all traffic through an external broker (Mosquitto, EMQX, HiveMQ, AWS IoT Core, …). The broker decouples publishers from subscribers and handles message routing and retention.
How it works
- A service adapter wraps your local interface implementation and publishes property changes, signals, and operation replies to the broker; it subscribes to inbound set-requests and operation calls.
- A client implements the same interface but, instead of running the logic locally, publishes/subscribes to the broker — acting as a remote proxy. Properties are cached locally and updated from retained messages.
- ApiGear uses MQTT v5 so that operation calls can carry
CorrelationDataandResponseTopicas message properties. A v3.1.1 fallback is available that embeds the same data in the payload (see the mapping page).
In this section
- Topic Mapping — the authoritative spec: topic structure, payloads, QoS, and the v3 fallback.
- ApiGear MQTT Spec v0.1 (PDF) — the formal specification document.
- Protocol reference: MQTT v5.0 (OASIS).
Implemented by
The MQTT transport is generated by these templates: