Know What Can Connect Before You Commit to Integration
- 01 · Requirement
Protocol names alone do not tell an owner whether specific equipment can be connected or controlled.
- 02 · Failure risk
A protocol label mistaken for proven fit can cause mapping errors, unsafe commands, schedule loss, rework, and a failed integration.
- 03 · Technical method
Protocol support is the start of integration. Building Automation Systems compatibility depends on device, firmware, transport, mapping, authority, failure behavior, cybersecurity, and test evidence.
- 04 · Acceptance evidence
Test the exact device, version, transport, mappings, commands, timing, failure behavior, and security boundary for the stated use case.
Technical detail begins here, with system names, authority, safety, evidence, and operating limits kept in view.
Use this standard to guide a decision, then confirm the project-specific facts and evidence before relying on a claim.
Technical boundary: Published decision standard, not project history, certification, partnership, or customer-result evidence.
Illustrative document—not a customer record, completed test, or delivered building automation system (BAS) handover.
Network, mapping, command, failure, and evidence details matter more than a protocol name alone.
Move from an equipment question to a versioned compatibility decision
A protocol name is only the beginning. The path keeps the exact device, required behavior, test evidence, and limits together.
Truth boundary: No step claims support for a manufacturer, model, firmware version, or command until a named test record exists.
- 01 · PolicyA protocol label is being mistaken for compatibility.
Understand the decision
See the device, version, mapping, authority, failure, security, and evidence factors that matter.
You are here - 02 · PolicyThe reviewer does not have the exact equipment or required behavior.
Prepare the facts
Use the local worksheet to prepare a specific equipment-and-behavior request.
Open this step → - 03 · PolicySupported, conditional, experimental, and unsupported results are being blurred.
Review evidence states
Use the matrix policy to keep scope, date, evidence, limits, and lifecycle visible.
Open this step → - 04 · PolicyNo current public test record covers the use case.
Prepare a test request
Prepare the versioned inputs required for future lab or engineering review.
Open this step →
Start with the decision you need to make
Each path keeps the professional / technical audience, operating impact, current status, and next useful action visible.
Understand What BACnet Support Does—and Does Not—Guarantee
“BACnet” is often treated as an automatic guarantee of interoperability.
Prepare a BACnet Check →Understand What BACnet Secure Connect Requires
Owners need secure BAS communications but may not understand certificate, network, and deployment requirements.
Review BACnet/SC Requirements →
Turn Modbus Registers Into a Tested Building-System Interface
A Modbus register map does not by itself define units, timing, scaling, write authority, or failure behavior.
Prepare a Modbus Review →
Identify What a KNX Integration Needs Before Work Begins
KNX projects require topology, addressing, datapoint, tool, and authority information that may not be available.
Prepare a KNX Review →
Define the DALI-2 Lighting Functions the Building Actually Needs
Lighting integration can fail when device types, addressing, gateways, emergency functions, and command boundaries are unclear.
Prepare a DALI-2 Review →
Define a Safe, Usable OPC UA Building Interface
OPC UA information models, namespaces, security, subscriptions, and control authority vary by system.
Prepare an OPC UA Review →
Define What MQTT Data Means Before Using It for Building Decisions
MQTT transports messages but does not automatically define topic meaning, quality, retention, security, or command safety.
Prepare an MQTT Review →See the Exact Equipment and Versions That Have Been Evaluated
Buyers need specific compatibility evidence, not a list of familiar protocol logos.
Review the Compatibility Matrix →
Prepare the Equipment Information Needed for a Compatibility Decision
Visitors do not know which technical facts are needed to judge compatibility.
Check My Equipment →
Request a Structured Compatibility Test for Specific Equipment
Unsupported or unlisted equipment needs a defined evaluation path.
Prepare a Test Request →Make the supported result and its limits reviewable
Test the exact device, version, transport, mappings, commands, timing, failure behavior, and security boundary for the stated use case.
- BACnet
- BACnet Secure Connect
- Modbus
- KNX
- DALI-2
- OPC UA
Illustrative closeout—not a customer result, case study, warranty, or measured savings claim.
Technical boundary
Published decision standard, not project history, certification, partnership, or customer-result evidence.
Documents and records that support field execution
Use the outputs for coordination, commissioning, review, and later troubleshooting.
Source and destination definition
Versioned point, transport, and authority scope
Test result, limits, failure behavior, and support status
Define, test, record, and close the technical gap
Use this standard to guide a decision, then confirm the project-specific facts and evidence before relying on a claim.
Capture requirements
Record the exact device, version, transport, mappings, and required functions.
Test the stated use case
Define data, command, timing, failure, cybersecurity, and ownership boundaries.
Publish the supported result
Test the stated use case and publish the supported result with limits and review date.
Reduce rework and make acceptance easier to defend
Requirements, interfaces, tests, exceptions, and handover stay connected to the decision.
Understand the exact device, version, transport, point scope, authority, failure behavior, and test status required.
Versioned compatibility testing confirms the exact equipment and software combination before support is promised.
Documented read, write, timing, and failure limits protect the building from unsafe integration assumptions.
Test the exact equipment before promising integration
A protocol name is not a compatibility result. The record must bind the device, version, transport, point meaning, write authority, failure behavior, security boundary, and named evidence.
Truth boundary: Illustrative record only. It does not claim support for a manufacturer, model, firmware version, protocol combination, or control function.
- 01 · Identify
Freeze the exact combination
Manufacturer, model, firmware, software, gateway, transport, and network role are recorded together.
- 02 · Define
Describe the required behavior
Points, units, timing, alarms, trends, commands, priorities, fallback, and authority are made explicit.
- 03 · Evaluate
Run a bounded test
The test plan states the environment, tools, reviewer, acceptance criteria, safety boundary, and rollback.
- 04 · Publish
Version the result and limits
Status, test date, evidence, exceptions, lifecycle, and retest triggers travel with the decision.