What Is Project Haystack?

Project Haystack is an open-source initiative that defines semantic data models and tagging conventions for building automation, HVAC, lighting, energy, and IoT equipment. Launched in 2011 and now at version 4, Haystack solves one of the most persistent problems in facilities management: the inability to share and interpret building data across different vendors, platforms, and analytics engines without custom integration work.

At its core, Haystack provides a dictionary of tags — key/value metadata pairs — that describe physical equipment, locations, points, and relationships in a machine-readable, vendor-neutral way. A chiller, an air-handling unit, a VAV box, or a power meter all receive standardized tags that any Haystack-aware application can parse without prior knowledge of the underlying BMS vendor.

The Tag Dictionary and Data Model

Haystack organizes its tag library into several layers:

  • Markers — Boolean flags that assert a fact (e.g., ahu, chiller, sensor, cmd). A point tagged with temp and sensor is understood as a temperature sensor reading.
  • Values — Tags that carry typed data: strings, numbers, references, lists, or dicts (e.g., unit: "°F", siteRef: @acme-hq).
  • References — Tags like siteRef, spaceRef, equipRef create explicit parent-child relationships, forming a graph of the building's hierarchy from site → building → floor → space → equipment → point.

Haystack 4 introduced defs — a formal ontology layer that rigorously defines every tag's meaning, its allowed conjuncts, and its inheritance hierarchy. This means a Haystack 4-aware engine can reason that chiller is a subtype of equip, which is a subtype of entity, enabling generic queries across heterogeneous equipment fleets.

Serialization Formats: Zinc, Trio, JSON, and CSV

Haystack data can be serialized in several formats depending on the use case:

  • Zinc — A compact, line-oriented text format optimized for API responses and streaming. Zinc is the default wire format for the Haystack REST API (ops: about, read, hisRead, nav).
  • Trio — A human-readable format for configuration files, similar to YAML. Engineers commonly use Trio files to define equipment templates and tag dictionaries in SkySpark or other Haystack servers.
  • JSON — The Haystack JSON encoding extends standard JSON with typed scalars (e.g., {"_kind":"Number","val":72.5,"unit":"°F"}), enabling integration with REST-native web services.
  • CSV — A simple grid format for bulk data export and import, useful when migrating point lists between systems.

The Haystack REST API

Project Haystack specifies a REST API that exposes standard operations over HTTP:

  • GET /api/about — Server metadata and capabilities
  • GET /api/read?filter=ahu — Query entities by tag filter expression
  • POST /api/hisRead — Read historical time-series for a point
  • POST /api/hisWrite — Write historical data back to the server
  • POST /api/invokeAction — Invoke an action (e.g., override a setpoint)
  • GET /api/nav — Navigate the site/floor/space/equipment hierarchy

This REST API is implemented by analytics platforms like SkySpark (SkyFoundry), Niagara Framework (Tridium), and open-source projects like Haxall. It provides a lingua franca that lets an analytics dashboard built by one vendor consume data from a BMS deployed by another.

Tagging HVAC Equipment: Practical Examples

Consider a supply air temperature sensor on an air-handling unit on the third floor of a building. Its Haystack tags in Trio format would be:

id: @ahu-3-sat
dis: "AHU-3 Supply Air Temp"
ahu
equip
siteRef: @main-campus
floorRef: @floor-3
supply
air
temp
sensor
point
unit: "°F"
his

Any Haystack-aware analytics engine reading this record immediately understands it is a historical temperature sensor point on the supply air side of an AHU. No custom mapping is needed. A fault detection rule that fires when supply air temperature deviates from setpoint by more than 3°F can operate across every AHU in every building in the portfolio using the same Haystack filter: ahu and supply and air and temp and sensor.

Haystack vs. Brick Schema

Brick Schema (brickschema.org) is a complementary semantic standard based on RDF/OWL that overlaps significantly with Haystack. Brick focuses on formal ontological reasoning using W3C Linked Data technologies, while Haystack prioritizes practical deployability with lightweight formats and a battle-tested REST API.

Many deployments now use both: Haystack for real-time BMS connectivity and analytics, and Brick for digital twin integration, energy modeling, and compliance reporting where formal OWL reasoning adds value. The Haystack 4 and Brick communities have published alignment documentation mapping Haystack defs to Brick classes to reduce duplication.

Implementation Roadmap for Building Owners

Adopting Project Haystack in an existing building portfolio involves several steps:

  • Point list audit — Export all BMS points with their existing naming conventions. Typically 20–40% of points will have inconsistent names across controllers from different eras.
  • Tag mapping — Use a Haystack server's normalization engine or a custom ETL script to map vendor-specific point names to Haystack tags. Many platforms offer AI-assisted auto-tagging that can correctly classify 70–85% of points from their names alone.
  • Equipment modeling — Define equip records for each piece of mechanical equipment and link points to them via equipRef. This enables equipment-level analytics (e.g., chiller COP trending).
  • Validation — Run the Haystack conformance test suite to verify that your tag model is internally consistent and compliant with the spec.
  • Analytics deployment — Once the data model is validated, fault detection rules, energy dashboards, and predictive maintenance algorithms can be deployed without further data mapping work.