Monitoring

How MQTT works

MQTT works at the TCP layer in a way similar to SNMP Traps. There is no request-response communication; instead, data are sent ("published") and acknowledged. This reduces network load: individual “input” devices (sensors, detectors etc.) actively send only short TCP messages to a specified address (to a “broker”).

The advantage is that the input devices only transmit whenever they need to – in regular intervals, or according to other manufacturer-specified criteria (input closed or open, a threshold exceeded, a value increase or decrease, etc.).
Each message begins with a “Topic” that identifies, characterizes or groups the data.

Broker

A MQTT broker primarily acts as a server, that is, it receives and stores data. However, it can also act as a client (input device) towards other brokers and forward data to all subscribed subscribers. Such a subscriber can be, for example, a web service, an application, or another broker.

End devices send data to specified broker addresses, subscribers subscribe to brokers (just like customers sign up to receive e-mail newsletters). When a broker receives a message with a Topic corresponding to a subscription, the message is stored and distributed to the subscribers.

Topic

The MQTT topic is always a text string. The slash (/) sign can be used to form a tree structure. The topic can look like this:

Poseidon/1-Wire/temperature/856275
GTS/nagano/room1/temperature

A subscriber can subscribe to a particular topic, to a tree branch, or to the entire tree.
The following wildcard characters can be used in the topic: “#”, “+” and “$”.

• “+” stands for a whole level (Poseidon/+/temperature/856275).
• “#” stands for several levels (Poseidon/#);
  „#“ can only be used at the end of the string.
• Topics that begin with a “$” (dollar sign) are special – usually system topics.
• When a topic begins with “$”, it is a special topic (such as $SYS/broker/uptime).

The Topic also includes a QoS flag that specifies whether the message must be delivered. 0 means that successful delivery is not required; 1 allows duplicate delivery (if there is no acknowledgement, the message is resent); and 2 indicates that successful delivery is required but without any duplicity.

Payload

MQTT payload is the actual message content. The message content is normally assumed to be textual. However, the MQTT protocol is not restrictive and it is up to the broker and the subscribers to handle the payload. So, the payload can be binary, or can consist e.g. of images. Message size and type are specified by the broker. Many brokers prefer XML or JSON because these formats are less resource-consuming for larger volumes of data than many short “topic” messages.

Security

By default, the MQTT protocol communicates via TCP at port 1883. Security can be enhanced with SSL/TLS; in this case, the communication takes place at port 8883.

MQTT in Poseidon2 and Damocles2

Poseidon2 and Damocles2 units include a MQTT client implementation with optional SSL support.

• MQTT enable – Enables or disables MQTT support in Poseidon2 and Damocles2 devices.
• Server – IP address or domain name of the MQTT broker (server).
• Port – TCP port where the broker listens.
• Username – Username for authenticating TCP communication.
• Password – Password for authenticating TCP communication.
• Secure SSL mode – Enables/disables SSL mode.                           
• Client ID – ID of the client for use in MQTT. Users enter their IDs themselves in their profile. A user can use multiple IDs in order to filter messages in their account.                        
• Publish Period – Period for transmitting measured data. In this the interval (in seconds) Poseidon2 periodically connects to the broker to transmit the values.
• Topic Prefix Name – Topic prefix. The entire Topic is then formed by concatenating the prefix + the topic below.
• Publish – Selects information to be sent.
• User Topic umožňuje vytvoření uživatelského topicu (zprávy) obsahujícího data jaké požaduje uživatelská aplikace (JSON, XML, CSV a pod.). K tomu slouží makropříkazy uvedené níže
  • User Topic Enable – zapne zasílání uživatelské zprávy
  • Topic Name - Název zprávy
  • Topic Value – šablona uživatelské zprávy
  • Topic Test – náhled výsledné zprávy po přeložení maker

Macros for User topic:

%ID_IN_*% - Start of sequence of the inputs with firmly defined ID’s %ID_IN_END% - End of the fixed sequence of the inputs
%LOOP_IN% - Beginning of the sequence of the inputs that passes all ID’s %LOOP_IN_END% - End of the complete sequence of the inputs
%ID_OUT_*% - Start sequence of the outputs with firmly defined ID’s %ID_OUT_END% - End of fixed sequence of the outputs
%LOOP_OUT% - Start sequence outputs that passes all ID’s
%LOOP_OUT_END% - End of the complete sequence of the outputs
%ID_SENSOR_*% - Start sequence with sensors firmly defined ID’s %ID_SENSOR_END% - End of fixed sequence sensors
%LOOP_SENSOR% - Start sequence of sensors that passes all ID’s %LOOP_SENSOR_END% - End of the complete sequence of sensors
%VAL_ID% - Variable ID item
%VAL_NAME% variable name item
%VAL_VALUE% - variable values of the item
%VAL_STATE% - state variables of the item

Username and password are optional. For example, broker.mqttdashboard.com does not require them yet.

MQTT in practice

There are many public MQTT brokers where data can be sent and topics can be subscribed to. A list of the most well-known ones is available at: https://github.com/mqtt/mqtt.github.io/wiki/public_brokers

