DALI User Manual: Alarms

Introduction

Most of the DALI API involves the client initiating requests for the server. In some cases the client is repetitively querying the server to see if a condition has occured such as a change in a digital output or an analog input exceeding a set of tolerances. This polling puts a high strain on the server. It is better for the client to specify the conditions under which it wants to be notified and then wait for the server to initiate communication telling it when the condition has become true.

In other cases there is no active client software but the user wants to be notified via e-mail or later review a log of alarms to check the state of the application.

DALI Alarms implement this concept. Alarms should be used any time a client is monitoring the state of something over time just to see if an event will occur. Two types of events are supported.

Once the alarm has been registered, the server is constantly checking the condition associated with the alarm to see if it has become true. The server will automatically take action when the alarm becomes true.

Alarms end when a duration associated with them expires, a fatal error occurs, or the client notifies the server that it is no longer interested in the alarm.

Alarm Notification Types

Notification via DALI Protocol

For systems where client software is actively monitoring the alarm the notification can be delivered live via a kind of SOAP callback. In this case the client becomes a kind of server waiting to receive notification. For example, a GUI application could turn on an LED when the server notifies it that a digital input has changed.

In this case there must be an open network path for the server to connect to the waiting client. The client and server cannot be separated by an Internet firewall which would prevent such connections.

Notification via E-mail

The DALI server can send an e-mail to a specified e-mail address anytime an alarm occurs. The message will contain information such as the alarm parameters, the time the alarm occured, and the value which triggered the alarm. A mail server must be available and configured to allow the DALI server to relay e-mail.

Notification via Logfile

The DALI server can log the alarm information to disk for later review. The logfile will contain entries with the alarm parameters, the time the alarm occured, and the value which triggered the alarm.

DALI Alarm Functions

The following DALI protocol functions are related to alarms.

Each client language implements alarms differently. See the the sections of this manual on the client implementation you will use for more information on the exact calling parameters. Alarms are not implemented in Java due to the constraints of Java Applet security.

The Alarm Lifecycle

A GUI application wants to turn an LED on or off on its screen when a specific digital input bit changes state. The DALI C/C++ client is used. The following sequence illustrates what happens internally when alarms are used.

  1. The GUI application calls DALIDIOInOnChange()
  2. Internally the DALI C/C++ client connects over the network to the DALI server and calls the SOAP function AlarmDIOInOnChange()
  3. The client disconnects from the server
  4. The DALI server begins to monitor the specified digital bit
  5. The GUI application starts a thread which calls DALIWaitForAlarm().
  6. Internally the DALI C/C++ client starts a SOAP server which waits for the DALI server to connect with an alarm notification.
  7. When the state of the digital bit changes, the DALI server initiates a SOAP client connection to the SOAP service specified with the alarm which includes the IP address of the client.
  8. Internally the DALI C/C++ client accepts the connection from the DALI server and processes the alarm notification. The server disconnects.
  9. The GUI thread DALIWaitForAlarm() returns with the alarm information. The GUI turns the LED on or off based on this information.
  10. The GUI returns to waiting on DALIWaitForAlarm.
  11. Later the GUI is done and calls the DALI C/C++ function DALIUnregisterAlarm()
  12. Internally the DALI C/C++ client connects to the DALI server and calls the SOAP function UnregisterAlarm()
  13. The DALI server stops monitoring the digital bit
  14. The GUI application exits

Alarm Error Handling

If DALI protocol alarm notification is used, the DALI server may delete the alarm if it is unable to connect to the client to send alarm notification. The server will make a number of attempts to connect to the client over several minutes.

The alarm may also be removed if the alarm condition is invalid. For example if an invalid channel is specified or there is a hardware problem which is generating errors. The DALI server will send a special type of alarm notification which includes a status code which specifies the error.

Every DALI alarm includes a duration parameter which specifies its lifetype in seconds. When this much time has passed the alarm will be removed. The DALI server will send a special type of alarm notification which incldues a status code which specifies a timeout.

Pre-configuring Alarms

Introduction

The DALI server supports a file configuration system which allows alarm conditions to be pre-configured when the server starts. There is no need for a client to connect first to initiate these alarms. This system is similar to the board configuration system documented earlier in this manual. Each pre-configured alarm has a configuration file which is found in the alarm configuration directory. This file contains a set of key=value pairs which contain the alarm parameters.

Example File

If it exists, the alarms directory is searched for alarm configuration files. The alarms-examples contains example files which can be used as templates when creating your own pre-configured alarms.

Here is the contains of an example file which configures an A/D alarm.


actiontype=SOAP
actiontarget=http://192.168.1.5:8444/dali/soap
channeltype=AD
lowvalue=-32768
highvalue=-16000
range=10
gain=1
polarity=BIPOLAR
channel=0
period=1
postalarmpause=60
board=dmm32

Pre-Configured Alarm File Directives

Directive Required / Optional
actiontype Required
Sets the action to be taken when an alarm condition becomes true. Valid action types are: SOAP EMAIL LOG


Directive Required / Optional
actiontarget Optional
Required for actiontype SOAP and EMAIL. In the case of SOAP this is the service URL for connecting to the client. It will look like this: http://192.168.1.1:8444/dali/soap but with the correct IP address and port for the client. In the case of EMAIL this is the e-mail address to be notified.


Directive Required / Optional
actiontarget Optional
Required for actiontype SOAP and EMAIL. In the case of SOAP this is the service URL for connecting to the client. It will look like this: http://192.168.1.1:8444/dali/soap but with the correct IP address and port for the client. In the case of EMAIL this is the e-mail address to be notified.


Directive Required / Optional
channeltype Required
The type of channel to monitor. Must be one of: AD DA DIOIN DIOOUT


Directive Required / Optional
lowvalue Optional
Required for AD alarms. Set to the low value of the acceptable range of AD values.


Directive Required / Optional
highvalue Optional
Required for AD alarms. Set to the high value of the acceptable range of AD values.


Directive Required / Optional
range Optional
Required for AD alarms. Set to 10 for 10 volt AD range or 5 for 5 volt AD range.


Directive Required / Optional
gain Optional
Required for AD alarms. Set to 1, 2, 4, or 8. The DAQ multiplies analog input voltage by this factor.


Directive Required / Optional
polarity Optional
Required for AD alarms. Set to UNIPOLAR or BIPOLAR. Sets the analog input voltage polarity.


Directive Required / Optional
channel Required
Set to the channel number to monitor.


Directive Required / Optional
bit Optional
Required for DIOIN and DIOOUT alarms. Set to the bit 0 - 7 to monitor.


Directive Required / Optional
period Required
How often in seconds the server should check the condition. Set to 1 to check every second.


Directive Required / Optional
postalarmpause Required
How long to wait in seconds after an alarm notification before checking the alarm condition. Avoids sending the user too many notifications when an ongoing alarm state is occuring.


Directive Required / Optional
board Required
The name of the board to monitor.