Sparkplug | This project has been moved to here : https : //github | Game Engine library

You are right in assuming that Hono's standard MQTT adapter supports the telemetry and event topics for publishing data only. Consequently, Hono does not work out-of-the-box with the Sparkplug topics. Given that Sparkplug is also an Eclipse standardization effort, it might be worth considering adding native support for Sparkplug to the standard MQTT adapter. Otherwise, implementing a dedicated Sparkplug adapter might be an option as well. There are no detailed instructions for how to implement a protocol adapter. However, the MQTT adapter in particular can serve as a blue print for doing so. It is already split up into a (generic) base class which provides means to forward messages from devices to downstream applications and vice versa. The Kura adapter simply extends this base MQTT adapter class and implements a different Kura-specific topic scheme on top of it. So, in general, this might be a good approach to take for a Sparkplug adapter as well.

From the sparkplug spec:

A critical aspect for MQTT in a real-time SCADA/IIoT application is making sure that the primary MQTT SCADA/IIoT Host Node can know the “STATE” of any EoN node in the infrastructure within the MQTT Keep Alive period (refer to section 3.1.2.10 in the MQTT Specification). To implement the state a known Will Topic and Will Message is defined and specified. The Will Topic and Will Message registered in the MQTT CONNECT session establishment, collectively make up what we are calling the Death Certificate. Note that the delivery of the Death Certificate upon any MQTT client going offline unexpectedly is part of the MQTT protocol specification, not part of this Sparkplug™ specification (refer to section 3.1 CONNECT in the MQTT Specification for further details on how an MQTT Session is established and maintained).

So, in MQTT terms, NDEATH is a 'Will' which, as mentioned above, is defined in section 3.1 of the the MQTT spec:

If the Will Flag is set to 1 this indicates that, if the Connect request is accepted, a Will Message MUST be stored on the Server and associated with the Network Connection. The Will Message MUST be published when the Network Connection is subsequently closed unless the Will Message has been deleted by the Server on receipt of a DISCONNECT Packet

In summary NDEATH creates a 'Will' which the MQTT broker publishes if it looses the connection with the publisher (unless a DISCONNECT is received first).

When you establish a bridge this relays messages published on whatever topic(s) the bridge is configured to relay. The bridge only communicates published messages; not information about what clients are connected (or any 'Will' they may have set) so when the bridged connection goes down subscribers will not receive the NDEATH.

Monitoring the connection status of bridges is not something covered by the spec so options vary from broker to broker. For example Mosquitto can (using a 'Will' on the bridge connection) provide a notification when the connection goes down (see notifications in mosquitto.conf). This may provide you with some options to get the information you need.

Excellent question. I've been meaning to address this area for ages. The answer is a simple "no, I haven't even looked at it". I'd be happy to do so, but reality is that I have limited time and need to prioritise effort on features people are asking for. "Any" is something I've heard basically no noise about, until today. If you have a genuine use case for it, we can probably look. GitHub or email may be a better place to explore it, unless you're happy to handle it simply via byte[] and your own code.

I think you can solve your problem using Where to filter the elements you want, then Select to only keep the Keys.