For our example, we have chosen broker.mqttdashboard.com. First, configure the Poseidon2 device:

Fill in the Server address, Port, Client ID (any value) and Topic Prefix Name (anything that can be used to distinguish the device). Using the Publish checkboxes, select the data to be published.
Then, Poseidon2 or Damocles2 needs to be restarted.  

Start the TT3 tool. It is essentially a MQTT Broker. It is available at: https://github.com/mqtt/mqtt.github.io/wiki/public_brokers

Set the broker (Server) address and Port (both values must be the same as in the Poseidon2), and a Client ID (must be different from the Poseidon Client ID). Then click Connect. The green status field in the lower right-hand corner will show Connected.

Then, in the Topic field, fil in the address that interests you. For example, “Poseidon2/#” means all messages whose Topic begins with Poseidon2/. Click Subscribe to start receiving messages.

The netGSM consists of a client and a server part. The server part is the Poseidon unit with the GSM modem. The clients are other units or software.

Devices currently suporting the netGSM (as of 1.11.2017)

Server (GSM modem needed)

• Poseidon 2250
• Poseidon 4001
• Poseidon 4002
• Poseidon2 4002
• Damocles2 2404
• HWg-SMS-GW/GW2/GW3

Client (no modem needed, SMS are sent through other unit)

• Poseidon 2250
• Poseidon 4001
• Poseidon 4002
• Poseidon 3266
• All products Poseidon2 family
• All products Damocles2 family
• All products IP WatchDog2
• HWg-WLD
• HWg-PWR3/12/25
• HWg-SH4
• HWg-DCD2
• Nagios Plugin (testing)
• PHP Script Example

netGSM supported functions

• SMS Send
• SMS Receive
• Ring a remote phone

Setup parameters descritpion for Poseidon2/Damocles2 in Server mode

Serial Port Settings

Port Function sets the serial port functionality (available only on models with a serial port and netGSM server support). Options:

• Disabled – The serial port is disabled – only with no modem connected and the device working as a client
• GSM modem – the GSM modem is connected and the Poseidon unit works as a server for the netGSM

Remote SMS gateway

Allows to set the IP address, HTTP port and a path to the service. This routes the SMS send requests, RFID control etc. The Poseidon2, Damocles2 and HWg-SMS-GW3 units always use service.xml !

GSM SMS interface

This setups the SMS parameters

• GSM Function – Allows to set if the SMS are sent through a local modem (available only if the serial port is in the GSM modem mode)
• SMS+Ring when Alarm – allows to ring a phone number when sending an SMS
• RS-232 GSM module – GSM modem status
• Not Enabled – not active. This is shown when the RS-232 port settings are changed, but not saved
• Not Found – the Poseidon is set to use the local modem, but that cannot be found
• Waiting for modem – searching for the device
• Initializing – the modem is initializing
• Ready – the device is prepared for use
• SMS center Number – for information, the SMS center number read from the SIM card. If this is not available, SMS cannot be sent

GSM SMS recipient

This allows the user to set the SMS destination numbers. It is independent on the operation mode (local / remote modem)

Setup example1

Two Poseidon units were used:

• 192.168.2.23 Poseidon2 4002 with a GSM modem connected
• 192.168.1.67 Poseidon 3266 with no modem, using the Poseidon 4002 to send SMS

Poseidon2 4002 setup (with the GSM modem)

In the default status you first need to enable the GSM modem in the Serial port Settings and then set the GSM Function to Local. Deactivating the SOAP destination is optional, as well as the SMS+ Ring when Alarm function.

XML setup example

<SerialPort>
<E>1</E>
</SerialPort>
<SMS>
<Function>1</Function>
<Ring>0</Ring>
<Dest>1</Dest>
<Module>Ready</Module>
<CenterNmr>+420608005681</CenterNmr>
<Recp1>777232759</Recp1>
<Recp2 />
<State>13</State>
<Message>OK</Message>
</SMS>
<SOAP>
<Entry>
<Idx>1</Idx>
<E>0</E>
<Server>192.168.1.36</Server>
<Port>80</Port>
<Route>service.xml</Route>
</Entry>
</SOAP>

Poseidon 3266 setup

In the default setting you just need to set the remote IP of the Poseidon and the SMS phone numbers. The SMS+ Ring when Alarm is optional.

XML setup example

<SerialPort>
<E>0</E>
</SerialPort>
<SMS>
<Function>0</Function>
<Ring>0</Ring>
<Dest>1</Dest>
<Module>Ready</Module>
<CenterNmr />
<Recp1>777232759</Recp1>
<Recp2 />
<State>13</State>
<Message>OK</Message>
</SMS>
<SOAP>
<Entry>
<Idx>1</Idx>
<E>1</E>
<Server>192.168.2.23</Server>
<Port>80</Port>
<Route>service.xml</Route>
</Entry>
</SOAP>

Setup example2

Poseidon2 4002 units used HWg-SMS-GW3:

• 192.168.100.169 HWg-SMS-GW3
• 192.168.100.223 Poseidon2 4002 without modem, using the HWg-SMS-GW3 to send SMS

HWg-SMS-GW3 setup

HWg-SMS-GW3 used security with username and password for netGSM (SOAP)

XML setup example

<Network>
<dhcp>1</dhcp>
<hostname>HWg-SMS-GW3</hostname>
<ip_address>192.168.100.169</ip_address>
<ip_mask>255.255.255.0</ip_mask>
<ip_gateway>192.168.100.1</ip_gateway>
<dns1>192.168.100.237</dns1>
<dns2>192.168.100.250</dns2>
<porthttp>80</porthttp>
<username/>
<password/>
<soap_username>1 1sX6k4D26A==</soap_username>
<soap_password>1 zd/uhpg=</soap_password>
</Network>

Poseidon2 4002 setup

In the default setting you just need to set the remote IP of the HWg-SMS-GW3 and the SMS phone numbers. The SMS+ Ring when Alarm is optional.

XML setup example

<SMS>
<Function>0</Function>
<Ring>1</Ring>
<Dest>1</Dest>
<Module>Not enabled</Module>
<CenterNmr/><Recp1>+420777232759</Recp1>
<Recp2/>
<Recp3/>
<Recp4/>
<Recp5/>
<State>0</State>
<Message/>
</SMS>
<SOAP>
<Entry>
<Idx>1</Idx>
<E>1</E>
<Server>192.168.100.169 </Server><Port>80</Port>
<Route>service.xml</Route>
<Name>testik</Name>
<Pswd>hwg</Pswd>
</Entry>
</SOAP>

Changes to temperature sensor accuracy over time

Typically 0.1°C/year

The drift increases with the measured temperature value. At 100°C, it may reach up to 0.3°C/year.

Changes to humidity sensor accuracy over time

Typically 1%RH/year

Causes of the drift

Unlike temperature sensors that can be protected from the environment with hermetic sealing, capacitive humidity sensors are exposed to the air or gas they are measuring, and thus to any potential contaminants. These contaminants can then increase the sensor response time or cause a temporary or permanent drift of its readings.

The resistance of RH sensors by different manufacturers to different contaminants varies considerably. It is therefore very important to consider the effects of various chemicals and their concentrations when choosing the most suitable sensor.

There are two common types of contaminants that can potentially affect the readings of a RH sensor.

1. Particulate contaminants

These are any particles suspended in the air that can be deposited on the RH sensor. Dust particles (depending on their type) may not have a significant effect on the sensor readings other than a potential increase in the sensor response time, depending on the buildup. Other particles, such as salts that can enter the environment from water sources, can have a significant effect on sensor readings in case of any significant buildup. In most cases, the RH sensor can be protected from such contaminants by selecting an appropriate filter to reduce the drift risk.

2. Vapor contaminants

Vapor contaminants are any volatile chemicals that have evaporated into the air. Some vapor contaminants are usually present in most environments in very small concentrations. The vapor concentration may increase in closed systems, such as environmental chambers. Once the vapor concentration reaches a certain level, the sensor readings may begin to drift. Unlike particulate contaminants, vapors cannot be easily filtered from the air. Other strategies, such as shorter calibration cycles, are often effective in reducing the risk of an out-of-tolerance condition.

While all capacitive RH sensors share a similar basic principle, the materials used and the general design will vary significantly. The long term stability and performance of a RH sensor is directly related to these differences in material and construction. Unfortunately, information regarding long term drift can be hard to find. Only a few datasheets list it. Sometimes it can be found in user manuals. But often it takes a call to the manufacturer to find out.

Recommendation

In a normal dust-free environment, HW group recommends to calibrate sensors once per year. In more demanding environments, the interval should be shortened to 0.5 years, or as needed.

How HTTPS works

HTTPS (Hypertext Transfer Protocol Secure) is a secure (encrypted) version of the HTTP communication protocol that is used to display WWW pages. Regular users encounter it when paying over the Internet, using electronic banking services, or in other situations where privacy is important.

HTTPS is, in essence, the standard HTTP protocol, with the communication and authentication wrapped inside SSL (Secure Sockets Layer) or TLS (Transport Layer Security – newer version of SSL) protocol.
The communication is based on certificates. There are several types of certificates that differ by the encryption method, key length, etc. From the user point of view, there are client certificates and intermediate certificates.

• Client certificates are issued by the so-called Certification Authorities (CA), who in turn issue their own intermediate certificates that prove their identity.
• Intermediate certificate is installed by the user to their web browser. During the communication, it is used to verify the authenticity of the other party's client certificate. If the connection is to be trusted, the intermediate certificate of the Certification Authority which has issued the other party's client certificate must be installed at the client side. In addition, the certificate must be installed as trusted.

In other words, trusted Certification Authorities are those that have their certificates installed in the „Trusted Certification Authorities“ section. Some certificates of trusted Certification Authorities are already preinstalled in Windows (Thawte, Symantec/VeriSign, GeoTrust, DigiCert and others).

The client certificate consists of a public key and a private key.

First, both parties, that is the client (user) and the server (website / Poseidon2) exchange their public keys in order to confirm their identity. For that to happen, the client party needs to have installed the root certificate of the Certification Aurhority that has issued the public key. 
From the obtained data, the client party prepares a basis for the encryption key and sends it to the server. The server decrypts the message with its private key and both parties calculate the resulting shared encryption key.  As soon the encryption key is mutually confirmed, the secure connection is established.

Open the WWW configuration interface of the Poseidon unit and switch to the Security tab:

Upload the public key (SSLCertificateFile) and the private key (SSLCertificateKeyFile) to the Poseidon2 unit.
After uploading, press Apply Changes

Make sure that the State of the key (SSLCertificateKeyFile) is Valid.

Reload the Poseidon2 web interface over HTTPS:

Generating certificates

Generate the self-signed SSL key and certificate in Poseidon

Poseidon is able to generate a private SSL key and own a certificate for closed networks or testing purposes. The generated certificate is self-signed and will be displayed as untrustworthy. Generated data will replace SSLCertificateFile and SSLCertificateKeyFile. Generating a key may take up to 10 minutes.

For generate certificat please push Generate  SSL key and certificate button:

A warning window is displayed during generating and elapsed time is displayed:

After the process is complete, you are prompted to restart the device:

After the restart, the certificates are already installed and after you approve the untrusted certificate, you can see the HTTPS interface (see Displaying a WWW page with a self-signed certificate chapter):

Generate the SSL key and certificate with OpenSSL

If you don't have certificates from a Certification Authority, you can generate them yourself.

The best tool to generate self-signed certificates is OpenSSL, an open-source implementation of the SSL and TLS protocols. It is available for download at https://www.openssl.org/.
After download and installation, the program is controlled via the command line – see below.

Public and private keys are generated with this command:

openssl req -new -x509 -days 3650 -nodes -newkey rsa:2048 -keyout C:\cert\server-key.key -out C:\cert\server-cert.crt

The days parameter determines the certificate validity period. The path to store the certificate is also determined (keyout for the private key, out for the public one).

After entering the command, the output looks like this:

C:\OpenSSL-Win32\bin>openssl req -new -x509 -days 3650 -nodes -newkey rsa:2048 -keyout C:\cert\server-key.key -out C:\cert\server-cert.crt
Generating a 2048 bit RSA private key
..........................+++
.......................................+++
writing new private key to 'C:\cert\server-key.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:CZ
State or Province Name (full name) [Some-State]:Czech Republic
Locality Name (eg, city) []:Prague
Organization Name (eg, company) [Internet Widgits Pty Ltd]:HW group
Organizational Unit Name (eg, section) []:Support
Common Name (e.g. server FQDN or YOUR name) []:poseidon-test.hwg.cz
Email Address []:support [at] hwg [dot] cz
C:\OpenSSL-Win32\bin>

The program asks for additional information – organization name, address, e-mail, and also a Common Name (CN). This is the most important field: it needs to contain the name of the server for which the certificate is issued, such as www.HW-group.com.

Now we have created a self-signed certificate. If we use it, for example, for a WWW server, the browser will complain that the certificate is not trusted because there is no intermediate certificate of a Certification Authority in the user's PC. However, browsers allow you to view such pages anyway.

Displaying a WWW page with a self-signed certificate

Click to confirm access to an untrusted page:

How to avoid the warning in the future

In order not to display the warning about untrusted certificate in the future, it is necessary either to install the intermediate certificate of the Certification Authority on the PC or to add the device's certificate to the PC as a trusted root certification authority. Internet Explorer is used to do that.

First, mark the site as trusted. Open the device web page over HTTPS, confirm opening the page. Then, in the browser's Internet Options menu, go to the Security tab, switch to Trusted Sites, and click Sites to add the website to the list of trusted sites.

Now click the warning about a certificate problem in the address bar, display the certificate and install it:

The certificate needs to be stored in a specific folder. In our case, among trusted root certification authorities:

After the installation is finished, the key fingerprint is displayed.

In this way, you can easily use HTTPS to communicate with Poseidon2 devices.

Individual variables are organized and described in so-called MIB (Management Information Base) table, which can be used for any device. The MIB table is distributed as a separate .mib file that can be downloaded to Damocles from our main web pages or found on the supplied CD which is part of start set.

SNMP is an asynchronous protocol based on the client/server model (here SNMP Client/SNMP Agent). This means that the supervisor (SNMP Client) queries for the state of the individual values and SNMP Agent, implemented in the device, responds.

SNMP protocol support is provided in many languages intended for creating dynamic WWW pages (e.g. PHP, ASP, Java, Perl, Python and others). Thanks to existing modules it is possible to allow access to reading or writing the data, provided by peripheral device to the system (e.g. a Poseidon), over the SNMP protocol quite quickly.

In classic communication mode, the communication proceeds in terms of questions and answers. The variables are defined by a numeric string that is described in the MIB table that also defines the meanings of the individual variables, format and names. If you know the hierarchy (numeric string – e. g. „.1.3.6.1.4.1.21796.3.3.1.1.2.3“ – state of binary input 3) for a specific value, you don’t need the MIB table.

Basic terms:

• MIB table (Management Information Base) – .mib file is a text-based file, describing individual variables supported by the device. It contains variables' addresses, their name, description and numeric format.
• OID (Object Identificator) is an identifier of the variable in the variables’ chart. It is represented by a long number, defining the variable’s position within the variable tree structure.

Some programs do not support MIB files for working with SNMP. With these programs, you must enter the OID strings manually. The strings can be found in the MIB table, but to save you looking there, we provide a summary of several variables, their OID in Damocles models manual.

OID descriptions of SNMP variables

The following table lists the variables, their OID addresses and values. The values apply to the specified Poseidon configuration shown in the HTML page screenshot on the right.

• Firmware: 1.9.6
• Dry contact states: 1=ON, 2=Off, 3=Off, no alarms

Whenever a value gets outside of the safe range for a sensor, the sensor enters the ALARM state. To notify about the alarm state, a SNMP trap is send to the specified IP address.

SNMP traps consist of two UDP packets sent by the SNMP Agent to the monitoring center (SNMP Client). The packet format is detailed in the MIB table. The first packet contains information about raising the ALARM, the second packet contains additional info about the sensor causing the alarm. When the alarm state ends (e.g. the temperature returns to the safe range), two more UDP packets are sent to inform about the termination of the alarm state.

This method was developed for faster notification of alarms because – in the normal request / response SNMP mode – the polling period may range from hundreds of milliseconds to minutes or even days.

For dry contacts, alarm can be sent upon opening/closing, or turned off completely.

Damocles2

SNMP traps sent by the Poseidon and Damocles

The MIB table contains a list as well as detailed descriptions of SNMP traps. An overview follows.

• Cold Start + Link Up Trap
  A pair of SNMP traps sent after the device starts up. If a sensor is in alarm upon startup, two more traps immediately follow.
   
• Alarm raised on a dry contact
  A pair of SNMP traps sent when an alarm is activated for a dry contact. The first trap contains alarm activation identification for maintaining the “alarm table”. The second trap contains, for instance, the name of the input in alarm.
• Alarm terminated on a dry contact
  A pair of SNMP traps sent when an alarm ends for a dry contact. This pair is always preceded by the traps related to the alarm activation. The first trap contains alarm activation identification for maintaining the “alarm table”. The second trap contains, for instance, the name of the input in alarm.
   
• Alarm activated due to sensor value
  A pair of SNMP traps sent when a sensor alarm is activated (temperature, humidity and others). Alarm is activated if the reading gets out of the defined range ± hysteresis. The first trap contains alarm activation identification for maintaining the “alarm table”. The second trap contains the assigned sensor name and the value causing the alarm. 
• Alarm activated due to sensor value
  A pair of SNMP traps sent when a sensor alarm is activated (temperature, humidity and others). Alarm ends when the reading returns back to the safe range ± hysteresis. The first trap contains alarm activation identification for maintaining the “alarm table”. The second trap contains the assigned sensor name and the value causing the alarm.

 

Recommended SW for SNMP experiments

GetIf

Getif is a utility for working with SNMP variables. It allows browsing the variables in the SNMP tree, reading the values, setting the values, and displaying details according to the supplied MIB.

Before using the utilities, we recommend to watch the demonstration Flash animation that is available at our website.

• License: Freeware
• Supported OS: Windows 2000, XP, 2003 Server
• Communication protocol: SNMP, contains MIB Manager
• Alarm response: No, SNMP trap reception not supported

iReasoning MIB Browser + Trap Receiver

Two freeware utilities for working with SNMP variables. They allow browsing the variables in the SNMP tree, reading the values, setting the values, and displaying details according to the MIB that can be loaded to the utility.

Before using the utilities, we recommend to watch the demonstration Flash animation that is available at our website.

4-20mA / 0-20mA analog current loop is the output interface of many industrial sensors (water level measurement, current transformers, gas concentration sensors, and so on). The output current is proportional to the measured value.

Connecting a sensor with a 4-20 mA output

• The analog sensor typically has no other power connection (it is powered from the minimum 4mA current).
• HW group converter provides power for the sensor (4mA / max 36V).

Is it possible to use “Sensor 0-20mA 1W-UNI”?

Yes, the HW group “0-20mA” converter can also be used, as long as an external current source is added:

Connecting a sensor with a 0-20 mA output

• Analog sensor (a current probe in this case) does not require external power.
• The HW group “Sensor 0-20mA 1W-UNI” converter does not provide power for the sensor.

How to connect multiple analog outputs

• Converters can be daisy-chained on the 1-Wire UNI bus.
• The number of converters is limited by the maximum number of sensors supported by the particular Poseidon2 or Ares unit.

The SNMP basics

The SNMP (Simple Network Management Protocol) is a way of quick and simple supervision of network elements and services.
                 
It is being increasingly used for monitoring the environment where these elements work. Mainly due to the possibility to monitor the temperature, humidity and other values in the same monitoring software as the other operating parameters of the system. The SNMP was originally designed to be extremely economical and to exist above the UDP protocol. This was to be sure the network management does not put a high load on the network itself. Today in times of gigabite and faster networks the priorities are a little bit different and thus the SNMP got a lot of extensions and improvements.

The SNMP is an asynchronous, transaction-oriented protocol based on the client/server model. The party that sends requests (SNMP client), can be a simple SNMP browser or a complex NMS (Network Management System). On the device side is there is an SNMP agent (SNMP server), that responds to the requests. SNMP traps are an exception and those are sent by agents asynchronously when an event occurs (power failure, fan failure, value excessed, new device discovered…). You need to define the address where the information is sent in advance. The UDP protocol is used to transmit data and it is defined where the applications of individual companies can connect. This is managed by IANA organization (Internet Assigned Numbers Authority - literally: Internet authority for assigning telephone numbers). SNMP can not only be used to read the current values, but also to write the operating values (configure devices).

The SNMP versions

The SNMP Protocol has been developed gradually. The first version (SNMPv1) provides basic SNMP functionality and it is very efficient. As networks were speeding up so was the need for a greater security. Simple authentication was added to SNMPv2 (security with username and password), which followed by adding encryption in the latest version of the protocol (SNMPv3)

In SNMPv1 only Community served for identification of the "authorized" agents. Although the name was user definable, usually only two values are used - "public" for reading and "private" for reading and writing.

The SNMPv2 improved in performance, security, privacy and communication management. The SNMPv2 standard is not much used and is replaced by SNMPv2c, which is compatible with SNMPv1 and has an extended set of commands and a higher efficiency. The SNMPv2u was also not very popular though it was the first attempt to establish SNMP security features.

SNMPv3 is an upcoming variant of the standard and it contains not only the user authentication, but also encrypted communications. For the security Username (similar to Community), Password for authorization (Authentisation password) and key (Privacy password) are used. During the authorization, the communication can be encrypted using MD5 or SHA, private communication can then be encrypted using DES or AES. Starting from SNMPv3 it becomes a full-fledged management protocol in the most demanding corporate networks. The main advantage is that the MIB stays the same and there is no need of any special arrangements during the transition to SNMPv3.

There is an unlimited number of users in the SNMPv3, which allows you to track and log the activity of individual operators. Each user has his combination of Username, Auth. and Privacy password along with the corresponding encryption, which together form a profile.

Using the SNMPv3

The Poseidon2 units now support SNMPv3 and up to 5 user profiles. Please see the images below for examples:

Poseidon2 4002 web interface with SNMP settings

Example of using the SNMPv3 with SNMPget:

C:\Users\volmr\Downloads\SnmpGet\SnmpGet.exe -r:192.168.2.71 -v:3 -sn:public -ap:MD5 -aw:idefix12345678790 -pp:DES -pw:idefix12345678790 -o:.1.3.6.1.2.1.1.3.0

Result:

Example of using SNMPv3 with MGSoft Mib Browser:

Configuration

The result of the Walk command

Frequently Asked Questions

• Can my Poseidon2 support SNMPv3?
  Yes, you must download latest FW and load it to your Poseidon2 device. This can be applied to all models Poseidon2.
   
• Can I load this FW into Poseidon 2250?
  No, Poseidon of first generation can not support SNMP v3.
   
• Are there any changes with structure of SNMP MIB because of support SNMPv3?
  In configuration if you choose SNMP version 1, everything remains compatible with current SNMP interface.

The Poseidon2 and Damocles2 works as a TCP Server at port 502 (Modbus standard). The Modbus/TCP communication takes place using the given addresses. For details, see http://www.modbus.org .

Caution: Modbus/TCP implementation support requires setting the " Slave ID " variable to number 2. Check the setting of this variable in case you are enable to establish a connection. (The actual name may differ in your software – it used to be an address to distinguish multiple devices on a RS-485 line in case of Modbus/RTU).

What you can find in this application note:

• We describe how to properly setup Modbus Poll program version 3.20
• You find out what is possible to read via Modbus/TCP protocol

Notice: Modbus Poll application version 3.20 in its unregistered version works only for 4 minutes after launch. It is necessary to restart the program after to run it again.

Mapping of variables for the Modbus/TCP protocol

Analog quantities
Address	I/O		Type		Functions		Units
100	int		4				Current number of installed (configured in Setup) sensors
101-10x	int		4		0,1°C		Current value of the sensor No. 1 through x, where x is the value at address 100. Units are configured in WEB Setup.
200	int		4		-		Current banknote counters
201 - 2xx	int		4		-		The current counter value, the first counter is at the address 201(H)-202(L), second on 203(H)-204(L) ….
201 - 2xx	int		16		-		Set the current counter value, the first counter is at the address 201(H)-202(L), second on 203(H)-204(L) ….
Digital values
Address	I/O		Type		Functions		Description
100 - 1xx	bit		2		0 - open, 1 - close		Current values of binary inputs
200 - 2xx	bit		1		0 - open, 1 - close		Reads the current value of the output
200 - 2xx	bit		5		0 - open, 1 - close		Sets the value of the output

Inputs registers

Outputs registers

Remote INPUTS

Poll Definition
Slave ID:		2
Function:		02 INPUT STATUS
Adress:		100
Length:		24
Scan Rate:		1000
Auto Read Enable:		Checked

Remote OUTPUTS

Poll Definition
Slave ID:	2
Function:	01 Coil Status
Adress:	200
Length:	4
Scan Rate:	1000
Auto Read Enable:	Checked

Sensors

Poll Definition
Slave ID:	2
Function:	04 INPUT REGISTER
Adress:	100
Length:	2
Scan Rate:	1000
Auto Read Enable:	Checked

The Poseidon2 and Damocles2 works as a TCP Server at port 502 (Modbus standard). The Modbus/TCP communication takes place using the given addresses. For details, see http://www.modbus.org .

Caution: Modbus/TCP implementation support requires setting the " Slave ID " variable to number 2. Check the setting of this variable in case you are enable to establish a connection. (The actual name may differ in your software – it used to be an address to distinguish multiple devices on a RS-485 line in case of Modbus/RTU).

Program Modbus Poll & Damocles MINI

Dry contact inputs - model MINI

Connect the Damocles MINI unit to ethernet and power supply. Launch Modbus Poll application (mbpoll.exe file). In setup menu select option Poll Definition (keyboard short cut F2).

Picture a - Input setting

Setting of inputs in Modbus Poll program (Picture a)

• Slave ID: 2
• Function: definition of running function 02 INPUT STATUS for monitoring of input states
• Address: definition of used variables that will be loaded (for addresses see figure bellow). Beginning at the address 100 - ending at the address 103
• Length: length of loaded variables
• Scan Rate: delay between two following loadings
• Auto Read Enable: to enable automatic reading of values
• Click OK button to confirm

 

Picture b - Network parameters setting

Addresses of inputs in terms of protocol are configured, now set up connection to device itself.

• In Connection menu select Connect (keyboard short cut F3)
• Select TCP/IP
• Set up device IP address and Port (standard is 502)
• Push OK button to confirm

Application is now connected to selected device and in periodic interval loads input values (see the picture c).

 

Picture c - Values loading

Picture d - Damocles MINI - WWW page

>> Damocles MINI
Download and application of Modbus Poll + examples

 

Binary outputs (Damocles MINI)

Open Poll Definition menu to control binary outputs.

Picture e - Output setting

• Slave ID: 2
• Function: definition of running function 01 COIL STATUS for monitoring of output states
• Address: defines the address of used variables that will be logged (for addresses see figure bellow). It begins at the address 200 - ending at the address 201
• Length: number of loaded variables
• Scan Rate: delay between two loadings
• Auto Read Enable: to enable automatic reloading
• Click OK button to confirm

To control binary inputs select option 05 in function menu: Write Single Coil (short cut F7).

Picture f - Output control

You can safe setting of Poll Definition to mbp file to simplify your work. Any time you need it simply load the saved setting.

 

Modbus Poll & Poseidon2 4002

Temperature sensor - model4002

Open Poll Definition in menu.

• Slave ID: 2
• Function: definition of running function 04 INPUT REGISTER for monitoring of output states
• Address: defines address of used variables that will be loaded (for address see figure above).
  • Andrea 100 - number of sensors
  • Addressed 101 - current value
• Length: number of logged values
• Scan Rate: delay between two readings
• Auto Read Enable: to enable automatic reloading
• Click OK button to confirm

Picture ch - Setting of temperature sensor

Two lines are displayed. The first line shows number of connected sensors and the second current temperature with an accuracy of 0.1° C. Save your setting to mbp file to simplify work with Poll Definition. In case you need it, simply load saved setting.

Industrial Bus (RS-485)

• Maximum cable length: 1000 m total
• Number of devices on the bus: Poseidon + up to 31 devices
• Power: 12V/120 mA supplied by the bus, can be boosted with an external adapter (through a S-Hub or a Spider unit).
• Cable type: UTP (2 or 3 pairs)

Topology 1: Basic

• The bus leads via a 4-wire connection from the Poseidon 1250 unit to two daisy-chained sensors, Temp-485 and HTemp-485. Two twisted pairs are used by the connection.
• A S-Hub unit is daisy-chain-connected via the RJ45 jack after the second sensor, using a 4-wire connection from the HTemp-485 sensor. The brown pair is used for power, the blue pair for data.
• Temp-485 and HTemp-485 sensors are connected to the S-Hub connectors 1 through 3 with 6-wire connections (brown pair for power, blue pair leads the bus to the device, green pair back from the device).
• Connector 4 of the first S-Hub unit is used to connect a Spider converter with a patch cable. The Spider unit is used to connect three Temp-1Wire 10m temperature sensors and one door contact (the contact is connected to the blue pair of the RJ45).
• A second S-Hub connects to the Spider unit output via a patch cable.
• Its connectors 1 through 3 are used to connect the Temp-485 and HTemp-485 sensors with 6-wire connections (brown pair for power, blue pair to the device, green pair back from the device).
• Connector 4 is used to connect a Temp-485 sensor with a 4-wire connection (brown pair for power, blue pair for the A/B signals of the bus).
• Termination is enabled at the Temp-485 sensor using the “TERM” jumper.

 

Topology 2: Connecting 10 sensors to IT Bus

Eight temperature sensors and two humidity sensors are connected via the IT Bus (RJ12) to a Poseidon 1250 unit. The 10 sensors are connected using two T-Box hubs and one T-Box2 unit.

