MQTT Engine

Le MQTT pour le parc d'appareils Cams. Le MQTT Engine est un consommateur backend placé derrière EMQX : il s'abonne aux topics partagés de présence et d'état, achemine les événements vers le même pipeline de présence que les transports HTTP et TCP, et publie des enveloppes de commandes du serveur vers les appareils.

Prise en main Documentation développeurs

Présentation

Un moteur de transport MQTT qui ingère les événements de présence et envoie les commandes aux appareils via un broker EMQX — conçu pour les grands parcs d'appareils connectés.

Le MQTT Engine est le transport MQTT de la famille de moteurs Cams, pendant du HTTP et du TCP persistant. Il s'exécute comme consommateur backend derrière un broker EMQX : il s'abonne aux topics partagés de présence et d'état sous api/mqtt/v1/{sn}/, achemine chaque événement vers le pipeline partagé et publie les commandes du serveur vers les appareils sur le topic de commande, sous forme d'enveloppes JSON compatibles avec les évolutions futures. EMQX termine les sessions TLS des appareils, l'authentification, la QoS et le last-will ; plusieurs instances du moteur se répartissent la charge via les abonnements partagés EMQX pour les grands parcs.

SERVICEMQTTEMQXTLSJSONC++

Utilisé dans :Flottes, transport et conducteurs Événements, festivals et stades

Schéma de topics MQTT (EMQX)

# device -> server (attendance)
api/mqtt/v1/{sn}/evt   { "user_id":"1001", "att_time":"...", "att_state":1 }
# device -> server (presence / LWT)
api/mqtt/v1/{sn}/st    { "online": true }
# server -> device (command)
api/mqtt/v1/{sn}/cmd   { "id":"c1", "op":"sync_user", "data":{} }

Fonctionnalités

Ce qu'il fait

Ingérer via MQTT

S'abonne aux topics d'événements partagés et achemine chaque événement de présence vers le même pipeline de stockage et d'envoi que HTTP et TCP.

Suivre la présence

Consomme le topic de présence et le last-will pour que les déconnexions détectées par le broker marquent un appareil comme hors ligne.

Envoyer des commandes

Publie les commandes en file d'attente du serveur vers l'appareil sur le topic de commande propre à chaque appareil, sous forme d'enveloppes JSON en QoS 1.

Mise à l'échelle horizontale

Les abonnements partagés EMQX répartissent la charge de la présence entre plusieurs instances du moteur pour les grands parcs d'appareils.

Caractéristiques

Tout est inclus

Frontal de transport MQTT pour la présence, homologue des moteurs HTTP et TCP natifs
Schéma de topics api/mqtt/v1/{sn}/{evt|cmd|st} aligné sur l'application et l'ACL EMQX
Consommateur backend derrière EMQX : les abonnements partagés répartissent la charge entre N instances
Ingère dans le pipeline partagé des événements de présence dont la charge utile est identique au corps d'un pointage HTTP
Présence et last-will via le topic d'état, pour que les déconnexions marquent les appareils comme hors ligne
Envoi de commandes du serveur vers l'appareil sous forme d'enveloppe JSON {id, op, data} compatible avec les évolutions futures, en QoS 1
TLS vers le broker avec vérification de l'autorité de certification ; le moteur utilise un compte backend, et non un numéro de série d'appareil
Build multiplateforme (Linux et Windows) sur Eclipse Paho C++

Développez avec MQTT Engine

Obtenez une clé, lisez la documentation et livrez. Notre équipe vous accompagne pour votre première intégration.

Parler à un ingénieur WhatsApp

FAQ

Questions fréquentes

Quel est le lien entre le MQTT Engine et EMQX ?

EMQX reste le broker qui termine les sessions TLS des appareils, l'authentification, la QoS et le last-will. Le MQTT Engine est un consommateur backend qui s'abonne à des topics partagés pour ingérer la présence et publie des commandes vers les appareils.

Puis-je exécuter plusieurs instances du MQTT Engine ?

Oui. Les abonnements partagés EMQX répartissent la charge des topics de présence et d'état entre toutes les instances en cours d'exécution : vous montez en charge en ajoutant des instances.

Quel est le format des commandes du serveur vers l'appareil ?

Une enveloppe JSON {id, op, data} sur le topic de commande en QoS 1, où op est le seul champ obligatoire et où les op inconnues sont ignorées par les appareils plus anciens pour garantir la compatibilité ascendante.