Currently, if you'd add a new sensor, for instance a 'Gas' sensor, we'd like to provide the following types:
Type: Manufacturer
Data type: Gas
Data sub type: Delivery
Data unit type: CubicMeterGas

However, the Data sub type has to be named 'DeliveryGas'. Even though we'd also like an Energy sensor with:
Type: Manufacturer
Data type: Energy
Data sub type: Delivery
Data unit type: KilowattHourEnergy

Now we have to define two separate sub types. If this is by design, let us know :)

Please add support for providing parameters for a Time Series Insights instance to which the Digital Twin resource can export all of its historical device data.

Current Space graph model of digital twin does not store historical information, such as sensor data. Model should have capability to define the store and attached to Sensor(s) and other model

Since a max node limit now exists on API GET calls, it would be helpful to have support for the ODATA $count feature.

When we specify a min and/or max value for creating a property key of type 'DateTime', we get an error stating that the min/max is invalid.

According to the doc, ISO8601 datetimes should be used, but:
- DateTime.ToString("o") gives a value that is too long (more than 20 chars, due to milliseconds);
- A string like "2000-01-01T00:00:00Z" is not accepted for instance;
- Tried with epoch notation, no luck either;

Do you have an example of a proper value? Could the documentation be updated to show such example? Or if it is a bug, then...

Thanks!

Space graph - Current Schema support, parent can have multiple children, However, we also need Schema to support child to have multiple parents as graph

After deleting my Digital Twins instance and deploying one with the same name a few minutes later I can't make any requests to the instance without the following error:

{
"error": {
"code": "500.600.999.999",
"message": "The underlying provider failed on Open.",
"innererror": {
"code": "500.600.999.999",
"message": "Login failed for user 'ManagementApi'."
}
}
}

This occurs on a GET request to
https://<instance-name>.westeurope.azuresmartspaces.net/management/api/v1.0/devices

Hello,

I recently moved a device from one spaceId to another via API call from Postman. To my surprise, the sensors attached to that device were still assigned to the previous spaceId. But, in the Azure Digital Twins Graph Viewer, they were properly displayed. Is this a bug in the API or is it a desired behaviour?

Kind regards,
Tudor Mazilu

It save a lot of time if there was a downloadable Postman collection with the API calls already defined (as with Swagger). It is simple to export/import a collection and environments can be used to ensure that credentials are kept separate.

It would be really helpful to be able to search for values within the content of the Digital Twins, e.g. searching in the names, properties, keys and attachments of the nodes within the Azure Twin tree.

How do you deal with conflictig permissions in Role defintions?

Is it a union of all permissions or intersection?

Role assignment API - how do I obtain object ID for a service principal/user? Is there some API which retrieves object Id given upn or name?

We are looking to create a digital twin based on the key asset attributes after it has undergone post processing from a device and is on an enterprise system. Rather that extract all the data continuously “Push” we would like to perform a pull on the data as required so that it is performed in a method that can substantiate the Digital twin when it is called upon “Pull” rather than continuous?

The user is able to create a backup of ADT data and restore it using by ADT API. It's possible to backup one subscription and restore data in other empty subscription

it should be possible to create a device configuration with device twin properties containing certain tags

Will Digital Twins support MSAL tokens? (i.e. Azure AD 2.0)

The paging for Devices is broken: the pagination is applied BEFORE the query filter, so unless your desired results are in the "$top" X items, you won't get them.