Questions about point-values endpoint

---

Hi again.

I have two questions about the GET request over /rest/v1/point-values/{xid} endpoint.

1. This endpoint responds an array of collections, something like this:

[
  {
    "value": 35,
    "timestamp": 1560516758380,
    "annotation": null
  },
  {
    "value": 35,
    "timestamp": 1560516818380,
    "annotation": null
  },
  ...
]

While i expected the response to be similar to the one delivered by the events endpoint.

{
  "values": [
  {
    "value": 35,
    "timestamp": 1560516758380,
    "annotation": null
  },
  {
    "value": 35,
    "timestamp": 1560516818380,
    "annotation": null
  },
  ...
  ],
  "total": 10
}

I just want to ask if this is the expected behaviour, to adapt my code to this response.

2. When i add this query from=2019-06-14T04:00:00.000Z&to=2019-06-15T03:59:59.999Z to the GET request, i mean, something like this:

http://[host]:[port]/rest/v1/point-values/{xid}?from=2019-06-14T04:00:00.000Z&to=2019-06-15T03:59:59.999Z

all works flawlessly. But when i put this query from=2019-06-14T00:00:00.000&to=2019-06-14T23:59:59.999 or this query from=1560484800000&to=1560571199999 (the same time range as the previous, but in milliseconds since epoch), it returns me a 400 (bad request) error.
I ask if there is something bad with this format.

Thank you...

Hi Johautt

I ask if there is something bad with this format.

There's nothing inherently wrong with epoch format. The worst mark against it would be its lack of human readability. During development Jared expressed a preference for the timezoned-human-readable format on the benefit of readability and therefore can be modified by hand. The first dates you provided have a Z to indicate their stamped in UTC time, but you could modify the Z to be something like from=2019-06-14T04:00:00.000-06:00 would be six hours less at the start of the period. It does mean daylight savings may affect your regions +/- amount. It's ISO 8601 format, so you should be able to convert any dates you have in a programming language to it fairly easily.

@johautt said in Questions about point-values endpoint:

I just want to ask if this is the expected behaviour, to adapt my code to this response.

In response to question #1 - Yes, this is the expected behavior, I would probably use the V2 version of the point values REST controller though.

The difference between the end points is that the events endpoint accepts a RQL query, our endpoints which accept RQL queries typically return an array of results and a total showing the number of results that could be returned if you didn't limit them.

@johautt said in Questions about point-values endpoint:

I ask if there is something bad with this format.

In response to question #2 - The query parameters are expected to be in ISO 8601 format as Phillip said. In JavaScript you can use toISOString()

Note that to query for a whole day you should use from=2019-06-14T04:00:00.000Z&to=2019-06-15T04:00:00.000Z as the from time is inclusive and the to time is exclusive.

Ok, i see the problem.
There is something bad, but with the code i am using.
It does not give me the trailing time zone characters. I will modify this code and test.

With respect to the V2 version of the point-value, is it the POST request of path /rest/v2/point-values?

Have you seen the swagger documentation for the REST API? https://help.infiniteautomation.com/explore-the-api

There are HTTP GET and POST variants.

Yes, i use the swagger documentation.

By this commentary you said:

@jared-wiltshire said in Questions about point-values endpoint:

would probably use the V2 version of the point values REST controller

I searched and found in the documentation the endpoint mentioned. I was just a little confused with the fact that it doesn't have the {xid} parameter in the url. But i found the xid in the body.
Thank you!!!

The XID is still in the URL for the GET variant e.g. where temperature is the XID
/rest/v2/point-values/time-period/temperature?bookend=true&fields=TIMESTAMP&fields=VALUE&fields=RENDERED&fields=ANNOTATION&fields=BOOKEND&from=2019-06-14T20:46:04.291Z&limit=5001&timezone=America%2FDenver&to=2019-06-14T21:01:04.291Z

@jared-wiltshire said in Questions about point-values endpoint:

/rest/v2/point-values/time-period/

Ok, thank you!!! I had not take a look to this endpoint before. It is good to know this variant of the request.