The current Nhaystack implementation seems to be centered around the use of BControlPoints in Niagara. You can drag these points on to the NhaystackServiceView to add a haystack tag slot. This works fine for BControlPoints but how about Custom components. F.i. i have custom components which already represent an equip, sensors and actuators within our Webeasy eco-system but these components do not get a haystack slot added to them when i drag and drop them on the NhaystackServiceView. These components also do not appear in the NhaystackServiceView when i manually add a Haystack slot of type HDict or HEquip.
Is there f.i. an interface i should implement to get these components recognised by the NhaystackService?
Mike JarmyTue 27 Jan 2015
Believe it or not you are the first person to actually ask for this :-). I thought it would come up a lot but it hasn't.
The answer, sadly, is that its not possible right now. I have a couple ideas for how to do it, though it is a rather substantial change
R BreijerTue 27 Jan 2015
Hi Mike,
Thanks for getting back to me.
Let me explain a little about why we would need the ability to tag custom components.
Ever since 2004 we’ve developed our own framework on top of Niagara. The reason for this is that, what we already have learned from the R2 era, is that is very time consuming/costly to realize HVAC projects with this product here in Europe. The whole procedure of, manually linking points, is both tedious and prone to errors. Also here in Europe we tend to do more centralized control than decentralized meaning that we use to jace to drive dumb IO rather than the more expensive bacnet/lon controllers with fixed firmware. So we use the jace as DDC controller rather than a SCADA solution that, for the most time, just binds points to views/histories and alarms. This means that all the control logic and hvac strategies are running in the jace. (or multiple when needed). To tackle the issue of manually linking IO points to the hvac applications and the physical IO we’ve devised a ‘tagging by object’ strategy. Sort of project-haystack avant-la-lettre. :-) Whereby we’ve modelled a hierarchy of sensors and actuators as java classes In Niagara to identify the meaning of a point or piece of equipment. F.i. We have an ‘outside air temp sensor’ object which inherits from ‘ temp sensor’ which in turn inherits from ‘ Analog input’.
We’ve also developed our own hardware line of low-cost modbus IO modules (which are also sold by Tridium UK to the niagara community in the EMEA area). We’ve also modelled these physical devices into Niagara (as a BDevice) but instead of using Niagara proxy points we’ve tied our objects in here to represent an IO point.
On the other hand we've created a suite of HVAC apps that model a piece of equipment like an AHU, Boiler plant etc.. In order to drive the control logic within the apps we need to connect inputs and outputs to it. Instead of using the traditional linking mechanism of Niagara we devised an object linking mechanism. The app (which is also just a BComponent) holds slots that ‘ expects’ a certain type of object. The engineer just have to go into the configuration of each app and selects one of the available objects (of the desired type) or create a new one if doesn’t exist yet. This way we can link up the logic super-fast without making mistakes of linking incorrect values to these slots. Together with a suite of workbench plugins/wizards A trained engineer can create a HVAC job with our appliance with .f.i. 50 to 100 IO points per hour.
If you like you can read the brochure about our product here : http://www.webeasy.nl/cms/wp-content/uploads/2013/04/Climate-Brochure.pdf to gain more insight in how this all works together.
Now to get back to the NHaystack issue at hand: Since we already have a sort of tagging mechanism in place it would be very beneficial for us to be able to map our object eco system to haystack. Since we seldom make use of BControlPoints we’re in a bit in a bind. The easiest way, from my perspective, is to have an BInterface that describes the contract for a BComponent that represents a Haystack point and one for representing a Haystack equip. This way 3rd party developers have more flexibility to adopt haystack.
I would be happy to work with you guys to get a solution for this stamped out.
Mike JarmyWed 28 Jan 2015
That sounds like a really interesting architecture. As you said, it sounds like you guys started creating something very "haystack-like" before the haystack name was coined. I was wondering how you managed to make it work without "real" BControlPoints :-).
I agree that if we were to do the work to adopt nhaystack to it, then using a BInterface of some kind would be the way to go.
However, there are a LOT of assumptions made in the nhaystack code about BControlPoints, and also about proxy points, writable points, proxied histories, etc etc. Its a substantial amount of work we are talking about here, and this is, after all, a volunteer project. And in the end, we'd have an even-more-complex nhaystack to maintain. I'm not saying that we definitely won't do it, but you may be underestimating the amount of work involved.
One thing that has occured to me is that your system could probably be adapted to the haystack protocol far more easily than standard AX. Have you considered writing your own haystack server? The haystack-java toolkit (which nhaystack uses) has most of the preliminary work already done for you. You might be surprised how quickly a prototype would come together. Just extend org.projecthaystack.server.HServer and see how it goes.
And of course you can take whatever you want from nhaystack itself. In fact you might even just declare nhaystack as a module dependency and use things like BHDict from it directly.
It would at least be a good project to do for starters just to see what would be involved.
R BreijerWed 28 Jan 2015
Ok Mike, thanks for your reply and i understand that this could be a lot of work.
In the meantime i've been playing around with the unmodified version of nhaystack and i was already successful in spoofing our apps as equip in haystack by extending from BHEquip instead of BComponent. Now comes the hard part of seeing if i can modify my objects to extend haystack control points. I'll let you know how it turns out in the next couple of days.
R Breijer Tue 27 Jan 2015
Hi,
The current Nhaystack implementation seems to be centered around the use of BControlPoints in Niagara. You can drag these points on to the NhaystackServiceView to add a haystack tag slot. This works fine for BControlPoints but how about Custom components. F.i. i have custom components which already represent an equip, sensors and actuators within our Webeasy eco-system but these components do not get a haystack slot added to them when i drag and drop them on the NhaystackServiceView. These components also do not appear in the NhaystackServiceView when i manually add a Haystack slot of type HDict or HEquip.
Is there f.i. an interface i should implement to get these components recognised by the NhaystackService?
Mike Jarmy Tue 27 Jan 2015
Believe it or not you are the first person to actually ask for this :-). I thought it would come up a lot but it hasn't.
The answer, sadly, is that its not possible right now. I have a couple ideas for how to do it, though it is a rather substantial change
R Breijer Tue 27 Jan 2015
Hi Mike,
Thanks for getting back to me.
Let me explain a little about why we would need the ability to tag custom components.
Ever since 2004 we’ve developed our own framework on top of Niagara. The reason for this is that, what we already have learned from the R2 era, is that is very time consuming/costly to realize HVAC projects with this product here in Europe. The whole procedure of, manually linking points, is both tedious and prone to errors. Also here in Europe we tend to do more centralized control than decentralized meaning that we use to jace to drive dumb IO rather than the more expensive bacnet/lon controllers with fixed firmware. So we use the jace as DDC controller rather than a SCADA solution that, for the most time, just binds points to views/histories and alarms. This means that all the control logic and hvac strategies are running in the jace. (or multiple when needed). To tackle the issue of manually linking IO points to the hvac applications and the physical IO we’ve devised a ‘tagging by object’ strategy. Sort of project-haystack avant-la-lettre. :-) Whereby we’ve modelled a hierarchy of sensors and actuators as java classes In Niagara to identify the meaning of a point or piece of equipment. F.i. We have an ‘outside air temp sensor’ object which inherits from ‘ temp sensor’ which in turn inherits from ‘ Analog input’.
We’ve also developed our own hardware line of low-cost modbus IO modules (which are also sold by Tridium UK to the niagara community in the EMEA area). We’ve also modelled these physical devices into Niagara (as a BDevice) but instead of using Niagara proxy points we’ve tied our objects in here to represent an IO point.
On the other hand we've created a suite of HVAC apps that model a piece of equipment like an AHU, Boiler plant etc.. In order to drive the control logic within the apps we need to connect inputs and outputs to it. Instead of using the traditional linking mechanism of Niagara we devised an object linking mechanism. The app (which is also just a BComponent) holds slots that ‘ expects’ a certain type of object. The engineer just have to go into the configuration of each app and selects one of the available objects (of the desired type) or create a new one if doesn’t exist yet. This way we can link up the logic super-fast without making mistakes of linking incorrect values to these slots. Together with a suite of workbench plugins/wizards A trained engineer can create a HVAC job with our appliance with .f.i. 50 to 100 IO points per hour.
If you like you can read the brochure about our product here : http://www.webeasy.nl/cms/wp-content/uploads/2013/04/Climate-Brochure.pdf to gain more insight in how this all works together.
Now to get back to the NHaystack issue at hand: Since we already have a sort of tagging mechanism in place it would be very beneficial for us to be able to map our object eco system to haystack. Since we seldom make use of BControlPoints we’re in a bit in a bind. The easiest way, from my perspective, is to have an BInterface that describes the contract for a BComponent that represents a Haystack point and one for representing a Haystack equip. This way 3rd party developers have more flexibility to adopt haystack.
I would be happy to work with you guys to get a solution for this stamped out.
Mike Jarmy Wed 28 Jan 2015
That sounds like a really interesting architecture. As you said, it sounds like you guys started creating something very "haystack-like" before the haystack name was coined. I was wondering how you managed to make it work without "real" BControlPoints :-).
I agree that if we were to do the work to adopt nhaystack to it, then using a BInterface of some kind would be the way to go.
However, there are a LOT of assumptions made in the nhaystack code about BControlPoints, and also about proxy points, writable points, proxied histories, etc etc. Its a substantial amount of work we are talking about here, and this is, after all, a volunteer project. And in the end, we'd have an even-more-complex nhaystack to maintain. I'm not saying that we definitely won't do it, but you may be underestimating the amount of work involved.
One thing that has occured to me is that your system could probably be adapted to the haystack protocol far more easily than standard AX. Have you considered writing your own haystack server? The haystack-java toolkit (which nhaystack uses) has most of the preliminary work already done for you. You might be surprised how quickly a prototype would come together. Just extend
org.projecthaystack.server.HServerand see how it goes.And of course you can take whatever you want from nhaystack itself. In fact you might even just declare nhaystack as a module dependency and use things like BHDict from it directly.
It would at least be a good project to do for starters just to see what would be involved.
R Breijer Wed 28 Jan 2015
Ok Mike, thanks for your reply and i understand that this could be a lot of work.
In the meantime i've been playing around with the unmodified version of nhaystack and i was already successful in spoofing our apps as equip in haystack by extending from BHEquip instead of BComponent. Now comes the hard part of seeing if i can modify my objects to extend haystack control points. I'll let you know how it turns out in the next couple of days.