As we have seen the raw webbrick command strings are not very easy to interpret so here we are going to use HttpAction to give more meaningfull names to them.
So first the Xml.
<eventInterfaces>
<eventInterface module='EventHandlers.HttpAction' name='HttpAction'>
<eventtype type="internal">
<eventsource source="lights/garage/on" >
<event>
<!-- Trigger Digital In 7 -->
<url address="10.100.100.101" uri="/hid.spi?COM=DO7N:" cmd="GET" />
</event>
</eventsource>
<eventsource source="lights/garage/off" >
<event>
<!-- Trigger Digital In 7 -->
<url address="10.100.100.101" uri="/hid.spi?COM=DO7F:" 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.
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 "internal" - This is just a convention of ours to identify events thats are local to this webbrick gateway.
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 lights/garage/on and lights/garage/off.
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 issue a DO7N command when we see lights/garage/on and a DO7F command when we see lights/garage/off.
Summary
This once again gives us much easier to read event names when generating more complex actions, there could be an evemnt despatch file for every webbrick mapping easy names to the command structure. This could be taken further for other devices, i.e. audio/lounge/cd/play
The next example will combine the first three examples into a single configuration file to give us the basis of using user understandable names.