alarms

The alarms URI gets a list of web service alarm records.

Data alarms are managed as a set of records, with each record describing a specific alarm condition. Multiple alarm conditions can be applied to a single URI. For any sample, all alarm conditions are tested and matching alarm conditions are pushed into the event channel, relative to buffering controls and the existence of an event channel.

Not all URIs support alarms. If a URI does not support alarms, an attempt to create an alarm results in an HTTP error.

Note In the initial WVA release, only vehicle data URIs support alarms. The interface is defined so that other URIs can be added to alarms without changing the registration methods.

The alarms URI operates like a data store. Initially, the store is empty. The existence of a record in the store corresponds with an alarm condition registered with the system. The external user can query, add, change, and remove records at will. The records have names that are arbitrary to the system, which you supply through the request URI.

URI path

alarms

Supported request methods

GET

Queries the system for the list of alarm records. The returned record is a list of URIs corresponding to the “children” of alarms in the web services data tree.

Supported content types

HTML

The result URIs are turned into URLs relative to the device, and returned in an HTML list.

XML

The result URIs are each wrapped in element tags, and returned within an alarms block. For example:

<alarms>
        <element>alarms/short_name_1</element>
        <element>alarms/short_name_2</element>
        :
        <element>alarms/short_name_N</element>
</alarms>

JSON

The result URI strings are collected in an array assigned to an alarms field. For example:

{ “alarms” : [ “alarms/short_name_1”,
               “alarms/short_name_2”, ...
               “alarms/short_name_N” ] }