This was discussed briefly by mail earlier, so I'll post a summary of that discussion here as well.

We initially enquired about the the possibility for Canary to automatically store SparkplugB NCMD/DCMD values. This would be valuable for us as we will publish commands to devices which they will in turn act upon. As it is we cannot verify what commands was sent and if the values published on the devices DDATA topic corresponds to the commands received. We got the following response from you (in italic):

The MQTT collector currently ignores NCMD and DCMD SparkplugB messages due to these targeting the individual nodes or devices. We could add a feature request for this, but I would like additional details regarding how the customer would like this to be modeled in the historian. One solution would be to create additional tags for each metric that is written to:

1. Controlling tag: MyMotorOutput digital output
2. When a DCMD is sent to turn MyMotorOutput = On, the MQTT collector would create (if it doesn’t already exist) a MyMotorOutput_WriteRequest tag and log the command request as a Boolean true under this tag

This solution would be what we're looking for. We in turn sent some feedback on the proposed solution:

• Consider if the suffix of the CMD tags should be customizable by the Canary user (change _WriteRequest to something else), either globally or a per subscription basis.
• The functionality for storing CMD should be optional, as it would create additional tags (higher subscription tier, performance, etc?). Perhaps it could be enabled with a checkbox in the MQTT Collector - Configuration - Subscription
• Not all tags will necessarily receive CMD messages, so it would be practical to create the Write_Request tags only at the point where a CMD message for a topic is first encountered.