Overview
In early 2025, a persistent communication issue was reported at a multi-use commercial building in Central London. The site, which utilises a hardwired M-Bus (Meter-Bus) network to collect data from various heat, water meters, began experiencing system-wide data retrieval failures. These failures were impacting not just billing and energy monitoring accuracy but also building performance analytics.
An on-site investigation revealed that a single faulty heat meter was the root cause—but identifying that meter required an extensive fault-finding process, including physical disconnection of parts of the network, manual downloads, and detailed network analysis.
This case study explores the fault, the investigative process, tools used, and the lessons learned from a technical standpoint.
Site Background and Network Setup
The building’s data collection system was configured to read over 350 M-Bus slave devices via a central master M-Bus gateway. Devices on the network included:
Ultrasonic heat meters
Pulse converters
Cold and hot water meters
The M-Bus network was hardwired in a daisy-chained topology, common in retrofitted commercial sites. Cabling routes followed vertical risers and horizontal distribution arms across several floors.
The data logger M-Bus gateway was set to poll devices at regular half-hourly intervals, storing and relaying consumption data to a cloud-based energy monitoring platform hosted by Sycous.
Symptoms and Initial Observations
The Product and Data Support team first noticed an increasing number of timeout errors from the gateways interface. Initially limited to a few devices, the problem worsened over the course of several days until approximately 30% of the devices failed to respond entirely throughout the day and often intermittency on half hourly readings.
Key symptoms included:
Sporadic or complete loss of communication with multiple meters
High retry counts from the M-Bus master
Voltage fluctuation alerts on the bus
Instances of garbled or corrupted data responses
Due to the nature of M-Bus communications, where all slaves are powered by and respond to two single M-Bus masters over two-wire communication, a single or multiple faulty or shorted devices can disrupt the entire bus, leading to widespread issues.
Engineer Deployment and Diagnostic Approach
A senior Sycous engineer was called to the site to isolate the root cause. The diagnosis process involved the following key steps:
1. Visual Inspection and Documentation Review
The engineer began with a visual check of accessible network cabinets and distribution boxes. Cabling appeared intact, with no immediate signs of physical damage or termination issues. Fortunately, the site had partially up-to-date M-Bus schematics showing device addresses and approximate locations—this proved critical in guiding the investigation.
2. Isolation Testing via Physical Network Splitting
The next step was to split the M-Bus network into smaller segments. Using labelled junction boxes and termination points, the engineer physically disconnected branches of the M-Bus line to isolate specific groups of meters.
This “divide and conquer” method allowed them to:
Restore communication on unaffected branches
Identify the segment(s) that continued to cause disruptions
Eliminate known good areas from suspicion
After splitting the network into three zones—Basement & Lower Floors, Mid-Levels, and Upper Floors—it became evident that the issue was isolated to a portion of the mid-level network.
3. Use of Portable M-Bus Reader for Manual Polling
To further narrow down the fault, the engineer used a portable USB M-Bus Master interface (with diagnostic software such as MBSheet or similar) to manually poll individual meters within the isolated segment.
This tool allowed the engineer to:
Detect valid M-Bus slave responses
Monitor bus voltage at specific locations
Log communication retries, corrupt packets, and address conflicts
As meters were reintroduced one-by-one to the test bus, the engineer noted a significant voltage drop and communication failure when a particular heat meter—an ultrasonic compact unit installed behind a HIU panel—was connected.
4. Confirmation of Faulty Meter
With the problematic meter connected, the M-Bus master would consistently drop voltage from its nominal 36V-42V range to under 15V, rendering other meters unresponsive. The meter itself provided no response when polled directly and appeared to have a short circuit or internal communication fault.
Once disconnected from the network:
Bus voltage normalized
All other meters in the zone communicated successfully
Data Logger (M-Bus gateway) logs showed clean, uninterrupted polling
The engineer confirmed that the meter’s internal communication board had failed, likely due to a surge or internal component fault.
Resolution and Next Steps
The faulty meter was left physically disconnected from the M-Bus line and isolated for replacement. Meanwhile, the Product and Data Support team at Sycous updated the meter status on the platform to indicate “Fault - Offline.”
Recommendations to the site included:
Immediate replacement of the failed heat meter
Routine use of portable diagnostic readers during network commissioning
Scheduled preventative maintenance checks
Key Learnings
This case highlights several important lessons for building services teams and contractors working with M-Bus systems:
Single or multiple Device Faults Can Cause System-Wide Disruption
Even one faulty slave device can bring down an entire network, making it essential to plan for fault-tolerant topologies and quick diagnostics.Segmented Network Design Aids Troubleshooting
Strategically placed junction boxes and isolation points enable rapid segmentation, which can drastically reduce fault resolution time.Manual Tools Remain Essential
Portable M-Bus readers and network diagnostic tools are indispensable for field engineers. Software tools alone, especially those relying solely on the central data collector (M-Bus master), may not offer sufficient granularity to isolate faults.Up-to-Date Schematics Are Crucial
Without a reasonably accurate map of meter locations and addresses, fault-finding becomes exponentially harder.
Conclusion
This real-world issue underscores the importance of proactive maintenance and thoughtful system design when deploying hardwired M-Bus infrastructure. While the protocol remains highly effective for metering and monitoring in complex buildings, engineers must be equipped with the right tools, documentation, and techniques to quickly identify and isolate faults when they inevitably occur.
Have an issue at your MBus network? Need help with intermittency reading? Call Sycous today on 0333 880 3115