I have many variations of chilled beam systems to characterize using Haystack. One of them is forced-air chilled beams. I put airRef on the chilledBeam equip, but it appears to be violating the Haystack scheme because a chilledBeam equip doesn't have an air-input. Since forced-air chilled beam is a pretty common system in the industry, I thought it would allow users to select whether it is active or passive. What's odd is that there is a tag called chilledBeamZone, which is for AHUs. That means Haystack knows some AHU supply air to chilled beams. But it doesn't allow users to reference the air source on the chilled beam equipment. Am I missing something?
If anyone has a well-established method for tagging the water-side and air-side of chilled beam systems, could you share your tagging scheme here? I know we have to create our own scheme or method eventually to cater to our applications, but I want to learn from other users as much as possible.
The air path of the chilled beam system I mentioned above is: AHU - VAV/CAV - primary air of multiple chilled beams. And the same AHU serves VAVs/CAVs that don't have chilled beams also. And, of course, the water-side zoning doesn't match the air-side zoning.
Marianna AFri 14 Aug
I second this. Can anyone provide their method for tagging the water-side and air-side of chilled beam systems?
Jason HoganSun 16 Aug
In Haystack 4, the cleanest way to handle active (forced-air/induction) chilled beams without tripping the def ontology validation is to explicitly define the inlet air interface and use flow references.
For an Active Chilled Beam (Forced Air) equipment entity:
id: @beam-101 dis: "Active Chilled Beam 101" equip chilledBeam active hvac-air-input hvac-chilledWater-input airRef: @vav-101 // or directly to @ahu-1 if no intermediate terminal unit chilledWaterRef: @chw-plant siteRef: @my-site spaceRef: @room-101 If you have an intermediate VAV/CAV supplying primary air to multiple induction beams:
Air Path Topology:
AHU (ahu, hvac-air-output) ➔ airRef on VAV
VAV (vav, hvac-air-input, hvac-air-output) ➔ airRef on each chilledBeam downstream.
Hydronic Path Topology:
Each chilledBeam has its own chilledWaterRef pointing to the hydronic loop/manifold or zone valve controller, completely decoupled from the air-side hierarchy.
If your validator is strictly complaining that base chilledBeam doesn't inherit air-input, adding the marker active along with the duct/pipe inlet tags (hvac-air-input, hvac-chilledWater-input) resolves the input interface definition for downstream relationship checks.
Hiroko Masuda Fri 1 Aug 2025
I have many variations of chilled beam systems to characterize using Haystack. One of them is forced-air chilled beams. I put airRef on the chilledBeam equip, but it appears to be violating the Haystack scheme because a chilledBeam equip doesn't have an air-input. Since forced-air chilled beam is a pretty common system in the industry, I thought it would allow users to select whether it is active or passive. What's odd is that there is a tag called chilledBeamZone, which is for AHUs. That means Haystack knows some AHU supply air to chilled beams. But it doesn't allow users to reference the air source on the chilled beam equipment. Am I missing something?
If anyone has a well-established method for tagging the water-side and air-side of chilled beam systems, could you share your tagging scheme here? I know we have to create our own scheme or method eventually to cater to our applications, but I want to learn from other users as much as possible.
The air path of the chilled beam system I mentioned above is: AHU - VAV/CAV - primary air of multiple chilled beams. And the same AHU serves VAVs/CAVs that don't have chilled beams also. And, of course, the water-side zoning doesn't match the air-side zoning.
Marianna A Fri 14 Aug
I second this. Can anyone provide their method for tagging the water-side and air-side of chilled beam systems?
Jason Hogan Sun 16 Aug
In Haystack 4, the cleanest way to handle active (forced-air/induction) chilled beams without tripping the def ontology validation is to explicitly define the inlet air interface and use flow references.
For an Active Chilled Beam (Forced Air) equipment entity:
id: @beam-101 dis: "Active Chilled Beam 101" equip chilledBeam active hvac-air-input hvac-chilledWater-input airRef: @vav-101 // or directly to @ahu-1 if no intermediate terminal unit chilledWaterRef: @chw-plant siteRef: @my-site spaceRef: @room-101 If you have an intermediate VAV/CAV supplying primary air to multiple induction beams:
Air Path Topology:
AHU (ahu, hvac-air-output) ➔ airRef on VAV
VAV (vav, hvac-air-input, hvac-air-output) ➔ airRef on each chilledBeam downstream.
Hydronic Path Topology:
Each chilledBeam has its own chilledWaterRef pointing to the hydronic loop/manifold or zone valve controller, completely decoupled from the air-side hierarchy.
If your validator is strictly complaining that base chilledBeam doesn't inherit air-input, adding the marker active along with the duct/pipe inlet tags (hvac-air-input, hvac-chilledWater-input) resolves the input interface definition for downstream relationship checks.