#1011 haxall history - hisRead

fabio antoci Wed 14 Sep 2022

hi all,

I would like to know if someone has experience with haxall history. In the documentation seems to be possible to read a history of a point with the function hisRead() but if i try to use it the error is throw.

Also in the documentation seems that in haxall the history of a point is saved only in the RAM so when a haxall server is restarted whole the data are lose. But in the documentation seems also that the history is stored : "This tag configures how long to buffer collected history items in memory before flushing them to the historian" https://haxall.io/doc/lib-phIoT/his-point

I would like to ask if someone knows:

  • how the historian actually works?
  • if is possible to read the history of a point?
  • if with haystack connectors the sync history works or not? (with a SkySpark main server connected to a haxall server)

Thanks

Brian Frank Wed 14 Sep 2022

The Haxall historian is just a RAM based circular buffer. You have a lot of options to collect data locally using hisCollectInterval and hisCollectCov, etc. Then it is buffered until you can push/poll it to north bound applications (you can poll data using the hisRead HTTP operation). If the north bound application is SkySpark then you can use clustering + cloning to sync the data too (although please direct further SkySpark specific questions to skyfoundry forum).

Nick Sexson Mon 26 May

Reviving an old thread here for some clarification.

I'm using Haxall 3.1.11 as the haystack endpoint. I've set up a point with hisCollectCov that gets a value from a MQTT message to simulate a COV point. The point setup, task, and all supporting setup is working as designed.

I can see the his buffer using pointDetails

val:
id:    @myPoint
dis:   myPoint
kind:  null
unit:  v
tz:    New_York

His Collect
=============================
hisStatus:       ok
hisErr:          null
interval:        null (0hr, 0min, 0sec)
cov:             marker
covRateLimit:    1sec
collectNA:       false
tz:              New_York
writeFreq:       1hr
writeLast:       never
writeErr:        null
buffer:          6 (16 max)
  2025-May-26 09:57:06 71 {null} pending
  2025-May-26 09:57:04 74 {null} pending
  2025-May-26 09:57:03 86 {null} pending
  2025-May-26 09:57:02 38 {null} pending
  2025-May-26 09:57:01 87 {null} pending
  2025-May-26 09:56:48 null {null} pending

However, when I use a client to execute the hisRead op for the point it returns empty.

My questions:

  1. Since Haxall only has a memory based buffer, is there something that needs to be done to simulate "writing to history" to make these values readable from a client calling the hisRead op endpoint?
  2. Is there any other function that can access the buffer directly instead of the text that is returned from pointDetails?
  3. Is there a flag or some other method that can increase the buffer past the default 16 readings?

Thanks, Nick

Brian Frank Mon 26 May

That isn't the actual in-memory history you are looking at there. That is a temp buffer used to cache items before flushing to the real history db (which in SkySpark is on disk and in Haxall is an in-mem database). It looks like the problem is that your writeFreq is 1hr, do you have the hisCollectWriteFreq tag configured for 1hr? That is probably your problem, becaues its caching the collection for 1hr before flushing to the in-memory database. Try removing that tag and then the hisRead network op should work fine to read your collected data

Nick Sexson Mon 26 May

Sorry that was left in there. I had configured it because it seemed that the values weren't being flushed to history. When removed I send new values through and can see them with point details:

val:
id:    @myPoint
dis:   myPoint
kind:  null
unit:  v
tz:    New_York

His Collect
=============================
hisStatus:       ok
hisErr:          null
interval:        null (0hr, 0min, 0sec)
cov:             marker
covRateLimit:    1sec
collectNA:       false
tz:              New_York
writeFreq:       null
writeLast:       never
writeErr:        null
buffer:          13 (16 max)
  2025-May-26 20:37:30 59 {null} skipped
  2025-May-26 20:37:29 61 {null} skipped
  2025-May-26 20:37:28 23 {null} skipped
  2025-May-26 20:37:27 2 {null} skipped
  2025-May-26 20:37:26 47 {null} skipped
  2025-May-26 20:37:25 36 {null} skipped
  2025-May-26 20:37:24 74 {null} skipped
  2025-May-26 09:57:06 71 {null} skipped
  2025-May-26 09:57:04 74 {null} skipped
  2025-May-26 09:57:03 86 {null} skipped
  2025-May-26 09:57:02 38 {null} skipped
  2025-May-26 09:57:01 87 {null} skipped
  2025-May-26 09:56:48 null {null} skipped

However, hisRead still shows empty. Are these supposed to show skipped? That makes it seem like they would not be flushed to the DB.

Nick Sexson Mon 26 May

Edit update: tag should be hisCollectCovRateLimit for rate. All working now.

Ok so I found out that if the task doesn't also write the curStatus to ok with each entry then it doesn't write. Added that and now it's writing, but no matter how I configure covRateLimit it goes back to 1 min and will only write once a minute. My previous examples show I could set it at 1sec but now with point:

id:@myPoint "myPoint"
covRateLimit:1sec
cur
his
hisCollectCov
kind:Number
mod:2025-05-27T01:11:44.021Z
point
tz:New_York
// restricted/transient tags
// curStatus:ok
// curVal:54
// hisEnd:2025-05-26T21:10:32-04:00 New_York
// hisSize:5
// hisStart:2025-05-26T21:06:32-04:00 New_York
// hisStatus:ok

it still shows this in point details:

val:
id:    @myPoint
dis:   myPoint
kind:  Number
unit:  null
tz:    New_York

His Collect
=============================
hisStatus:       ok
hisErr:          null
interval:        null (0hr, 0min, 0sec)
cov:             marker
covRateLimit:    1min
collectNA:       false
tz:              New_York
writeFreq:       null
writeLast:       1min 17sec ago
writeErr:        null
buffer:          16 (16 max)
  2025-May-26 21:10:32 54 {ok} wroteVal
  2025-May-26 21:09:32 37 {ok} wroteVal
  2025-May-26 21:08:32 16 {ok} wroteVal
  2025-May-26 21:07:32 85 {ok} wroteVal

Any idea why the 1sec won't stick?

Login or Signup to reply.