Hauptseite

Aus IEM

Wechseln zu: Navigation, Suche

---


Inhaltsverzeichnis

Ablauf und Planung

1. Weiterführende Analyse zu ESH

a. Konzept
b. Implementierung
c. Bindings hinzufügen

2. Konzeptentwicklung für erste Test-Binding

a. Ziel:
i. Erste Ansteuerung des DSS über ESH
ii. Erfahrungen zur vollständigen Implementierung/Konzept lernen
b. Benötigt:
i. Konzept; wie soll der 1. Test aussehen? was wollen wir damit erreichen?
ii. Benötigte Dokumente herrausfinden und sammeln

3. Implementieren

4. Gesamt Konzept entwickeln

5. Implementierung

desweiteren zwischen drin:
1. Weiterführende Analyse von DS inkl. Doku
2. Weiterführende Analyse von ESH inkl. Doku
3. Konzept Doku vorgehen
4. Konzept für Binding

Meilensteine

1. Abschluss: Vorläufige Konzeption

2. Fertigstellung: Erstes Test DS-Binding

  • Client Implementierung (OpenHAB1- Client als Test benutzen)
  • bridge-Implementierung
  • nötige Thing-xml-Dateien
  • zunächst manuell anschließend evtl. automatisch


2.1. evtl. Fertigstellung: Client Implementierung

  • OpenHAB1-Client um fehlende Methoden erweitern oder neue Implementierung des Clients realisieren


3. Fertigstellung: Automatisierung implementieren

  • automatische Thing-xml-Dateien Generierung
  • automatische Discovery realisieren
  • thing-Discovery vervollständigen
  • bridge-Discovery hinzufügen


4. Fertigstellung: Implementierung der verschiedenen Handler

5. Fertigstellung: Szenen Implementierung

6. Abschluss: finaler commit, Dokumentation abschließen, Präsentation vorbereiten


Optional: Einstellungsmöglichkeiten für Szenen implementieren


Link-Sammlung und Quellen

Eclipse SmartHome(OpenHAB 2.0):

Beispiele für die implementierte Bindings:

Schritt 1:

Setup Development Environment

Schritt 2:

Developing a new binding for OpenHAB 2
HowTo (Sample Project on Yahoo Weather)

eigene Quellen:

ESH Community Forum:
ESH Forum “New Thing concept” von Kai Kreuzer:
ESH Architektur Doku

DigitalSTROM:

Produktseite:
DigitalSTROM Allianz:
Architekturdokumente:
als Einstieg:
JSON Schnittstelle:
Entwicklerplattform:


Neues Thing-Konzept


  • im Mittelpunkt des neuen Konzepts stehen die sogenannten “things”
  • ein thing ist ein physikalische Einheit oder ein Dienst, das mit dem Eclipse Smarthome (ESH) System verbunden ist
  • things werden Channels zugeordnet, die an items gebunden werden können
  • things besitzen einen Status (online, offline), Meta-Informationen (Hersteller, Version) und eine Konfiguration
  • things werden mit Hilfe des OSGi ConfigurationAdmin (??) definiert
  • channels beinhalten Informationen, welcher item type mit dem channel verbunden werden kann, desweiteren enthalten sie die entsprechende Konfiguration
  • things werden in der Regel über einen Bus, wie IP-basierte Netze oder das Stromnetz (DigitalSTROM), genannt Bridge, mit dem ESH verbunden
  • eine Bridge enthält oder verbindet things
  • alle mit dem System verbundenen things werden in der ThingRegistry registriert
  • die ThingRegistry verwaltet die things, sie werden nicht automatisch hinzugefügt, aber sie werden durch das Binding vorgeschlagen und müssen durch einen User oder eine andere Instanz bestätigt werden
  • ein thing gehört immer zu einem Binding
  • bindings arbeiten mit things mit Hilfe des ThingHandlers
  • der ThingHandler erhält automatisch Befehle und update-Events, welche an items gesendet werden, die mit channels an things gebunden sind
  • der ThingHandler hat Zugriff auf die things und ihre Konfiguration


Vorteile:

  • Wir haben ein Konzept zur automatischen Erkennung und Paarung von Geräten mit bindings zwischen ESH und einem Device/Service/System ermöglicht, ohne sich zu sehr mit dem "abstrahiert" Item-Konzept beschäftigenzu müssen.
  • Informationen über erforderliche Konfiguration werden mit den bindings bereitgestellt; Dies ermöglicht die Konfiguration von GUIs, ähnlich wie HABmin, um dynamisch generierte Konfigurationsseiten zu erstellen.
  • Alle Konfigurationen sind dauerhaft im ConfigurationAdmin gespeichert, sodass sich konfigurierte Benutzerschnittstellen nicht mit der Itemdatei-Syntax beschäftigen müssen, dies ist nur EIN Weg um eine

Konfiguration zu erstellen. ( All configuration is persisted through ConfigurationAdmin, so configuration UIs do not need to deal with the items file syntax, which is only ONE way to provide a configuration.)

  • bindigs werden durch ein Multi-Instanz-Setup unterstützen. So können Sie mehrere, anstatt nur ein Gateway von jedem Typ haben.
  • bindigs benötigen keine internen Lookup-Tabellen um ihre Objektnamen, Typen und Konfiguration zu halten. Stattdessen erhalten sie direkt die Ereignisse über den Channel, an den es gebunden ist.
  • Die Syntax in der Item-Datei homogenisiert für alle Bindungen

Konzept 1. Test DS-Binding

Ziele:

  • Manuelle Verbindungsherstellung zwischen ESH und dSS über demo.thing
  • Ansteuerung einer Lampe (An/Aus)

Benötigte Artefakte:

  • JSON Befehle
  • XML Struktur
  • Programmierung
  • Benötigte Parameter

Vorgehen:

Zunächst muss eine sinnvolle Struktur zur Aufteilung der Hardware-Bestandteile von DS für die ESH-INF erarbeitet werden (siehe z.B. HUE-Binding). Anschließend werden die erforderlichen Parameter für die entsprechenden XML-Dateien, welche alle Informationen zur Verbindung zu DS und deren HW enthalten, gesucht und erstellt.
Als nächstes müssen die Java-Klassen programmiert werden. Dazu wird zunächst eine Konstanten-Klasse (DigitalSTROMConstains.java) benötigt, welche alle relevanten Konstanten auflistet. Nun müssen die Klassen DigitalSTROMHander.java und DigitalSTROMHandlerFactory.java implemeniert werden. Die Klasse DigitalSTROMHandlerFactory.java wird zur Erkennung des unterstützten Bindings und Erstellung eines entsprechenden Handlers (DigitalSTROMHander.java) benötigt. Über den DigitalSTROMHander werden die gesendeten Befehle des Nutzers von ESH ausgewertet, so umgewandelt, dass er an den dSS weitergeleitet werden kann. Antworten des dSS werden weitergeleitet, dadurch ESH Status geändert und ggf. Fehlermeldungen erstellt.

Umsetzung:

-Struktur ESH-INF.thing:

-Bridge.xml (Verbindungsinformationen, AuthentifizierungSicherstellung der Echtheit eines Kommunikationspartners, bei Programmen oder Daten: Sicherstellung der Urheberschaft, Schutz gegen Täuschung. )
  - bridge-type
    - id = dsBridge
    - label = DigitalSTROM
    - description = The DigitalSTROM bridge represents the DigitalSTROM bridge.
    - config-description
      - parameters
        - IP (DNS-Name)
        - username
        - password
- channels.xml (channels)
  - channel-type
    - Brightness Channel
      - id = brightness
      - item-type = Dimmer
      - label = Brightness
      - description = The brightness channel allows to control the brightness of a light. It is also possible to switch the light on and off.
      - config-description ?
        - parametes
    - SensorXY Channel 
      - id = sensorXY
      - item-type = Numer
      - label = sensorXY
      - description = The sensorXY channel returns the value of the XYsensor.
      - config-description
        - parametes
    - Secene ?
    - ...
- things → Klemmentypen (Hardwaretyp) + Stecker
  - unterstützte channels
  - name (String)
  - id 
  - ...


Number Name Color Function
1 lights yellow room lights
2 blinds gray blinds or shades outside
3 climate blue heating or cooling
4 audio cyan playing music or radio
5 video magenta TV, video
8 joker black configurable behaviour
n/a security red security related functions, alarms
n/a access green access related functions, door bell


Konzept DSS JSON API

1. Automatisch aus json_api.xml generieren

a. als Java-Klassen mit Methoden und JSON-Objekt als Rückgabetyp
b. als Konstanten für URL-Builder

2. Manuell geschrieben

a. wie 1.a. doch mit besser behandelbaren Rückgabetyp
b. wie 1.b.
c. OpenHAB1-Client um fehlende Methoden erweitern


DigitalSTROM Zertifizierungsregeln

Regel 1
Ein DigitalSTROM fähiges Gerät verfügt, muss in der richtigen funktionellen Gruppe vorkonfiguriert werden. Dies ist wichtig, um sicherzustellen, dass alle elektrischen Geräte im einer funktionelle Gruppe gemeinsam angesprochen werden können.
Regel 2
Ein DigitalSTROM fähiges Gerät muss genau für eine funktionelle DigitalSTROM Gruppe konfiguriert werden. Der zugeordnete Funktionsgruppe muss eindeutig sein und ist ein Teil der statischen Gerätekonfiguration.
Regel 3
Die Funktion einer Geräte-Ausgabe ist die Basis ihrer Gruppenzugehörigkeit. Bei Geräten ohne Antrieb ist die Zielfunktion des Schaltknopfes entscheidet über die Gruppenmitgliedschaft.
Regel 4
DigitalSTROM-Geräte müssen ein Standardverhalten(default) für alle 128 Szenenbefehle implementiert haben. Das Systemverhalten und die Standardwerte sind in den jeweiligen Dokumenten für jede funktionelle Gruppe definiert.
Regel 5
Wenn Anwendungen Szenenbefehl auf einen Gruppe von DigitalSTROM Geräte mit mehr als einem Zielgerät senden, müssen die Szenen Anrufe an eine Gruppe gerichtet wenden. Aufspaltung in mehrere Anrufe auf einzelne Geräte soll aufgrund von Latenz und Status Konsistenz Problemen vermieden werden.
Regel 6
digital fähige Geräte müssen Schrittbefehle ignorieren, wenn ihre Ausgabewert null ist.
Regel 7
DigitalSTROM Geräte müssen ihre Identifikation innerhalb von 4 Sekunden während des Programming-Mode-Start Befehls abgeschlossen haben.
Regel 8
Anwendungsprozesse, die Geräteparameter automatisch, zyklisch lesen oder schreiben unterliegen einer Abfragegrenze: maximal eine Anfrage pro Minute und Stromkreis sind erlaubt.
Regel 9
Anwendungsprozesse, die automatisch, zyklische Mess-Werte abfragen, unterliegen ebenfalls einer Abfragegrenze: maximal ein Anfrage pro Minute und eine Stromkreis erlaubt ist.
Regel 10
Der Befehl "Set Output Value" darf nicht für etwas anderes als für Gerätekonfigurations Zwecke verwendet werden.
Regel 11
DigitalSTROM fähige Geräte müssen keine upstream Ereignisse kontinuierlich senden und müssen aufhören Low-Level-Event-Daten zu senden, selbst wenn das Ereignis noch oder immer wieder gültig ist. Übertragung von Drucktasten Ereignissen müssen nach einer maximalen Zeit von 2,5 Minuten eingestellt werden. Automatisch generierte Events dürfen eine Frequenzgrenze von 10 Events pro 5 Minuten nicht überschreiten.
Regel 12
Zur Kommunikation mit dem DigitalSTROM-Server ist die Webservice-Schnittstelle zu verwenden. Direkte Schnittstellen mit der dSM-API sollen vermieden werden, da es eine innere Schnittstelle ist und sich die API in der Zukunft ändern könnte..
Regel 13
Anwendungen, die automatisch generierte Call-Szene Aktionsbefehle aufrufen,(siehe 5.1.1) dürfen die Aktionsbefehle nicht schneller als eine Anfrage pro Sekunde ausführen.
Meine Werkzeuge
Buch erstellen