Sparkplug B Nodes im Detail nutzen

Es gibt Node-Sets wie node-red-contrib-sparkplug-b oder node-red-contrib-mqtt-sparkplug-plus. Sie arbeiten auf demselben MQTT-Broker, verarbeiten aber die Sparkplug-B-Spezifikation (spBv1.0/... Topic + protobuf Payload + Birth/Death-Sequenz) automatisch.

Das Gateway implementiert das Sparkplug-B-Senden bereits als eigene Komponente (siehe advanced/sparkplug), diese Nodes verwenden Sie jedoch, wenn Sie in Node-RED einen Empfang/eine Überwachung oder eine Nachbildung externer Geräte aufbauen.

Broker-Verbindungsdaten der 2026.05+ Box

• Broker: 127.0.0.1:1883 (HiveMQ, im selben Container)
• Username / Password: app.properties aus mqtt.server.user / mqtt.server.password — bei Serienboxen erzeugt install.sh pro Box einen Zufallswert (nachzusehen in /etc/kopens/credentials.txt). HiveMQ auth.properties wird vom Entrypoint bei jedem Start automatisch mit app.properties synchronisiert.
• Group ID / Edge Node ID: bleibt das Feld leer, werden automatisch edge.site_id / edge.id verwendet (z. B. SITE_00001 / EDGE_00303)
• Kompatibel zur Sparkplug 3.0.0 spec (NBIRTH seq=0, DDEATH/NDEATH bdSeq, Properties, alias-Option)

---

1. Kernkonzepte

Begriff	Bedeutung
Group ID	Gruppierung (z. B. Plant1)
Edge Node ID	Kennung eines Gateways/Geräts
Device ID	Die einzelne Anlage darunter — optional
Metric	Entspricht einem Tag (Metrik in Sparkplug)
Birth (NBIRTH/DBIRTH)	Node/Device publiziert die „vollständige Definition“ seiner Metriken auf einmal — Subscriber synchronisieren sich sofort
Data (NDATA/DDATA)	Normale Wertänderung — nur die geänderten Metriken (Delta)
Death (NDEATH/DDEATH)	Als LWT registrierte Nachricht, die die Lebendigkeit anzeigt — wird bei Abbruch automatisch publiziert

---

2. Grundlegender Publish-Ablauf (Edge → Cloud)

inject (5s) ─▶ 태그값 읽기 ─▶ function (Sparkplug 메트릭 변환) ─▶ sparkplug device out

function:

return {
  payload: {
    metrics: [{
      name:  msg.payload.tag_id,           // "TAG_TEST_00042"
      type:  'Int32',
      value: parseInt(msg.payload.value, 10),
      timestamp: Date.now()
    }]
  }
};

Konfiguration von sparkplug device out (oder mqtt-sparkplug device):

Position	Wert (Beispiel)
Group ID	Plant1
Edge Node ID	EDGE_00303
Device ID	(kann entfallen — Publish direkt auf Edge-Ebene)
Broker	(der oben unter MQTT angelegte Broker wird unverändert weiterverwendet)

Birth/Death übernimmt der Node selbst — beim Deploy wird NBIRTH publiziert, bei Stop/Crash des Nodes wird NDEATH per LWT gesendet.

---

3. Empfangsablauf (Cloud / Leitstand → Monitoring der Edges)

sparkplug client in (Group=Plant1) ─▶ switch (msg.topic 으로 분기) ─▶ ...

Ein einzelner sparkplug client in-Node abonniert das gesamte Topic spBv1.0/Plant1/..., parst den Nachrichtentyp (NBIRTH/NDATA/NDEATH/DBIRTH/...) automatisch und stellt ihn aufbereitet in msg.command / msg.payload.metrics bereit.

Verzweigungsbeispiel (switch):

Bedingung	Verarbeitung
msg.command === 'NBIRTH'	DB-Abgleich der Gerätemetadaten — Metrik-Katalog aktualisieren
msg.command === 'NDATA'	Zeitreihe in InfluxDB / Cassandra usw. speichern
msg.command === 'NDEATH'	Benachrichtigung — „EDGE_00303 getrennt“

---

4. Hinweise zur Verwendung von Sparkplug

• Die Metriknamen müssen in BIRTH und DATA übereinstimmen (bei Namensänderung gilt sie erst ab dem nächsten BIRTH).
• Publizieren mehrere Clients gleichzeitig mit derselben Group/Edge Node ID, kollidiert die Seq Number und die Daten werden als Stale behandelt — die Edge ID muss pro Gateway eindeutig sein.
• Sendet die Cloud-Seite ein Rebirth Request, muss NBIRTH erneut publiziert werden — die Bibliothek erledigt das automatisch, bei Eigenimplementierung müssen Sie es selbst umsetzen.

---

5. Nächste Schritte

• IIoT-Beispiel — Sparkplug B senden
• Sparkplug-Komponente des Gateways selbst: Sparkplug B (Erweitert)