Closed pietercardoen closed 2 years ago
If you reuse the bdSeq in the new rebirth request, at least ignition will keep on asking the rebirth command again and again. It expects another bdSeq.
What I do is reconnect, so I can send another last will. Not optimal, but at least Ignition will accept that.
On the other hand, adding new metrics is a pain in the ass and you should reconnect again, which is also a bad thing. I had to avoid Node metrics and go always with devices.
Ignition will accept another NBIRTH with the same bdSeq repeated. It only complains and requests another rebirth if the sequence number doesn't reset to 0. (bdSeq
and sequence
are two separate counters.)
However, you are correct about adding/removing metrics on the node level being problematic. Our implementation handles this by aborting the MQTT connection (which triggers the LWT NDEATH message) and reconnecting with a new bdSeq and the updated metric list. Our state machine already handled reconnecting on accidental disconnects, so we just create one intentionally.
Oh that's true! In the end it was the seq not resetting! My bad.
The only problem I see here is adding new metrics, and that the last will not having the same bdSeq if you don't reconnect and reset the last will. We also reconnect and it works as expected, just that the spec don't states this on the NBIRTH
section and could lead to an error.
I'll add a non-normative statement to clarify this in chapter 6
Dear
The specification states that: "The NDEATH message MUST include the same bdSeq number value that will be used in the associated NBIRTH message. This is used by Host Applications to correlate the NDEATH messages with a previously received NBIRTH message."
If you have a node which transmits a new BIRTH message while being alive:
then this node needs to reuse the bdSeq value. Only when the node had been disconnected resulting in an NDEATH message being transmitted, then the bdSeq value may be incremented.
Is this valid?