Why Smart Building Commissioning Is Just as Important as the Hardware
Here’s a scenario that plays out more often than anyone in the industry likes to admit. A building owner invests in a well-designed PoE lighting system with quality hardware, the right switch infrastructure, and a solid floor plan. Installation goes cleanly. Then the system gets handed off, and within six months the building owner is calling the integrator because zones aren’t responding, lights are coming on at 4am for no apparent reason, and nobody can explain why.
The hardware didn’t fail. The smart building commissioning did.
Getting a connected building to perform the way it was designed requires more than pulling cable and powering nodes. It requires a structured process for discovering every device, organizing it into the right zones, configuring it to the right specs, and building the policy logic that makes the whole thing behave intelligently. That process is smart building commissioning, and it deserves as much attention in project planning as the hardware spec sheet.
The Scale Problem Nobody Talks About in Pre-Sales
A mid-size commercial floor might contain 80 to 150 PoE nodes. A campus deployment can run into the thousands. Each node needs to be assigned to a zone, configured with the correct fixture wattage and voltage, mapped to its sensors and wall switches, and tested before the space goes live.
Do that manually, device by device, and you introduce two problems. First, the labor hours become unsustainable. Second, and more damaging to long-term performance, manual configuration creates inconsistencies. One node gets configured at 40 volts, another at 42. One zone has motion unlock enabled, the next doesn’t. Six months later, nobody can explain why the behavior is different across floors.
Smart building commissioning at scale requires a repeatable, centralized process. Without one, even a technically sound hardware deployment becomes difficult to manage, nearly impossible to troubleshoot, and expensive to maintain.
How aida™ Structures the Smart Building Commissioning Process
aida™ is the AI-powered building software from Building AI Solutions that runs on MHT’s Inspextor® hardware nodes. Where Inspextor provides the base platform, aida adds a more robust commissioning environment and AI-driven automation capabilities, including intelligent daylight harvesting for shade control and occupancy-based decision-making. It was built specifically to solve the scale and consistency problems that manual smart building commissioning can’t.
Rather than a general-purpose building management interface, aida is a smart building commissioning platform that structures the process around a seven-step wizard taking a deployment from blank environment to fully operational space.
The first step is network configuration: communication method, protocol selection (CoAP or MQTT Secure for Core Node deployments), and server IP assignments. The platform runs on Ubuntu 22.04 and scales its server requirements based on node count, with a minimum of 8GB RAM and 200GB storage for deployments under 250 nodes. Get these settings right at the start and the rest of the process runs cleanly. Skip them and discovery won’t work.
Step two is the pull schedule, and this is where smart building commissioning either gets built on a solid foundation or doesn’t.
The Pull Schedule: Where Commissioning Actually Starts
The pull schedule is a structured spreadsheet that maps every node serial number to its physical location, control zone, channel configuration, sensor assignment, and wall switch input. Installers fill it out in the field as hardware goes in, recording five-digit serial numbers directly from each node as they mount it.
When that file gets imported into aida, the software does something significant: it automatically creates the entire zone and group structure, then pre-assigns every node to its designated location. On a 1,000-device deployment spread across 40 zones, that would take hours to configure manually. With a clean pull schedule, it happens on import.
The pull schedule also handles the differences between node types automatically. A Node 90 has two output channels and a sensor input. A Core Node has one output channel, one sensor input, and a wall switch input. The template accounts for all of it, and the software reads the “type” column to know what it’s working with before discovery even runs.
This is why experienced MHT integrators treat the pull schedule as a commissioning document, not just a reference sheet. If the pull schedule is accurate, smart building commissioning moves quickly and cleanly. If it’s full of gaps or errors, every step after it costs extra time.
Auto-Discovery and Configuration Templates
With the pull schedule imported, the next step is auto-discovery. The integrator inputs the IP address range for the deployment, kicks off the process, and the platform scans the network, identifies every connected node, and assigns each one to the zone defined in the pull schedule. On a 12-node deployment, that takes minutes. On a 500-node deployment, it’s still the same process, just longer to complete.
Once devices are discovered and assigned, configuration templates handle the next layer of smart building commissioning: telling each node what it’s actually connected to.
A 10-watt downlight and a 50-watt linear fixture are both connected to PoE nodes, but they need completely different output configurations. Configuration templates let integrators define the correct wattage, voltage, color application (static white, tunable white, or RGBW), and emergency mode settings once, then push that configuration to an entire zone in a single operation. A conference room template gets applied to every node in the conference room. A corridor template goes to corridors. An RGBW template handles the architectural lighting package.
The platform logs every configuration push in real time, showing which nodes accepted the template, which are still pending, and which failed. Failures are flagged with enough detail to tell you exactly what command the node rejected, which makes field troubleshooting far more efficient than the alternative of testing each device manually.
Policy Configuration: Making the Building Behave
Hardware configuration tells nodes what they’re powering. Policy configuration tells the system how to behave.
This is where smart building commissioning gets into the logic that building owners actually care about. Lighting schedules. Occupancy responses. Color tuning by time of day. Motion controls that know the difference between a space that’s just empty and a space that should be dark.
aida separates this into lighting policy and hardware policy. Lighting policy handles time-based scheduling: a corridor stays at 80% from 7am to 7pm, then drops to 0% and switches to motion-only after hours. A conference room warms its color temperature at 7am when it turns on and cools it by midday. Those rules get built once and applied to the target cluster.
Hardware policy handles the motion and sensor logic. The motion timer on a conference room gets set to 15 minutes of vacancy before the lights drop out. The behavior mode matters here too: auto-on/auto-off means the lights respond to presence and absence automatically; manual-on/auto-off means occupants turn lights on themselves but the system handles turnoff; auto-on/manual-off flips it. Each space can be configured differently based on how it’s actually used.
The distinction between motion-locked and motion-unlocked in a lighting policy is a good example of why commissioning detail matters. If a policy runs a space at 80% from 7am to 6pm with motion locked, the lights stay at 80% all day regardless of whether anyone is in the room. Motion-unlocked means the same schedule applies, but the system will dim or turn off based on vacancy. The hardware is identical either way. The behavior is completely different. That difference lives entirely in how the system was commissioned.
Operational Visibility: The Smart Building Commissioning Benefit That Outlasts Installation
A properly commissioned smart building doesn’t just work at handoff. It stays understandable over time.
aida maintains detailed logs across multiple categories: CoAP and MQTT command logs that capture every control event the software generates, event logs that record every motion trigger, vacancy event, and manual switch action with timestamps and node identifiers, and access logs that show who logged in, when, and what they did.
When a building owner calls six months after installation and reports that the lights were on at 4am, the event log has the answer. Filter by the affected zone, pull the event history for that time window, and the log will tell you exactly which node detected motion, at what time, and whether it was a sensor trigger or a manual switch action. If someone physically unplugged a fixture from a node output, that event gets captured too.
Inactive node monitoring adds another layer of smart building commissioning value. When a node goes offline, it appears in the monitoring dashboard with its serial number, IP address, and the time it went dark. The platform can push that alert via email or SMS, sending up to three notifications at 15-minute intervals so the right person actually sees it. Combined with remote firmware management, which lets integrators schedule updates after hours without anyone setting foot in the building, the operational picture is one a facilities team can actually act on.
Third-Party Integrations Extend the Value
Smart building commissioning in aida isn’t limited to MHT’s own hardware. The same commissioning environment handles third-party sensor integration, shade control, and API connections to external systems.
Steiner and O3 environmental sensors connect directly to aida, feeding temperature, humidity, lux levels, and occupancy counts into the dashboard. Once onboarded, those sensors can also trigger lighting events: a Steiner detecting occupancy in a space can instruct aida to turn on the lights just as a native MHT sensor would.
Shade integration works through either the manufacturer’s gateway (Somfy and Mako both have gateway-based options) or by replacing the manufacturer’s hub entirely with an MHT node wired directly to the shade motor. Either way, shades get scheduled, positioned by floor plan, and controlled through the same interface as the lighting. One system, one commissioning environment.
For building owners who want to integrate aida data with broader platforms, the software exposes a full API. Light levels, occupancy status, power consumption, shade positions, and RGBW color settings are all accessible through documented API calls, which means a third-party analytics platform or a Cisco Spaces integration can pull live building data without a separate middleware layer. That connectivity is a direct extension of smart building commissioning: a system that was properly set up from the start has clean, reliable data worth connecting to.
Why Commissioning Deserves a Seat at the Table Earlier
In most smart building projects, commissioning is treated as a phase that happens after everything else is done. Hardware is selected, installation is planned, and commissioning gets scheduled for the tail end of the project timeline with whatever budget is left.
That sequencing creates problems. A pull schedule that hasn’t been thought through before installation starts means installers aren’t recording serial numbers in the field. A configuration template strategy that gets invented on-site rather than planned in advance means the commissioning team is building the process while also executing it. Policies that aren’t discussed with the building owner before handoff mean the system gets configured to generic defaults that don’t match how the spaces actually get used.
Integrators who go through MHT’s certification training understand smart building commissioning as a design discipline, not a post-installation task. The pull schedule gets built alongside the fixture schedule. Configuration templates get mapped to space types before anyone pulls cable. Policy requirements get documented as part of the scope. That planning doesn’t just make commissioning faster. It makes the system perform better from day one and stay manageable for years afterward.
The hardware powers the building. The commissioning determines what it actually does.
This is the third in a series exploring intelligent PoE infrastructure for smart buildings.
Read Part 1: Why the Smartest Buildings Run on PoE Infrastructure.
Read Part 2: Inside the MHT PoE Hardware Platform for Intelligent Buildings.
MHT Technologies designs and manufactures intelligent PoE infrastructure solutions for commercial, hospitality, healthcare, and enterprise environments. The MHT platform includes the Inspextor® PoE hardware family and the aida™ AI-powered building management software. Learn more at mhtechnologies.com.