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.
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.
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.
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.
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.
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).
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.
Copyright © 2000-2014 Tridium Inc. All rights reserved.