Downloading events from TSI is currently limited to 10000 events. This is probably because the query API is limited to 10000 events per query. Please consider increasing this limit.

For C# users, a NuGet package should be made available for working with the TSI Query API.

There is some code already here: https://github.com/Azure-Samples/Azure-Time-Series-Insights/tree/master/csharp-tsi-preview-sample/DataPlaneClient/Generated

It could be greate to be able to retrieve via API markers that analysts have spotted using Azure TSI, in order to persist and use those markers elsewhere.

Currently, only 20 concurrent connections are allowed which limits usage of the API heavily. Would be great if this was increased to a larger amount per environment.

It is currently not possible to do "group by" queries in TSI Gen 2 although it was possible in Gen 1 (https://docs.microsoft.com/en-us/rest/api/time-series-insights/gen1-query-api#get-environment-aggregates-api).

This seemed to be on the roadmap (fleet queries) but it should be proritized to allow migration between Gen1 and Gen2.

Cf. Q&A https://docs.microsoft.com/en-us/answers/questions/86928/how-to-group-events-by-an-event-variableproperty-i.html?childToView=90552#answer-90552

You can get the monthOfYear and the dayOfMonth but not the dayOfWeek. For our requirements it would be very helpful to have this possibility.

Example
We need only the days from monday to friday, within a daterange greater than x months.

We have a requirement to aggregate data using MODE function ( returns the most occurring value from the given time range. Does Azure TSI supports this? Please suggest.

The timestamp is an important factor in the Azure Time Series Insights. But there is no proper documentation regarding the format, the best practices to send timestamp in UTC (or in any other format) from the IoT device. It will be extremely helpful if there is proper documentation for this scenario.

When aggregating data in TSI, you must provide an interval and a search span.

Sometimes the intervals start before the search span instead of at the specified "from" time. This also results in inconsistent number of intervals being returned.

e.g.

"aggregateSeries": {

    "interval": "P1M",

    "searchSpan": {

        "from": "2020-11-01T00:00:00Z",

        "to": "2020-12-31T23:59:59.999Z"

    }, 

   ....

}

TSI returned 3 intervals with timestamps:

- "2020-10-03T00:00:00Z"
- "2020-11-02T00:00:00Z"
- "2020-12-02T00:00:00Z"

We expect 2 intervals with timestamps:
- "2020-11-01T00:00:00Z"
- "2020-12-01T00:00:00Z"
| |