Provide API to read device related information for example, device ID, Remaining storage info
We need device specific API to get information about device, it could be a device ID, remaining storage details after application installed.
Could you provide some scenarios where you need the device-ID?
Mark Scott commented
I am currently working on a project that needs some sort of immutable device identifier which is available programatically. Client doesn't want to use the 128 character Device ID. We are in search of some way to find an immutable "device identifier". The MAC address would be sufficient; however, neither the MAC nor the Device ID are accessible via an API. We have a similar scenario to what Martijn mentioned, in that we need to set this up during the provisioning process.
Martijn Stolk commented
We'd want some sort of ID that we can store during provisioning (i.e. during manufacturing) that we can also access from the application afterwards. Both Device-ID and WIFI mac-address can be read by tools during/after provisioning, but are both unknown to the application. In our case it doesn't actually have to be the Device-ID, but it needs to be something fixed to the device (and very close to unique).
The Device-ID would be best, since it's guaranteed unique and we could "dumb it down" according to use-cases. It's known during the provisioning process and can be stored in an ERP system, i.e. to match it with serial numbers put on any enclosures.
We considered a workaround where we store a randomly generated string in Mutable Storage on the device, but found it to not be a good solution, since it's application-specific and could be wiped. Besides that, there needs to be internet connectivity first before that generated string is even known in the cloud and thus cannot be used for identification purposes before that point.
A few scenario's in which to use it:
1. We have an existing JSON protocol we'd like to adhere to. This protocol dictates the message contains the 'originator'. For messages regarding the controller itself (i.e. status notifications or its own telemetry) the originator is the device-id itself. However, when the controller is connected via (i.e. modbus) to a non-connected device, it reads that device's serial number and uses that as 'originator' and forwards its telemetry.
2. Imagine a scenario where a device is installed at a customer, but requires configuration via a mobile app using bluetooth before it can connect to wifi and communicate. It's a headless device and thus cannot show a pincode for pairing purposes. We do want to use a PIN for security purposes though. We'd use a math calculation based on the device id to reach a fixed bluetooth pincode. A webapplication can calculate the PIN based on Device-ID and/or WIFI mac that was recorded when the device was provisioned (i.e. stored in ERP). The application itself comes to the same PIN since it can do the same calculation based on Device-ID.