Device DataSource Instance datapoint historical data using RestAPI v3

I’m successfully reaching the timeseries data from a different dataSource on the same device then using that data to calculate predictive metrics.  I still have to add a couple of calculations, but this is the basic goal I’m shooting for.

Need to optimize the code as well, as it’s currently several API calls happening for each device and I don’t want it to eat the whole TCP ephemeral stack.

Confirmed absent thorugh the support team

Is there a way to get the DeviceDatasourceID as a built in variable from the platform? 

Not that i’m aware.

Is there a way to get the DeviceDatasourceID as a built in variable from the platform?  That would save a ton of API overhead.  Then I can just grab the instances from that and get my historical data using the DDI’s properties.  I don’t find anything in the LM Docs that state this for use in dataSources, I do find them for alerts though.

I can get the deviceid and the instanceid, but not the datasourceid… from the restAPI, I can access the device and the dataSource, but not the instance… so I have to get the devicedatasource to get to the instance no matter how I slice it.  That adds an extra uneccesary API call that could be a single pre-filtered call.

I’ll put in a feedback for the direct instance access as I would prefer that since we seem to have that ID as an instance level token as ##system.instanceid##  I would expect there to be a ##system.devicedatasourceid## that we could reach now to get the necessary IDs for filling out the URL to the instance.

Got it to cooperate using powershell… The filters I was adding pass through two functions I wrote.. at some point, it was inserting the ‘?’ dividing the URL from the queries.  Fixed that… the datapoint names are CaSe SeNsItIvE.  When accessing a single instance, there are no .item objects, so I had to catch for quantity of returns.

I’m ready to move forward with some deeper predictive metrics now :)

Right, LM needs to flip some flags when they generate the swagger docs. I just put in a feed for it, but the more the merrier.

Really, there’s no reason, now that we have bearer tokens, to be able to do what swagger does in their example. Notice the “try it out” buttons on each call. 

Auth works, but the fields are all un-editable.

For what it’s worth, you should be able to use the swagger docs themselves to test out API calls. However, this was never explored/explained/enabled by LM since the auth was too complicated for even swagger to decipher. However, now that bearer tokens are a thing, you should be able to put your bearer token into the swagger web page, provide the path and query variables for a call and run the call. That’s what the “Authorize” button is for at the top of the page (that they forgot to disable or couldn’t figure out how to disable). LM needs to turn on a couple flags when generating the swagger docs though (like the ability to specify the portal url, and the “execute” buttons that swagger normally offers), then it should be possible to run all the API calls you want right from the swagger docs.

returns:

@{dataSourceName=WinVolumeUsageAzure-; dataPoints=System.Object[]; values=System.Object[]; time=System.Object[]; nextPageParams=}

I don’t have API access to LM to test this, but it looks like your dataPoints and values property does contain an array of items (“System.Object[]”). Are the properties blank? Try piping the return value to convertto-json -depth 100. I find that an easy way to look for nested objects (it’s like groovy’s .dump()).

Specifically based on this: