I'm running Niagara 3.8 with nHaystack version 1.5.2 and we are running into a problem with the haystackSyncHis from a group of jaces into a single Skyspark database. We have 10+ sites, each with it's own jace. About half are 100% functional, and the other half have this sync problem. All versions and settings look identical in all jaces, including all Timezone settings set to "America/New_York".
What's happening is when we pull the data into Skyspark from the problem jaces, the timestamps between 11pm and 12am all get shifted forward a full day. The other 23 hours worth of data is perfect.
We've run through the obix XML through Niagara and I've included it below, but everything seems to be right timezone/timestamp wise. This XML readout looks exactly the same on the working jaces and the problem jaces. All tagging across the Skyspark is uniform and to haystack standard.
Anybody come across this problem in the past? Or any possible settings on either ends of the connector that I could cross-check for differences between the working jaces and the functional ones?
Brian FrankFri 3 Jun 2016
What does the same data look like over Haystack when you do a hisRead? Is the nHaystack timestamps not matching the oBIX timestamps?
Trevor AdelmanFri 3 Jun 2016
Here's the haystackHisRead readout via folio in zinc format. Looks like the nHaystack timestamps are not matching up. You can see somehow that 24th hour of the day is getting kicked over from 2016-06-02 to 2016-06-03.
That does appear to be a nHaystack bug. Just to verify without any third party software such as SkySpark, can you run that query strictly from your browser against nHaystack such as and see if you are getting the corrupt timestamps:
Here's the output of the nHaystack HTTP GET request. Still happening there. We've also just tried to nuke one of the "bad" jaces all the way down to recreating the connector and re-importing the entire site tree in builder and re-binding the points and that didn't help either.
Are you reading directly from a Jace, or from a Web Supervisor?
If it is a Web Supervisor, are the histories logged locally or are they imported from a Jace?
Are the history extensions just standard Numeric Interval Extensions set to log at 1 minute intervals?
Is there anything else I need to know to try and replicate the problem?
regards, Richard
Trevor AdelmanWed 8 Jun 2016
Hey Richard,
1)We are reading straight from the Jaces
2)Histories are logged locally on the Jaces
3)You're correct, just standard numeric histories at 1 minute histories. The booleans are actually working as far as we can tell.
4)The weird part is, we've got some jaces that work and others that don't. It should have been an easy troubleshoot in that regard since we'd be able to find what's different between the working ones and the problem ones, however everything seems to be identical on all the jaces. All the same timezone settings, all the same history settings, all the same site/equip/point structure even. All the same imports were used on the Skysaprk side as well from across the board. I can't find a single unique thing about the ones that don't work outside of the timestamp issue itself...
If you'd like to set up a webconference to poke around I'm sure the customer would be open to something like that if you can't replicate it on your bench.
Richard McElhinneyThu 9 Jun 2016
Hi Trevor,
let me try to replicate it myself. If I can't do so I'll come back to you on the forum and sort out an avenue to work together.
Cheers, Richard
Trevor AdelmanMon 27 Jun 2016
Thanks for looking into it Richard. Any luck finding that same problem on your machine?
Richard McElhinneyTue 12 Jul 2016
Hi Trevor,
apologies for the delay in getting back to you. I haven't been able to reproduce it on my machine. Are you able to work with me offline and provide me with a copy of the station so I can run it on my machine?
Trevor Adelman Fri 3 Jun 2016
Hey everyone,
I'm running Niagara 3.8 with nHaystack version 1.5.2 and we are running into a problem with the haystackSyncHis from a group of jaces into a single Skyspark database. We have 10+ sites, each with it's own jace. About half are 100% functional, and the other half have this sync problem. All versions and settings look identical in all jaces, including all Timezone settings set to "America/New_York".
What's happening is when we pull the data into Skyspark from the problem jaces, the timestamps between 11pm and 12am all get shifted forward a full day. The other 23 hours worth of data is perfect.
We've run through the obix XML through Niagara and I've included it below, but everything seems to be right timezone/timestamp wise. This XML readout looks exactly the same on the working jaces and the problem jaces. All tagging across the Skyspark is uniform and to haystack standard.
Anybody come across this problem in the past? Or any possible settings on either ends of the connector that I could cross-check for differences between the working jaces and the functional ones?
Brian Frank Fri 3 Jun 2016
What does the same data look like over Haystack when you do a hisRead? Is the nHaystack timestamps not matching the oBIX timestamps?
Trevor Adelman Fri 3 Jun 2016
Here's the haystackHisRead readout via folio in zinc format. Looks like the nHaystack timestamps are not matching up. You can see somehow that 24th hour of the day is getting kicked over from 2016-06-02 to 2016-06-03.
Brian Frank Tue 7 Jun 2016
That does appear to be a nHaystack bug. Just to verify without any third party software such as SkySpark, can you run that query strictly from your browser against nHaystack such as and see if you are getting the corrupt timestamps:
Trevor Adelman Tue 7 Jun 2016
Here's the output of the nHaystack HTTP GET request. Still happening there. We've also just tried to nuke one of the "bad" jaces all the way down to recreating the connector and re-importing the entire site tree in builder and re-binding the points and that didn't help either.
Richard McElhinney Wed 8 Jun 2016
Hi Trevor,
Can I just clarify a few points please?
Are you reading directly from a Jace, or from a Web Supervisor?
If it is a Web Supervisor, are the histories logged locally or are they imported from a Jace?
Are the history extensions just standard Numeric Interval Extensions set to log at 1 minute intervals?
Is there anything else I need to know to try and replicate the problem?
regards, Richard
Trevor Adelman Wed 8 Jun 2016
Hey Richard,
1)We are reading straight from the Jaces
2)Histories are logged locally on the Jaces
3)You're correct, just standard numeric histories at 1 minute histories. The booleans are actually working as far as we can tell.
4)The weird part is, we've got some jaces that work and others that don't. It should have been an easy troubleshoot in that regard since we'd be able to find what's different between the working ones and the problem ones, however everything seems to be identical on all the jaces. All the same timezone settings, all the same history settings, all the same site/equip/point structure even. All the same imports were used on the Skysaprk side as well from across the board. I can't find a single unique thing about the ones that don't work outside of the timestamp issue itself...
If you'd like to set up a webconference to poke around I'm sure the customer would be open to something like that if you can't replicate it on your bench.
Richard McElhinney Thu 9 Jun 2016
Hi Trevor,
let me try to replicate it myself. If I can't do so I'll come back to you on the forum and sort out an avenue to work together.
Cheers, Richard
Trevor Adelman Mon 27 Jun 2016
Thanks for looking into it Richard. Any luck finding that same problem on your machine?
Richard McElhinney Tue 12 Jul 2016
Hi Trevor,
apologies for the delay in getting back to you. I haven't been able to reproduce it on my machine. Are you able to work with me offline and provide me with a copy of the station so I can run it on my machine?
Cheers, Richard