Um rebirth do Sparkplug é um comando que uma aplicação host envia a um edge node para fazê-lo republicar as suas mensagens NBIRTH e DBIRTH, de modo que o host possa reconstruir uma visão completa e atual daquele node. Neste guia você vai aprender quais situações pedem um rebirth, como enviar um manualmente, como um edge node correto responde e como diagnosticar o problema mais comum em campo: nodes que fazem rebirth sem parar.
O que um rebirth faz
Os consumidores Sparkplug dependem das mensagens de birth para três coisas: a lista de métricas, o mapeamento de aliases para nomes e tipos de dados e o valor atual de cada métrica. Se um host perde um birth ou perde o controle da sequência, o seu modelo do node fica incompleto. Um rebirth corrige isso sem derrubar a conexão MQTT.
O comando é uma mensagem NCMD em spBv1.0/{group}/NCMD/{edge_node} contendo uma métrica booleana chamada Node Control/Rebirth definida como true. O edge node responde publicando um novo NBIRTH com o seq zerado e o mesmo bdSeq da sessão atual, seguido de um DBIRTH para cada device. Não existe rebirth separado em nível de device; um rebirth do node sempre republica todos os seus devices.
Quando um host deve solicitar um rebirth
| Gatilho | Por que importa |
|---|---|
| O host inicia ou reconecta quando o node já está online | O host nunca viu os births originais |
| Lacuna no seq | Uma mensagem se perdeu; os valores e possivelmente as definições de métricas podem estar errados |
| Dados recebidos com um alias desconhecido | O host não consegue mapear o valor para uma métrica |
| Dados de um node ou device sem birth conhecido | O host não tem nenhuma definição de métrica |
| Métrica com um nome ausente no birth | A configuração do node mudou sem um novo birth |
| Operador pede uma atualização | Recuperação manual durante o comissionamento |
Aplicações host bem implementadas enviam essas solicitações automaticamente. Se você está escrevendo o seu próprio consumidor, implementar os três primeiros gatilhos cobre a maioria das situações reais.
Como o edge node deve responder
- Receber o NCMD e confirmar que a métrica
Node Control/Rebirthé true. - Zerar o seq.
- Publicar o NBIRTH com todas as métricas do node, seus valores atuais, o bdSeq atual e a métrica
Node Control/Rebirthde volta para false. - Publicar um DBIRTH para cada device conectado no momento.
- Retomar NDATA e DDATA com o seq continuando a partir dos births.
O bdSeq permanece o mesmo porque a sessão MQTT, e portanto o will NDEATH registrado, não mudou. Um node que incrementa o bdSeq no rebirth sem reconectar vai confundir os hosts que verificam o bdSeq quando um death chegar mais tarde. As regras completas dos certificados estão explicadas em certificados de birth e death do Sparkplug.
Envie um rebirth manualmente
Durante o comissionamento é útil disparar um rebirth você mesmo. Este script Python usa paho-mqtt 2.x e classes geradas a partir do arquivo sparkplug_b.proto do Eclipse Tahu (veja o nosso tutorial sobre como decodificar Sparkplug B em Python para o passo único de geração):
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}")
Execute-o contra um simulador no servidor MQTT público, por exemplo python rebirth.py demo-3f9a1c line1, enquanto acompanha o group:
mosquitto_sub -h broker.connectmq.com -p 1883 -i rebirth-watch-77d2 -v \
-t "spBv1.0/demo-3f9a1c/#"
Você deve ver o NCMD e, em instantes, um NBIRTH e um DBIRTH. Em um broker de produção, conecte pela porta 8883 com TLS e as suas credenciais do portal, e lembre-se de que apenas aplicações host autorizadas devem enviar comandos a equipamentos reais.
Fluxo de solução de problemas
Quando um host mostrar métricas desatualizadas ou ausentes, siga estes passos em ordem:
- O node está conectado? Verifique a conexão. No ConnectMQ, assine
$SYS/broker/connection/{clientId}/statepara o client ID do node ou consulte o portal. - O node publicou os births? Procure NBIRTH e DBIRTH nos topics dele. Se nenhum aparecer depois da conexão, ele pode estar esperando uma Primary Host Application cujo STATE não consegue ver.
- O node assina o NCMD? Envie um rebirth manual. Se nada acontecer, o node não está assinando
spBv1.0/{group}/NCMD/{node}ou não implementa rebirth. - Os births contêm todas as métricas? Compare o DBIRTH decodificado com as tags esperadas. Métricas ausentes são um problema de configuração do node, não de transporte.
- O seq é contínuo? Observe várias mensagens de dados depois do birth. Lacunas indicam perda de mensagens ou um segundo cliente usando o mesmo edge node ID.
- Os aliases são resolvidos? Todo alias em NDATA ou DDATA precisa aparecer no birth mais recente. Se não aparecer, o node está enviando aliases que nunca declarou.
- O host está processando os births corretamente? Se o broker mostra births corretos, mas o host continua exibindo dados desatualizados, o problema está do lado do host.
Ver os payloads decodificados torna os passos 2, 4, 5 e 6 muito mais rápidos. O ConnectMQ decodifica Sparkplug B no topic explorer do portal, então você consegue ler a lista de métricas de um birth, conferir os valores de seq e identificar aliases sem escrever um decodificador.
Tempestades de rebirth e como interrompê-las
Uma tempestade de rebirth é um loop em que um node faz rebirth continuamente, inundando o broker e o host com mensagens de birth. Causas típicas:
| Causa | Como reconhecer | Solução |
|---|---|---|
| Dois clientes com o mesmo edge node ID | Valores de seq intercalados, desconexões frequentes | Dê a cada node um ID único por group |
| Client ID duplicado | O node se desconecta sempre que outro cliente se conecta | Use client IDs únicos; no ConnectMQ use o ID emitido |
| O host trata a volta do seq de 255 para 0 como lacuna | Rebirth a cada 256 mensagens | Corrija a lógica de lacunas do host |
| Vários hosts solicitando rebirths | Rebirth sempre que qualquer host reinicia | Limite quais hosts podem enviar NCMD |
| O node publica aliases que não estão no birth | Rebirth após cada mensagem de dados | Corrija a configuração de aliases do node |
| Limites de taxa do broker atingidos durante os births | Births truncados, lacuna detectada, novo rebirth | Births menores ou um plano com limites mais altos |
A última linha merece atenção em infraestrutura compartilhada. O servidor MQTT público permite 10 mensagens por segundo por cliente e 64 KB por mensagem, e os planos Serverless têm os seus próprios limites de tamanho de mensagem. Um node com milhares de métricas pode gerar um birth grande, então verifique os tamanhos ao passar de um simulador para equipamentos reais.
Os hosts também devem limitar a taxa das próprias solicitações. Uma regra simples é no máximo um rebirth pendente por node, liberado quando o NBIRTH chega, com backoff se o birth nunca vier.
Checklist de prevenção
- Edge node IDs únicos por group e client IDs MQTT únicos por conexão.
- Births sempre publicados antes dos dados, com todas as métricas e aliases declarados.
- seq zerado em todo NBIRTH; bdSeq inalterado no rebirth.
- Detecção de lacunas no host que trate a volta de 255 para 0.
- Um único host designado com permissão para enviar comandos em produção.
- Tamanho dos births conferido em relação aos limites do broker.
Mantenha o transporte confiável
A maioria dos rebirths é sintoma de algo anterior: conexões que caem, IDs duplicados ou um host reiniciando. Um broker estável reduz a primeira categoria. Um broker MQTT gerenciado ou um broker MQTT na nuvem tira das suas mãos patches, certificados e monitoramento. Para o panorama mais amplo do Sparkplug em arquiteturas de planta, leia o guia de IoT Industrial com MQTT.
Comece com o ConnectMQ
Crie um broker Serverless gratuito em app.connectmq.com, sem cartão de crédito. Conecte os seus edge nodes e o host, dispare um rebirth com o script acima e inspecione os births decodificados no topic explorer do ConnectMQ.
Perguntas frequentes
Um rebirth do Sparkplug desconecta o edge node?
Não. O node continua conectado e republica os seus births na mesma sessão MQTT. É por isso que o bdSeq não muda durante um rebirth.
Posso solicitar um rebirth para um único device?
Não. O comando de rebirth é direcionado ao edge node, que então republica o seu NBIRTH e um DBIRTH para cada device conectado.
Por que o meu host continua solicitando rebirths?
As causas mais comuns são edge node IDs duplicados, aliases não declarados nos births ou uma lógica no host que trata a volta normal do seq de 255 para 0 como uma lacuna.
Os births devem ser retained para evitar rebirths?
Não. Os births do Sparkplug nunca são retained. Um host que inicia depois solicita um rebirth para sempre obter os valores atuais.
