Sparkplug B-Knoten

Es gibt Knoten-Sets wie node-red-contrib-sparkplug-b oder node-red-contrib-mqtt-sparkplug-plus. Sie laufen auf demselben MQTT-Broker, verarbeiten aber automatisch das Sparkplug-B-Spezifikations Format (spBv1.0/... Topic + Protobuf-Payload + Birth/Death-Sequenz).

Der Gateway hat den Sparkplug-B-Versand bereits als eigene Komponente implementiert (siehe advanced/sparkplug), wird aber in Node-RED verwendet, um Empfang/Überwachung oder Simulation externer Geräte zu erstellen.

Broker-Verbindungsinformationen für Boxen ab 2026.05+

• Broker: 127.0.0.1:1883 (HiveMQ, im selben Container)
• Username / Password: app.properties unter mqtt.server.user / mqtt.server.password — Bei Produktionsboxen generiert install.sh pro Box ein zufälliges Passwort (einsehbar unter /etc/kopens/credentials.txt). HiveMQ auth.properties wird vom Entrypoint bei jedem Start automatisch mit app.properties synchronisiert.
• Group ID / Edge Node ID: Wenn leer, werden automatisch edge.site_id / edge.id verwendet (z. B. SITE_00001 / EDGE_00303)
• Kompatibel mit 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	Eindeutige Kennung eines Gateways/Geräts
Device ID	Einzelne Geräte darunter — optional
Metric	Entspricht einem einzelnen Tag (Metrik in Sparkplug)
Birth (NBIRTH/DBIRTH)	Der Knoten/das Gerät veröffentlicht die "vollständige Definition" seiner Metriken auf einmal — Abonnenten werden sofort synchronisiert
Data (NDATA/DDATA)	Normale Wertänderungen — nur geänderte Metriken (Delta)
Death (NDEATH/DDEATH)	Eine als LWT registrierte Nachricht, die signalisiert, dass das Gerät aktiv ist — wird bei Verbindungsabbruch automatisch veröffentlicht

---

2. Grundlegender Veröffentlichungsfluss (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()
    }]
  }
};

sparkplug device out-Einstellungen (oder mqtt-sparkplug device):

Element	Wert (Beispiel)
Group ID	Plant1
Edge Node ID	EDGE_00303
Device ID	(weggelassen werden kann — direkt auf Edge-Ebene veröffentlichen)
Broker	(Wiederverwendung des zuvor unter MQTT erstellten Brokers)

Birth/Death werden vom Knoten automatisch behandelt — NBIRTH wird beim Deploy-Zeitpunkt veröffentlicht, und bei einem Stopp/Absturz des Knotens wird NDEATH als LWT veröffentlicht.

---

3. Empfangsfluss (Cloud / Überwachung → Monitoring der Edge-Knoten)

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

sparkplug client in Ein Knoten abonniert das gesamte spBv1.0/Plant1/...-Topic, parst automatisch die Nachrichtentypen (NBIRTH/NDATA/NDEATH/DBIRTH/...) und organisiert sie unter msg.command / msg.payload.metrics.

Verzweigungsbeispiel (switch):

Bedingung	Verarbeitung
msg.command === 'NBIRTH'	Gerätemetadaten DB-Synchronisierung — Metrikkatalog aktualisieren
msg.command === 'NDATA'	Zeitreihen speichern in InfluxDB / Cassandra usw.
msg.command === 'NDEATH'	Benachrichtigung — "EDGE_00303 getrennt"

---

4. Hinweise zur Sparkplug-Nutzung

• Metriknamen müssen in BIRTH und DATA übereinstimmen (bei Namensänderung greift es erst ab dem nächsten BIRTH).
• Veröffentlichen mehrere Clients gleichzeitig mit derselben Group/Edge Node ID, kollidiert die Seq-Nummer, und die Daten werden als Stale behandelt — Edge-ID muss pro Gateway eindeutig sein.
• Wenn auf Cloud-Seite Rebirth Request gesendet wird, muss NBIRTH erneut veröffentlicht werden — die Bibliothek übernimmt dies automatisch, aber bei manueller Implementierung muss dies realisiert werden.

---

5. Nächste Schritte

• IIoT-Beispiel — Sparkplug B senden
• Gateway-eigene Sparkplug-Komponente: Sparkplug B (Erweitert)