Device Control and/or using MQTT "Device Control/Scanner Interval Ms"

MQTT/SparkplugB & OPC UA
1

I’m reading through the MQTT output from a Groov Rio. The MQTT device was configured with a “Scan Time (ms)” of 1000.

In the DBIRTH message, I see a “Device Control/Scanner Interval Ms” Metric. I see also that the Rio has subscribed to NCMD and DCMD topics for itself.

Having read the specification at GitHub - eclipse-sparkplug/sparkplug: Sparkplug, I saw a mention of “Device Control” as an option. The specification uses an example named Device Control/Rebirth, “Used by backend application(s) to request a new DBIRTH from a device.”

Does the Rio implement device control of any sort? Could I set the Scanner Interval Ms by publishing to a DCMD topic from the primary application (somehow)?

2

I posed a question about Device Control here:

I was looking for precisely the feature used in a Sparkplug spec example, namely the “Device Control/Rebirth” idea that would allow a backend application to request a copy of the DBIRTH message to be republished. However, setting RETAIN for the DBIRTH messages would also do.

The reason is that I want to extract metrics from the MQTT/Sparkplug system without impacting the primary host application. If my metrics copier starts after the Rio does, it’ll receive DDATA payloads with metrics that have aliases and not names. I need a copy of the DBIRTH payload to “rehydrate” those metrics for export. Is there anything else I could do?

3

Hi Josh,
Hope you don’t mind, but I flattened the two posts into one, they seemed directly related to each other.

Yes. That tag is writable, so you can send a SparkPlug payload to that topic and change the scanner interval. Note, DCMDs are issued on DDATA tags and NCMDs are issued on NDATA tags. Don’t get them mixed up.

The rebirth request comes from the host application, when correctly formatted any groov device will respond with a rebirth message. Our client current does not have a ‘button’ or API call to sort of self emulate a host application sending that request. You could brute force it by stopping and then starting the MQTT client via groov Manage.
Of course the right way to go about it is to visit the Tahu GitHub page and take a look at the Sparkplug Developer Docs. You should find an example of how to craft the boolean required to ask the client to issue the rebirth.

1 Like
4

Yes. That tag is writable, so you can send a SparkPlug payload to that topic and change the scanner interval.

Cool. I looked over the Tahu examples and gave it a try by sending a NCMD with the metric to write. Not clear yet what’s happening, but I somehow triggered (from the MQTT logs).

ERROR|2022-03-02 07:35:13,972|MqttHub.java|445|messagearrived(), exception reported: null
java.lang.NullPointerException
	at com.Opto22.OptoEdgeNode.MqttHub.messageArrived(MqttHub.java:413)
	at org.eclipse.paho.client.mqttv3.internal.CommsCallback.deliverMessage(CommsCallback.java:519)
	at org.eclipse.paho.client.mqttv3.internal.CommsCallback.handleMessage(CommsCallback.java:417)
	at org.eclipse.paho.client.mqttv3.internal.CommsCallback.run(CommsCallback.java:214)
	at java.lang.Thread.run(Thread.java:748)

As for “Device Control/Rebirth”, it sounds like this is actually standard (not just an example, which the Sparkplug specs describe it as). The reason I wouldn’t expect this to work for the Groov Rio is that the NBIRTH payload does not include a “Device Control/Rebirth” metric. The Sparkplug specification 7.7 states:

The DCMD topic provides the Topic Namespace used to publish metrics to any connected device. This means sending a new metric value to an associated metric included in the DBIRTH metric list

Since I don’t see “Device Control/Rebirth” in the DBIRTH payload, I wouldn’t expect it to be supported. This investigation led to a couple of other issues with my MQTT broker, so this isn’t fully explained yet. Thanks!

5

Above I’m referring to Sparkplug specification section 16.2, which writes

The DBIRTH message can also include optional ‘Device Control’ payload components. These are used by a backend application to control aspects of a device. The following are examples of Device Control metrics.
• Metric name: ‘Device Control/Reboot’
o Used by backend application(s) to reboot a device.
• Metric name: ‘Device Control/Rebirth’
o Used by backend application(s) to request a new DBIRTH from a device.
• Metric name: ‘Device Control/Scan rate’
o Used by backed application(s) to modify a poll rate on a device.

Emphasis on “examples”. My interpretation was that “Device Control/Rebirth” is not a special, standard convention, but it seems to be singled out in the Paho examples so maybe it’s intended to be special?

6

On further investigation, Groov Rio does not support a “Device Control/Rebirth” metric, but it does support a “Node Control/Rebirth” NCMD metric, and when the node is reborn the device will also issue a rebirth, so I’ve succeeded to make this work.

That said, you should receive the report above of a null pointer exception when the Rio processes any DCMD metrics as real. I am not able to control the “Device Control/Scanner Interval Ms” metric and the null pointer exception is very easy to reproduce.

2 Likes