Resolution Logic for Time Series Node

Help
1

Hello Losant Team,

I built a workflow with a Time Series Node and the following settings:

  • custom time range
  • range end/duration defined by payload values
  • Aggregation - None

With such settings, Losant automatically puts resolution property to 1 minute and does not allow me to change this setting.

This setup works good for ranges less than a few days, but for a range of a few months 1 minute resolution seems to be small. In other words, it takes a while for such volume of data to be transferred to the front-end.

Is there a way automatically change resolution setting depending on duration value on the fly?

2

Hi @Alexander_Kondrov,

The reason this is blocked out is due to your Aggregation being set to none. It is not necessarily locking at 1 minute, it is returning every state reported in your selected time range, as the data is not being aggregated. If you toggle Aggregation to something other than “None,” the Resolution should become configurable; would an aggregation of something other than “none” work in your use case? :smile:

Thanks!
Julia

1 Like
3

Hi Julia,

Thank you for the prompt reply.
It does work and doesn’t at the same time. So, far I’ve changed the aggregation setting from None and divided flow to three different ranges (bigger time range - > bigger resolution). It looks a bit bulky. It would be nice to have a resolution settable by a payload value as well in the future.

image

Another question came up in addition. Is there a way to use Switch Node for value ranges. I.e. define path depending on X<1; 1<X<2; X>=2 ?

5

Hi @Alexander_Kondrov,

Yes, I see what you mean, it is a bit bulky! You might benefit from using the Losant API Node in place of the Data: Time Series Node. You can use the Data: Time Series Query resource, which allows for a more advanced configuration.

55%20PM
Screen Shot 2019-09-26 at 12.50.55 PM.png616Ă—1426 74.8 KB

This means you can configure the options in a JSON Template, so you would be able to pull a value from your payload for the resolution. The query would look like so:

{
  "end": 0,
  "duration": {{data.duration}}, /// these are my payload values
  "resolution": {{data.resolution}},
  "aggregation": "MEAN",
  "attributes": [
    "voltage"
  ],
  "deviceTags": [
    {
      "key": "floor",
      "value": "8"
    }
  ]
}

For the Switch node question, I had never actually tried this myself, and since my first couple ideas didn’t work out so well, I think this would be an excellent feature request and have put it into our system. The solution that did eventually work was a Function Node and a Switch, and it should help to decrease your number of nodes. I set up my workflow like so:

17%20PM
Screen Shot 2019-09-26 at 2.13.17 PM.png1640Ă—1532 348 KB

The value is stored on my payload at data.x, and I do my conditionals in my Function Node, putting a string value on the payload for the case that is true:

if(payload.data.x<=1){
  payload.data.result="less than one"; // Creating and setting result on the payload
}
else if(payload.data.x>=2){
  payload.data.result="greater than two";
}
else{
  payload.data.result="between one and two";
}

Over in my switch statement, I use my new data.result value to determine which path to take:

27%20PM
Screen Shot 2019-09-26 at 2.17.27 PM.png2298Ă—1596 506 KB

I decided to take the Function Node route as it will make things easier if your conditionals were to grow in number, or become more complicated. I have created a feature request for expression based switching, and will update you in the future should that become available.

Let me know how else I can help!
Julia

1 Like
7

Julia,

Thank you for your reply. I will consider using Losant API Node for a configurable resolution setting, I need to learn more about it first from Losant docs, though.

Regarding Function + Switch approach, I was thinking about it as well, but it would complicate later debugging maintenance. Therefore, I will wait until this is implemented as a standard feature.

1 Like
10

Hi @JuliaKempf, I would like to ask an additional question about using Losant API Node for retrieving time series data. I followed your advice and tried to implement Losant API Node with Action “Data: Time Series Data”. I didn’t find the exact example in the docs, and that’s what I put to the JSON Template field of the node, basically repeating Data: Time Series Node settings:

{
"aggregation":"MEAN",
"attributes": [
  "name_of_a_custom_attribute"
],
"end":{{path_to_end_number_in_ms}},
"deviceIds":[{{path_to_losant_device_id}}],
"duration": {{path_to_duration_number_in_ms}},
"resolution":60000,
"deviceTags": {}
}

This gives me a error.

Could you help me to detect missing/wrong fields please?

12

@Alexander_Kondrov,

Hi! Could you provide the error you’re getting?

13

Hi Taron,

image

14

@Alexander_Kondrov,

Ah, I think I see the issue. You need some quotes: ["{{path_to_losant_device_id}}"]

However, when templating string objects you can always do this:
{{jsonEncode path_to_losant_device_id}}

jsonEncode will automatically parse as a json value. It’s helpful for two reasons:

  1. It will add the quotes for you
  2. It will escape any thing in the string that JSON doesn’t like. For examples, a " character in in the middle of the string that will break things.
15

Taron, I am checking both of the options for deviceID you provided. So far, the behavior changed indeed.
Still getting the following validation error though…
image

16

Sweet! Different errors mean progress. :slight_smile:

This time, the issue is that deviceTags is supposed to be an array .

You can see the details of that request here: https://docs.losant.com/rest-api/data/#time-series-query

1 Like
17

Actually, your solution was good enough. I just needed to delete an empty {} deviceTags property to make it work. Super. Thank you for the prompt response:

PS As a recommendation, it would be useful to extend the example you referenced with settings defined by the payload path, but not only constants, as it is now

18

@Alexander_Kondrov,

There are some pending improvements coming to the docs around templating. But, that’s a great recommendation!