Un rebirth Sparkplug est une commande qu'une application hôte envoie à un edge node pour qu'il republie ses messages NBIRTH et DBIRTH, afin que l'hôte puisse reconstruire une vue complète et à jour de ce nœud. Dans ce guide, vous verrez quelles situations justifient un rebirth, comment en envoyer un manuellement, comment un edge node correct y répond, et comment diagnostiquer le problème le plus fréquent sur le terrain : des nœuds qui font des rebirths en boucle.
Ce que fait un rebirth
Les consommateurs Sparkplug s'appuient sur les messages de birth pour trois choses : la liste des métriques, la correspondance entre alias, noms et types de données, et la valeur courante de chaque métrique. Si un hôte manque un birth ou perd le fil de la séquence, son modèle du nœud est incomplet. Un rebirth corrige cela sans couper la connexion MQTT.
La commande est un message NCMD sur spBv1.0/{group}/NCMD/{edge_node} contenant une métrique booléenne nommée Node Control/Rebirth à true. L'edge node répond en publiant un nouveau NBIRTH avec seq remis à 0 et le même bdSeq que sa session en cours, suivi d'un DBIRTH pour chaque device. Il n'existe pas de rebirth distinct au niveau device ; un rebirth de nœud republie toujours tous ses devices.
Quand un hôte doit demander un rebirth
| Déclencheur | Pourquoi c'est important |
|---|---|
| L'hôte démarre ou se reconnecte alors que le nœud est déjà en ligne | L'hôte n'a jamais vu les births d'origine |
| Trou dans seq | Un message a été perdu ; les valeurs, voire les définitions de métriques, peuvent être fausses |
| Données reçues avec un alias inconnu | L'hôte ne peut pas associer la valeur à une métrique |
| Données d'un nœud ou d'un device sans birth connu | L'hôte n'a aucune définition de métrique |
| Métrique dont le nom est absent du birth | La configuration du nœud a changé sans nouveau birth |
| Un opérateur demande une actualisation | Récupération manuelle pendant la mise en service |
Les applications hôtes bien conçues les envoient automatiquement. Si vous écrivez votre propre consommateur, implémenter les trois premiers déclencheurs couvre la plupart des situations réelles.
Comment l'edge node doit répondre
- Recevoir le NCMD et vérifier que la métrique
Node Control/Rebirthest à true. - Remettre seq à 0.
- Publier le NBIRTH avec chaque métrique du nœud, sa valeur courante, le bdSeq actuel et la métrique
Node Control/Rebirthremise à false. - Publier un DBIRTH pour chaque device actuellement connecté.
- Reprendre NDATA et DDATA, seq continuant à partir des births.
Le bdSeq ne change pas, car la session MQTT, et donc le will NDEATH enregistré, n'a pas changé. Un nœud qui incrémente bdSeq lors d'un rebirth sans se reconnecter va perturber les hôtes qui vérifient le bdSeq à l'arrivée ultérieure d'un death. Les règles complètes des certificats sont expliquées dans certificats birth et death Sparkplug.
Envoyer un rebirth manuellement
Pendant la mise en service, il est utile de déclencher soi-même un rebirth. Ce script Python utilise paho-mqtt 2.x et des classes générées à partir du fichier sparkplug_b.proto d'Eclipse Tahu (voir notre tutoriel pour décoder Sparkplug B en Python pour l'étape de génération, à faire une seule fois) :
import sys
import time
import uuid
import paho.mqtt.client as mqtt
import sparkplug_b_pb2 as spb
if len(sys.argv) != 3:
sys.exit("usage: python rebirth.py <group_id> <edge_node_id>")
group, node = sys.argv[1], sys.argv[2]
payload = spb.Payload()
payload.timestamp = int(time.time() * 1000)
metric = payload.metrics.add()
metric.name = "Node Control/Rebirth"
metric.timestamp = payload.timestamp
metric.datatype = 11 # Boolean
metric.boolean_value = True
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
client_id=f"rebirth-{uuid.uuid4().hex[:8]}")
client.connect("broker.connectmq.com", 1883, keepalive=30)
client.loop_start()
info = client.publish(f"spBv1.0/{group}/NCMD/{node}", payload.SerializeToString(), qos=0)
info.wait_for_publish()
client.disconnect()
client.loop_stop()
print(f"rebirth sent to {group}/{node}")
Lancez-le contre un simulateur sur le serveur MQTT public gratuit, par exemple python rebirth.py demo-3f9a1c line1, tout en surveillant le groupe :
mosquitto_sub -h broker.connectmq.com -p 1883 -i rebirth-watch-77d2 -v \
-t "spBv1.0/demo-3f9a1c/#"
Vous devriez voir le NCMD, puis un NBIRTH et un DBIRTH dans la foulée. Sur un broker de production, connectez-vous sur le port 8883 avec TLS et vos identifiants du portail, et rappelez-vous que seules les applications hôtes autorisées doivent envoyer des commandes à de vrais équipements.
Démarche de dépannage
Lorsqu'un hôte affiche des métriques périmées ou manquantes, suivez ces étapes dans l'ordre :
- Le nœud est-il connecté ? Vérifiez sa connexion. Sur ConnectMQ, abonnez-vous à
$SYS/broker/connection/{clientId}/stateavec le client ID du nœud, ou consultez le portail. - Le nœud a-t-il publié ses births ? Cherchez NBIRTH et DBIRTH sur ses topics. S'ils n'apparaissent pas après la connexion, il attend peut-être une application hôte primaire dont il ne voit pas le STATE.
- Le nœud est-il abonné à NCMD ? Envoyez un rebirth manuel. S'il ne se passe rien, le nœud n'est pas abonné à
spBv1.0/{group}/NCMD/{node}ou n'implémente pas le rebirth. - Les births contiennent-ils toutes les métriques ? Comparez le DBIRTH décodé avec les tags attendus. Des métriques manquantes relèvent de la configuration du nœud, pas du transport.
- seq est-il continu ? Observez plusieurs messages de données après le birth. Des trous indiquent des pertes de messages ou un second client utilisant le même edge node ID.
- Les alias se résolvent-ils ? Chaque alias présent dans NDATA ou DDATA doit figurer dans le dernier birth. Sinon, le nœud envoie des alias qu'il n'a jamais déclarés.
- L'hôte traite-t-il correctement les births ? Si le broker montre des births corrects mais que l'hôte affiche toujours des données périmées, le problème se situe côté hôte.
Voir les payloads décodés accélère nettement les étapes 2, 4, 5 et 6. ConnectMQ décode Sparkplug B dans l'explorateur de topics de son portail : vous pouvez lire la liste des métriques d'un birth, vérifier les valeurs de seq et repérer les alias sans écrire de décodeur.
Les tempêtes de rebirth et comment les arrêter
Une tempête de rebirth est une boucle dans laquelle un nœud enchaîne les rebirths, inondant le broker et l'hôte de messages de birth. Causes typiques :
| Cause | Comment la reconnaître | Solution |
|---|---|---|
| Deux clients avec le même edge node ID | Valeurs de seq entremêlées, déconnexions fréquentes | Donner à chaque nœud un ID unique par groupe |
| Client ID dupliqué | Le nœud se déconnecte dès qu'un autre client se connecte | Utiliser des client ID uniques ; sur ConnectMQ, utiliser l'ID attribué |
| L'hôte traite le passage de seq de 255 à 0 comme un trou | Rebirth tous les 256 messages | Corriger la logique de détection de trous de l'hôte |
| Plusieurs hôtes demandent chacun des rebirths | Rebirth à chaque redémarrage d'un hôte | Limiter les hôtes autorisés à envoyer des NCMD |
| Le nœud publie des alias absents du birth | Rebirth après chaque message de données | Corriger la configuration des alias du nœud |
| Limites de débit du broker atteintes pendant les births | Births tronqués, trou détecté, nouveau rebirth | Births plus petits ou offre avec des limites plus élevées |
La dernière ligne mérite attention sur une infrastructure partagée. Le serveur MQTT public gratuit autorise 10 messages par seconde et par client et 64 Ko par message, et les offres Serverless ont leurs propres limites de taille de message. Un nœud avec des milliers de métriques peut produire un birth volumineux : vérifiez les tailles lorsque vous passez d'un simulateur à de vrais équipements.
Les hôtes doivent aussi limiter le rythme de leurs propres demandes. Une règle simple : au plus un rebirth en attente par nœud, libéré à l'arrivée du NBIRTH, avec un backoff si le birth n'arrive jamais.
Checklist de prévention
- Edge node ID uniques par groupe et client ID MQTT uniques par connexion.
- Births toujours publiés avant les données, avec chaque métrique et chaque alias déclarés.
- seq remis à 0 à chaque NBIRTH ; bdSeq inchangé lors d'un rebirth.
- Détection de trous côté hôte qui gère le passage de 255 à 0.
- Un seul hôte désigné autorisé à envoyer des commandes en production.
- Taille des births vérifiée par rapport aux limites du broker.
Garder un transport fiable
La plupart des rebirths sont le symptôme d'un problème en amont : connexions coupées, ID dupliqués ou redémarrage d'un hôte. Un broker stable réduit la première catégorie. Un broker MQTT managé ou un broker MQTT dans le cloud vous décharge des mises à jour, des certificats et de la surveillance. Pour une vue plus large de Sparkplug dans les architectures d'usine, lisez le guide de l'IoT industriel avec MQTT.
Démarrer avec ConnectMQ
Créez un broker Serverless gratuit sur app.connectmq.com, sans carte bancaire. Connectez vos edge nodes et votre hôte, déclenchez un rebirth avec le script ci-dessus, et inspectez les births décodés dans l'explorateur de topics de ConnectMQ.
Questions fréquentes
Un rebirth Sparkplug déconnecte-t-il l'edge node ?
Non. Le nœud reste connecté et republie ses births sur la même session MQTT. C'est pourquoi le bdSeq ne change pas lors d'un rebirth.
Puis-je demander un rebirth pour un seul device ?
Non. La commande de rebirth cible l'edge node, qui republie alors son NBIRTH et un DBIRTH pour chaque device connecté.
Pourquoi mon hôte demande-t-il sans cesse des rebirths ?
Les causes les plus fréquentes sont des edge node ID dupliqués, des alias non déclarés dans les births, ou une logique d'hôte qui traite le passage normal de seq de 255 à 0 comme un trou.
Faut-il publier les births en retained pour éviter les rebirths ?
Non. Les births Sparkplug ne sont jamais retained. Un hôte qui démarre plus tard demande un rebirth afin d'obtenir toujours les valeurs actuelles.
