MP-SS14-01

Aus Verteilte Systeme - Wiki
Wechseln zu: Navigation, Suche

Inhaltsverzeichnis

Organisatorisches

Projektteilnehmer

René Drolshagen, B.Sc. - 4. Semester Master Informatik

Projektbetreuer

Prof. Dr. Reinhold Kröger - Projektbetreuender Professor

Dipl.-Inform. (FH) Kai Beckmann, M.Sc. - Projektbetreuer

Projektdefinition/Projektbeschreibung

Ziel dieses Projekts ist es der aktuell verfügbaren Heimautomatisierung eine Regelengine an die Seite zu stellen, um die Modellierung von diversen Nutzerszenarien zu ermöglichen. Ideenlieferant dieses Projekts stellt dabei das QIVICON Projekt der Telekom dar, welches vor kurzer Zeit auf der CeBIT vorgestellt wurde. Die baugleiche Hardware der Firma Sumitomo Electric Networks dient als technischer Ausgangspunkt, um eine vergleichbare Lösung zu erzielen. Angestrebt wird hierbei ein Deployment der mächtigen Regelengine JBoss Drools, welche in der aktuellen Version 7.0 durch Einführung des PHREAK Algorithmus nochmals an Geschwindigkeit im Bereich des Reasoning gewonnen hat. Als OSGi Umgebung wird das ProSyst Smart Home SDK verwendet, welches auch Basis der QIVICON Plattform ist.

Eine Projektdokumentation in Form eines Wikis ist zu erstellen und zeitnah am Fortschritt des Projekts zu führen. In diesem soll auch ein konzeptioneller Teil im Bereich der Regeleingabe erstellt werden. Dieser befasst sich mit verschiedenen Definitionsmöglichkeiten von Regeln, welche ausreichend detailiert beschrieben und einem "Proof of Concept" unterzogen werden sollen.

Die Evaluierung des Projekts wird anhand von WieDAS (einem zuvor abgeschlossenen Heimautomatisierungsprojekts für das Leben im Alter) Szenarien durchgeführt. Am Ende des Projekts steht eine Abschlusspräsentation, welche öffentlich zugänglich ist, um anderen Studierenden das Projekt näher bringen zu können.

Aufgabenliste

Termine / Zeitplan

Projektstart

Montag, der 24.03.2014

Zwischenpräsentation

Die Zwischenpräsentation findet am Donnerstag, den 15.05.2014 ab 17.45 Uhr statt. Folgende Themen sollen Inhalt der Präsentation sein:

  • Problemfeld / Forschungsgebiet
    • Labor
    • WieDAS
    • Thema des Doktorandenkolleg
  • Fragestellung des Themas
    • Analyse & Bewertung
    • Drools in der Projektumgebung
      • Aufgabe durch openHAB
      • Performance
  • Organisatorisches
  • Aktueller Stand und Zeitplan
  • Planung, Ziel und Aussicht
    • UseCase / Anwendungsfall
    • Szenario (WieDAS!)
    • Performancebeurteilung / Funktionierende Bewertung am Ende

Abschlusspräsentation (öffentlich)

Die Abschlusspräsentation findet am Donnerstag, den 26.06.2014 ab 17.45 Uhr statt.

  • Problemfeld / Forschungsgebiet
    • Labor
    • WieDAS
    • Thema des Doktorandenkolleg
  • Fragestellung des Themas
    • Analyse & Bewertung
    • Drools in der Projektumgebung
      • Aufgabe durch openHAB
      • Performance
  • Organisatorisches
  • Aktueller Stand und Zeitplan
  • Planung, Ziel und Aussicht
    • UseCase / Anwendungsfall
    • Szenario (WieDAS!)
    • Performancebeurteilung / Funktionierende Bewertung am Ende

Abschlusspräsentation (Labor) & Abnahme

Die Abschlusspräsentation findet am Mittwoch, den 20.08.2014 ab 15.00 Uhr statt.

  • Problemfeld / Forschungsgebiet
    • Labor
    • WieDAS
    • Thema des Doktorandenkolleg
  • Fragestellung des Themas
    • Analyse & Bewertung
    • Drools in der Projektumgebung
      • Aufgabe durch openHAB
      • Performance
  • Inhalte der Entwicklung
    • UseCase / Anwendungsfall
    • Szenarios (WieDAS!)
    • Performancebeurteilung
    • Funktionierende Bewertung am Ende
  • Live-Demo

Wiki

Die finale Version des Projektwiki's muss bis zum 17.08.2014 fertig sein.

Aktueller Status

  1. Einarbeitung in das openHAB Projekt [erledigt]
  2. Einarbeitung in OSGi [erledigt]
  3. Einarbeitung in JBoss Drools [erledigt]
  4. Einarbeitung in die Dokumentation des Sumitomo Electric Networks MegaBit Gear MR5102 [erledigt]
  5. Vergleich der Rule Engines [erledigt]
    1. JBoss Drools [erledigt]
    2. Prosyst Home Automation Manager [erledigt]
    3. Rule Engine von openHAB [erledigt]
    4. Abschließender Vergleich [erledigt]
  6. Konzeption [erledigt]
    1. Entwicklung von diversen Möglichkeiten zur Verwaltung der JBoss Drools Regeln für Endanwender [erledigt]
      1. Logischer Verschaltungsplan nach dem Vorbild von SPS Programmierung [erledigt]
      2. Sprachliche Eingabe ähnlich zum Kickstarter Projekt "Homey" [erledigt]
      3. Textuelle Eingabe via Drools ähnlicher Editor Syntax [erledigt]
      4. Konfiguration über eine Website/Webapp [erledigt]
  7. Recherchen zu möglichen Regelszenarien [erledigt]
    1. Allgemeine Szenarien [erledigt]
    2. Im QIVICON Kontext [erledigt]
    3. In Roadmaps der Bundesregierung [erledigt]
    4. In der ProSyst mBS Smart Home SDK Dokumentation [erledigt]
  8. ProSyst SDK [erledigt]
    1. Installation [erledigt]
    2. Ausführung eines Testprojekts [erledigt]
    3. Erstellen und Deployen eines Drools OSGi Projekts auf die ProSyst Emulator Umgebung [erledigt]
  9. Inbetriebnahme des Sumitomo Electric Networks MegaBit Gear MR5102 [gescheitert - siehe [1]]
    1. Konfiguration des Geräts im Hochschulnetzwerk [erledigt]
    2. Konfiguration des zweiten Geräts in meinem Netz daheim [erledigt]
    3. SSH und Telnet Zugang zum MR5102 finden + eigene Bundles deployen [erledigt]
    4. Erstellen und Deployen eines Drools OSGi Projekts auf das MegaBit Gear MR5102 mittels der ProSyst Umgebung [gescheitert - siehe [2]]
  10. Inbetriebnahme des ProSyst mBS Smart Home SDK auf dem Raspberry Pi [erledigt]
    1. Konfiguration des Geräts im Hochschulnetzwerk [erledigt]
    2. Installation der aktuellen Raspbian Version [erledigt]
    3. Konfiguration einer ProSyst mBS Smart Home SDK Umgebung inklusive JBoss Drools 7 [erledigt]
    4. Deployen eines JBoss Drools Testprojekts zur Prüfung der Umgebung [erledigt]
    5. Installation des QIVICON ZigBee USB-Sticks [erledigt]
    6. Installation des EnOcean USB-Sticks [erledigt]
    7. Konfiguration von ZigBee und EnOcean Geräten [erledigt]
    8. Inbetriebnahme einer UPnP Gerätschaft [erledigt]
  11. Messungen zwischen openHAB mit und ohne JBoss Drools [nicht möglich - siehe [Kreu14]]
  12. Entwicklung [erledigt]
    1. Anzeigen von allen angebundenen Geräten [erledigt]
    2. Schnittstelle zu ProSyst finden & Abstraktion implementieren [erledigt]
    3. Anbindung der ProSyst mBS Smart Home SDK Geräte an JBoss Drools [erledigt]
    4. Implementierung von Zeitaspekten innerhalb der Regeln [erledigt]
    5. Entwicklung eines Simulators für physische Anwesenheit einer Person in der Umgebung [erledigt]
    6. JBoss Drools in einem durchgehenden Zyklus Regeln prüfen & abarbeiten lassen [erledigt]
    7. Zusammenbringen aller vorherigen Implementierungen [erledigt]

Referenzprojekte

openHAB

Das openHAB Projekt ist eine in Java entwickelte Heimautomatisierungslösung, welche Komponenten hersteller- und protokollneutral miteinander verbindet. Das Projekt wird unter der Eclipse Public Licence entwickelt und ist frei über github.com verfügbar. OpenHAB ist betriebssystemunabhängig und bietet Interfaces für den Webbrowser und alle gängigen mobilen Betriebssysteme.

Das openHAB Projekt lässt sich in zwei Teile aufteilen:

  1. openhab-runtime
  2. openhab-designer

Die openHAB Runtime verrichtet die eigentliche Arbeit innerhalb des Projekts. Diese wird auf dem Server aufgespielt und verarbeitet die Kommunikation zu den einzelnen Sensoren und bietet die Oberflächen zur Benutzung und Überwachung. openHAB arbeitet mit dem OSGi Framework Equinox, welches den Vorteil der Modularität besitzt, sodass Komponenten zur Laufzeit gestartet und gelöscht werden können. Außerdem bietet dieser Ansatz die Möglichkeit, mit relativ geringem Aufwand eigene Bindings (Anbindungen an Geräte) zu entwickeln, sodass die Liste der durch openHAB ansprechbaren Geräte theoretisch unbegrenzt ist. Zum aktuellen Zeitpunkt unterstützt openHAB 61 Geräte bzw. Gruppen von Geräten, sodass ohne Aufwand bereits ein Großteil der heute gebräuchlichen Heimautomatisierungsgeräte ansprechbar ist. Beispiele hierfür sind die nachfolgend aufgeführten: Asterisk, Bluetooth, Comfo Air, CUPS, digitalSTROM, DMX512, EnOcean, Epson Projector, Exec (Execute Command), Fritz!Box, Fritz AHA, HDAnywhere, Heatmiser, Homematic, HTTP, IHC / ELKO, INSTEON Hub, KNX, Koubachi, MAX!Cube, MiLight, Modbus TCP, MPD, MQTT, Netatmo, Network Health, Nibe Heatpump, Nikobus, Novelan/Luxtronic Heatpump, NTP, One-Wire, Onkyo AV Receiver, Open energy monitor, OpenPaths, OpenSprinkler, OSGi Configuration Admin, Philips Hue, Piface, Pioneer AV receiver, Plugwise, PLCBus, PulseAudio, RFXCOM, Samsung TV, Serial, SNMP, Squeezebox, System Info, Somfy URTSI II, Sonos, TCP/UDP, Swegon ventilation, TinkerForge, Tivo, VDR, Wake-on-LAN, Z-Wave.

Der openHAB Designer ist eine Eclipse basierte Plattform zur Entwicklung und Verwaltung von Konfigurationen der openHAB Runtime.

openHAB besitzt zwei Arten der Kommunikation. Zum einen den asynchronen Event Bus, über welchen Statusinformationen der angebundenen Geräte ausgetauscht werden. Und zum anderen ein Item Repository, welches an den Event Bus angebunden ist und den aktuellen Status der angeschlossenen Geräte verfolgt. Das Item Repository führt immer den aktuellen Stand der Status (auch Prozessabbild genannt) und kann somit für die Visualisierung auf einer Weboberfläche o.Ä. herangezogen werden. Eine Persistenzschicht innerhalb von openHAB ermöglicht das Speichern und Verfolgen von Zuständen der angeschlossenen Geräte. Somit bietet openHAB die Möglichkeit, Verläufe und Graphen über einzelne Informationen wie beispielsweise Temperatursensoren zu erstellen. Anbindungen an nahezu alle gängigen Datenbanken bietet openHAB von Haus aus an [Open14].

QIVICON

QIVICON ist eine Heimautomatisierungslösung, welche von der Deutschen Telekom seit einiger Zeit angeboten und beworben wird. Im Gegensatz zu openHAB wird hierbei nicht nur die Software vertrieben, sondern direkt ein komplettes Endgerät, welches auf den Namen QIVICON Homebase hört. Dieses kümmert sich komplett um die Anbindung der einzelnen Heimautomatisierungsgegenstände wie Lichtschalter oder ähnliche. Als Verwaltungsplattform der QIVICON Homebase und deren angebundenen Geräte bietet die Telekom eine App (für iOS und Android). Apps der QIVICON Partner EnBW, eQ-3 und Bitron können ebenfalls verwendet werden. Als Endgeräte bietet QIVICON zum aktuellen Zeitpunkt lediglich einige Schalter, Taster, Heizungssteuerungen, Temperatur- und Feuchtigkeitssensoren, Bewegungsmelder, Rauchmelder und Türkontaktschalter. Die Möglichkeit, eigene Applikationen und Erweiterungen für weitere Geräteanbindungen, zu schreiben wird zum aktuellen Zeitpunkt nicht unterstützt [Qivi14].

In absehbarer Zukunft soll eine neue API erscheinen, welches es Hobbybastlern und anderen Entwicklern ermöglicht, eigene "Gerätetreiber", Applikationen und ähnliches für die QIVICON Homebase zu schreiben. Auch wird zu diesem Zeitpunkt die Möglichkeit geschaffen, die QIVICON Homebase komplett ohne die Telekom Cloud zu betreiben. Zu diesem Zweck wurden die APIs der Telekom Cloud und der QIVICON Homebase im letzten Softwareupdate angeglichen. Auch hat die QIVICON Homebase ein Java SE Update von 1.4 auf 1.7 erhalten. Gegen Ende 2014 soll, laut Roadmap, die QIVICON Homebase bzw. die Software auf ihr weiter in Richtung Opensource und Community gelenkt werden [Hill14].

Zum aktuellen Zeitpunkt nutzt die QIVICON Homebase ein "QIVICONManifest", welches die Rechteverwaltung der einzelnen OSGi Applikationen übernimmt. Dieses ist gegenüber dem normalen Java Rechte Management eine deutliche Verbesserung, soll jedoch in absehbarer Zeit auch möglichst vereinfacht werden. Im Bereich Cloud <-> QIVICON Homebase Kommunikation setzt die Deutsche Telekom aktuell auf synchrone JSON-RPC Aufrufe für die normale Kommunikation und Websockets für Pushnachrichten des Servers [Hill14].

Die QIVICON Homebase basiert auf einem Gerät der Firma Sumitomo Electric Networks. Wie beim Sumitomo Electric Networks MR5102 auch nutzt die QIVICON Homebase OSGi.

Vorstellung der Rule Engines

openHAB

Das openHAB Projekt hat bis zur Mitte des Jahres 2012 (bis Version 0.9.0) standardmäßig auf JBoss Drools als Rule Engine zum Definieren von Abläufen, Automatismen und ähnlichem innerhalb von openHAB gesetzt [Kreu12]. Seit diesem Zeitpunkt wurde die damals vorhandene Drools Rule Engine durch ein Eigenkonstrukt ersetzt [OpHA14]. Gründe für diesen Wechsel sind laut [Kreu12] und [Kreu14] die nachfolgend aufgeführten:

  • Bessere Syntax, welche leichter zu lesen und schreiben ist und die openHAB Konzepte perfekt integriert
  • Vollständiger IDE Support innerhalb des openHAB Designer
  • Die Ausführungszeit der Rule Engine ist deutlich verbessert, da die Regeln nicht mehr in Java Quellcode kompiliert werden müssen sondern nur interpretiert werden
  • Geringere Speicheranforderungen zur Laufzeit
  • Kein Java Compiler (4,8MB) und kein JBoss Drools (5MB) notwendig, sodass ca. 10MB Quellcode gespart werden

Das neue Rule Engine System besteht im Grunde genommen aus den folgenden zwei Teilen:

  • Definition des Triggers/Auslösers
  • Aktion der Regel

Folgender Quelltextausschnitt zeigt beispielhaft eine Regel, welche mit openHAB realisiert werden kann. Die Statements im "when"-Teil sind hierbei die Definition des Auslösers zuzuordnen, wohingegen im "then" Teil die Aktion der Regel definiert wird. Diese Art eine Regel aufzuschreiben, ähnelt stark der Optik von JBoss Drools.

// Entnommen von: [Kreu12]
rule "Turn light on"
    when
        Item Door changed to OPEN
    then
        Light.postUpdate(ON)
end

Die nachfolgend aufgeführten Projekte werden für die Realisierung der Rule Engine verwendet [Kreu12]:

  1. Xtext für den Aufbau der Regeln
  2. Xbase zur Realisierung des Aktionsteils
  3. Quartz als zeitlichen Scheduler
  4. Joda Time für die Darstellung von Zeiten und Daten

Xtext ist ein Framework zur Erstellung einer Domänenspezifischen Sprache (DSL), welches auf Basis von einfachen Grammatiken vollwertige Integrierte Entwicklungsumgebungen (IDE) generieren kann. Diese sind dann vollständig mit Validierungen, Verbesserungsvorschlägen, Syntax Hervorhebung, Content Assist und weiteren Funktionen ausgestattet. Die Grammatikdateien der Xtext-Validierungen von openHAB befinden sich im Github Projekt (Link) in folgenden Pfaden:

  • /bundles/model/org.openhab.model.rule/src/org/openhab/model/rule/Rules.xtext
  • /bundles/model/org.openhab.model.item/src/org/openhab/model/Items.xtext
  • /bundles/model/org.openhab.model.sitemap/src/org/openhab/model/Sitemap.xtext
  • /bundles/model/org.openhab.model.script/src/org/openhab/model/script/Script.xtext

Xbase wird verwendet, um den vorher erstellten (noch strukturellen) Informationen eine Funktion zu geben. Xbase nimmt den Quellcode, welcher anhand der Xtext definierten DSL geschriebenen strukturellen Code und übersetzt diesen in Java Quellcode. Dieser kann dann ausgeführt und somit ausgewertet/verwendet werden [Xbas14]. Durch den Einsatz von Quartz und Joda Time ist es außerdem möglich, zeitliche Abläufe und Zeitpunkte innerhalb der Regeln zu definieren. Beispielsweise ist es möglich Timer zu definieren, nach welchen eine bestimmte Interaktion ausgeführt wird. Auch gibt es die Möglichkeit, eine Cronjob ähnliche Syntax zu verwenden, um Aktionen in bestimmten zeitlichen Abständen auszuführen. Die zeitlichen Möglichkeiten werden von den nachfolgenden Quellcode Ausschnitten beispielhaft gezeigt:

// Entnommen von: [Kreu12]
rule "Turn on irrigation system after two days without rain"
    when
        Time is midnight
    then
        if(Rain==OFF && !Rain.changedSince(now.minusDays(2))) {
            Irrigation.sendCommand(ON)
        }
end

rule "Time trigger"
    when 
        Time is midnight or
        Time cron "0 15 * * * ?"
    then
        callScript("doSomething")
end

Die komplette Liste der Aktionen im "then"-Abschnitt der Regeln können im openHAB-Wiki unter folgendem Link nachgelesen werden: https://github.com/openhab/openhab/wiki/Actions

QIVICON

Die Regel Engine, welche in der QIVICON Box eingesetzt wird, nennt sich "Home Automation Manager (HAM)" und ist ein Produkt von ProSyst. Daher wird der nachfolgende Artikel auf der offiziellen ProSyst Dokumentation basieren, welche unter [Auto14] zu finden ist.

Der Home Automation Manager bietet die Möglichkeit Aktionen basierend auf einer Vielzahl von Eingangsparameternauszulösen. Diese Auslöser können von jedem ProSyst SDK steuerungsfähigen Gerät geniert und als Eingabe für Regeln verwendet werden. Die Ausführung der Regeln kann, je nach Konfiguration, sequentiell oder nach einer selbstdefinierten Logik erfolgen. Angelegte und definierte Regeln werden von dem HAM in einem so genannten "Config Tree Admin" gespeichert, welcher als Basis für einen Export und Re-Import in ein anderes HAM fähiges System dient.

Der ProSyst HAM benötigt die folgenden OSGi Bundles (Installation in der aufgeführten Reihenfolge) um vollständig lauffähig zu sein:

  • org.json.jar (Apache Support Bundles)
  • org.apache.commons.io.jar (Apache Support Bundles)
  • org.apache.commons.fileupload.jar (Apache Support Bundles)
  • fw.web.common.jar (Web Common Resources Bundle)
  • fw.remote.jsonrpc.jar (JSON-RPC Provider Bundle)
  • ham.api.jar (HAM API)
  • ham.core.jar (HAM Manager)
  • ham.timer.jar (HAM Timer Support)
  • ham.logic.jar (HAM Logic Condition)
  • ham.log.jar (HAM Log Command)
  • ham.commands.jar (HAM Console Commands)
  • ham.astro.sunriset.jar ( Astro Calculator for Sunriset Library)
  • ham.remote.jar (HAM Remote Handler)
  • ham.servlet.jar (HAM Support for Configurations Import/Export)
  • ham.event.jar (HAM Event Command and Condition)
  • ham.command.rule.jar (HAM Rule State Command Provider)
  • ham.web.console.plugin.jar (HAM Plugin for Web Console)
  • ham.event.web.jar (HAM Event Command and Condition Web GUI)
  • ham.command.rule.web.jar (HAM Rule State Command Web UI)

An der Namensgebung bestimmter OSGi Bundles sieht man, dass der ProSyst HAM in der Lage ist komplexe Eingaben als Auslöser für Regeln anzunehmen. Diese können beispielsweise zeitliche, sensorische oder auch Vorgänge der Natur wie beispielsweise der Sonnenaufgang sein. Hiermit wird ein breites Spektrum an Sensoren/Aktoren Anbindungen geboten, welche für Regeln verwendet werden können. Eine vollständige Liste der ansteuerbaren Knoten befindet sich nachfolgend:

Beispielhafte Bedingung für eine HAM Regel. Bild entommen aus [Auto14]
Beispielhafte Aktion einer ProSyst HAM Regel. Bild entommen aus [Auto14]
Beispielhafte Webconsolen Regel. Bild entommen aus [Auto14]
  • Bluetooth
  • Cameras
  • ConfigTree
  • Database
  • DECTDevStreams
  • DLNA Server Enabler
  • Email
  • EnOcean
  • Home Automation Manager
  • Home Device Manager
  • KNX
  • Notification Manager
  • OSGi Mobile
  • Peripherals
  • Residential Management Tree
  • RSS
  • Serial and Parallel
  • Test Execution Environment
  • Tooling Agents
  • UPnP
  • USB
  • Wireless M-Bus
  • Wireless Messaging
  • X10
  • ZigBee
  • Z-Wave

Das Management der einzelnen Regeln und Abläufe wird im HAM mithilfe der Textconsole oder einer Webconsole durchgeführt. Auch ist es möglich mittels einer Java und JSON-RPC API die Regelnd es Systems zu verwalten. Die Dokumentation der hierzu benötigten Befehle kann in der HAM Dokumentation von ProSyst gefunden werden (http://dz.prosyst.com/pdoc/mBS_SH_SDK_7.5/modules/hdm/api.html).

JBoss Drools

Drools ist eine in Java programmierte Rule Engine. Ein Framework, das in eine Anwendung integriert, Funktionen zum Verwalten von Geschäftsregeln bereitstellt. Das Drools Projekt wurde im Jahre 2001 auf SourceForge unter der Apache Software Lizenz v2 (ASL2) erstellt. Im Jahre 2005 wurde das Projekt von JBoss übernommen und sollte seitdem den Namen "JBoss Rules" tragen, jedoch wurde dieser Name von der Nutzergemeinde nie angenommen und daher wurde der Name einige Zeit später in JBoss Drools geändert. Die aktuelle Version 6.0 von JBoss Drools wurde Ende Dezember 2013 veröffentlicht und kann kostenfrei von der JBoss Homepage heruntergeladen werden [Wiki14].

Regeldefinition

JBoss Drools verwaltet seine Regeln in sogenannten Drools Rule Files, welches eine einfache Textdatei mit der Endung .drl sind. In ihnen werden das Regelwissen sowie Funktionen, neue Typen und Queries von Drools definiert. Der Inhalt eines Drools Files kann aus den nachfolgend aufgeführten Teilen bestehen. Hierbei spielt (bis auf die package Information) die Reihenfolge der aufgeführten Elemente keine Rolle. Alle nachfolgend aufgeführten Elemente sind in den folgenden Unterkapiteln, basierend auf [Meie06] und [Preck12], ausführlich erläutert.

  • package package-name
  • imports
  • globals
  • functions
  • queries
  • rules

Package

Das Package Statement entspricht der bekannten Java Package Deklaration, welche sich daher auch nicht in der Syntax unterscheidet.

Import Statement

Mithilfe des Import Statements ist es möglich, Java Klassen zu importieren, welche dann als Grundlage für Ausgangsobjekte einer Regel verwendet werden können. Dies muss explizit getan werden für alle Klassen, welche nicht zum java.lang Package gehören. Die Syntax des Import Statements ist nachfolgend aufgeführt:

import java.util.Date;

Typdeklarationen

Typdeklarationen innerhalb von Drools Rule Files bieten dem Entwickler die Möglichkeit, Datenmodelle direkt der Rule Engine übergeben zu können, ohne vorher aufwändig Java-Klassen implementiert zu haben. In Drools Rule Files deklarierte Typen werden Faktentypen genannt, da ihre Hauptaufgabe darin besteht, als Fakten von Regeln gehandelt zu werden. Ein Zugriff auf diese Objekte außerhalb der Rule Engine ist nicht möglich. Die Syntax für eine Drools Rule File Typ Deklaration ist nachfolgend aufgeführt:

declare Raum
     quadratmeter : double
     bezeichnung : String @key
     stockwerk : int
end

Durch die Annotation @key ist es möglich, dem Faktentyp mitzuteilen, welches Attribut als Primärschlüssel dienen soll. Auch ist zu beachten, dass es möglich ist Faktentypen von normalen Java Klassen abzuleiten, um diese vererbte Klasse dann anonym nutzen zu können. Ein Beispiel zeigt die nachfolgende Fakten Typ Deklaration:

import meineKlasse.Raum

declare Büro extends Raum
     anzahlRJPorts : int
     anzahlProfessorenPlaetze : int
end

Regeln

Generell kann bei Systemen, welche Inferenz betreiben, zwischen zwei Vorgehensweisen unterschieden werden. Diese sind "Vorwärtsverkettung" und "Rückwärtsverkettung". JBoss Drools verwendet Vorwärtsverkettung, welche man sich vereinfacht als "wenn Aktion, dann Reaktion" vorstellen kann. Somit versucht Drools immer, aus bestehendem Wissen mithilfe einer Inferenzmethode (z.B. modus ponens) weiteres Wissen zu generieren, welches dann erneut als Prämisse für die bestehenden Regeln verwendet werden kann [Vorw14], [Görz14].

Die Definition von Drools Regeln hat stehts die gleiche Struktur, welche nachfolgend gezeigt ist.

rule "name"
     ATTRIBUTE
     when
          LHS - Bedingungen
     then 
          RHS - Folgerung/Aktion
end

Der Name einer Regel kann frei gewählt werden, muss jedoch eindeutig innerhalb des Packages sein. Die verschiedenen möglichen Aktionen im LHS und RHS Teil einer Regel sind in den folgenden Unterkapiteln erläutert.

LHS - Bedingungen

Im Left Hand Side (LHS) oder Bedingungsteil sind Bedingungen formuliert, welche während der Laufzeit der Rule Engine gegen die vorhandenen Fakten abgeglichen werden. Diese können theoretisch inline geschrieben werden, sollten jedoch wegen der Übersicht halber zeilenweise notiert werden. Implizit setzt Drools zwischen jede Bedingung im LHS-Teil einer Regel ein logisches AND. Sollte eine andere Verknüpfung gewünscht sein, so muss diese explizit gewählt werden. Hierbei können alle logischen Operationen einer Programmiersprache verwendet werden. Für Operationen auf Variablen einer Klasseninstanz können die gewohnten logischen Operationen von Java verwendet werden. Sollen mehrere Attribute überprüft werden, so können diese mittels "&&" oder "||" verknüpft werden. Auch ist es möglich (und oft ratsam), Variablen oder Instanzen einer Klasse an neue Variablen zu binden, da diese dann einfach im RHS-Teil der Regel verwendet werden können. Einen beispielhaften LHS-Teil zeigt der folgende Quellcode:

// Entnommen von: [Preck12]
rule "Wenn es einen Kuchen gibt und eine Person mit Hunger, die jünger als 30 ist, dann . . . "
     when
          exists Kuchen ()
          $p : Person ( hatHunger == true && alter < 30)
     then
          . . .
end
RHS - Folgerung/Aktion

Im Folgerungsteil, auch Right-Hand-Side genannt, kann theoretisch jeder beliebige Java Code ausgeführt werden. Somit wird hier auch die normale Java Syntax verwendet. Neben dieser Möglichkeit bietet JBoss Drools die Möglichkeit, die Wissensbasis mit den nachfolgenden Operationen zu verändern:

  • insert(Object o): Neuen Fakt einfügen
  • retract(Object o): Löschen eines Faktes
  • update(Object o): Updaten eines Faktes mithilfe einer im LHS Teil gebundenen Variable
  • modify(Object o) {}: Updaten des Objects mithilfe von Setter-Methoden innerhalb der geschweiften Klammern

Das weitergeführte Beispiel aus dem Unterkapitel LHS zeigt die Verwendung von Aktionen:

// Entnommen von: [Preck12]
rule "Wenn es einen Kuchen gibt und eine Person mit Hunger, die jünger als 30 ist, dann hat die Person keinen Hunger mehr und lösche den Kuchen"
     when
          $k : Kuchen()
          $p : Person(hatHunger == true && alter < 30)
     then
          retract($k);
          $p.setHatHunger(false);
          update($p);
          modify($p){setHatHunger(false)} //hat denselben Effekt wie der Setter + Update
end

Funktionen

Funktion können verwendet werden, um häufig verwendete Berechnungen innerhalb von Regeln auszulagern. Die Syntax der Funktionen sieht wie folgt aus:

function int calcZwoelf(int wert) {
     return wert*12;
}

Algorithmischer Hintergrund

Überblick

Bis zur Version 6.0 von JBoss Drools, wurde eine angepasste Version des Rete Algorithmus verwendet. Dieser ist unter dem Namen ReteOO bekannt und ist eine Erweiterung des Standard Rete Algorithmus um die Möglichkeit Objekte verwenden zu können. Der klassische Rete Algorithmus wurde im Jahre 1979 von Charles Forgy im Rahmen seiner Doktorarbeit entwickelt. Sein Ziel war es die Regelverarbeitung deutlich zu beschleunigen und effizienter zu gestalten. Dies wird erreicht durch die Zwischenspeicherung von bereits ausgewerteten Argumenten [Preck12].

Ab Drools Version 6.0 kommt als Algorithmus zum inferieren von Wissen der PHREAK-Algorithmus zum Einsatz. Dieser ist keine komplette Neuentwicklung sondern basiert auf dem bisher verwendeten ReteOO Algorithmus. Weitere Ideen wurden von LEAPS, RETE/UL and Collection-Oriented Match herangezogen um den PHREAK-Algorithmus zu entwickeln.

PHREAK

Beschreibung

Wie bereits in der Übersicht erwähnt, basiert PHREAK zu großen Teilen auf ReteOO. Durch diese Tatsache erbt PHREAK die nachfolgend aufgelisteten Eigenschaften von ReteOO, welche in jedem theoretischen Informatik Buch über Algorithmen nachgelesen werden können:

  • Node sharing
  • Alpha indexing
  • Beta indexing
  • Tree based graphs
  • Modify-in-place
  • Property reactive
  • Sub-networks
  • Backward Chaining
  • Lazy Truth Maintenance
  • Heap based agenda
  • Dynamic Rules
Speichermodell des PHREAK Algorithmus. Quelle siehe Bild Beschreibung.

Desweiteren besitzt PHREAK vier weitere Konzepte, welche teilweise vom JBoss Team entwickelt und teilweise von anderen Algorithmen übernommen wurden. Diese sind nachfolgend im englischen Originaltitel aufgelistet und werden darunter in einzelnen Abschnitten erläutert.

  • Three layers of contextual memory: Node, Segment and Rule memories.

Die Evaluierung von Regeln geschieht in PHREAK nur, wenn diese eingebunden sind. Standardmäßig sind alle Regeln ungebunden. Eine einfache Heuristik entscheidet die nächste zu feuernde Regel, mit dem Ziel durch die Auslösung der Regel möglichst viele neue Regeln feuern zu können. Sobald für eine der Regeln alle Eingabeparameter vorliegen, wird die Regel inklusive der Parameter in eine prioritätssortierte Warteschlange eingereiht. Einzig die Regeln, welche sich in dieser Warteschlange befinden werden ausgewertet. Alle anderen Regeln müssen warten [Red14].

Im Unterschied zu ReteOO besitzt PHREAK 3 verschiedene Speicherebenen, welche das zuvor erläuterte Vernetzungsverhalten unterstützen. Dies wird im Speichermodell, welches im rechten Bild gezeigt wird, veranschaulicht.

Sharing Segment eines PHREAK Graphen. Quelle siehe Bild Beschreibung.
  • Rule, segment, and node based linking.

Im Gegensatz zu ReteOO werden in PHREAK Regeln bzw. Teile von Regeln nur einmal ausgewertet. Beim Aufbau der/des Graphen werden so genannte Segmente gebildet, welche Gemeinsamkeiten haben. Diese werden dann nur einmal ausgewertet und für beide Regeln verwendet. Die Segment Markierungen werden mithilfe einer Bitmaske festgehalten.

Im Bild sieht man beispielhaft eine Regel, welche ein gemeinsames Segment hat. In diesem Fall wäre R1 = A B C, und R2 = A D E. Der Regelabschnitt A ist für beide Regeln gleich und wird somit nur einmal ausgewertet. Das entstandene Ergebnis wird für beide Regeln zur weiteren Verarbeitung verwendet [Red14].

  • Delayed and Stack Based Evaluations.

In PHREAK werden Regeln für welche die kompletten Eingabeparameter noch nicht verknüpft sind nicht als sogenanntes "Goal" aufgenommen. "Goal" beschreibt in diesem Fall eine komplette Regel inklusive ihrer Eingabeparameter, welche in der Warteschlange zur Bearbeitung eingereiht wurde. Dies wird von PHREAK so umgesetzt, da diese Regeln durch die nicht kompletten Eingabeparameter zu keinem gesamten Ergebnis, sondern nur zu wertlosen Teilergebnissen kommen würde [Red14].

  • Isolated rule evaluation.

PHREAK arbeitet im Gegensatz zu ReteOO mit einem set-orientierten Ansatz und keinem Tuple-orientiertem. Dies sieht in PHREAK so aus, dass im ersten zu besuchenden Knoten ein Set erzeugt wird, welches die Ergebnisse aller eingereihten Einfüge-, Änderungs- und Löschoperationen enthält. Dieser Set wird dann zum nächsten Kindknoten weitergegeben, welcher die Ergebnisse seiner Operationen hinzufügt. Dieser Set wird von Eltern- zu Kindknoten weitergereicht, bis der finale Knoten erreicht wurde. Diese Art der Abarbeitung erzeugt eine Art Pipelining Effekt, welcher Performance Vorteile in der Ausführung mit sich bringt [Red14].

Abgesehen von den oben aufgeführten neuen Konzepten bietet der neue Algorithmus eine Vielzahl von weiteren Möglichkeiten zur Optimierung. Somit sollte JBoss Drools in absehbarer Zeit die Inferenz weiter verbessern können.

Performance Messung

Eine Messung eines JBoss Entwicklers, auf welchem der nachfolgende Abschnitt und alle Messergenisse basieren [Smet14], zeigt eine deutliche Reduzierung der Laufzeiten in den meisten Fällen. Hierzu wurden nachfolgend 4 Beispiele der JBoss Software OptaPlanner mit beiden Rule-Engines (PHREAK / ReteOO) laufen gelassen, um eine adequate Aussage über die Laufzeiten treffen zu können. Die getesteten Beispiel sind in OptaPlanner unter den folgenden Namen zu finden:

  • Course scheduling
  • Exam scheduling
  • Hospital bed planning
  • Nurse rostering

Die Ausführung der Beispiele wurde jeweils auf dem gleichen System mit einer Gesamtanzahl von 39 Datensätzen durchgeführt. Alle Beispiele nutzen "Stateful Drools sessions" und haben im Schnitt eine Laufzeit von mehr als 5 Minuten. Beide Varianten wurden auf den identischen Drools 6.0 Versionen ausgeführt. Der einzige Unterschied ist die Definition der zu nutzenden Rule-Engine, welche via kieBaseConfiguration.setOption(RuleEngineOption.PHREAK/RETEOO) eingestellt wurde.

Die Übersicht der Messungen zeigt, dass in 3 von 4 Fällen eine Reduzierung der Laufzeit um ca. 20% möglich ist. Der vierte Fall welcher auf den ersten Blick langsamer geworden ist würde je größer die Datensatzmenge ist auch schneller werden. Dieser skaliert also mit der Menge der Datensätze. Nachfolgend eine Übersicht, welche von [Smet14] übernommen wurde:

Durchschnitt pro Usecase (über alle Datensätze pro Usecase):

  • Course scheduling: PHREAK ist 20% schneller als ReteOO
  • Exam scheduling: PHREAK ist 21% schneller als ReteOO
  • Hospital bed planning: PHREAK ist 4% langsamer als ReteOO
  • Nurse rostering: PHREAK ist 20% schneller als ReteOO

Die einzelnen Feinheiten der Messungen können unter folgendem Link nachgelesen werden.

Vergleich

In diesem Kapitel sollen übergreifend die Rule-Engines verglichen werden, um einen leichten Überblick ermöglichen zu können. Hierzu dienen als Basis die vorherigen Abschnitte und einige weitere Recherchen, welche gesondert per Quelle angegeben werden.

Rule-Engine Lizenz Temporale Aspekte Mächtigkeit Möglichkeit im "then"-Teil Regelmengenwechsel nach bestimmten Zeitpunkten oder Aktionen Änderungen am Rechtemodell möglich (Modewechsel)
JBoss Drools Apache License 2.0 JBoss Drools bietet umfangreiche Möglichkeiten, um zeitliche Aspekte innerhalb der Regeln zu berücksichtigen. Es sind sowohl zeitliche Abfolgen (Regel A nach B oder Regel A während Regel B uvm.), als auch Zeitdauern und zeitliche Wiederholungen definierbar. Genauere Informationen finden sich hier [Anm. 1] +++ (unbegrenzt) Jeder beliebige Java-Quellcode kann ausgeführt werden. Außerdem stehen Funktionen zur Veränderungen der Wissensbasis zur Verfügung. Ja Ja
ProSyst HAM (QIVICON Rule-Engine) - Der HAM bietet von Haus aus einen periodischen Timer an. Es gibt jedoch die Möglichkeit durch erstellen einer Unterklasse von ITimer neue Timer hinzuzufügen. ++ (via Umwege unbegrenzt) Durch die Möglichkeit den HAM via Java-Quellcode zu steuern, kann theoretisch jeder beliebige Java-Quellcode ausgeführt werden. Es gibt die Möglichkeit mehrere "Condition Provider" vorzuhalten und diese dann als aktiven zu registrieren. Siehe [Anm. 2] Nein
openHAB Eigenbau Eclipse Public License (EPL) Durch den Einsatz von Quartz und Joda Time ist es möglich feingranulare zeitliche Interaktionen in die Regeln zu integrieren. Beispielsweise ist es möglich Timer zu definieren, nach welchen eine bestimmte Interaktion ausgeführt wird. Auch gibt es die Möglichkeit, eine Cronjob ähnliche Syntax zu verwenden, um Aktionen in bestimmten zeitlichen Abständen wiederkehrend auszuführen. - (eingeschränkt) Eine fest definierte Menge von Befehlen werden unterstützt. Siehe [Anm. 3] Nein Nein
  1. http://docs.jboss.org/drools/release/5.2.0.CR1/drools-fusion-docs/html/ch02.html
  2. http://dz.prosyst.com/pdoc/mBS_SH_SDK_7.5/modules/automationengine/developer/extend/develop_condition_type/overview.html
  3. https://github.com/openhab/openhab/wiki/Actions

Zusammenfassung

Das Kapitel der Regelengine Vergleiche hat gezeigt, dass es bedeutende Unterschiede in den diversen Regelengines gibt. Die Frage des Funktionalitätsumfangs und das Einsatzgebiet der Regelengine sollte jedoch weiterhin der Fokus sein. Eine Regelengine wie JBoss Drools bringt zwar eine riesige Mächtigkeit und ein großes Einsatzgebiet mit sich, jedoch kann es für bestimmte Anwendungskontexte (siehe openHAB) durchaus relevant sein diesen Moloch von Regelengine passend zu ersetzen.

Der ProSyst Home Automation Manager stellt für ein Projekt wie die QIVICON oder ein Endgerät wie das MR5102 einen durchaus guten Mittelweg dar. Eine Vielzahl von Funktionen werden bereits von ProSyst mitgeliefert und können somit ohne große Bedenken und Umschweife eingesetzt werden. Auch eine (zwar nicht sonderlich intiutive) Oberfläche wird direkt von ProSyst mitgeliefert. Die Mächtigkeit von JBoss Drools wird vermutlich in diesem Projektkontext nicht annähernd ausgereizt, sodass eine schlankere Regelengine wie der ProSyst HAM oder der Eigenbau von openHAB durchaus als sinnvoller Gedanke betrachtet werden kann.

Szenario Recherche

In diesem Kapitel werden verschiedene Szenarien zum Thema Smart Home aufgeführt und kurz erläutert. Quellen können hierbei die nachfolgend aufgeführten sein und sind zu jedem Szenario einzeln aufgeführt:

  • Hersteller von Smart Home Systemen oder Komponenten
  • Roadmaps zum Thema Smart Home
  • Veröffentlichungen von Standards
  • Papers über Forschungsergebnisse

Szenarien der Telekom QIVICON

Auf der Telekom QIVICON Seite finden sich drei mögliche Szenarien, welche von der Telekom zu Marketingzwecken dort aufgeführt sind. Diese sind leider nur sehr detailarm beschrieben, jedoch kann man mit den dort aufgeführten Informationen durchaus die dahinterstehende Regelmenge bzw. die Art der Regel erahnen. Nachfolgend finden sich die besagten Szenarien inklusive einer kurzen Erläuterung.

Szenario Sicherheit

Das "Szenaro Sicherheit" beschreibt die Telekom auf der QIVICON Seite wie folgt:

Ein ganz einfacher Anwendungsfall mit einer großen Wirkung für Ihr Sicherheitsgefühl: Statten Sie Ihr Smart Home mit Rauchmeldern und Fenster-/Türkontakten aus. Damit erhalten Sie bei Rauchentwicklung oder beim Öffnen von Fenstern und Türen in Ihrer Abwesenheit eine Benachrichtigung auf Ihr Smartphone.

Um diesen Anwendungsfall zu realisieren benötigt man mindestens drei Komponenten:

  • QIVICON Homebase bzw. den RaspberryPi aus diesem Projekt
  • 1x Türkontaktschalter
  • 1x Rauchmelder

Szenario Büro

Das zweite Szenario der Telekom QIVICON Homepage ist das "Szenario Büro", welches auf den Bereich Energiekosten abzielt. Der hierfür zu findende Werbetext ist der folgende:

Auch für Ihre Geschäftsräume eignet sich Smart Home. Sparen Sie bis zu 30 Prozent Energiekosten! Verbinden Sie ganz einfach die Heizkörper und die Beleuchtung mit Smart Home. Temperatur und Licht lassen sich so automatisch den Öffnungs- oder Geschäftszeiten Ihres Unternehmens anpassen.

Um diesen Anwendungsfall zu realisieren benötigt man mindestens drei Komponenten:

  • QIVICON Homebase bzw. den RaspberryPi aus diesem Projekt
  • 1x Heizkörperthermostat
  • 1x Steckdosenadapter

Szenario Komfort

Das dritte beispielhafte Szenario, welches die Telekom auf der QIVICON Homepage zu Marketingzwecken listet befasst sich mit dem Bereich Komfort und wird daher "Szenario Komfort" genannt. Hier steht die Automatisierung zur Vereinfachung des Lebensalltages im Vordergrund. Der hierzu gehörige Marketingtext ist der folgende:

Machen Sie es sich gemütlich. Mit der Smart Home App, der QIVICON Home Base und einigen Zwischensteckern können Sie alles ganz bequem vom Smartphone steuern. Dann ist der Kaffee schon fertig, bevor Sie in die Küche gehen. Und Ihr Wohnzimmer nach einem anstrengenden Arbeitstag gemütlich geheizt und beleuchtet.

Um diesen Anwendungsfall zu realisieren benötigt man mindestens drei Komponenten:

  • QIVICON Homebase bzw. den RaspberryPi aus diesem Projekt
  • 1x Heizkörperthermostat
  • 1x Steckdosenadapter

Szenarios der VDE-Roadmap

In diesem Abschnitt sollen die zwei Use-Cases der Roadmap zum Thema SmartHome, welche durch den Verband der Elektrotechnik und der Deutschen Kommission der Elektrotechnik veröffentlicht wurde. Unterstützt wurde diese Roadmap durch das Bundesministerium für Wirtschaft und Energie. Diese Roadmap wird somit als Quelle für die nachfolgenden Unterkapitel verwendet und wird daher nicht in jedem Kapitel gesondert aufgeführt. Die Roadmap findet sich hier.

Szenario Raumtemperatur

Dieses Szenario befasst sich mit der Thematik der Raumtemperatur und wird in der Roadmap im Abschnitt 2.6 erläutert. Hierbei geht es um die Beheizung bzw. Kühlung von Räumen durch die Möglichkeiten von SmartHome. Die folgenden benötigten Sensorinformationen sind hierbei direkt aus dem Standard zitiert aufgelistet:

  • Temperaturmessung z. B. je Raum (realisiert durch Sensoren)
  • evtl. Auswertung anderer Sensoren (Fensteröffnung, Präsenzerkennung)
  • Klimaregelung (realisiert durch einen Temperaturregler oder Lüftungsregler)
  • Regelung der Heizung/Lüftung (realisiert durch konnektive Anlagen oder einen oder

mehrere Aktoren)

Auf Basis dieser Informationen kann dann die Regelung der Temperatur bzw. die dazu benötigten Interaktionen durchgeführt werden.

Szenario "smarte" Waschmaschine

In diesem Szenario beschreibt die Roadmap die "smarte" Waschmaschine, welche nach erfolgreicher Initialkonfiguration (Waschpulver einfüllen, Wäsche einladen usw.) auf bestimmte Aspekte achtet. Als Beispiel wird hierfür die folgende Auswahl in der Roadmap geboten:

  • Start der Waschmaschine nach Auswahl der günstigsten Stromtarife
  • Start, damit die Waschmaschine zur gewünschten Endzeit fertig ist
  • Optimierungen anhand von Umweltaspekten (bspw. wenn eine Solaranlage auf dem Dach ist, dann macht es Sinn diesen Strom zu verwenden und daher in der Mittagszeit zu waschen)

Außerdem kann die Waschmaschine basierend auf den gegebenen Informationen für den Nutzer die folgenden Kenngrößen berechnen bzw. vorhersagen. Diese sind laut Roadmap:

  • Geschätzter Stromverbrauch & dazu gehörige Kosten
  • Dauer des Waschgangs
  • Fertigstellung des Waschvorgangs
  • ...

Außerdem ist es möglich, dass die Waschmaschine dem Nutzer für diverse Ereignisse Informationen Nachrichten generiert und diese dem Nutzer via SMS o.Ä. zustellt.

Szenarios aus dem ProSyst mBS Smart Home SDK

In diesem Abschnitt werden die Use Cases, welche im ProSyst mBS Smart Home SDK für das Thema Smart Home aufgeführt sind, vorgestellt.. Diese sind alle aus folgender Quelle, welche daher nich in den Unterkapiteln aufgeführt wird. Hierbei ist zu beachten, dass dies keine expliziten Use Cases sind sondern lediglich kurze Beschreibung wie das SDK genutzt werden kann. Diese dienen in Ihrer Form jedoch trotzdem als Veranschaulichung des Themas Smart Home.

Szenario "Home Monitoring"

In diesem Abschnitt beschreibt ProSyst eine Funktion, welche das Haus bzw. die Wohnung schützen sollen. Im Detail handelt es sich hierbei um eine Art Trigger, welche basierend auf erkannten Bewegungen, zerbrochenen Scheiben oder ausgelösten Türsensoren dem Nutzer eine Nachricht zukommen lässt. Dieser kann dann, selbst aus dem Urlaub, die Polizei oder Nachbarn alamarieren um im Haus nach dem Rechten zusehen.

Szenario "Home Automation"

Unter diesem Thema fasst ProSyst die Automatisierung rund um das Zuhause auf. Hierbei ist insbesondere die automatische Aktivierung von Lampen durch die Auslösung von Bewegungssensoren und die automatisierte Regelegung von Lichtern durch verschiedene Auslöser gemeint. Auch beschreibt ProSyst die Möglichkeit der automatisierten Anpassung der Innentemperatur an die gemessene Außentemperatur.

Szenario "Energy Efficiency"

Unter dem Szenario bzw. Abschnitt "Energy Efficiency" beschreibt ProSyst einen ähnlichen Ansatz wie bereits im Roadmap Abschnitt erläutert. Ein Gateway, welches im ProSyst SDK eingebettet ist überwacht den Strompreis und startet dann dynamisch basierend auf dem günstigsten Preis Aktionen. Diese können beispielsweise die Waschmaschine, der Geschirrspüler oder ähnliche Geräte sein, welche nicht zu einem definierten Zeitpunkt laufen müssen.

Szenario "Vacation Homes"

Dieses Szenario beschreibt Möglichkeiten, welche beispielsweise während einem Urlaub durchgeführt werden können. Klingelt der Postbote oder ein Gast an der Türe, so kann der Hauseigentümer das Kamerbild der Türklingelanlage auf seinem Handy sehen und das Gespräch mit der Person aus der Ferne führen. Auch ist es dem Eigentümer möglich die Tür aus der Ferne zu öffnen und demjenigen somit den Zutritt zum Haus zu gewähren.

Der zweite beschriebene Fall in diesem Kontext ist die Wasser-/Stromabschaltung aus der Ferne im eigenen Heim um bei einem signalisierten Wasseraustritt größeren Schaden aus der Ferne vermeiden zu können.

Szenario "Smart Metering"

Dieser Abschnitt befasst sich mit der automatisierten Erfassung von Verbrauchszahlen im gesamten Kontext des Hauses. Diese Daten, wie Strom-, Wasser- oder Gasverbrauch, können genutzt werden um in Analysen Verschwender im Eigenheim feststellen und abstellen zu können. Auch dienen diese Daten als Basis für weitere Automatismen wie beispielsweise die automatische Waschmaschinensteuerung.

Szenario "Smart Grid"

Auch bietet das Smart Home die Möglichkeit automatisch zwischen erneuerbaren Energien, welche man beispielsweise in Form von Sonnenenergie direkt auf seinem Hausdach gewinnen kann und der verlässlichen Energie der Stromkonzerne zu wechseln. Hierdurch kann ohne großen Aufwand automatisch die "kostenlose" selbsterzeugte Energie verwendet werden, sofern diese verfügbar ist. In Zeiten von schlechtem Wetter schaltet das Smart Home automatisch auf die Stromversorgung der Großkonzerne um.

Konzeption

In diesem Abschnitt sollen verschiedene Möglichkeiten zur Definition von Regeln evaluiert werden. Hierzu wurden in den vorherigen Abschnitten bereits die Eingabemöglichkeiten von JBoss Drools, openHAB und dem ProSyst HAM betrachtet. Die Konzepte dieses Masterprojekts werden hierbei so detailnah wie nötig beschrieben, um die Idee leicht aufnehmen zu können. Außerdem soll nach Möglichkeit zu jeder Idee eine Art Vorteile/Nachteile Auflistung erstellt werden. Diese soll als Basis für eine Art "Proof of Concept" dienen, um die Idee evaluierbar zu machen.

Textuelle Eingabe via Editor

In diesem Abschnitt soll die Konzeption einer klassischen Eingabemethode betrachtet werden. Dies ist, ähnlich wie auch in openHAB und JBoss Drools, die klassische Eingabe über einen Texteditor. Hierbei dient die Art der Regeldefinition von openHAB als Basis, da diese (nach der Ersetzung von JBoss Drools) verhältnismäßig einfach geworden ist. Das nachfolgende Beispiel zeigt beispielhaft eine Regel, welche in openHAB definiert werden könnte.

// Entnommen von: [Kreu12]
rule "Turn light on"
    when
        Item Door changed to OPEN
    then
        Light.postUpdate(ON)
end 


rule "Turn on irrigation system after two days without rain"
    when
        Time is midnight
    then
        if(Rain==OFF && !Rain.changedSince(now.minusDays(2))) {
            Irrigation.sendCommand(ON)
        }
end

Diese Art der Regeldefinition könnte als Ausgangspunkt für eine eigene Umsetzung dienen. Die einfache Regeldefinition (erste Regel im Beispiel) kann von der Einfachheit her von einer Vielzahl technikaffiner Anwender verwendet und definiert werden. Einzig bei der Verschachtelung bzw. mehrfachen Auslösung von Aktoren im "then"-Abschnitt der Regel wird selbst ein technikaffiner Anwender ohne Programmierkentnisse an seine Grenzen stoßen. Die Begrenzung auf eine kleine Menge von Aktionen im "then"-Abschnitt macht die Regeldefinition im Vergleich zu JBoss Drools (in dem jeglicher Java Quellcode zulässig ist) zwar einfacher, jedoch ist die Komplexität in diesem Bereich zu hoch.

Eine mögliche Optimierung dieser Eingaben könnte die Möglichkeit sein, die Abschnitte im "then"-Teil näher an die natürliche Sprache heranzuführen. Dies hätte zwar eine Anpassung an jede zu unterstützende Sprache zur Folge, würde jedoch eine Vielzahl neuer Anwender die Möglichkeit bieten die Konfiguration eines Systems durchzuführen. Die komplette Unterstützung der bspw. deutschen Sprache wird aufgrund der Komplexität wohl nicht umsetzbar sein, jedoch sollte eine Untermenge bzw. adaptierte Form der Sprache durchaus realisierbar sein und zum gewünschten Ziel führen. Viele Schlüsselwörter der Sprache (und, oder usw.) lassen sich direkt auf Bausteine der Logik umsetzen und könnten somit fehlerfrei geparst werden. Zwischen diesen "logischen Bausteinen der Sprache" könnten Abfragen (im "when"-Teil) oder Anweisungen (im "then"-Teil) vom Benutzer platziert werden. Eine beispielhafte Regel der deutschen Sprache könnte eventuell wie nachfolgend aufgeführt aussehen:

regeldefinition "Schalte das Licht an" // Freier & unwichtiger Name zur Übersicht für den Benutzer
    wenn sich die Haustüre öffnet // Definition des Auslösers 
    dann schalte die Wohnzimmerlampe an // Definition der Aktion
ende // Ende der Regel

Das oben aufgeführte Beispiel zeigt die Definition einer einfachen Regel in einer Art deutschem Dialekt. Hierbei sind eine Vielzahl von Schlüsselwörtern direkt ein Teil der definierten Syntax meiner Definitionssprache. Diese sind "wenn", "dann" und "an". Die Elemente "Wohnzimmerlampe" und "Haustüre" sind hierbei Namen von Elementen, welche im System registriert sind. In diesem Fall also eine Lampe bzw. ein Steckdosenschalter und ein Kontaktschalter an der Haustüre. Diese können vom System durch Xtext Definitionssyntax direkt gefunden werden. Durch die Gegebenheit der deutschen Sprache bekommt man eine Vereinbarung nahezu gratis, dass im "dann"-Abschnitt hinter einem schaltbaren Element immer die Aktion notiert ist (Wohnzimmerlampe an bzw. Wohnzimmerlampe aus). Nachfolgend findet sich ein Beispiel mit verknüpften Interaktionen, welche ähnlich zum vorherigen Beispiel vermutlich nahezu problemlos verarbeitet werden können, da auch hier auf die Syntax der Schlüsselwörter geachtet wurde.

regeldefinition "Rasenwässerung" // Freier & unwichtiger Name zur Übersicht für den Benutzer
    wenn 0 Uhr und Regensensor aus // Definition des Auslösers 
    dann schalte den Rasensprenkler an // Definition der Aktion
ende // Ende der Regel
Vorteile (+) Nachteile (-)
- direkte Übersicht über die Regeln - Vielzahl von Anpassungen notwendig bei Internationalisierung der Plattform
- simple Umsetzung via DSL - eventuelle Probleme bei sprachlichen Hürden
- einigermaßen großer Nutzerkreis
- große Mächtigkeit der Ausdrücke möglich

Logischer Verschaltungsplan

Beispielhafte Umsetzung des Verschaltungsplans.

In diesem Abschnitt soll die Definition von Regeln anhand eines logischen Verschaltungsplanes (ähnlich der Programmieren von SPS Elementen) aufgezeigt werden. Dies wäre für einen erfahrenen Programmierer in diesem Bereich eine logisch nachvollziehbare und leicht machbare Möglichkeit um die Hausautomatisierung zu definieren. Basierend auf dem vom Anwender erstellten Schaltungsplan könnten durch die definierten Elemente (UND, ODER usw.) in Verbindung mit steuerbaren Elementen (Schaltern usw.) leicht Regeln für das auszuführende System generiert werden.

Hierbei muss bedacht werden, dass jede Regel somit eine eigene Veschaltung über eine beliebige Menge von Elementen ist. Diese könnte der Einfachheit halber in einem eigenen Schaltplan dargestellt werden. Dies würde ein Problem der Übersichtlichkeit der Regeln hervorrufen, welches durch eine globalere Sicht der Regeln ausgeglichen werden muss. Hierzu könnte dem Anwender/Programmierer ein gesamter Schaltplan gezeigt werden, außerdem wäre es sinnvoll ihm eine Übersicht sortiert nach den einzelnen schaltbaren Elementen zu bieten. Dies würde dem Programmierer ausreichend Übersicht über sein aktuell laufendes System geben.

Vorteile (+) Nachteile (-)
- Saubere Übersicht über die Regeln - (Stark) eingeschränkter Nutzerkreis
- Leichte Umwandlung vom Schaltungsbild in Regeln für das System - Hohe Einstiegshürde für neue Anwender
- Erneute Konfiguration benötigt einen (eventuell teuren) Technikereinsatz für Anwender ohne Kenntnisse
- Eingeschränkte Mächtigkeit durch die Elemente der Verschaltung

Sprachliche Eingabe

Diese Idee bzw. dieser Abschnitt basiert auf einem Kickstarter Projekt, welches ich durch Zufall (Link) entdeckt habe. Der Gedanke bzw. die erste Umsetzung erfolgte als Hochschulprojekt in Holland und wird nun nach 3 Jahren Entwicklungsarbeit via Kickstarter zu einem Produkt für die breite Allgemeinheit gebracht.

Als Basis der Spracherkennung und Umsetzung von Interaktionen dient die Spracherkennungssoftware von Google. Diese Umsetzung von Regeldefinition sollte von nahezu jedem verwendbar sein, weswegen es aus aktueller Sicht die perfekte Defintion von Regeln darstellt. Zur Sicherstellung der korrekten Eingabe von Regeln dient ein Bildschirm (bzw. eine App), welche das Ergebnis der Definition dem Anwender zur Kontrolle vorlegt. Ein Video zur Demonstration der Mächtigkeit dieser Eingabemethode findet sich hier.

Die Umsetzung einer Regeldefinition bietet viel Potential zur Verbreitung in den Endkundenmarkt, birgt jedoch auch eine Vielzahl von Probleme. Unsauber Ausgesprochene Sätze oder Dialekte der Sprachen benötigen besondere Aufmerksamkeit und müssen in mühevoller Kleinarbeit perfektioniert werden. Auch ist eine Anpassung der Software in einer Vielzahl von Fällen der Portierung notwendig. Soll das System also in weiteren Ländern mit der Muttersprache vermarktet werden, muss die erkannte Sprache der Google Spracherkennungssoftware erst auf die darunterliegende Regelengine bzw. Ausführungsebene umgemünzt werden. Eine Abhilfe könnte hierbei die Umsetzung in der englischen Sprache bringen, welche weit über den Globus verbreitet ist.

Die Idee der sprachlichen Eingabe könnte somit eine Art "erzählerische Form" der oben aufgeführten deutschen Editor Syntax sein. Regeln könnten somit mit einfachen Kommandos wie "Wenn ich nach Hause komme und es dunkel ist, dann schalte die Wohnzimmerlampe an" definiert und vom System verarbeitet werden.

Vorteile (+) Nachteile (-)
- Nahezu jeder Mensch ist ein potentieller Nutzer - Erkennungsprobleme der Sprache beeinflussen die Nutzerzufriedenheit
- Einfachste Umsetzung einer Regeldefinition - Falschinterpretationen der Spracherkennung könnten ungewollte Aktionen ausführen
- Keine Lernhürde zur Definition von Regeln - Hoher Anpassungsaufwand der Plattform bei Unterstützung von neuen Sprachen

Weboberfläche (Webapp)

Beispielhafte Umsetzung der Website/Webapp.

In diesem Abschnitt soll die Definition von Regeln in einer Weboberfläche bzw. Webapp betrachtet werden. Diese wird vergleichbar vom ProSyst HAM angeboten und könnte ähnlich umgesetzt werden. Einzig die Darbietung der Oberfläche sollte überarbeitet werden, da diese selbst für erfahrene Nutzer viele Fragen aufwerfen wird. Eine vereinfachte Homepage, welche dann auch auf mobilen Endgeräten bedient werden kann, sollte klare Strukturen und prägnante Namen aufweisen. Nachfolgend sind drei Screenshots der Oberfläche des ProSyst SDK HAM beispielhaft gezeigt:

Basierend auf diesen Definitionsoberflächen wurden die nachfolgenden Konzeptionen für eine eigene Oberfläche entworfen. Diese wird einmal als normale Website und einmal als angepasste Webapp für das Smartphone, welche heutzutage eine hohe Verbreitungsrate genießt präsentiert. Diese bietet einfache Kontextmenüs zum hinzufügen/löschen von neuen Eingabeparametern und daraus resultierenden Aktionen des Systems. Das nebenstehende Bild zeigt beispielhaft eine Smartphone Webapp Ansicht zur Definition einer Regel zur Lichsteuerung.

Vorteile (+) Nachteile (-)
- Definition von Regeln am "Zahn der Zeit" - Bei verschachtelten Regeln möglicherweise unübersichtlich
- Zugriff über jede Art von Gerät möglich
- Schnelle Anpassungen von Regeln

Installation/Einrichtung der Arbeitsumgebung

OSGi Entwicklungsumgebung mit ProSyst SDK

Vor Beginn/Durchführung dieser Installationsanleitung muss "Eclipse for RCP and RAP Developers" der Version (4.3.2) SR2 heruntergeladen und entpackt werden.

Installation ProSyst SDK

  1. Entpacken des mBS-SH_SDK_7.4.1_e.zip
  2. Setzen der Ausführungsrechte auf der Datei "startinstall" (Konsolenbefehl: chmod +x startinstall)
  3. Ausführen der Datei "startinstall" (Konsolenbefehl: ./startinstall)
  4. Navigieren durch die sich öffnenden Menüs, bis der Installationsprozess vollzogen wird (Anmerkung: Der Lizenzschlüssel befindet sich in einer sn.txt in dem entpackten Ordner)

Installation ProSyst Eclipse Plugins

  1. Starten der zuvor heruntergeladenen "Eclipse for RCP and RAP Developers" Software
  2. Navigiere zu "Help" -> "Install new Software" -> "Add"
    1. Name: ProSyst SDK
    2. Location: Pfad zum <smart_home_sdk_home>/eclipse-plugins
  3. Aktivieren des benötigten Smart Home SDK
  4. Durchklicken der Menüs inklusive akzeptieren der Lizenzvereinbarungen & Akzeptieren des "unsigned Content"
  5. Neustart von Eclipse nach Aufforderung
  6. Auswählen des Targetplatformwechsels von Eclipse nach dem Neustart (Popup Fenster)

Einrichtung Eclipse

Da das ProSyst SDK maximal Java 1.6 unterstützt, müssen diverse Einstellungen innerhalb von Eclipse überprüft werden, damit sichergestellt ist, dass die gebauten OSGi Applikationen auch lauffähig auf dem OSGi von ProSyst sind. Diese sind alle unter "Window" -> "Preferences" zu finden und müssen wie nachfolgend beschrieben gesetzt sein:

  1. "Java" -> "Installed JREs": Muss auf einem Java 1.6 kompatiblen JRE stehen (Bsp.: java-6-openjdk-amd64 o.Ä.)
  2. "Java" -> "Compiler": Das "Compiler Compliance Level" muss auf 1.6 stehen
  3. "mToolkit": Innerhalb der OSGi Runtime muss der Pfad auf <smart_home_sdk_home>/runtime gesetzt werden
  4. "Plug-in Development" -> "Target Platform": Diese muss auf "mBS Smart Home SDK" stehen.

Starten der ProSyst OSGi Umgebung

Die ProSyst OSGi Umgebung muss auf einer Konsole gestartet werden, welche dauerhaft im Hintergrund geöffnet bliebt. Die auszuführende Datei namens "server" liegt in folgendem Verzeichnis: "<smart_home_sdk_home>/runtime/osgi/bin/vms/jdk". Nach erfolgreicher Ausführung läuft ein ProSyst OSGi Container, welcher über die Konsole administriert werden kann. Beispielhaft kann ein "fw.ls" abgesetzt werden, um alle aktiven Bundles anzuzeigen.

Hier sollte direkt mittels "fw.install iagent.rpc.jar" ein Paket installiert werden, welches für die späteren Verbindungen aus Eclipse heraus benötigt wird. Ob die Installation erfolgreich verlief, lässt sich wieder mit "fw.ls" überprüfen.

Einrichten Eclipse Frameworks View & Console

Sollten die vorherigen Schritte erfolgreich ausgeführt worden sein, so kann nun die Frameworks View innerhalb von Eclipse eingerichtet werden. Diese dient primär dazu den OSGi Container innerhalb der Eclipse Umgebung administrieren zu können. Hierzu sind die folgenden Schritte notwendig:

  1. Sollte die View nicht vorhanden sein, muss diese mittels "Window" -> "Show View" -> "Other" -> "mToolkit" -> "Frameworks" hinzugefügt werden.
  2. Im sich öffnenden "Framework Details" Fenster wird der Haken bei "Auto connect to the remote framework,. after its creation" gesetzt. Anschließend kann das Fenster mittels "OK" geschlossen werden.
  3. Die Framework Ansicht sollte sich nun geöffnet haben (meist unten im Abschnitt der Konsole). Hier können nun die OSGi Bundles inklusive ihrer verschiedenen Details in Erfahrung gebracht werden.
  4. Die Konsole der OSGi Umgebung kann mithilfe eines Rechtsklicks auf <Frameworkname> -> "Show console" zum Vorschein gebracht werden. Diese kann nun äquivalent zur Linux Konsole verwendet werden.

Anmerkung: Die Linux Konsole darf NICHT geschlossen werden, da sonst die OSGi Umgebung geschlossen wird.

Anlegen eines Testprojekts

Mithilfe der nachfolgend aufgeführten Schritte kann ein Eclipse Projekt erzeugt werden, welches dann zum Testen der eben durchgeführten Installation benutzt werden kann:

  1. "File" -> "New" -> "Plug-in Project"
    1. Projectname: de.renedrolshagen.osgiproj
    2. This plug-in is targeted to run with: "an OSGi framework: standard"
  2. 2x "Next"
  3. Auswahl von "Hello OSGi Bundle" -> "Finish"

Nun führt man einen Rechtsklick auf das eben erstellte Projekt -> "Install to" -> <Frameworkname> aus und das eben erstellte Bundle wird erstellt, gepackt und auf die ProSyst Umgebung deployed. In der Consolenansicht (Linux oder innerhalb von Eclipse) sollte nun ein "Hello World!!" sichtbar geworden sein. Ein "fw.ls" sollte das Bundle wie nachfolgend auflisten "<ID> ACTIVE de.renedrolshagen.osgiproj.20140404-091422700".

Installation OSGi Umgebung mit Apache Felix / Eclipse Equinox

Vor Beginn/Durchführung dieser Installationsanleitung muss "Eclipse for RCP and RAP Developers" der Version (4.3.2) SR2 heruntergeladen und entpackt werden.

Installation bndtools

  1. Starten der zuvor heruntergeladenen Eclipse IDE
  2. Navigieren zu "Help" -> "Eclipse Marketplace"
  3. Eintragen von "bnd" in die Suchmaske sollte Bndtools als Auswahlmöglichkeit hervorrufen
  4. Anschließend muss der Installationsassistent des Eclipse Marketplace vollständig durchlaufen werden
  5. Nach einem Neustart der IDE ist die Installation von bndtools abgeschlossen

Download Java 7 JDK

  1. Herunterladen des aktuellen JDK (jdk-7u51) von der offiziellen Oracle Seite
  2. Entpacken des JDK's in ein beliebiges Verzeichnis

Installation von GEF

Bevor Drools in Eclipse installiert werden kann, muss das GEF (Eclipse Graphical Editing Framework) installiert sein. Dies kann über "Help" -> "Install new Software" -> "Add" mit der Site "http://download.eclipse.org/tools/gef/updates/releases/" nachinstalliert werden.

Installation JBoss Drools

  1. Die Drools Daten können mithilfe von folgender Site heruntergeladen werden: http://download.jboss.org/drools/release/6.0.0.Final/org.drools.updatesite/
  2. Anschließend muss zu "Window" -> "Preferences" -> "Drools" -> "Installed Drools Runtime" -> "Add" navigiert werden
  3. Nach dem Klick auf "Create a new Drools 6 Runtime ..." muss ein Installationsverzeichnis ausgewählt werden.
  4. Nach einigen Sekunden ist die Runtime installiert und Drools einsatzbereit!

Einrichtung

Nach der erfolgreichen Installation von bndtools, muss diese Eclipse Erweiterung noch konfiguriert und eingerichtet werden. Hierzu wird einfach ein Bndtools OSGi Project erstellt. Anschließend öffnet sich vollautomatisch das Konfigurationsmenü für das OSGi Plugin Repository. Folgende Einstellungen werden in dem Menü gemacht:

  1. Erste Seite:
    1. Setup: "Create a configuration project (recommend)"
    2. Location: "Create in Eclipse Workspace"
  2. Zweite Seite:
    1. Select Template: "Bundle-Hub Configuration"

Weiterführend kann das Bndtools Tutorial (http://bndtools.org/tutorial.html) durchgearbeitet werden um die Grundzüge der Eclipse Erweiterung leicht verstehen zu können.

Sumitomo MegaBit Gear MR5102

Hardware

Die nachfolgende Hardwareauflistung wurde mittels SSH direkt aus dem Linux herausgelesen.

Prozessor: Marvell PJ4Bv7 Processor rev 1 (v7l) @ 797.90 MHz

Arbeitsspeicher: 503752 kB

Netzwerk: 100/1000Mbit/s (2 ports)

Speicher:

Filesystem 1K-blocks Benutzt Verfügbar Benutzung in % Mount
none 8192 164 8028 3% /var/log
none 8192 0 8192 0% /mnt
none 8192 96 8096 2% /dev
tmpfs 32768 0 32768 0% /dev/shm
ubi2_0 50720 112 47920 1% /tmp/config
ubi1_2 230380 100 225444 1% /osgi/cache
ubi1_0 137468 32 132600 1% /mnt/tmpf1
ubi1_1 137468 32 132600 1% /mnt/tmpf2

Funktionsumfang

Folgende Funktionen stellt der MR5102 bereit:

  • IPv4
  • ARP
  • IPv4 Router
  • NAPT Router
  • DHCPv4 Client
  • DHCPv4 Server
  • DNS Resolver
  • DNS Proxy
  • RTC
  • SNTP Client
  • Manual Adjustment
  • JavaVM (Oracle CDC1.1.2 based on Java SE1.4.2)
  • OSGi Framework (Prosyst mBS Smart Home 7.1 based)
  • MicroSD Data Backup
  • TR-069
  • SSH2
  • Web UI
  • Firmware Upgrade (TR, USB)
  • Firmware Duplication on Flash
  • Configuration Backup and Restore
  • Initialization
  • Log Backup
  • Automatic Reboot on OS Hang Up
  • Selftest on Boot Up

Konfiguration

Die Inbetriebnahme des Sumitomo MegaBit Gear MR5102 gestaltet sich insofern relativ einfach, dass es über ein Webinterface verfügt, welches nach dem Bootvorgang unter der 192.168.2.1 erreichbar ist. Insofern diese IP nicht durch den Heimrouter verwendet wird und sich im gleichen Subnetz des zugreifenden PCs befindet wird das Passwort 01234567 benötigt, um sich am Webinterface anzumelden. Nun stehen dem Anwender eine Vielzahl von Optionen zur Verfügung, welche der MegaBit Gear MR5102 bietet. Diese sind nachfolgende aufgeführt:

  • WAN Konfiguration
  • LAN Konfiguration
  • Datums/Zeit Einstellungen
  • diverse Backup und Reset Optionen
  • Firmware Updates via Webinterface
  • Konfiguration des installierten DHCP Servers
  • Anzeigen der installierten Bundles inklusive deren Status

Alle aufgeführten Einstellungen können direkt über das Webinterface verwaltet werden und sind dann nach maximal einem Neustart aktiv.

OSGi Bundles

Verpacken von OSGi Bundles

Diese kurze Anleitung soll dazu dienen Bundles zusammen zu fassen.

Importvorgang von Bundles:

  1. Erstelle ein neues Plugin-Projekt via: "File-> New -> Project -> Plug-in Development -> Plug-in from Existing JAR Archives"
  2. Wähle die OSGi Bundles, welche im neuen Bundle enthalten sein sollen.
  3. Definiere Name, Bundleversion usw. des neuen Bundles.
  4. Entferne den Haken bei "Unzip the JAR archive into the project" (vermeidet das entpacken von unnützen Klassen)
  5. Drücke "Finish"

Exportvorgang von Bundles:

  1. Wähle das zu exportierende Bundle und navigiere zu "File -> Export -> Plug-in Development -> Deployable plug-ins and fragment"
  2. Entferne den Haken bei "Export source", sofern dieser gesetzt ist.
  3. Definiere den Speicherort des neu erstellten Bundles
  4. Drücke "Finish"

Deployen von OSGi Bundles

Via Eclipse ProSyst Plugin

Ein anderer Weg zum deployen von Bundles ist das Eclipse Plugin von ProSyst zu verwenden. Hierzu ist es vorher notwendig via Telnet & microSD Karte (siehe vorheriger Abschnitt) das ProSyst Bundle "iagent.rpc.jar" zu deployen. Dieses befindet sich in der ProSyst SDK Installation unter "<Installationsordner>/runtime/osgi/bundles". Nach erfolgter Installation und Aktivierung des Bundles, kann der MR5102 via Eclipse Plugin verwaltet werden. Dies kann zum weiteren deployen von Bundles und zur allgemeinen Administration der ProSyst OSGi Umgebung genutzt werden.

Via Telnet & microSD

Das deployen von eigenen Bundles auf dem MR5102 wird über die Telnet Konsole gemacht. Hierfür sind die nachfolgend aufgeführten Schritte notwendig:

  1. Verbinden zum MR5102 via Telnet: # telnet <MR5102 IP Address> 10001
  2. Login mit den folgenden Zugangsdaten:
    1. Benutzername: "user"
    2. Passwort: "user"
  3. Die eigentliche Installation von Bundles erfolgt dann mittels: fw>$ install file:/media/aaaa.jar ("aaaa.jar" is bundle file name)
  4. Sollte das Bundle via Netzwerk erreichbar sein, kann auch der folgende Befehl genutzt werden: fw>$ install <Install bundle URI>
  5. Das Starten des Bundles erfolgt dann mittels: fw>$ start <Installed bundle ID>

Beispielhaftes Deployment eines Bundles, nach erfolgtem Telnet Login:

  • fdisk -l
  • mount -t vfat /dev/<name> /media
  • install file:/media/<bundle-name>
  • start <bundle-id>

Sollte das Bundle erfolgreich deployed sein, wird dieses im Cache des MR5102 abgelegt und bei jedem Neustart automatisch ausgeführt.

JBoss Drools Deployment mit Java 1.4

Bestandsaufnahme

Dieser Abschnitt befasst sich mit dem Deployment von JBoss Drools auf den MR5102. Für eine vollständige JBoss Drools Installation sind die folgenden Bundles notwendig:

  • 0 ACTIVE System Bundle
  • 1 ACTIVE javax.servlet
  • 2 ACTIVE fw.osgilib
  • 3 ACTIVE fw.putil
  • 4 ACTIVE fw.db
  • 5 ACTIVE fw.metatype
  • 6 ACTIVE fw.config
  • 7 ACTIVE fw.log
  • 8 ACTIVE fw.http
  • 9 ACTIVE fw.useradm
  • 10 ACTIVE [lazy] fw.usradmex
  • 11 ACTIVE fw.devicem
  • 12 ACTIVE fw.connector
  • 13 ACTIVE fw.prvagent
  • 14 ACTIVE fw.kitman
  • 15 ACTIVE fw.console
  • 16 ACTIVE fw.telnet
  • 17 ACTIVE iagent.ext.rpc
  • 18 ACTIVE iagent.rpc
  • 20 ACTIVE ch.qos.logback.core-1.0.0
  • 21 ACTIVE com.google.protobuf-2.5.0
  • 22 ACTIVE deps-1.0.0
  • 23 ACTIVE xstream-1.4.3-1.4.3
  • 24 ACTIVE javax.inject-1.0.0
  • 25 ACTIVE hibernate-jpa-2.0-api-1.0.1.Final-1.0.1
  • 26 ACTIVE javax.servlet-2.5.0
  • 27 ACTIVE xml-apis-1.3.04-1.3.4
  • 28 ACTIVE antlr-runtime-3.5-3.5.0
  • 29 ACTIVE org.apache.commons.codec-1.4.0
  • 30 ACTIVE poi-3.9-3.9.0
  • 31 ACTIVE poi-ooxml-3.9-3.9.0
  • 32 ACTIVE xmlbeans-2.3.0-2.3.0
  • 33 ACTIVE dom4j-1.6.1-1.6.1
  • 34 ACTIVE org.drools.compiler-6.1.0
  • 35 ACTIVE org.drools.core-6.1.0
  • 36 ACTIVE org.drools.decisiontables-6.1.0
  • 37 ACTIVE org.drools.templates-6.1.0
  • 38 ACTIVE ecj-3.7.2-3.7.2
  • 39 ACTIVE jaxen-1.1.6
  • 43 ACTIVE org.kie.api-6.1.0
  • 44 ACTIVE org.kie.internalapi-6.1.0
  • 45 ACTIVE org.mvel2-2.1.7
  • 48 ACTIVE osgi.cmpn-5.0.0
  • 49 ACTIVE slf4j.api-1.7.2
  • 51 ACTIVE ch.qos.logback.classic-1.0.0
  • 52 ACTIVE javax.xml-1.3.4
  • 53 ACTIVE xpp3_min-1.1.4c-1.1.0
  • 70 ACTIVE poi-ooxml-schemas-3.9-3.9.0

Problemanalyse & Lösung

Nachfolgend finden sich die Namen der Bundles mit Problemen, deren Fehlermeldung und Lösungswege zum ermöglichen des Deployments:

Name des Bundles Status Anpassungen risikobehaftet? Fehler Lösungsweg / Aktuelles Problem
javax.servlet-2.5.0 gelöst Nein Bundle ist schon in Version 4.1.0 vorinstalliert Keine Lösung notwendig. Benötigte Version wird auch exportiert.
javax.xml-1.3.4 gelöst Eventuell "Can't resolve javax.xml : The bundle javax.xml cannot be resolved because requires Execution Environment(s) [J2SE-1.2], which is/are not available in the framework Execution Environment(s) [OSGi/Minimum-1.0,OSGi/Minimum-1.1,OSGi/Minimum-1.2,CDC-1.0/Foundation-1.0,CDC-1.1/Foundation-1.1]", Bundle-RequiredExecutionEnvironment: J2SE-1.2 Nach dem Entfernen der Anforderungen an die OSGi Umgebung (Bundle-RequiredExecutionEnvironment: J2SE-1.2) deployed das Bundle. Dies sollte eigentlich stabil laufen, da die ProSyst Umgebung Java 1.2 erfüllt.
slf4j.api-1.7.2 gelöst Eventuell "The bundle slf4j.api cannot be resolved because requires Execution Environment(s) [J2SE-1.3], which is/are not available in the framework Execution Environment(s) [OSGi/Minimum-1.0,OSGi/Minimum-1.1,OSGi/Minimum-1.2,CDC-1.0/Foundation-1.0,CDC-1.1/Foundation-1.1]", Bundle-RequiredExecutionEnvironment: J2SE-1.3 Nach dem Entfernen der Anforderungen an die OSGi Umgebung (Bundle-RequiredExecutionEnvironment: J2SE-1.3) deployed das Bundle. Dies sollte eigentlich stabil laufen, da die ProSyst Umgebung Java 1.3 erfüllt.
ch.qos.logback.core-1.0.0 gelöst Ja "Can't resolve ch.qos.logback.core : The bundle ch.qos.logback.core cannot be resolved because requires Execution Environment(s) [J2SE-1.5], which is/are not available in the framework Execution Environment(s) [OSGi/Minimum-1.0,OSGi/Minimum-1.1,OSGi/Minimum-1.2,CDC-1.0/Foundation-1.0,CDC-1.1/Foundation-1.1]", Bundle-RequiredExecutionEnvironment: J2SE-1.5 Nach dem Entfernen der Anforderungen an die OSGi Umgebung (Bundle-RequiredExecutionEnvironment: J2SE-1.5) deployed das Bundle. Dies könnte zu Problemen führen (!!), da die OSGi Umgebung von ProSyst nur Java 1.4 bereitstellt.
ch.qos.logback.classic-1.0.0 gelöst Ja "Can't resolve ch.qos.logback.classic : The bundle ch.qos.logback.classic cannot be resolved because requires Execution Environment(s) [J2SE-1.5], which is/are not available in the framework Execution Environment(s) [OSGi/Minimum-1.0,OSGi/Minimum-1.1,OSGi/Minimum-1.2,CDC-1.0/Foundation-1.0,CDC-1.1/Foundation-1.1]", Bundle-RequiredExecutionEnvironment: J2SE-1.5 Nach dem Entfernen der Anforderungen an die OSGi Umgebung (Bundle-RequiredExecutionEnvironment: J2SE-1.5) deployed das Bundle. Dies könnte zu Problemen führen (!!), da die OSGi Umgebung von ProSyst nur Java 1.4 bereitstellt.
ecj-3.7.2 gelöst Ja Benötigt "javax.annotation.processing", "javax.lang.model", "javax.lang.model.element", "javax.lang.model.type", "javax.lang.model.util" und "javax.tools", welche laut Java Dokumentation erst ab Java 1.6 verfügbar sind (Quelle, Quelle, Quelle, Quelle, Quelle). Die benötigten Pakete aus Java 1.6 werden von dem OSGi Bundle "deps 1.0.0" vorgetäuscht.
dom4j-1.6.1-1.6.1 gelöst Eventuell "javax.swing" fehlt (eigentlich ab Java 1.2 verfügbar) Wird normalerweise von der OSGi Umgebung bereitgestellt. In der ProSyst Dokumentation findet sich nichts und ich vermute, dass ProSyst kein grafischen Oberflächen macht weswegen die Klassen nicht angeboten/exportiert werden. Vortäuschen der OSGi Bundles durch das Dummy Bundle "deps 1.0.0" mit der Hoffnung, dass nie ein Aufruf auf diese Referenz gebraucht wird.
xstream-1.4.3-1.4.3 gelöst Eventuell "javax.security.auth" fehlt (eigentlich ab Java 1.4 verfügbar). Ist außerdem abhängig von dom4j-1.6.1-1.6.1 Das Paket ist eigentlich ein Teil normaler Umgebungen, jedoch wohl nicht Teil der ProSyst Umgebung. Das Paket wird nun vom OSGi Bundle "deps 1.0.0" vorgetäuscht in der Hoffnung, dass dies glatt geht.
poi-ooxml-schemas-3.9-3.9.0 ungelöst "javax.imageio" fehlt (eigentlich ab Java 1.4 verfügbar) und weitere Abhängigkeitsfehler, welche sich nicht auflösen lassen.
poi-3.9-3.9.0 ungelöst "javax.imageio" fehlt (eigentlich ab Java 1.4 verfügbar) und weitere Abhängigkeitsfehler, welche sich nicht auflösen lassen.
poi-ooxml-3.9-3.9.0 ungelöst "org.apache.xmlbeans.impl.xb.xmlschema" wird als fehlend angeprangert, welches eigentlich vom OSGi Bundle xmlbeans-2.3.0 bereitgestellt wird.,
hibernate-jpa-2.0-api-1.0.1.Final-1.0.1 gelöst Eventuell "javax.sql" fehlt (nicht verfügbar) Download von jdbc-se2.0.jar und Manipulation des Manifest, damit das benötigte javax.sql auch exportiert wird.
xmlbeans-2.3.0 gelöst Nein "javax.xml.stream" fehlt (nicht verfügbar) Nachinstallation von stax-api-1.0.1, welches die benötigte Klasse zur Verfügung stellt.


TODO: 
org.drools.compiler-6.1.0
org.drools.core-6.1.0
org.drools.decisiontables-6.1.0
org.drools.templates-6.1.0
org.kie.api-6.1.0
org.kie.internalapi-6.1.0

Der Versuch die Bundles auf dem MR5102 lauffähig zu bekommen wurde mit dem vorher beschriebenen Stand abgebrochen, da das System bereits zu diesem Zeitpunkt mehr als instabil schien. Es wurde eine aktualisierte Firmware bei Sumitomo Electric Networks angefragt. Die Updateanweisungen und die daraus resultierenden Ergebnisse für das Projekt sind in den folgenden Abschnitten aufgeführt.

JBoss Drools Deployment mit Java 1.6

Auch nach dem durchgeführten Update der Java Version machte die Lösung mit dem Sumitomo MR5102 diverse Probleme im Bereich des Deployments. Daher wird diese Plattform nicht weiter verfolgt und die Entwicklung ausschließlich auf dem Raspberry Pi weitergeführt.

Firmwareupdate

In diesem Abschnitt soll das Firmware Update des MR5102 näher beschrieben werden. Das von Sumitomo Electric Networks bereitgestellte Firmwareupdate betrifft eigentlich das japanische Modell des MR5102, soll jedoch mit einigen Abwandlungen auch auf dem europäischen MR5102 lauffähig sein. Hierzu wurde die folgende Updateanweisung bereitgestellt:

  1. Erstellen eines Backups der IP-Addresse, Zeitzone u.Ä. mithilfe des Backup Assistenten in der Weboberfläche
  2. Aufbau einer SSH Verbindung zum Gerät
  3. Abändern des Wertes innerhalb der "/etc/sysinfo/hardtype" Datei. Dieser wird von "0x080C0000" auf "0x08100000". ACHTUNG: Dieser Schritt ist extremst wichtig - Sollte der Wert nicht geändert worden sein vor dem Update, ist der MR5102 danach unbrauchbar
  4. Upgrade der Firmware über die Weboberfläche

Notizen:

  • Nach dem Update der Firmware ist die Weboberfläche auf dem Port 8080 (nicht wie bisher auf 80)
  • Sollte nach dem Firmware Update ein Factory Reset gemacht werden besitzt der MR5102 danach die 192.168.173.1 als IP-Addresse. Die vorherige 192.168.2.1 ist hinfällig.
  • Der SSH Zugang ist nurnoch mittels eines Schlüsselpaares als User "guest" möglich
  • Das Passwort um per SSH zum Root ("su") zu werden lautet nach dem Update: "mr5102root"
  • Ein Verbindungsaufbau via Telnet auf dem TCP Port 10001 ist ausschließlich über den LAN-Port möglich

Raspberry Pi

Die nachfolgenden Abschnitte befassen sich mit der Plattform Raspberry Pi, der Installation eines Raspbian Betriebssystems und dem Deployment einer ProSyst OSGi Umgebung inklusive der JBoss Drools Bundles. Dies wurde durchgeführt, um eine alternative Plattform zum MR5102 zu haben.

Hardware

Als Basis für diesen Abschnitt und die folgende Installation dient der Raspberry Pi in der Modellvariante B. Dieser hat die nachfolgenden Leistungsdaten:

Attibut Raspberry Pi Modell B
Größe: Kreditkartengröße 85,60 mm × 56 mm × 21 mm
System-on-a-Chip (SoC): Broadcom BCM2835
CPU: ARM1176JZF-S (700 MHz)
GPU: Broadcom VideoCore IV
Arbeitsspeicher (SDRAM): 512 MB
USB-2.0-Anschlüsse: 2 (über integrierten Hub)
Videoausgabe: FBAS, HDMI
Tonausgabe: 3,5-mm-Klinkenstecker (analog), HDMI (digital)
Nicht-flüchtiger Speicher: Kartenleser für SD (SDHC und SDXC)/MMC/SDIO
Netzwerk: 10/100-MBit-Ethernet-Controller (LAN9512 des Herstellers SMSC)
Schnittstellen: Bis zu 17 GPIO-Pins, SPI, I²C, UART, EGL
Leistungsaufnahme: 5 V, 700 mA (3,5 Watt)
Stromversorgung: 5-V-Micro-USB-Anschluss (Micro-B), alternativ 4 × AA-Batterien
Betriebssysteme: GNU/Linux, BSD, RISC OS, Plan 9

Installation des Betriebssystems

Die Installation des benötigten Raspbian Betriebssystems funktioniert vergleichsweise einfach in wenigen Schritten. Diese sind:

  1. Download des aktuellen Raspbian Images von http://www.raspberrypi.org/downloads/
  2. Installation des Images auf die SD-Karte:
    1. Windows: Hierzu kann am einfachsten Win32DiskImager genutzt werden. (Download unter: http://sourceforge.net/projects/win32diskimager/)
    2. Linux: Siehe http://www.raspberrypi.org/documentation/installation/installing-images/linux.md
  3. Nachdem das Image erfolgreich auf der SD-Karte installiert ist, kann diese in den Raspberry Pi gepackt und hochgefahren werden.
  4. Nach ca. 1 Minute kann man das System via SSH erreichen und die restliche Konfiguration über den Assistenten vornehmen.
  5. Sobald die Konfiguration abgeschlossen ist sollte das System aktualisiert werden (via "sudo apt-get update && sudo apt-get upgrade && sudo apt-get dist-upgrade)

Erstellen & Installation einer ProSyst Umgebung

Dieser Abschnitt befasst sich mit der Installation des ProSyst mBS Smart Home SDK auf dem Raspberry Pi. Basis hierfür ist die vollständige Installation des ProSyst SDK auf dem Rechner, von dem aus diese Anleitung durchgeführt wird. Basierend auf dem "normalen" SDK, muss eine Raspberry Pi Erweiterung installiert werden. Diese muss in das Verzeichnis: "<mbs-sh-sdk_installation>\runtime" kopiert werden. Anschließend kann Eclipse gestartet werden.

  1. Erstellen eines neuen Projekts via "File" -> "New" -> "Project"
  2. Anlegen einer "Image Description" Datei via "File" -> "New" -> "Other" -> "Image Description" innerhalb des vorher erstellten Projekts
  3. Ausfüllen der Maske mit den gewünschten Informationen wie Name usw.
  4. Bearbeiten der neu erstellten "Image Description" Datei
    1. Platform Settings: -> "RaspberryPI-Raspbian"
    2. Startup Scripts: -> "JDK"
  5. Im Bundle Abschnitt können nun alle gewünschten Bundles hinzugefügt werden. Eine vollständige Auflistung der benötigten OSGi und JBoss Drools Bundles findet sich auch in diesem Wiki.

Nach erfolgreichem Bearbeiten der "Image Description" Datei kann über den Export Dialog von Eclipse eine lauffähige OSGi Umgebung erzeugt werden. Hierzu wählt man "File" -> "Export" -> "OSGi Image". Das hierdurch erstellte Archiv kann direkt auf den Raspberry Pi kopiert werden. Hierzu sind die folgenden Schritte notwendig:

  1. Entpacken des Archivs
  2. chmod +x <pfad-zum-entpackten-archiv>/osgi/bin/vms/jdk/server
  3. sudo <pfad-zum-entpackten-archiv>/osgi/bin/vms/jdk/server

Danach startet die ProSyst mBS Smart Home Umgebung nach einigen Sekunden und die gewohnte Kommandozeile zur Verwaltung kann genutzt werden.

Inbetriebnahme Telegesis EXTX3USB Coordinator (ZigBee)

Der Telegesis EXTX3USB Coordinator ist ein USB-Stick, welcher auch von der Telekom bei QIVICON vermarktet wird, um ZigBee Geräte anbinden zu können. Dieser USB-Stick wird von ProSyst zur Verwendung empfohlen, da hiermit bereits seit langer Zeit gute Erfahrungen gemacht wurden. Eine Liste von anderweitig einsetzbaren Geräten kann hier gefunden werden. Die Installation des USB-Stick in unserer Raspberry Pi Umgebung gestaltet sich etwas schwieriger und wird daher im folgenden Abschnitt erläutert:

  1. Installation der benötigten Bundles (entnnommen aus der ProSyst mBS Smart Home SDK Dokumentation):
    • Event Admin Bundle: fw.eventadmin.jar
    • The Web Admin Console bundles:
      • fw.web.common.jar
      • fw.remote.jsonrpc.jar
      • org.apache.commons.io.jar
      • org.apache.commons.fileupload.jar
      • org.json.jar
      • fw.web.console.branding.jar
      • org.apache.felix.webconsole.jar
      • org.apache.felix.webconsole.plugins.event.jar
    • The Home Device Manager bundles:
      • Home Device Manager API: hdm.api.jar
      • Home Device Manager Core: hdm.core.jar
      • Home Device Manager Device Classes: hdm.dc.jar
      • Home Device Manager Util: hdm.util.jar
      • Home Device Manager Remote Handler: hdm.remote.jar
      • Home Device Manager Plugin for Web Console: hdm.web.console.plugin.jar
    • The ZigBee Module bundles:
      • ZigBee Core: zigbee.core.jar
      • ZigBee Abstract Driver: zigbee.driver.jar
      • ZigBee Telegesis Driver : zigbee.telegesis.jar
      • ZCL Metadata: zigbee.zcl.metadata.jar
      • ZigBee ZCL Services: zigbee.zcl.services.jar
      • ZCL HVAC Metadata: zigbee.zcl.hvac.jar
      • ZCL Lighting Metadata: zigbee.zcl.lighting.jar
      • ZCL Sensing and Measurement Metadata: zigbee.zcl.sensing.measurement.jar
      • ZCL Closures Metadata: zigbee.zcl.closures.jar
      • ZCL Security and Safety Metadata: zigbee.zcl.security.jar
      • ZigBee Home Automation Profile: zigbee.ha.profile.jar
      • ZigBee Smart Energy Profile: zigbee.se.profile.jar
      • ZigBee HDM Adapter: zigbee.hdm.adapter.jar
  2. Anschließend muss der ZigBee-Stick für die Umgebung konfiguriert werden. Hierzu sind die folgenden Schritte notwendig:
    1. Anschließen des ZigBee-Sticks an den Raspberry Pi
    2. Abfragen der Addresse mittels "dmesg". In den meisten Fällen ist der gesuchte Wert "/dev/ttyUSB0"
    3. Aufrufen des Webinterfaces "<ip/hostname>/system/console". Die benötigten Logindaten sind "admin"/"admin"
    4. Unter "Konfiguration" -> "ZigBee Telegesis Configuration" den Port auf den eben abgefragten Wert setzen (z.B.: "/dev/ttyUSB0")

Nach der Durchführung dieser Schritte sollte der ZigBee USB-Stick komplett konfiguriert sein. Innerhalb des ProSyst mBS Smart Home SDK gibt es ein Demo Projekt, welches zum Testen verwendet werden kann. Dieses befindet sich unter "<pfad_zum_sdk>/runtime/osgi/demo/zigbee". Dieses kann in Eclipse importiert und dann mittels "Install to" direkt auf das Ziel übertragen werden. Nach dem Deployment sollte die ProSyst Umgebung bzw. der ZigBee Stick anfangen nach Devices zu suchen. Sollte keine in der Nähe sein, bricht der Vorgang (meist) mit einer NullPointerException ab. Jedoch startet dieser überhaupt erst, sobald alle Bundles richtig deployed und der Stick richtig installiert wurde. Somit lässt sich aus dem Beginn der Suche schlussfolgern, dass die Installation erfolgreich war.

Für die weitere Arbeit mit dem ZigBee Stick befindet sich in der Weboberfläche eine "Home Devices" Sparte, welche sich zur Übersicht der Konfiguration und zur Anzeige der verbundenen Geräte eignet.

Das hier beschriebene Image wurde während dem Projekt erstellt und liegt unter dem Namen "ZigBee_ProSystPi.zip" bereit.


Notizen:

  • Anzeigen aller möglichen Parameter der Bundles auf der ProSyst mBS Smart Home SDK Konsole: "config.list -p"
  • Reset der kompletten OSGi Umgebung (löscht alle Bundles!): sudo ./server clean

Inbetriebnahme EnOcean USB300 DA

Der EnOcean USB300 DA ist ein USB-Stick, welcher von EnOcean erworben werden kann. Dieser wird komplett vom ProSyst SDK unterstützt und kann verwendet werden, um EnOcean Geräte an das ProSyst SDK anzubinden. Die Installation des USB-Sticks bzw. der benötigten Bundles wird nachfolgend erläutert:

  1. Installation der benötigten Bundles:
    • System Bundle
    • fw.metatype
    • fw.db
    • javax.servlet
    • fw.putil
    • fw.config
    • fw.osgilib
    • fw.usradmex
    • fw.http
    • fw.log
    • fw.devicem
    • fw.useradm
    • fw.connector
    • fw.eventadmin
    • fw.scr
    • fw.prvagent
    • fw.web.common
    • fw.web.console.branding
    • org.json
    • org.apache.commons.fileupload
    • org.apache.commons.io
    • fw.console
    • org.apache.felix.webconsole.plugins.ds
    • fw.kitman
    • org.apache.felix.webconsole
    • fw.telnet
    • org.apache.felix.webconsole.plugins.packageadmin
    • org.apache.felix.webconsole.plugins.event
    • fw.remote.ea.jsonrpc
    • fw.remote.ua
    • fw.remote.jsonrpc
    • fw.web.console.resman
    • fw.web.console.shell
    • fw.web.console.auth.pass
    • hdm.web.console.plugin
    • hdm.api
    • hdm.util
    • hdm.dc
    • hdm.commands
    • hdm.core
    • hdm.remote
    • enocean.api
    • enocean.core
    • enocean.hdm.adapter
    • enocean.json.rpc
    • iagent.rpc
    • iagent.ext.rpc
    • com.prosyst.mbs.usb.os.linux.raspberry_raspbian
    • com.prosyst.mbs.usb
    • com.prosyst.mbs.services.enocean.linux
  2. Anschließend muss der EnOcean-Stick für die Umgebung konfiguriert werden. Hierzu sind die folgenden Schritte notwendig:
    1. Anschließen des EnOcean-Sticks an den Raspberry Pi
    2. Abfragen der Addresse mittels "dmesg". In den meisten Fällen ist der gesuchte Wert "/dev/ttyUSB0"
    3. Aufrufen des Webinterfaces "<ip/hostname>/system/console". Die benötigten Logindaten sind "admin"/"admin"
    4. Unter "Konfiguration" -> "EnOcean USB Driver Configuration" den Port auf den eben abgefragten Wert setzen (z.B.: "/dev/ttyUSB0")

Nach der Durchführung dieser Schritte sollte der EnOcean USB-Stick komplett konfiguriert sein. Für die weitere Arbeit mit dem EnOcean Stick befindet sich in der Weboberfläche eine "Home Devices" Sparte, welche sich zur Übersicht der Konfiguration und zur Anzeige der verbundenen Geräte eignet. Das hier beschriebene Image wurde während dem Projekt erstellt und liegt unter dem Namen "EnOcean_ProSystPi.zip" bereit.

Anbinden von Geräten

In diesem Abschnitt wird der Verbindungsaufbau und die Konfiguration von einzelnen Endgeräten genauer beschrieben. Die Anbindung von diesen Geräten wird in zwei getrennten Unterkapiteln (je nach Technologie) beschrieben.

EnOcean

Das Anbinden von EnOcean Geräten gestaltet sich extrem leicht. Hierzu ist es nur notwendig in der ProSyst mBS Smart Home SDK Web Admin Console im Tab "Home Devices" die Suche zu starten und gleichzeitig am jeweiligen Gerät die Taste zu betätigen. Hierbei kann es von Gerät zu Gerät unterschiedlich sein in welcher Frequenz die Taste betätigt werden muss. Diese ist jedoch immer den beiliegenden Zettelchen beschrieben.

ZigBee

Das Anbinden von ZigBee Geräten gestaltet sich relativ leicht. Hierzu ist es nur notwendig in der ProSyst mBS Smart Home SDK Web Admin Console im Tab "Home Devices" die Suche zu starten und gleichzeitig am jeweiligen Gerät die Taste zu betätigen. Hierbei kann es von Gerät zu Gerät unterschiedlich sein in welcher Frequenz die Taste betätigt werden muss. Daher folgt hier eine Übersicht der von mir verwendeten Geräte und deren Anbindungseigenschaften:


  • Bewegungsmelder: n-mal hintereinander "schnell" den Knopf drücken bis der nachfolgende Text auf der Konsole erscheint:
fw>$ZigBee Device event: com/prosyst/mbs/services/zigbee/added

fw>[0x29,0xf8]      [0x0,0x12,0x4b,0x0,0x1,0xee,0x12,0xa9]


  • Steckdose mit Dimmer-Funktion: n-mal "langsam" den Knopf auf dem Gerät drücken, bis der nachfolgende Text auf der Konsole erscheint:
fw>$ZigBee Device event: com/prosyst/mbs/services/zigbee/added

fw>[0xbf,0xcd]      [0x0,0x12,0x4b,0x0,0x3,0xc9,0xc8,0x3e]

fw>ZigBee attribute report received

fw>NWK Address: [0xbf,0xcd]

fw>IEEE Address: [0x0,0x12,0x4b,0x0,0x3,0xc9,0xc8,0x3e]

fw>Source Endpoint: 0x1

fw>Destination Endpoint: 0x8

fw>Cluster ID: 0x6

fw>Attribute Description: 

fw>	Name: On/Off

fw>	Id: 0

fw>	Type: BOOLEAN

fw>	Value: false

fw>ZigBee attribute report received

fw>NWK Address: [0xbf,0xcd]

fw>IEEE Address: [0x0,0x12,0x4b,0x0,0x3,0xc9,0xc8,0x3e]

fw>Source Endpoint: 0x1

fw>Destination Endpoint: 0x8

fw>Cluster ID: 0x8

fw>Attribute Description: 

fw>	Name: CurrentLevel

fw>	Id: 0

fw>	Type: UNSIGNED_8_BIT_INT

fw>	Value: 0

Entwicklung

Allgemein

UML Klassendiagramm der OSGi Umgebung auf dem prosystpi
UML Klassendiagramm des Simulator Clients

Das Projekt gliedert sich in zwei einzelne Entwicklungsbereiche. Zum einen exitistert die "Serverseite", also die Software welche auf dem Raspberry Pi läuft. Und zum anderen gibt es den Client, welcher sich via einer Socket-Verbindung an diese Serverseite andockt, um die Schaltvorgänge auf dem Simulator vornehmen zu können.

Der größere Teil der Entwicklung ist die Serverseite, welche eine Vielzahl von Aufgaben zu bewältigen hat. Hierzu zählen:

  • Ansprechen/Abfragen der verbundenen Geräte via ProSyst mBS Smart Home SDK
  • Verwalten der Geräte
  • Beheimaten der JBoss Drools Instanz
  • Reasoning über die verfügbaren Fakten + anschließende Auslösung von Interaktionen
  • Bereitstellung der Socket-Verbindung zur Simulatorkommunikation

Ein klassischer Ablauf der Serverseite kann wie folgt beschrieben werden: OSGi Umgebung starten -> Verbinden des ZigBee/EnOcean Sticks -> Verbinden der Geräte -> Suchen der verfügbaren Geräte im Bundle -> Hinzufügen zu JBoss Drools als Java Objekte -> Verwendung der Objekte im Bereich Reasoning

Die Clientseite hingegen ist nur eine Art Addon zur Realisierung eines Simulators, welcher dann via Socket geschaltet werden kann. Der Simulator wird von der Serverseite als Java-Objekt in der JBoss Drools Umgebung bereitgestellt und kann via Getter/Setter Methoden aus der Ferne manipuliert werden.

Sowohl für die Client-, als auch für die Serverseite können auf der rechten Seite Klassendiagramme zur besseren Übersicht der Software gefunden werden.

Probleme/Herausforderungen

In diesem Abschnitt sollen Probleme, welche im Laufe der Entwicklung aufgetreten sind näher beschrieben werden. Hierzu wird für jedes aufgetretene Problem ein Unterabschnitt erzeugt, welcher dann eine ausführliche Fehleranalyse und die dazu gewählte und umgesetzte Lösung enthält.

Generierte Klassen vom ProSyst mBS Smart Home SDK

Problemaufnahme & Analyse

Während der Anbindungsphase des ProSyst mBS Smart Home SDK an JBoss Drools stellten sich einige Problem heraus, welche in diesem Abschnitt genauer beschrieben werden sollen. Das Hauptproblem, welches hierbei zu lösen war ist die Tatsache, dass das ProSyst mBS Smart Home SDK zwar eine Abstrahierung der unterschiedlichen Geräte durchführt, diese jedoch hinter verschiedenen genierten Klassen versteckt. Ein einfaches Beispiel:

Die Klasse "BinarySwitch" abstrahiert die darunter liegenden Geräte, welche die simple "An/Aus" Operation unterstützen. Somit kann der Entwickler jeden beliebigen bspw. Lichtschalter ansteuern ohne sich für das darunterliegende Gerät zu interessieren. Das Problem an diesem Vorgehen ist, dass JBoss Drools zur Compilezeit schon wissen muss, welche Klasse es später als Fakt in der Basis verwenden kann. Das ProSyst mBS Smart Home SDK generiert jedoch erst zur Ausführungszeit (beim Verbinden des Geräts) eine Instanz von folgender Klasse: "generated.com.prosyst.mbs.services.hdm.deviceclasses.BinarySwitch". JBoss Drools erwartet jedoch ein Objekt der Klasse "com.prosyst.mbs.services.hdm.deviceclasses.BinarySwitch". Auch wenn die darunterliegenden Klassen komplett identisch sind, kann JBoss Drools mit diesen generierten Klassen nicht umgehen und wirft eine Exception.

Lösung

Die Lösung des Problems stellt eine Wrapperklasse für jedes HomeDevice dar. Hierbei wurden für jedes zu verwendende Gerät Klassen geschrieben, welche als privates Attribut die generierten ProSyst mBS Smart Home SDK Klassen enthalten. Diese Klassen sind identisch mit der ProSyst mBS Smart Home SDK API und reichen lediglich die Aufrufe an das gekapselte Objekt weiter.

JBoss Drools bekommt somit ein Objekt vom Typ "BinarySwitchWrapper", welches zur Compilezeit bekannt ist und die generierten Objekte abstrahiert. Hierauf führt JBoss Drools die Operationen aus, welche innerhalb der Klasse transparent an das generierte Objekt des ProSyst mBS Smart Home SDK weitergereicht werden. Auch Fehler, Exceptions und Rückgabewerte werden transparent durchgereicht und verhalten sich entsprechend der ProSyst mBS Smart Home SDK API.

Nachfolgend findet sich ein Beispiel für eine Wrapperklasse:

 
package de.renedrolshagen;

import com.prosyst.mbs.services.hdm.HomeDeviceException;
import com.prosyst.mbs.services.hdm.deviceclasses.MultiLevelSwitch;

/**
 * A wrapper class for the MultiLevelSwitch defined in the ProSyst mBS Smart Home SDK For the documentation of the functions and attributes please visit the SDK documentation which is available under:
 * http://dz.prosyst.com/pdoc/mBS_SH_SDK_7.5/modules/hdm/api/index.html
 */
public class MultiLevelSwitchWrapper {
	private MultiLevelSwitch obj;
	private int cacheLevel;
	private int cacheStep;
	public static final String OPERATION_STEP_DOWN = "stepDown";
	public static final String OPERATION_STEP_UP = "stepUp";
	public static final String PROPERTY_LEVEL = "level";
	public static final String PROPERTY_STEP = "step";
	public static final String TYPE_VALVE = "valve";

	public MultiLevelSwitchWrapper(MultiLevelSwitch inObj) throws HomeDeviceException {
		this.obj = inObj;
		this.cacheLevel = inObj.getLevel();
		this.cacheStep = inObj.getStep();
	}

	public void setLevel(int level) throws HomeDeviceException {
		this.cacheLevel = level;
		this.obj.setLevel(level);
	}

	public int getLevel() throws HomeDeviceException {
		return this.cacheLevel;
	}

	public int getStep() throws HomeDeviceException {
		return this.cacheStep;
	}

	public void stepDown() throws HomeDeviceException {
		if ((this.cacheLevel - this.cacheStep) > 0) {
			this.cacheLevel = this.cacheLevel - this.cacheStep;
			this.obj.setLevel(this.cacheLevel);
		} else {
			this.cacheLevel = 0;
			this.obj.setLevel(this.cacheLevel);
		}
	}

	public void stepUp() throws HomeDeviceException {
		if ((this.cacheLevel + this.cacheStep) < 255) {
			this.cacheLevel = this.cacheLevel + this.cacheStep;
			this.obj.setLevel(this.cacheLevel);
		} else {
			this.cacheLevel = 255;
			this.obj.setLevel(this.cacheLevel);
		}
	}

}

Abarbeitungseigenschaften von JBoss Drools

Problemaufnahme & Analyse

JBoss Drools führt eine erneute Evaluation der Regeln nur durch, wenn sich an der Faktenbasis etwas verändet hat. Hier liegt das Problem in meiner Entwicklung, da durch das Bearbeiten von Eigenschaften auf einem Objekt die Faktenbasis nicht verändert wird. Eine Veränderung wäre nur das Hinzufügen oder Löschen von Fakten der Basis. Somit muss nach einem Weg gesucht werden die Auslösung von erneuten Evaluationen der Regelbasis auch nach Veränderungen an einem Objekt anstoßen zu können.

Lösung

Die Lösung für dieses Problem ist eine Anpassung der in JBoss Drools gebundenen Klassen oder eine Anpassung im Bereich der Regeln. Die erste Möglichkeit ist die Anpassung der in JBoss Drools gebundenen Klassen. Hierzu ist es notwendig jeder Klasse ein "PropertyChangeListener" mitzugeben, welcher Veränderungen auf dem Java Objekt überwacht und ggfs. Interaktionen von JBoss Drools anstoßen kann. Hierzu muss folgender Quellcode in die Klassen eingefügt werden:

private final PropertyChangeSupport changes = new PropertyChangeSupport( this );

public void addPropertyChangeListener(final PropertyChangeListener l) {
    this.changes.addPropertyChangeListener( l );
}

public void removePropertyChangeListener(final PropertyChangeListener l) {
    this.changes.removePropertyChangeListener( l );
}

Außerdem muss nach jedem ändern von Attributen eine Funktion aufgerufen werden, welche die Veränderungen in Richtung JBoss Drools signalisiert. Hierzu gibt es die nachfolgend aufgeführte Funktion:

this.changes.firePropertyChange( "<variable>", oldState, newState );

Die zweite Möglichkeit, um Änderungen an Objekten in JBoss Drools mitzubekommen ist eine Anpassung der Regeln um einen modify Block. Hierzu dient die beispielhafte Regel zur Veranschaulichung:

rule Bootstrap
    when
        f : Fibonacci( sequence == 1 || == 2, value == -1 ) // multi-restriction
    then 
        modify ( f ){ value = 1 };
        System.out.println( f.sequence + " == " + f.value );
end

Hierbei löst die Änderung auf dem Objekt f eine automatische erneute Evaluierung aller Regeln der Regelengine aus.


Reaktionsgeschwindigkeit des ProSyst SDK / der angebundenen Geräte

Problemaufnahme & Analyse

Inhalt dieses Problems ist die Tatsache, dass die Evaluierung und anschließende Ausführung von Regeln durch JBoss Drools schneller geschieht, als das ProSyst SDK reagieren kann. Genauer gesagt bedeutet das, dass JBoss Drools ineinander greifende Regeln derart schnell auslöst, dass das ProSyst SDK nicht hinterher kommt die Schaltvorgänge auf den realen Devices durchzuführen. Hierdurch überspringt JBoss Drools teilweise Regeln, da diese noch auf "alten" Eigenschaften/Fakten der Java Objekte ausgelöst wurden. Somit kann es passieren, dass ein Schaltvorgang zwar laut JBoss Drools durchgeführt wurde, da Drools nur eine Variable anpasst welche dann vom ProSyst SDK umgesetzt wird, jedoch in der Realität nie eine Änderung des Geräts eintritt (bspw. Licht an / Licht aus).

Lösungsmöglichkeit I

Zum einen ist es möglich während des weiterreichens des Schaltvorgangs an das ProSyst SDK den Prozess für einen kurzen Zeitraum (ca. 1 Sekunde) zu verzögern, um somit dem realen Device die Möglichkeit zu geben den Schaltvorgang tatsächlich umzusetzen. Dies hat jedoch den fatalen Nachteil, dass hierdurch die gesamte Regelengine "schlafen gelegt" wird und somit keine anderen Regeln evaluiert und eventuell ausgeführt werden können. Dies könnte je nach Anwendungsfall bzw. auszuführender Regeln ernsthafte Konsequenzen haben. Als Beispiel hierfür könnte man einen einfachen "Licht an" Vorgang nehmen, welcher das komplette System für 1 Sekunde schlafen legt. Werden hierbei noch diverse Latenzen betrachtet bleibt das System somit für 1-2 Sekunden "stehen". Sollte in dieser Zeit eine sicherheitskritische Regel ausgeführt werden müssen (bspw. Alarmierung des Rettungsdienstes bei einem Sturz o.Ä.) und diese basiert auf einmaligen Event, welches nur via Trigger an die Regelengine gesendet wird, dann könnte dieser Vorgang eventuell niemals erkannt und bearbeitet werden.

Lösungsmöglichkeit II

Die andere mögliche Lösung ist eine zeitliche Verzögerung auf Regelebene. Hierzu sieht JBoss Drools einen Parameter vor, welcher die Aktivierungs- und Ausführungszeiten der Regel reglementiert. Hierzu müssen die folgenden zwei Schritte durchgeführt werden:

  1. Der KieSessionConfiguration muss bei der Initialisierung eine Uhr zugewiesen werden.
  2. Die Regel muss mit der Zeit versehen werden.

Diese beiden Schritte werden beispielhaft in den nachfolgenden Quellcode Schnippseln gezeigt:

KieSessionConfiguration config = kServices.newKieSessionConfiguration();
config.setOption(ClockTypeOption.get("realtime"));
rule "Licht aus"
  timer(int: 0s 3s) // Die erste Zahl ist die Verzögerung zum Ausführungsstart. Die zweite Zahl beschreibt nach welcher verstrichenen Zeit die Regel wieder aktiviert werden darf.
  when
      $bs: BinarySensorWrapper(getState() == true);
      $mls: MultiLevelSwitchWrapper(getLevel() == 255);
      $tp: TimeProvider(isMorning() == true);
      $ps: PresenceSimulator(isPresent() == false);
  then
      modify( $mls ) {
        setLevel(0)
      };
 
  System.out.println("MultiLevelSwitchWrapper.setLevel(0);"); 	
end

Die zweite beschriebe Lösung verhindert zwar, dass die Regelengine das ProSyst SDK zeitlich übergeht jedoch entstehen hierdurch teilweise doppelte Ausführungen von Regeln. Dieses Problem wird im nächsten Abschnitt genauer analysiert.

Lösungsmöglichkeit III

Eine dritte Lösungsmöglichkeit ist im nächsten Abschnitt beschrieben. Diese dritte Möglichkeit ist auch die, welche im Endzustand des Projekts verwendet wurde.

Doppelte Ausführung von Regeln

Problemaufnahme & Analyse

Inhalt des Problems ist die "doppelte" Auslösung von Regeln innerhalb der JBoss Drools Umgebung. Dieses Problem rührt von der gleichen Tatsache wie im vorherigen Problem, jedoch liegt es in diesem Fall an der Art wie das ProSyst mBS Smart Home SDK die Attribute der Objekte aktualisiert. Bei einem Schaltvorgang auf einem Objekt (z.B. MultiLevelSwitch) wird nach dem Aufruf der setLevel(int value) Funktion zuerst auf dem realen Objekt der Schaltvorgang (z.B. Licht an) durchgeführt. Erst wenn dieser Vorgang abgeschlossen ist wird das Attribut des Objekts der ProSyst mBS Smart Home SDK Umgebung aktualisiert. Sollte JBoss Drools zwischen diesen Aktionen weitere Regeln schlussfolgern, passiert dies auf falschen Fakten wodurch weitere/doppelte Schaltvorgänge durchgeführt werden. Hierdurch kommen mehrfache (oder teilweise unendliche) Wiederholungen von Regelausführungen zustande, welche ungewollt sind.

Lösung

Für dieses Problem gibt es eine einfache Lösungsmöglichkeit, nämlich die Einführung einer Art Cache in den Wrapper Klassen. Beim erstellen einer Wrapper Instanz wird der aktuelle Wert des ProSyst mBS Smart Home SDK Objekts gespeichert und bei jedem Schaltvorgang automatisiert aktualisiert. JBoss Drools schlussfolgert nun auf dem Cache, welcher bei jedem Schaltvorgang sofort aktualisiert wird und muss somit nicht auf die Aktualisierung des ProSyst mBS Smart Home SDK Objekts warten. Hierdurch wird der JBoss Drools Instanz sofort der aktuelle Wert zur Verfügung stellt obwohl dieser real noch nicht aktualisiert wurde. Durch Einführung des Caches wird auch das direkt hiervor beschriebene Problem mit den gezwungenen zeitlichen Verzögerungen gelöst, da dieses durch die sofortige Aktualisierung des Caches nicht mehr nötig ist um aktuelle Fakten zum schlussfolgern zu haben.

Durch diese Problemlösung entsteht wieder ein neues Problem im Bereich der Abarbeitung. Eine Interaktion auf dem realen Objekt wird in keiner Form vom ProSyst mBS Smart Home SDK quittiert, sodass es möglich ist das JBoss Drools auf vorgegriffenen Fakten weitere Regeln auslöst. Diese werden zwar durch das ProSyst mBS Smart Home SDK garantiert in der richtigen Reihenfolge abgearbeitet, jedoch kann es sein dass diese auf falschen Fakten ausgelöst wurden.

Ein Beispiel hierfür ist:

  • Regel A ändert Wert A
  • Regel B wird auf Basis von Wert A ausgelöst
  • Umsetzung des Wertes auf ProSyst mBS Smart Home SDK Objektebene schlägt fehl -> Exception
  • Regel B wird trotzdem ausgeführt, obwohl Wert A eigentlich real nie den benötigten Wert angenommen hat

Dieses Problem könnte mit einer Art aktivem Polling auf die Beendigung der Umsetzung gelöst werden. Oder man findet im ProSyst mBS Smart Home SDK eine Möglichkeit eine Art Callback bei Abschluss von Operationen zu bekommen.

Quellen

Nachfolgend befinden sich alle verwendeten Quellen des Wiki Eintrages. Im Abschnitt "Onlinequellen" befinden sich Skripte aus Vorlesungen, Papers von anderen Professoren und andere Onlinedokumente. Der Abschnitt "Buchquellen" beinhaltet ausschließlich physisch in Bibliotheken vorhandene Bücher.

Buchquellen

[Webe10] Bernd Weber, Patrick Baumgartner, Oliver Braun: OSGi für Praktiker, 2010 Carl Hanser Verlag München Wien, ISBN 978-3-446-42094-6

[Wüth08] Gerd Wütherich, Nils Hartmann, Bernd Kolb, Matthias Lübken: Die OSGi Service Plattform - Eine Einführung mit Eclipse Equinox, 2008 dpunkt.verlag GmbH, ISBN 978-3-89-864-457-0

[Görz14] Günther Görz: Handbuch der Künstlichen Intelligenz, Verlag 2014, ISBN 978-3-486-71307-7

Onlinequellen

[Open14] Kai Kreuzer: openHAB Wiki, https://github.com/openhab/openhab/wiki, entnommen am 28.03.2014

[Qivi14] Holger Knöpke, Deutsche Telekom AG: https://www.qivicon.com, entnommen am 28.03.2014

[Kreu12] Kai Kreuzer: http://kaikreuzer.blogspot.de/2012/05/xtext-xbase-quartz-joda-time-perfect.html, entnommen am 03.04.2014

[OpHA14] OpenHAB Wiki: https://github.com/openhab/openhab/wiki/Feature-Overview, entnommen am 03.04.2014

[Xbas14] Nirmal Sasidharan, Robert von Massow und Hendy Irawan: Eclipse Wiki: https://wiki.eclipse.org/Xbase, entnommen am 03.04.2014

[Wiki14] Wikipedia: http://en.wikipedia.org/wiki/Drools, entnommen am 10.04.2014

[Vorw14] Wikipedia: http://de.wikipedia.org/wiki/Vorw%C3%A4rtsverkettung, entnommen am 10.04.2014

[Auto14] ProSyst SDK Dokumentation: http://dz.prosyst.com/pdoc/mBS_SH_SDK_7.5/modules/automationengine/ham_module.html, entnommen am 01.05.2014

[Smet14] Geoffrey De Smet, JBoss Drools Developer Team: http://blog.athico.com/2014/01/which-rule-engine-algorithm-is-faster.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+DroolsAtom+%28Drools+-+Atom%29m entnommen am 08.05.2014

[Proc14] Mark Proctor, JBoss Drools Developer Team: http://blog.athico.com/2013/11/rip-rete-time-to-get-phreaky.htmlm entnommen am 08.05.2014

[Red14] Red Hat, Inc., JBoss BRMS 6.0 Development Guide: https://access.redhat.com/site/documentation/en-US/Red_Hat_JBoss_BRMS/6.0/html/Development_Guide/chap-Expert_Systems.html, entnommen am 08.05.2014

[Kreu14] Kai Kreuzer, openHAB Google Group: https://groups.google.com/forum/#!topic/openhab/3kgd_lEOsVk, entnommen am 09.05.2014

Paper

[Meie06] JBoss Drools, Patrick Meier - Fachhochschule Nordwestschweiz, http://www.gruntz.ch/courses/sem/ws06/RBP.pdf

[Preck12] Repräsentation medizinischen Wissens mit Drools am Beispiel der Adipositas-Leitlinie, Jonas Preckwinkel - Fachhochschule Brandenburg, http://ots.fh-brandenburg.de/downloads/abschlussarbeiten/2012-10-02%20ba_Jonas%20Preckwinkel.pdf

Gesprächsnotizen

[Hill14] Dipl. Ing. (FH) Jochen Hiller, Developer Evangelist QIVICON, Deutsche Telekom AG - Gespräch geführt auf dem 'OSGi UFG Treffen' am 14.04.2014 in Darmstadt

Notizen

  • Kai ist ab dem 11.08.2014 wieder in Wiesbaden & ab dem 18.08.2014 im Labor
  • ProSyst Raspberry Pi ZigBee:
    • Notiz: Verfügbar als ZigBee_ProSystPi.zip - die beiden Smartcomm Lib Dateien (letzten zwei Bundles) müssen dann noch per Hand nachinstalliert werden!
    • Benötigte Bundles für die ZigBee OSGi Umgebung auf dem Raspberry Pi:
      • 0 ACTIVE System Bundle
      • 1 ACTIVE fw.metatype
      • 2 ACTIVE fw.db
      • 3 ACTIVE javax.servlet
      • 4 ACTIVE fw.putil
      • 5 ACTIVE fw.config
      • 6 ACTIVE fw.osgilib
      • 7 ACTIVE fw.usradmex
      • 8 ACTIVE fw.http
      • 9 ACTIVE fw.log
      • 10 ACTIVE fw.devicem
      • 11 ACTIVE fw.useradm
      • 12 ACTIVE fw.connector
      • 13 ACTIVE fw.eventadmin
      • 14 ACTIVE fw.prvagent
      • 15 ACTIVE fw.scr
      • 16 ACTIVE configtree
      • 17 ACTIVE devstreams.smartcomm.serial
      • 18 ACTIVE devstreams.smartcommlib.impl
      • 19 ACTIVE devstreams.smartcommlib.serial
      • 20 ACTIVE fw.console
      • 21 ACTIVE fw.kitman
      • 22 ACTIVE fw.telnet
      • 23 ACTIVE fw.web.common
      • 24 ACTIVE fw.remote.ea.jsonrpc
      • 25 ACTIVE org.json
      • 26 ACTIVE fw.remote.jsonrpc
      • 27 ACTIVE org.apache.commons.fileupload
      • 28 ACTIVE org.apache.commons.io
      • 29 RESOLVED fw.web.console.branding
      • 30 ACTIVE fw.remote.ua
      • 31 ACTIVE fw.kxml2
      • 32 ACTIVE fw.web.console.resman
      • 33 RESOLVED org.apache.felix.webconsole.plugins.ds
      • 34 ACTIVE fw.web.console.ua
      • 35 ACTIVE org.apache.felix.webconsole
      • 36 ACTIVE fw.web.console.shell
      • 37 ACTIVE fw.web.console.auth.pass
      • 38 ACTIVE org.apache.felix.webconsole.plugins.packageadmin
      • 39 ACTIVE org.apache.felix.webconsole.plugins.event
      • 40 ACTIVE configtree.commands
      • 41 ACTIVE comm.lin-raspberry_raspbian
      • 42 ACTIVE devstreams.frameanalyzer.charconverter
      • 43 ACTIVE devstreams.frameanalyzer.web.console
      • 44 ACTIVE devstreams.frameanalyzer.api
      • 45 ACTIVE configtree.servlet
      • 46 ACTIVE configtree.web.console.plugin
      • 47 ACTIVE hdm.api
      • 48 ACTIVE hdm.util
      • 49 ACTIVE hdm.dc
      • 50 ACTIVE hdm.commands
      • 51 ACTIVE hdm.core
      • 52 ACTIVE hdm.remote
      • 53 ACTIVE hdm.simulator
      • 54 ACTIVE hdm.web.console.plugin
      • 55 ACTIVE hdm.simulator.dc
      • 56 ACTIVE zigbee.zcl.services
      • 57 ACTIVE hdm.configtree
      • 58 ACTIVE hdm.ham
      • 59 RESOLVED hdm.ham.web.gui
      • 60 ACTIVE ham.api
      • 61 RESOLVED ham.command.rule.web
      • 62 RESOLVED ham.event.web
      • 63 ACTIVE ham.web.console.plugin
      • 64 ACTIVE zigbee.commands
      • 65 ACTIVE zigbee.driver
      • 66 ACTIVE zigbee.ha.profile
      • 67 ACTIVE zigbee.zcl.hvac
      • 68 ACTIVE zigbee.zcl.closures
      • 69 ACTIVE zigbee.ha.dco.provider
      • 70 ACTIVE zigbee.se.profile
      • 71 ACTIVE zigbee.zcl.sensing.measurement
      • 72 ACTIVE zigbee.zcl.general
      • 73 ACTIVE zigbee.general.dco.provider
      • 74 ACTIVE zigbee.core
      • 75 ACTIVE zigbee.zcl.lighting
      • 76 ACTIVE zigbee.zcl.security
      • 77 ACTIVE zigbee.se.dco.provider
      • 78 ACTIVE zigbee.metadata.provider
      • 79 ACTIVE zigbee.hdm.adapter
      • 80 ACTIVE zigbee.telegesis
      • 81 ACTIVE zigbee.hdm.deviceclass.provider.demo_1.2.1
      • 82 ACTIVE zigbee.frame.analyzer
      • 84 RESOLVED fw.console.jline
      • 85 ACTIVE org.apache.felix.scr-1.6.2
      • 86 ACTIVE org.apache.felix.configadmin-1.6.0
      • 87 ACTIVE zigbee.telegesis.simulator.sample
      • 88 ACTIVE zigbee.telegesis.simulator
      • 89 ACTIVE zigbee.simulator
      • 90 ACTIVE iagent.rpc
      • 91 ACTIVE iagent.ext.rpc
      • 92 ACTIVE com.prosyst.mbs.smartcommlib.20140627-084407364
      • 93 ACTIVE com.prosyst.mbs.smartcommlib.20140627-084418543


  • ProSyst Raspberry Pi EnOcean:
    • Notiz: Verfügbar als EnOcean_ProSystPi.zip
      • 0 ACTIVE System Bundle
      • 1 ACTIVE fw.metatype
      • 2 ACTIVE fw.db
      • 3 ACTIVE javax.servlet
      • 4 ACTIVE fw.putil
      • 5 ACTIVE fw.config
      • 6 ACTIVE fw.osgilib
      • 7 ACTIVE fw.usradmex
      • 8 ACTIVE fw.http
      • 9 ACTIVE fw.log
      • 10 ACTIVE fw.devicem
      • 11 ACTIVE fw.useradm
      • 12 ACTIVE fw.connector
      • 13 ACTIVE fw.eventadmin
      • 14 ACTIVE fw.scr
      • 15 ACTIVE fw.prvagent
      • 16 ACTIVE fw.web.common
      • 17 RESOLVED fw.web.console.branding
      • 18 ACTIVE org.json
      • 19 ACTIVE org.apache.commons.fileupload
      • 20 ACTIVE org.apache.commons.io
      • 21 ACTIVE fw.console
      • 22 ACTIVE org.apache.felix.webconsole.plugins.ds
      • 23 ACTIVE fw.kitman
      • 24 ACTIVE org.apache.felix.webconsole
      • 25 ACTIVE fw.telnet
      • 26 ACTIVE org.apache.felix.webconsole.plugins.packageadmin
      • 27 ACTIVE org.apache.felix.webconsole.plugins.event
      • 28 ACTIVE fw.remote.ea.jsonrpc
      • 29 ACTIVE fw.remote.ua
      • 30 ACTIVE fw.remote.jsonrpc
      • 31 ACTIVE fw.web.console.resman
      • 32 ACTIVE fw.web.console.shell
      • 33 ACTIVE fw.web.console.auth.pass
      • 34 ACTIVE hdm.web.console.plugin
      • 35 ACTIVE hdm.api
      • 36 ACTIVE hdm.util
      • 37 ACTIVE hdm.dc
      • 38 ACTIVE hdm.commands
      • 39 ACTIVE hdm.core
      • 40 ACTIVE hdm.remote
      • 41 ACTIVE enocean.api
      • 42 ACTIVE enocean.core
      • 43 ACTIVE enocean.hdm.adapter
      • 44 ACTIVE enocean.json.rpc
      • 45 ACTIVE iagent.rpc
      • 46 ACTIVE iagent.ext.rpc
      • 47 INSTALLED com.prosyst.mbs.usb.os.linux.raspberry_raspbian.20140626-034433306
      • 48 ACTIVE com.prosyst.mbs.usb.20140626-034515741
      • 50 ACTIVE com.prosyst.mbs.services.enocean.linux.20140626-034545000