#458 Propose to enhance the response of watchPoll() .

Samuel Toh Thu 8 Dec 2016

Hi,

After studying the specification for watchPoll() a bit and using Json Briggs' NHaystack implementation as a guide line.

Quote:

* Poll for any changes to the subscriptions records.
* This returns only the id, curVal and curStatus tags for each point.
*/

Refer: https://bitbucket.org/jasondbriggs/nhaystack/src/29f497b9b9dcff3ad9d0214261d38c426ba99dbc/src/nhaystack/server/NHWatch.java?at=default&fileviewer=file-view-default#NHWatch.java-181:184

It sounds like the response for the watchPoll() end point is a HGrid with HRows containing 3 columns namely the Id, curVal and curStatus. Now, please pardon me on this assumption as the home page's documentation isn't very clear to me, so I am forced to reference the NHaystack source code here. So please correct me if I am wrong.

As there is no way for one to make out what is the date time stamp of a particular value for now, I am proposing to add another column call "ts" (timestamp) to give more meaning to the data. That is, the date time frame in which the value was recorded.

Please let me know this make sense.

Brian Frank Tue 20 Dec 2016

As there is no way for one to make out what is the date time stamp of a particular value for now,

The current stuff is really more indicative of "current value as quickly as we can read it". Timestamp values are really more paired up in the historical logging APIs such as the hisRead and hisWrite ops.

Stuart Longland Wed 21 Dec 2016

I suppose this is where we're in a somewhat unique situation: the comms driver in our case timestamps each sample as it captures it and reports that along with the state.

So if a poll of an attribute succeeded, the value will be whatever was read from the device, the state will be OK and the timestamp will be the time that poll was performed.

If there was a communications problem though, it'll report a state of COMMS_ERR, the value will likely be reported as null (we use JSON to represent data) and the timestamp will be the time of the failed attempt. Other status codes we have include NOT_FOUND (the attribute doesn't exist), DENIED (for later use -- indicates the user isn't allowed to touch this), NO_DATA (e.g. the attribute hasn't been sampled at that time)… etc.

At the moment, I'm playing around with a nHaystack instance here in the office, poking it with pyhaystack and seeing how it moves. The real-time stuff isn't implemented in pyhaystack officially, but we can go in the back door and call the session object's _post_grid method along with hszinc to abstract a lot of the detail, so things aren't too bad.

First thing I noticed doing a watchSub is nHaystack reports a NullPointerException (and HTTP status 200 OK, in spite of the obvious internal server error) unless you specify lease (which is "optional" according to the docs).

No problem, I set it to one hour, and after a few false starts getting the unit right, it was happy with that. My request looks like this:

ver:"2.0" watchDis:"New Watch" lease:1hr
id
@C.Sampler.Float

and it responded with a response like this:

ver:"2.0" watchId:"11e6c7eb-4043-74bc-0000-000000009e78" lease:3600000.0ms
id,curVal,curStatus
@C.Sampler.Float,0.061065064668,"ok"

Doing a watchPoll, I sent a request grid like this:

ver:"2.0" watchId:"11e6c7eb-4043-74bc-0000-000000009e78"
id

and got a reply like this:

ver:"2.0"
id,curVal,curStatus
@C.Sampler.Float,6.342,"ok"

To me, slipping an extra ts column with a DateTime value wouldn't break anything.

Both watchSub and watchPoll seem to have very similar responses (both looking nothing like the read, contrary to documentation). Does that seem like a reasonable assumption?

As for the curStatus field, ok is clearly equivalent to our OK status (lower case instead of upper case), but what other status codes are there and what are their meanings?

Login or Signup to reply.