-
Notifications
You must be signed in to change notification settings - Fork 5
KNX Integration
For the Home/Building Automation domain universAAL provides a solution for integrating KNX, the most popular and widespread Home and Building Automation standard in Europe. This bundle suite provides interaction facilities with KNX sensor networks. The suite includes the KNX message protocol and provides monitoring and control features for KNX devices (sensors and actuators) and exports them to universAAL buses..
KNX features a twofold structure: on one hand there are single devices (sensors/actuators) where one device can have multiple inputs or outputs, which are called Communication Objects. Those Communication Objects can be grouped in so called Group Addresses. Group Addresses can contain Communication Objects from sensors (e.g. switch) and actuators (e.g. light controller). Therefore Group Addresses can be seen as Functions (e.g. switching/controlling a light, control the heating/cooling, control shutters/blinds,...). All devices which should be controlled or monitored must be included in a Group Address, otherwise the messages/events will not be sent over the KNX bus! Its also important to say that one Group Address has exactly one KNX data type, which implies that only Communication Objects from the same data type can be combined in one Group Address (e.g. 1-bit KNX-DPT-1 for on/off).
For this reasons universAAL LDDI focuses on Group Addresses (which can be seen as functions/machines) and not on single inputs/outputs (sensors/actuators).
| Artefact: KNX | |
|---|---|
| Maven artefact |
org.universAAL.lddi/lddi.knx.networkdriver: KNX Network Driver (spec). Establishes connection to the physical KNX/IP gateway either by binding to an UDP Multicast Channel or by direct tunneling connection to the gateway.
org.universAAL.lddi/lddi.knx.devicemanager: KNX Device Manager (spec). Reads KNX Group Address configuration from XML files (exported by ETS4) and registers a OSGI service for every KNX Group Address (a virtual KNX device). org.universAAL.lddi/lddi.knx.library: KNX Library (spec). Provides class models, utilities and interfaces for representing KNX devices. org.universAAL.lddi/lddi.lib.activityhub: Activity Hub Library (spec). Provides class models, utilities and interfaces for representing ActivityHub (ISO 11073) devices. org.universAAL.lddi/lddi.knx.refinementdriver.dpt1.activityhub: KNX Refinement Driver - Datapoint1 to ISO 11073 (spec). Converts a virtual KNX device of datapoint type 1.* to an equivalent virtual Activity Hub device (All Activity Hub sensor types are related to a KNX type 1.*). org.universAAL.lddi/lddi.knx.exporter: KNX Exporter. Exports virtual KNX devices to the universAAL middleware. org.universAAL.lddi/lddi.exporter.activityhub: Activity Hub Exporter. Exports virtual Activity Hub devices to the universAAL middleware. |
| Pax Composite bundle | - |
| Karaf Feature | uAAL-LDDI |
| Maven Site |
lddi.knx.networkdriver lddi.knx.devicemanager lddi.knx.library lddi.lib.activityhub lddi.knx.refinementdriver.dpt1.activityhub lddi.knx.exporter lddi.exporter.activityhub |
- Connection to the physical KNX/IP gateway
- Binding to UDP Multicast Channel
- Establishing a direct tunneling connection.
- OSGi shell command (universaal:knxcommand) for simulation of real sensor events to upper layers.
- KNX Representation as OSGi interfaces
- KNX Datapoint Types specifying methods for communication with device services.
- KNX drivers and KNX device model: KNX datapoint type specification
- Refinement of KNX devices of datapoint type 1.* to appropriate ActivityHub devices
- ActivityHub drivers and ActivityHub sensor model: Representation of all ActivityHub sensors.
- KNX Representation as registered OSGi services
- KNX Group Addresses
- KNX Device
- ActivityHub devices
- Exporter of KNX Devices to universAAL Service and Context bus as
- ActivityHub devices (ISO 11073-10471)
- Official unviersAAL Devices Ontology
The installation of the KNX network (sensors / actuators) is left to the KNX technician. Please be aware that multicast channels are not routed by IP network routers: The KNX/IP gateway should be on the same IP network segment as the uAAL peer. Officially supported/tested KNX/IP gateways:
- Siemens IP Router N 146/02 5WG1146-1AB02
- Merten KNX/IP-Router REG-K 680329
- ...Middleware bundles...
- org.universAAL.ontology/ont.phWorld/x.y.z
- org.universAAL.ontology/ont.device/x.y.z
- org.apache.felix/org.apache.felix.dependencymanager/3.1.0
- org.apache.felix/org.apache.felix.devicemanager/0.9.0-SNAPSHOT
- at.ac.tuwien.auto/calimero/ (Not a bundle, use wrap: prefix)
- org.jdom/jdom/ (Not a bundle, use wrap: prefix)
- jaxen/jaxen/1.1.3 (Not a bundle, use wrap: prefix)
- org.universAAL.lddi/lddi.knx.library/x.y.z
- org.universAAL.lddi/lddi.knx.networkdriver/x.y.z
- org.universAAL.lddi/lddi.knx.devicemanager/x.y.z
- org.universAAL.lddi/lddi.knx.exporter/x.y.z
Since a KNX Group Address has only one data type, and there are many data types in KNX for various use cases (e.g. switch, up/down, open/close, start/stop, occupied/notoccupied; all 1-bit), it can be easily mapped to certain ontologies (e.g. occupied/notoccupied -> motion sensor). The default KNX Exporter lddi.knx.exporter (which comes in the Karaf feature) maps KNX Group Addresses to the official uAAL Device ontology: This exporter component uses KNX services registered in OSGi directly (without any datamapping in between!) No abstract data model is used (like ISO11073-10471). This way the abstraction layer in the 3-tier LDDI architecture is not needed. KNX devices are directly mapped to Sensor concepts from the universAAL Device ontology. Incoming sensor events from the hardware are converted to context events and sent on the context bus.
However we implemented an additional Exporter, lddi.exporter.activityhub, that maps KNX Group Addresses to the ISO 11073-10471 (Activity Hub) specification: Matchmaking between ISO device services in OSGi registry (from Abstraction Layer) and the drivers is done by OSGi DAS. The devices are exported to the universAAL middleware buses using the (ActivityHub Ontology). Service profiles are registered on the service bus to provide access to device information. Incoming sensor events from the hardware are converted to context events and sent on the context bus.
To install this alternative exporter, in addition to all the original bundles, you need to install the Activity Hub ontology, and then change the lddi.knx.exporter for lddi.exporter.activityhub:
- org.universAAL.ontology/ont.activityhub/x.y.z
- org.universAAL.lddi/lddi.exporter.activityhub/x.y.z
The configuration of the KNX network (sensors / actuators) is left to the KNX technician. The KNX configuration should follow the rules for the establishment of a KNX network of the KNX Association.
Important for this KNX Suite is the availability of the KNX project export from ETS4 (zip file). This export is used by KNXDeviceManager (see below), which imports all important KNX configuration. The Importer needs the datapoint types of KNX group addresses and devices (communication objects). Therefore datapoint types must be specified for all used group addresses and communication objects in ETS4. Otherwise the Importer cannot handle these devices and they will not be part of the KNX abstraction in universAAL.
Configuration properties for connection are stored in config files and are provided by OSGi ConfigurationAdmin. The name of the config file is lddi.knx.networkdriver.cfg and must be placed in the configuration folder (e.g. /etc in Karaf). Most important parameters are mulitcast-IP and port (typically 224.0.23.12 and 3671) and address of the KNX/IP gateway.
You can find the default values, as an example, in https://github.com/universAAL/lddi/blob/master/lddi.knx/lddi.knx.networkdriver/src/main/resources/lddi.knx.networkdriver.cfg . If you install KNX Integration with its Karaf feature, this file is automatically created.
Since KNX has no device discovery, the device manager is responsible for creation of virtual KNX devices in the Access Layer by registering them as OSGi device services in the OSGi registry. The KNX device configuration is extracted from XML files which are exported from ETS4 before. ETS4 is the standard tool for management of KNX networks and devices, provided by the KNX Association.
The bundle gets updated by Configuration Manager, on bundle-start or change of the configuration file which defines the ETS4-Export-File location. Therefore you need 2 configuration files:
- A config file lddi.knx.devicemanager.cfg placed in the configuration folder (e.g. /etc in Karaf), defining the path to the ETS4 configuration file, like:
knxConfigFile = etc/KNX_Demowand-uAAL-MW20-Test-3.knxproj - A ETS4-Export-File, which is the file you referenced in the configuration file above. The Device Manager will load KNX group addresses from this file, extract group address information and create virtual KNX group functions and register them as device services in OSGi.
There are some sample applications that can be used as tests or examples for the KNX Integration. Take into account that these examples are not placed in the LDDI repository but the Samples repository.
- ActivityHub Simulator: Simulation of Activity Hub Sensor events with random time interval and pre-configured number of Sensors, according to configuration file. Generated events are sent to universAAL context bus using ont.activityhub. Five kinds of sensors can be created (most important ones for AAL domain): MotionSensors, ContactClosureSensors, UsageSensors, SwitchSensors, TempSensors. In the config file the number of sensors to create can be specified for all sensor types. Also, the time interval of sending events can be defined.
- ActivityHub Client: Receiver of Sensor Events from universAAL Context Bus according to the activityhub.ontology. Two service requests are implemented for lddi.hw.activityhub.exporter: getSensorInfo and getAllSensors. A Swing GUI shows all information: Logs, Sensor list, Sensor Events, Sensor Details.
- Device Client: Receiver of Sensor Events from universAAL Context Bus according to the Device ontology. A Swing GUI shows all information: Logs, Sensor list, Sensor Events, Sensor Details.