MQTT Last Will Placeholders to support Eclipse Sparkplug

[pedro-nicolau-carvalho]

Hello,

I'm trying to integrate Eclipse Ditto with Eclipse Sparkplug, and I've been mostly successful in all the message types and flows:

• Javascript Payload mappers to decode protobuf messages
• Combining modify and merge protocol topics for birth or data messages
• Sending DCMD/NCMD commands using eclipse messages
• Conditional updates when sequence numbers are out of order (update only if incoming seq number is bigger that what is twin persisted)
• When a host application (a sparkplug host application is equivalent to an eclipse ditto connection), is started, a message to mqtt is sent declaring it is online, and when it closes, it sends a message informing it is closing. I've used connection announcements for this purpose. The payload of this message is the following:

{
   "online": boolean
   "timestamp: milis since epoc - this timestamp is always the timestamp of when the connection is started, so a correlation betwen online/offline states can be made
}

Only one small detail is missing to support Eclipse Sparkplug in this last point. When eclipse ditto ungracefully disconnects from the MQTT broker, a last will message should be sent with the status and the timestamp. Since the last will connection configuration is static, the timestamp cannot be rightfully set.

Does it make sense for Eclipse Ditto to support placeholders in the last will message? Also, the issue still remains that the timestamp should be the same as the last connection opened announcement. Could a connection-specific placeholder exist which holds the value of when the connection opens or closes?

It seems to me at least that an integration between these two projects is fruitful since they both act under the same domain and under the Eclipse umbrella.

Thank you.

[thjaeckle]

Hi.

Very interesting, would be nice to read about a finished Sparkplug integration at some point.

Hm, if I understood Mqtt last will correctly, providing a dynamic payload to it won't work. I understood that a client defines this last will message eg after first connection. Then, when the broker detects that the client is gone, it will publish the (previously defined) last will message to subscribers. So Ditto has no chance to provide a dynamic payload.

I'm not an mqtt expert, but maybe the last will message could be refreshed/updated periodically, eg each minute? This could be something Ditto could handle.

[pedro-nicolau-carvalho]

Hello @thjaeckle,

Yes you're right, the will message is sent along with the connect packet, which I assume happens before the ConnectionOpennedAnnouncement eclipse ditto message. So I guess that won't work...

I guess a really dirty workaround (😄) would be to use an http push connection that listens to closed connection announcements and updates the last will message and javascript mappers with new timestamps. Have you seen approaches like these, that use http push connections that update ditto entities? Any opinions?

Thank you for the help!

[thjaeckle]

@pedro-nicolau-carvalho sorry for the late reply

Have you seen approaches like these, that use http push connections that update ditto entities? Any opinions?

No, I did not see approaches like there - I would also not suggest to build such a "recursion" (Ditto invoking Ditto :D). A lot things could go wrong here I assume ..