This is a simple example with some issues but is good for explaining concepts. It listens for an event from a single webbrick and instructs another webbrick to toggle an output. i.e. If you had a switch on one webbrick that was to control the lights on another webbrick.
So first the Xml.
<eventInterfaces>
<eventInterface module='EventHandlers.HttpAction' name='HttpAction'>
<eventtype type="http://id.webbrick.co.uk/events/webbrick/TD">
<eventsource source="webbrick/100/TD/0" >
<event>
<!-- Trigger Digital In 7 -->
<url address="10.100.100.101" uri="/hid.spi?COM=DO7T:" cmd="GET" />
</event>
</eventsource>
</eventtype>
</eventInterface>
</eventInterfaces>
element: <eventInterfaces>
Each event despatch control file has a single top level container element called eventInterfaces, inside of which are 1 or more eventInterface elements.
element: <eventInterface>
An eventInterface element configures one instance of a named eventInterface, the configuration of an instance is private to itself. Most of the event interfaces can be loaded multiple times in the same configuration files or across multiple configuration files. A few can only be loaded once as they use dedicated resources or there is no point loading multiple times - these are typically listed in BaseHandlers.xml.
An event interface element lists two attributes that are used to dynamically load the event interface, these will be documented for each event interface. The dynamic loading means that it is possible to develop bespoke event interfaces and deploy without rebuilding the complete gateway. Each event interface element typically has one or more eventType elements, not typically but it is possible to have event interfaces that handle the configuration differently.
The sample above loads the event interface HttpAction, this event interface performs an HTTP request when it sees the configured event.
events
I am going to digress slightly here. Within the gateway an event consists of an event type an event source and optional other data. The event type identifies the meaning of the event and will specify the content of the other data, in effect it is a contract. If something sends a specific event type out it must supply the documented other data. The event source identifies where the event has come from, this generally is a relative URI but in passing across between webbrick gateways it may be turned in to an absolute URI. Think of the event source as a bit like a telephone number, where a relative URI it consists of the just the local part of the number, when made absolute it aquires the exchange code. Even then it is being made unique within the country and not world wide.
element: <eventtype>
Most event interface then lists one or more event types that it is interested in, this may be blank if it wants to see all event types and filter on the other things. The event log is an example of an event interface that listend to all events from all event sources (see BaseHandlers.xml).
The sample above listens for the event type http://id.webbrick.co.uk/events/webbrick/TD - the definition of the event types we define can be found at http://docs.webbrick.co.uk/events The TD event is sent by a webbrick when it sees a digital input activated, a Td (lower case d) is sent when the same event is generated from the webbricks own home page.
element: <eventsource>
Within the event type element the event interface lists one or more eventsource entries, these are the event source's that the interface it is interested in. It is possible again to put the empty string in here which means listen to all events of the named type.
The sample listens for webbrick/101/TD/0. This is an event from a webbrick, webbrick node number 101, type is TD and channel is 0. This is the naming convention for events sent by webbricks.
element: <event>
The elements contained within the eventsource element tend to be more event interface dependant and reference should be made to the event interface documentation at. http://docs.webbrick.co.uk/eventinterfaces/EventInterfaces.html
In the case of the HttpAction each event source element contains one event element, within each of these is one or more uri elements.
element: <uri>
Each URI element has 3 attributes. These are address, uri and cmd. The address is the network address of the server to send the HTTP request to, this may be a dotted IP address or a hostname that can be resolved by the host platform. The uri is the full uri to access on the targetted server and cmd is the HTTP command verb to use.
In the sample we are accessing a webbrick at address "10.100.100.101". The uri is "/hid.spi?COM=DI7:". /hid.spi?COM= is the network command interface to a webbrick, the remainder follows the webbrick command documentation.
Summary
So the minimalistic xml above loads the event interface HttpAction, it listens for a trigger of digital channel 0 on webbrick 100. It then issues an HTTP request to webbrick 10.100.100.101. The command is DO7T, which is a command to toggle the state of digital output 7.
Gotchas
By directly specifying the source webbrick for the event and the target webbrick in one place if you move a switch or change a light channel you may have to edit the configuration in multiple places. See the next sample for use of EventMapper to turn physical channel/webbrick numbers into logical devices, i.e. lights/kitchen/left/switch.