MQTT Publisher Down, Change Data Quality in Comm Server

This is an interesting quirk from the indirect nature of MQTT, which makes it important to be able to track not only individual data points but also the state of the publisher. In order to do this at scale and without significant customization and integration work, one would ideally use a standard and that's where Sparkplug helps us.

Our MQTT drivers support Sparkplug both as publishers and consumers, which makes interoperatbity via MQTT a lot more convenient. Sparkplug includes a standardized approach to management of the state of devices and publishers which allows consumers like SCADA systems to track (and indicate) if the current data is live and can be trusted or if the device currently is offline and the last known value may not by a correct representation of the current state.

This is an interesting quirk from the indirect nature of MQTT, which makes it important to be able to track not only individual data points but also the state of the publisher. In order to do this at scale and without significant customization and integration work, one would ideally use a standard and that's where Sparkplug helps us.

Our MQTT drivers support Sparkplug both as publishers and consumers, which makes interoperatbity via MQTT a lot more convenient. Sparkplug includes a standardized approach to management of the state of devices and publishers which allows consumers like SCADA systems to track (and indicate) if the current data is live and can be trusted or if the device currently is offline and the last known value may not by a correct representation of the current state.

Thank you, Rickard, for answering the question very quickly. As I do understand your suggestion with the adoption of Sparkplug B specification, I still think that for the Systems and Devices that don't support Sparkplug B spec we need a solution. A feasible way to deal with this would be an Enhancement in our existing MQTT Driver. The enhancement would lead to users configure & monitor the "Last Will" topic & message at each publisher level. Once the data received at Last Will Topic corroborates to something suggesting publisher offline, this could then affect MQTT Driver marking all the items subscribed with bad quality. In my honest opinion this solution, if implemented, would be more inclusive and could help in implementing communication for publishers that are not yet Sparkplug ready. What are your thoughts on this, and would you agree if I carry on getting this created via the right channels?