#707 nhaystack 3.0.1 beta released and looking for feedback

Richard McElhinney Tue 28 May

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

Paul Quinn Tue 4 Jun

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

Eric Anderson (Tridium) Fri 7 Jun

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.

Paul Quinn Fri 19 Jul

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.

Richard McElhinney Mon 22 Jul

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

Paul Quinn Thu 25 Jul

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?

Login or Signup to reply.