We have a mixed EoN environment using Ignition Distributor/Engine as the Broker/Consumer. Using NodeRed on one node with the node-red-contrib-sparkplug (node) - Node-RED flow. Generally works great. However, when testing with Trial Version of Ignition we noticed that when the Trial Expires and is Reset, the NodeRed flow goes from “Disconnected” to “Connected”, but the data in the MQTT Engine remains “Stale”. It is only after we redeploy the Flow in NodeRed, that the full communications is re-established and the data becomes Good Quality.
Does any one of the Gurus know why this may be happening and potential work around, so the EoN (NodeRed) can Robustly Reconnect after this event?
Thanks in advance to the forum members.
BTW: We tried manually initiating a DBIRTH in NodeRed, but this does not seem to re-establish Good Data Quality in the MQTT Engine.
It’s been a while since I’ve played with the Node Red client. My guess is that after MQTT Engine goes offline and reconnects, the client is not republishing the full BIRTH sequence which is required per Sparkplug rules.
Normally this is handled via a ‘primary host’ setting in the Sparkplug/MQTT client. But, I don’t think the Node Red client supports this yet. Pull Requests are always welcome in Tahu 
There are a couple of other potential options I can think of offhand:
- Make sure the Node Red client is publishing data often. If doing so, Engine (after coming back online) should see a DATA message and send a Rebirth request to bring the Edge Node back online.
- Script a ‘Rebirth’ Request at the Engine side to force a Rebirth after Engine comes back online.
Wes,
As it turned out, it was actually the MQTT Distributor ACL (Access Control Level) configuration that seems to be the issue. We will conduct more tests, but does the NodeRed implementation use the R STATE/[PrimaryHostID]? When we changed the ACL, the connection re-established and data was flowing (no need to redeploy flows in NodeRed).
We will continue testing, but I thought you should know about this discovery.