getDataBy...() methds return None if timeseries has no variable called value

[rafaelschlatter]

Hi Anders,

All three methods getDataById(), getDataByName() and getDataByDescription() return None in case the timeseries that have been queried for do not contain a variable called value.

This is can be seen in code at lines 610, 711 and 810 in TSIClient.py. The payload contains a hardcoded variable name that will be looked for in the TSI environment: "value": {"tsx": "$event.value"}. I think this works fine most of the time, as by default (with the default type I belief, I am a bit rusty with the TSI jargon now) each timeseries has only one variable with the name value.

But the following situation is a problem:

MyPythonDevice has three variables and the current code returns None for all of them. To return e.g. the temperature, one has to use "value": {"tsx": "$event.temperature"} in the payload.

I try to address this in my next PR, at the moment I am not sure whether there is a way to retrieve the variable names (I just quickly checked the JSON for the time series instance and the type, and none of these contained the variable names).

Best regards,
Rafael

[rafaelschlatter]

I figured out that this endpoint: https://{environmentFqdn}/eventSchema?api-version=2018-11-01-preview can be used to get an eventSchema (docs here: https://docs.microsoft.com/en-us/rest/api/time-series-insights/dataaccess(preview)/query/geteventschema). This will return the variable names, but just as a list of properties. It also not only contains the variables, but some other stuff as well, and it does not allow to link timeseries ids to variables. This is a body of a sample response:

{
  "properties": [
    {
      "name": "messageId",
      "type": "Double"
    },
    {
      "name": "deviceId",
      "type": "String"
    },
    {
      "name": "temperature",
      "type": "Double"
    },
    {
      "name": "humidity",
      "type": "Double"
    },
    {
      "name": "iothub-connection-device-id",
      "type": "String"
    },
    {
      "name": "value",
      "type": "Double"
    }
  ]
}

temperature, humidity and value are variables in this case. Not yet sure what to do with this ...

[rafaelschlatter]

@SiriOvregard your PR #24 solves this right? This issue could be closed in that case.

[SiriOvregard]

@rafaelschlatter it solves the problem if and when the type JSON build up is something like
{ "id":"59c7d57d-3440-4858-9013-d9ac78ffe5fd", "name":"Double", "variables":{ "Value":{ "kind":"numeric", "value":{ "tsx":"$event.[value].Double" }, "aggregation":{ "tsx":"avg($value)" } } } },

meaning if the "build up" is not Type > variables > Value > value > tsx:

types={}
jsonResponse = self.getTypes()     
for typeElement in jsonResponse['types']:
    try:
        typeElement['variables']['Value']['value']['tsx']
        types[typeElement['id']] = typeElement['variables']['Value']['value']['tsx']
    except:
        logging.error('"Value" for type id {type} cannot be extracted'.format(type = typeElement['id']))
        pass
return types

As you see, at the moment an error is logged in the case of the type JSON build up being different and thats it.

In our application of the client it works, but i believe the type JSON build up can vary, so I would recommend to test before closing the issue.

(In any case, I believe this represents a bit of a weakness and should probably be amended at some point...)

[rafaelschlatter]

Lets keep it open

[mpschr]

Hi there - first of all thanks for the library - it as facilitated the entry to the TSI API.

I run into this same error message. After digging a bit into the code I came to the conclusion, that the current architecture allows only for one variable, called Value within a TSI-Type. In my case my IoT device that dumps the data onto TSI has currently 5 variables configured (and more variables are in the data structure and currently unused). I am not able to create multiple Types on TSI for the same Time Series. Therefore my conclusion is, that I will not be able to query for the additional data - is that correct?

Here a screenshot of the type in question for better understanding: