Smarthome

Smarthome 2.0 – wie openHAB, Netatmo, Hue, Max und co zusammen fanden

Veröffentlicht

Seit längerem hatte ich mich mit dem Gedanken zur Einrichtung einer „richtigen“ Smarthomelösung herumgeschlagen, im Mai und Juni 2014 war es dann endlich soweit:  Entschluss gefasst, eine Lösung musste her. Und Technik, jede Menge Technik! Zum regeln, steuern, messen, benachtigen, einfach für alles. Da sich mein Projekt leider auf eine Mietwohnung beschränkt, flogen fixe Verkabelungen, KNX-Module und Rolloantriebe allerdings aus dem Konzept raus, Funk musste her…

TL;DR – hier lang

Hardware
Vor der Umsetzung musste allerdings erstmal ein Plan her, also: Bestandsaufnahme.
Folgende Komponenten hatte ich bereits seit längerem erfogreich im Einsatz, somit war die Integration in die „eierlegene Smarthome-Sau“ auch unumgänglich:

Max! System von elv (Heizkörper-Termostate, Fensterkontakte, Eco-Taster, Wandtermostat, Max!Cube als LAN-Gateway), quasi mein erstes Stück Smarthome von vor drei Jahren
-12 Brennenstuhl RNS 1000 Funksteckdosen mit passenden Fernbedienungen, DIP-Codiert auf dem jeweiligen Raum
FritzBox 7490 mit Freetz, UPnP / Mediaserver, NAS
-zwei Dreamboxen (Schlafzimmer und Wohnzimmer)
-zwei Apple TVs (dto.), davon eine mit Jailbreak ATV Flash (black) und XBMC
Airport Basisstation für Airplay in der Küche
 -ein altes iPad in der Küche an der Wand, um beim kochen das TV Programm von der Dreambox zu streamen

Wünsche
Als nächstes schrieb ich meinen Wunschzettel für das neue System zusammen. Dabei entstanden Produkt- und Funktionskategorien, welche im späteren Verlauf in dieser Form auch beinahe eins zu eins übernommen wurden. Folgende Bereiche sollten mit der neuen Lösung abgedeckt werden können:

-Komfort (Licht schalten, Multimedia schalten, Temperaturen aktiv regeln, Szenen / Gerätegruppen schalten…)
-Umwelt (intelligente Heizungssteuerung, Verbraucher abschalten wenn nicht benötigt, kein Standby…)
-Gesundheit (Raumklima messen, proaktiv Empfehlungen zur Situationsverbesserung erhalten…)
-Sicherheit  (Raumüberwachung, Objektüberwachung, Alarmierung, Brandfrüherkennung)
-Automatisierung (intelligente Schaltungen, Szenen, Regelungen…)
-Überwachung / Monitoring (Ist jemand zuhause? welche Geräte laufen oder sollten laufen…)

Software
Aus dieser Zusammenstellung ergab sich dann der Einkaufszettel. Als Basissoftware entschied ich mich, nach einem kurzen Abstecher zu FHEM, für openHAB. Mich überzeugte hier vor allem die einfache Administration und die immer größer werdenden Community, aber auch die Vielzahl an sog. „Bindings„, welche mit jedem Release umfangreicher wird. Mit diesen Modulen ist es mit extrem wenig Aufwand möglich, die unterschiedlichsten Geräte an das System anzubinden. Das ist allerdings nicht immer möglich und genau da punktet openHAB gleich noch einmal, denn über Module wie EXEC-Bindings etc. begibt man sich raus aus dem openHAB-Framework und kann z.B. auch ganz klassische Shell-Kommandos absetzen, Webseiten parsen oder Standard-Betriebssystemfunktionen verwenden. Das macht die Lösung umso flexibler, der Fantasie sind somit eigentlich keine Grenzen mehr gesetzt, quasi: geht nicht gibts nicht.

neue Hardware
Als Hardware für openHAB verwendete ich ein Ein-Platinen-System von Cubietech, Cubietruck. Nachdem ich bereits einige Erfahrungen mit Raspberry und Co gesammelt hatte, entschied ich mich aufgrund der performanten Ausstattung für den Cubie: Gigabit Ethernet, 2GB RAM und Dual Core CPU in dieser kleinen Bauform sollten ausreichend Leistung für das Projekt hergeben.

Um Lichtsteuerung, Klimakontrolle und Geräteschaltung gewährleisten zu können kamen noch folgende Produkte zum Einsatz:
Philips Hue Starterkit
Philips Bloom
Philips Iris
Brematic LAN-Gateway
netatmo Urban

Es geht los
Nach und nach besorgte ich mir die benötigte Hardware und begann damit, den Cubie startklar zu machen. Als Distribution verwendete ich zuerst Cubian, allerdings scheint hier der Support für die ARM-basierende Hardware noch nicht so wirklich zu klappen. Zuletzt kam dann Lubutu direkt auf den Chip. Nachdem das System soweit eingerichtet war (am längsten dauert hier der Flash-Vorgang des Cubies mit der LiveSuit, alles andere ist schnell erledigt) beschäftigte ich mich die nächsten paar Stunden damit, openHAB kennen zu lernen und zu verstehen. An dieser Stelle ein Hinweis: Ich empfehle für die ersten Gehversuche, unbedingt die Demo-Config zu verwenden. Wer es mit Coding nicht so hat, der sollte sich auch in jedem Fall den openHAB Desiger installieren, das macht einiges einfacher. 

Als nächstes machte ich mich daran, die einzelnen Komponenten einzurichten und, falls vorhanden, erst einmal mit dem jeweiligen App bzw. der jeweiligen Software zu regeln und zu schalten. In der Rückschau muss man folgendes festhalten: es ist teilweise wirklich armselig, was renomierte Hersteller da so alles ausliefern. Wenn man sich einmal an die Bedienung über openHAB gewöhnt hat, dann möchte man nichts anderes mehr verwenden. Interessant wurde die ganze Sache besonders bei dem Brematic Gateway. Es gibt zwar ein paar (kostenpflichte) Apps wie Steckerchecker, aber eine echte Lösung stellt das nicht dar, zumal die Config auf jedem Gerät einzeln vorgenommen werden muss. Eine zentrale Lösung ist das also nicht. Glücklicherweise hat sich aus einer der vielen Smarthome-Communities ein Projekt entwickelt, das einen anderen Ansatz verfolgt. Die Lösung nennt sich „Conn-Air Mobile“ und stellt als Webseite eine Verbindung zu den Brennenstuhl-Steckdosen her, jedoch, aufgrund der Hardware, immer nur in sendender Richtung. Doch das ist besser als nichts, denn es eröffnet auf dieser Basis auch die Möglichkeit, die Steckdosen von openHAB aus über das Brematic Gateway anzusprechen. Hier kommt dann auch zum ersten Mal die Notwendigkeit nach einer Möglichkeit, quasi „an openHAB vorbei“ zu schalten, die Wahl der Methode fiel zu diesem Zweck auf EXEC-Binding.

in openHAB sieht das Item dann so aus:
Switch Light_GF_Living_Couch        „Steckdose Sofa“    (GF_Living) { exec=“OFF:/opt/brematic/licht_sofa_off.sh, ON:/opt/brematic/licht_sofa_on.sh“ }

Das Gegenstück dazu bildet das Shell-Script:
#!/bin/bash
an () {
    echo „TXP:0,0,10,5600,350,25,1,3,1,3,1,3,1,3,1,3,3,1,1,3,1,3,1,3,1,3,1,3,1,3,1,3,3,1,1,3,3,1,1,3,3,1,1,3,3,1,1,3,1,3,1,3,3,1,1,16,;“ | /bin/nc -u 192.168.178.33 49880 &
    pid=$!
    sleep 1
    kill $pid 2>/dev/null >/dev/null
}
echo An
an

Der ganze Block ab „TXP“ ist das Schaltkommando inkl. Steckdosen-ID, welches das Brematic-Gateway erhält und dann an die entsprechende Steckdose weitergibt. Am einfachsten erhält man diesen Code, wenn man einen Schaltbefehl von Conn-Air aus absetzt und dabei mit tcpdump aufzeichnet, was da genau gesendet wird. Nicht unbedingt schick, aber funktionell.

Bei anderen Produkten wie netatmo oder Max! ging die Einbindung da mit vorhandenen Add-Ons schon wesentlich leichter von der Hand, allerdings ist auch hier manchmal eine gehörige Portion Hirnschmalz und eine grundsätzliche Lust an Webrecherchen gefragt. So geschehen zum Beispiel bei der Einbindung des Outdoor-Moduls der Wetterstation: In der Beschreibung des Bindings steht lediglich

Example item for the outdoor sensor (first id is the device, second id is the module):

Number Netatmo_Outdoor_Temperature "Outdoor temperature [%.1f °C]" {netatmo="00:00:00:00:00:00#00:00:0

Klar, die Mac-Adresse des Basis findet man leicht, aber die Adresse des anderen Moduls herauszubekommen erforderte dann schon ein wenig Fantasie:

First serial character is „h“:  start with „02“,
first serial character is „i“: start with „03“,
append „:00:00:“,
split the rest into three parts of two characters and append with a colon as delimeter.
For example your serial number „h00bcdc“ should end up as „02:00:00:00:bc:dc“.
Diese Info war auch leider nicht beim Binding nachzulesen, insofern kann auch so ein, scheinbar einfacher Task, das eine oder andere mal mit einem gewissen Zeit- und Suchaufwand verbunden sein. 
Der schöne Nebeneffekt bei größeren Projekten ist, dass immer Synergien entstehen. Nachdem ich die Philips-Lampen erstmal in Betrieb genommen hatte, „stolperte“ ich eher zufällig über ein XBMC-Plugin, mit welchem man z.B. das Wohnzimmer in eine große Ambilight-Zone verwandeln kann. Nette Geschichte, dass 🙂
Es wird.. 

Irgendwann waren dann alle Geräte und Komponenten, Räume, Schalter, Sensoren und Apps eingerichtet und das große schalten und walten konnte beginnen. Doch halt! Was hatte ich, ausser ein paar neuen Geräten und einer einheitlichen Oberfläche, überhaupt gewonnen? Eigentlich nichts. Dabei waren die Wünsche doch eigentlich klar und nicht mal im Ansatz erledigt:

-Komfort (Licht schalten, Multimedia schalten, Temperaturen aktiv regeln, Szenen / Gerätegruppen schalten…)
-Umwelt (intelligente Heizungssteuerung, Verbraucher abschalten wenn nicht benötigt, kein Standby…)
-Gesundheit (Raumklima messen, proaktiv Empfehlungen zur Situationsverbesserung erhalten…)
-Sicherheit  (Raumüberwachung, Objektüberwachung, Alarmierung, Brandfrüherkennung)
-Automatisierung (intelligente Schaltungen, Szenen, Regelungen…)
-Überwachung / Monitoring (Ist jemand zuhause? welche Geräte laufen oder sollten laufen…)

Weiter gehts!
Im Bereich „Temperaturen aktiv regeln“ und „intelligente Heizungssteuerung“ entschloss ich mich nach einigem hin und her letztlich dazu, diese Aufgabe weiterhin dem Max!Cube zu überlassen. Sicherlich würde das in openHAB auch gehen, aber einseits wurde die Geräteliste und damit die Anzahl aktiver Tasks auf dem Cubie immer mehr, andererseits bin ich der Meinung, dass man das Rad nicht immer neu erfinden muss. Insofern beschränkte ich mich bei der Verbindung von Max! zu openHAB auf einen rein lesenden Zugriff zur Darstellung der Sensorwerte, aber auch zur Auswertung der Fensterkontakte für den Bereich „Sicherheit“. Anders sah es da schon bei den anderen Bereichen aus, ich entdeckt die Regeln in openHAB. Ich weiß nicht ob es anderen openHAB Usern auch so gegangen ist, aber für mich eröffnete sich eine Welt voll von Möglichkeiten. Ein Beispiel:

Anspruch: Wenn der Schalter „Insektenschutz“ aktiviert ist und im Wohnzimmer ein Fenster geöffnet wird, dann schalte alle Lampen aus, damit nicht soviel „Viecher“ in der Wohnung rumfliegen

Lösung:
import org.openhab.core.types.*

var string varLight_GF_Living_Lightchain = OFF
var string varLight_GF_Living_Star = OFF
var string varLight_GF_Living_Lamp = OFF
var string varHue_GF_Living_Couch = OFF
var string varHue_GF_Living_Table = OFF
var string varHue_GF_Living_TV = OFF

rule „GF_Living_LightOff_Window“
        when
                Item Window_GF_Living changed from CLOSED to OPEN
        then
                if (Insektenschutz_GF_Living.state == ON)
                {
                varLight_GF_Living_Lightchain = Light_GF_Living_Lightchain.state
                sendCommand(Light_GF_Living_Lightchain, OFF)

                varLight_GF_Living_Lamp = Light_GF_Living_Lamp.state
                sendCommand(Light_GF_Living_Lamp, OFF)

                varHue_GF_Living_Couch = Hue_GF_Living_Couch.state
                sendCommand(Hue_GF_Living_Couch, OFF)

                varHue_GF_Living_Table = Hue_GF_Living_Table.state
                sendCommand(Hue_GF_Living_Table, OFF)

                varHue_GF_Living_TV = Hue_GF_Living_TV.state
                sendCommand(Hue_GF_Living_TV, OFF)

                varLight_GF_Living_Star = Light_GF_Living_Star.state
                sendCommand(Light_GF_Living_Star, ON)
                }
        end

rule „GF_Living_LightOn_Window“
        when
                Item Window_GF_Living changed from OPEN to CLOSED
        then
                if (Insektenschutz_GF_Living.state == ON)
                {
                sendCommand(Light_GF_Living_Star, OFF)
                sendCommand(Light_GF_Living_Lightchain, varLight_GF_Living_Lightchain)
                sendCommand(Light_GF_Living_Lamp, varLight_GF_Living_Lamp)
                sendCommand(Hue_GF_Living_Couch, varHue_GF_Living_Couch)
                sendCommand(Hue_GF_Living_Table, varHue_GF_Living_Table)
                sendCommand(Hue_GF_Living_TV, varHue_GF_Living_TV)
                }
        end

Ein anderes Beispiel: Innenraumüberwachung – Wenn Wohnung „scharf“ geschaltet ist (manuell oder automatisch durch Anwesenheitserkennung) und der Geräuschpegel höher als 40db wird, gib eine Meldung aus (Prowl)

import org.openhab.core.types.*

var boolean NoiseHighWarningAlarm = false

rule „Monitor noise level for security“
    when
        Item Netatmo_Indoor_Noise changed
    then
        if(Netatmo_Indoor_Noise.state > 40) {
            if(Presence_Global.state == OFF) {
                pushNotification(„Security Alert“, „Geräusche in der Wohnung festgestellt! Eventueller Einbruch!“)
                NoiseHighWarningAlarm = true
            }
        } else {
            NoiseHighWarningAlarm = false
        }
end

noch ein Beispiel: Sonnenstands-bezogen schalten

import org.joda.time.*

var Timer tIndoorLights

rule „React to sunset“
when
    Time cron „0 0 16 * * ?“   // Every day 16:00 hours, evaluate sunset
then
    var year   = now.getYear
    var month  = now.getMonthOfYear
    var day    = now.getDayOfMonth
    var datum  = year+“-„+month+“-„+day+“ „+strSunset.state
    logInfo(„Sunset“,“datum = “ + datum)
    var DateTime sunset = parse(year+“-„+month+“-„+day+“T“+strSunset.state)

    /*
     * Indoor Lights
     */
     // Cancel timer to avoid reschedule
    if(tIndoorLights!=null) {
    logInfo(„Sunset“,“Timer tIndoorLights cancelled“)
    tIndoorLights.cancel()
    }
    logInfo(„Sunset“,“Timer tIndoorLights created“)
    tIndoorLights = createTimer(sunset.minusMinutes(15)) [|
    logInfo(„Sunset“,“Timer tIndoorLights executed“)
    pushNotification(„Info“, „Sonnenuntergangstimer ausgelöst“)
    GF_Sunset?.members.forEach(Switch|
        sendCommand(Switch, ON)
    )
    ]
end

Rules rule
Nach Stunden, ach: Tagen des Regeldesigns musste ich meine Liste nochmals überprüfen:

-Komfort (Licht schalten, Multimedia schalten, Temperaturen aktiv regeln, Szenen / Gerätegruppen schalten…)
-Umwelt (intelligente Heizungssteuerung, Verbraucher abschalten wenn nicht benötigt, kein Standby…)
-Gesundheit (Raumklima messen, proaktiv Empfehlungen zur Situationsverbesserung erhalten…)
-Sicherheit  (Raumüberwachung, Objektüberwachung, Alarmierung, Brandfrüherkennung)
-Automatisierung (intelligente Schaltungen, Szenen, Regelungen…)
-Überwachung / Monitoring (Ist jemand zuhause? welche Geräte laufen oder sollten laufen…)

Wer hätte das gedacht? Alles erledigt 🙂 Zusammengefasst bleibt nur eins zu sagen: openHAB + Bindings bringt viel. Das System ist schnell aufgesetzt, man kommt schnell zu Ergebnissen und konsolidiert innerhalb kürzester Zeit eigentlich alle anderen Bedienkonzepte / Apps etc. in eine einheitliche Oberfläche. Aber richtig interessant (und smart, wie in „Smarthome“) wird openHAB erst / vor allem durch das Regelwerk,  die Timer und die manigfaltigen Benachrichtigungsmöglichkeiten, erst dadurch wird aus dem ganzen ein echtes „Smarthome“!

Wie gehts weiter?
Da ich der Ansicht bin, dass das Potential von openHAB für mich noch lange nicht ausgeschöpft ist, werde ich mich demnächst mit folgenden Punkten beschäftigen:
-Präsenzerkennung durch RFID-Chips
-Branderkennung mit „richtigen“ Brandmeldern
-proaktive Videoüberwachung des Eingangsbereichs
-Messung des Stromverbrauchs z.B. der Waschmaschine, um eine Benachrichtigung zu erhalten, wenn die Maschine fertig ist
-Pflanzenüberwachung mit Koubachi
-….

Für einen Kollegen durfte ich in der Zwischenzeit auch schon tätig werden, hier wurde eine Alarmanlage realisiert, in absehbarer Zeit wird noch eine Öltank-Überwachung mit SRF02 und Arduino-Shield dazu kommen. Und mit ein wenig Glück darf ich dann auch noch an das KNX-System ran 😉

Zusammenfassung
Bindings / Regeln
-Exec (Fernsteuerung Brennenstuhl Power Outlets via Brematic Gateway)
-Hue (Licht Szenen, Präsenz)
-Max! (Heizung, Fensterkontakte, Cube für Klima Kontrolle und Sicherheit / Proaktive Lichtkontrolle via Kontakten)
-ownTracks (Präsenz, Coming Home / Leaving Home, Sicherheit)
-NetAtmo (Wetter, Luftqualität, Lautstärke, Luftdruck, Sicherheit)
-GCal (Timer, Präsenz-Sim.)
-HTTP (Monitoring)
-NTP (Zeit)
-Network Health (Monitoring)
-Prowl (Nachrichten, Sicherheit)
-ReWrite Rules (Brematic <> NH)
-Insect-Mode (Licht aus wenn XYZ)
-Coming Home / Leaving Home (ownTracks)
-Heizpläne
-Sonnenaufgang / Sonnenuntergang
-…
 


Bilder / Screenshots
bitte hier entlang

Ein Gedanke zu „Smarthome 2.0 – wie openHAB, Netatmo, Hue, Max und co zusammen fanden

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.