I'm trying to model a pump section which is supplied with hot water from a header and feeds into a heating coil of a AHU and I'm running into some issues. See the picture below for an overview.
I was thinking of modeling the pump section (grey area) as a hot water plant as this would allow for a hotWaterRef from the heating coil to the pump section. The issue I'm having is, how to tag the temperature sensors associated with hot water from/to the headers. It feels to me as if I'm missing tags for this.
If I compare the pipeSectionType with ductSectionType the latter has the 4 tags for air in/out of an AHU where as the former has 2 tag for water in/out of a hot water plant
I've considered using warm-water and hot-water, analogue to condensate-water and chilled-water in the chilled-water-plant example, but this doesn't make sense to me as the water on both sides of the pump section is heated and used for HVAC purposes.
Am I approaching this all wrong and is there a different way to model this or are the tags indeed missing and should they be added?
Frank SmitFri 18 Mar 2022
Onno
In this case what you show the hot water temp? is water what is coming from a boiler or heatpump plant or storage vessel. So the tags you can use are hot-water-output-temp and hot-water-input-temp and the boilerRef. In case of low temperature heating below 45C we use warm water. But as an old engineer we always called it supply en return so it would be more logic to use supply-temp-boiler and return-temp-boiler and the boilerRef or outlet-temp-heatpump and inlet-temp-heatpump and the heatpumpRef. The Project Haystack definitions for Internet of Things are not always talking the same language as mechanical engineers. Look also in the subtypes of a tag there you find the most answers.
Brian FrankFri 18 Mar 2022
Typically in a situation like that you would coin two new tags such as internal vs external to clarify the location/roles. Although there is no standard tags for that currently.
The recommended way would be to more fully model the topology of your piping system which provides a precise mechanism to attach sensors. You do this by creating sections of pipe tagged as hot-water-pipe and modeling the topology of water flow using hotWaterRef. Then you can create child points in any section of pipe required.
Onno BrunklausMon 21 Mar 2022
Thank you both for the reply.
I was indeed contemplating using additional tags to clarify the location of the sensor. I do try to keep the number of non-defined to a minimum, but this would be the quick-fix. I agree that supply & return make more sense as there are consistent throughout the piping system and do not change if you're looking in or out (of a equip)
I agree that the best way would be to model the pipe system more extensive. This will involve multiple hotWaterRefs (see below). The headers themselves also have a temperature sensor, but that is quite straight forward to model, using the header tag. Retrieving the (temperature) information for the pump group will be a bit more cumbersome, but nothing which can't be done.
Onno Brunklaus Thu 17 Mar 2022
I'm trying to model a pump section which is supplied with hot water from a header and feeds into a heating coil of a AHU and I'm running into some issues. See the picture below for an overview.
I was thinking of modeling the pump section (grey area) as a hot water plant as this would allow for a hotWaterRef from the heating coil to the pump section. The issue I'm having is, how to tag the temperature sensors associated with hot water from/to the headers. It feels to me as if I'm missing tags for this.
If I compare the pipeSectionType with ductSectionType the latter has the 4 tags for air in/out of an AHU where as the former has 2 tag for water in/out of a hot water plant
I've considered using warm-water and hot-water, analogue to condensate-water and chilled-water in the chilled-water-plant example, but this doesn't make sense to me as the water on both sides of the pump section is heated and used for HVAC purposes.
Am I approaching this all wrong and is there a different way to model this or are the tags indeed missing and should they be added?
Frank Smit Fri 18 Mar 2022
Onno
In this case what you show the hot water temp? is water what is coming from a boiler or heatpump plant or storage vessel. So the tags you can use are hot-water-output-temp and hot-water-input-temp and the boilerRef. In case of low temperature heating below 45C we use warm water. But as an old engineer we always called it supply en return so it would be more logic to use supply-temp-boiler and return-temp-boiler and the boilerRef or outlet-temp-heatpump and inlet-temp-heatpump and the heatpumpRef. The Project Haystack definitions for Internet of Things are not always talking the same language as mechanical engineers. Look also in the subtypes of a tag there you find the most answers.
Brian Frank Fri 18 Mar 2022
Typically in a situation like that you would coin two new tags such as internal vs external to clarify the location/roles. Although there is no standard tags for that currently.
The recommended way would be to more fully model the topology of your piping system which provides a precise mechanism to attach sensors. You do this by creating sections of pipe tagged as
hot-water-pipe
and modeling the topology of water flow usinghotWaterRef
. Then you can create child points in any section of pipe required.Onno Brunklaus Mon 21 Mar 2022
Thank you both for the reply.
I was indeed contemplating using additional tags to clarify the location of the sensor. I do try to keep the number of non-defined to a minimum, but this would be the quick-fix. I agree that
supply
&return
make more sense as there are consistent throughout the piping system and do not change if you're looking in or out (of a equip)I agree that the best way would be to model the pipe system more extensive. This will involve multiple
hotWaterRef
s (see below). The headers themselves also have a temperature sensor, but that is quite straight forward to model, using theheader
tag. Retrieving the (temperature) information for the pump group will be a bit more cumbersome, but nothing which can't be done.I guess it would look something like this: