SNMP – Interface description

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.