In this blog post “A second master in M-Bus, is not possible? It is possible!”, we portrayed our data concentrator MBUS-GSLE.
Here is a brief wrap-up:
You may have run into this problem before: all properties within a Facility Management System are to be visualized and monitored centrally. In some installations, meter data are already captured by M-Bus and processed by a building management system (BMS) or building automation. However, neither the readout system nor the BMS dispose of an interface to actively forward the data to the Facility Management System or to provide the data. You are not authorized or you are reluctant to modify the existing system, but you are in dire need of the data of the existing meters.
To access the data of the meters, the meters must be queried via the M-Bus interface in parallel. This is highly critical for the M-Bus as only one master governs the bus. A remedy consists in parallel access on the M-Bus. This is precisely where our MBUS-GSLE fits in.
The MBUS-GSLE is an M-Bus master capturing the data of connected meters and forwards these data upon request via the M-Bus slave interface to another master. The existing master can operate undisturbed, but is fed the data from the slave interface of the MBUS-GSLE.
Today, we would like to point out a new aspects worth noting:
The readout cycle of the existing master and the MBUS-GSLE should be harmonized.
For instance, if the existing master takes a readout every 15 minutes and the MBUS-GSLE once per hour, then the existing master will receive identical data for 3 out of 4 readouts. It is thus recommended that the readout interval of the MBUS-GSLE is always a bit shorter than the readout interval of the existing master.
So far so good. But how are the data from the GSLE fed into the Facility Management System?
Initially, all meter data are stored in a local database. The transmission of the data can be configured in up to 10 report instances that can be configured independently. Depending on the interface available in the Facility Management System, diverse protocols like FTP, MQTT, SMTP (e-mail) and TLS can be employed. Should the standard protocols not match to 100%, individual variants can be coded. The Scripting function serves this purpose. We will elaborate more closely in the following blog post. The data formats CSV, XML and JSON are available. Optionally, the data can be transmitted via Modbus TCP or BACnet.
As stated above, the data are read from the meters and transmitted via the slave interface.
In the following section, we stress a special aspect of the slave interface and give a guideline how to configure it on the device.
In some applications it may be necessary to transmit the meter data at the slave interface via M-Bus and via Ethernet. Besides the cyclic requests of the existing master via M-Bus, the data can also be requested by other systems via Ethernet. This use case is graphically reproduced in the following figure:
A minor configuration is needed via the web page of the device to exploit this function. First, navigate to the tab “Configuration”. In its lower section you find the parameters of the slave interface.
To provide the meter data once via M-Bus and once via Ethernet (TCP/IP), one needs to set “M-Bus slave mode” to “M-Bus” and “M-Bus slave mode (2nd)” to “TCP”. Afterwards, a port must be picked and everything saved.
The following screenshot depicts a readout of the connected meters with the M-Bus tool “M-Tool” via the IP address of the MBUS-GSLE at the selected port 5020.
The active window states: Meter ‘Unknown device’ detected. Meter ‘Unknown device’ loaded successfully.
This blog post highlights how our data concentrator MBUS-GSLE is assigned a particular role as „second“ master and thus aids in solving intriguing demands.
Do you have special demands, further questions or would like to have more information on our products? Give us a ring under +49 3677 7613066 or drop us a line via e-mail to sales@solvimus.de. Our sales team and support are glad to assist you!
