2 Presentation of the device ..................................................................................................................................... 9
3.7Import of a device list................................................................................................................ 22
4 Web-based front end ............................................................................................................................................ 23
4.1Access via HTTPS ........................................................................................................................ 23
M-Bus meters are not found ................................................................................................... 49
M-Bus meters are found, but do not show any data ...................................................... 49
The search takes a long time .................................................................................................. 50
Device restarts during search ................................................................................................. 50
6 Reading meters via wM bus ................................................................................................................................ 51
6.1Signalling via wM bus ............................................................................................................... 51
6.2Troubleshooting the wM bus ................................................................................................. 51
wM-Bus meters are not found ............................................................................................... 51
wM-Bus mounters are found but show no data .............................................................. 52
7 Reading meters via pulse interface ................................................................................................................... 53
7.1Setup of a meter in the web front end ................................................................................ 53
7.2Troubleshooting the pulse interface ................................................................................... 55
The meter does not increment .............................................................................................. 55
8 Reading meters via serial interface ................................................................................................................... 56
8.1Setup of the interface in the web front end ...................................................................... 56
Serial mode ................................................................................................................................... 56
DLDE baud rate, data bits, stop bits and parity ................................................................ 56
8.2Setup of the meter in the web front end ........................................................................... 57
8.3Troubleshooting the serial interface.................................................................................... 59
Meters are not read out ............................................................................................................ 59
9 Transmission of meter data ................................................................................................................................ 60
9.1Instances and database ............................................................................................................ 60
System meter script ................................................................................................................... 87
10.8Media types, measurement types and units ..................................................................... 88
11 Access to meter data via Modbus TCP ............................................................................................................. 92
11.1General information .................................................................................................................. 92
11.2Function codes and addressing ............................................................................................ 92
Why does the value in the Modbus differ from the value on the website? ............ 99
Why does the device/the Modbus server not respond? ............................................... 99
12 Access to meter data via BACnet IP ................................................................................................................ 100
12.1General information ................................................................................................................ 100
This manual provides guidance and procedures for a fast and efficient installation and start-up of the units
described in this manual. It is imperative to read and carefully follow the safety guidelines.
1.2 Legal basis
Copyright protection
This documentation, including all illustrations contained therein, is protected by copyright. The author is
Danfoss A/S, Nordborg. The exploitation rights are also held by Danfoss A/S. Any further use that deviates
from the copyright regulations is not allowed. Reproduction, translation into other languages, as well as
electronic and phototechnical archiving and modification require the written permission of Danfoss A/S.
Violations will result in a claim for damages.
Danfoss A/Sreserves the right to provide for any alterations or modifications that serve to increase the effi-
ciency of technical progress. All rights in the event of the granting of a patent or the protection of a utility
model are reserved by Danfoss A/S. Third-party products are always mentioned without reference to patent rights. The existence of such rights can therefore not be excluded.
Personnel qualification
The product use described in this documentation is intended exclusively for electronics specialists or persons instructed by electronics specialists. They must all have good knowledge in the following areas:
Applicable standards
Use of electronic devices
The solidus GmbH accepts no liability for faulty actions and damage to the described devices and thirdparty products caused by disregarding the information in this manual.
Intended use
If necessary, the components or assemblies are delivered ex works with a fixed hardware and software configuration for the respective application. Modifications are only permitted within the scope of the possibilities shown in the documentation. All other changes to the hardware or software as well as the non-intended use of the components result in the exclusion of liability on the part of Danfoss A/S.
Please send any requests for a modified or new hardware or software configuration to Danfoss A/S.
1.3 Symbols
Caution: It is essential to observe this information in order to prevent damage to the device. Notice: Boundary conditions that must always be observed to ensure smooth and efficient opera-
tion.
ESD (Electrostatic Discharge): Warning of danger to components due to electrostatic discharge.
Observe precautionary measures when handling components at risk of electrostatic discharge.
Note: Routines or advice for efficient equipment use.
Further information: References to additional literature, manuals, data sheets and internet pages.
1.4 Font conventions
Names of paths and files are marked in italics. According to the system the notation is done by slash or
backslash.
An arrow between two menu items or tabs indicates the selection of a sub-menu item from a menu or a
navigation history in the web browser.
e. g.:
File → New
Buttons and input fields are shown in bold letters.
e. g.: Input
Key labels are enclosed in angle brackets and shown in bold with capital letters.
e. g.: <F5>
Program codes are printed in Courier font.
e. g.: ENDVAR
Variable names, identifiers and parameter entries are marked in italics in the text.
e. g.: Measured value
1.5 Number notation
Numbers a noted according to this table:
'0110.0100'
Table 1: Number systems
nibbles separated by dot
1.6 Safety guidelines
The power supply must be switched off before replacing components and modules.
If the contacts are deformed, the affected module or connector must be replaced, as the function is not
guaranteed in the long term. The components are not resistant to substances that have creeping and insulating properties. These include e.g. aerosols, silicones, triglycerides (ingredient of some hand creams). If
the presence of these substances in the vicinity of the components cannot be excluded, additional
measures must be taken. Install the components in an appropriate casing. Handle components with clean
tools and materials only.
Only use a soft, wet cloth for cleaning. Soapy water is allowed. Pay attention to ESD. Do not use solvents like alcohol, acetone etc. for cleaning. Do not use a contact spray, because in an extreme case the function of the contact point is im-
paired and may lead to short circuits.
Assemblies, especially OEM modules, are designed for installation in electronic housings. Do not
touch the assembly when it is live. In each case, the valid standards and directives applicable to the
construction of control cabinets must be observed.
The components are populated with electronic elements which can be destroyed by an electro-
static discharge. When handling the components, ensure that everything in the vicinity is well
earthed (personnel, workplace and packaging). Do not touch electrically conductive components,
e.g. data contacts.
1.7 Scope
This documentation describes the devices made by Danfoss A/S, Nordborg stated in the title.
SonoCollect stands for a communication module, which automatically records customer's consumption
data within the scope of Smart Metering. This is sent via a wide area network (WAN) to the measuring service provider or measuring point provider and, via a local interface, it can also be displayed on a customer
PC.
The so-called SonoCollect 112 is a variant of such a communication module. This is separate from the meter, and acts as the data transport interface. The SonoCollect is the central device for the implementation of
Smart Metering. Its advantage is that the measuring equipment and short-lived wide area communication
are installed in separate devices, and so can be installed or exchanged independently of each other.
The SonoCollect 112 is a modular controller. The device comes in a 4U enclosure (modules) and is intended
for DIN rail mounting (DIN rail 35 mm).
2.1 Delivery variants
The SonoCollect 112 is offered in a range of versions, and so can easily be adapted to the requirements of
the particular property.
Table 3: Abbreviations
*The Variants “EB-WM-80” and “GB-WM-80” includes the BACnet IP communication protocol.
The RS485 interface can be used both for communication (e.g. with a display (optional) and for reading
meters.
2.2 Connectors
The various interfaces of the SonoCollect 112 are on different sides of the device.
The following figure shows the device variants:
Connection cable 2.5 mm²
24 VDC, 100 mA
No galvanic isolation
Table 4: Pin assignments
2.3 Status LEDs
Depending on the version, the SonoCollect 112 has up to 5 status LEDs. These indicate the following states:
green
green
orange (flashing)
orange
Meter reading
Main program is running
Scanning meters
Initialization is running
red (flashing)
red
yellow
green
green
yellow
white
Data connection setup
Low received field strength
Average received field strength
Good received field strength
WAN module switched on (no data connection)
WAN module switched on + data connection (no data traffic)
WAN module switched on + data connection (active data traffic)
*only available in variant with WAN
Table 5: Status LEDs (all models)
In the operating state, the State LED is green and the active LED flashes green briefly during the readout.
The Mode LED indicates the reception field strength when the WAN connection is active at and the Link
LED lights up yellow or white when the WAN connection is active.
2.4 First steps
Power supply
The SonoCollect 112 has an integrated power supply unit and is supplied with 230 VAC (wide input voltage
range). Therefore, initially only the supply of the device must be ensured. The SonoCollect 112 starts automatically after connection to the supply voltage.
By default, following calls are made on system startup:
Configuration of the network interface (Ethernet) via DHCP or static configuration
Initial generation of SSL device keys (needs some time at first startup)
Obtaining the system time via SNTP
Starting the system services
Start of the main program
The main program then provides the entire functionality, including the web interface of the SonoCollect
112.
Network configuration and first access
The SonoCollect 112 can be completely configured via the network interface. This must therefore be configured according to your network. If necessary, ask your administrator.
SonoCollect 112 is set by default to the static IP address 192.168.1.101 (subnet mask: 255.255.255.0,
gateway: 192.168.1.254).
For intuitive operation, a configuration website is available on the device, which can be accessed via
website on the SonoCollect 112, e.g.: http://192.168.1.101
when handling multiple devices under one IP (e.g. commissioning) or different software versions
(e.g. update), you should always empty the cache of the browser (e.g. Ctrl+F5) to prevent an inconsistent display of the website.
The following site opens in the browser:
Figure 2 Website of the SonoCollect 112
The web frontend is described separately in chapter 4. There you will find a detailed overview of the functionalities of the web-based frontend.
In addition, access via SFTP, SCP, FTPS (file transfer) or via SSH (console) is also possible by default:
Figure 3 WinSCP main window after connection establishment
2.5 Specific troubleshooting SonoCollect 112
All LEDs remain dark, the device does not respond.
CAUTION LIFE HAZARD: The testing of the power supply may only be carried out by trained person-
nel.
Switch off the power supply. Remove all cables and antennas except the power supply. Now switch on the
power supply and check the voltage level from 90 to 260 VAC.
Ensure that no faults are caused by the infrastructure, circuit breakers or circuit breakers of the power supply. Test the SonoCollect 112 under laboratory conditions if necessary.
If errors could not be rectified, please contact your local Danfoss customer support.
The Power LED flashes green.
Switch off the power supply. Remove all cables and antennas except the power supply. Now switch on the
power supply and check whether the power LED is now permanently lit.
Now reconnect all cables and antennas one by one and check after each step whether the power LED remains permanently lit.
If the fault actually occurs on the connection of a specific cable, check it more thoroughly. There may be a
fault in the external circuitry, e.g. short-circuit or overload. If necessary, replace faulty cables.
If errors could not be rectified, please contact your local Danfoss customer support.
2.6 Typical application scenarios
The following are examples of how the SonoCollect 112 can be used.
To use the SonoCollect 112, the network and meter interfaces must be parameterized according to your
The SonoCollect 112 can be used for local meter reading.
No control system is required to collect and store meter data. Server services can therefore be deactivated
(Server tab ). Only the local storage of CSV files has to be set up.
The SonoCollect 112 is accessed in this application via a PC that is located in the same network. The current
meter values can thus be monitored via the website in the Meters tab. The CSV files can be accessed via
FTP access, provided logging is active. To do this, connect to the SonoCollect 112 with an FTP client (see
chapter: 6.2.2).
Users can be configured in the user management with the corresponding access rights to allow read access to the meter list (see chapter 4.7).
Remote monitoring without control system
This application case is largely equivalent to the example in section 2.6.1. The only difference is the network infrastructure that is set up between a PC and the SonoCollect 112 (Internet). The PC and the SonoCollect 112 are not located in a physical but in a logical network.
As a rule, routers and firewalls must be parameterized here to allow access from an external net-
work (PC in the Internet) to the SonoCollect 112 in the internal system network. Please ask your administrator about setting up routings, port forwarding, packet filters and firewalls for the individual
services of the product, such as FTP, HTTP and SSH.
If the network is parameterized correctly, you can access the SonoCollect 112 in the same way as in the local application.
Remote monitoring with email dispatch
The SonoCollect 112 can send the meter data as e-mails to any e-mail address. The meter data is stored in
XML format and can be processed as required (see section 9.7).
In order to send emails, the internal system network has to be set up correspondingly (e.g. firewall,
router). Ask your administrator about this.
Remote monitoring with FTP upload
The SonoCollect 112 can also actively upload this data to an FTP server instead of manually downloading
the CSV data. This makes it possible to access and process the files automatically.
For the FTP Upload, on the one hand the internal system network (e.g. firewall, router) and on the
other hand the receiving FTP server must be correctly configured. Ask your administrator about
this.
Remote monitoring with SFTP upload
The transfer of files to a server can also be secured via encrypted communication. For example, it is possible to encrypt the data using Secure Shell (SSH).
The following configuration must be made in the device to use the so-called SFTP.
The SSH and thus the SFTP use the asymmetric encryption and are secured by certificates. Both remote sta-
tions have both a private and a public key. A PKI (Public Key Infrastructure) is used to check the authenticity. This is usually associated with administrative work. Therefore, the authenticity can also be confirmed by
the user.
For this purpose, a finger print is exchanged during the initial connection, which uniquely identifies the
remote station. The finger print is the public key of the remote station. Now the user can manually check
and trust this. If this remote station is a trusted host, its fingerprint must be entered in the file
app/ssh/known_hosts. This is done by adding such a line to the file:
Therefore, the corresponding finger print of the server must first be called in order to be entered into this
file. There are two possibilities:
The finger print is called directly from the server and manually entered into the file
app/ssh/known_hosts.
The server is accessed via SSH from the device and its finger print is accepted. Then the finger print is
automatically written to the file app/ssh/known_hosts.
It can be done directly from the device via the SSH console:
> ssh admin@192.168.2.34 <ENTER>
The authenticity of host '192.168.2.34 (192.168.2.34)' can't be established. ECDSA key fingerprint is
SHA256:HtAa1pkvafJSmAiMJmi1ZvJi6spgf5i0yt/A2rJ/OnY. Are you sure you want to continue connecting
(yes/no/[fingerprint])?
yes <ENTER>
Warning: Permanently added '192.168.2.13' (ECDSA) to the list of known hosts.
Subsequently, an encrypted cyclic upload of meter data can be performed via SFTP.
Remote monitoring with TCP/HTTP transmission
The transmission of XML data per TCP or HTTP is suitable for the direct connection of database systems.
The database servers can thus receive the data directly (XML format see chapter: 6.3.3).
For TCP/HTTP dispatch, on the one hand the internal system network (e.g. firewall, router) and on
the other hand the database server must be correctly configured. Ask your administrator about
this.
2.7 Technical data
General properties
Dimensions/Weight
The casing has the following dimensions (without antenna):
Width: 72 mm
Height: 91 mm
Depth: 62 mm (without antenna sockets)
Weight: approx. 210 or 220 g
Assembly
The device is intended for control cabinet mounting:
Temperature range: -20-70 °C
Air humidity: 0-95 \% relH
Type of protection: IP20
Top hat rail mounting (DIN rail 35 mm)
Electrical properties
Power supply
The device has an internal power supply unit (for pin assignment, see section 2.2):
Voltage: 90-260 V(AC), 50-60 Hz, screw clamps (≤2.5 mm²)
Power consumption: 2 W (idle), max. 10 W
Safety: Overvoltage category 3, protection class 1
Peak inrush-current: <40 A
Galvanic isolation between interfaces and mains: >3 kV
Meter interfaces
The device has various meter interfaces (for pin assignment, see section 2.2):
M-Bus: compliant with to EN 13757-2, max. 80 standard loads (UL), Uspace = 36 V, Umark = 24 V, screw
clamps (≤2.5 mm²).
wM-Bus: compliant with EN 13757-4, 169/433/868 MHz, S, T or C mode, SMA antenna connector for ex-
ternal antenna
S0: compliant with EN 62053-31, U = 24 V, screw terminals (≤2.5 mm²)
DLDERS: compliant with EN 62056-21, mode and UART settings, see section: 4.4, EIA-485, screw clamps
(≤2.5 mm²)
The meter interfaces are not galvanically isolated from each other.
Communication interfaces
The device has an Ethernet communication interface (for pin assignment, see section 2.2):
Ethernet: compliant with IEEE 802.3, 10/100 base-TX, RJ45 connector incl. status LEDs, no Auto-MDIX
Mobile communication: 4G modem, LTE Cat1, Band 2,8,9, SMA antenna connector for external antenna
Further characteristics
Galvanic isolation
The Ethernet communication interface is separated from the meter interface and supply:
Galvanic isolation: 1000 V
Processing unit
The central unit is a microprocessor system:
CPU: ARM9™ architecture, 454 MHz clock frequency
Memory: 128 MB RAM, 4 GB internal eMMC flash memory
Operating System : Linux
Integrated RTC: Power reserve for up to 7 days
Danfoss provides its customers with the Netdiscover tool for easier management of products in the customer network. This tool allows you to find SonoCollect devices in the local network and to manage them.
The installation integrates two additional programs. The Putty and WinSCP programs are installed utilities
for SSH and (S) FTP access. The integration into the Netdiscover tool enables the easy access to the devices
from a central location.
3.1 Locating and accessing devices
When the tool started, it uses UDP broadcast via UDP port 8001 to determine all SonoCollect devices accessible in the local network and displays them in the main window.
Figure 4 Main window of the Netdiscover tool
The UDP broadcast finds all devices on the local network, regardless of IP settings and subnet
masks. Therefore, this function is initially recommended.
The UDP broadcast is usually not forwarded by routers. Therefore, this tool will only find all devices
on the local network in front of the router.
In addition to the MAC address of the devices and their network configuration, the names of the devices
and also the version of the operating system can be viewed. Thus, all devices to be managed can be clearly
identified and assigned.
The name of the devices corresponds to the Device name entry in the General tab (see section 4.2).
Various functions can be called up in the context menu that appears by right-clicking on one of the devices:
Ping:
Starts the ping via ICMP to the device in a separate tab. So testing of connectivity via TCP is possi-
ble.
Web:
Opens the default browser with the IP of the device. The web-based frontend should open (see
chapter 4).
FTP:
Starts WinSCP with the IP of the device or in general. The login data or also its IP must be entered
before connecting to the FTP/SFTP server of the device.
FTP (default):
the admin-user.
SSH:
sole.
Deploy:
Import device list:
Net configuration:
broadcast.
Starts WinSCP with the IP of the device and connects an SFTP with default access data of
Starts Putty with the IP of the device. The login data must be entered to connect to the SSH con-
Starts the mass management of the devices in a separate tab.
Imports a device list into the main window.
Starts in a separate tab for changing the network configuration of the devices via UDP
Depending on the network settings of your PC or your general network infrastructure, the UDP
port 8001 may be blocked. Then calls of the tool are blocked and the main window remains empty.
When a firewall in your network (also directly on the PC) is used, it is to create an appropriate fire-
wall rule. It releases this port to be able to list the devices.
Ask your administrator about the firewall and network configuration.
If access via UDP broadcast is not possible, a list can be imported with the Import device list func-
tion in order to still be able to use all other functions via TCP.
Some important functions are described in more detail in the following subsections.
3.2 Network configuration
It is often necessary to adjust the network settings of the device for further work with the devices, especially when commissioning devices.
The command
network configuration. Thus, IP address, subnet mask or gateway address can be changed statically or
DHCP can be activated to obtain these settings automatically from a DHCP server.
Net configuration from the context menu in the Netdiscover tool opens another tab for the
Figure 6 Network configuration via the Netdiscover tool
Modifications are only accepted with the password of the admin user.
3.3 Access to the web-based front end via HTTP
A web server is integrated on the SonoCollect devices. This enables the configuration of the devices via an
integrated, web-based front end (see chapter 4).
Use the command
default browser.
Web
from the context menu in the Netdiscover tool to quickly and easily call it from the
If the web-based front end does not open, please follow the instructions in section 4.13.
3.4 Access to the file system via FTP
The SonoCollect devices can be accessed via FTP to work directly on the file system level. Updates, special
configurations and function extensions can be carried out (see chapter 10). The integrated FTP server of
the devices supports both FTP and SFTP.
If access via FTP or SFTP is not possible, check especially the IP settings and the port release of port
21 for FTP and 22 for SFTP.
In case of access problems, ask your administrator.
The commands
gram and use the IP address of the selected device. Always use the selected device to have access via FTP.
To use a secure SFTP, the context menu must be called without a selected device, then only the command
FTP
is available. Now select in the WinSCP window whether FTP, SFTP or SCP should be used.
The mode
any access data can be entered.
FTP
and
FTP (default)
FTP (default)
tries to log in with the default access data of the admin user, while in the mode
from the context menu in the Netdiscover tool start the WinSCP pro-
FTP
Figure 7 Entering user data when logging in via SFTP
If the access data of the admin user is modified, the use of FTP (default) is not possible.
WinSCP now establishes a secure SFTP or unsecure FTP connection. When a connection is established to a
specific device with SFTP, its authenticity is checked using stored certificates. Normally, the SonoCollect
devices receive an individual, self-signed certificate upon delivery. This certificate is usually classified as untrusted by your PC. Therefore, a security prompt with information about the device's certificate is
displayed. The user must actively trust this certificate for the connection to be established. The confirmed
certificate is stored in the PC for future connections.
Figure 8 Safety query for the certificate of the device
WinSCP presents a two-part file browser view after successful login. This allows files to be uploaded to or
downloaded from the device. File commands can be executed via a context menu (e.g. copying, renaming
or editing. Drag&Drop for uploading and downloading is also supported.
Changes to the files or the file system can limit the functionality of the system.
The standard access data in the delivery state are contained in the section 4.8.
3.5 Access to the command line via SSH
Access to the command line interface (CLI) of the device is suitable for maintenance purposes.
The command
establishes a connection to the device.
When a connection is established to a specific device with SSH, its authenticity is checked using stored cer-
tificates. Normally, the SonoCollect devices receive an individual, self-signed certificate upon delivery. This
certificate is usually classified as untrusted by your PC. Therefore, a security prompt with information about
the device's certificate is displayed. The user must actively trust this certificate for the connection to be established. The confirmed certificate is stored in the PC for future connections.
SSH
from the context menu in the Netdiscover tool opens the integrated Putty client and
Figure 10 Safety query for the certificate of the device
Now the Putty client opens where the SSH access data of the admin user must first be entered. Then. the
command line is ready for input via SSH.
Figure 11 Command line in the Putty client
Inputs on the command line can restrict the functionality of the system.
The standard access data in the delivery state are contained in the section 4.8.
3.6 Mass management
Using this function it is possible to perform certain device configurations or firmware updates in parallel for
all devices displayed in Netdiscover. This makes it possible, for example, to import an exported device configuration to other devices at the same time. Another example would be importing certificate files needed
on multiple devices to export meter data. A third and final example would be updating the application
software on multiple devices in parallel.
The configuration or update should only be carried out explicitly for similar devices.
In this case mark the devices in Netdiscover on which you want to perform a parallel configuration or firmware update.
Figure 12 Selection and call of the mass management
The
Deploy
ment.
command from the context menu in the Netdiscover tool opens another tab for mass manage-
Figure 13 Mass management via the Netdiscover tool
The following input fields and buttons are available here:
Upload: The configuration or update to be uploaded.
HTTPS: Selection field whether HTTP or HTTPS should be used.
CA: The CA certificate to verify the client certificate of the devices for HTTPS-based work.
Login: User name and password for the admin user.
Start: Starts the process.
Abort: Cancels the process.
Close: Closes the mass management tab.
In the central part, there is a list view with information about the devices and the status/progress of the operation.
Only *.tar.gz archives are intended for uploading to the device.
The file is unpacked on the device after the upload, and processed, the device is then restarted.
3.7 Import of a device list
Devices cannot always be found automatically. Firewalls, routing settings or also the deactivation of the
function
A device list can be imported in order to still be able to manage devices via the Netdiscover tool.
Network discovery active in the
Security
tab (see section 4.7) are possible causes.
Figure 14 Viewing and using an imported list in the Netdiscover tool
A suitable CSV file must first be created before the actual import. A comma or semicolon can be used as a
separator in the CSV file. The device data is entered here according to the following example to obtain the
above list in the Netdiscover tool:
Many products of Danfoss A/S, especially data concentrators and gateways for smart metering, have an
integrated web server and provide a website for the configuration. The devices can be configured easily
and in a user-friendly manner via this website. Device parameters, meter configuration as well as service
services can be displayed or changed on this website.
This chapter contains an overview of the operating options via the web front end.
The use of some functions listed below depends on the product. A gateway for example does not
have a report interface for data push or a cellular modem. This is indicated at the relevant point.
The web front end can be easily opened in the browser by entering the device IP address. Alternatively,
right-click on the device in our Netdiscover tool (see chapter 3
text menu to call the browser.
) and select the
We test the web front end in different browsers. We recommend the use of the Chrome and Firefox
browsers for optimal viewing.
In the delivery state, the browser automatically logs the user into the website using the standard access
data. The user "`web"' with the password "`web"' is stored ex works for this purpose. This user has full access to the website. This facilitates the initial commissioning.
If the default user "`web"' has been changed in the configuration via the tab
the password, the correct access data must be entered in order to log in. Then, the automatic login will not
take place. A login window will then always appear:
Web
command in the con-
User
, for example by changing
Figure 15 Login window
To change an already logged-in user (or default user), the Logout button in the top right can be
selected.
The standard access data in the delivery state are contained in the chapter 4.7.
If the logged-in user has write access, the user must be logged out after the configuration has finished. If
the connection remains active, no other work computers have write access to the web front end. Only one
session with write access is possible at a time.
If a session is terminated without prior logout, e.g. by closing the browser window, it remains ac-
tive for approx. 1 min. Afterwards it is automatically closed and write access is possible again.
The functions are subdivided into different tabs on the website of the device. So the clarity can be maintained despite the large number of parameters. All modifications in one of the tabs must be saved before
changing tabs, otherwise the modifications will be lost. The functions and parameters of the individual
tabs are described below.
4.1 Access via HTTPS
Normally the web front end is accessible via HTTP (port 80) as well as via HTTPS (port 443). Depending on
the requirements, one of the services can be deactivated (see section 4.10).
Compared to HTTP, HTTPS offers both encryption and authentication methods and thus enables secure
access to the devices in insecure networks.
The SonoCollect devices are delivered with certificates and keys in preparation for HTTPS access:
app/keys/http_host_cert. : Self-generated certificate of the device to verify the identity of the de-
vice, server-side authentication
app/keys/http_host_key. : Private key of the device
Serial number of the device (MAC address), not editable
DHCP
Enable automatic network configuration
IP address
IP address of the device, not editable with DHCP
Subnet mask
Subnet mask of the device, not editable with DHCP
Gateway IP address
IP address of the default gateway, not editable with DHCP
DNS IP address (primary)
IP address of the primary DNS server, not editable with DHCP
DNS IP address (secondary)
IP address of the secondary DNS server, not editable with DHCP
VPN
Activates the OpenVPN client functionality
Free space log (kB)
Free space on the log area, not editable
Free space Flash (kB)
Free space on the application area, not editable
System date (local)
Current, local system date
System time (local)
Current, local system time
Log mode
Detail depth of the log entries of the application
The user can upload another certificate to the device to fully secure the communication and for mutual authentication.
app/keys/http_host_ca. : Root certificate to check the client certificate of the browser and thus the
identity of the client, client-side authentication
Based on these files, a protected identification and authentication of the communication partners takes
place and a symmetric session key is negotiated.
Access to the web front end via HTTPS can be blocked by installing incorrect or invalid certificates. Deactivating HTTPS or HTTP is only possible via the other access to the web front end. Optionally, customer-specific certificates can be uploaded before delivery.
4.2 General tab
The General tab displays general properties of the device and its network configuration.
Figure 16 General tab
The following values can be viewed or changed here:
SNTP server Address of the time server
None: The application does not generate log entries
Standard: The application generates log entries for errors and warnings.
All: The application generates log entries for all events
Table 6: Fields in the General tab
The Save button is used to save the configuration. The Reload command loads the last saved values and
resets the current changes.
System: Monitoring of internal measured values of the device
S (Status)
Shows the status of the meter or the meter value
Serial
Serial number of the meter (meter number, secondary ID)
MAN
Manufacturer of the meter (abbreviation), DLMS Flag-ID
Medium
Meter medium, see second column in Table 25
Version
Version number of the meter
Link
Primary address of a meter (M-Bus) or reception field strength (RSSI) for wM-Bus
Value
Meter reading or measured value (unscaled)
Scale
Scaling factor (scientific notation)
Unit
Unit, see second column in Table 27
OBIS-ID
OBIS code in the format X-X:X.X*X (X=0..255)
If the network configuration is changed, the device is available under the new IP after the save process. All
existing connections will be disconnected or logged in users will be logged out automatically.
Changing the network parameters of the device can restrict the accessibility. If the network param-
eters have already been set correctly by an administrator, they should not be changed.
The device is automatically reinitialized by setting the parameters via the SAVE button. Date and time are always processed as UTC time (without time zone shift). When displayed on the
website, the browser converts it according to the locally set time zone of the computer. In Central
Europe, for example, this is Central European Time or Central European Summer Time. If a different
time zone is set here, the time on the website will also be displayed accordingly.
The use of OpenVPN is described in the section 10.5.
4.3 Meter tab
The Meter tab displays an overview of the connected meters, and gives the user the possibilities of automatically searching for meters, adding meters manually, and configuring meters that are already present.
The meter list can additionally be exported in this way.
The meter list is displayed in tabular form. Meter entries and the corresponding meter value entries are displayed one below the other. The individual columns have the following meaning:
M-Bus: wired M-Bus according to EN 13757-2/-3/-7 and OMS
wM-Bus: wireless M-Bus according to EN 13757-4/-3/-7 and OMS
DLDE: wired serial interface according to IEC 62056-21 or IEC 1107/61107
S0: wired meter/pulse interface according to IEC 62053-31 or for simple contactors
!: Meter or not all meter values can be read, meter value not current
E: Meter/meter value edited
A: Meter/meter value added
*: Meter value list limited (see Maximum value parameter count in Configuration tab)
Classified as Business
Encryption key Key for encrypted wM-Bus meters
Cycle
Readout interval in seconds (at 0 the general readout cycle is used, see Configuration tab)
User label
User defined description of the meter value, this allows an application specific assignment.
Description
Description of the meter value according to the second column in Table 26. The display of memory
Configuration tab.
Idx
Index/position of meter/meter value in the meter list
Register
Offset of the register set to the value when using the Modbus server
BACnet
Object number of the value when using the BACnet server
Active
Activates a meter or meter value for transmission to the server or logging.
Allowed characters are: A-Z, a-z, 0-9, !,§,\$,\%,\ ,/,(,),=,?,+ and *. A comma is also allowed.
Inadmissible are: $\langle$, $\rangle$ and ".
When using the CSV format, the semicolon (or the corresponding separator) should not be used.
number, tariff, value type and raw data can be configured via the Description mode parameter in the
Table 7: Columns in the Meter tab
The meter configuration can be changed with the buttons in the lower area or through the context menu.
Individual meters or meter values can be automatically searched for, created, deleted or changed according to the limitation of the interface used (M-Bus, wM-Bus etc.).
The meters or meter values in the list can be selected by a simple mouse click. A range can be selected with
SHIFT> key held down, or multiple meters can be selected with the <STRG> key held down.
the <
Duplicates of the serial number are marked in yellow for easier checking of the meters created. With the
Search button the complete meter list can be searched for a search text. Hidden entries are also searched
(meter values of closed maters).
Reload loads the last saved values, resets current changes, and correspondingly updates the meter values.
In the delivery state, the device has an empty meter list. If meters are connected via the external interfaces
of the device, the
Configuration
Scan button can start an M-Bus scan. The scan mode "M-Bus mode" is configured in the
tab. More information on this can be found in chapter 6.1.1.
Depending on the mode and the number of connected meters, this may take a very long time.
The process can be interrupted with the Cancel button, whereby the meters already found are saved in the
meter configuration. After the scan, the meter configuration is immediately accepted, and only has to be
saved again after further changes. The scan can add meters to the existing meter list but no already configured meters are deleted or changed. Newly found M-Bus meters and their values are automatically activated after the scan or are assigned a Modbus address or BACnet number. The scan also permanently adds
newly received wM-Bus meters to the configuration, provided that the parameter wM-Bus listen in the
figuration
tab is activated. Since wM-Bus meters are not necessarily your own, they are not automatically
Con-
activated, unlike the M-Bus. The list mode initially only lists all received meters without permanently saving
their configuration.
The meter values of M-Bus and wM-Bus meters are arranged in the same order as the data in the M-
Bus or wM-Bus protocol. This means that the meanings of the values can be directly compared with
the data sheet of the relevant meter. Alternatively, the arrangement can be via the raw data of the
meter values (see Description mode parameter in the
Configuration
tab in chapter 4.3).
The time stamps transmitted in the M-Bus or wM-Bus protocol are automatically assigned to the
individual measured values, and therefore not listed in the meter list by default. The explicit representation of all time stamps can be manually activated via the configuration parameter
MUC_SHOWTIMESTAMPENTRIES (chip.ini) (see chapter 8.4.1).
Newly received wM-Bus meters are deactivated by default, and have to be manually activated and
saved in order to be transmitted in the server communication and log data. Non-saved wM-Bus
meters are deleted after a restart.
Meters not found and meters not connected via interfaces which do not allow an automated search, can
be added manually with the
can be found in chapter 6.1.3.
Add button or with
Add meter
in the context menu. More information on this
To configure individual meters or meter values, double click an entry or call the Editing window with the
Edit
context menu item
Individual fields are activated or deactivated according to the interface.
. The field descriptions correspond to the columns of the meter list (see Table 7).
Among other things, User label can be assigned to all entries here, so the meter or meter value can be as-
signed to a specific application. The (specific) read out interval of the meters can also be set via the parameter Cycle. The key required for decoding can also be set for wM-Bus meters in the Meter editing window.
S0 meters are internally processed with the number of pulses. The representation on the website in
the value column is nevertheless scaled to provide better readability. The Scale column contains
the pulse value and, in contrast to other meter interfaces, does not have to be additionally multiplied. If a value of 280.09 and a scaling of 1e-4 is displayed in the Meter tab, 2800900 pulses are recorded internally. However, this unscaled meter value appears analogously to those of other meters
in the report data, such as the CSV of the XML.
With S0 meter values, the meter value itself can only be set in the Add or Edit window if the Set
Value checkbox set is activated. The Set Value checkbox must be deactivated if a configuration does
not change or overwrite the current meter value (e.g.: change of the user label). The input of a meter value is scaled.
Before an S0 meter value is saved, the input value is calculated back to the pulse value and
rounded to whole pulses. Inaccuracies can result from the floating point data types.
The configuration can be finished with the Ok button or cancelled with the Cancel button.
For transmission and logging, individual meters and meter values can be directly activated or deactivated
with the checkbox in the Active column. The meter values are automatically activated or deactivated by the
configuration of a meter corresponding to the hierarchy. In the same way, an inactive meter is automatically activated if one of its meter values is activated. Multiple selected meters or meter values can be set
with the context menu items
Activate
and
Deactivate
.
All selected meters and meter values can be deleted with the Delete button or the context menu item with
the same name. Deleted wM-Bus meters are then created again if the wM-Bus lists parameter in the Config-uration tab is activated.
Individual meter values of an M-Bus or wM-Bus meter cannot be deleted.
The meter list is saved with the Save button.
Saving causes all the meter log data on the clipboard which have not yet been transmitted via the
WAN interface to be lost. This also deletes the CSV log data of the current day because the column
assignment it contains may have changed.
The
Export
of an active report at a certain point in time as a CSV or XML file.
The system meter is a special function for providing device-specific operating parameters. These parameters are displayed via the system meter like normal meter values and can thus be monitored and evaluated.
These default values are available depending on the device:
button can be used to export the meter list as a CSV file or, if available, to download the data set
Logged meter data can only be exported if data was recorded for the specified period, i.e. a report
Format of the specification of the standard readout cycle (for all meters, unless otherwise specified for
Mode for displaying the meter value description on the website:
Maximum device count
Limit for the number of meters during a scan (0: no limit). Already configured meters are not limited by this
Maximum value count
Limit for the number of meter values of a meter during a readout process (0: no limit). Already configured
Raw log active
Activation oft he raw data loggings
Specific parameters to the M-Bus*
M-Bus mode
Sets the first address for the primary search
Primary start address
Sets the last address for the primary search
Primary final address
Sets the search mask for the secondary search, 8 digits; wildcards are indicated by the letter "F"; missing
characters are replaced by 0 from the left
Secondary address mask
Baud rate for M-Bus communication (300 - 19200 baud)
M-Bus baud rate
M-Bus timeout until first data is received (in ms)
M-Bus timeout
M-Bus timeout for detecting the end of communication (in ms)
M-Bus idle timeout
M-Bus timeout (total) for the reception of a data packet (in ms)
M-Bus full timeout
Limit for the number of meters during a scan (0: no limit). Already configured meters are not limited by this
parameter.
M-Bus request mode
Mode of the M-Bus readout (REQ\_UD2):
M-Bus reset mode
Mode of the M-Bus-Reset (before scan and readout operations):
M-Bus max. multipage
Limits the number of multipage requests
M-Bus transparent port
Network port for transparent M-Bus mode
Specific parameters to the M-Bus slave*
M-Bus slave mode
Configuration of the M-Bus-Salve-Mode (M-Bus, TCP or UDP) or deactivation of the interface
M-Bus slave port
Network port for the M-Bus slave in case of TCP or UDP
M-Bus slave mode (2nd)
Configuration of the M-Bus-Salve-Mode (Instance 2, only TCP or UDP) or deactivation of the interface
M-Bus slave port (2nd)
Network port for the M-Bus slave (instance 2)
Specific parameters to the wM bus*
individual meters in the Meter tab via the parameter Cycle).
Second: Cycle of the readout is specified in seconds
Minute: Cycle of the readout is specified in minutes
Hour: Cycle of the readout is specified in hours
Daily: Readout takes place daily at the specified time
Weekly: Readout takes place daily on the specified weekday and at the specified time
Monthly: Readout takes place monthly on the specified day of the month and at the specified
time
Quarterly: Readout takes place quarterly on the specified day and month of the quarter and at the
specified time (month 1..3 per quarter)
Yearly: Readout takes place annually on the specified day and month and at the specified time
Readout cycle Standard readout cycle of the meters (unit according to Readout interval mode in seconds, minutes or hours)
Readout date (local)
Readout time (local) Time of readout for daily to annual specification of the standard readout cycle
Description mode
Day of readout for weekly to yearly specification of the standard readout cycle, depending on the interval
format the month specification is used, the year specification is not used
None: No display of the meter value description
Standard: Display of the general meter value description
Extended: Expanded display (individual parameters are only displayed if they are not 0):
Notation: Description [memory no.] <Tariff> Value type
Example: Energy [2] <1> max
Extended with DIF/VIF: Extended display additionally with DIF/VIF raw data:
Notation: Description [memory no.] <Tarif> Value type # XX XX XX …
Example: Energy [2] <1> # 8C 11 04
Extended with raw data: Expanded display also including the raw data of the complete meter
value entry. Notation corresponds to Extended with DIF/VIF:
Example: Energy [2] <1> # 8C 11 04 96 47 06 00
DIF/VIF: Representation of the DIF/VIF raw data
Raw data: Display of the raw data of the complete meter value entry
parameter.
meter values are not limited by this parameter.
Standard: Readout process with REQ\_UD2
Extended 1: Readout process with Get-All-Data (DIF/VIF 7F 7E) and REQ\_UD2
Extended 2: Readout process with Get-All-Data (DIF 7F) and REQ\_UD2
None: No reset
Standard: SND\_NKE to the primary address of the meter or broadcast for secondary addressing.
Extended 1: SND\_NKE to the primary address FD and a SND\_NKE to the primary address of the
meter or broadcast in case of secondary addressing.
Extended 2: SND\_NKE and an application reset to the primary address FD and a SND\_NKE to the
primary address of the meter or broadcast for secondary addressing.
wM-Bus frequency Frequency band for communication with the wM-Bus meters
Configuration of the wM-Bus communication mode for the OMS interface (T, S, C or C/T-Mode) or
wM-Bus transparent mode
Configuration of the transparent wM-Bus communication mode (Transparent/TCP, Transparent/UDP)
wM-Bus transparent port
Network port for transparent wM-Bus mode
wM-Bus listen
Activates the detection and display of newly received wM-Bus subscribers.
Show encryption keys
Displays the keys in plain text after the save operation
Specific parameters to the wM bus (channel 2)*
wM-Bus2 mode
Configuration of the wM-Bus communication mode for the OMS interface (T, S, C or C/T mode) or
wM-Bus2 transparent mode
Configuration of the transparent wM-Bus communication mode (Transparent/TCP, Transparent/UDP)
(channel 2)
wM-Bus2 transparent port
Network port for transparent wM-Bus mode (channel 2)
Specific parameters for pulse inputs*
S0 mode
Selection for absolute or relative pulse counting or deactivation of the interface
Specific parameters for the serial interface*
Serial mode
Operating mode of the serial interface (DLDE, Transparent/TCP or Transparent/UDP) or deactivation of the
interface
DLDE baud rate
Baud rate for serial DLDE communication
DLDE data bits
Data bits for serial DLDE communication
DLDE stop bits
Stop bits for serial DLDE communication
DLDE parity
Parity for serial DLDE communication
DLDE mode
Flow chart for serial DLDE communication:
DLDE idle timeout
DLDE idle time out for receiving the first data of the meter (in seconds). In push mode, no data may be sent
DLDE full timeout
Maximum DLDE waiting time for reading a meter (in seconds)
DLDE transparent port
Network port for transparent DLDE mode
deactivation of the interface.
wM-Bus2 frequency Frequency band for communication with the wM-Bus meters (channel 2)
deactivation of the interface (channel 2).
Request: Request according to mode A or B according to IEC 62056-21 (constant baud rate)
Request (C-Mode): Request and handshake according to mode C of IEC 62056-21 (constant baud
rate)
Push: Receiving spontaneous data sent by the meter
DLDE first timeout Timeout until reception of first data (in ms) for serial DLDE communication
from the meter within this configured time (corresponds to the idle time).
*if device has this interface/function
Table 9: Fields in the Configuration tab
The configuration is saved with the Save button. The Reload command loads the last saved values and resets the current changes.
The device is automatically reinitialized by setting the parameters via the Save button.
4.5 WAN tab
The
WAN
tab enables the configuration of the WAN connection for devices with integrated cellular mo-
dem. This is permanently set up when the device is restarted and is kept permanently active.
Interval in days after which a forced disconnection and re-establishment of the mobile radio connection is carried
out (if no data is exchanged). Rationale numbers are also valid here, e.g.: 0.25.
Status
Status of the WAN connection (connected / not connected)
Network
Information about the mobile network
RSSI (dbm)
Display of the reception field strength in dBm (-113 to -51 dBm, -114 corresponds to not connected)
IP address
IP address in the WAN
Gateway IP address
Remote station in the WAN
DNS IP address (primary)
IP address of the primary DNS server, not editable with DHCP
DNS IP address (second)
IP address of the secondary DNS server, not editable with DHCP
The following parameters are available:
Figure 21 WAN tab
Table 10: Fields in the WAN tab
The necessary parameters for WAN connection should be provided by the mobile service provider of your
SIM card.
Please check whether the mobile radio contract includes the expected quantity of data, otherwise
increased costs or a blocking of the SIM card may follow.
Please check that the parameters are correct. The entry of incorrect parameters can lead to in-
creased mobile radio costs or blocking of the SIM card.
If an invalid PIN is entered, it will be used only once per software startup. Thus, the remaining at-
tempts for entering the PIN are not depleted and a new PIN can be entered via the website.
Changing the WAN configuration via an active mobile radio connection is not recommended, as
the device may no longer be accessible after a changed or invalid configuration.
The configuration is saved with the Save button. The Reload command loads the last saved values and resets the current changes.
The device is automatically reinitialized by setting the parameters via the SAVE button. An existing
Parameters for data collectors with push functionality
Report instance
Selection of the respective instance
Report mode
Operating mode or deactivation of the respective instance. There are these modes to choose from:
Report format
Data format for the transmission of the respective instance. Several CSV and XML formats are available.
The User format uses a stored XSLT script to format the data (see 10.7.1).
Report cycle mode
Format of the indication of the transmission cycle of the respective instance
Report cycle
Transmission cycle of the respective instance
Report cycle date (local)
Day of transmission of the respective instance for weekly to yearly indication of the transmission cycle,
depending on the interval format, the month indication is used, the year indication is not used.
Report cycle time (local)
Time of transmission for daily to annual Transmission cycle indication
Report address
Host address of the remote station or mail server (outgoing mail server)
Report port
Port number of the remote station to be connected
Report directory
Directory on the server
Report username
User name for server access
Report password
Password for server access
Report source address
Address of the transmitter (e-mail)
Report destination address
Destination address (e-mail)
Report user parameter 1
User-specific parameters 1 (use of format or user mode)
Report user parameter 3
User-specific parameters 3 (use of format or user mode)
Parameters for Modbus server
Modbus mode
Operating mode: Modbus TCP or Modbus UDP
possible.
Modbus port
Network port to which the remote station (the Modbus TCP client) must connect.
Modbus test
Dummy mode, where the test process image shown in Table 34 is activated, see section 11.4.2
Modbus swap
Changes the Word order from MSW first (default) to LSW first (option checked), see section 11.4.3
Modbus float only
Reduces the Modbus register layout from 10 registers/value to 2 registers/value and represents only the
Modbus multi slave
Activates the multi-slave feature, where the data of a meter can be accessed as its own virtual Modbus
Parameters for BACnet server
BACnet active
Activates the BACnet functionality globally
BACnet config network
Activates a second virtual network interface for the BACnet service
BACnet IP
IP address of the second virtual network interface for BACnet
BACnet netmask
Subnet mask of the second virtual network interface for BACnet
BACnet broadcast
Broadcast address of the second virtual network interface for BACnet
BACnet port
UDP port number of the BACnet service (default port: 47808)
BACnet device ID
ID number of the BACnet device
BACnet device name
Device name of the BACnet device
BACnet location
Location information of the BACnet device
TLS: Transmission via active data push over secured TCP channel to specified server
TCP: Transmission via active data push over unsecured TCP channel to specified server
SMTP: Transmission via active data push by e-mail to the specified address
FTP (client active): Transmission by active file transfer via FTP to the specified server (encrypted or
unencrypted), in case of unencrypted FTP data connection is established from the server
FTP (client passive): Transmission by active file transfer via FTP to the specified server (encrypted or
unencrypted), in case of unencrypted FTP data connection is established from the device
MQTT: Transmission via active data push via MQTT client to the specified server/broker (encrypted or
unencrypted)
File: Generation of local files for later retrieval (data pull) by third party system
User: User-specific connection procedure based on a Bash script (see section 10.7.210.7.2)
Second: Cycle of the transmission is specified in seconds.
Minute: Cycle of the transmission is indicated in minutes.
Hour: Cycle of transmission is specified in hours.
Daily: Transmission takes place daily at the specified time
Weekly: Transmission takes place daily on the specified day of the week and at the specified time.
Monthly: Transmission takes place monthly on the specified day of the month and at the specified time.
Quarterly: Transmission takes place quarterly on the specified day and month of the quarter and at the
specified time (month 1..3 per quarter)
Yearly: Transmission takes place annually on the specified day and month and at the specified time.
Report user parameter 2 User-specific parameters 2 (use of format or user mode)
In the operating mode "Modbus TCP" up to 5 parallel connections by different Modbus TCP masters are
serial number of the meter and the floating point value of the corresponding meter value, see section 11.3
and section 11.4.4
slave under its own Modbus address, see section 11.4.5
BACnet BBMD IP address of a BACnet Broadcast Management Device (BBMD) for routing across local network boundaries
Activates the internal HTTP server of the device, activation and deactivation only possible via HTTPS to be
HTTPS server active
Activates the internal HTTPS server of the device, activation and deactivation only possible via HTTP to be
FTP server active
Activates the internal FTP server of the device, if deactivated, no FTP access to the device is possible.
SSH server active
Activates the internal SSH server of the device (administrative access)
Network discovery active
Activates the internal discovery server of the device; if deactivated, the device is no longer displayed in the
Network discovery password
Password for setting the network parameters via the Netdiscover tool
Modbus server active
Modbus server active, read-only, depending on the Server tab
BACnet server active
BACnet server active, read-only, depending on Server tab
Individual parameters that are required for the configuration are enabled corresponding to the operating
mode of the server interface.
The configuration is saved with the Save button. The Reload command loads the last saved values and resets the current changes. The
data.
Test button allows die immediate transmission of the previously read-out
The device is automatically reinitialized by setting the parameters via the SAVE button. Make sure that the system time is correct before you activate the report. If the system time is syn-
chronized later, e.g. by NTP service, gaps may occur in the log. These gaps are then transferred to
the target system in the form of empty files.
4.7 Security tab
The Security tab enables the parameterization of the network services of the device.
Figure 23 Security tab
The following parameters are available:
able to use the website.
able to use the website.
Netdiscover tool (see chapter 3).
Table 12: Fields in the Security tab
The configuration is saved with the Save button. The Reload command loads the last saved values and resets the current changes.
The device is automatically reinitialized by setting the parameters via the SAVE button. An existing
WAN connection is terminated and re-established.
4.8 User tab
In the User tab different users with specific access rights to the website can be created.
Administrative user that allows full access to all services of the device (HTTP, FTP, SSH, IP configuration).
web
web
Default user for the web interface. If a user with this name and password exists, the web interface
ftp
ftp
User for unencrypted FTP access to the log directory ext/Log
Field name
Description
Name
User name
Overwrite password
It is set if a (new) password has been set for the user in the editing window.
Require change Password
Setting whether the user must change his password at the next login
Maximum sessions
Setting, how often the user may be logged in at the same time (-1=unlimited)
Read General
Read authorization for the General tab
Write General
Write authorization for the General tab
Read Meter
Read authorization for the Meter tab
Write Meter
Write authorization for the Meter tab
Read Config
Read authorization for the Configuration tab
Write Config
Write authorization for the Configuration tab
Read WAN
Read authorization for the WAN tab
Write WAN
Write authorization for the WAN tab
Read Server
Read authorization for the Server tab
Write Server
Write authorization for the Server tab
Read Security
Read authorization for the Security tab
Write Security
Write authorization for the Security tab
Read Service
Read authorization for the Service tab
Write Service
Write authorization for the Service tab
Write User
Read and write authorization for the User tab
FTP
Authorization of the user to log in via FTP (maximum 2 users)
Figure 24 User tab
The following users are preconfigured in the delivery state:
automatically logs in with these access data. Otherwise, the user is prompted to enter the access data.
When delivered, this user has full access to the website of the device.
Table 13: User accounts on delivery
The existing configuration in the user table can be changed on the website:
Change Password Setting whether the user is allowed to change his password
Sessions Display how often the user is logged in at the same time
Table 14: Fields in the User tab
The user configuration can be changed with the buttons in the lower area or through the context menu.
With the exception of the admin user, individual users can be created, deleted or changed.
The users in the list can be selected with a simple mouse click. A range can be selected with the <SHIFT>
key pressed, or multiple users can be selected with the <
CTRL> key pressed.
The Reload command loads the last saved values and resets the current changes.
When write access is activated on a tab, read access is also activated.
The admin user cannot be changed or deleted in the general user configuration. The administrator
password can only be changed with the
Change password
button if the admin user is logged in.
Encrypted/secured FTP is usually SFTP not FTPS.When resetting, all configuration data and meter
data are lost.
Only the admin user has full access to the file system of the device via encrypted FTP. The second
FTP user can also access /ext/Log without encryption.
New users can be added via the button Add or via the context menu entry of the same name. The following window will open:
Figure 25 Input mask for adding a user
In addition to the user name and password, you can specify how often a user may log in at the same time (1 no restriction). Besides the user admin another user can get FTP access to the device. The unencrypted
FTP access only allows access to the log data of the device (directory: /ext/Log). This property can only be
enabled at the time the user is created.
A separate FTP user (e.g.: ftp) allows a remote client to call the stored log data (manually or auto-
matically), whereby it is not given access to other services or data of the SonoCollect 112.
To configure an already existing user, the Editing window can be called by double clicking its entry or via
the context menu item
To reset the password of an existing user, the
Edit. This window has the same structure as the input window for creating a user.
Set Password checkbox must be set. If the Set Password
checkbox is not set, the user password is not changed or reset during this configuration process. A user
password cannot be read.
The configuration can be finished with the Ok button or cancelled with the Cancel button.
The rights of an individual user are set directly in the user list. If a user has write access in a tab, he/she automatically also receives the right to display the tab (read access).
All selected users (with the exception of the admin user) can be deleted with the Delete button or the Context menu item with the same name.
The user configuration is saved with the Save button.
4.9 Log tab
The Log tab provides access to log information and status outputs. that facilitates the analysis of the be-
haviour and troubleshooting.
The scope of the log entries depends largely on the settings in the Log mode field in the General
tab (see section
For raw data logs on the meter interfaces, the Raw data log field in the
Character string according to which the log is to be filtered (search for keyword or regular expression in
Figure 26 Log tab
The following options are available on the website:
System log: Display of the log entries of the system (Linux) and the application
Application: Display of the log entries of the application
M-Bus: Display of the raw data of the M-Bus interface (if Raw data log is active in the Configuration tab)
wM-Bus: Display of the raw data of the wM-Bus interface (if Raw data log is active in the Configuration tab)
DLDE: Display of the raw data of the DLDE interface (if Raw data log is active in the Configuration tab)
Message column)
Table 15: Fields in the Log tab
The Reload button updates the entries. The Filter button activates the search filter and the time range from
the input fields and thus offers the possibility of targeted searches.
The raw data log can be searched for meter numbers with the special filter input serial=, e.g.: se-
rial=12345678. All packages will then appear at the named meter.
If no log entries are displayed, please check the entries. If necessary, extend the specified time
range or reset the filter.
The number of log entries displayed is limited to 500. Use the filter or the time range to reduce the
entries.
The Export button downloads a compilation of all entries matching the filter as a CSV file from the device.
This download may take some time depending on the size of the log.
tab enables maintenance work and provides related information or functions:
Classified as Business
Field name
Description
Hardware version
Version of the hardware
OS version
Version of the operating system
Software version
Version of the software
Website version
Version of the website
Figure 27 Service tab
Table 16: Fields in the Service tab
The values are updated with the Reload button.
The buttons Config export and Config import are available to download the configuration of the device or
to upload a configuration to the device.
When exporting the configuration, a selection box can be used to specify which data is downloaded from
the device:
Certificates
Device configuration
Network configuration
Device name
Meter configuration
The Network configuration and the device name are part of the device configuration. If the device
configuration is to be transferred to another device, it is recommended not to export the network
configuration and the device name as well, since these settings are usually not to be transferred as
well.
The configuration is downloaded as *.tar.gz file. This archive is an extract from the file system of the device.
It can be stored and modified for later use on another device. It can be used when transferring a valid configuration to a replacement device or when commissioning many similar devices.
When importing the configuration, a file selection window opens in which you can select a corresponding
*.tar.gz file.
Pressing the buttons Update firmware also opens a file selection window. An update file can be selected in
this window. Danfoss provides update files as *.enc files at regular intervals. These files can then be uploaded to the device. After a successful upload, the update process is carried out automatically and the device is then restarted.
The device can be restarted with the Reboot system button, All internal processes are shut down and reinitialized after the restart. Meter data (WAN interface) stored on the clipboard may be transferred after a
restart. Use this button to adapt the configuration manually per FTP(S) adjustment or make an update.
4.11 Print page
A print version of the web page can be called up via the Print button (bottom right) to print view of the
configuration or to export the device configuration via the clipboard. The website generates an additional
print preview containing all available configured parameters according to the access rights. The print preview is automatically closed after a user has logged out (if not already closed).
The meter list displayed is also suitable for insertion into a table calculation.
Danfoss provides a manual as a PDF file on the devices. Use the Help button (on the right bottom) to access this manual.
4.13 Front-end troubleshooting
Access to the web server of the device via a standard web browser provides an easy and intuitive way to
operate the device. Nevertheless, impairments or unwanted behaviour may occur.
A possible source of error is the browser cache, especially if several devices are operated under the
same IP or an update has been applied. First terminate the web session with the
and then completely reload the website to eliminate this source of error. Depending on the
browser, this is done using a key combination, e.g. <
CTRL+F5> or <CTRL+R>.
Website or front end cannot be accessed
The website cannot be loaded or the error message "webservice not available" appears.
Check the IP settings of the device and your computer. The IP addresses should be in the same subnet or a
route must be set up. If possible, change the IP addresses accordingly. Ask your administrator. Alternatively, you can use DHCP to give the device a valid IP address (see the Netdiscover tool in chapter 3). Two
examples of a valid configuration:
101 and 254 and other already used IP addresses), typical for connection to a router in the home
network
Logout button
Check whether the device is listed in the Netdiscover tool (see chapter 3). Check the general connectivity
via ping test also from the Netdiscover tool.
Check whether a firewall blocks the data exchange or the routing is configured accordingly. Ask your administrator in this case.
In the case of an HTTPS connection, the browser may block the connection under certain circumstances.
Confirm the stored certificate in the browser or "trust" the website and the certificate if you are sure to access the device.
If errors could not be rectified, please contact your local Danfoss support:
Login on website not possible
Check the user settings and rights for the website and the access data.
There may be another user already logged in and the number of active sessions may be limited. Then the
login is also denied. In the User tab check the access data and the number of active sessions.
If errors could not be rectified, please contact your local Danfoss support:
All input fields or buttons are greyed out.
Greyed out buttons indicate a denied write access. A maximum of one user has write access.
Check whether another session is already active. This can also occur if a window in the browser is simply
closed without logging out first. The session is then active for a short time. Log out again and wait about
User
one minute. In the
Check whether the user has write access.
If errors could not be rectified, please contact your local Danfoss support:
tab check the user rights and the number of active sessions.
Check the user's read access. Only the tabs for which the read access is active can be viewed. Check the
User
user rights in the
If errors could not be rectified, please contact your local Danfoss support:
tab.
Export of the log data of one/several meters is empty
Log data is only generated when a report is active in order to optimize the memory. Check in the Server tab
whether a report is active.
Check the time range for the export. The time of the report must start before a valid readout. For example,
to export the readout from 09/29/2020 13:15, the time for export should be set to 09/29/2020 13:10. The
report then contains all readouts from 13:10 onwards until the end of the
instance 1 or 15 minutes.
If errors could not be rectified, please contact your local Danfoss support:
Report cycle in the Server tab of
The log is empty
Check the filter settings. If no filter is active, entries should always be available for the Log source System
log. If not, this indicates a system-level misconfiguration. This can be remedied by the command solcmd
config-partitions via the SSH console (see section
Check whether the raw data log is active for the interfaces (see
for the
If errors could not be rectified, please contact your local Danfoss support:
A widely used interface for the automated acquisition of meter data is the wired M-Bus (Meter-Bus). This
was originally specified in EN 1434-3. It received its own series of standards with EN 13757:
EN 13757-2 Communication systems for meters - Part 2: Wired M-Bus communication
EN 13757-3 Communication systems for meters - Part 3: Application logs
EN 13757-7 Communication systems for meters - Part 7: Transport and security services
Originally developed for heat meters, the M-Bus is now available for all types of consumption meters as
well as sensors and actuators. Thus, it has a high value with regard to the collection of consumption data.
Essential features and advantages of the M-Bus are:
The M-Bus is a digital interface for the electronic reading of meter data.
All consumption meters in a building/property can be operated and read on a single cable.
All consumption meters are addressable.
The readout is protected against transmission errors and is very robust.
The data is machine-readable and therefore easy to process.
The data are self-describing.
High readout rates are possible.
The M-Bus is manufacturer independent, there is a wide range of devices.
5.1 Signalling on the M-Bus
The M-Bus is a single master multiple slave bus. Therefore, a single bus master controls the bus and the
data traffic on the bus, to which several slaves, i.e. meters, can be connected.
A second physical master is not allowed on the M-Bus.
The M-Bus uses voltage and current modulation on a physical level to transmit data. The master transmits
telegrams by voltage modulation, the slave transmits telegrams by current modulation.
This is shown schematically in the following figure:
Absinken der Busspannung durch BusImpedenz
slight drop in bus voltage due to
bus impedance
Figure 30 Signalling with M-Bus
The M-Bus works according to the request-response principle, i.e. the master initiates the communication
by a request/command which is then answered/confirmed by the slave. Spontaneous data transmission on
the part of the slaves is not allowed.
Certain terms are used in the M-Bus standard. The basics of communication are taken from IEC 60870-5-
101. Key examples are explained in the table below:
The Transparent modes allow the physics of the M-Bus interface to be used via a TCP or UDP port. The data
stream is thus forwarded from the M-Bus interface to an IP interface (network (LAN) or mobile radio
(WAN)). The device then works in a similar way to an Ethernet M-Bus converter or even a mobile radio
router with an M-Bus interface. The network port to be used is defined in the parameter
port.
The transparent mode makes it possible to directly address meters via M-Bus interface. This re-
quires appropriate M-Bus software on the host system. The device provides the physical connection. The transparent mode makes it possible to directly address meters via M-Bus interface.
Configuration
tab activates the M-Bus interface and defines the basic
A distinction is made between primary addressing and secondary addressing with the M-Bus.
The primary address is used for access control on the link layer. It is the basis of communication between
master and slaves on the M-Bus and is used for communication in every telegram except the short frame.
The secondary address is an extension of the addressing and additionally controls the access to the application layer.
The valid address range for the primary addresses is 0-250, whereby the address 0 is given a special posi-
tion. According to the standard, this is only permissible for unconfigured meters (ex works). The address
253 is a special address for the use of secondary addressing, the addresses 254 and 255 are used for the
broadcast with and without response. The addresses 251 and 252 are reserved.
The secondary address consists of 4 parts. These are the secondary ID (an 8-digit decimal number), the
manufacturer ID (value of 0-65535), the medium ID (value of 0-255), and the version number (value of 0-255).
15
Thus the address space is theoretically 115.19*10
unique values.
The vendor ID can be converted to a vendor identifier , which is maintained by the DLMS User Associ-
ation. An overview can be found here: https://www.dlms.com/flag-id/flag-id-list
The slave whose primary address matches the address in the request responds in case of primary addressing. This makes it possible to implement simple and short communication.
If the primary address is not unique during primary addressing, collisions and thus disturbed com-
munication may occur, since several slaves are responding.
Secondary addressing, on the other hand, uses a so-called selection (slave select) on the basis of the secondary address in order to be able to address the meter with a matching secondary address via the primary
address 253.
The non-matching meters deselect in the same step. Therefore, the process will be somewhat more complex, since an additional selection with confirmation is required. Communication takes a longer time. However, the address space is much larger, collisions do not occur, and more than 250 meters are possible on
one bus system. In addition, commissioning is faster because not every meter has to be configured to a
unique primary address.
Figure 31 Example of primary and secondary addressing in comparison
Wildcards are also supported for secondary addressing. This allows, for example, the sole use of the 8-digit
secondary ID for selection. The other parts are masked with the placeholder 0xFF (255) or 0xFFFF (65535).
Individual digits of the secondary address can also be masked with 0xF (16).
The M-Bus uses the BCD display for the Secondary ID, therefore the 8-digit decimal number is en-
coded by an 8-digit hexadecimal number. Special functions can be represented by the characters
A-F per digit, but only the F is used, as a placeholder at the respective digit.
The placeholders are also the basis of the secondary search. This divides the secondary address space piece
by piece by means of the placeholders and checks whether there are meters in the respective part. If so,
this part is further subdivided until there is only at most one meter per part or further subdivision is not
possible. The classic procedure here is to mask the manufacturer ID, medium ID and version number and
search the 8-digit number range of the secondary ID.
The range 000000-999999 is divided by sending the selection to 0FFFFFFF, i.e. selecting all meters with a 0
at the top of the Secondary ID. A query is then sent to the selected meters using the primary address 253. If
no response is received, no meter is in this range the lowest unmasked digit can then be incremented and
it continues with 1FFFFFFF. If you get an undisturbed response, there is only one meter in this range and
you can save this meter as found and count up the lowest unmasked digit and continue searching. If one
receives a disturbed response or collision, one moves to the next still masked location and traverses it from
0 to 9. Due to the variability of the process depending on the meters and the distribution of the secondary
ID in the address space, it is difficult to estimate in advance what time a search will take.
Primary search, in contrast, is very direct and determinate. Every primary address is requested and depending on a valid answer a meter is then stored as found or not. Thus, 250 queries are always necessary for a
complete search.
The parameters Primary start address and Primary final address in the
search by specifying the start and end. The parameter
Secondary address mask is used to mask the second-
Configuration
tab limit the primary
ary ID, so that the search can be limited to certain areas. For example, a mask 33FFFFFF limits the search to
all meters whose secondary ID begins with 33.
The parameter M-Bus baud rate in the
interface. The baud rate essentially determines the speed of the data transmission.
M-Bus usually uses 2400 baud. 300 baud and 9600 baud are other common baud rates. Many me-
ters detect the baud rate automatically.
The other parameters for the bit display of the M-Bus interface are fixed to 8 data bits, even parity
and 1 stop bit (8-E-1).
Configuration
tab is used to configure the bit display on the M-Bus
M-Bus timeouts
The M-Bus interface uses with M-Bus timeout, M-Bus idle timeout and M-Bus full timeout three different
timeouts (in transparent mode only the
tion
tab.
The M-Bus idle timeout specifies what time the M-Bus interface must be "idle", i.e. no data is sent/received,
in order to detect the end of a telegram (end of communication). It is mainly used for package formation of
the M-Bus data stream, i.e. the assignment of incoming data to a logical unit (data packet).
The M-Bus timeout specifies what time it takes to wait for a response from the meter. If no data is received
within this time from the request, the readout attempt is aborted.
The M-Bus full timeout indicates the latest time at which reception is interrupted in order to process the
received meter data. This parameter also terminates reception if the
cause data is continuously received (without idle, e.g. in the event of faults).
M-Bus idle timeout), which can be parameterized in the
M-Bus idle timeout is not reached be-
Configura-
M-Bus request mode
By default the readout is done via the command REQ_UD2 which the master sends to the meter. This is answered by the meter with the RSP_UD, which contains the usual meter data (consumption data).
In addition, the parameter M-Bus request mode in the
data to be read out before the actual readout. In case of the SonoCollect devices there is the possibility to
send a so-called global readout request to the meter before the actual query. For this purpose a SND_UD is
sent to the meter. The user data then consists of only one or two characters. There are two implementations with the same function, depending on the manufacturer one or the other is supported:
User data consisting of 2 bytes: DIF=0x7F, VIF=0x7E → M-Bus request mode Extended 1
User data consisting of 1 byte: from DIF=0x7F → M-Bus request mode Extended 2
This command is usually not necessary, because all meter values are transmitted by default with
the normal query.
The use may result in a change of the data record of the meter
Configuration
tab can be used to explicitly select the
M-Bus reset mode
With the M-Bus there are several variants and applications of a reset. A distinction is made between:
The link layer reset is only responsible for initializing the communication flow of the link layer according to
EN 13757. Therefore, it resets the selection based on the secondary address, deselects the meter, and also
resets the FCB mechanism (see section 5.2.7).
The application layer reset, on the other hand, resets the application in the meter (or the communication
application).
The parameter M-Bus reset mode in the
which address it is sent. The resets are then sent at the beginning of a search run and before each readout
of a meter:
None: Neither a link layer reset nor an application layer reset is sent.
Standard: A link layer reset is sent to the broadcast address 0xFF and, in the case of primary ad-
dressing, also to the respective primary address.
Extended 1: A link layer reset is explicitly sent to the selection address 0xFD and then the link layer
resets of the standard mode.
Extended 2: After the link layer reset to the selection address 0xFD an application layer reset is sent
to the broadcast address 0xFF and then the link layer resets of the Standard mode.
M-Bus multipaging
If the data of a meter do not fit into a single telegram (maximum 255 bytes user data), there is the possibility to split these data into several logically connected, consecutive telegrams. The FCB mechanism according to IEC 60870-5-2 is used for the readout sequence. Danfoss calls this process "multipaging".
In order to call possibly existing telegrams of the meter, the master must switch the FCB with each new request REQ_UD2 to inform the meter to send the following telegram. If the master does not switch the FCB,
the meter always responds with the same telegram again. The REQ_UD2 then alternately have a C field of
0x5B or 0x7B.
The parameter M-Bus max. multipage in the
lated telegrams to a number. Especially in the case of meters with a lot of data (e.g. load profiles, reference
date series), the readout time can be shortened and less relevant values are not read out at all.
It is sufficient to use the first telegram of the telegram sequence for most applications. The M-Bus does not provide a mandatory mechanism to directly access certain telegrams of the
sequence. As a rule, the procedure always starts from the first telegram. At least all relevant telegrams must be called.
An "Application reset" to the meter leads to a reset to the first telegram of the sequence.
Configuration
tab restricts the maximum number of interre-
5.3 M-Bus troubleshooting
Physical troubleshooting
In order to determine why meters on the M-Bus do not respond or are not found during the search, a physical check of the M-Bus network is usually suitable. It can be relatively easy to basically determine whether
the M-Bus is at least correctly wired.
A standard multimeter is sufficient for simple measurement. The most important measurement is the voltage measurement between both M-Bus lines. The voltage measurement shows that:
the M-Bus master correctly supplies the bus: approx. 30-40 V are present
the meter is correctly connected to the M-Bus: approx. 30-40 V are present
the voltage drop is not too high: the voltage at the master is only slightly higher than at the meter
the telegrams of the master arrive at the meter: when sending, the value in the display of the multi-
meter 'wobbles'.
Another important measurement is the current measurement on the two M-Bus lines. The current measurement shows that:
the load on the M-Bus is in a valid range: approx. (number of meters)*1.5 mA flows
no external currents are present: current through both lines is identical
the telegrams of the meter arrive at the master: the value in the display of the multimeter 'wobbles'
Figure 32 Troubleshooting the M-Bus by measurement with multimeter
M-Bus meters are not found
Check the cables between the device and the meter, and replace faulty cables if necessary. While the device is switched on, measure the M-Bus voltage (approx. 30 to 40 V) between the two M-Bus connections
on the device and also on the meter.
Ensure that the M-Bus interface is activated via the parameter M-Bus mode on the web page in the
uration
ter(s).
tab and that the search mode configured therein (secondary or primary) is supported by the me-
Work with search masks or a restriction of the search range to search the M-Bus step by step (e.g.: Primary start address, Secondary search mask).
The M-Bus query can also be adapted with the following parameters:
M-Bus request mode
M-Bus reset mode
Scan again with a different M-Bus baud rate (300, 2400 or 9600) or lengthen the timeout.
Remove other meters (if any) to eliminate a possible source of error.
If another M-Bus meter (possibly the same type) is available, you can perform another communication test
with the other meter to localize the source of error.
The number of attempts for an M-Bus request can be increased via the parameter MBUS_MAXRETRY in the
extended configuration of the device by the use of file app/chip.ini (see section
10.3) This makes it easier to
find meters that do not answer every query. The default value here is 3. Start the search again.
Collisions can occur if the same primary or secondary addresses occur more than once during the search
procedures. An address duplication is common with primary addressing. Therefore we recommend secondary addressing. In such cases collisions can also occur, since due to the default value of the parameter
MBUS_SELECTMASK=14 (see section 10.3), only the 8-digit serial number is searched during the search.
Activate the raw data log with Raw data log in the
Configuration
tab (see section 4.4). The communication
process can be analyzed very well using this raw data log.
If errors could not be rectified, please contact your local Danfoss support.
Some meters contain incorrect secondary address or encryption information in the data packet. As a result,
they may not be addressable for readout or may be processed incorrectly. Parts of the secondary address
can be masked and thus meters can be read after all using the parameter MBUS_SELECTMASK (see section
) The parameter MBUS_DISABLEDECRYPTION=1 (see section 10.3) can also be used to disable the unu-
10.3
sual decryption of M-Bus packets if they pretend to be encrypted.
Restart the search or perform a readout.
If errors could not be rectified, please contact your local Danfoss support.
The search takes a long time
The search for M-Bus meters can take a long time under certain circumstances, quite longer than 1 h, especially with secondary search and ascending meter serial numbers.
Work with search masks or a restriction of the search area to search the M-Bus step by step.
Decrease the value of the parameter MBUS_MAXRETRY in the file app/chip.ini (see section 10.3) or reduce
the timeouts.
Use a different search mode in the
search Secondary scan reverse may help in this case. Then start the search again.
In the event of faults on the M-Bus, long search runs may also occur, since faults are processed as receive
packets and a meter is thus assumed in each search step.
If errors could not be rectified, please contact your local Danfoss support.
Configuration
tab (see section 4.4). In particular, the reverse secondary
Device restarts during search
For safety reasons, the device operates with an internal watchdog, which is intended to prevent the device
from becoming unreachable. If the search takes a long time, this watchdog may cause the device to restart.
If the search takes a long time, it is recommended to increase the value of the parameter
DOG_SCAN in the file app/chip.ini (see section 10.3). Then start the search again.
There may also be severe collisions on the bus under certain circumstances, e.g. if all meters respond at the
same time. In exceptional cases, these severe collisions and the associated large increase in current can
lead to the device restarting. Work with search masks or a restriction of the search range to search the MBus step by step (e.g.:
search, and search the bus sections one after another.
If errors could not be rectified, please contact your local Danfoss support.
Primary start address, Secondary search mask). If necessary, divide the bus for the
A widely used interface for the automated acquisition of meter data is the wireless M-Bus (wM-Bus, wireless M-Bus, wireless Meter-Bus). Like the wired M-Bus, it is specified in the series of standards EN 13757:
EN 13757-4 Communication systems for meters - Part 4: Wireless M-Bus communication
EN 13757-3 Communication systems for meters - Part 3: Application logs
EN 13757-7 Communication systems for meters - Part 7: Transport and security services
The wM-Bus is the extension of the M-Bus for use via a radio system. Protocol and mechanisms are therefore very similar, deviations are due to the speciality of radio. Thus, it has a high value with regard to the
collection of consumption data.
Essential features and advantages of the wM-Bus are:
The wM-Bus is a digital interface for the electronic reading of meter data.
All consumption meters have a unique identifier.
The readout is protected against transmission errors and is very robust.
The data is machine-readable and therefore easy to process.
The data are self-describing.
High readout rates are possible.
The M-Bus is manufacturer independent, there is a wide range of devices.
The data can be encrypted and is protected against replay attacks.
The used frequency of 868 MHz offers sufficient penetration in the building at low transmission
power.
Repeaters can be used to extend the radio network.
6.1 Signalling via wM bus
The wM-Bus is a radio system that operates mainly in the SRD band at 868 MHz. Other frequencies, such as
433 MHz or 169 MHz are also defined. The used and allowed frequency differs between continents and
countries.
Technically, the wM bus uses frequency modulation (FSK). The physical parameters and the modulation
type depend on the mode of the wM bus. There are different modes:
S-Mode: Stationary mode: Mode originally intended for fixed installations, declining importance
T-Mode: Frequent transmit mode: Mode originally intended for walk-by application, frequently
used
R-Mode: Frequent receive mode: Special mode for reception on multiple radio channels simultane-
ously
C-Mode: Compact mode: Energy-optimized variant similar to T-mode, growing importance
N-Mode: Narrow band VHF: Special mode for the use of 169 MHz
F-Mode: Frequent receive and transmit mode: Special mode for the use of 433 MHz
The modes S, T, C and N are defined as unidirectional (e.g. S1 or T1) as well as bidirectional (e.g. S2 or T2).
The R and F modes are always bidirectional. In the context of the meter interface, unidirectional means that
the meter only transmits and does not receive. Therefore, no data can be sent to the meter. The reception
time window in the meter is open for only a very short time after a telegram has been sent due to the battery in case of bidirectional communication. The other side must then respond within this very short time
to keep the receiver active, otherwise it will be switched off again.
The SonoCollect devices are intended for unidirectional operation and are therefore only used to
receive meter data.
6.2 Troubleshooting the wM bus
wM-Bus meters are not found
Ensure that the wM-Bus interface is configured for T-, C-, C/T- or S-Mode via the parameter wM-Bus mode
on the web page in the
tab (see section 4.4) according to the configuration of the meter.
Classified as Business
Test the communication connection over a short distance. To do this, position the meter at a distance of
about 1 m from the device.
Check the internal configuration of the meter (e.g.: transmission mode, transmission interval). Check the
antenna connection and the position of the antenna.
Check whether the parameter wM-Bus lists in the
added to the list.
Configuration
tab is active. If not, no new meters are
If another wM-Bus meter is available, you can run the communication test again with this meter to localize
the source of error, possibly with a different communication mode.
Activate the raw data log with Raw data log in the
analyzed very well using this raw data log.
Configuration
tab. The communication process can be
If errors could not be rectified, please contact your local Danfoss support.
wM-Bus mounters are found but show no data
In most cases, this occurs when the transmitted meter data are encrypted. Check whether encryption is
Meter
active in the meter and whether the entered key is correct. For this purpose go to the
the correct key there (column Encryption key, see section
4.3).
If errors could not be rectified, please contact your local Danfoss support.
A simple way to digitize consumption is the pulse interface.
The method of digitization consists of outputting a certain number of pulses per unit of consumption. This
way gives a pulse a weighting. It is therefore possible to infer the consumption value and thus the meter
reading by counting the pulses. The weighting of the pulses is meter-specific and usually noted on the meter. Example: Inscription "1000 Imp/kWh" → 1 pulse = 1 Wh, so with each pulse the energy register can be
increased by 1 Wh.
Generally, this pulse interface is referred to as the S0 interface. However, this designation is to be understood only as a synonym. There are essentially 3 different realizations:
S0 Type A according to EN 62053-31
S0 Type B according to EN 62053-31
Potential free contact
Physically, the types differ from each other. The real S0 interfaces according to EN 62054-31 are digital current interfaces. A pulse is represented by a current of more than 10 mA. In the idle state, the current is less
than 2 mA. Type A and type B differ only in the maximum permitted voltage. Type A uses a maximum of 27
V, type B a maximum of 15 V. The specified maximum current of results in a minimum internal resistance of
1 kOhm. A minimum voltage is required depending on the implementation.
The potential-free contact is easier to implement on the encoder side (meter). This usually simply uses the
transistor output of an optocoupler which is directly controlled. The internal resistance is the same as the
optocoupler and no minimum voltages are required.
This device has a pulse interface which is compatible with S0 interfaces according to type A and
with potential-free contact. Therefore all common meters with pulse interface can be connected.
7.1 Setup of a meter in the web front end
The setup of a meter with pulse interface is only possible manually.
First, the pulse interface must be activated. This is done in the
(see section
Disabled
Absolute
Relative
The most commonly used mode is Absolute. Here, the meter value is continuously incremented by its value
for each pulse. Thus, the recorded measured value should always correspond to the display of the meter.
In the Relative mode, the value is also incremented, but is reset to 0 at the end of the readout period to increment again. This can be used to record the consumption per period.
After activating and setting the mode of the pulse interface, the meter can be added in the
The meter is first created via the Add button or the context menu. In the dialog, the Interface must be set
to S0-n (n = channel number). Further data such as manufacturer code, serial number,
bel are optional and can be assigned. The user may refer to Table 25 for the Medium field. This ensures a
uniform display across all meters. Use the
meter list in the
4.4). Three modes can be set here:
Ok button to accept the entries and the meter is created in the
A meter value must now be added to the newly created meter. This is done by right-clicking on the newly
added pulse meter and selecting the
dialogue box for entering the parameters of the meter value.
Add value command from the context menu. This command opens a
Figure 34 Creating the meter a pulse meter (sample data)
The parameters Value and Unit should be set to the values in the meter display. The unit may differ, we recommend using basic units such as Wh as opposed to the standard unit often used for energy meters kWh.
The parameter Scale indicates the pulse value. The value entered in Value is incremented by this value during a meter pulse. The calculation of the pulse value results from the indication on the meter, here are a
few examples:
1000 Imp/kWh → 0.001 = 1e-3 with unit kWh or 1 = 1e+0 with unit Wh
5000 Imp/kWh → 0.0002 = 2e-4 for unit kWh or 0.2 = 2e-1 for unit Wh
200 Imp/m³ → 0.5 = 5e-1 with unit m³
The parameters Value and Scale must be set to ensure correct metering, the other parameters are used for
an easily readable data display. The user can refer to Table 26 and Table 27 for the fields
Unit. This ensures a uniform display across all meters.
The measured value set up in this way is now updated by incrementing, depending on the number of
pulses acquired, with each readout. For S0 meters, only one meter value can be assigned.
Description and
7.2 Troubleshooting the pulse interface
The meter does not increment
Check the technical specification of the pulse generator, especially its internal resistance or its current consumption in active/inactive state. The detection threshold is approx. 8-10 mA.
Check the polarity.
If errors could not be rectified, please contact your local Danfoss support.
One way to read meters is via serial communication. Physically, these can be found in the form of RS-485,
RS-232, optical interface (D0) or current loop interface (C0).
Some SonoCollect devices offer an RS-485 interface or an RS-232 interface. Coupling of other physics requires appropriate converters (e.g. optical read head for RS-485).
In addition to the physics, the meter's protocol is crucial. Here you can find several variants:
EN 62056-21, also IEC 61107 or IEC 1107 (ASCIIprotocol, called DLDE by us), part of DLMS
"Real" DLMS according to series of standards EN 62056
SML
Modbus RTU
The SonoCollect devices support both SML and EN 62056-21 (Mode A and Mode C). While SML is only processed as a receive stream (data push of the meter), EN 62056-21 allows both the data push to be processed and data to be actively requested from the meter (data request).
8.1 Setup of the interface in the web front end
The setup of a meter with serial interface is only possible manually.
First the serial interface must be activated and parameterized. This is done in the
parameter set
DLDE.... (see section 4.4).
Serial mode
Configuration
tab via the
The parameter Serial mode activates the serial interface and defines the basic range of functions:
The Transparent modes allow the use of the physics of the serial interface via a TCP or UDP port. The data
stream is thus forwarded from the serial interface to an IP interface (network (LAN) or mobile radio (WAN)).
The device then operates in a similar way to an Ethernet-to-serial converter or even a mobile radio router
with a serial interface. The network port to be used is defined in the parameter
The transparent mode makes it possible to read meters via serial interface even if their protocol is
not directly supported by the device. The protocol can then be processed in the host system while
the device provides physical connectivity.
The mode DLDE activates the reading of meters by the device itself. This means that the protocol is handled directly in the device and the meter must be created accordingly (see section 8.2).
Regardless of the mode, the parameters for baud rate, bit representation and timeouts must be set
to match the serial (see section 8.1.2).
DLDE transparent port.
DLDE baud rate, data bits, stop bits and parity
The parameters DLDE baud rate, DLDE data bits, DLDE stop bits and DLDE parity are used to configure the
bit display on the serial interface.
The baud rate essentially determines the speed of the data transmission. The other parameters describe
the byte display:
The number of data bits is either 7 bits or 8 bits.
The parity activates an additional bit to enable error detection. While parity None (no parity, N) re-
nounced this additional bit, the modes Even (even parity, E) or Odd (odd parity, O) add a corresponding bit which supplements the data bits in such a way as to obtain an even or odd number of
ones (1) in the data stream. The modes Mark (character, M) and Space (space, S) complement either
a 1 or a 0, but are practically not used.
The number of stop bits is either 1 bit or 2 bits.
2400-8-E-1 (e.g. for M-Bus)
300-7-E-1 (e.g. for meters according to EN 62056-21)
9600-8-N-1 (e.g. for meters with SML push or according to DLMS)
DLDE mode
The protocol implementation of EN 62056-21 takes place in three variants. This is set by the parameter
DLDE mode.
The mode Push is provided for meters that send their data cyclically, unsolicited. The meters according to
EN 62056-21 and SML protocol can be processed.
Meters which have to be requested according to EN 62056-21 can be requested either via the modes Re-quest or Request (C-Mode). Request is the mode A described in the standard. When the meter is queried, it
gives its meter values in response. The mode C described in the standard allows a baud rate change before
the response with meter data. For this purpose an additional telegram exchange is mandatory (baud rate
negotiation). The exchange is supported in the Request (C-Mode) mode, but the set baud rate is requested.
DLDE timeouts
The serial interface uses three different timeouts with DLDE first timeout, DLDE idle timeout and DLDE full
timeout (in transparent mode only the DLDE idle timeout).
The DLDE idle timeout specifies what time the serial interface must be "idle", i.e. no data is sent/received, in
order to detect the end of a telegram (end of communication). It is mainly used for package formation of
the serial data stream, i.e. the assignment of incoming data to a logical unit (data packet). In the Push mode
this time is used to detect the start of the telegram, therefore no data may be sent from the meter for this
time.
The DLDE first timeout specifies what time it takes to wait for a response from the meter. If no data is received within this time from the request, the readout attempt is aborted.
The DLDE full timeout indicates the latest time at which reception is interrupted in order to process the received meter data. This parameter also terminates reception if the
cause data is continuously received (without idle time, e.g. in the event of faults).
DLDE idle timeout is not reached be-
8.2 Setup of the meter in the web front end
After activating and parameterizing the serial interface, the meter can be added in the
The meter is first created via the Add button or the context menu. To do this, the Interface must be set to
DLDE in the dialog. The parameters
their input is therefore mandatory. Further data
The user may refer to Table 25 for the
Ok button to accept the entries and the meter is created in the meter list in the
the
Serial and Manufacturer are used to assign the meter data to the meter;
Medium or User label are optional and can be assigned.
Medium field. This ensures a uniform display across all meters. Use
A meter value must now be added to the newly created meter. This is done by right-clicking on the newly
added DLDE meter and selecting the
dialogue box for entering the parameters of the meter value.
Add value command from the context menu. This command opens a
Figure Creating the meter a DLDE meter (sample data)
Figure 36 Creating the meter a DLDE meter (sample data)
The assignment of meter values for EN 62056-21 (DLDE) is based on OBIS codes. This 6-digit code is standardized worldwide and clearly describes the measured value. Therefore, it is mandatory to assign the correct value in the parameter
ing to the meter.
OBIS-ID (A-B:C.D.E*F). The parameters Unit and Scale should also be set accord-
We recommend the use of base units like Wh and a scaling factor Scale of 1e+3 compared to the
oten used standard unit for energy meters kWh with factor 1e+0.
The user can refer to Table 26 and Table 27 for the fields Description and Unit. This ensures a uniform display across all meters.
The measured value set up in this way is now read out and recorded cyclically by the meter. The DLDE meters often transmit multiple values for various OBIS codes, so additional meter values can be added to the
meter. Here are a few examples of commonly used OBIS codes, especially for energy meters:
1-0:1.8.0*255 → Total value of active energy import
1-0:1.8.1*255 → Total value of active energy import (tariff 1)
1-0:1.8.2*255 → Total value of active energy import (tariff 2)
1-0:2.8.0*255 → Total value of active energy export
1-0:3.8.0*255 → Total value of apparent energy import
1-0:4.8.0*255 → Total value of apparent energy export
1-0:1.7.0*255 → Instantaneous value of active power import
1-0:31.7.0*255 → Instantaneous current phase 1
1-0:51.7.0*255 → Instantaneous current phase 2
1-0:71.7.0*255 → Instantaneous current phase 3
1-0:32.7.0*255 → Instantaneous voltage phase 1
1-0:52.7.0*255 → Instantaneous voltage phase 2
1-0:72.7.0*255 → Instantaneous voltage phase 3
8.3Troubleshooting the serial interface
Meters are not read out
Check whether the parameters of the serial interface are set correctly in the
Check whether the meter supports the protocol according to IEC 62056-21 (DLDE mode Request) or spon-
taneously transmits data according to IEC 62056-21 or SML format (
Check the timeout parameters of the serial interface in the
Activate the raw data log with Raw data log in the
analyzed using this raw data log.
If errors could not be rectified, please contact your local Danfoss support.
Contains a complete package with one or more muc entries.
MESSAGE_TYPE
Specifies the type/version of the package: e. g. 1
muc
Contains the data for one device at a time with corresponding meter entries.
MUC_ID
Hexadecimal notation of the serial number of the device (corresponds to the serial number/MAC
address on the website in the General tab).
VERSION
Protocol version
9 Transmission of meter data
A basic distinction is made between actively sending data, the data push, and collecting data, the data pull
when transmitting meter data to third-party systems such as meter data management, energy management or monitoring systems.
The SonoCollect device is the client and the third-party system is the server in the client-server model. In
the case of the data pull, the SonoCollect device is the server and the third-party system is the client. The
client establishes the connection and monitors the data exchange. The server answers the requests and
executes the commands of the client.
This chapter describes the data push, which can be configured in the data concentrators in the
The data pull is described separately, e.g. in the chapter
11 or in the section 2.6.
9.1 Instances and database
In the SonoCollect devices of 10 independent report instances can be parameterized. The settings such as
cycle time, data format, transport mechanism and other parameters can be set for each of these reports in
Server
the
The data sent in the reports is stored in a database. The database is file-based and uses SQLITE. The report
instances therefore have the same data.
tab (see section 2.6).
The database is not active until at least one report instance is active. If not, no data is stored in the
database and is therefore not available later.
Only active values (column Active in the
Meter
) tab are written to the database. Other values are not
available later.
Report
tab.
9.2 General settings
Each instance has a parameter set. This can be configured via the web interface in the
rameters are always to be configured, others depend on the set mode.
The following parameters are available and to be configured for each instance:
Report mode: Operating mode or deactivation of the respective instance (see also section 4.6)
Report format: Data format for the transmission of the respective instance ( see also section 4.6)
Report cycle mode: Format specifying the transmission cycle of the respective instance (see also
section
4.6).
Report cycle: Transmission cycle of the respective instance (see also section 4.6)
Report cycle date (local): Day of transmission of the respective instance, for weekly to annual for-
mat (see also section
4.6)
Report cycle time (local): Time of transmission of the respective instance, with daily to annual for-
mat specification (see also section
4.6)
Report
tab. Some pa-
9.3 Preset data or file formats
The SonoCollect devices have some predefined data formats.
XML format
Several XML formats are available for transmission. XML is a data stream distinguished by so-called tags
(entries and attributes) for the display of hierarchically structured data. These data are usually in plain text
and therefore readable by both humans and machines.
Application-specific description of the meter (configured in the Meter tab)
MAN
Manufacturer code of the meter
VER
Version number of the meter
MED
Medium of the meter, see second column in Table 25
data
Contains one or more measured values of a type in the respective entry entries, which are
OBIS_ID
OBIS code according to OBIS specification is configured via the web page, in version XML-8 the
DIF/DIFE/VIF/VIFE fields from the M-Bus/wM meter value are transmitted in this code.
DESCRIPTION
See second column in Table 26
MEDIUM
Medium of the meter, see second column in Table 25
UNIT
See second column in Table 27, energy values in Wh are converted to kWh
SCALE
Signed scaling factor (scientific notation)
DIF
DIF/DIFE fields from the M-Bus/wM-Bus raw data, the display is in hexadecimal byte notation.
VIF
VIF/VIFE fields from the M-Bus/wM-Bus raw data, the representation is in hexadecimal byte
notation.
USER
Application-specific description of the meter value (configured in the Meter tab)
entry
Data entry consisting of a time stamp (T) and a measured value (VAL)
parameter
Contains a parameter value
NAME= “T”
The associated parameter value represents the UNIX time (UTC) at the time of the measurement,
NAME= “T_MUC”
The associated parameter value represents the UNIX time (UTC) of the device at the time of
NAME= “VAL”
The associated parameter value represents the measured value specified in data.
Entry
Attribute
XML-3
XML-6
XML-7
XML-8
XML-9
interface
x
x
x
x
x
MESSAGE_TYPE
x
x
x
x
x
muc
x
x
x
x
x
MUC_ID
x
x
x
x
x
TIMESTAMP
x
x
x
x
x
meter
x
x
x
x
x
INTERFACE
Numeric
Numeric
Numeric
Numeric
Text
METER_ID
x
x
x
x
x
USER
x
x
x
x
MAN
x
x
x
VER
x
x
x
MED
x
x
x
MED_ID
x
data
x
x
x
x
x
OBIS_ID
x
x
x
Raw data
x
DESCRIPTION
x
x
x
x
x
MEDIUM
x
x
x
x
SCALE
x
x
x
x
x
VIF
x
DIF
x
USER
x
x
x
x
entry
x
x
x
x
x
parameter
x
x
x
x
x
NAME= „T“
x
x
x
x
x
NAME= „T_MUC“
x
x
x
x
x
NAME= “VAL“
x
x
x
x
x
MED_ID Medium ID of the meter, see first column in Table 25
specified via the attributes.
if transmitted by the meter with the measured value.
receipt of the measurement data
Table 18: Format of the XML data
The following table illustrates the different protocol versions:
Several CSV formats are available. CSV is a table-like file format which uses a character, at Danfoss a semicolon ";" to separate numerical values and texts (columns) from each other. This makes processing or viewing
e.g. with Excel very easy.
The header line in the file specifies the column heading; the following lines contain data on the meter and
the meter values at a particular readout time.
The CSV data have the following format:
Index Indexes the different devices within a CSV file
The timestamp transmitted by the meter (Unix timestamp or readable time), or 0 if not available.
ObisidX
OBIS-ID (column OBIS-ID in Meter tab)
Column
CSV-0
CSV-1
CSV-3
CSV-4
CSV-5
CSV-6
CSV-9
Index
x
x
Timestamp
Unix
Unix
Unix
Unix
Unix
Unix
Plain text
Link x
x
x
x
User
x
x
x
IndexX
x
x
ValueX
x
x
x
x
x
x
x*
ScaleX
x
x
x
x
x
x
UnitX
x
x
x
x
x
x
x
DescriptionX
x
x
x
x
x
x
x
UserX
x
x
x
x
x
x
TimestampX
Unix
Unix
Unix
Unix
Unix
Plain text
ObisIdX
x
x
x
x
x
x
x
Object
Property
Data type
Description
muc
Object
Contains the data for one device at a time with corresponding meter entries.
MUC_ID
String
Hexadecimal notation of the serial number of the device (corresponds to the serial
VERSION
String
Protocol version
TIMESTAMP
Integer
UNIX time (UTC) at time of transmission
meter
Array
Array of meter objects
meter
Object
Contains the data for one meter at a time with corresponding data entries.
METER_ID
String
Serial number of the meter
INTERFACE
String
Interface of the meter
S0
MBus
wMBus
DLDERS
System
Table 20: CSV format
The first columns of a line entry contain data of the meter, including the meter identification (address) and
the time the data was read out. The other columns are inserted dynamically according to the configured
meters and number of meter values, whereby the meter values are inserted starting from 0 (e.g.: Value0).
The following table illustrates the different protocol versions:
DeviceId x x x x x x x
*scaled value
Table 21: Data in different CSV versions
An example record of the CSV data in version 3 is shown in the following figure:
Figure 37 Section of a CSV log file
JSON format
A JSON format is available for transmission. JSON is a compact, serialized data stream for representing
structured data. These data are usually readable by both humans and machines and separated by separators.
number/MAC address on the website in the General tab).
Medium of the meter, see second column in Table 25
MED_ID
String
Medium ID of the meter, see first column in Table 25
USER
String
Application-specific description of the meter (configured in the Meter tab)
data
Array
Array of data objects
data
Object
Contains the data for one meter value each with corresponding entry entries.
DESCRIPTION
String
See second column in Table 26
UNIT
String
See second column in Table 27; Energy values in Wh are converted to kWh
SCALE
String
Signed scaling factor (scientific notation)
OBIS_ID
String
OBIS code according to OBIS specification is configured via the web page, in version
USER
String
Application-specific description of the meter value (configured in the Meter tab)
VIF
String
VIF/VIFE fields from the M-Bus/wM-Bus raw data, the representation is in hexadecimal
byte notation.
entry
Array
Array of data objects
entry
Object
Data entry consisting of a time stamp (T) and a measured value (VAL)
T_MUC
Integer
UNIX time (UTC) of the device at the time of receipt of the measurement data
T
Integer
UNIX time (UTC) at the time of the measurement, if transmitted by the meter with the
VAL
String
Measured value specified in data
XML-8 the DIF/DIFE/VIF/VIFE fields from the M-Bus/wM-Bus raw data are transmitted to
the meter value in this code.
DIF String DIF/DIFE fields from the M-Bus/wM-Bus raw data, the display is in hexadecimal byte
notation.
measured value
Table 22: Format of the JSON data
A sample JSON packet looks like this (breaks inserted due to display):
{"muc":{ "MUC_ID":"6891d0800e62","VERSION":"1","TIMESTAMP":1601297784,"meter":[
{"METER_ID":"00000001","INTERFACE":"MBus","MAN":"SIE","VER":21,"MED":"Electricity",
"MED_ID":2,"USER":"metering1","data":[
{"DESCRIPTION":"Energy","UNIT":"kWh","SCALE":0.001,"OBIS_ID":"1-0:1.8.0*255",
"USER":"energy3","DIF":"04","VIF":"03","entry":[
{"T_MUC":1601297679,"VAL":"537980",{"T_MUC":1601297761,"VAL":"537980",
{"T_MUC":1601297765,"VAL":"537980",{"T_MUC":1601297770,"VAL":"537980"]],
{"METER_ID":"00094824","INTERFACE":"MBus","MAN":"BEC","VER":32,"MED":"Electricity",
"MED_ID":2,"data":[
{"DESCRIPTION":"Energy","UNIT":"kWh","SCALE":0.01,"DIF":"0E","VIF":"84 00","entry":[
{"T_MUC":1601297679,"VAL":"2887897",{"T_MUC":1601297761,"VAL":"2887897",
{"T_MUC":1601297765,"VAL":"2887897",{"T_MUC":1601297770,"VAL":"2887897"],
{"DESCRIPTION":"Power","UNIT":"W","SCALE":0.01,"DIF":"04","VIF":"A9 00","entry":[
{"T_MUC":1601297679,"VAL":"382207",{"T_MUC":1601297761,"VAL":"382207",
{"T_MUC":1601297765,"VAL":"382207",{"T_MUC":1601297770,"VAL":"382207"]]]
User format
If the above options do not fit or are not sufficient, the report can be switched to scripting with Report format User.
This provides the user with an XSLT parser to generate specific data formats. An overview of this can be
found in section 10.7 and specifically in section 10.7.1.
Only one user format is available for the standard operating modes (e.g. TCP or FTP). For different, userspecific formats, the script-based report (see section 9.10) must be used.
A common communication method for transmitting data is to use the data content of TCP packets. The
data is thus sent as a data stream to the remote station, where it is collected and processed.
The data is transmitted unencrypted using TCP. If encryption is necessary, the data should be sent via TLS
(see section 9.5).
Since the data processing systems are usually databases or similar, an automated processable data format
such as XML or JSON is preferred here. But any data format can be transferred.
According to the destination the parameters Report address, Report port and Report directory have to be
set. An empty path specification in
generates an HTTP data stream (e.g. "/", "/upload").
Report directory generates a TCP data stream, a set path specification
Figure 38 Example configuration for 15-minute transmission of XML data via TCP
9.5 Data transmission via TLS
As a rule, an unencrypted TCP connection for the transmission of data (see section 9.4) is not recommended in productive use. Encryption is common here.
The data stream is asymmetrically encrypted via TCP by using TLS. Each participant has both a private key
known only to him and a public key known to everyone. Data that is exchanged is encrypted with the public key of the other participant. The decryption is then performed using the secret private key on the recipient side.
Figure 39 Example configuration for hourly transmission of XML data via TCP
TLS also offers mutual authenticity checks of client and server by means of signed certificates, which provides a very high level of security. A distinction is made between server-side authentication and client-side
authentication, depending on which side is authenticating. Both variants are supported, also in combination, by the products of Danfoss.
The SonoCollect devices use certificates in the PEMformat (RFC 7468).
In the case of server-side authentication, the server, and in the case of data collectors and gateways therefore the remote terminal, must authenticate itself. In order to check its certificate, a certificate from a certification authority (its public key) must be installed on the SonoCollect device against which the server certificate can be checked.
Unless otherwise specified and available, the file app/cacert.pem is used to check the authenticity
of the server on the SonoCollect devices (RFC 4945).
The client, and therefore the device in the case of data collectors and gateways, must authenticate itself
with client-side authentication. It requires an issued certificate and a secret private key in this case.
Unless otherwise specified and available, the file app/clicert.pem is used as the certificate of the de-
vice for the SonoCollect devices (RFC 5280).
Unless otherwise specified and available, the file app/clikey.pem is used as the private key of the
device for the SonoCollect devices (RFC 5958).
The certificates can be uploaded manually via SFTP (see also section 3.4
port via the
Service
tab (see section 4.10). The file(s) must be packed as a *.tar.gz file in this case.
). However, it is also possible to im-
To create a *.tar.gzarchive, the free, open source software 7zip can be used. The file meter_conf_im-
port.csv can be packed herewith without subdirectory first into a *.tar ball and afterwards into a *.gz
archive.
If the files are to be named differently or different certificates are possibly required per configured
server instance, the use of other file names and paths must be entered manually in the file
app/chip.ini (see also section 10.3).
The following parameters are entered for the assignment to the respective report in the file app/chip.ini in
the area [REPORT_x]:
CA_FILE: the public key of the certification authority matching the server certificate, e.g.:
CA_FILE=app/srv\_instance1.pem
CERT_FILE: the certificate of the device for the respective report, e.g.: CERT_FILE=app/dcu.pem
KEY\_FILE: the private key matching the certificate of the device, e.g.: KEY_FILE=app/key.pem
9.6 Sending files via FTP
Another common communication method for transferring data is the use of the FTP protocol, especially
when it comes to file-based transfer.
The data is transmitted unencrypted using FTP. If encryption is required, data should be sent via SFTP or
FTPS (see section 9.6.1).
Since files are transferred, the CSV format is preferred here. It enables easy import into Excel or databases
among other things. However, other data formats can also be transferred.
According to the destination, the parameters Report address, Report port, Report directory, Report
username and Report password must be set.
Figure 40 Example configuration for automatic transfer of CSV data via FTP
The Report mode is either FTP (active) or FTP (passive). Both differ in the procedure by the definition of the
port to be used for the data connection. FTP uses one TCP port for the control connection, e.g. for transmitting control commands, and a second TCP port for the data connection. The client specifies the second
port; in the passivemode, the server specifies the second port in the active mode. Therefore, FTP (passive) is
usually used, because firewalls on the server side often only allow outgoing communication on an "arbitrary" port.
If no Report port is specified, the default port 21 is used.
Sending files via SFTP or FTPS
As a rule, an unencrypted FTP connection for transferring files (see section 9.6) is not recommended for
productive use. Encryption is common here.
By using TLS, secure transmission is also possible for FTP (see also section 9.5). A distinction is made here
between SFTP, an FTP imitated via SSH, and FTPS, FTP via a channel secured by TLS. Since SSH also uses
SSL, both are very similar from a security standpoint. SFTP has the advantage that SSH and therefore only
one port is used (usually port 22) while FTPS uses the two ports as with FTP, only the data content is encrypted.
Encrypted/secured FTP is usually SFTP not FTPS.
Figure 41 Example configuration for monthly transfer of CSV files via SFTP
Since both variants involve a connection secured by TLS, appropriate certificates must be stored and configured. Background information and the procedure are described in section 9.5.
9.7 Sending e-mails via SMTP
Data can also be sent by e-mail. SMTP is used for this purpose.
It is necessary to send this data in the text of the e-mail or as an attachment depending on the require-
ment.
SMTP itself is not encrypted. The STARTTLS extension provides a certain level of security based on TLS, but
the connection is also established unencrypted. For complete encryption of the communication, the use of
SMTPS is recommended.
MQTT is a widely used standard in cloud communications, specifically for sending data to a cloud system. It
is an open network protocol which can be used in the area of M2M communication despite potentially
high delays and networks which are not continuously available. TCP ports 1883 and 8883 reserved for
MQTT, the latter for encrypted communication using the TLS protocol.
MQTT distinguishes between:
Publischer: Device or service that sends the data, e.g. a sensor or a data concentrator.
Subscriber: Device or service that processes the data, e.g. a visualization or a billing software.
Broker: Central data hub for MQTT, this also manages the network and ensures robustness
MQTT uses so-called topics to classify messages hierarchically. This is comparable to a path specification.
The publisher sends data of these Topics to the Broker. This then distributes the data to the subscribers.
Certificates must be provided on the device for the encrypted connection via port 8883. Ask your administrator in this case.
Example Azure Cloud
Set the parameters as follows to connect to an Azure cloud:
Report address: Internet address of the Azure cloud server
Report directory: Device ID and Topic for the Azure Cloud
Report user name: User name for the Azure cloud, usually consisting of internet address, device
name and API version.
Report password: Password for the Azure cloud, usually a composition of access key, signature and
expiration date.
The following example should clarify the parameters:
Report address: ExampleHub.azure-devices.net
Report directory: devices/MUC063C/messages/events
Report user name: ExampleHub.azure-devices.net/MUC063C/?api-version=2018-06-30
Report password: SharedAccessSignature sr=ExampleHub.azure-devices.net%2fdevices%2f
MUC063C&sig=rQXaVuN%2bjWqh0vVr9E6ybo7VbMBQ4QQNOidzMtoqI2g%3d&se=1639260907
Set the parameters as follows to connect to an AWS cloud:
Report address: Internet address of the AWS cloud server
Report directory: User name and Topic for the AWS Cloud
Report user name: User name for the AWS Cloud
Report password: Password for the AWS Cloud
The following example should clarify the parameters:
The meter data can also be stored directly on the device as a file. This can be used if the data is to be called
via FTP, for example. This is called a data pull.
As with all other reports, the predefined formats and the user-specific format are available for selection.
The files are stored according to the set parameters in the folder ext/Log/YYYY/MM, where YYYY is the asso-
ciated year and MM is the associated month for the report (according to the system time of the device).
The following settings, for example, cause a CSV file containing all readings from the previous report pe-
riod to be created and stored on the system every day at 01:00 local time:
Figure 44 Example of a report via local file storage
If the above options do not fit or are not sufficient, the report can be switched to scripting using Report
port User.
This way, the user has free access to the powerful Linux tools supplied with the device. Each instance is assigned its own script. An overview of this can be found in section 10.7 and specifically with examples in
section 10.7.2.
Since the script-based report offers a lot of freedom, additional parameters Report user parameter 1, Report user parameter 2 and Report user parameter 3 are available to the instance, in which any texts can be
entered. This information is then available to the script. The parameters of the report instance can be used
in the script, but do not have to be.
Figure 45 Example configuration for 15-minute transfer of CSV data via a user script
9.11 Specific troubleshooting
Troubleshooting the transmission of meter data is very complex. Typically it is due to connectivity or au-
Log
thentication/encryption. Indications of the cause of the error can be found in the
Check whether the remote terminal can be reached. Use the ping command from the SSH console of the
device for this purpose (see also section 10.1.2). This will also check the name resolution (DNS). A hostname
should be converted to an IP address when pinging.
Check whether a firewall blocks the data exchange or the routing is configured accordingly. Ask your administrator in this case.
In the case of TLS encryption, check whether all necessary certificates are available, especially the CA certificate for the remote terminal.
Check the correct entry of Report username and Report password as well as Report address, Report port
Report directory of the respective instance.
and
If errors could not be rectified, please contact your local Danfoss support.
The SonoCollect devices are based on the Linux operating system. This ensures that the devices continuously follow the state of the art and that errors in the software are quickly found and corrected due to a
large community. It also ensures a certain basic functionality and security for the user.
The Linux operating system is built through the Yocto/openembedded build environment, with all components included according to the latest version and security patches. The Linux itself is unchanged except
for a few specific tools and customizations (e.g. solcmd). Corresponding Linux documentation can thus be
used directly. For custom projects, additional components provided on the Yocto/openembedded platform can be made available on the target system.
User rights
Linux supports and has in principle user roles. There is operating system internally the user root with full
access to all operating system functions. In addition, further users with restricted access can be created.
Their permissions can be set by groups and names, mostly file access permissions (read, write or execute).
In case of the SonoCollect devices, in addition to the user root, the user admin has also been created. It has
read and write access to the partitions /app and /ext and can execute files there. For the user, admin is the
user who can completely configure the device.
The user web is created as the default user for the web interface, but has no access rights to the file
system.
For reasons of downward compatibility, the user ftp is created as the default user for FTP access to
the directory /ext.
The user root has no external access to the device. It protects the safety of the user. Only the user
admin can grant the user root the release.
The password of the user root is generated randomly and device-specific during production and
stored access-protected in a database.
Command line
The Linux operating system on the SonoCollect devices has a command line based on BASH. It allows the
user and also other applications to execute commands via the command line.
The user can access the command line via an SSH console. The Netdiscover tool (see chapter 3 ) opens an
SSH console with a Putty client.
Standard commands
The Linux operating system and the command line BASH provide certain built-in standard commands. Examples include:
help: Display list of all integrated commands
cd: Navigation in the directory tree
ls: List directory contents
cat: View file contents
cp: Copying files/directories
mv: Move/rename files/directories
rm: Delete files/directories
sync: Write the data from the RAM buffer to the data carrier
chmod: Adjust access rights
grep: Search for text content
echo: Output text
date: Display system time
ps: Show list of all running processes
tail: Output last lines of a file
netstat: Query the status of the network interfaces
ping: Network connectivity test
nslookup: Display of the DNS configuration
/sbin/ifconfig: Overview of the network interfaces
Further commands are provided by programs:
tcpdump: Recording network traffic
openssl: Use of encryption, certificates and PKI
curl: Calling a server connection
esmtp: Sending e-mails
socat: Connecting two interfaces
vi: Editing files
xsltproc: Execution of XSL transformations
Solcmd command interpreter
For special application functions of Danfoss there is a command interpreter solcmddue to the system access rights. The interpreter can be called with various parameters and thus provides access to the application and its control.
The following parameters are supported:
format-partition-app: Formatting the configuration partition /app
format-partition-ext: Format the logging partition /ext
config-partitions: Resetting the access rights to the partitions
config-users: Transfer of the changed user settings
config-hostname: Acceptance of the changed device name
config-timezone: Adopting the time zone setting
restart-eth0: Restart of the Ethernet interface
restart-wifi: Restarting the WLAN interface (only if WLAN is available)
filter-vlan: VLAN filter for network interface (only if switch integrated)
start-ppp0: Establishing the PPP dial-up connection (mobile network)
stop-ppp0: Disconnection of the PPP dial-up connection (mobile network)
start-vpn: Establishing a VPN connection (OpenVPN)
stop-vpn: Terminating a VPN connection (OpenVPN)
manual-vpn: Establishment of a VPN connection (OpenVPN) in the foreground with manual pass-
word entry
restart-server: Restarting the server services
regenerate-server-keys: Re-creating the keys for secured server services
start-solapp: Starting the main application
stop-solapp: Exit the main application
start-transparent-tty: Activate transparent data forwarding of a serial interface to Ethernet port
stop-transparent-tty: Stop transparent data forwarding of a serial interface to Ethernet port
start-virtual-tty: Activating a virtual interface via an Ethernet port
stop-virtual-tty: Terminating a virtual interface via an Ethernet port
update-rtc: Writing the system time to the buffered real-time clock
factory-reset: Resetting the device to factory settings
update-system: Performing a System Update
reboot-system: Restarting the system
help: Command overview with explanation and examples
10.2 Update
The firmware can be updated manually or conveniently via the web interface (see section 4.10).
IP address of the secondary DNS server, IP or host
Text, max. 255 characters
Not set
Group [VPN]
ENABLE
Activation of the OpenVPN client
0.1
0
Group [WEB]
HTTP_ENABLE
Activation of the HTTP server
0.1 1 HTTPS_ENABLE
Activation of the HTTPS server
0.1
1
Group [FTP]
ENABLE
Activation of the FTP server
0.1
1
Group [SSH]
ENABLE
Activation of the SSH server
0.1
1
Group [UDPCFG]
ENABLE
Activation of the UDP-based search and
0.1
1
Group [Danfoss]
BACNET_BBMD
IP of the BACnet BBMD (BACnet Broadcast
Management Device)
Text, max. 255 characters
Not set
BACNET_BROADCAST
BACnet broadcast IP address (system configuration
Text, max. 255 characters
Not set
Access via SSH is necessary for a manual update, and the easiest way to download the update file is via
SFTP. The tools for this are provided by the Netdiscover tool (see chapter 3).
First, the appropriate and signed update file *.enc must be loaded via SFTP into the directory ext/Upd (see
section 3.4). It requires the admin access.
After uploading the file, the user must log in as admin via SSH (see section 3.5). In the command line (see
section 10.1.2), the command solcmd update-system must then be executed. After completion, a reboot is
necessary, which is triggered with the command solcmd reboot-system.
10.3 Configuration file chip.ini
The file /app/chip.ini contains the general system parameters and is therefore the central configuration file.
The parameters are grouped into different sections. If the parameters are not configured in chip.ini, the default values are used.
In order for manual changes to the file chip.ini to be adopted by the device, it must be restarted via
the web front end using the button
Reboot system in the
Manually changed data will only be permanently stored on the flash after a few minutes. As a re-
sult, such changes may not be applied after a power supply reset.
The file chip.ini can be transferred to another device via FTPS, taking into account the network con-
figuration (e.g. different IP address).
Service
tab or the command line.
name
name
configuration protocol
IPCFG_PASSWORD Password for changing the IP address via the UDP
bit value (0: first FCB bit set, 1: first FCB bit not set)
Classified as Business
Parameter
Description
Value range
Standard
MBUS_FLOWCONTROL
Flow control for M-Bus communication:
0, 1, 2, 8, 9
0
MBUS_FORCE
Compatibility mode for reading faulty M-Bus
0-2
0
MBUS_FREEZE\STORAGENUM
Memory number for freeze meter data
0-4294967295
0
MBUS_FULL\TIMEOUT
Maximum waiting time for reading out the meter
(in ms)
0-65535
10000
MBUS_IDLE\TIMEOUT
Time out to detect the end of communication (in
0-65535
100
MBUS_IGNORE\CRCFIELD
Compatibility mode for reading faulty M-Bus
0, 1
0
MBUS_IGNORE\LENGTH\FIELD
Compatibility mode for reading faulty M-Bus
meters, ignores length field
0, 1
0
MBUS_LOAD\PROFILE\MANUF
Manufacturer code for identification of the load
→
0-65535
5544
MBUS_LOAD\PROFILE\MAXCO
Number of load profile entries that are initially
1-65535
65535
MBUS_LOAD\PROFILE\MODE
Activation of load profile reading for electricity
meters via M-Bus
DISABLED, DIZH, DIZG
DISABLED
MBUS_LOADPROFILE START
Start index for the load profile call
0-65535
1
MBUS_MAX\MULTIPAGE
Limits the number of multipage requests
0-255
3
MBUS_MAX\PRIMARY\ADDRE
Upper address for M-Bus primary search
0-250
250
MBUS_MAX\RETRY
Retries for a M-Bus or multipage request
0-255
3
MBUS_MIN\PRIMARY\ADDRES
Lower address for M-Bus primary search
0-250
0
MBUS_NOADDRESS\VERIFY
Deactivates the address check for primary
0, 1
0
MBUS_PARITY
Parity for the M-Bus communication:
4: space
0-4
2
MBUS_RAWLOG\ENABLE
Activation of raw data logging to the directory
ext/
0, 1
0
MBUS_REQUEST\MODE
Inquiry mode
ALL, EXT, ONLY, FREEZE
ONLY
MBUS_RESET\MODE
Reset Modes:
0-4
0
MBUS_RS485\ENABLE
Activation of the RS-485 interface for M-Bus
communication
0, 1
0
MBUS_SCAN\MODE
Search algorithm for the M-bus
PRIMARYSCAN,
SECONDARYSCAN
MBUS_SEC\MASK\MANUFACT
URER
Predefined manufacturer ID for secondary search
Exactly 4 characters each
0-9 or 0xFFFF
0xFFFF
MBUS_SEC\MASK\MEDIUM
Predefined medium ID for secondary search
Exactly 2 characters each
0xFF
MBUS_SEC\MASK\SERIAL
Secondary search mask for the meter serial number
Exactly 8 characters each
0xFFFFFFFF
MBUS_SEC\MASK\VERSION
Predefined version number for secondary search
Exactly 2 characters each
0-9 or 0xFF
0xFF
MBUS_SELECT\MASK
Hiding of selection areas, placeholders are used for
0-15,
14
0: none,
1: XON/XOFF during transmission,
2: RTS/CTS,
8: XON/XOFF when receiving,
9: XON/XOFF during transmission and reception
meters, emulates correct ACK
ms)
meters, ignores CRC field
ACTURER
UNT
SS
S
profile meter, according to M-Bus standard:
"`EMH"'=(0xA8 0x15)
called from the meter.
addressing
0: none,
1: odd,
2: even,
3: mark,
0: NKE after Select,
1: NKE before Select
2: No NKE
3: NKE at 0xFD and NKE at 0xFF before
communication
4: NKE at 0xFD, Application Reset at 0xFF and NKE at
0xFF before communication
Activation of manufacturer-specific decoding
(manufacturer code SPX)
0, 1
0
MBUS_STOPBITS
Stop bits for M-Bus communication
1, 2
1
MBUS_TIMEOUT
Waiting time until first data are received from the
0-65535
2000
MBUS_TRANSPARENT
Activation of transparent forwarding of the M-Bus
NONE, MBUS, TCP, UDP
NONE
MBUS_WAKEUP\ENABLE
Activation of the specific wakeup request
0, 1
0
MBUSSLV_BAUDRATE
Baud rate for M-Bus slave communication
300, 600, 1200, 1800,
230400, 460800
2400
MBUSSLV_DATABITS
Data bits for M-Bus slave communication
7, 8
8
MBUSSLV_DEBUGOUT
Activation of raw data output for M-Bus slave
communication in the system log
0, 1
0
MBUSSLV_DEVPATH
Linux path for the M-Bus slave interface
Text, max. 255 characters
Not set
MBUSSLV_FLOWCONTROL
Flow control for M-Bus slave communication:
0, 1, 2, 8, 9
0
MBUSSLV_FULLTIMEOUT
Maximum waiting time for the request for a meter
0-65535
10000
MBUSSLV_IDLETIMEOUT
Time out to detect the end of communication (in
ms)
0-65535
100
MBUSSLV_PARITY
Parity for M-Bus slave communication:
4: space
0-4
2
MBUSSLV_RS485\ENABLE
Activation of the RS-485 interface for M-Bus slave
0, 1
0
MBUSSLV_STOPBITS
Stop bits for M-Bus slave communication
1, 2
1
MBUSSLVMETER_ECHO
Echo suppression
0, 1
Depending on
MBUSSLVMETER_MODE
Activation of the M-Bus slave interface:
interface
DEFAULT, NONE, TCP,
DEFAULT
MBUSSLVMETER_PORT
Network port for access to the M-Bus slave interface
0-65535
5040
MBUSSLVMETER_WMBUSALL
OW\ENCRYPTED
Activates the forwarding of encrypted wM-Bus
meters via the M-Bus slave interface
0, 1
0
MBUSSLVMETER_WMBUSALL
Activates the forwarding of specific wM-Bus header
0, 1
0
MBUSSLVMETER_WMBUSALL
Activates forwarding despite unknown wM-Bus
0, 1
0
MBUSSLV2METER_MODE
Activation of the second M-Bus slave interface:
UDP: Activation via a UDP port
NONE, TCP, UDP
NONE
MBUSSLV2METER_PORT
Network port for access to the second M-Bus slave
0-65535
5050
MBUSSLV2METER_WMBUSALL
Activates the forwarding of encrypted wM-Bus
0, 1
0
8: Medium
meter (in ms)
interface to a network port or an M-Bus slave
interface:
NONE: Forwarding disabled,
TCP: Forwarding to a TCP port,
UDP: Forwarding to a UDP port
MBUS_TRANSPARENT\PORT Network port for transparent forwarding via TCP or
UDP
0: none,
1: XON/XOFF during transmission,
2: RTS/CTS,
8: XON/XOFF when receiving,
9: XON/XOFF during transmission and reception
0-65535 0
2400, 4800, 9600, 19200,
38400, 57600, 115200,
OW\EXTENDEDHEADER
OW\OTHER
(in ms)
0: none,
1: odd,
2: even,
3: mark,
communication
DEFAULT: Activated depending on the product,
NONE: Disabled,
TCP: Activation via a TCP port,
UDP: Activation via a UDP port,
MBUS: Activation via the physical M-Bus slave
via TCP or UDP
data (e.g. AFL/ELL) via the M-Bus slave interface.
Activation of the RS-485 interface for serial Modbus
communication (RTU)
0, 1
0
MODBUS_SPAN
1
MODBUS_STOPBITS
Stop bits for Modbus serial communication (RTU)
1, 2
1
MODBUS_VENDOR
Manufacturer information within the device
Text, max. 255 characters
MODBUS_VENDORURL
Website information about the manufacturer within
the device identification
Text, max. 255 characters
MODBUS_VERSION
Version information within the device identification
Text, max. 255 characters
1.34.1001.1
MODBUS_WRITE ACCESS
READONLY
MODBUSMETER_PROTOCOL
Protocol version of the Modbus meter data:
Bit 3: Dummy mode activated
0-16
0
MUC_CONFIG_VER
Version of the configuration, compatibility with
1-21
-
MUC_LOG
Sets the level of the system output via system log
DEFAULT,
DEFAULT
MUC_LOGCYCLE DIVIDER
1
MUC_REPORT
0
MUC_REPORT
SCRIPTABORTTIMEOUT
30
MUC_SCALEVALUES
Scaled numerical values within the CSV and XML log
0, 1
0
MUC_SETDEVICES
Activation of the setting of meter values
S0,
S0
MUC_SETDEVICETIME
0
MUC_SHOWDATAFRAME
Explicit listing of the raw data frame as meter value,
0, 1
0
MUC_SHOW
TIMESTAMPENTRIES
Explicit display of the timestamps of a meter
0, 1
0
MUC_SHOW
Explicit listing of the manufacturer-specific data as a
0, 1
0
MUC_SHOW
Display of binary data on the web page
0, 1
0
MUC_SHOW
WMBUSRSSIVALUE
0
MUC_TRIMVALUES
0
MUC_USE_FREEZE
Activation of the freeze command for meter reading
0, 1
0
SHOW_KEYS
Display decryption data on the web page.
0, 1
1
SNTP_ENABLE
Activation of the time reference via SNTP server
0, 1
1
SNTP_REQTIMEOUT
Waiting time for an SNTP request (in ms)
1-65535
15000
SNTP_RETRY
Number of retries for an SNTP request
0-255
2
SNTP_TIMEOUT
Waiting time for a new SNTP time poll (explicit, in s)
1-4294967295
86400
identification
VERSION
MUC_METER
DESCRIPTION_ENABLEFLAGS
FATALREBOOTTIMEOUT
Bit 0: 2 registers per value (floating point value
only),
Bit 1: Multislave activated,
Bit 2: Word swapping of 32-bit floating point values,
older firmware versions.
Enable flags for the display of the description on the
web page:
Bit 0: Description
Bit 1: Storage-Number, Tariff, Value Type
Bit 2: DIF/VIF raw data
Bit 3: Total raw data of the data value entry
for multipage meter one entry is inserted per frame
Explicit listing of the status byte of the meter (M-Bus
and wM-Bus) as meter value
meter value
(manufacturer-specific or data container)
0, 1 0
Classified as Business
Parameter
Description
Value range
Standard
SNTPIP
Address of the time server (SNTP)
Text, max. 255 characters
pool.ntp.org
SNULL_ENABLE
Activation of the S0 interface
0, 1
0
SNULL_MODE
Metering mode for S0
RELATIVE,
RELATIVE
WAN_APN
Access point for dialling into the WAN
Text, max. 255 characters
Not set
WAN_AUTH
Authentication procedure for dialling into the WAN
NONE, PAP,
CHAP
WAN_BAUDRATE
Baud rate for WAN communication
300, 600, 1200, 1800,
230400, 460800
115200
WAN_DATABITS
Data bits for WAN communication
7, 8
8
WAN_DEBUGOUT
Activation of raw data output for WAN
0, 1
0
WAN_DEVPATH
Linux path for the WAN interface
Text, max. 255 characters
Not set
WAN_ENABLE
Activation of WAN communication (mobile radio)
0, 1
0
WAN_FLOWCONTROL
Flow control for WAN communication:
0, 1, 2, 8, 9
0
WAN_FULLTIMEOUT
0
WAN_IDLETIMEOUT
0
WAN_MAXRETRY
Number of retries for the WAN connection setup (0:
0-255
0
WAN_OLDBAUDRATE
Baud rate for WAN communication, only affects
300, 600, 1200, 1800,
0
WAN_PARITY
Parity for WAN communication:
0-4
0
WAN_PASSWORD
Password for dialling into the WAN
Text, max. 255 characters
Not set
WAN_PIN
PIN of the SIM card
Text, max. 255 characters
Not set
WAN_PUK
PUK of the SIM card
Text, max. 255 characters
Not set
WAN_RADIOACCESS
Selection of radio access technology:
0
WAN_RECONNECT
MAXTIMEOUT
Seconds
1800-4294967295
604800
WAN_RS485ENABLE
Activation of the RS-485 interface for WAN
0, 1
0
WAN_RSSITEST
0
WAN_STOPBITS
Stop bits for WAN communication
1, 2
1
WAN_USER
User name for dialling into the WAN
Text, max. 255 characters
Not set
WATCHDOG_IDLE
Watchdog timeout for the idle state (in s)
1-4294967295
120
WATCHDOG_PROCESS
Watchdog timeout in busy state (in s)
1-4294967295
900
WATCHDOG_READOUT
Watchdog timeout during readout (in s)
1-4294967295
4-fold readout cycle,
SS
WATCHDOG_SCAN
Watchdog timeout during the scan process (in s)
1-4294967295
43200000
communication in the system log
0: none,
1: XON/XOFF during transmission,
2: RTS/CTS,
8: XON/XOFF when receiving,
9: XON/XOFF during transmission and reception
endless)
ABSOLUTE
CHAP
2400, 4800, 9600, 19200,
38400, 57600, 115200,
TECHNOLOGY
older devices
0: none,
1: odd,
2: even,
3: mark,
4: space
0: Default,
1: GPRS only (HL85XX, HL76XX),
2: UMTS only (HL85XX, HL76XX),
3: First search GPRS then UMTS (HL85XX),
4: First search UMTS then GPRS (HL85XX),
5: LTE only (HL76XX),
6: First search UMTS then LTE (HL76XX),
7: First search LTE then UMTS (HL76XX),
8: First search GPRS then LTE (HL76XX),
9: First search LTE then GPRS (HL76XX)
Manufacturer code of the meter (wildcard 0xFFFF, if
not set)
Not set
NZR
meter
version
Version number of the meter
0xFF
0x01
meter
medium
Medium of the meter, see second column in table
Not set
Electricity
meter
primaryaddress
Primary address of the meter (M-Bus or S0)
0
0x03
meter
addressmode
Addressing mode
1: Primary
0
0
meter
readoutcycle
Specific readout cycle (in s)
0
900
meter
maxvaluecount
Limitation of the number of meter values
0
12
meter
encryptionkey
Key for secure communication, e.g.: AES for wM-Bus
Not set, 0
0x82 0xB0 0x55 0x11
0x67 0x45 0x23 0x01
meter
active
Activates the meter for logging or for WAN
1
1
meter
rssi
RSSI value of the last transmission (wM-Bus)
0
123
meter
user
Application-specific text (see User label column in
Not set
OG-1-right
meter
dbid
unique database key of the meter, if the meter is
activated for WAN transmission
-
1
meter
value
Parent element for each register value in the meter
-
-
value
description
Description of the meter value, see second column
None
Energy
value
encodetype
Coding of the meter value
NODATA
INT32
value
scale
Scaling factor of the meter value (scientific
notation)
1e0
1e-3
value
valuetype
Type of meter value:
instantaneous
instantaneous
*x denotes the report instance 1-10
Table 23: Parameters of chip.ini
10.4 Configuration file Device\_Handle.cfg
The file /app/device_handle.cfg stores the meter configuration. If this file is not present, it can be created via
the website in the Meter tab. wM-Bus meters detected during operation are accepted after a scan process
or by manually saving the configuration. Only the entries that deviate from the defined default value must
be saved (version entry excluded).
When changing the meter configuration, all files in the folder ext/Tmp must be deleted manually (if
present).
The file must be saved as UTF8-encoded XML file. The meter data (report) that have not yet been transmitted are discarded when the meter configu-
ration has been changed.
In order for manual changes to the file to be accepted by the device, it must be restarted. The de-
vice must be restarted via the website, not by a power reset (as this will not complete any memory
accesses that are still open).
The file can be transferred to another device via FTP, taking into account the connected meters.
The file is an XML file and has the following structure:
meter interface Interface of the meter: M-Bus, wM-Bus, DLDERS, S0 - M-Bus
leading
25 (wildcard 0xFF, if not set).
0: Secondary,
0x91 0xF5 0x1D 0x66
0xEF 0xCD 0xAB 0x89
transmission.
meter register Register assignment (e.g. Modbus) 0 250
the Meter tab)
value unit Unit of the meter value, see second column in table
Generic data, OBIS code of the register value (XX:X.X*X; X=0-255; see column OBIS-ID in Meter tab)
Not set
0x01 0x00 0x01 0x08
0x00 0xFF
value
rawdata
Raw data to the meter value with M-Bus and wM-
-
07 FB 0D 00 00 00 00
value
dif
Data information boxes for the meter value with M-
-
07
value
vif
Value information boxes for the meter value with
M-Bus and wM-Bus
-
FB 0D
value
active
Activates the meter value for logging or for WAN
1
1
value
register
Register assignment (e.g. Modbus)
0
250
value
user
Application-specific text (see User label column in
Not set
Room 2
Bus
Bus and wM-Bus
transmission.
the Meter tab)
00 00 00 00
Table 24: Structure device_handle.cfg
10.5 OpenVPN Client
In order to enable an encrypted remote access to the SonoCollect devices and thus create a comfortable
way of configuring and operating the devices remotely, an OpenVPN client has been implemented. The
configuration on the devices themselves, is very simple and intuitive.
Configuration of the device
Only a created client configuration file config.ovpn must be stored in the path app/vpn to use an OpenVPN.
Activation takes place via the selection field VPN in the
Note the correct file name config.ovpn.
When saving the configuration via the website, the OpenVPN client is started and the VPN connection is
established.
OpenVPN usually uses the UDP port 1194. This port must be enabled in a firewall.
General
tab (see section 4.2).
Please contact your administrator to deploy a client configuration file.
10.6 Preconfiguration of the meter list
Manual editing of the meter list for large installations with many meters is time-consuming.
Using the file app/meter-conf-import.csv this can also be automated. This file is used when scanning/listing
a meter to add meta information such as the
If the meter is already listed or configured in the
over. The meter must then first be removed from the list.
The file can be manually uploaded to the device via SFTP (see also section 3.4). However, it is also possible
to import via the
Service
tab (see section 4.10). The file must be packed as *.tar.gz file.
Encryption key or the User label.
Meter
tab, the data from the file will not be taken
To create a *.tar.gzarchive, the free, open source software 7zip can be used. The file meter-conf-im-
port.csv can be packed herewith without subdirectory first into a *.tar ball and afterwards into a *.gz
archive.
The following columns can be used in the CSV file:
Interface: Interface via which the meter is read out (MBUS, WMBUS).
Serial: 8-digit meter number
Encryptionkey: Meter key in hexadecimal byte notation (optional)
user label: User-specific text for the meter (optional)
Cycle: Readout interval to the meter (optional)
Here is an example:
Interface;Serial;Encryptionkey;user label;
By scripting we mean the extension of the functional scope of the standard device by customer-specific
functionalities on the basis of source codes which are executed or interpreted on the target system, i.e. the
device.
Compiled standard environments such as XSLTPROC or BASH are available as interpreters of the SonoCol-
lect devices. Scripts can run in these environments and perform various functions.
XSLT parser
XSLTPROC is an interpreter for applying XSLT stylesheets to XML documents.
More information can be found at: http://xmlsoft.org/XSLT/xsltproc.html
Extensible Stylesheet Language Transformation XSLT is a description language for transforming an XML
document into another document. This can be an XML document, a text document (e.g. CSV file or JSON
file) or even a binary file.
Source and target files are considered as logical trees in XSLT. The transformation rule describes which
nodes of the tree are processed and how the new content is derived from them. Conditional statements
and loops can also be used.
The use of XSLT on the SonoCollect devices is intended for the generation of user-specific data formats.
The device internally uses a proprietary XML format to provide the meter data. In order to generate the format that the user uses or prefers, an XSLT conversion rule is used. In this way, the standard available formats can be generated (see section 4.6) and additional user formats can be stored.
Only one user format is available for the standard operating modes (e.g. TCP or FTP) of the report
instance. If several different user-specific formats are required, other instances must be set to User
mode.
Possible applications are exemplary:
CSV file per meter
JSON data stream for IoT communication
Time display as readable ASCII string instead of UNIX timestamp
Fixed point notation in CSV file
Changed column arrangement in CSV file
Summary of several identical meter value types at one point in time in one line
The XSL files should be stored in app/report. The file app/report/report.xsl is used for a
which can be selected via the web front end.
Report format
User
Report script
In addition to the user, the application can also issue commands via the command line (see section 10.1.2).
It can be used on the SonoCollect devices to implement user-specific processes.
If the mode of a report instance is set to User, this function comes into play. Instead of the fixed programmed processes like TCP or FTP, the stored BASH script is now called. The command sequence contained therein is run through and then the script is terminated. In this way, third-party tools available for
Linux can also be used to transfer data or to implement functions that are independent of it.
Possible applications are exemplary:
MQTT for IoT communication
Connection to an InfluxDB
Request to server before sending data (conditional data sending)
Sending to different file servers, depending on the set user label
Threshold testing and alarming
The script files are stored as sh files in the
app/report
folder. The file name is composed of report_ and a
consecutive number from 1 upwards. Thus, up to 10 user-specific file names can be realized: report_1.sh, report_2.sh, ...
The following example sends user-specific data via MQTT, therefore XSLTPROC is called before the actual
MQTT call is made via mosquitto_pub (long lines are wrapped):
#!/bin/bash
exec 1> >(logger -t report) 2>&1
set -e
set -o pipefail
Like the data dispatch with the report scripts (see section 10.7.2), the system meter can also be extended
user-specifically with system meter scripts.
Here a BASH script is called at the readout time, which returns a meter value after completion. The return
must contain the following values separated by newline in this order:
Designation of the measured value, description column
Unit of the measured value, unit column
Value of the measured value, value column
Possible applications are exemplary:
Measure ping times for network quality monitoring
Display outdoor temperature via Web API access
The script files are stored as sh-file in the app/metersystem folder. The file name is composed of "value" and
a consecutive number from 1 upwards. Thus, additional 1-n measured values can be realized: value1.sh,
value2.sh, ...
The following example adds the ping time to the system meter at www.example.de:
#!/bin/bash
echo -ne "Ping\nms\n"
ping=$(ping -n -c 3 www.example.de 2> /dev/null)
if [ $? -eq 0 ]; then
echo $ping | awk -F '/' 'END {print $4'
else
echo -1
fi
10.8 Media types, measurement types and units
In the EN 13757-3 standard, media types, measurement types (measurement value descriptions) and units
and are predefined. This procedure is used in the SonoCollect devices to enable uniform data display.
The following table contains the predefined values of the medium:
The following table contains the predefined measurement types (descriptions for the measured value).
One's own text-based measurement types (indication by index 31) can also be configured according to the
meter interface.
Request of meter data, register layout, see tables in section 11.3
0x05
Write Single Coil
Currently without function
0x06
Write Single Register
Currently without function
0x10
Write Multiple Register
Currently without function
0x0F
Force Multiple Coil
Currently without function
0x2B
Read Device Identification
Request of device information with MEI = 0x0E
Object ID
Name
Data type
Example
Type
0x00
VendorName
String
Danfoss A/S
Basic
0x01
ProductCode
String
1036
Basic
0x02
MajorMinorRevision
String
001
Basic
0x03
VendorUrl
String
www.danfoss.com
Regular
0x05
ModelName
String
Standard
Regular
0x06
UserApplicationName
String
Modbus TCP Gateway
Regular
11 Access to meter data via Modbus TCP
11.1 General information
The Modbus protocol was originally developed by the Modicon company (now Schneider Electric) for data
traffic with their controllers. Data were transmitted in the form of 16 bit registers (integer format) or as status information in the form of data bytes. Over the course of time, the protocol has been continually expanded. Modbus TCP is such a type.
Modbus TCP is part of the standard IEC 61158
A specification can be found at: http://www.modbus.org
The Modbus protocol is a single-master protocol. This master controls the entire transmission and monitors any timeouts that may occur (no response from the addressed device). The connected devices may
only send telegrams upon request by the master.
The SonoCollect devices are if, option available, a Modbus TCP server and therefore a Modbus TCP slave.
The Modbus communication requires the establishment of a TCP connection between a client (e.g.: PC or
Server
controller) and the server (this device). The TCP port reserved for Modbus from the
communication. This is configured to 502 by default (see section
4.6).
If there is a firewall between server and client, it must be ensured that the configured TCP port is
enabled.
The SonoCollect devices allow up to 5 simultaneous Modbus TCP connections in the standard configuration. This means, for example, that in addition to a classic PLC, you can also connect a building control system and a Modbus-capable display to the device without the queries of these Modbus clients influencing
each other.
The configuration parameter MODBUS_MAXCONNECTIONS (app/chip.ini, see chapter 8.4.1) determines the
maximum number of simultaneous Modbus queries. If this limit is exceeded, the oldest existing Modbus
TCP connection is disconnected by the gateway and the newly requested connection is allowed.
The device supports up to five simultaneous Modbus TCP connections in the standard configura-
tion.
tab is used for
11.2 Function codes and addressing
The following function codes are supported by the SonoCollect devices:
Table 28: Function codes for Modbus TCP or Modbus UDP
The function codes marked "without function" are answered with ILLEGAL DATA ADDRESS (0x02), all others
not listed with the error message ILLEGAL FUNCTION (0x01).
If the function code 0x2B with MEI = 0x03 is used, the device returns an identification packet. The values
0x01 and 0x02 are supported as Device ID code, which allows the simple (basic device identification) and the
standard (regular device identification) data to be called. The following data can be called via the device
identification:
Current Unix timestamp of the system time of the device. For this purpose,
6
Reserved
Reserved
7
Type field / Reserved
16 bits
The type field (value=1 for device entry) is transmitted in the high-order
byte. The least significant byte is reserved.
8-9
Reserved
Reserved
*Corresponds to the configured Device name in the General tab
Table 29: Device identification
Different stations on the bus can be addressed in the Modbus via a slave address. Addressing is done directly in the Modbus TCP via the IP address of the device. Therefore, the slave address remains usually unused. It is therefore recommended to use 0xFF (255) for Modbus TCP.
The SonoCollect devices do not check the slave address in the standard configuration, but always
respond if the IP address matches.
The meter data of the connected meters are not logically separated In the standard implementa-
tion of the Modbus server from each other and can be called across the board using a Modbus
query.
11.3 Data display
The data arrangement in the Modbus registers corresponds to the usual structure at Danfoss A/S. Addressing starts with 0 and uses the big endian display, therefore in the 16-bit registers the higher byte is sent
first, the lower then afterwards (this is also called most significant byte first or MSB).
Example: Value: 0x1234 → is sent: first 0x12, then 0x34
Numbers and data ranges that exceed 16 bits are represented in a similar manner. Again, the most signifi-
cant 16-bit register is sent first, so it is at the lowest register address (this is also referred to as most signifi-cant word first or MSW).
Example: Value: 0x12345678 → is sent: first 0x12, then 0x34, 0x56 and 0x78
The devices use 10 Modbus registers for each entry in the meter list to display meta information such as
readout time, unit and readout status. This results in the following Modbus register specification with a
fixed grid of 10 Modbus registers each.
The register addresses are counted starting from the value 0. For data types that span more than one register, the higher order data word is encoded at the
lower address.
The Modbus registers are read out via the function code 0x03 (Read holding register) (see section
11.2).
In the Modbus protocol, the data are transmitted as integers or floating values. Other data formats,
which are specified for the M-Bus (e.g.: BCD), are already converted internally into integer values
before transmission.
The 10 Modbus registers starting at address 0 are status registers of the device itself and are defined according to the following table:
3 Version 16 bits Software version of the device (integer value)
the clock time in the device must be set correctly (manually or via SNTP).
Table 30: Modbus register for the data set of the device
These first 10 Modbus registers are now followed by entries for meters and entries for meter values in accordance with the hierarchy in the meter list. An entry for meters is followed by associated entries for meter values, before a new entry for the next meter follows, and so on.
The 10 Modbus registers of a meter entry are defined according to the following table, where the offset
must be added to the configured Modbus address in the
The serial number is encoded in hexadecimal. Unlike M-Bus or wM-Bus, this is
2
Manufacturer
16 bits
The encoding of the manufacturer identification as three ASCII characters is
transferred value corresponds to the index.
4-5
Time stamp
32 bits
Unix time stamp at the time of the last meter reading. For this purpose, the
6
Reserved
Reserved
7
Type field / Reserved
16 bits
The type field (value=2 for meter entry) is transmitted in the high-order byte.
8
Flags
16 bits
Bit 0: Value 1: Meter not read, value 0: Meter correctly read
9
Reserved
Reserved
Offset
Designation
Data width
Description / Comment
0-3
Meter value
64 bits
Signed, integer meter value (unscaled)
6
Scaling factor
16 bits
Signed scaling factor to base 10
7
Type field / Unit
16 bits
The type field (value=0 for meter value entry) is transmitted in the high-order
Table 27. The transferred value corresponds to the index.
8-9
Time stamp
32 bits
Unix time stamp provided by the meter. If the meter does not transmit any
Address
Value
Designation
Decoded value
Device entry
0
0x0002
Serial number
0x0002993A
1
0x993A
2
0x0001
Protocol version
1
3
0x006F
Version
Version = 0x006F = 111 ? v1.11
4
0x519C
Time stamp
0x519CC16D = 1369227629:
5
0xC16D
Wed, 22 May 2013 15:00:29 GMT+2
6
0x0000
Reserved
7
0x0100
Type field / Reserved
8
0x0000
Reserved
an integer and not BCD.
identification
3 Version / Medium 16 bits The meter version is encoded in the high-order byte and the medium ID in the
done via individual bit areas: Bits 10-14: First character, bits 5-9: Second
character and bits 0-4: Third character. The particular character results from the
individual meter values (significant bit at the highest position), counted
starting with the letter "A" with the value 1.
low-order byte of the register. The medium is assigned using Table 25. The
clock time in the device must be set correctly (manually or via SNTP).
The least significant byte is reserved.
Bit 1: Value 1: Not all meter values current, value 0: All meter values up to date
Bit 2-7: Reserved
Table 31: Modbus register for the data set of a meter
The 10 Modbus registers of a meter value entry are defined according to the following table, where the off-
Meter
set must be added to the configured Modbus address in the
4-5 Meter value 32 bits Floating point meter value (scaled to the unit in register 7), IEEE 754
byte. The unit is transmitted in the least significant byte. This is assigned using
time values, this time stamp is 0.
tab:
Table 32: Modbus register for the data set of a meter value
Floating point formats have a limited resolution. It may result in slight deviations between the rep-
resented value and the exact number.
0x449a522b = 1234.5677490234375 instead of 1234.5678
The following figure shows an example configuration of the Modbus addresses via the web interface:
Figure 46 Configured Modbus registers on the website
The following data is transmitted to the Modbus master in this example:
Version of the communication protocol of the device
2
3
0x0084
Version of the software of the device
0x84 = 132: Version 1.32
4
0x5CE5
Time stamp of the device, upper word
0x5CE55EAC = 1559054252:
6
0x0000
Empty field
7
0x0100
Type field of the register set in the upper byte
0x01: Entry of the device type
8
0x0000
Empty field
9
0x0000
Empty field
10
0x00BC
Serial number of the meter, upper word
0xBC614E = 12345678
1st character: _011.00__.____.____’ → 0x0C = 12 → L
2nd character: ‘____.__10.101_.____’ → 0x15 = 21 → U
3rd character: ‘____.____.___0.0111’ → 0x07 = 7 → G
Medium = 4 = Heat (outlet)
17 0x0200 Type field / Reserved
21 0x0000 Resulting meter value: 267 * 10³ Wh
Type = 2 → meter entry
Type = 0 → Meter value entry
Table 33: Example data for Modbus
11.4 Configuration via web front end
The Modbus function is activated and configured via the
section
4.6. The settings are explained in detail below.
Modbus mode and Modbus port
The Modbus function can be activated with the aid of the parameter Modbus mode and set to Modbus TCP
or Modbus UDP.
Modbus TCP is the most widespread and common Modbus variant based on IP and uses TCP for communication. The use of UDP at Modbus UDP is uncommon, but is available as an option.
The port specified in the parameter Modbus port is used for both IP-based protocols. This is 502 by default.
If the parameter Modbus port is set to a value that is used by other services (e.g.: HTTP: port 80),
these services may block each other and access to the device is restricted.
Server
tab. The parameters are described in the
Modbus test
Depending on the Modbus implementation, data arrangement and addressing may differ between the
Modbus nodes. The transmission of static test data can be activated with the parameter Modbus test in the
Server
tab
then provided via Modbus according to the register assignment from chapter 6.3.4:
tab to check the correct data transmission parameters, (see chapter: 4.5). The following data is
68:91:D0:80:0D:C1
Wed, 22 May 2019 16:37:32 GMT+2
Classified as Business
11 0x614E Serial number of the meter, lower word
12
0x0443
Manufacturer identification of the meter (see chapter 6.3.4)
0x0443: ABC
13
0x0102
Version (upper byte) and medium (lower byte) of the meter
0x01: Version = 1,
14
0x5CE5
Time stamp of the meter, upper word
0x5CE55EAC = 1559054252:
15
0x5EAC
Time stamp of the meter, lower word
16
0x0000
Empty field
17
0x0200
Type field of the register set in the upper byte
0x02: Entry of the meter type
19
0x0000
Empty field
20
0x0000
Meter value (integer), highest word
0xBC614E = 12345678:
21
0x0000
Meter value (integer)
22
0x00BC
Meter value (integer)
23
0x614E
Meter value (integer), lowest word
25
0x522B
Meter value (floating point), lower word
26
0xFFFC
Scaling factor (exponent to base 10)
0xFFFC = -4: Factor = 10-4
27
0x0005
Type field of the register set in the upper byte and unit in the
0x00: Entry of the type meter value
28
0x5CE5
Time stamp of the meter value, upper word
0x5CE55EAC = 1559054252: Wed, 22 May 2019
Order of
Mode
Bits in the byte
Bytes in word
Words
Byte 1
Byte 2
Byte 3
Byte 4
Abbreviated form
Standard
big endian
big endian
MSW
0x44
0x9A
0x52
0x2B
ABCD
big endian
little endian
MSW
0x9A
0x44
0x2B
0x52
BADC
Modbus swap
big endian
big endian
LSW
0x52
0x2B
0x44
0x9A
CDAB
big endian
little endian
LSW
0x2B
0x52
0x9A
0x44
DCBA
0x02: Medium = 2 (electricity)
Wed, 22 May 2019 16:37:32 GMT+2
18 0x0000 Flags in the lower byte 0x00: Meter correctly read and all values up to
24 0x449A Meter value (floating point), upper word 0x449A522B = 1234.5677490234375
lower byte (see Table 27)
29 0x5EAC Time stamp of the meter value, lower word
date
Resulting meter value:
12345678 * 10-4 = 1234.5678 Wh
(Rounding error at FLOAT32)
0x05: Unit = Wh
16:37:32 GMT+2
Table 34: Test data for Modbus TCP or Modbus UDP
So, the above values should be reproduced exactly(!) in the target system. If not, the addressing type and
byte order probably do not match.
Modbus swap
The Modbus uses the data display big endian for bytes and words (individual registers) and addressing is
started at 0. Depending on the manufacturer and implementation, the address count and the arrangement
of data may differ between nodes for data types larger than 16 bits.
While the two types of addressing from 0 or from 1 can be corrected relatively easily by an additive offset,
the byte order is somewhat more complex.
Since the meter values are transmitted as floating point values (FLOAT32), the possible arrangements are
shown as examples. The FLOAT32 value is displayed in 32 bits and thus 4 bytes. These 4 bytes are stored in
two Modbus registers. Each of the bytes follows the big endian notation, but the byte order is not always
consistent.
-4
For the example, a meter value from the test data of 12345678 * 10
This value is represented by the FLOAT32 number 0x449A522B.
= 1234.5678 Wh is used (see Table 34).
Table 35: Data sequence with Modbus in the example
The bits and bytes in the register are always displayed in the format big endian according to the Modbus
standard for SonoCollect devices. The registers themselves are displayed either as most significant word
first (MSW) when Modbus swap is not active (default mode) or as least significant word first (LSW) when
Modbus swap is active.
Modbus float only
In most applications, only the pure measured value is used for further processing. Here, the floating point
representation of the measured values via Modbus is particularly suitable.
By omitting the meta information, the data display via Modbus can be more compact in order to save storage space or communication effort. By setting the parameter Modbus float only in the
bus address space is consolidated and only the serial number of the meter as integer and the floating point
values of the meter value entries are transmitted. This reduces the grid to 2 Modbus registers. The device
entry is then not available.
The meter entry only contains the serial number of the meter and is formatted as follows:
0-1 Serial number 32 bits
Table 36: Meter entry with reduced Modbus register layout
The serial number is encoded in hexadecimal. Unlike M-Bus or wM-Bus, this is an
integer and not BCD.
The meter value entry only includes the scaled floating point value, which is calculated from the integer
values of the meter, if the meter does not provide a floating point value. The meter value is formatted as
follows:
0-1 Meter value 32 bits Floating point meter value (scaled), IEEE 754
Table 37: Meter value entry with reduced Modbus register layout
Modbus multi slave
Depending on the use and further processing of the data, it may be useful to logically separate meter data
from different meters.
When setting the parameter Modbus multi slave in the
range in the Modbus. Each M-Bus slave in the meter list is thus managed as a separate virtual Modbus slave
with its own Modbus address. The slave address of the respective meter is then displayed in the column
Meter
Register in the
tab at the meter entry and can be adjusted there (see section 4.3). The meter value en-
tries show the corresponding Modbus register addresses within this virtual Modbus slave.
If there are meters in the meter list, the addresses must be re-assigned after activating or deactivat-
ing the Multi-Slave functionality.
Multiple selection by holding down SHIFTor CTRL is possible within the meter list.
Server
tab, each of the meters gets its own address
The reset or reallocation of the slave addresses and Modbus register addresses are possible, while marking
all meters with the help of the functions
Allocate and Deallocate from the context menu.
This allows the dedicated call of only one meter at a time. The register meter then starts anew at each meter. This enables the creation of macros and other automation approaches when programming the Modbus client if the same meter type is used several times.
Since the slave address can only accept values 1-247, no more than 247 meters can be addressed
logically.
The slave address 0 is a broadcast address.The slave address 255 addresses the device itself. Per slave address the register layout follows the conventions according to section 11.3 or section
11.4.4.
11.5 Instructions for use
How often is the data updated?
The meter data is read out independently of the Modbus requests. The meter data is updated with each
automatic or manual reading of a meter and is then currently available via Modbus. You can set the required cycle time in the
Meter
cycle in the
tab in the column Cycle .
Configuration
How can you detect if the meter is read or the value is current?
tab for all meters or also provide individual meters with an individual
For monitoring applications such as in automation technology (e.g.: SCADA system, PLC), it is often decisive which quality a value has. It is therefore recommended to check whether a meter could be read at all
and whether the meter value is also current.
The register set of the meter entry also contains, among other things, the readout time stamp and a flag
register that provides information about the readout status.
If the flag register has the value 0 the last readout was complete and therefore the values of this meter are
current. An explanation of the values can be found in Table 31. The time stamp can also be used to assess
the timeliness and provides information on how old the meter values are (also in the event of an error).
Which data type must be used?
The register set of the meter value entry contains both the unscaled meter value as INT64 value in connection with a scaling factor and the scaled value as FLOAT32 value.
When it comes to exact billing/settlement, the INT64 value is to be preferred, since this can be processed
further without loss of accuracy. However, not all Modbus clients are capable of processing 64-bit data. It
should also be noted that the scaling factor must still be multiplied. The INT64 value is therefore to be regarded as a fixed point value.
It cannot be excluded that the scaling changes during the runtime, because it is determined and
transmitted by the meter.
For monitoring applications such as in automation technology (e.g. SCADA system, PLC), the FLOAT32
value is more suitable. Subsequent scaling is thus not necessary and the accuracy of about 7 digits is sufficiently good in most cases.
What is the unit of value?
The register set of the meter value entry contains, among other things, the unit and the scaling of the
value. An explanation can be found in Table 32.
How many Modbus masters can call data simultaneously?
The SonoCollect devices allow up to 5 simultaneous Modbus TCP connections in the standard configuration.
How can the data be automatically assigned?
Each register set, i.e. device entry, meter entry and meter value entry, contains a type field (see Table 30,
Table 31 and Table 32). This type field can be used to automatically identify which entry this is.
If the register addresses in the
arranged logically one after the other in the Modbus data area:
Device entry
- Meter entry 1
Meter value entry 1
Meter value entry 2
Meter value entry x
Meter
tab are assigned automatically (see section 4.3), then the values are
Meter value entry x+y+..+1
Meter value entry x+y+..+2
.
.
Meter value entry x+y+..+z
This allows the complete Modbus data set to be run through iteratively in a 10 register grid and the hierarchy and assignment to be recorded automatically. When using the contents of the respective entry, you
Meter
thus obtain an image of the meter list from the
tab.
11.6 Specific troubleshooting
Why does the value in the Modbus differ from the value on the website?
Value deviations can have various causes. A list is provided to explain the most common causes of errors.
If the web page or the
current values. In this case reload the
If you compare the information on the web page with a FLOAT32display, there may be small devia-
tions from the 7th digit. These are accuracy errors due to the format.
Check the use of the correct data type, the meter values are available as INT64 plus scaling and
FLOAT32.
Check the data arrangement, specifically the Word order on MSW or LSW (see section 11.4.3).
Check the register address. Pay special attention to the count based on 0 or 0. Also note the addi-
tive offsets in the respective register set (e.g. to use the FLOAT32value).
In case of integer display, check whether your Modbus master also supports 64 bit wide data types.
In case of floating point display, check whether your Modbus master also supports FLOAT32values.
Fixed point numbers are not supported.
Use the test data to check various settings (see section 11.4.2).
If errors could not be rectified, please contact your local Danfoss support.
Meter
tab has been open for some time, it may no longer display the most
Meter
tab using the Reload button.
Why does the device/the Modbus server not respond?
Connection problems with Modbus TCP or Modbus UDP can have various causes. A list is provided to explain the most common causes of errors.
Check your IP settings. Are Modbus client and Modbus server in the same IP address range or sub-
net? If not, is the gateway and route set correctly? A ping test
Check whether Modbus is activated on the device in the
Check that the port on the master and client match (usually 502). Also check if another service on
the device is mistakenly blocking the port.
Check whether a firewall is blocking the communication.
Check if the correct slave address for Modbus is used.
If errors could not be rectified, please contact your local Danfoss support.
BACnet (Building Automation and Control Networks) is a network protocol for building automation. It is
standardized by ASHRAE, ANSI and as ISO 16484-5.
This device is a BACnet server.
A specification can be found at: http://de.wikipedia.org/wiki/BACnet
BACnet communication requires the establishment of a UDP connection between a client (e.g.: PC, control-
Server
ler or BMS) and the server (this device). The UDP port reserved for BACnet from the
communication. This is configured to 47808 by default (see section
4.6).
If there is a firewall between the server and the client, ensure that the configured UDP port and the
broadcast transmission are enabled.
Implemented services
The following BACnet services are supported by the device:
tab is used for
Table 38: Implemented BACnet services
Supported BACnet Interoperability Building Blocks (Annex K)
12.2 Configuration via web front end
The BACnet function is activated and configured via the
section
4.6. The settings are explained in detail below.
BACnet active
The BACnet IP function can be activated via the parameter BACnet active. BACnet IP is a widely used and
common BACnet variant based on IP and uses UDP for communication.
BACnet config network, BACnet IP, BACnet netmask und BACnet broadcast
The device supports the activation of a second, virtual network interface for the BACnet service. Thus, the
device can be integrated into two logical networks via one physical network connection.
This function is activated via the parameter BACnet config network.
The second, virtual network interface is set up via the parameters BACnet IP, BACnet netmask and BACnet
broadcast.
The parameters BACnet IP and BACnet netmask are independent of the default settings in
tab.
BACnet BBMD
Server
tab. The parameters are described in the
General
Various messages are sent to the broadcast MAC address (FF:FF:FF:FF:FF:FF) on the local network with the
aid of BACnet IP. All BACnet devices in the local network receive the message and respond accordingly.
However, routers that switch to other subnets do not forward these messages. The BACnet Broadcast Management Device (BBMD) was introduced to solve this problem. The BBMD forwards IP broadcast messages
to other subnets using a Broadcast Distribution Table (BDT).