Alongside Shawn Jacobson's post - I would like to propose the HisRead op is modified as well to allow multiple recs to have their histories read from at the same time.
HisRead
The hisRead op is used to read a time-series data from historized point(s).
Request (single point): a grid with a single row and following columns:
id: Ref identifier of historized point
range: Str encoding of a date-time range
Response (single point): rows of the result grid represent timetamp/value pairs with a DateTime ts column and a val column for each scalar value. In addition the grid metadata includes:
id: Ref of the point we read
hisStart: DateTime timestamp for exclusive range start in point's timezone
hisEnd: DateTime timestamp for inclusive range end in point's timezone
Request (multi point): a grid with a single row and following columns:
range: Str encoding of a date-time range
id0: Ref identifier of the first historized point
id1: ...
where the id columns are named id0, id1, etc, for the successive historized points .
Response (multi point): rows of the result grid represent timestamp/value pairs with a DateTime ts column and a val column for each scalar value, named v0, v1 etc, with a Ref identifier of the writable point defined in the column metadata:
ts: DateTime timestamp of sample in point's timezone
v0: Value of the first timestamp sample
v1: ...
In addition, the grid metadata include:
hisStart: DateTime timestamp for exclusive range start in point's timezone
hisEnd: DateTime timestamp for inclusive range end in point's timezone
The range Str is formatted as one of the following options:
"today"
"yesterday"
"{date}"
"{date},{date}"
"{dateTime},{dateTime}"
"{dateTime}" // anything after given timestamp
Ranges are exclusive of start timestamp and inclusive of end timestamp. The {date} and {dateTime} options must be correctly Zinc encoded. DateTime based ranges must be in the same timezone of the entity (timezone conversion is explicitly disallowed). Date based ranges are always inferred to be from midnight of starting date to midnight of the day after ending date using the timezone of the his entity being queried.
Silly question, is there any reason why the server needs to care about the column names in this circumstance?
It might be helpful for the end user if the server simply "round tripped" the column names, so that each row had a column "ts" which was the timestamp, then the remaining columns are named whatever the request named them.
Alex Afflick Mon 7 Dec 2015
Alongside Shawn Jacobson's post - I would like to propose the HisRead op is modified as well to allow multiple recs to have their histories read from at the same time.
HisRead
The
hisReadop is used to read a time-series data from historized point(s).Request (single point): a grid with a single row and following columns:
id: Ref identifier of historized pointrange: Str encoding of a date-time rangeResponse (single point): rows of the result grid represent timetamp/value pairs with a DateTime
tscolumn and avalcolumn for each scalar value. In addition the grid metadata includes:id: Ref of the point we readhisStart: DateTime timestamp for exclusive range start in point's timezonehisEnd: DateTime timestamp for inclusive range end in point's timezoneRequest (multi point): a grid with a single row and following columns:
range: Str encoding of a date-time rangeid0: Ref identifier of the first historized pointid1: ...where the id columns are named id0, id1, etc, for the successive historized points .
Response (multi point): rows of the result grid represent timestamp/value pairs with a DateTime ts column and a val column for each scalar value, named v0, v1 etc, with a Ref identifier of the writable point defined in the column metadata:
ts: DateTime timestamp of sample in point's timezonev0: Value of the first timestamp samplev1: ...In addition, the grid metadata include:
hisStart: DateTime timestamp for exclusive range start in point's timezonehisEnd: DateTime timestamp for inclusive range end in point's timezoneThe range Str is formatted as one of the following options:
Ranges are exclusive of start timestamp and inclusive of end timestamp. The
{date}and{dateTime}options must be correctly Zinc encoded. DateTime based ranges must be in the same timezone of the entity (timezone conversion is explicitly disallowed). Date based ranges are always inferred to be from midnight of starting date to midnight of the day after ending date using the timezone of the his entity being queried.Example of a single point hisRead request:
Example of a multi point hisRead request:
Stuart Longland Thu 28 Jan 2016
Silly question, is there any reason why the server needs to care about the column names in this circumstance?
It might be helpful for the end user if the server simply "round tripped" the column names, so that each row had a column "ts" which was the timestamp, then the remaining columns are named whatever the request named them.
e.g.
If a user chooses to use v0, v1, v2, … then more power to them, this will still work.