“Hue Emulation” bei Beleuchtungsgruppen nach Update auf openHAB 2.4

Nach dem Update auf openHAB 2.4 funktioniert der folgende Sprachbefehl nicht mehr “Alexa, schalte das Licht Wohnbereich aus” in unserem SmartHome. Das zugehörige Item ist wie folgt definiert:

Switch Licht_EG_Wohnbereich     "Licht Wohnbereich"         (gLicht_EG, gLicht)             [ "Lighting" ]

Mit diesem Item schalte ich dann in einer Regel alle Lichter in den gewünschten Zimmern aus. Mit openHAB 2.3 hat das auch noch alles ohne Probleme funktioniert. Das Problem trat bei uns im Haus auf, wenn ein physikalischer Lichtschalter aktiviert wurde und dann dieses Licht per Sprache ausschalten wollte (das passiert bei uns öfter).

Ein ähnliches Problem wurde hier im openHAB-Forum leider ohne Lösung beschrieben.

Scheinbar gab es eine Änderung in dem Binding zwischen den Versionen 2.3 / 2.4 bezüglich der Stati ON / OFF / NULL. Ein Verweis auf den aktuellen Snapshot-Build hat das Problem gelöst.

Ich habe den Snapshot (Testversion) wie folgt eingespielt:

  • Hue Emulation deinstallieren –  PaperUI – Add-ons – MISC (misc-hueemulation – 2.4.0
  • Download der Datei org.openhab.io.hueemulation-2.5.0-SNAPSHOT.jar
    • Weitere Informationen zu den Änderungen gibt es hier
  • Die Datei wird in den Ordner /addons auf dem openHAB-System kopiert
  • Ergebnis kontrollieren – PaperUI – Configuration Services – IO – Hue Emulation
  • Optional: Die Logs auf entsprechende Fehler / Hinweise durchsehen

Nach dieser kleinen Änderung können “Gruppen-Schalter” (in unserem Fall Lichter) wieder über Alexa komplett geschalten werden.

Egal wie zuverlässig man alles testet, kommt bei jedem Software-Update immer eine “Kleinigkeit” dazu die man vergessen hat. 🙂

Hattet Ihr ähnliche Erfahrungen nach dem openHAB 2.4 Update?

 

Integration Webmail in ownCloud 10

Von unterwegs nutze ich öfter einen Webmail-Client zum Schreiben von E-Mails, anstatt die “Apps” über das Smartphone zu verwenden. In den meisten Fällen habe ich ein Notebook bei mir und kann mit einer richtigen Tastatur einfach besser und schneller Texte verfassen.

Allgemeine Informationen

Mit dem Update auf ownCloud 10 war eine einfache Integration der vorherigen Mail-App nicht mehr so einfach möglich.

Auf der einen Seiten waren mir die PHP-Abhängigkeiten zu hoch und auf der anderen Seite war die App nicht im offiziellen Marketplace vorhanden.

Es gab aber mit RainLoop eine weitere Webmail-App mit IMAP-Funktionalität im Store.

Installation

Die Installation führt man einfach über die Administrationsoberfläche von ownCloud durch und ist sofort erledigt.

Grundkonfiguration

Danach habe ich noch folgende Anpassungen in der RainLoop-Administration vorgenommen:

  • Standardpasswort und Benutzer für die Administration geändert
  • Sprache generell von Englisch auf Deutsch gestellt
  • In den Domain-Einstellungen musste ich noch meine E-Mail-Domain mit IMAP- und SMTP-Einstellungen aktivieren

Danach war das Grundcustomizing auch schon abgeschlossen und ich konnte mich wieder mit meinen E-Mail-Konten direkt im Web anmelden.

Fazit

Der Austausch der Webmail-App war sehr einfach möglich (ist ja auch keine gravierend schwierige Funktion).

Der neue Client integriert sich jetzt komplett in die Kontaktverwaltung – das macht es in der Verwendung schon viel einfacher.

Leider ist das Layout von ownCloud und RainLoop nicht komplett identisch – das hat für mich aber keine höhere Priorität.

Habt Ihr auch einen Webmail-Client mit ownCloud im Einsatz? Welche Software nutzt Ihr dazu?

Aktualisierung von ownCloud 9 auf ownCloud 10

Für den privaten Gebrauch (als “Private Cloud”) nutze ich ownCloud in einer älteren Version, da die Updates der Software meistens sehr aufwändig für mich waren.

Allgemeine Informationen

Im ersten Schritt habe ich die Release Notes und die Changelogs der Version 10 (und der vorherigen 9er Versionen kontrolliert). Diese findet Ihr hier und hier.

Es wird die Verwendung von PHP 7.2 auf dem Server empfohlen d.h. man sollte die vorhandene PHP-Version auch gleich noch einmal kontrollieren.

Danach habe ich noch einmal die letzte Upgrade-Anleitung gelesen, da ich ja öfter Probleme nach dem Update von diversen ownCloud-Versionen hatte.

Es müssen auf alle Fälle die vorhandenen 3rd-Pary-Apps auf Kompatibilität kontrolliert, vor dem Update aktualisiert und dann deaktiviert werden. Die aktuellen Versionen kann man über den Marketplace einsehen.

Da ich mein System auf einem Shared-Hosted-System betreibe, habe ich mich für den Update-Pfad über die Updater-App entschieden.

Hier habe ich noch eine gute Anleitung zur Aktualisierung bei decatec.de gefunden (diese kann man gut als Basis verwenden).

Voranalyse

Folgende Punkte habe ich im Vorfeld kontrolliert:

  • PHP Version (Aktualisierung von 5.5 auf 7.2 notwendig)
  • Installierte Apps prüfen
  • Cron-Job prüfen
  • Update-Pfad prüfen (mir wurde ein Update von 9.1.6 auf 9.1.8 und dann auf 10.0.10 angeboten)

Apps

Im nächsten Schritt habe ich alle vorhandenen 3rd-Party-Apps auf die aktuellsten Stände gebracht und ggf. auch aussortiert:

Die Mail-App und die ownNote-App wollte ich nicht weiter nutzen. Die Mail-App hatte andere Abhängigkeiten zu PHP und habe ich damit gelöscht. ownNote läuft leider noch nicht mit der ownCloud Version 10 und wurde auch deinstalliert

Aktualisierung

Die Aktualisierung habe ich zwei Mal durchgeführt:

  • 9.1.6 auf 9.1.8
  • 9.1.8 auf 10.0.10

Der Ablauf war ganz grob wie folgt:

  • Backup der vorhandenen Daten durchführen
    • config-Ordner sichern
    • data-Ordner sichern
    • ownCloud-Datenbank sichern
  • Kompatibilität der 3rd-Party-Apps noch einmal kontrollieren
  • Alle 3rd-Party-Apps in der Administrationsoberfläche deaktivieren
  • Updater-App aufrufen und ausführen (ACHTUNG: Hier hat vor allem der Punkt mit der Aktualisierung der Apps etwas gedauert)
  • Nach ein paar Minuten war der Update-Prozess abgeschlossen

Jetzt folgen die Funktionstests:

  • Anmeldung an der Weboberfläche
  • Admin-Oberfläche auf Warnungen und Hinweise kontrollieren
  • Schritt für Schritt die 3rd-Party-Apps wieder aktivieren und testen (bei mir speziell die Kalender und Kontakte auf allen Endgeräten)
  • Danach den ownCloud-Client neu starten und auch die erfolgreiche Synchronisation kontrollieren

Fazit

Im Gegensatz zu den letzten Major-Release-Updates liefen diese beiden Updates sehr einfach und gut durch. Scheinbar hat man sich die Update-Probleme bei ownCloud doch genau angesehen und zum positiven verändert.

Jetzt verfüge ich über ein neues ownCloud 10 System und kann mit der Integration der neuen Funktionen beginnen.

Im nächsten Schritt werde ich den Webmail-Client gegen eine neue Version ersetzen.

Habt Ihr ownCloud 10 auch im Einsatz? Hattet Ihr auch ähnliche positive Erfahrungen beim Update?

Installation und erste Tests mit MQTT und openHAB 2.4

Vorbereitend für unsere Sonoff-Steckdosen zum Schalten der Weihnachtsbeleuchtung habe ich mich etwas mehr mit dem Thema MQTT beschäftigt.

Was ist MQTT?

Ein guter Einstiegsartikel zum Thema MQTT mit dem Fokus auf openHAB findet Ihr in diesem Blog-Beitrag.

MQTT steht für Message Queuing Telemetry Transport und entspricht dem ISO Standard – ISO/IEC PRF 20922. Es handelt sich dabei um das meist verwendete Protokoll im Internet der Dinge (IoT). Bei MQTT handelt es sich um ein “publish-subscribe” basiertes Nachrichtenprotokoll.

In einem MQTT-System kommunizieren Clients mit einem Server (dieser wird oft “Broker” genannt). Ein Client kann Nachrichten verteilen (Publisher) oder empfangen (Subscriber).

Installation MQTT in openHAB

In diesem Artikel wird nur die MQTT-Integration von openHAB 2.4 und neuer betrachtet (in den vorherigen Versionen sind andere Installationen und Konfigurationen notwendig).

Im ersten Schritt wird das MQTT Binding wie folgt installiert:

  • Paper UI – BINDINGS – MQTT Binding (binding-mqtt-24.0) – INSTALL

Im Zweiten Schritt wird der MQTT Broker hinzugefügt:

  • Paper UI – MISC – Embedded MQTT Broker (misc-mqttbroker-2.4.0) – INSTALL
  • Optionaler Konfiguration: Paper UI – Configuration – Services – MQTT – MQTT Embedded Broker – CONFIGURE

Danach befindet sich ein Item “MQTT Broker” (embedded-mqtt-broker) in der Inbox und muss akzeptiert und als Thing hinzugefügt werden (hier ist keine weitere Konfiguration notwendig).

Im letzten Schritt wird noch die MQTT Action aktiviert:

  • Paper UI – Add-ons – ACTIONS – MQTT Action (action-mqtt-1.13.0) – INSTALL

Konfiguration einer Regel

Um den integrierten MQTT Broker zu testen habe ich folgende MQTT.rules-Datei erstellt:

rule "MQTT_TEST"
when
    Time cron "0 */1 * ? * *" //every 1 Minute
then
val actions = getActions("mqtt","mqtt:systemBroker:embedded-mqtt-broker")
actions.publishMQTT("test/system/started","true")
end

Damit wird jede Minute eine Test-Nachricht auf das MQTT Topic “test/system/started” mit dem Wert “true” geschrieben.

MQTT-Client zum Test

Da ich aktuell noch kein MQTT-fähiges Endgerät im Haus habe, konnte ich mit mqtt-spy das Ergebnis testen. Den direkten Download der Version findet Ihr hier.

Die Konfiguration des Clients kann wie folgt aussehen:

  • Configuration – Konfiguration erstellen
  • Connections – Manage Connections
  • Verbindung zum MQTT Broker: IP:1883 (Port 1883 stellt die unverschlüsselte Verbindung dar)
  • Im Control panel kann dann …
    • … “Publish message” mit Topic “test/system/started” gesendet werden
    • “Subscription and received messages” “test/system/started” empfangen werden

Damit kann ich dann an den in openHAB 2.4 integrierten MQTT Broker Nachrichten senden und von dort empfangen.

Eine mögliche Konfiguration sieht so aus:

Zusammenfassung

Mit openHAB 2.4 und dem zugehörigen Blog-Eintrag war eine einfache und schnelle Einarbeitung in MQTT mit den neuen openHAB-Elementen möglich. Jetzt habe ich die MQTT-Basis verstanden und ein MQTT-System installiert und konfiguriert.

Das Basis-System steht damit und ich kann in die Detailkonfiguration der Things / Items in openHAB einsteigen. Für die nächsten Tests fehlt mir noch ein MQTT-fähiges Endgerät. Hier habe ich bereits ein paar Sonoff S20 Steckdosen bestellt, die ich mit Tasmota flashen möchte.

Nutzt Ihr MQTT in euren SmartHome-Szenarien? Welche Endgeräte habt Ihr damit angebunden?

Erstinstallation des HABot mit openHAB 2.4

Mit obenHAB 2.4 kam als neue Funktion der HABot hinzu (in openHAB 2.3 und früher konnte man den Chat-Bot leider nicht integrieren). In diesem Artikel beschreibe ich wie einfach man einen Chat-Bot für sein SmartHome mit openHAB in Betrieb nehmen kann.

Was ist ein Chat-Bot?

Ein Chat-Bot ist ein textbasiertes Dialogsystem das die schriftliche Kommunikation mit technischen Systemen erlaubt. Einen Chatbot kann man als bessere Volltextsuchen oder erste Ansätze von künstlicher Intelligenz verstehen.

Der Bot basiert auf der Eclipse SmartHome Laufzeitumgebung, kann offline verwendet werden und speichert keine Daten in “Third-Party-Anbieter-Clouds”.

Welche Technologien werden für HABot benutzt?

Der HABot basiert auf folgenden Technologien:

  • Einer “Machine Learning” Sprache basierend auf Apache OpenNLP
  • Ein modulares System auf Basis OSGi
  • Ein Karten basierendes “User Interface” basierend auf einer REST API und dem dem Quasar Framework
  • Ein auf Eclipse SmartHome basierenden Human Language Interpreter
  • Progressive Web App als Basis für die Integration in die mobile Welt z.B. Push-Nachrichten, Spracherkennung und Ressourcenverwaltung

Wie wird der HABot eingerichtet?

Der Bot wird in der Paper UI wie folgt aktiviert:

  • Add-ons – USER INTERFACES – HABot (2.4.0)

Danach kann der HABot ohne weitere Konfiguration für einen ersten Test verwendet werden. In diesem einfachen Beispiel wurden noch keine erweiterten Attribute wie semantische TagsMetadaten oder  Kategorien verwendet.

Wie wird der HABot benutzt?

Für den Start des HABot wird einfach folgende URL im Webbrowser aufgerufen:

http://IP:PORT/habot/

Danach kann durch die Eingabe der folgenden Beispiel-Elemente mit dem Bot kommuniziert werden (“Christbaum” ist ein vorhandenes openHAB-Item in meiner Umgebung):

  • “Schalte den Christbaum ein”
  • “Schalte den Christbaum aus”

Im User-Interface sieht das wie folgt aus:

Wo gibt es weiterführende Informationen?

Ein gutes Video vom SmartHome Day 2018 zum Thema HABot gibt es hier:

Gibt es Anwendungsfälle im SmartHome?

Es ist immer schön wenn man sich mit neuen und innovativen Technologien beschäftigen kann, aber für mein privates SmartHome habe ich bis jetzt noch keine Anwendungsfälle für einen Chat-Bot gefunden. Die meisten Geräte werden bei uns per Sprache oder physischen Schaltern aktiviert.

Wie sieht es bei euch aus? Seht Ihr Anwendungsfälle für einen Chat-Bot im SmartHome? Welche Szenarien sind für euch denkbar?

“Günstige” Alternative zur Steuerung der Weihnachtsbeleuchtung / Steckdosen

Ich benötige saisonal (also an Weihnachten) ca. 10 – 15 schaltbare Steckdosen für unsere gesamte Weihnachtsbeleuchtung im Haus.

Aktuell werden die “Lichterketten” über manuelle Zeitschaltuhren gesteuert. Das klappt mal besser und mal nicht so gut z.B. verschiedene Steckdosen gehen zu verschiedenen Zeiten an.

Als Alternative wollte ich die gesamte Beleuchtung über openHAB und Regeln zentral steuern. Hierfür war mir aber die Schaltung der EIB / KNX Steckdosen im Haus zu teuer bzw. im Keller habe ich nicht überall schaltbare Steckdosen. Auch der HomeMatic Funk-Schaltaktor für ca. 40 Euro ist preislich nicht angemessen.

Ich habe mir in der Facebook-Gruppe OpenHAB Germany ein paar Ideen / Anregungen eingeholt.

Herausgekommen ist jetzt erst einmal folgende Idee:

  • Verwendung der Sonoff S20 Steckdosen (4 Stück für ca. 40 Euro bei Ebay) (das scheint für meinen Anwendungsfall die günstigste Variante zu sein)
  • Da ich die Steckdosen nur bei mir lokal mit dem Protokoll MQTT verwenden möchte ist die Firmware Tasmota auf den Endgeräten notwendig
  • Die Firmware kann ohne Löten bei der S20 aufgespielt werden (Beispiel), da an der S20 “Jumping Wires” direkt einstecken kann (das war mir wichtig, da mir das Löten zu aufwändig erschien)
  • Für den Flash-Vorgang ist ein FTDI-Adapter notwendig und ein paar Kabel
  • Die Firmware-Tasmota kann dann mit Atom oder der ArduinoIDE entsprechend angepasst / geflasht werden

Danach hat man eine per MQTT schaltbare Steckdose die mit dem heimischen WLAN verbunden ist. Die Einbindung per MQTT an openHAB ist dann kein Problem mehr.

Ich denke der manuelle Aufwand sollte nach den ersten ein / zwei Versuchen recht minimal sein. Damit wäre das die bisher günstigste Variante von schaltbaren Steckdosen in meinem SmartHome.

Habt Ihr schon einmal auf Endgeräte Tasmota geflasht? Wie sind eure Erfahrungen?

Aktualisierung openHAB 2.3 auf 2.4

Ich habe in den vorherigen Artikeln bereits beschrieben welche Mehrwerte und neue Funktionen openHAB 2.4 hat. In diesem Beitrag beschreibe ich kurz die Aktualisierung von openHAB 2.3 auf 2.4 und mögliche “Stolpersteine” nach dem Update.

Aktualisierung der Installation

Das Update in einer Linux-Distribution auf Debian-basieren wird wie folgt durchgeführt:

sudo systemctl stop openhab2.service
sudo apt-get update
sudo apt-get upgrade

Mit dem ersten Befehl wird der openHAB-Dienst beendet. Die beiden nächsten Zeilen starten die Aktualisierung.

Nach der Aktualisierung kann man das System mit folgendem Befehlt komplett neu starten:

sudo shutdown -r now

Damit ist die Installation von Version 2.3 auf 2.4 aktualisiert. Am Ende der Installation werden jetzt auch noch die “Breaking Changes” angezeigt d.h. die Änderungen die Ihr manuell durchführen müsst.

Manuelle Anpassungen der Konfigurationen

Folgende Bindings habe ich nicht im Einsatz und damit nicht weiter betrachtet:

  • Jeelink Binding
  • Milight Binding
  • WeatherUndergroundBinding
  • ZWave Binding
  • Synop Binding

Folgende Bindings habe ich im Einsatz und musste ich kontrollieren:

  • Astro Binding
  • AmachonEchoControl Binding
  • Hue Binding

Astro Binding

The ‘kilometer’ and ‘miles’ channels have been replaced by a new ‘distance’ channel

Die kleineren Anpassungen (nur wenn man Distanzen verwendet hat) findet man hier.

AmazonEchoControl Binding

The account thing does not have settings anymore. The new version will not longer store your amazon credentials. You have to login at amazon once again through the proxy server http(s):///amazonechocontrol. This will create a refresh token which is internal stored for the authentication. Furthermore is the polling replaced through a web socket connection.

Hier musste ich mehrere Anpassungen durchführen:

  • Beta-Version aus 2.3 unter /usr/share/openhab2/addons löschen
  • Installation der Version 2.4:
    • Paper UI – Add-ons – BINDINGS – Amazon Echo Control Binding (2.4.0) – INSTALL
  • siehe oben, damit eine neue Authentifizierung durchgeführt wird

Hue Binding

Hue emulation: The item to hue ID mapping is no longer stored in files, but in the openHAB storage service. You need to rediscover “devices” in all services that use the hue emulation (Amazon Echo, Google Home, etc).

Bei der Hue Emulation gab es leider ein paar mehr Probleme in meinem Fall:

  • Hue Emulation war nicht mehr installiert / aktiviert
  • Installation der Version 2.4: Paper UI – Add-ons – BINDINGS – Hue Binding (2.4.0) – INSTALL
  • Aktivierung der temporären Option:
    • Paper UI – Configuration – Services – Hue Emulation – Device Pairing + Amazon Echo device discovery fix – AKTIVIEREN
  • Amazon Echo App – Suchen der Geräte
  • “Switchable” Elemente (bei mir Steckdosen) werden nicht mehr erkannt und müssen auf “Lighting” gestellt werden (siehe Link1 und Link2)

Weiterführende Informationen

Folgende Links und weiterführende Informationen habe ich bei meinen Recherchen noch gefunden:

Fazit

Nach etwas zwei Stunden Arbeit und etwas Vorbereitung läuft meine Installation nun auf openHAB 2.4. Was sich in der Anleitung so leicht liest, ist im täglichen Einsatz leider doch etwas mehr Aufwand (vor allem der Test aller Endgeräte im Haushalt darf nicht vernachlässigt werden).

Etwas ärgerlich waren die Änderungen in der Hue Emulation und im Amazon Echo Control Binding. Diese Auswirkungen waren mir zum Teil nicht klar bzw. das Thema mit dem “Switchable” habe ich so gar nicht gesehen.

Jetzt ist das Update aber eingespielt und die neuen Funktionen werden von mir getestet.

Habt Ihr auch schon auf openHAB 2.4 aktualisiert? Hab es bei euch Probleme? Welche neuen Funktionen nutzt Ihr?

Optimiertes Log-Verhalten für openHAB

Da unser openHAB-System in einem RaspberryPi mit einer SD-Karte läuft, wollte ich einmal die Schreibzugriffe auf die Karte kontrollieren bzw. optimieren.

Die meisten Schreibzugriffe werden beim Logging durchgeführt. Hier habe ich gesehen, dass noch INFO-Meldungen protokolliert werden.

Den Tipp für die Deaktivierung der Loggings und damit einer längeren Lebensdauer habe ich bei getmob.de gelesen. Die komplette Dokumentation zum Logging in openHAB findet Ihr hier.

Konfiguration

Viele Log-Level sind bei openHAB im Standard auf “INFO”. Während des Aufbaus der Installation ist das auch interessant. Aber wer liest schon im laufenden produktiven Betrieb später noch Log-Dateien?

In meinem Fall führt auch jede Logausgabe zu einem Schreibzugriff auf der SD-Karte und damit zu einer verminderten Lebenszeit des Flash-Speichers.

Das Logging-Verhalten kann hier angepasst werden:

/var/lib/openhab2/etc/org.ops4j.pax.logging.cfg

Ich habe die folgenden Log-Level auf “WARN” gestellt:

  • org.openhab
    • Alt: #log4j2.logger.openhab.level = INFO
    • Neu: log4j2.logger.openhab.level = WARN
  • org.eclipse.smarthome
    • Alt: #log4j2.logger.smarthome.level = INFO
    • Neu: log4j2.logger.smarthome.level = WARN
  • smarthome.event
    • Alt: #log4j2.logger.events.level = INFO
    • Neu: log4j2.logger.events.level = WARN

Die Änderungen in der Konfiguration sollten ohne Neustart übernommen werden.

Fazit

Bei einem Neustart des Systems und im laufenden Betrieb sieht man wesentlich weniger Log-Meldungen. Damit sollten weniger Schreibzugriffe im Gesamtsystem vorhanden sein.

Leider sieht man jetzt auch keine Meldungen mehr vom KNX-Bus z.B. Licht geht an, Licht geht aus. Hier müsste ich vor einer tieferen Fehlersuche dann die Konfiguration wieder ändern (aber es sind ja nur ein paar Handgriffe im laufenden Betrieb).

Weiterführende Informationen

Hier gibt es noch einen weiteren Artikel über das Thema Logging – https://andreas.scherbaum.la/blog/archives/967-Avoid-wear-out-of-SSD-cards-in-an-openHAB-system.html

Dort wird auch beschrieben wie man die Log-Dateien auf eine RAM-Disk auslagern kann. Das dortige Beispiel basiert auf Ansible.