Hi All,

As discussed at Haystack Connect recently a lot of work has been done by Tridium to simplify the tagging process in Niagara. The code has been up on my BitBucket account for some time but I have received feedback that more people would be prepared to test if the modules were already built.

So...

I'm pleased to advise that you can now download the latest in built form here.

In the zip archive there is a readme.md, I encourage everyone to read this first and please bear in mind that the documentation is still a work in progress.

All contributions welcome!!!

Also, I would advise that for anyone testing this new version that it should not be run on a production system straight away. My advice is to take a copy of a Niagara station and run it locally on your laptop with the new modules and run some of your own tests before deploying it to production.

Lastly, could I ask that any feedback, questions or bugs please be submitted as an issue on the BitBucket account. I am likely to be able to respond more quickly and keep track of different topics using BitBucket.

You can submit issues here.

Thanks and happy testing!

Cheers, Richard

Richard, I'm interested in beta testing. What version on Niagara is required?

The nhaystack 3.0.1 beta depends on the latest haystack-rt updates. The latest and recommended versions, 4.4.94.14 (r44u3) and 4.7.110.32 (r47u1), contain these haystack-rt updates. Patches of haystack-rt exist for 4.4.93.40 (r44u2), 4.6.96.28 (r46), and 4.7.109.20 (r47) and are included with the nhaystack 3.0.1 download.

I've been running 3.0.1 on a site in two different clients and I notice that the haystackReadAll will occasionally hang for no apparent reason on both sites. I receive a time out error.

There is no error on the NHaystack service. There are no errors logged in the Platform Application Director. The jace/supervisor CPU usage is low. The jace/supervisor memory usage is low. There is plenty of disk space. Both instances are running inside the corporate firewall. One is on a 1GB LAN in a small office that doesn't have much traffic on it. The other one is on a WAN that is slower but doesn't have much latency. The Actions/Rebuild Cache runs in seconds (even when the haystackReadAll is hung). I still get a ping response from the connector even when the haystackReadAll is hung. After a while it will start working again.

When I don't get the "hang" the haystackReadAll response is in seconds in both scenarios. If I disable the NHaystack Service and then enable it, the "hang" seems to go away (might be coincidental).

The haystackReadAll("his and axHistoryId") is very simple. I'm not using or filtering using any NHaystack tags (Site or Equip) or tagging within the jace.

Any suggestions would be appreciated.

Hi Paul,

Thanks for reporting this.

Can you give some more details around this?

Niagara Version? How many entities would you expect to be returned in such a query? Can you try more filtering to reduce the number of entities being returned? What version of the Jace is it?

Cheers, Richard

I'm interfacing with N4.4.73.24 running as a supervisor on a Windows 2012 server.

The supervisor has very few control points or histories. One installation has only 50 points, the other about 2,000.

It doesn't seem to matter if the filter returns a lot of records (2,000+) or none (0). The run delay is about the same (over one minute).

The system integrator asked if you could put some run durations in your code and write it to the Application Director to help zero in on if the time delay is within certain loops in your code or hanging somewhere outside your code (maybe not even excuting yet). Could we turn that logging on/off with an option on the NHaystack service?

Hi Richard, this is great news, I have a couple of questions

1) Will implied tags ( Native N4 tags) automatically be returned in the haystack API 2) Any time line on when this module can be used in production

Hi Alex,

1) Yes.

2) The more testing we get then the more confident we can be. There are a couple of bugs that have popped up in the last week we would like to take care of and there are some new features we require testing of.

Are you in a position to be able to help with testing?

Richard, Ok thanks for the update. We have a paying customer we would like to try this with, but not sure about the product maturity, we will provide feedback on BitBucket if we decide to move forward testing.

Also do you happen to know if the native N4 tagging (NEQL) can be exposed through an HTTP API,

Thanks!

Alex, the latest nhaystack module is probably your best bet. The latest enhancements to the module allow native N4 tags to be exported over the Haystack REST API. Even more recent enhancements allow those tags to come from any tag dictionary instead of just the one with the "hs" namespace.

Just started to play with it and I must say it is the missing piece. It allow all the work done with nhaystack to be compatible with native tags.

Good work !

@richard and @eric

Is json the best choice when interacting with nhaystack ?

Would there be any advantage to use zinc ?

Disclosure : I would prefer json :0)

Hi Christian,

Thanks for your comments...we appreciate your feedback!

I am hoping that if you send a request to the REST API with the Accept Header saying application/json then it should return a JSON response.

nhaystack uses the Haystack Java Toolkit so it should support the same encodings that are found there. However, I have to sheepishly admit I haven't checked lately that nhaystack is properly returning the JSON encoding.

I will put that on my to do list but if you could give it a try in the meantime and provide any feedback it would be appreciated.

First tries I made tell me it is working.

In fact, I see a great speed update using JSON with pyhaystack. Can't tell if it's completely our fault or if some speed issues are due to the Jace processing the response... anyway.

Just want to be sure everything is covered.

Hi, I use pyhaystack to talk to skyspark and indeed it is much faster when requesting data as JSON instead of hszinc.