Multi-vendor Integration

Real buildings have heterogeneous control stacks. The lobby chiller plant is on a 2014 Tridium Niagara JACE. The rooftop air handlers were retrofitted in 2019 onto Automated Logic WebCTRL. The boiler room is still talking native Modbus RTU to a Cleaver-Brooks panel. Two of the floors have Daikin VRF systems on a proprietary BACnet/IP profile. AiTBMS treats this as the default — not the exception — and ships an adapter layer specifically designed to read every one of those without forcing a forklift upgrade.

The unified data model

Internally, every point AiTBMS reads gets normalized into a single canonical schema: a point belongs to an equipment, equipment belongs to a building, points emit trend samples on a fixed cadence, and faults reference both points and equipment. Whether the source is BACnet object analog-input:42 named AHU-2.MAT or a WebCTRL eWeb path /system/AHUs/AHU-2/MixedAirTemp, after ingestion it's the same AHU-2.mat point inside AiTBMS, with the same units, the same timezone, and the same engineering metadata. This normalization is the single most important architectural decision in the product — it's what lets the conversational assistant answer "what's AHU-2's mixed air temp?" without needing to know which vendor owns the data.

Adapter layer — what we support today

AiTBMS ships with five first-party adapters, all built on the same plugin contract:

• WebCTRL eWeb (SOAP) — the licensed Automated Logic interface. We use the documented SOAP endpoints for getValue, getTrendData, and getAlarms. Read-only by default; writeback is gated by the tier model (see Tier-gated Control Authority) and goes through setValue with audit-trail capture in WebCTRL's own logbook. WebCTRL is Automated Logic's trademark; AiTBMS is a complement, not a replacement.
• Tridium Niagara (Fox + oBIX + REST) — pulls live values via Niagara's Fox protocol where available, falls back to oBIX REST for trend history. Compatible with Niagara 4.x and AX (legacy AX support is deprecated but not removed).
• BACnet/IP (native) — direct ReadProperty / ReadPropertyMultiple against any BACnet/IP device. Discovers devices via Who-Is broadcast, builds an object inventory, and tags points using BACnet object names plus PICS metadata when available. This is the universal fallback for any device not covered by a higher-level adapter.
• Modbus TCP / RTU — for legacy boilers, generators, and metering panels that pre-date BACnet. We require a point map config file (CSV) that documents register-to-engineering-unit mapping, because Modbus has no self-description.
• REST / OpenAPI — for modern devices and gateways (Distech ECLYPSE, KMC Conquest, Smart submeters, Aclara water meters) that publish JSON over HTTP. The adapter accepts an OpenAPI spec or a hand-written endpoint map.

Adapter layer — on the roadmap

• Johnson Controls Metasys (MetasysAPI) — JCI's documented REST API for Metasys 12+.
• Siemens Desigo CC (REST + WSI).
• Honeywell EBI / WEBs-AX.
• Niagara N4 Cloud / Carbon API — once Tridium ships it broadly.

The adapter contract is small enough on purpose — discover(), read(pointIds, sinceTimestamp), write(pointId, value, justification), subscribe(pointIds, callback). Anyone with the protocol spec for a controller we don't yet support can write a new adapter against this interface without touching the rest of the product.

What "read-only by default" means in practice

For the first 30 days of any deployment, every adapter is hard-locked to read-only mode at the configuration level — no agent, no operator action, no forgotten tier setting can issue a write. This is deliberate: it gives the building's own operations team time to validate that AiTBMS's view of the building matches reality before any AI agent touches a setpoint. After 30 days, you graduate adapters individually into write-eligible mode, and even then, every write is gated by the four-tier authority model documented in Tier-gated Control Authority. We never ship a deployment where an agent can write to equipment on day one.

Discovery and onboarding

Onboarding a new building takes two artifacts: a BMS endpoint (URL + read-only credentials) and an equipment list (CSV or, for WebCTRL sites, a Site Builder export). AiTBMS runs an automated discovery pass — typically 2–4 hours for a 10-equipment building — that walks the BMS object tree, infers equipment groupings, tags points against our canonical schema, and produces a discovery report for the operations team to review before any agent goes live. Anything the discovery pass can't classify confidently shows up in a "needs review" queue rather than getting silently mislabeled. This is slower than vendors who promise instant onboarding, and on purpose: a misclassified discharge-air-temp sensor is the kind of error that propagates into every downstream agent decision for months.