Ciao Marcin,
you have done one question with one answer that it's not simple at all...
this is one of most complicated thing that I could explain for our system...
on our Application we use the DTMI for 3 different purpose...
1) every single demo inside the ST BLE Sensor application could be customized using the DTMI
For this topic take a look on the BLESensorPnPL project on FP-SNS-STBOX1
that you could find here:
https://www.st.com/en/embedded-software/fp-sns-stbox1.html
or:
https://github.com/STMicroelectronics/fp-sns-stbox1
for example you could take a look on Projects/STWIN.box/Applications/BLESensorsPnPL
in this application we use the DTMI for allowing the possibility to customize the Plot Demo and the Environmental demo
This application uses like dtmi the following one:
https://github.com/STMicroelectronics/appconfig/blob/release/dtmi/appconfig/steval_stwinbx1/FP_SNS_STBOX1_BLESensorPnPL-1.expanded.json
take a look on "applications_stblesensor" component
we had also a python script that reading this DTMI is able to create the skeleton for your code creating the components implementation
(take a look on the STWIN.box/Applications/BLESensorsPnPL/PnPL directory)
and you need only to fill the callbacks present on App_model.c file:
Projects/STWIN.box/Applications/BLESensorsPnPL/Src/App_model.c
2) some of our demos are completely dynamic and created starting from a DTMI
and without this DTMI... that demo are locked and cannot be used
for example, you could take a look on HSDataLog2 or FP-ATR-BLE1 package:
https://www.st.com/en/embedded-software/fp-sns-datalog2.html
with dtmi:
https://github.com/STMicroelectronics/appconfig/blob/release/dtmi/appconfig/steval_stwinbx1/FP_SNS_DATALOG2_Datalog2-5.expanded.json
3) we use the DTMI also for decoding what will will receive on the Raw PnPL controlled BLE feature
for example you could have one idea taking a look on FP-IND-DATALOGMC package
https://www.st.com/en/embedded-software/fp-ind-datalogmc.html
We send on this characteristic some Slow Telemetries produced by the Motor... and what we will receive on it are explained on the related DTMI:
https://github.com/STMicroelectronics/appconfig/blob/release/dtmi/appconfig/steval_stwinbx1/FP_IND_DATALOGMC_DatalogMC-1.expanded.json
(Take a look to the st_ble_stream)
so here you could find some examples of these DTMI and how we use them
But it's not enough...
You need not only to create a custom DTMI entry... but you need also to create a custom FW db entry for your fw, in order that the ST BLE Sensor application, reading your boardID and FwId during the BLE Advertising will be able to recognize you and take the right DTMI that you want to use...
for taking one example of this custom Fw db entry...
you could take the Projects/STWIN.box/Applications/BLEGPEx example always on FP-SNS-STBOX1 package
That contains one example of this custom Fw db entry
https://github.com/STMicroelectronics/fp-sns-stbox1/blob/main/Projects/STWIN.box/Applications/BLEGPEx/STWINBoxBLEGPEx.json
in this file...
At the beginning there are written the board ID and the Fw ID that you must also use on ble advertise
"ble_dev_id": "0x0E",
"ble_fw_id": "0xFF",
the ble_dev_id is the device id for your board...
ble_fw_id = 0xFF is mandatory... we accept only custom fw db entry that have this fw id = 0xFF
inside this .json you must write that you want to use your custom DTMI ...
so you must add one field to it
"dtmi": "dtmi:appconfig:xxxxxxx;1",
in this way this dtmi don't point to a real dtmi present here:
https://github.com/STMicroelectronics/appconfig/tree/release/dtmi/appconfig and the application will use the one that you have load with the custom DTMI entry...
you could take a look on example of all our fw db entries here:
https://github.com/STMicroelectronics/appconfig/blob/release/bluestsdkv2/catalog.json
It's not simple at all...
good luck
Ciao
Luca
