Hi All,

[Edited] I am new to Haystack and this forum. I need guidance on implementation of read, hisRead and watchPoll operations. We are trying to develop a Haystack server.

My understanding is: 1) For hisRead operation,

• "his" tag is associated with a point
• data is fetched periodically from end-points (e.g. BACnet devices) and stored locally say in a database
• as a response to hisRead operation, data from database should be returned based on "range" parameter

2) For watchPoll operation,

• real-time data is fetched from end-points whenever watchPoll operation request is received
• as a response, it is sufficient to return data for tags: curval and curStatus. (There is no need to return data for tags like "dis")

3) For read operation,

• data of all tags associated with a point should be returned in a response
• even if a "cur" tag is associated with a point, there is no need to fetch real-time data from end-points. Latest available value (say from database) can be used for curval and curStatus tags

Is this understanding correct ?

Query: Consider a scenario: For a point "cur" tag is associated, however "his" tag is not associated and a watch is also not set.

a) In this case, when do we obtain/set value of curVal and curStatus tags ?

b) Should there be any periodic (say every 30 min) data fecth from end-points for all such points ?

Any inputs and comments are highly appreciated.

Thanks.

Your understanding is correct.

• hisRead should read previously trended historical timestamp samples in batch (according to the range). It requires that the device does its own historical data trending/logging
• watchPoll should "subscribe" to downstream data. The initial read might not reflect the latest curVal, but subsequent polls should eventually report a fresh curVal. Its not formally defined about whether you should return all tags or just curVal on additional polls. Its supposed to be all the tags, but due to performance problems I believe nHaystack was changed to just return curXXXX tags
• reads just return all the tags including the last curVal read which might be stale. A read operation should not perform any curVal refresh

The way we we implemented it in SkySpark is that only a watchAdd will cause curVal to be refreshed (we also have functions to force a connector read, but that isn't part of our standard Haystack API)

Thanks Brian for quick and detailed reply.

So the way i think about the scenario as: Say for a point only "cur" tag is associated. There is no watch or "his" tag associated with this point.

And say, there is no periodic data fetch as well

In this case,

1) when first "read" operation comes for this point, we might need to fetch data from end-point to obtain values for curXXX tags

2) Then for all subsequent "read" operations on this point, same values will be returned for curXXX tags.

Is this correct ?

I'm assuming you are designing a server system here.

You can make it work however you want. I don't think it will hurt to have read operations perform a "curVal" refresh.

However, from a semantics perspective making a read call isn't an indication that I want the curVal. Most of the time I'm just trying to understand the structure of the database, list equip, points, etc. If I happen to read stale curVal that is just a bonus. But a single read can't guarantee fresh data - that requires an async mechanism (which is why its tied to watches).

So the only calls which semantically mean "I want curVal" are watchXXXX.

Personally I like to avoid any curVal refreshes unless the client explicitly asks for them via watchAdd. Although like I said, if your system does background curVal refreshes it isn't going to hurt anything. It largely depends on what your underlying protocol/devices look like. If the fieldbus protocol has the bandwidth to support keeping everything fresh then that keeps thing simple.

Thanks a ton Brian !

We are indeed working on server side and your views are definitely worth considering.

Thanks once again