Hey Guys.... Wanted to update everyone on nHaystack. For the last 3 years J2 has been managing this project, with the help of the community. Feature design, testing, have all been done out of Chino CA. We have a lot of help on testing and features from the community as well. During this time we used Mike Jarmy an internal resource for a good % of the development, however there has been a lot of contributions outside. Including Brian Frank, Richard, Ron from Web Easy, and a handful of other developers as well. Friday was Mike Jarmy's last day at J2, as he is starting to work for another consulting firm in Richmond. I wanted to personally thank Jarmy for all the hard work he has done. He has left nHaystack in really good hands and in great shape, in fact it's already working in N4 (Too bad Tridium didn't have this working already :} ). We are hoping that Tridium will work with us going forward, maybe you guys can bug them too :}

J2 will continue to do development, testing, and feature design internally, however we will be looking for some more help. Richard has already mentioned that he will be available to contribute. So between my team at J2, and Richard I think we are in good hands. Let me know if anyone else would like to start contributing.

We are really excited on where Haystack is going. nHaystack is installed in 1000s of buildings already, and we can't wait to see where it goes next.

First, thanks to Mike. He really did a great job improving the first version that Richard did a really long time ago now. It's now way easier and complete.

I would like to contribute with something.

Already had a talk with Mike a long time ago about a pull request I would like to submit.

It adds the opportunity to automatically add markers or tags to a point based on its name.

As an integrator, I often use the same kind of controllers for my clients and the point names are always the same (almost the same). I can then build myself a simple csv file, residing on my PC.

When dragging the points in the nhaystack service, the system will look the name of the point, if it's in the list, it will apply the configured tags.

A small example of a file :

name,markers
DA-T,discharge air temp sensor
DAT-SP,discharge air temp sp
DA-H,discharge air humidity sensor
DA-P,discharge air pressure sensor
DA-VP,discharge air flow sensor
SF-C,discharge air fan cmd
SF-S,discharge air fan sensor
SF-O,discharge air fan speed cmd
CLG1-C,cool stage:1 cmd
CLG2-C,cool stage:2 cmd
CLG3-C,cool stage:3 cmd
CLG4-C,cool stage:4 cmd

If it's not, it'll simply act as usual with a default value.

I also added a few buttons to the service view (Build Cache, Initialize, ..., etc... to ease my life) By default, I also escape the $bla caracters when looking at the tree... if I really want to get annoyed by all those $% caracters, I just have to press the Haystack Format button.

You can see the code here : https://bitbucket.org/christiantremblay/nhaystack

I've been able to merge my branche to the newest version so I think it should not be a big deal.

I'm pretty sure it can be useful for a lot of people, it adds so much speed to the tag process.

Also pretty sure it can be improved so I'm open to comments too.

I also would like to contribute my source as well. I've made it possible for Niagara developers to identify custom BComponents as either a Site, Equip or Point through a collection of BInterface's and thus have the ability to add haystack tags to them. Typically only BControlPoints are taggable as points.

https://bitbucket.org/romalt/nhaystack-custom

Perhaps we can streamline this into the main build of nhaystack for the benefit of all?

I'm also thinking about adding push capabilities for syncing histories, alarms, schedules and point values via a reversed watch mechanism. Http push makes more sense when dealing with niagara stations that are behind a firewall etc. rather than the regular pull based connection.

Sounds great guys, let's meet offline and figure this out.