xevent-handler - A Generic Event Handler for Small Linux Devices
xevent is a light weight automation framework implemented in C++. It consists of a generic part that organizes the event handling and a domain specific part that does the work.
Many technical tasks require an asynchronous handling of events. These events origin from timers, interrupts, or external input. They initiate a work flow. Some calls within this work-flow might be also synchronous, such as fetching a measurement value.
xevent is a light weight automation framework implemented in C++. Task specific code is simply added by additional shared libraries. A xevent process is started for each shared library as defined in the configuration file.
The configuration file defines the following items:
- The workflow with the participating object classes
- xevent processes with the corresponding shared libraries
- The distribution of the object classes to the shared libraries / event handler processes
- Timers and interrupts
The workflow has to be built from standard event types: GET,SET,CREATE,DELETE,TRIGGER,RESPONSE. The RESPONSE event is used for the responses of synchronous calls. Participating object classes have to implement the events that are used with this class.
part provides the following object classes:
is used for data calibration. Measurement values can be mapped with a calibration curve. See header file DataProvider.h
writes data to a log file.
performs calls to the operating system.
Classes to perform fuzzy logic.
An application has to define a logic tree in its configuration file, that is built by fuzzy operations (e.g. NOT, AND, OR ) and comparator leaves. Fuzzy logic allows to implement expressions from natural speech like âin the nightâ: This may be defined by:
- âcompletely in the nightâ: 11 pm to 5 am, resulting in a 100% value
- ânot in the nightâ: 9 am to 5 pm, resultingin a 0% value
- The time in between results in percentages by linear interpolation.
Typical use of this software are all kinds of steering tasks like operating cooling and heating, where it is already in use, or steering tasks in a production environment.
A user library has to be linked into a file called HandledObject.so, that has to be in the shared library path of that event handler instance, that is intended to handle the therein implemented objects. Every user library has to provide a class HandlerFactory.cpp. Therein the factory methods for the implemented user classes have to be provided. See HandlerFactory.h. Indide a user library the configuration can be accessed via the ConfigFile class. The configuration file name is accessed via EDCommon. See ConfigFile.h EDCommon.h
For details see the EXAMPLE section.
The whole system is configured by the configuration file, typically /etc/xevent-handler.conf.
xevent provides some generic classes, that can be used as scetch for your application.
DataProvider instances are indentified by the instance numbers, starting with 1. In the configuration file there is a special DataProvider section, that assigns a calibration file name and the validity time to each DataProvider instance. This calibration file consists of lines of integer/float pairs, seperated by semicolon (100;23.4). The validity time defines how long (in seconds) the last value is returned in a GET. If the time is over, GET returns return value 1, which should result in a synchronous GET to the instance providing the raw measurement value.
GET provides float output.
RESPONSE inputs the new integer measurement value for calibration.
0, if the GET is withing the validity time, 1 otherwise.
A typical event flow can be seen in the repository file Test/etc/nestedsync.conf.
Logger writes messages to log file.
TRIGGER expects any value to write to log. No output.
A typical event flow can be seen in the repository file Test/etc/attribute.conf.
configuration file format
ConfigFile.h DataProvider.h EDCommon.h HandlerFactory.h