6
identifier to indicate the reason that a notification is being sent – e.g. normal scheduled
update or an alarm detection event. A description of the protocol, format of messages,
and definition of event codes is available on request. Reference protocol document
“M09-PRTCLxxx”.
Some of the conditions on which notifications can be sent to the host server are listed
below:
Any monitored value exceeding a pre-defined or user-defined limit
A digital input changing state (on/off)
A digital output changing state
An analog input transitioning into a warning or alarm region
A scheduled update
System faults
SMS text commands from a user or host server
Power on or reset
1.3.1
Event Codes
Every message sent by the Messenger to a host-based server application is triggered by
an event. The event generates a message and the message contains an Event Code. The
Event Code uniquely identifies to the server the reason the message is being sent. Some
of the messages generated contain data, others serve as just notification that an event
has occurred.
1.3.2
Positive Acknowledgement
The Messenger can be configured to require a message acknowledgement from the host
server or to send once and forget. Message acknowledgement provides a verifiable
mechanism that a message was delivered, even during poor network conditions.
This parameter setting can be found in the CELL configuration.
1.3.3
Store and Forward Data Queue
There are several scenarios where a message may not be deliverable – network down,
host server down, poor connectivity to name a few. In the event that a message cannot
be delivered, it is stored in memory and is continually re-sent until properly
acknowledged. This store and forward memory is non-volatile and remains intact
during power off.
1.3.4
Real-Time Clock (RTC)
The RTC is used to time stamp data records and events. All messages sent to the host
server contain a time stamp to provide a chronology of data/events to the end user. The
RTC is battery backed to provide time keeping during power off. If the RTC is
