Poseidon network communication protocols
Poseidon connects temperature, humidity and other sensors to the Ethernet network. In following text, you will learn closely about individual communication interfaces, that can be used for communication with Poseidon. Here you will also find some links to interesting SW utility programs.
Request/response type of communication
Request-response protocols are designed for periodical logging of values from all sensors . Poseidon is in TCP Server mode and waiting for request from supervising application.
Temperature and sensors' states are displayed on a simple WWW page which is first loaded when accessing Poseidon using web browser. The page is reloaded every 5 to 30 seconds (see the Poseidon manual).
If some variable reaches the value that is set as ALARM value, this binary input or a thermometer is colored red.
Access to this WWW page is not restricted, it only writes values and there is also nothing to modify. The access can be restricted by IP address filtering.
Notice: On the other hand for access to the Flash Setup user name and password can be demanded. You can find this option in "General
Setup" bookmark in FLASH Setup. In case you forget your password new configuration of the device to "Set to Default" over RS-232 Setup is necessary
The values, monitored by measuring sensors are displayed in the defined .XML page (for example values.xml) and they can be read easily from XML tags by any application. It represents the most efficient way of retrieving data for Machine-to-Machine TCP/IP, because values from all sensors are stored in one file. XML entry is comprehensible for a man as well, process independent on SW platform and information can be retrieved even without a special software.
Note: We recommend using XML as the input interface for your SW applications.
Example of XML record for a thermal sensor:
Notice: Majority of the Poseidon models contains two XML files which differ in range of commands. The smaller file (typically values.xml) is used for print-out of connected sensors state. The second file (typically setup.xml) contains full device configuration data and you can dump sensor values, names of sensors, their alarm state configuration and others using your SW application. If the setting of Poseidon allows it, you can change some parameters directly in this file.
The Modbus is a communication protocol developed for measuring devices communicating over RS-485 or RS-232. The Modbus protocol allows sharing the variables' memory area over one of the physical interface, from measuring values for instance. Modbus/TCP represents the extension of this protocol for Ethernet communication.
Easy implementation into visualization systems for industrial professions is advantageous.Mapping the variables of the Modbus/TCP protocol
Schedule of individual parameters mapping can be found in the Poseidon manual.
SNMP (Simple Network Management Protocol) is suitable for primary system information exchange using short packets sent via UDP/IP.
Individual variables are organized and described in so-called MIB (Management Information Base) table, which can be used for any device. The table is distributed as a separate .mib file that can be downloaded to Poseidon from our web pages or found on the supplied CD.
SNMP is an asynchronous protocol based on the client/server model (here SNMP Client/SNMP Agent). This means that the supervisor (SNMP Client) queries Poseidon for the state of the individual values in MIB held in the Poseidon and SNMP Agent, implemented in Poseidon, 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 queries and responses. 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. „.22.214.171.124.4.1.217126.96.36.199.1.2.3“ – state of binary input 3) for a specific value, you don’t need the MIB table.
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 Poseidon manual.
Event alarm type of communication
For unrepeated notice of beginning and end of alarm status, different type of protocols than for periodical logging is necessary. Poseidon reacts to events automatically and notice is sent to one or more recipients according to the configuration.
If sending of an Email is allowed as a reaction to Alarm, Poseidon sends email directly or via supervising program. It is standard email, where recipient, subject and some parts of the message can be set.
Methods of sending the email
The trap consists of two SNMP traps for increasing of security and compatibility with other systems.
The alarm is state value so that after alarm termination (for example temperature goes back to the defined range) another two SNMP Traps are transmitted.
The trap system was developed to speed up delivery of information about changes of state because in the classic SNMP mode - question/answer, the period between each query can last from miliseconds up to several hours. For input contacts it is possible to define sending Alarm at Opening /Closing or the alarm can be disabled completely.
Detailed description and a summary of SNMP Traps can be found in the MIB table. The Poseidon manual contains enhanced description.
The alarm status notification can be realized with redirecting the Email to SMS. Because of possible failure, an independent GSM modem can be connected directly to the Poseidon unit or to the server which supervises with several Poseidon units.
Methods of SMS sending