Mbus Driver Guide

Frequently Asked Questions

Is my meter fully supported?

The chances are that your meter is supported providing that it is fully compliant with the MBus standard. However the standard does allow for Manufacturer Specific Data which may not be supported. Please refer to Meter Installation Notes for further information.

Why does the Discovery process have two major operations?

The reason for having to carry out a detection phase before the normal Niagara Discovery phase, is because of the inherent delays required in the system. These delays make it necessary to provide the operator with additional facilities to add MBus slave units (meters) into the network on a unit-by-unit basis. For example, some slave units require a time period of at least 10 seconds between messages, thus having transmitted the initialisation message, the driver follows this up with an "are you there" message. This is followed up by two individual requests for data which are sent with differing FCB bit values. All this gives a communications period in excess of 40 seconds just for a single slave device! A full primary search of a potential 250 devices could take over 2 hours at this rate. The Network Manager therefore first carries out a selective search for the slave units and then the Niagara Discovery operates on all detected devices.

Why does Niagara not discover my device on a TCP/IP Gateway?

TCP/IP Gateway's are typically configured to run at a given baud rate, set by proprietary tools to the gateway. The baud rates that both devices are set to should match. All devices that conform to the standard, should be able to run at 300 baud however some will not do this automatically, and they may need the baud rates manually setup with the relevant tools to the meter / gateway.

How do I add a Slave Device into the network?

Please see the discovery section.

If you know the primary address of the device and it is known to be unique, it is recommended to use the primary address discovery and set the specific address as the 'start' and 'end' addresses.

If the primary address is unknown, the preferred method is to connect the device to the bus, on its own. Then perform a single device discover. Should this not be possible, a secondary discovery should locate the device as long as wild-card addressing is supported by the device.

If the device's primary address is not unique, or it has a value of "0" then the BMbusNetwork Action "Assign Address" with the device connected to the bus, on its own should be used to allocate it a valid unique number. Alternatively it should be possible to do this to a device currently addressed using secondary / secondary extended addressing.

Should the device not have a unique Primary Address then the new Slave device must be connected into the network, without the device of the same address being connected, and its Primary address changed using the facilities provided.

I cannot discover my device after connecting it individually via a Serial interface

  • Attempt scanning at all available baud rate's
  • The majority of meters will react to the "standard timings", however some will require longer timeouts in which case try selecting the "Slow timings". (This has been seen in, for example Kamstrup based meters.)
  • Finally, should you be unsuccessful with standard or slow timing settings, refer to the meter's manual and customise the timings based on what you can find. Here are some individual settings:
  • Points remain in stale, or enter fault after a reboot with a 'null' response in the proxy extension

    This is usually a consequence of the system not waiting long enough for a response. Suggest increase the 'Response timeout' setting for the device, under its MBusConfig if it is enabled, or otherwise under the network.

    How unique is my Parameter?

    The MBus driver software uses the Units, Description, Orthogonal Description and Record Number to identify a parameter. This identity must be unique unless the parameter is part of a data block/array (this will also be compliant with the needs of the storage block e.g. length of block, start time, time interval, position in block). The block cannot traverse message boundaries (all elements of the block must be in the same message and follow contiguously).

    Why does the Relay MBSheet software read data faster than with this Niagara driver ?

    At the time of testing, the Relay "MB Sheet" software did not fully support the MBus standard because it did not support "continuation blocks". This meant that it read the first set of data only, where as the Niagara driver continues to read the continuation blocks until all are input. Thus the Relay seemed to complete the reading task quickly but was incomplete. Because of the inter message interval required by some meters, the Niagara driver has added the required interval between each "continuation block" and this can amount to several minutes before all data is read and then updated to the GUI.