How smart building projects fail
The failure mode is almost always the same: a project that looked straightforward at tender stage turns out to involve legacy equipment with undocumented Modbus maps, a BMS that won't accept third-party BACnet devices without a firmware update the OEM charges for separately, a DALI bus that was wired with the wrong cable causing address collisions, or a LoRaWAN gateway placed by someone who assumed RF propagation works like WiFi. These aren't unusual problems — they're the standard reality of integrating systems designed by different teams at different times for different purposes. The mistake is treating them as exceptional.
What independent diagnosis adds
The people already on site when a project breaks down are usually those with the most to lose by admitting the problem. A contractor whose commissioning engineer has been on site for eight weeks won't easily write a report that says the specification was incorrect from the start. An independent assessment removes that conflict and can state what the actual cause is, what it will take to fix it, and what the sequence of remediation should be — in a document that all parties can act on rather than dispute.
Common failure patterns
BACnet integration failures
- MS/TP bus collisions from duplicate MAC addresses or missing termination
- Controller firmware incompatibility with third-party BACnet clients
- Object identifier conflicts from unconfigured controllers
- BACnet/IP routing failures across VLANs
Modbus mapping failures
- Register map version mismatch between document and actual firmware
- Endianness errors in multi-register values (float, 32-bit integers)
- Coil vs holding register confusion in control sequences
- Cable length exceeding RS-485 specification causing intermittent errors
Wireless network failures
- LoRaWAN gateway coverage gaps from poor site survey
- Bluetooth Mesh network partitioning from node spacing errors
- RF interference from co-located 2.4GHz equipment
- Payload decoding errors from incorrect device profile
DALI bus failures
- Bus short circuits from wiring errors
- Address conflicts from uncontrolled recommissioning
- Gear type code mismatches causing emergency lighting test failures
- Bus overload from too many devices or incorrect power supply rating
Spektris works independently of all parties on a project. The diagnosis report is written to be technically accurate and useful, not to protect any particular position. That independence is what makes it actionable.
The diagnosis process
A typical troubleshooting engagement involves: a documentation review (specification, points list, commissioning records, any existing fault reports), a site visit with appropriate test equipment (network analyser, BACnet browser, DALI controller, oscilloscope), a structured test sequence against each suspected failure mode, and a written report within five working days of the site visit. The report identifies root cause, quantifies the scope of remediation required, and provides a prioritised action plan.