La réponse en bref
Une passerelle MQTT demande une décision explicite sur les données à conserver pendant une panne. Historique des mesures, état courant et ordres ont des besoins différents. Retrouver la connexion ne prouve pas que l’application reprend correctement son travail.
Classer les messages selon leur signification
Décidez pour chaque type si le dernier état suffit ou si l’historique complet est nécessaire. Précisez quand l’information devient périmée. Une ancienne mesure peut être utile à une série historique et inadaptée à l’affichage de l’état présent.
Attribuez des identifiants à l’équipement et à l’événement. Indiquez si l’horodatage représente la mesure ou l’envoi. Si l’horloge n’est pas fiable après redémarrage, cette incertitude doit rester visible plutôt que devenir une date apparemment correcte.
Séparer protocole et stockage applicatif
MQTT 5 distingue durée de session et durée de vie du message. Ces options ne créent pas automatiquement un stockage local persistant pour l’application. OASIS — MQTT Version 5.0
Décrivez séparément ce que conservent appareil, bibliothèque, broker et destinataire. Vérifiez l’implémentation et sa configuration réelle. Une valeur par défaut non documentée ne garantit pas le comportement après redémarrage de l’appareil ou mise à jour d’une bibliothèque.
Calculer capacité et politique de débordement
Une première estimation est : fréquence des messages × durée maximale hors ligne × octets stockés par enregistrement. Ajoutez métadonnées et réserve. Deux enregistrements par seconde pendant une heure donnent 7 200 entrées ; leur volume dépend encore du format de chacune.
Choisissez l’action à saturation : remplacer les anciennes données, éliminer certains messages ou signaler un défaut. Limitez le rattrapage pour continuer à traiter nouvelles mesures et commandes. Pour une mémoire persistante, considérez aussi la fréquence prévue des écritures.
Vérifier l’effet de bout en bout
Le destinataire doit reconnaître les événements déjà traités grâce à leur identifiant applicatif. Un message répété ne doit pas exécuter accidentellement le même ordre une seconde fois. Définissez aussi validité et confirmation du résultat des commandes.
Testez séparément coupure réseau, redémarrage du broker et de l’appareil. Au retour, vérifiez quantité, ordre, âge et doubles traitements. Le succès correspond à l’effet attendu dans l’application, pas simplement à un voyant de connexion allumé.
Décisions pour le mode hors ligne
- Séparer historique, état et commandes.
- Définir âge admissible et durée de coupure.
- Calculer tampon et comportement à saturation.
- Définir identifiants et traitement des doublons.
- Tester séparément réseau, broker et appareil.
Questions fréquentes
Un QoS plus élevé garantit-il une seule opération métier ?
Pas à lui seul. L’application doit définir les liens entre réception, stockage et traitement, et reconnaître les événements répétés.
Faut-il conserver chaque mesure durablement ?
Seulement si l’usage le demande. Certains indicateurs se contentent du dernier état, tandis qu’un historique peut nécessiter la connaissance des pertes. Cette décision doit figurer dans les exigences.
Sources techniques
Prestation associée