davidgraeff / scenecontrol

A plugin extendable software for home automation / domotics requiering a small always-on pc like the raspberry pi. Use your modern webbrowser to simply configure events-conditions-actions. Extendable functionality through an easy to use plugin API.

Heimautomatisierung Framework

Das Framework führt Szenenabläufe durch. In einer Szene sind Ereignisse, Bedingungen und Aktionen frei verknüpft angeordnet. Funktionalität wird durch lokale oder entfernte " Service " Prozesse bereichgestellt.

Alle weiteren Informationen, die Roadmap und Downloads befinden sich auf der Webseite dieses Projekts.

Anwendungsgebiete

• Intelligenter Wecker
• Energiesparsystem
• Intelligenter Raum
• Automatisiertes Heimkino

Entwicklungsdetails

Das Kernprogramm ist in JavaScript erstellt und läuft als node js Programm. Durch die Verwendung von JavaScript können der Editor und das Kernprogramm Quellcode gemeinsam nutzen. Der Datenaustausch erfolgt über JSON. Szenen, Szenenelemente und alle weiteren Daten werden in einer mongoDB Datenbank gehalten. Services sind aktuell überwiegend in C++ realisiert.

Scenes Editor

Um Ereignisse, Bedingungen und Aktionen zu erstellen und grafisch in Szenen zu organisieren exitiert eine Web-Anwendung. Die Anwendung kann direkt durch das Aufrufen der index Datei gestartet oder über einen beliebigen Webserver ausgeliefert werden. Eine Demonstartion befindet sich auf der Webseite des Projekts.

Screenshot:

Android-App

Fast alle Funktionen der Services können über eine Android App kontrolliert und ausgelöst werden. Eine Funktionen des Editors sind auch in der App möglich, wie das Erstellen und Verknüpfen von Startzeiten mit Szenen.

Code Stabilität

Über das Travis CI wird die ständige Kompilierbarkeit sichergestellt und automatisierte Tests decken bereits einige Bereiche des Kernprogramms ab. Auf der Webseite befindet sich eine Roadmap. Gemeldete Fehler und Wünsche werden über das Ticketsystem von github verwaltet.

Installation

Es wird node js, cmake und ein c++ compiler benötigt.

• BUILD Verzeichnis erstellen, z.B. "./build"
• cmake im BUILD Verzeichnis ausführen, z.B. "cmake ../"
• Installieren mit "make install"
• Ausführen des Servers mit "sceneserversession"

Die Ausführung erfolgt dabei in einem screen Fenster. Der Server kann auch direkt gestartet werden, etwa mit "nodejs /usr/lib/scenecontrol_suite/core/main.js".

scenecontrol's Issues

Ubuntu PPA Build einrichten

Ubuntu PPA Build einrichten: travis-ci sollte nach erfolgreichem Build ein neu Generieren anstoßen

Webseite

Indexseite

• Downloadbutton
• Bild von Editor in Header neben Titel
• Linke Spalte überarbeiten tiefer, Elemente klickbar, "Beispiel" o.ä. Schriftzug einbetten

Konfigurieren

• Einleitung
• Detailiertes Handbuch für den Editor
• (Demo) Live Editor (Demo Modus ohne Websockets mit fester Datenbasis)

Downloadseite/Get started Seite

• Schritt für Schritt Anleitungen: kompilieren

Anleitungen

• Erweitern
• Bilder

Architekturschaubilder

Plugin: dmx/artnet

Unterstützung um DMX Lampen nutzen zu können

Neue Monitor Klasse und Kommandos dafür

Server

Hängt von #16 ab

Clients sollen sich für Notifications für die Ausführung/Beenden von Szenen und Szenenelementen registrieren können. Eine Monitor Klasse und neue JSON Kommandos müssen erstellt werden.

Editor

Vor dem Starten einer Szene soll sich der Editor bei der Monitor Klasse registrieren und die Oberfläche soll die aktuell ausgeführten Szenenelemente hervorheben.

Plugin: Webhooks

Als Event

Einfacher http server bietet URL an, die aufgerufen werden kann, zB http://127.0.0.1:3110/webhook/4746373

Eine Webapp ruft diese URL dann auf mit zB http://127.0.0.1:3110/webhook/4746373?first=test

Datenübertragung:

Die akzeptierten GET Parameter werden als Variablen gespeichert.
Wird POST benutzt muss der MIME Typ json sein. Die Im JSON Text übermittelten Variablenwerte werden verwendet.

Beispiel SceneControl/JSON

{componentid_:"webhook",type_:"event",hookname:"4746373",acceptvars:["first"]}

Als Aktion:

Eine angegebene URL wird aufgerufen, zB. http://www.some-webapp.io/service

Datenübertragung:

Variablen können in der URL verwendet werden, zb. http://www.some-webapp.io/service?first={{variablen_name}}

• Feld post: String wird per HTTP Post gesendet.

Rückgabe

• Rückgabe: Die Rückgabe der Seite steht dem nachfolgendem Szenenelement als "@lastresponse" zur Verfügung.

Probleme: JSON Rückgabe?! Evtl. javascript in Szenenelement einbetten oder allgemeines Javascript Szenenelement, welches auf lastresponse, variablen, properties zugreifen darf.

• Keine Asynchronität: kein setTimeout o.ä.
• Zeitlich begrenzte Ausführung: Nach 1,5s Abbruch
• Kein require(..) o.ä.

Beispiel SceneControl/JSON

{componentid_:"webhook",type_:"action",
url:"http://www.some-webapp.io/service?first={{variablen_name}}"}

Mit Post

{componentid_:"webhook",type_:"action", post:"{\"test\":"\json\"}"
url:"http://www.some-webapp.io/service?first={{variablen_name}}"}

Plugin IPC: Von QLocalSocket/QDataStream zu SSL/TCP/JSON

Plugins sollen sich über den Kommandosocket verbinden, statt wie bisher eine unix localsocket Verbindung aufzubauen. Als Format soll JSON statt dem QDataStream Format verwendet werden.

Vorteile

• SSL Verbindung mit Plugin spezifischem Zertifikat: Dadurch Authentifizierung
• Plugins können auch entfernt ausgeführt werden (TCP über Netzwerk)
• Plugins können auch in anderer Programmiersprache als Qt/C++ erstellt werden

Nachteile

• Langsamer da SSL+Text statt Binary Daten

Anpassungen:

Neue Konfigurations-Schema Schlüsselwörter:

• "is_remote" mit true oder false (default). Wenn dieser Schlüssel auf true gesetzt ist, dann wird die beschriebene Plugininstanz nicht sofort gestartet, sondern eine Verbindung von einem Plugin eines anderen Systems für die entsprechende Instanz ID wird erlaubt.
• "allowed_remote_hosts" mit ["127.0.0.1", "server.local","cinemasystem.local"]. Eine Liste von IPs oder DNS Hostnamen, von welchen die Verbindung der beschriebenen Plugininstanz erlaubt ist.

Editor: Szenenliste durch Grid ersetzten

Bisher werden Szenen in einer Liste dargestellt. Auf größeren Bildschirmen sollte der Platz besser für Thumbnails der Szenen genutzt werden.

Daher: Umstellung auf Grid Ansicht statt Listenansicht im html Editor.

Editor: Generisch Models/Services unterstützen

Die Web App / der Editor bietet bisher keine Ansteuerung der Services an, obwohl alle Funktionalität über Schemata beschrieben ist.

Verfügbare Aktionen aus Schema Dateien ableiten

Jede Funktion eines Plugins, die in einer Szene als Szenenelement auftauchen kann, wird durch eine Schema Datei im JSON Format beschrieben.
Aus den Schemadateien, welche Aktionen beschreiben, könnten gfs.
alle durchführbaren Funktionen abgeleitet werden. Alle Schemas, die auf einer Steueroberfläche angeboten werden sollen, sollten markiert werden, z.B.
{...,"uicontrol":true}

ohne Parameter

Bei einfachen Schemas ohne Parameter können auf der GUI Buttons verwendet werden.

ein Parameter

Bei Schemas mit einem Parameter hängt die Darstellung vom Parametertyp ab. Ist dies ein Boolean, kann ein Toogle-Button in der GUI angeboten werden. Ist der Typ ein eingeschränkter Integer oder Integer oder Float kann eine Range-Slider oder ein Nummerneingabefeld dargestellt werden.
Andere Arten von Parametern (String, MultiEnum) würden nicht unterstützt werden.

ein Parameter, Typ enum

Für alle Belegungsarten des Enums wird ein eigener Button auf der GUI erstellt.

mit mehreren Parametern

Bei Aktionen mit mehreren Parametern können entweder alle Parameter bis auf einer mit einem Standardwert belegt werden, oder die Funktion kann nicht angeboten werden.

Changed Ereignisse den GUI Elementen zuordnen

I.d.R. hat das Auslösen einer Funktion eine Änderung des Plugin Zustandes zur Folge. Ein Property-Changed Ereignis wird dann vom Server abgesetzt. Die GUI Elemente müssen ihren Zustand (Toggle Button oder Slider) entsprechend anpassen.

3rd Party Repositories

Script um 3rd Party Repositories vor dem Build zu integrieren

Editor: Szene starten/stoppen

Eine Szene soll im Editor->Szene bearbeiten Modus gestartet und gestoppt werden können

Authentifizierung und Zugriffsrechte

Bisher gibt es keine Authentifizierungsmöglichkeit. Clients, wie der Editor müssen ebenfalls Authentifizierung beherrschen.
Zugriffsrechte sollen den Funktionsumfang einschränken können.

Editor: Rechtsklick/Longtouch menu

Aktuell werden Links und Szenenelemente unintuitiv mit Tastenkombinationen bearbeitet (zB entfernen durch ENTF Taste).

Ein Kontextmenü soll die Aktionen Entfernen, Neue Verbindung, Neue alternative Verbindung (für Bedingungen), Ausführung hier starten enthalten.

Server: Variablen/Plugin Properties in Szenenelementen

Aktuell können Server Variablen über eine eigene Aktion gesetzt und als Bedingung verwendet werden. Variablen können nicht an beliebiger Stelle in Szelenelementen genutzt werden.

Hängt von #16 ab

Variablen in Szenenelementen

Vor der Ausführung von Szenenelementen sollten @{var_name|defaut_value} Templates durch die entsprechende Variablenbesetzung oder den angegebenen Standardwert ersetzt werden.

Plugin Properties in Szenenelementen

Vor der Ausführung von Szenenelementen sollten @{plugin_property_name|plugin_instance_id|defaut_value} Templates durch die entsprechende Propertybesetzung oder den angegebenen Standardwert ersetzt werden.

Anpassungen

Der Server muss eine Kopie aller Plugin Property Werte vorhalten, um diese direkt in Szenenelementen einsetzen zu können. Eine Asynchrone Abfrage an das entsprechende Plugin würde zu lange dauern.

Editor: Von JQuery Mobile auf Twitter Bootstrap umstellen

Der Editor war eigentlich nie für Smartphones, sondern mindestens Tablets gedacht. Daher soll jquery mobile durch twitter bootstrap http://twitter.github.com/bootstrap ersetzt werden.
In dem Zuge werden die js/css/img Dateien in eigene Ordner verschoben.

Vorteile

• Weniger javascript Einwirkung
• Page transitions sind weniger kompliziert, weniger Markup

Nachteile

• $.mobile.loading/hide fehlt
• keine Popup Unterstützung

Server auf Node.js/mongodb umstellen

Node.js

Da Szenen/Szenenelemente in json vorliegen und die Kommunikation mit Plugins und über den Kontrollsocket über das json Format ablaufen hat es Vorteile den Server direkt in Javascript über node.js zu implementieren.

Vorteile

• JSON als Datenformat erlaubt in JS das direkte Verwenden und Manipulieren von Daten
• Mit MongoDB baut die Datenhaltung auf einer echten Datenbank auf, statt auf dem Dateisystem
• Auf Änderungen in der Datenbank kann mit dem Publish/Subscribe Pattern (https://github.com/scttnlsn/mubsub) reagiert werden.
• Unit Tests sind möglich
• Mit Node.js clustern kann die Kontrollsocket Arbeit parallelisiert werden

Nachteile

• Performance und Speicherverbrauch könnte steigen
• Garbage Collector, Kein kontrolliertes Aufräumen

Datenhaltung per mongodb

Ein node.js/mongoDB treiber existiert (https://github.com/christkv/node-mongodb-native)

Plugin: Email unter Linux versenden

Das Plugin soll bekannte E-Mail SMTP Programme unter Linux unterstützen.

Verwendungszweck: Statusinformationen

Websocketproxy als node.js app

Mit https://github.com/Worlize/WebSocket-Node den Websocketproxy als node.js Anwendung bereitstellen. Hängt von #16 ab.

Vorteile

• Die vormals vom Server und vom websocketproxy verwendete SceneDocument-C++-Klasse kann entfernt werden. Die im Server verwendete JS Kapselung kann dann verwendet werden.

Android App: Generisch Models/Services unterstützen

Bisher werden einige ausgewählte Pluginfunktionen in der Android App mit jeweils spezialisiertem Code realisiert und angeboten, obwohl alle Funktionalität über Schemata beschrieben ist. Eine generische Lösung ist wünschenswert.

Siehe auch #15