• Bus used to connect the sensors: IT Bus

• Total bus length: 10m
• Maximum number of sensors: 10
• Sensors used:
  • 2x Humid-1Wire 1m
  • 8x Temp-1Wire 1m 
• Accessories used:
  • 2x T-Box
  • 1x T-Box2

Conclusion:

This solution is limited by the maximum IT Bus length. It is suitable for applications that use 1 to 10 sensors at one place (one location, 19” rack cabinet, etc.)..

Topology 3: Poseidon Spider – bus converter

The solution combines the properties of both buses. Two Spider units are far apart, connected via a Patch cable with RJ45 modular jacks. Both Spider units connect to four temperature or humidity sensors, each with a 10m cable. One Temp-485 sensor is located at the end of the chain and terminates the bus.

• One Temp-1Wire temperature sensor with a 10m cable is connected directly to the Poseidon unit to the RJ12 jack.
• Six temperature sensors and two humidity sensors are connected via the IT Bus (RJ12) to the Spider units. Each sensor is connected with a 10m cable.
• Two Spider units are connected to Poseidon 1250 with a standard RJ45 Patch cable using the Industrial Bus. Bus length is limited to 1000m.
• The Spider unit comprises 4 inputs for external sensors and supports one sensor per connector – for a maximum of 4 sensors.
• The Industrial Bus is terminated by connecting a Temp-485 sensor with termination enabled over a 4-wire connection. The Spiders have mutually different addresses and are set to the “middle” mode.

• Bus used to connect the sensors: IT bus, Industrial Bus
• Total bus length: 1000m + 9x 10m
• Maximum number of sensors: 40
• Sensors used:
  • 6x Temp-1Wire 10m
  • 2x Humid-1Wire 3m
  • 1x Temp-485
• Accessories used:
  • 2x Poseidon Spider
  • 2x RJ45 Patch cable 300m (RJ45-RJ45)
  • 1x RJ45 TP cable 300m (RJ45-4 pins, “LAST” wiring)

Conclusion:

This solution is not limited by the IT Bus length. The Spider units can be up to 1000m apart. The solution is suitable for large-scale applications with many sensors (e.g. server rooms).

 

Topology 4: Using the Industrial Bus – star topology

This solution demonstrates a star-like connection of sensors to the Industrial Bus using an S-Hub unit. The S-Hub is the central point that connects individual sensors. The maximum bus length decreases to 500m because the cable length of all sensors connected to the S-Hub must be counted twice. A Temp-485 sensor with termination is at the end of the bus.

• One Temp-1Wire temperature sensor with a 10m cable is connected directly to the Poseidon unit, to the RJ12 jack.
• The Industrial Bus connects to the S-Hub input via a RJ45 patch cable. At the same time, the cable powers the sensors as well as the S-Hub; extra power can be supplied by an external power adapter.
  • Sensors must be connected to the S-Hub in a sequence, starting from output No. 1. Outputs cannot be skipped. (For instance, connecting outputs 1,2,5,6 while leaving outputs 3 and 4 unconnected will not work.)
• First three temperature (Temp-485) and temperature/humidity (HTemp-485) sensors are connected in sequence to the first three outputs. An RJ45 / 6-wire cable, wired according to the “MIDDLE” version, is used to connect them.
• The Spider unit is connected with a Patch cord. The Spider connects four Temp-1Wire sensors at 4x 10m distances. The Spider unit is in the “MIDDLE” mode.
• The Industrial Bus is terminated at the Temp-485 sensor connected to the S-Hub at position No. 5. The connecting cable is wired according to the “LAST” version, termination is enabled at the sensor (Term=On).

Topology 5: Using the Industrial Bus – daisy chain

The solution demonstrates daisy-chain linked sensors on the Industrial Bus. Note the distances between sensors. The Spider unit connects four local temperature sensors. At the end of the bus, there is a Sens-UI voltage and current sensor with termination enabled.

• One Temp-1Wire temperature sensor with a 10m cable is connected directly to the Poseidon unit to the RJ12 jack.
• Two HTemp-485 temperature/humidity sensors are connected at the beginning of the bus, using a 4-wire cable connected to the terminals.
• The bus continues to the Temp-485 temperature sensor, still with 4 conductors.
• The Temp-485-Pt100-Cable uses a 4-wire connection as well. The temperature is measured by a Pt100 sensor mounted on a 2m silicon cable.
• The next Temp-485-Pt100-2xDIN converter, mounted on a DIN rail, uses a 4-wire connection. Two external Pt100 thermometers measure two temperature values.
• The following Temp-485-Pt100-Box sensor, designed for external environment, includes a probe for precise temperature measurement. 4-wire connection.
• The Spider unit is, on the contrary, connected via a RJ45 jack. The Spider connects four Temp-1Wire sensors located 4x 10m away.
• Please note the crossing of cables. It is necessary to respect the input and output designation of the RJ45 jacks. The Spider is in the “middle” mode.
• The Industrial Bus finally leads, via a 4-wire connection, to a Sens-UI sensor that measures external voltage and current.
• At this point, the bus is terminated by an external 120 Ohm resistor between the A and B pins.