After the MUC500 was installed, 400 meters were connected and 150 of them were made readable in the second service job, the remaining 400 meters should be connected to the system in a final job.
Service job 3:
Normally you simply scan the M-Bus for meters and then have the meters recorded. But it turned out differently. When I noticed that the meters could not be found by primary or secondary selection and that even a direct query of the serial numbers was unsuccessful, it was clear to me that there must definitely be a physical problem.
So, together with the property manager, I created a list of the meters and their installation locations. Such an overview helps to localize error patterns and to go to specific locations.
First, however, I checked the remaining repeaters again. The meters should be connected there. If the meters are connected, it must be possible to prove this by measurement. To do this, I checked incoming M-Bus lines and measured the current in the idle state.
Here is a small sketch of the current measurement:
In principle, EN 13757-2 defines a unit load (UL) at 1.5 mA. This is the power consumption which a meter should not exceed in the idle state.
So, I was able to roughly estimate how many meters there are on one line. The measurement result showed a valid range, but one effect was noticeable: During the current measurement, I could detect a pulse-like power. This should not be seen on M-Bus lines. Because without a request from a master, no M-Bus meter may send anything on the bus, i.e. to modulate the current. Since the readout was not active at the moment, this indicated a faulty / wrong device or a faulty installation.
After several attempts to locate the problem by disconnecting the bus lines, it turned out that control lines of the smoke extraction system were clamped in an M-Bus junction box and thus probably interfered with the bus. I removed these lines.
After the interfering signal was gone, I immediately received the rest of the meters connected to this line. So, the problem was solved. Very good, I thought to myself. There were now another 350 meters in the system. After I could not find any further errors on the repeater strings, but there were still some meters that were not integrated, I started to check the meters on site.
This resulted in further error scenarios:
Some meters showed abnormalities. Briefly summarized, there were 4 error causes:
- The meter is M-Bus-capable, but there was no M-Bus supply line.
- The meter is not M-Bus-capable, but was used in that way.
- The meter is M-Bus-capable, but was defective, so it did not respond to master requests.
- It was a pulse meter that was clamped to the M-Bus.
The consequence was to replace the meters or to relocate the supply line. This was done by the system operator in consultation with us.
The cabling was also not carried out correctly in all parts. The used control cable with 4 wires, two of them were used, and the incorrect handling in the junction boxes was another cause of the error:
- Coming from the master, the red and black wire pairs of a J-Y-ST-Y 2x2x0.8 mm² were used for M-Bus.
- In one of the junction boxes, red and black were no longer used, but green and white for the meters.
The red and black were then connected to the meter again. I was able to fix the error by using red and black throughout.
At the end of my third service job, all meters could now be read out and the problems could be solved. I finally did it. There was now an error-free M-Bus network with a system that reads 800 meters, except for a few that had to be replaced, and reports meter data on a daily basis.
This example shows that complex M-Bus networks sometimes require several service jobs to establish error-free M-Bus communication. And at the beginning of a support case, you never really know what to expect. But this is what makes my work so exciting and varied.
At the end of my blog post I would like to show you a snapshot of my service job. Here I checked a meter in the false ceiling and the feet that can be seen are of course mine. ?
