waschto.eu https://waschto.eu Der Blog für FHEM-Einsteiger und Raspberry-Begeisterte Sat, 06 May 2017 21:10:20 +0000 de-DE hourly 1 https://wordpress.org/?v=4.7.5 https://i0.wp.com/waschto.eu/wp-content/uploads/2016/08/cropped-cropped-webiconNNN.png?fit=32%2C32&ssl=1 waschto.eu https://waschto.eu 32 32 104475921 Statusdisplay mit ESP Easy, DLCD und FHEM https://waschto.eu/statusdisplay-mit-esp-easy-dlcd-und-fhem https://waschto.eu/statusdisplay-mit-esp-easy-dlcd-und-fhem#comments Mon, 24 Apr 2017 19:14:16 +0000 https://waschto.eu/?p=2548 .tve_more_tag {display: none !important}Jeder der in seiner Freizeit ab und zu mit dem Arduino oder Raspberry programmiert, ist früher oder später auf eines der beliebten LCDs gestoßen. Es gibt sie in unterschiedlichen Ausführungen. Sei es mit 16 Zeichen und zwei Zeilen oder die große Ausführung mit 20 Zeichen und vier Zeilen. Auch im Bezug weiterlesen →]]> Jeder der in seiner Freizeit ab und zu mit dem Arduino oder Raspberry programmiert, ist früher oder später auf eines der beliebten LCDs gestoßen.

Es gibt sie in unterschiedlichen Ausführungen. Sei es mit 16 Zeichen und zwei Zeilen oder die große Ausführung mit 20 Zeichen und vier Zeilen. Auch im Bezug der Hintergrundbeleuchtung und Schriftfarbe gibt es unterschiedliche Ausführung. Unter anderem grüne Hintergrundbeleuchtung mit schwarzer Schrift oder blaue Hintergrundbeleuchtung mit weißer Schrift. Für jeden Geschmack etwas dabei.

Auch ich habe bereits damals mit diesen LCDs herumgespielt. Dank vorhandenen Treiber und Bibliotheken ist das Programmieren auch für Anfänger sehr leicht und garantiert schnelle Erfolgserlebnisse. Mir kam deswegen schon früh die Idee das Display auch in FHEM einzubinden und ein paar Informationen auf diesem anzuzeigen. Leider haben immer wieder andere Projekte dieses Vorhaben nach hinten gedrängt - bis jetzt. In diesem Beitrag möchte ich euch deswegen mein Vorgehen schildern und euch zum Nachmachen animieren. 

Welches LCD mit welcher Hardware?​

Bevor ich mich ans Programmieren und Definieren gemacht habe, habe ich mich zunächst auf die Suche nach einem passenden Display und der passenden Hardware gemacht. ​

Wie der Titel schon verrät, habe ich mich für die Software ESP Easy entschieden und der regelmäßige Blogleser unter euch wird es schon erahnt haben, ein WeMos-Baustein als Hardware.  

Damit das Display nun problemlos am WeMos-Baustein angeschlossen werden kann und später von ESP Easy unterstützt wird, bedarf es ein weiteres Stück Hardware. Eine I2C-Schnittstelle wird die Verbindung zwischen WeMos-Baustein und Display herstellen. Dieser I2C-Baustein kann einzeln bestellt werden.

Letzte Aktualisierung am 27.05.2017 / Affiliate Links / Bilder von der Amazon Product Advertising API

Ich empfehle euch jedoch ein Display zu kaufen, welches bereits eine I2C-Schnittstelle integriert hat bzw. diesen Baustein bereits besitzt. 

Letzte Aktualisierung am 27.05.2017 / Affiliate Links / Bilder von der Amazon Product Advertising API

Ich persönlich finde eine blaue Hintergrundbeleuchtung etwas moderner, weswegen ich mich für ein Display mit vier Zeilen und 20 Zeichen mit weißer Schrift auf blauer Hintergrundbeleuchtung entschieden habe. Natürlich mit bereits angelöteter I2C-Schnittstelle (rote Platine).

Der Aufbau

Dank der I2C-Schnittstelle ist der Aufbau relativ simpel. Ihr müsst einfach die vier Anschlüsse mit dem WeMos-Baustein verbinden. 

LCD - I2c

WeMos-Baustein

GND

GND

VCC

VCC

SDA

ein freier GPIO - in meinem Fall: D7

SCL

ein freier GPIO - in meinem Fall: D6

Der Jumper auf der linken Seite (siehe Bild) dient der Stromversorgung der Hintergrundbeleuchtung. Ist der Jumper gesetzt, so wird die Hintergrundbeleuchtung durch den Controller gesteuert und kann über ESP-Easy entweder aus- oder auf 100% angeschaltet werden.

optionale Helligkeitssteuerung

Möchtet ihr die Helligkeit regeln​, könnt ihr dies über ein Potentiometer realisieren oder ihr benutzt einen weiteren freien GPIO des WeMos-Boards und könnt die Helligkeit dann auch über FHEM regeln.

Da die GPIOs des WeMos-Boards leider nur mit 3,3V arbeiten, kann man zwar nicht die gleiche Helligkeit erreichen, wie mit 5V, aber für meine Bedürfnisse noch ausreichend. Wer es jedoch heller möchte, kann natürlich mit einem Level-Shifter oder mit einem Transistor arbeiten. 

Bevor ich jedoch mit der Anpassung begonnen habe, habe ich gemessen, wie viel Strom die Hintergrundbeleuchtung benötigt. Dazu habe ich einfach den Jumper entfernt und ein Strommessgerät zwischen geschaltet.

Bei einem 20x4 LCD mit blauer Hintergrundbeleuchtung sind es ca. 30 mA. Für die WeMos-GPIOs also noch im grünen Bereich. Andere LCDs können natürlich andere Werte haben, aber sollten sich alle so im Bereich 30-40 mA befinden. 

Da mir persönlich die Helligkeit bei 3,3 V ausreicht, habe ich einfach den Jumper entfernt und einen freien GPIO-Pin vom WeMos-Board (D3) verwendet und diesen mit dem oberen PIN der Jumperleiste verbunden.

Voraussetzung ist natürlich, dass dieser PIN direkt mit dem "Kathoden-Anschluss" des Displays verbunden ist (zweiter PIN von links, beschriftet mit K). Somit lässt sich die Helligkeit direkt über diesen Anschluss steuern. Sollte dies nicht der Fall ist, könnt ihr natürlich direkt an den Kathoden-Anschluss gehen und die Leiterbahn entsprechend unterbrechen.

Die Konfiguration der Helligkeitssteuerung auf der Softwareseite wird später beim entsprechenden Device in FHEM vorgenommen.

​Installation ESP Easy 

Wie am Anfang schon erwähnt, wird die Software ESP Easy verwendet. Bevor man nun also mit der Konfiguration fortfährt, muss die aktuellste Version auf den WeMos-Board geflasht werden. Wie dies geht, könnt ihr auf meinem Blogbeitrag zum Thema erfahren. Für die LCD-Steuerung wurde die ESP Easy Version 147 verwendet. 

Konfiguration ESP Easy

Bevor mit der Definition in FHEM begonnen werden kann, müssen erstmal ein paar Einstellungen auf der Konfigurationsseite von ESP Easy vorgenommen werden.

Zum Einen solltet ihr im Reiter "Config" dem WeMos-Board einen eindeutigen Namen vergeben. Ich habe "WeMos-LCD" verwendet.​

​Wichtig ist nun, dass unter dem Reiter "Hardware" die verwendeten PINs für die I2C-Schnittstelle angegeben werden. In meinem Fall GPIO13 (D7) für SDA und GPIO12 für SCL.

Nachdem Bestätigen durch Klicken auf "Submit" muss das Board neu gestartet werden. Dazu einfach den Reset-Button des Boards drücken oder kurz die Stromversorgung trennen.

Sobald das Board neu gestartet wurde, kann unter dem Reiter "Tools" und dann auf "I2C Scan" überprüft werden, ob das Display erkannt wird.

Das LCD wurde unter der Adresse 0x27 erkannt. Mit dieser Adresse kann man unter dem Reiter "Devices" das LCD einrichten. Dazu einfach auf "Edit" und dann als Device "Display - LCD2004" auswählen. Hier lassen sich nun die entsprechenden Einstellungen des Displays eingeben. 

Wichtig ist hier nun die IC2-Adresse. Diese muss auf die ermittelte Adresse gesetzt werden. Des Weiteren kann über "Display Size" die Größe des Display angegeben werden. Zum Test kann nun noch der Inhalt der Zeilen befüllt werden, welche beim Start des Display angezeigt werden sollen (INFO: Die Zeilen nach dem erfolgreichem Test wieder leer lasse, da es sonst zu Komplikationen mit den gesendeten Textzeilen von FHEM kommen kann).

Mit Submit könnt ihr eure Eingaben bestätigen. Da das Display aber selber keine Daten sendet, ist es nun sinnvoll ein weiteres Device anzulegen, welches Daten sendet. Dies erleichtert das spätere Einrichten unter FHEM. Zum Einsatz kann nun ein System-Wert kommen, welcher kontinuierlich an  FHEM gesendet wird. 

Dazu einfach unter FHEM ein neues Device einrichten. Siehe Bild.​

Nachdem ihr durch "Submit" die Eingaben bestätigt habt, könnt ihr zum Testen das Board erneut neustarten. Es sollten nun die ebene eingegebenen Zeilen auf dem Display erscheinen. 

Das LCD ist nun in ESP Easy fertig eingerichtet. Damit dies später auch in FHEM gesteuert werden kann, kann man unter dem Reiter "Config" die Verbindung zu FHEM aufbauen. Mehr dazu in meinem Blog-Beitrag.

Einrichtung unter FHEM

Habt ihr den kleinen Trick mit den Systeminfos gemacht, sollte das WeMos-Board nun automatisch in FHEM eingerichtet sein.

Der automatisch vergebene Name kann nun geändert werden.

rename ESPEasy_WeMos_LCD_rssi WeMos_LCD

Wurden keine sendenden Devices eingerichtet, kann das Board natürlich auch manuell eingerichtet werden. Dazu einfache folgenden Befehl in FHEM eingeben.

define WeMos_LCD 192.168.2.144 80 espBridge WeMos-LCD_LCD​

Die Syntax lautet dabei wie folgt:

​define <name> ESPEasy <ip|fqdn> <port> <IODev> <identifier>

Der <name> kann frei gewählt werden. Wichtig ist, dass ihr die IP-Adresse des WeMos-Boards angibt und als Port 80 nimmt. Der Identifier muss folgenden Aufbau haben: <esp name>_<esp device name>. In meinem Fall also WeMos-LCD_LCD.

Da das LCD selber keine Daten sendet, wird es unter FHEM als "absent" angezeigt. Aber keine Sorge, Befehle von FHEM empfängt das Board trotzdem.

Steuern des Displays

Das eingerichtete Device stellt nun ein paar Befehle zur Verfügung um das LCD zu steuern.

Text ans LCD senden

Das Display lässt sich nun über das eingerichtete Device mit Text befüllen. Der Befehl dazu hat folgende Syntax:

set WeMos_LCD <Reihe> <Zeichen> <Text>​

Zum Beispiel das Wort "Hallo" in der ersten Zeile beginnend beim ersten Zeichen:

set WeMos_LCD 1 1 Hallo​

LCD löschen

Das LCD bzw. den Text löschen, kann man mit folgendem Befehl:

set WeMos_LCD lcdcmd clear​

LCD an- / ausschalten

Das LCD bzw. die Hintergrundbeleuchtung lässt sich wie folgt an- bzw. ausschalten:

set WeMos_LCD lcdcmd on
set WeMos_LCD lcdcmd off

Displayhelligkeit

Habt ihr, wie oben beschrieben, die kleine Hardwareanpassung vorgenommen, so könnt ihr nun über das DLCD-Device die Helligkeit der Hintergrundbeleuchtung regeln. Dies geschieht über ein PWM-Befehl.

set WeMos_LCD pwm <GPIO> <level>​

In meinem Fall habe ich den D3 verwendet. Dies entspricht GPIO0. Über den obigen Befehl kann man nun die Helligkeit regeln. Das Helligkeitslevel kann dabei theoretisch Werte von 0 bis 4095 haben. In meinem Fall gab es jedoch schon ab ca. 1000 keine Helligkeitssteigerung mehr. 

set WeMos_LCD pwm 0 400

Vor- und Nachteile

Die Einrichtung des ESP-Easy-Devices erleichtert das Steuern des Displays schon enorm. Es lässt sich durch einfache set-Befehle das LCD bedienen. Der Nachteil ist jedoch, dass sich leider keine ganzen Sätze an das Display senden lassen. Selbst der Einsatz von Klammern oder Anführungszeichen hat nicht geholfen.

set WeMos-LCD 1 1 "Hallo du da im Radio"​
set WeMos-LCD 1 1 'Hallo du da im Radio'
set WeMos-LCD 1 1 (Hallo du da)

Es wird immer nur das letzte Wort mit dem entsprechenden Sonderzeichen an das Display gesendet. Schade.

Ich habe mir also ein paar Gedanken gemacht, um dieses Problem zu beheben. Aber dazu später mehr.

DLCD - Der Helfer für LCDs

Damit das Steuern von LCDs noch einfacher klappt, hat der FHEM-Forum-User "epsrw1" das Modul "DLCD" programmiert und der FHEM-Community zur Verfügung gestellt.

Mit Hilfe des Moduls lassen sich die Reihen eines Displays als Readings anzeigen und durch Attribute mit Inhalt füllen.​ Durch diverse weitere Attribute lassen sich LCDs auch direkt vom DLCD-Device steuern.

Aktuell (April 2017) steht das Modul jedoch noch nicht über das offiziellen FHEM-Update bereit, sondern muss manuell aus dem Forum heruntergeladen werden. Ihr erhaltet die Modul-Datei als Anhang im ersten Forums-Post (Info: Ihr müsst registriert sein, um die Datei herunterladen zu können) 

Die Datei "39_DLCD.pm" müsst ihr dann in euren FHEM-Installationsordner in den Ordner FHEM kopieren und FHEM anschließend neu starten. 

Anschließend könnt ihr in FHEM ein entsprechendes Device vom Type DLCD definieren:

define FL_LCD DLCD​

Anschließend müssen nun noch ein paar benötigte Attribute gesetzt werden.

attr FL_LCD dlcdPhysicalRows 4;
attr FL_LCD dlcdRows 8;

Zum Einen muss dem Device mitgeteilt werden, wie viele physikalische Reihen das Display besitzt. In meinem Fall vier. Des Weiteren kann man nun sagen, wie viele Reihen man mit Text befüllen möchte. Ich habe mich für acht Reihen entschieden. Da dies mehr Reihen sind, als das Device anzeigen kann, kann man sich für ein automatisches durchscrollen entscheiden. Dies kann mit folgendem Attribut aktiviert werden:

attr FL_LCD dlcdScrolling​ 1

Anschließend könnt ihr durch das Setzen von drei Attributen jede der definierten Textzeilen mit Leben füllen.

Attribut

Erklärung

Beispiel

dlcdLine<NR>

Inhalt der Textzeile, %NR% gibt dabei das Reading an, welches mit dem Attribut dlcdVal<NR> definiert wird.

Wohnzimmer: %1%

dlcdVal<NR>

Definition evtl. gewünschter Readings

WZ_Temperatur:state

dlcdVal<NR>formatnum

Formatierung des Readings: <Gesamtanzahl der Ziffern>+<Nachkommastellen>

2+1

dlcdVal<NR>formatstring

Formatierung des Reading mit sprintf-Syntax, setzt dlcdVal<NR>formatnum außer Kraft.

%03f

Mehr Infos im FHEM-Wiki. Ich habe die Attribute wie folgt gesetzt:

Die durch die Attribute gesetzten Textzeilen erscheinen nun nach kurzer Zeit als Reading. Für jede Zeile ein extra Reading. Hier kann man dann direkt kontrollieren, ob die Attribute alle wie gewünscht gesetzt wurden.

Die Linien-Readings werden nun bei jeder Wertänderung automatisch aktualisiert. 

Solltet ihr das Srollen aktiviert haben, ändert sich nun das Reading "scrollingState" im regelmäßigem Abstand. Jede Zahl steht dabei für ein unterschiedliches Fenster an Zeilen (in meinem Fall vier Zeilen). Bei acht eingerichteten Zeilen gibt es demnach acht unterschiedliche Fenster: 1234 - 2345 - 3456 - 4567 - 5678 - 6781 - 7812 - 8123. Diese "Sichtfenster" werden nun im zehn Sekundentakt durchgescrollt. 

Die Hauptaufgabe des DLCD-Moduls liegt darin, die Textzeilen ansprechend darzustellen und somit einfacher steuern zu können. Damit die gesetzten Textzeilen jedoch auch an ein wirkliches LCD weitergeleitet werden, ist ein weiteres Attribut notwendig. Mit dem Attribut "dlcdTriggerCmd" lässt sich der Befehl festlegen, welcher bei einem Event (also eine Zeilenänderung) abgesetzt werden soll.​ Dabei kann der Platzhalter %L% für die aktuelle Textzeilennummer und %T% für den aktuellen Text verwendet werden. 

Für das oben eingerichteten ESP Easy Device (WeMos_LCD) kann das Attribut demnach wie folgt lautet:

attr FL_LCD dlcdTriggerCmd set WeMos_LCD lcd %L% 1 %T% ​

Nun wird bei jeder Textänderung dieser Befehl abgesetzt und somit das LCD mit dem gewünschten Text befüllt. Doch genau hier macht uns nun der oben beschriebene Nachteil einen Strich durch die Rechnung. Geht man davon aus, dass die erste Zeile nun an das LCD geschickt werden soll, dann wird aufgrund des Attributs "dlcdTriggerCmd", folgender Befehl gesendet:

set WeMos_LCD lcd 1 1 Wohnzimmer: 21.9​

Wie oben schon erwähnt, kommt nur das letzte Wort beim LCD an, in diesem Fall also nur der Wert 21.9. Um diese Eigenheit zu umgehen, habe ich mir eine kleine Routine zusammengebastelt. 

Hilfs-Routine zum Senden ganzer Sätze mit DLCD​

Um ganze Sätze über DLCD an das Display zu senden, habe ich mir zwei kleine Routinen geschrieben. Diese wird einfach in die Datei "99_myUtils.pm" geschrieben.

Eine Routine erlaubt das einfache Senden eines Satzes an eine bestimmte Zeile auf dem Display. Damit bei langen Sätzen kein Umbruch auf die nächste Zeile erfolgt, habe ich ein Schutzmechanismus eingebaut.

sub sendLCDSatz($$$){
my ($reihe, $zeichen, $sendText) = @_;
my @array;
my @laenge;

# Nachricht in Wörter aufsplitten
@array=split(/ /,$sendText);

# Erstes Wort senden und Länge ermitteln
fhem("set WeMos_LCD lcd $reihe $zeichen $array[0]");

$laenge[0] = length($array[0]);

# Länge der Wörter ermitteln und restlichen Satz schicken
for (my $i = 1; $i < @array; $i++) {
$laenge[$i] = length($array[$i]);
$zeichen = $zeichen + $laenge[$i-1] + 1;
if($zeichen > 20) {return 0};
fhem("set WeMos_LCD lcd $reihe $zeichen $array[$i]");
}

return NULL;}

Der Subroutine übergibt man die gewünschte Zeile ($reihe), gewünschte Startposition ($zeichen) und den zu sendenden Text ($sendText). Zusätzlich zu diesen drei Variablen ist ein Array definiert, welches die einzelnen Wörter des Satzes speichern soll und eine Variable für die Länge eines Wortes, damit die richtigen Postionen berechnet werden können. 

Damit die Wörter einzeln an das LCD gesendet werden können, wird der Satz in seinen einzelnen Wörter gesplittet.

Zu Beginn wird das erste Worte direkt an das LCD gesendet und dessen Länge abgespeichert.​ Anschließend wird in einer for-Schleife die Länge der anderen Wörte abgespeichert. Die aktuelle Position auf dem Display wird dann aktualisiert, in dem die Länge der vorigen Wortes plus eins für das Leerzeichen und die Wörter nach und nach entsprechend ihrer Länger verschoben an das LCD gesendet.

Die zweite Routine ist extra dafür da, die Zeilen aus dem DLCD-Device an das Display zu senden. Diese Sätze bestehen immer aus zwei Wörtern, der Name und das Reading selbst.

Zum Beispiel "Wohnzimmer: 21.9". Das erste Wort wäre dann "Wohnzimmer:" und das zweite Wort "21.9". Die Routine beschränkt sich also auf das Senden von zwei Wörtern. 

Bevor ich jedoch beginne die Routine zu erklären, werde ich etwas auf die Funktionsweise vom DLCD-Modul eingehen. Dadurch, dass das automatische Scrollen aktiviert ist, muss bei jeder Änderung des "Sichtfensters" alle Zeilen neu geschrieben werden. Das Modul ruft also bei einem vierzeiligen Display vier mal den Schreibbefehl auf, welcher mit dem Attribut "dlcdTriggerCmd" gesetzt wurde.

sub sendLCDInfo($$){
my ($reihe, $sendText) = @_;
my @array;

# Nachricht in Wörter aufsplitten
@array=split(/ /,$sendText);

# Name des Reading senden
fhem("set WeMos_LCD lcd $reihe 1 $array[0]");

# Wert des Readings
fhem("set WeMos_LCD lcd $reihe 16 $array[1]");

return NULL;}

Der Subroutine "sendLCDInfo" müssen zwei Argumente übergeben werden. Zum Einen die zu beschreibende Textzeile ($reihe) und zum Anderen den Inhalt ($sendText). Zuerst wird wieder die zu sendende Nachricht aufgesplittet. 

Anschließend wird das erste Wort an das LCD gesendet und danach das zweite Wort etwas versetzt. In meinem Fall an die 16. Stelle. Dies habe ich gemacht, damit die Readings alle untereinander stehen. Solltet ihr ein kleineres Display haben, so müsst die Stelle natürlich anpassen.

Subroutine für DLCD verwenden

Nachdem es nun durch die beiden Subroutinen möglicht ist ganze Sätze an das Display senden zu können, kann man diese Subroutine nun auch im DLCD-Device verwenden. Dazu einfach den Aufrufe-Befehl der Routine als "dlcdTriggerCmd" setzen.

Da zwei Subroutinen erstellt wurden, könnt ihr euch nun entscheiden, welche Subroutine ihr verwenden wollt. Die Subroutine "sendLCDSatz" sendet die Zeilen unformatiert an das Display. Die Subroutine "sendLCDInfo" führt vor dem Senden eine kleine Formatierung durch, indem die Werte der Readings untereinander geschrieben werden.

set FL_LCD dlcdTriggerCmd {sendLCDSatz(%L%, 1, "%T%")}​
set FL_LCD dlcdTriggerCmd {sendLCDInfo(%L%, "%T%")}​

Damit das Scrollen nun reibungslos funktioniert, muss dem DLCD-Device noch der Befehl zum Löschen des Displays mitgeteilt werden. Dies geschieht über das Attribut "dlcdClearAllCmd".

attr FL_LCD dlcdClearAllCmd ​set WeMos_LCD lcdcmd clear

Damit euch nun das LogFile nicht voll geschrieben wird, könnt ihr dies durch folgendes Attribut verhindern:

attr WeMos_LCD verbose 0​

Mein Alltagseinsatz

Ich persönlich verwende TabletUI um Messwerte visuell darzustellen. Das Anzeigen auf dem LCD ist für mich also zur Zeit nur eine kleine Spielerei. Dennoch denke ich, dass ich dem LCD in Verbindung mit DLCD und FHEM Potential steckt. Zum Beispiel ein kleiner Tischwecker mit Uhr und kleines Info-Display. Ich denke ich werde in der Zukunft noch einiges mit LCDs anstellten und dies natürlich mit euch teilen.

​Bis dahin hoffe ich jedoch, euch die Benutzung eines LCDs mit FHEM interessant erklärt zu haben und bin natürlich auf interessante Ideen eurerseits gespannt. 

]]>
https://waschto.eu/statusdisplay-mit-esp-easy-dlcd-und-fhem/feed 4 2548
RGB-Ambientlicht im Eigenbau https://waschto.eu/rgb-ambientlicht-im-eigenbau https://waschto.eu/rgb-ambientlicht-im-eigenbau#comments Fri, 24 Mar 2017 21:22:23 +0000 http://waschto.eu/?p=2376 .tve_more_tag {display: none !important}Jeder der sich mit Smart-Home beschäftigt, wird früher oder später auf die Lampen aus der Philips-Hue Reihe stoßen. Mittlerweile gibt es ein breites Angebot. Beginnend bei den einfachen Lampen mit E27 Fassung bis hin zu kompletten Ambient-Leuchten wie die Philips Living Colors Iris. Sale Philips Hue White LED Lampe E27 weiterlesen →]]> Jeder der sich mit Smart-Home beschäftigt, wird früher oder später auf die Lampen aus der Philips-Hue Reihe stoßen. Mittlerweile gibt es ein breites Angebot. Beginnend bei den einfachen Lampen mit E27 Fassung bis hin zu kompletten Ambient-Leuchten wie die Philips Living Colors Iris.

Sale
Philips Hue White LED Lampe E27 Erweiterung, dimmbar,...

Philips - Haushaltswaren - Italienisch, Deutsch, Französisch, Englisch, Spanisch

19,95 EUR - 1,74 EUR 18,21 EUR
Sale
Philips Living Colors Iris, EEK A, Energiesparende...

Philips - Haushaltswaren - Italienisch, Deutsch, Französisch, Englisch, Spanisch

129,00 EUR - 65,40 EUR 63,60 EUR

Letzte Aktualisierung am 27.05.2017 / Affiliate Links / Bilder von der Amazon Product Advertising API

Aber leider sind diese Lampen meistens etwas teurer und lassen sich meist nicht ohne zusätzlicher Bridge in FHEM einbinden.

Aus diesem Grund möchte ich euch in diesem Beitrag gerne zeigen, wie ihr relativ kostengünstig eure eigene Ambient-Beleuchtung bauen könnt und diese in FHEM einbinden und somit steuern könnt.

Grundidee

Ich hatte mir bereits vor Jahren eine einfach RGB-Lichtkugel von Tschibo gekauft. Im eingeschalteten Zustand hat sie den RGB-Farbraum durchlaufen und durch einen Knopf konnte man bei der gewünschten Farbe stoppen. Für den Anfang hat mir das auch gereicht, nur als ich immer mehr ins Thema FHEM eingestiegen bin, kam mir irgendwann der Wunsch, diese Lampe etwas smarter zu machen.

Mein Ziel war es, die Lampe in FHEM einzubinden und sie somit darüber steuern zu können. Mit der aktuell verbauten Technik war dies leider nicht möglich. Bevor ich mir also eine Alternative überlegt habe, habe ich eine Liste der Anforderungen erstellt.

  • Ansteuerung einer oder mehrer RGB-LEDs
  • Einbinden über das heimische WLAN, damit kein weiteres Gateway nötig ist
  • Platzsparend
  • Flexibel in der Ansteuerung und einfaches Einbinden in FHEM

Umsetzung

Mein Gedanke fiel dabei sofort auf ESP-Easy. Die Administrationssoftware für ESP-Bausteine hat bereits eine Vielzahl an Sensoren und Aktoren implementiert. Dank des ESP-Bausteins lassen sich diese zudem einfach ins eigene Heimnetz einbinden. Des Weiteren existieren bereits Module für FHEM um diese auch hier einbinden und steuern zu können. Also beste Vorraussetzung für meine eigene RGB-Ambientbeleuchtung. Da ich zuhause noch ein paar WeMos D1-Mini-Pros habe, habe ich mich für diesen als Herzstück für die RGB-Ambientleuchte entschieden. Es sind natürlich auch andere ESP-Module möglich. Wichtig ist, dass ihr mindestens drei PWM-Ausgänge habt. Je nach Anzahl der LEDs.

WEMOS D1 mini Pro *16 MB Flash* ESP 8266 Node MCU NodeMCU...

WeMos - Elektronik

Derzeit nicht verfügbar

Letzte Aktualisierung am 27.05.2017 / Affiliate Links / Bilder von der Amazon Product Advertising API

Damit die Lampe später auch eine gewisse Helligkeit liefern kann, habe ich mich für eine High-Power-RGB-LED entschieden. Dimmen kann man ja softwaretechnisch später immer noch.

Highpower LED 3W RGB auf PCB, rot grün blau

world-trading-net - Elektronik

Derzeit nicht verfügbar

Letzte Aktualisierung am 27.05.2017 / Affiliate Links / Bilder von der Amazon Product Advertising API

Aufgrund der hohen Leistung der LED, ist ein direktes Steuern über den ESP-Chip leider nicht möglich. Bevor ich mir nun eine Transistorschaltung mit entsprechenden Vorwiderständen (je nach Farbe unterschiedlich) aufbaue, habe ich mich auf die Suche nach einer Konstantstromquelle gemacht. Die LED benötigt je Farbe bei maximaler Helligkeit ca. 350mA. Durch eine PWM-gesteuerte (Pulsweitenmodulation) Konstantstromquelle wäre ein Dimmen und somit ein Mischen der Farben möglich, ohne auf die unterschiedlich benötigten Spannungen der LED-Farben achten zu müssen. Fündig wurde ich auf eBay. KT-Electronic bietet eine 300mA Konstantstromquelle an, welche man über PWM dimmen kann. Des Weiteren sind sie für einen großen Spannungsbereich einsetzbar (Input: 6-30V; Output: 0-30V), sodass man mit denen auch größere Projekte (mehr LEDs) problemlos realisieren kann. Da ich jede Farbe getrennt steuern möchte, habe ich mir drei von diesen Quellen besorgt.

Da die Ausgänge der WeMos-Bausteine auf 3,3V laufen, kann es am PWM-Eingang der Konstantstromquelle zu Problemen und Fehlinterpretationen kommen. Um dies vorzubeugen, habe ich mich für den zusatzlichen Einsatz von Pegelwandlern (optional) entschieden. Diese regeln die 3,3V-Pegel des WeMos-Bausteins auf 5V-Pegel, welche dann problemlos von der Konstantstromquelle als HIGH-Pegel erkannt werden. Auch hier wurde ich wieder bei eBay fündig - 3,3V zu 5V Pegelwandler.

Ein Weiterer wichtiger Punkt war die Stromversorgung. Der WeMos-Baustein benötigt 5V und die Konstantstromquellen mindestens 6V (bei einer LED). Um die Lampe in Zukunft eventuell durch zusätzliche LEDs erweitern zu können, habe ich mich dazu entschieden, die Konstantstromquellen mit 12V zu betreiben. Dies erlaubt mir den Einsatz von bis zu drei LEDs in Reihe. Um den WeMos-Baustein nun mit seinen benötigten 5V zu versorgen, habe ich einen Step-Down-Spannungswandler eingesetzt, der mir die 12V Eingangsspannung auf 5V herunterregelt, ohne groß Abwärme zu produzieren. Was bei einem einfachen Spannungsregler 7805 leider der Fall wäre. Auch hier wurde ich wieder bei eBay fündig - LM2596 DC Step Down Spannungswandler.

Als Steckernetzteil habe ich eins verwendet mit 12V und 2A. Je nach Anzahl der LEDs ist eventuell eine Netzteil mit mehr Leistung notwendig, bzw. mit einer höheren Ausgangsspannung. Der Strom ist bei maximaler Helligkeit immer 3x300mA (je nach Konstantstromquelle). ​Mit 2A hat man also genug Leistung zum Betreiben der High-Power-LEDs und der zusätzlichen Module. Bei den verwendeten Konstantstromquellen kann man die benötigten Kenndaten des Netzteils aus folgender Tabelle entnehmen:

Ausgangsspannung Netzteil (mind.)

max. Anzahl LEDs

(Reihenschaltung)

benötigter Ausgangsstrom

6V

1

3x 300mA + 100mA = 1A

11V

3

3x 300mA + 100mA = 1A

32V

10

3x 300mA + 100mA = 1A

Sale
LE Trafo/Netzadapter für LED 12V DC, AC 100-240V...

Lighting EVER

17,99 EUR - 10,00 EUR 7,99 EUR

Letzte Aktualisierung am 27.05.2017 / Affiliate Links / Bilder von der Amazon Product Advertising API

​Je mehr LEDs in Reihe geschaltet werden, desto mehr Eingangsspannung benötigen die Konstantstromquellen um die 300mA bereitstellen zu können. Der benötigte Ausgangsstrom des Netzteils ist unabhängig von der Anzahl der LEDs. Durch den Einsatz von drei Konstantstromquellen mit jeweils 300mA empfehle ich ein Netzteil von mindestens 1A, damit noch genug Leistung für die anderen Modulen zur Verfügung steht. Wer mehr Infos zum Thema LED-Reihenschaltung haben möchte, dem empfehle ich die Seite von ledhilfe.de.

Aufbau der Hardware

Wie oben schon erwähnt, besteht der Aufbau aus einigen Modulen.

Damit alles so funktioniert wie es soll, müssen diese nun entsprechend miteinander verbunden werden. Folgendes Blockschaltbild zeigt den Zusammenhang der einzelnen Module.

Das Steckernetzteil versorgt die komplette Schaltung mit Spannung. Über den Step-Down-Wandler werden aus diesen 12V die benötigten 5V für den WeMos-Baustein. Die Konstantstromquelle wird direkt mit den 12V versorgt. Der WeMos-Baustein erzeugt ein PWM-Signal, welches über ein Pegelwandler die Konstantstromquelle steuert, welches wiederrum die LED mit dem benötigten Strom versorgt.

Im folgenden werde ich die genaue Verdrahtung der einzelnen Module näher beschreiben.

Steckernetzteil

Über das Steckernetzteil werden die drei Konstantstromquellen (rot, grün, blau) und der Step-Down-Wandler mit 12V Gleichspannung versorgt. Hier ist es wichtig, dass ein Netzteil verwendet wird, welches genügend Leistung zur Verfügung stellt. Siehe Tabelle weiter oben.

Step-Down-Wandler

Wie oben schon erwähnt, bekommt der Step-Down-Wandler direkt die Ausgangsspannung des Netzteils als Eingangsspannung. In meinem Fall also die 12V.

ACHTUNG: Bevor ihr mit der weiteren Verdrahtung fortfahrt, stellt über das kleine blaue Potentiometer die Ausgangsspannung auf 5V.

Solltet ihr mit einer höheren Versorgungsspannung arbeiten, müsst ihr darauf achten, dass der Spannungsregler (LM2596S) ausreichend gekühlt ist. Die Kühlkörper für den Raspberry funktionieren dafür sehr gut.

Rydges - Kühlkörper 2x Kupfer für Raspberry Pi 3...

Rydges Media Technology - Elektronik

6,99 EUR

Letzte Aktualisierung am 27.05.2017 / Affiliate Links / Bilder von der Amazon Product Advertising API

WeMos D1 Mini Pro

Das Herzstück der Ambientlampe ist der WeMos D1 Mini Pro. Dieser kümmert sich später darum, dass die Lampe sich ins heimische Netztwerk einwählt und die Lampe somit über FHEM steuerbar ist. Mit Spannung wird der Chip über die 5V Ausgangsspannung des Step-Down-Wandlers. Dazu einfach den Ausgang des Wandlers mit dem 5V- und GND-PIN vom WeMos-Baustein verbinden (siehe Schaltplan).

Vom WeMos-Baustein werden die Dateinausgänge D6, D7 und D8 verwendet. Diese gehen jeweils auf einen Eingang (LOW-Level) des Pegelwandlers. Diese drei digitalen Ausgänge steuern später jeweils eine Farbe (rot, grün, blau) der High-Power-LED.

Des Weiteren wird der 3,3V-Ausgang des WeMos-Chips benötigt. Dieser versorgt den Pegelwandler mit den benötigten 3,3V.

Pegelwandler (optional)

Der Pegelwandler wandelt die 3,3V-Pegel vom WeMos-Baustein zu 5V-Pegel, welche dann für Regelung der Konstantstromquellen verwendet wird. Die hier verwendeten Konstantstromquellen können jedoch auch mit den 3,3V-Pegel arbeiten (L-Pegel = 0V und H-Pegel = 2,5 - 5V). Damit ich in der Zukunft eventuell andere Konstantstromquellen einsetzen kann, habe ich mich jedoch für den Pegelwandler entschieden.

Damit der Pegelwandler funktioniert, bekommt er die 3,3V vom WeMos-Baustein für die Low-Level-Seite und die 5V vom Step-Down-Wandler. Zusätzlich werden beide Seiten noch an GND angeschlossen. Entweder an einen GND-Pin vom WeMos-Baustein oder an den GND-Pin des Step-Down-Wandler-Ausgang.

Wie oben schon erwähnt, bekommt der Pegelwandler die Signale der digitalen Ausgänge D6-D8 als Eingangssignal. Die entsprechenden Ausgänge des Pegelwandlers werden dann jeweils auf ein Dim-Eingang einer Konstantstromquelle geführt.

Konstantstromquelle

Die Konstantstromquelle wird mit der Ausgangsspannung vom Netzteil versorgt (In+ und In-). Das Signal für den Dim-Eingang kommt vom Pegelwandler bzw. vom WeMos-Baustein.

Auf der Ausgangsseite der Konstantstromquellen wird die LED angeschlossen (LED+ und LED-). An jeder Konstantstromquelle wird jeweils eine Farbe der LED angeschlossen.

High-Power-RGB-LED

Die High-Power-LED wird an den Ausgang der Konstantstromquelle angeschlossen. Jeweils eine Farbe an einem Ausgang. Hier ist man relativ frei, welche Farbe man an welcher Konstantstromquelle anschließt. Ihr solltet sptäter nur wissen, welcher digitale Ausgang welche Konstantstromquelle steuert, damit eine softwaretechnische Zuweisung ohne herumprobieren möglich ist.

Beim Anschließen ist es jedoch wichtig, dass der Minus-Anschluss der LED auch an den entsprechenden Minus-Ausgang der Konstantstromquelle angeschlossen wird (siehe Schaltplan).

Zusammenbau

Da die Lichtkugel von Tschibo leider nicht so ohne weiteres zu öffnen war, habe ich mir im Bauhaus eine einfache Glas-Lichtkugel-Lampe gekauft und den E14-Lampen-Sockel entfernt. Mit bisschen Gefummel und Heißkleber habe ich dann die komplette Technik unterbringen können. Unter der High-Power-LED habe ich noch ein kleines Stück Aluminiumblech mit Wärmeleitpaste angebracht. Die Befestigungsklammer für die Glaskugel hilft zusätzlich für die Wärmeabfuhr.

Ich habe die beiden Kondensatoren vom Step-Down-Wandler durch neue ersetzt und diese dann abgewinkelt eingelötet damit sie sich nicht im Lichtkegel befinden.

Software

ESP Easy installieren

Wie oben schon erwähnt, fiel meine Entscheidung auf ESP Easy. Leider liefert die Software kein Modul für RGB-LEDs mit. Da die Community rund um ESP Easy schon recht groß ist, machte ich mich auf die Suche nache der passenden Erweiterung.

Fündig wurde ich im FHEM-Forum. Der Entwickler "dev0" hat das ESP Easy Plugin "Lights" entwickelt, welches das Steuern von RGBWW-LEDs ermöglicht. Das Plugin lässt sich von GitHub herunterladen.

Zusätzlich muss natürlich die ESP Easy Software selbst herunter geladen werden. Dies könnt ihr auf der Seite des Herstellers herunterladen. Für diesen Beitrag wurde die Version R147_RC8 verwendet.

Die benötigte Datei "_P123_LIGHTS.ino" des Plugins "Lights" muss dann einfach in den Ordner "Source/ESPEasy" kopiert werden. Ihr könnt nun den WeMos-Chip über die Arduino-IDE auf den Chip flashen (einfach die Datei "Source/ESPEasy/ESPEasy.ino" mit der Arduini IDE öffnen) oder ihr benutzt das ESP-Flash-Tool. Ich persönlich empfehle euch das Verwenden des Tools, da hier nicht darauf geachtet werden muss, dass die benötigten Libarys und Treiber in der Arduino IDE korrekt geladen wurden. Des Weiteren ist das Benutzen des Tools nicht so anfällig für Anwenderfehler.

Damit man jedoch das Tool verwenden kann, ist die entsprechende bin-Datei notwendig. FHEM-Forum-Mitglied "Waldmensch" stellt diese bin-Datei für 1024kb-Module im Forum zur Verfügung. Diese kann problemlos für die WeMos-Bausteine verwendet werden. Damit diese mit dem Flash-Tool verwendet werden kann, einfach die vorhandene Datei "ESPEasy_R147_1024.bin" in "ESPEasy_R147_1024_old.bin" umbenennen und die aus dem Forum heruntergeladenen bin-Datei in "ESPEasy_R147_1024.bin" umbenennen.

Nachdem der WeMos-Chip mit dem PC verbunden wurde, kann mit Hilfe der Datei "flash.cmd" das Flashen gestartet werden.

HINWEIS: Ich hatte schon mehrere Blog-Leser, die Probleme beim Flashen hatten. Grund war meist der Einsatz eines minderwertigen USB-Kabels.

Der COM-Port muss natürlich entsprechend angepasst werden. Welcher Port aktuell verwendet wird, könnt ihr in Windows über den Gerätemanager herausfinden. Sobald der Flash-Vorgang abgeschlossen ist, bekommt ihr eine entsprechende Meldung.

ESP Easy einrichten

Nachdem das Flashen erfolgreich war, kann mit dem Einrichten begonnen werden. Dazu verbindet man sich mit dem neu eröffneten Access Point vom WeMos-Board - Passwort "configesp". In meinem Fall mit dem Namen "ESP_0". Startet man nun den Browser öffnet sich die Konfigurationsseite. Sollte dies nicht der Fall sein, kann diese auch über die Eingabe der IP-Adresse geöffnet werden. In meinem Fall "192.168.4.1". Über die Konfigurationsseite kann das WeMos-Board nun mit dem heimischen WLAN verbunden werden. Mehr Infos dazu auf meinem Beitrag zum Thema ESP Easy.

Nachdem sich nun der WeMos-Baustein im eigenen WLAN befindet, kann mit dem eigentlichen Einrichten begonnen werden.

Unter dem Reiter "Config" wird die Verbindung zur FHEM-Installation eingerichtet. Wichtig ist hier, dass als Protokol "FHEM HTTP" ausgewählt wird und unter Controller IP die IP-Adresse des Raspberrys auf dem FHEM läuft eingetragen wird. Des Weiteren muss unter "Name" ein eindeutiger Name vergeben werden.

Weiter geht es mit dem Reiter "Devices". Hier wird nun die High-Power-RGB-LED definiert. Als Device wird das Plugin "Lights" ausgewählt.

Da ich nur eine normale RGB-LED verwende, habe ich nur die RGB Channels aktiviert. Wer möchte, kann natürlich auch die WW- und CW-Channels aktivieren. Wichtig ist, dass die verwendeten Ausgänge angegeben werden. Die digitalen Ausgänge D6-D8 sind die Gpios 12, 13 und 15. Ein komplette Auflistung der Zuordnung könnt ihr im Reiter "Hardware" einsehen.

Die Einrichtung von ESP Easy ist nun abgeschlossen und es kann mit der Einrichtung in FHEM begonnen werden.

Einrichtung unter FHEM

Wie ihr ein ESP-Device in FHEM definiert, könnt ihr in meinem Blog-Beitrag zu diesem Thema nachlesen. Folgende Schritte werden sich auf die anschließenden Konfigurationen und Anpassungen des ESP-Devices fokusieren. Das eigentliche Einbinden des ESP-Devices entnehmmt ihr deswegen bitte aus meinem Blog-Beitrag. Im Folgenden hat das eingerichtete ESP-Device den Namen "ESP_Lichtkugel". Nach dem automatischen Anlegen des ESP-Devices könnt ihr den Namen durch folgenden Befehl in "ESP_Lichtkugel" ändern.

rename ESPEasy_Lichtkugel_RGBWW ESP_Lichtkugel

Wer dieses Device bereits zum Steuern verwenden möchte, kann durch das Hinzufügen von ein paar Attributen die Steuerung etwas erleichtern.

attr ESP_Lichtkugel colorpicker HSVp;
attr ESP_Lichtkugel colorpickerCTww 2000;
attr ESP_Lichtkugel colorpickerCTcw 6000;
attr ESP_Lichtkugel devStateIcon { ESPEasy_devStateIcon($name) };
attr ESP_Lichtkugel mapLightCmds Lights;
attr ESP_Lichtkugel parseCmdResponse Lights;
attr ESP_Lichtkugel webCmd ct:pct:rgb:rgb ff0000:rgb 00ff00:rgb 0000ff:toggle:on:off;

Durch die Auswahl einer Farbe kann nun bereits getestet werden, ob die LED wie gewünscht funktioniert. Die Farbe lässt sich mit entweder über die Schaltflächen ändern oder über folgenden Befehl:

set ESP_Lichtkugel rgb 00ff00 5

Dieser Befehl ändert die Farbe zu Grün. Durch die optionale Angabe einer Zeit in Sekunden, stellt man die Zeitkonstante ein, mit der zur dieser Farbe gewechselt wird. In diesem Fall wechselt die Farbe also langsam (innerhalb von 5 Skunden) zur Farbe grün. Diese Funktion machen wir uns später für den automatischen Farbverlauf zu nutzen.

Dummy FL_Lichtkugel

Um etwas mehr Freiheit bezüglich der Konfiguration zu bekommen, habe ich ein Dummy angelegt, welches später die RGB-Ambientleuchte darstellt. Wer möchte, kann natürlich alle Anpassungen direkt am ESP-Device vornehmen, da ich dieses jedoch gerne "unberührt" lassen wollte, habe ich mich für den Umweg über einen Dummy entschieden. Da ich die ganze Technik in eine Glaskugel untergebracht habe, habe ich das Dummy "FL_Lichtkugel" genannt. Das FL steht dabei für den Standort Flur.

define FL_Lichtkugel dummy

Das nackte Dummy kann nun noch nicht sehr viel. Im Grunde kann es gar nichts. Ich habe mir deswegen ein paar Gedanken gemacht, was die Lichtkugel später alles können soll.

  • Automatischer Farbverlauf im RGB-Farbraum (Modus: Fade)
  • Farbauswahl vordefinierter Farben (Modus: Farbe)
  • Automatischer Farbverlauf mit einstellbarer Schnelligkeit
  • Ein / Aus (Modus: Off)
  • Steuern über Apples Homekit

Nachdem das Ziel definiert wurde, habe ich mich an die Konfiguration des Dummys gemacht. Damit in der Device-Overview die Kontrollelemente für die Steuerung erscheinen, habe ich folgende Attribute hinzugefügt:

attr FL_Lichtkugel readingList Zeit,rgb;
attr FL_Lichtkugel setList Zeit:slider,1,1,20 rgb:colorpicker,rgb state:Fade,Farbe,off;
attr FL_Lichtkugel webCmd state:Zeit:rgb:rgb FF0000:rgb 00FF00:rgb 0000FF:rgb FFFF00:rgb FFA500:rgb 8a2be2;

Diese Attribute bewirken nun, dass man direkt in der Device-Overvie den Modus (off, Fade, Farbe) über ein Drop-Down-Menü auswählen kann, die Schnelligkeit (Zeit, 0s - 20s) über einen Slider steuern kann, den Farbwert über ein Color-Picker-Feld aussuchen und vordefinierte Farben über Farbfelder anklicken kann.

Die über den Slider eingestellte Zahl, beschreibt das Reading "Zeit" mit dieser. Das Format ist dabei eine einfache Zahl - 0 bis 20. Für die späteren Hilfsdevices wird jedoch eine Zeitangabe im Format "hh:mm:ss" benötigt. Über das Attribut userReadings wird deswegen ein zusätzliches Reading mit dem Namen "Time" erstellt, welches die Zahl aus dem Reading "Zeit" in das gewünschte Format ändert.

attr FL_Lichtkugel userReadings Time {sec2time(ReadingsVal("FL_Lichtkugel","Zeit",0))}

Die Umwandlung passiert dabei in der Routine "sec2time". Das Anlegen dieser Routine geschieht später weiter unten.

Für das Optische (alias, Raum etc.) werden dann noch ein paar zusätzliche Attribute gesetzt.

attr FL_Lichtkugel alias Lichtkugel;
attr FL_Lichtkugel group Licht;
attr FL_Lichtkugel icon LED_Kugel;
attr FL_Lichtkugel devStateIcon {".*Fade:LED_Kugel_RGB .*off:LED_Kugel .*:LED_Kugel@#".ReadingsVal($name, "rgb", "ffffff")};
attr FL_Lichtkugel room Alexa,Flur,Homekit;
attr FL_Lichtkugel stateFormat state;

Die Raumauswahl ist natürlich euch überlassen. Wollt ihr jedoch, dass die Lampe später auch per Apples Homekit und Amazons Alexa steuerbar ist, solltet ihr die Lampe auch jeweils in den Raum "Homekit" und "Alexa" packen, damit diese Anleitung problemlos übernommen werden kann.

Der erfahrende FHEM-User wird schon gesehen haben, dass die ausgewählten Icons "LED_Kugel" und "LED_Kugel_RGB" keine offiziellen FHEM-Icons sind. Da FHEM kein passendes Icon für meine Lichtkugel bereitstellt, habe ich mir ein eigenes Icon erstellt. Wer möchte, kann sich diese Icon hier downloaden. Die beiden Dateien einfach auf den Raspberry in den Ordner "/opt/fhem/www/images/fhemSVG" kopieren und FHEM neustarten.

Das sieht nun zwar alles schon recht hübsch aus, jedoch sind die Schaltflächen noch ohne Funktion. Da kommen nun ein paar Hilfs-Devices und Routinen zum Einsatz.

atRGB - Hilfsdevice für den automatische Farbverlauf

Damit dem Dummy nun auch Leben eingehaucht wird, kommt unter anderem das at-Device "atRGB" zum Einsatz. Dieses at-Device sorgt im Modus "Fade" dafür, dass im Abstand der eingestellten Zeit (Reading Time) sich die Farbe der Lichtkugel automatisch ändert.

define atRGB at +*{ReadingsVal("FL_Lichtkugel","Time",0)} { 
my $Status = ReadingsVal("FL_Lichtkugel","state",0);
my $Zeit= ReadingsVal("FL_Lichtkugel","Zeit",0);
my $rgb = randomRGB();
if($Status eq "Fade") {
fhem("setreading FL_Lichtkugel rgb $rgb");
fhem("set ESP_Lichtkugel rgb $rgb $Zeit");}
}

Info: Ich empfehle euch zuerst ein at-Rohling zu definieren (define atRGB at 00:00:00 a) und dann über den DEF-Editor die finale Definition einzutragen.

Das at-Device wird kontinuierlich ausgeführt. Die Zeitkonstante ist dabei das Reading "Time" vom Dummy "FL_Lichtkugel". Ändert man also durch den Schieberegler vom Dummy die Zeit, so ändert sich der Widerholungsintervall des at-Devices.

Innerhalb des at-Devices werden dann zunächst drei Variablen erzeugt. Eine Variable enthält den ausgewähltem Modus vom Dummy - $Status. Die Variable "$Zeit" enthält die Zeitkonstante als reine Zahl. Die Variable "$rgb" enthält einen zufälligen RGB-Wert, welcher über die Routine "randomRGB" aus einem Farbwert-Pool ausgewählt wird. Mehr zur Routine und dessen Definition erfahrt ihr später weiter unten.

Befindet sich die Lichtkugel nun im Modus "Fade", wird das Reading "rgb" vom Dummy mit dem zufälligen Farbwert beschrieben. Damit die Lichtkugel selbst auch die Farbe annimmt, wird das ESP-Device auf die Farbe mit der Zeitkonstate (Zeit) gesetzt. Die Farbe der Lichtkugel ändert sich nun innerhalb der Zeitkonstante zur gewünschten Farbe.

Da die Zeitkonstante identisch ist mit dem Widerholungsintervall des at-Devices (Zeit = Time), startet das Faden zur neuen Farbe mit dem Erreichen der aktuell gewünschten Farbe. Es erfolgt somit ein automatischer Farbverlauf, solange wie der Modus "Fade" aktiv ist.

notifyRGB - Hilfsdevie zur Modi-Steuerung

Das notify "notifyRGB" sorgt dafür, dass je nach Modus die entsprechenden Hebel gesetzt werden, dass die Lichtkugel entsprechend reagiert.

define notifyRGB notify FL_Lichtkugel:.* {
my $Status = ReadingsVal("FL_Lichtkugel","state",0);
my $RGB = ReadingsVal("FL_Lichtkugel","rgb",0);
if($Status eq "off"){
fhem("set atRGB inactive");
fhem("setreading FL_Lichtkugel rgb 000000");
fhem("set ESP_Lichtkugel rgb 000000");}
elsif($Status eq "Farbe"){
fhem("set atRGB inactive");
fhem("set ESP_Lichtkugel rgb $RGB");}
elsif($Status eq "Fade"){
fhem("set atRGB active");}
}

Das notify reagiert auf eine Readings-Änderung vom Dummy-Device "FL_Lichtkugel". Ändert man also den Modus vom Dummy, so reagiert das Notify.

Zuerst werden wieder zwei Variablen definiert. Zum Einen der aktuelle Status (§Status) vom Dummy und zum Anderen der aktuelle Farbwert (§RGB).

Danach beginnen drei if-Abfragen, jeweils nach dem Status.

off

Farbe

Fade

  • das at-Device "atRGB" wird deaktiviert
  • der Farbwert vom Dummy und vom ESP-Device wird auf "000000" gesetzt
  • das at-Device "atRGB" wird deaktiviert
  • das ESP-Device wird auf die eingestellte Farbe gesetzt, welche durch den Color-Picker oder durch die Farbfelder ausgewählt wurde
  • das at-Device "atRGB" wird aktiviert - der automatische Farbverlauf beginnt.

sec2time - Routine zur Formatsumwandlung

Nachdem die benötigten Hilfsdevices eingerichtet wurden, können die benötigten Routinen eingerichtet werden. Diese werden in der Datei "99_myUtils.pm" geschrieben.

Die Rounte "sec2time" wandelt die einfache Zahl vom Reading "Zeit" in einen Zeitstring im Format "hh:mm:ss" um.

##### Zeit ##############

sub sec2time($)
{
my ($sec) = @_;
my $m = int($sec/60);
my $s = $sec - ($m * 60);
my $h = int($m/60);
my $m = $m - ($h * 60);
my $timestring = sprintf("%02d:%02d:%02d",$h,$m,$s);

return $timestring
}

randomRGB - Routine für die zufällige Farbwahl

Die Routine "randomRGB" wählt aus einer Auswahl von RGB-Farbwerten zufällig ein Farbwert und gibt diese zurück. Die Anzahl an Farbwerten kann nach belieben angepasst bzw. vergrößert werden.

###### RGB ##############

sub randomRGB()
{
my @rgbarray = ("FF0000","00FF00","0000FF","8A2BE2","FFA500","FF69B4","FFFF00");
my $Laenge = @rgbarray;

my $rgbneu = $rgbarray[int(rand($Laenge))];

return $rgbneu;
}

Wollt ihr andere Farbwerte im Farbverlauf haben, dann passt einfach die Werte vom Arra "rgbarray" an. Ihr könnt natürlich auch weitere Farbwerte hinzufügen.

Lichtkugel in Apples Homekit einbinden

Solltet ihr, wie ich auch Apples Homekit verwenden, dann könnt ihr natürlich auch die Lichtkugel darin integrieren. Im folgenden erkläre ich euch, wie ihr dies macht.

Solltet ihr die Homebridge (Schnittstelle zwischen Homekit und FHEM) noch nicht eingerichtet haben, dann solltet ihr meinen Blog-Beitrag dazu besuchen. Im folgenden ist die Homebridge zu eingerichtet, dass alle Geräte im Raum "Homekit" für Homekit berücksichtigt werden.

Wie ihr weiter oben schon bemerkt habt, befindet sich das Dummy-Device bereits in den Raum "Homekit". Damit das Dummy jedoch auch als Lampe erkannt wird, ist ein weiteres Attribut notwendig.

attr FL_Lichtkugel genericDeviceTyp light

Ich habe mich dazu entschieden, dass ich mit Apples Homekit die Lichtkugel auf in den Modus "Fade" versetzen und sie wieder ausschalten kann. Damit dies auch funktioniert, muss man dies mit Hilfe des Attributs "homebridgeMapping" Homekit mitteilen.

attr FL_Lichtkugel homebridgeMapping On=state,valueOn=/Fade/,valueOff=/off/,cmdOn=Fade,cmdOff=off

Für das Verständnis werde ich dieses Attribut nun ein bisschen erklären:

"On=state" - Das Reading "state" wird gesteuert.

​"valueOn=/Fade/,valueOff=/off/" - Gibt den Wert des Readings an, welches es haben muss, damit das Gerät als on bzw. off angezeigt wird.

"cmdOn=Fade,cmdOff=off" - Gibt an, auf was das Reading geschaltet werden soll, wenn es an bzw. ausgeschaltet wird.

Wenn ihr nun eure Homebridge neu startet, solltet die Lichtkugel bereits unter Apples Homekit angezeigt werden.

Lichtkugel mit Amazons Alexa steuern

Solltet ihr anstelle von Apples Homekit lieber auf Amazons Alexa setzen, dann geht dies auch relativ einfach. Voraussetzung ist hier jedoch, dass ihr Alexa bereits mit FHEM verbunden habt. Mehr zu diesem Thema auf meinem Blog. Ich persönlich habe meine ganzen Devices für Alexa in den Raum "Alexa" gepackt. Mit dem room-Attribut haben wir dies weiter oben schon erledigt.

Damit Alexa aber das Dummy richtig erkennt, sind auch hier wieder die beiden Attribute "genericDeviceTyp" und "homebridgeMapping" notwendig:

attr FL_Lichtkugel genericDeviceTyp light
attr FL_Lichtkugel homebridgeMapping On=state,valueOn=/Fade/,valueOff=/off/,cmdOn=Fade,cmdOff=off

Wenn ihr nun innerhalb der Alexa-App nach neuen Devices sucht, sollte die Lichtkugel auftauchen.


Ich hoffe ich konnte euch mein kleines Projekt verständlich näher bringen und euer Interesse wecken. Ich freue mich über jeden Nachbauer. Sollten fragen auftauchen, dann stellt sie mir gerne in den Kommentaren.

]]>
https://waschto.eu/rgb-ambientlicht-im-eigenbau/feed 2 2376
Verkehrsinfo und Traffic – Verkehrsmeldungen in FHEM einbinden https://waschto.eu/verkehrsinfo-und-traffic-verkehrsmeldungen-in-fhem-einbinden https://waschto.eu/verkehrsinfo-und-traffic-verkehrsmeldungen-in-fhem-einbinden#respond Sat, 18 Mar 2017 20:26:47 +0000 http://waschto.eu/?p=2300 weiterlesen →]]> Nach meinem Artikel über den Spritpreismonitor, wird der folgende Artikel sich ebenfalls an die Autofahrer unter euch richten. Ich werde euch zeigen, wie ihr Verkehrsmeldungen in FHEM einbindet, sie ansprechend im TabeltUI darstellt und euch jeden morgen die aktuellen Verkehrsmeldungen per Telegram oder Pushover auf euer Handy schicken lasst. 

Für die Verkehrsinfos stellt FHEM im Grunde zwei Module zur Verfügung, abgesehen von diversen Möglichkeiten über HTTPMOD. Zum Einen das Modul "Verkehrsinfo" und zum Anderen das Modul "TRAFFIC" zur Verfügung.

"Vekehrsinfo" basiert auf Verkehrsmeldungen diverser Quellen. Neben dem Beschränken auf einzelnen Autobahnen oder Bundesstraßen lassen sich auch ganze Bundesländer auswählen.

Das Modul "TRAFFIC" verfolgt einen anderen Weg. Anstatt Verkehrsmeldungen bestimmter Autobahnen anzuzeigen, berechnet das Modul "TRAFFIC" basierend auf den aktuellen Verkehr die Reisezeit einer bestimmten Strecke. So lässt sich zum Beispiel der Arbeitsweg angeben und dann die benötigte Reisezeit als Reading ausgeben.

  • Verkehrsinfo
  • TRAFFIC

Wie oben schon erwähnt, baut das Modul "Verkehrsinfo" auf die Stau- und Verkehrsmeldungen verschiedener Quellen auf. Aktuell werden folgende Quellen unterstützt:

Da die Filterung der gewünschten Meldungen bei den Quellen "hessenschau.de" und "radiosaw.de" umtsändlich über Attribute erfolgt, habe ich mich für "verkehrsinfo.de" als Quelle entschieden. Hier erfolgt die Filterung über die entsprechende Wahl der URL.

Vorbereitung

Damit die Abrage der Vekehrsinfos funktioniert, sind einige Vorbereitungen auf dem Raspberry notwendig. Um genau zu sein, sind die Perlmodule "HTML::TreeBuilder::XPath" und "libjson-perl" notwendig.

sudo apt-get install libxml-treebuilder-perl libhtml-treebuilder-xpath-perl
sudo apt-get install libjson-perl

Vor der Definition in FHEM sollte der Raspberry neugestartet werden.

sudo reboot

die passende URL

Wie schon erwähnt, definiert man das Modul über eine URL. Bevor mal also mit der Definition in FHEM beginnt, sollte man sich die passende URL raussuchen. Dazu einfach folgende URL aufrufen:

https://www.verkehrsinfo.de/httpsmobil/

Wählt man nun die gewünschte Straße bzw. das gewünschte Bundesland, erhält man in der Browserleiste die gewünschte URL. Für die Autobahn 5 (A5) lautet die URL wie folgt:

https://www.verkehrsinfo.de/httpsmobil/index.php?c=staulist&street=A5&lat=&lon=

Definition in FHEM

Mit dieser URL lässt sich nun das Modul definieren.

define VerkehrA5 Verkehrsinfo https://www.verkehrsinfo.de/httpsmobil/index.php?c=staulist&street=A5&lat=&lon= 3600

Die "3600" beschreibt dabei den Aktuallisierungsintervall, in der die Verkehrsmeldungen aktualisiert werden. In diesem Fall also alle 60 Minuten.

Nach einer kurzen Zeit erscheinen die Verkehrsmeldungen nun als Reading.

zusätzliche Attribute

Durch das Setzen von Attributen lassen sich die Verkehrsmeldungen etwas anpassen.

filter_exclude / filter_include

Mit den beiden Attributen "filter_exclude" und "filter_include" lassen sich die Verkehrsmeldungen filtern. Dabei werden die Verkehrsmeldungen nach den gesetzten Schlagwörtern durchsucht und entsprechend gefiltert.

Beide Attribute können auch gemeinsam verwendet werden.

attr VerkehrA5 filter_exclude Baustelle
attr VerkehrA5 filter_include Karlsruhe

In diesem Fall würden alle Meldungen bezüglich Baustellen rausgefiltert und des Weiteren nur Meldungen für Karlsruhe angezeigt. Beide Filter sind durch ein UND miteinander verknüpft. Ein Schlagwort, welches durch exclude rausgefiltert wurde, kann somit nicht über include wieder eingebunden werden.

Hat man sich zum Beispiel ein Device für die Verkehrsmeldungen in Baden-Würtemberg definiert, so lassen sich mit den Filter-Attributen auch nach bestimmten Autobahnen filtern.

attr VerkehrBW filter_include A8

Das oben gesetzt Attribut filtert zum Beispiel nach dem String "A8". Aber Achtung, diese neben der Autobahn "A8" wird nun auch zum Beisiel die Autobahn "A81" angezeigt, da der String "A8" ebenfalls in "A81" enthalten ist. Umgehen kann man dieses Problem durch eine kleiner Erweiterung des Attributs:

attr VerkehrBW filter_include A8[a-zA-Z]

Aber ich empfehle euch, lieber die entsprechende URL der gewünschten Autobahn für die Definition zu verwenden, als über die Filter-Attribute die Autobahn rauszufiltern. Die Filter-Attribute sind eher dazu da, die Meldungen zu filtern und zum Beispiel Dauerbaustellen aus den Meldungen zu entfernen.

Eine weitere Einsatzmöglichkeit der Filter ist das Entfernen unerwünschte Straßen durch das "filter_exclude" zu entfernen.

attr VerkehrBW filter_exclude A5 | A8

So werden die Autobahnen A5 und A8 aus den Meldungen entfernt. Mit Hilfe dieses Attributes lassen sich somit alle unerwünschten Autobahnen, Bundesstraßen oder Kreisstraßen rausfiltern. Einfach ein paar Tage beobachten und nach und nach alle unerwünschten Meldungen in den Filter packen.

Eine Weitere Möglichkeit ist das Filtern nach Ausfahrten. Sonderzeichen müssen dabei durch ein "" gekennzeichnet werden. Folgender Filter filtert die Ausfahrt 55:

attr VerkehrBW filter_include (55)

Wie ihr seht, lässt sich mit den Filter-Attributen eine Menge anstellen. Da muss jeder für sich den auf seinen Bedürfnissen angepassten Filter zusammenstellen.

orderby

Mit dem Attribut "orderby" lassen sich die Verkehrsmeldungen z.B anhand der Meldung sortieren.

attr VerkehrBW orderby 

Es werden somit erst alle Meldungen aufgelistet, welche den String "stockender Verkehr" in der Meldung haben.

msg_format

Mit dem Attribut "msg_format" lässt sich das Format des Readings "xx_msg" anpassen. So lassen sich die bestimmten "Textbausteine" an den Anfang der Meldung stellen.

attr VerkehrBW msg_format [road | head | both]

Jenachdem, wie das Attribut gesetzt wurde, wird der entsprechende Textbaustein der Meldung vorangestellt.

stateFormat

StateFormat ist jetzt kein Modul-spezifisches Attribut, jedoch lässt sich mit diesem Attribut das Device etwas visuell aufwerten. Wer möchte, kann nämlich alle Meldungen als innerhalb des Device-Overviews auflisten.

attr VerkehrBW stateFormat {my $tmp=Verkehrsinfo_GetData('VerkehrBW');; $tmp=~s/n/<br>/g;; $tmp=~s/- -//g;; return $tmp;;}

Verkehrsmeldungen akustisch ausgeben

Wer zusätzlich eine akustische Ausgabe der Verkehrsmeldungen möchte, kann dies über ein entsprechendes System machen, welches eine Sprachausgabe unterstützt und in FHEM eingebunden wurde. Entweder über das Modul "Text2Speech" über einen angeschlossenen Lautsprecher oder über ein eingebundenes Tablet über AMAD2. Folgende Anleitung bezieht sich auf die Sprachausgabe über ein Tablet mit dem Befehl: "set Tablet ttsMsg Dies ist eine Sprachausgabe".

Die folgende Definition des atDevices bewirkt eine akustische Ausgabe der aktuellen Verkehrsmeldungen um 05:30 Uhr über das Tablet. Die Zeit und die Namen der Devices ("VerkehrBW und Tablet") müssen entsprechend anpasst werden. Solltet ihr ein anderes Sprachausgabegerät verwenden, dann auch entsprechend den dazu benötigten Befehl anpassen. 

define *05:30:00 {
my $stau_counter = ReadingsVal("VerkehrBW","count","");
my $stau = "Es liegen " . " " . "$stau_counter" ." Staumeldungen um ". TimeNow() ." vor:";

my $complete_message;

## Anhand Meldungszahl das Reading in der Schleife zusammenbauen

my $head_pre="e_";
my $head_suff="_head";
my $road_pre="e_";
my $road_suff="_road";
my $msg_pre="e_";
my $msg_suff="_msg";
my $head;my $road;
my $msg;

## Iterationsvariable
my $i = 1;

## weitere Meldungen
while ($stau_counter >= $i){
$head="$head_pre"."$i"."$head_suff";
$road="$road_pre"."$i"."$road_suff";
$msg="$msg_pre"."$i"."$msg_suff";

$complete_message="$complete_message"."nn"."Meldung $i: ".ReadingsVal("VerkehrBW",$road,"")." - ".ReadingsVal("VerkehrBW",$head,"").": ".ReadingsVal("VerkehrBW",$msg,"").".";
$i++;
}

fhem("set Tablet ttsMsg $stau $complete_message");
}

(C) Kopiert aus dem FHEM-WIKI und entsprechend angepasst und erweitert

Hinweis: Das atDevice erst als "Rohling" definieren: "define atStaumelder at *05:36:00 a" und die finale Definition über den DEF-Editor einfügen.

Verkehrsmeldungen als Textnachricht

Wenn man keine Möglichkeit hat akustische Sprachausgaben zu realisieren oder aufgrund von noch schlafenden Mitbewohnern eher davon absehen möchte, kann sich die Verkehrsmeldungen natürlich auch aufs Handy schicken lassen.

Auch hier gibt es wieder mehrere Möglichkeiten. Zum einen das Versenden als Push über Pushover oder die Benutzung von Telegramm. ​Aufgrund der meist etwas längeren Verkehrsmeldungen, empfehle ich die Verwendung von Telegramm. 

Um das Senden per Telegramm zu realisieren, reicht es aus, das oben definierte atDevice um den entsprechenden Befehl zu ergänzen.

...
fhem("set Telegram message $stau $complete_message");
fhem("set Tablet ttsMsg $stau $complete_message"); }

Alternativ kann nun natürlich der Befehl für die akustische Meldung entfernt werden.

Einbindung der Verkehrsmeldung in TabletUI

Der FHEM-Nutzer "Paul79" hat für das Einbinden in TabletUI ein Widget geschrieben, welches sich die Daten direkt vom FHEM-Modul Verkehrsinfo holen kann. Aktuell (Stand März 2017) befindet sich das Widget noch nicht im TabletUI-Repository.

Vorbereitung

Damit das Widget verwendet werden kann, muss deswegen eine JavaSkript-Datei mit dem Namen "widget_verkehrsinfo.js" im Widget-Ordner von TabletUI angelegt werden. Bei einer Standartinstallation befindet sich dieser Ordner hier:

/opt/fhem/www/tablet/js

Der FHEM-Nutzer "Paul79" hat die benötigte Datei im FHEM-Forum online gestellt. Die aktuelle Version (Stand 01.03.2017) findet ihr hier:

https://forum.fhem.de/index.php/topic,55118.msg557656.html#msg557656

Am besten schaut ihr euch aber noch ein paar weitere Beiträge an, um eventuell eine aktuellere Version zu erhalten. Die heruntergeladene Datei schiebt ihr dann einfach in den oben genannten Ordner auf den Raspberry.

Definition

Die Definition erfolgt über data-type="verkehrsinfo". Die Mindestdefinition lautet dabei wie folgt:

<div data-type="verkehrsinfo" data-device="name in FHEM" ></div>

Es werden jedoch einige zusätzliche Attribute mitgeliefert, mit denen man die Anzeige etwas anpassen kann.

<div data-type="verkehrsinfo" 
data-device="name in FHEM"
data-max="5" data-color-msg="#CEBCB7"
data-color-head="#FD6F3F"
data-shadow="true"
data-shadow-head="true"
data-icon="2" ></div>

Eine Beschreibung der einzelnen Attribute findet ihr im FHEM-Wiki.

Ich hoffe ich konnte euch zwei ansprechende Möglichkeiten aufzeigen, mit denen ihr Verkehrsmeldungen in FHEM einbindet. Wer mehr zu diesem Thema wissen möchte, dem empfehle ich das FHEM-Forum zum Modul Verkehrsinfo und TRAFFIC.

]]>
https://waschto.eu/verkehrsinfo-und-traffic-verkehrsmeldungen-in-fhem-einbinden/feed 0 2300
Spritmonitor und Tankalarm – Spritpreise der Umgebung per FHEM überwachen https://waschto.eu/spritmonitor-und-tankalarm-spritpreise-der-umgebung-per-fhem-ueberwachen https://waschto.eu/spritmonitor-und-tankalarm-spritpreise-der-umgebung-per-fhem-ueberwachen#comments Thu, 23 Feb 2017 20:05:15 +0000 http://waschto.eu/?p=2219 .tve_more_tag {display: none !important}Jeder Autofahrer unter euch hatte bestimmt schonmal das Problem, nicht zu wissen, ob es sich nun lohnt tanken zu fahren oder nicht. Zwar gibt es schon einige Online-Portale oder Apps, die einen über den aktuellen Benzinpreis informieren. Aber wäre es nicht entspannter, einfach nur einen Blick auf das Tablet im weiterlesen →]]>

Jeder Autofahrer unter euch hatte bestimmt schonmal das Problem, nicht zu wissen, ob es sich nun lohnt tanken zu fahren oder nicht. Zwar gibt es schon einige Online-Portale oder Apps, die einen über den aktuellen Benzinpreis informieren.

Aber wäre es nicht entspannter, einfach nur einen Blick auf das Tablet im Flur werfen zu müssen und direkt die Benzinpreise der Tankstellen in der Umgebung ablesen zu können? Oder bei einem niedrigen Preisniveau eine Art "Tankalarm" auf das Handy zu bekommen? Ich finde schon, deswegen werde ich euch in diesem Beitrag erklären, wie ihr die Preise der umliegenden Tankstellen in FHEM einbindet und übersichtlich darstellt. Des Weiteren zeige ich euch, wie ihr euch einen eigenen Tankalarm definiert und die Preise ansprechend in TabletUI anzeigen könnt.

Vorbereitung

Die Einbindung erfolgt über das Hilfsmodul HTTPMOD. Mit Hilfe dieses Moduls lassen sich Daten aus dem Internet abfragen und für FHEM in Readings umwandeln. Die benötigten Benzinpreise werden davon vom Portal www.clever-tanken.de abgerufen.

Damit man auch die richtigen Daten bekommt, ist es notwendig, sich die ID der gewünschten Tankstelle herauszusuchen. Dazu einfach das Portal besuchen und über das Suchfeld die gewünschte Tankstelle heraussuchen. In der URL findet ihr nun die Tankstellen-ID:

http://www.clever-tanken.de/tankstelle_details/11133

In diesem Fall ist die Tankstellen-ID 11133. Wollt ihr mehrere Tankstellen in FHEM einbinde, dann sucht euch nun alle benötigten IDs raus.

Definition in FHEM

Wie oben schon erwähnt, erfolgt die Definition über das Hilfsmodul HTTPMOD. Benötigt wird dazu die Tankstellen-ID bzw. die URL.

define TankstelleOWM HTTPMOD http://www.clever-tanken.de/tankstelle_details/11133 600

Das definierte Hilfsmodul HTTPMOP liefert jedoch zunächst keine Daten. Damit man nun die gewünschten Werte erhält, sind einige Attribute notwendig. Um genau zu sein, definiert man sich nun durch das Attribut "userReadings" die Readings selbst.

attr TankstelleOWM group Benzinpreis;
attr TankstelleOWM icon gasoline;
attr TankstelleOWM alias OWM;
attr TankstelleOWM room Spritpreise;
attr TankstelleOWM readingsName_Diesel Diesel;
attr TankstelleOWM readingsName_SuperE5 SuperE5;
attr TankstelleOWM readingsRegex_Diesel <span>Diesel</span>[^0-9]+([0-9.]+);
attr TankstelleOWM readingsRegex_SuperE5 <span>Super E5</span>[^0-9]+([0-9.]+);
attr TankstelleOWM timeout 5;

Sollte die Tankstelle noch weitere Kraftstoffe anbieten, so lassen sich diese ebenfalls durch ein userReading hinzufügen. INFO: Es lassen sich nur Kraftstoffe hinzufügen, welche über die MTS-K API bereitgestellt werden. Bei CleverTanken erkennt man dies durch eine Kennzeichnung unter dem Kraftstoffnamen.

attr TankstelleOWM readingsName_SuperE10 SuperE10 
attr TankstelleOWM readingsRegex_SuperE10 <span>Super E10</span>[^0-9]+([0-9.]+)

Je nach Wunsch kann dann noch das stateFormat angepasst werden:

attr TankstelleOWM stateFormat {sprintf("Diesel: %.2f € - Super: %.2f € - E10: %.2f €",ReadingsVal("TankstelleARAL","Diesel",0),ReadingsVal("TankstelleARAL","SuperE5",0),ReadingsVal("TankstelleARAL","SuperE10",0))}

Da die oben aufgezählten Anweisungen noch auf eine alte Version des HTTPMOD-Moduls basieren, ist das Umstellen auf die neue Struktur notwendig. Dies geschieht über das Setzen eines Attributes und das anschließende updaten der Readings:

attr TankstelleOWM enableControlSet 1 
set TankstelleOWM upgradeAttributes

Nun sollten die Spritpreise als Reading angezeigt werden.

Zum Schluss dann noch das stateFormat anpassen, damit in der Device-Übersicht die Preise direkt abgelesen werden können. Hier könnt ihr natürlich auch nur den von euch getankten Kraftstoff anzeigen lassen. Folgendes Attribut zeigt den Literpreis aller drei definierten Kraftstoffe an:

attr TankstelleOWM stateFormat {
sprintf("Diesel: %.2f € - Super: %.2f € - E10: %.2f €",
ReadingsVal("TankstelleOWM","Diesel",0),
ReadingsVal("TankstelleOWM","SuperE5",0),
ReadingsVal("TankstelleOWM","SuperE10",0))}

Um den Spritpreis vergleichen zu können, ist es natürlich sinnvoll sich mehrere Tankstellen aus der Umgebung zu definieren. Ich habe mir insgesamt vier Tankstellen in FHEM eingerichtet.

Einrichtung einer readingsGroup

Mit Hilfe einer readingsGroup lassen sich die Spritpreise noch ein bisschen komfortabler anzeigen. Dazu definieren wir uns eine readingsGroup mit vier Spalten - den Namen und je eine Spalte für Diesel, Super und E10.

define GroupSpritpreise readingsGroup 
<Tankstelle>,<Diesel>,<Super>,<E10>
TankstelleOWM:Diesel,SuperE5,SuperE10
TankstelleREAL:Diesel,SuperE5,SuperE10
TankstelleESSO:Diesel,SuperE5,SuperE10
TankstelleARAL:Diesel,SuperE5,SuperE10
attr GroupSpritpreise room Spritpreise

Anschließend kann man sich daran machen, diese readingsGroup etwas visuell aufzupeppen.

attr GroupSpritpreise valueFormat {"%.2f €"} 
attr GroupSpritpreise style style="font-size:18px"

Wer möchte kann dann noch über das Attribut "alias" die Überschrift der readingsGroup anpassen.

attr GroupSpritpreise alias Spritpreise

Statistik über die Spritpreise

Das Anzeigen der Spritpreise ist alleine gesehen schon eine coole Sache, aber interessant wird es erst, wenn man sich zusätzlich eine Art Tankalarm definiert.

Die Idee ist, dass man die Spritpreise über einen längeren Zeitpunkt beobachtet und bei einem Preisniveau unter den Durchschnittswerten sich eine Nachricht auf das Hnady zukommen lässt.

define SpritpreiseStatistik statistics Tankstelle.*
attr SpritpreiseStatistik minAvgMaxReadings Diesel,SuperE5,SuperE10

Absofort werden für die Readings Diesel, SuperE5 und SuperE10 der Minimal-, Maximal- und der Durchschnittswert von unterschiedlichen Zeiträumen ermittelt. Zur Verfügung steht ein Stunden-, Tages-, Monats- und Jahreszeitraum.

Diese Readings machen wir uns zu Nutzen und ermitteln daraus, ob es sich aktuell lohnt, tanken zu fahren. Damit wir jedoch mit diesen Readings arbeiten können, erstellen wir uns aus den Min-, Max- und Avg-Werten einzelne Readgings.

attr SpritpreiseStatistik singularReadings 
Tankstelle.*:.*:(Min|Avg|Max):(Hour|Day|Month)

Absofort erhält man nun einzelne Readings für die ermittelten statistischen Werte. Nach einer gewissen Zeit beinhalten diese auch sinnvolle Werte. Die Monats-Werte brauchen natürlich etwas länger um sinnvolle Werte liefern zu können.

Tankalarm

Mit den oben erstellen statistischen Werte kann man sich nun einen eigenen Tankalarm definieren. Ich habe mir dazu ein kleine SubRoutine erstellt und rufe sie mit Hilfe eines Notifys auf.

Für die SzbRoutine werden folgende statistische Readings benötigt:

Mit diesen drei Readings habe ich mir einen kleinen "Abfragemarathon" erstellt um herauszufinden, ob es momentan sinvoll ist zu tanken. Dabei habe ich den aktuellen Spritpreis genommen und mit den Stunden-, Tages- und Monatsdurchschnittswerten verglichen. Um das Ergebnis dieser Abfrage zu bewerten, habe ich mir ein Bewertungssystem überlegt.

Ergebnis

Bewertung

größer aller Durchschnittswerte

kleiner als Stundendurchschnitt

kleiner als Tagesdurchschnittswert

kleiner als Stunden- und Tagesdurchschnittswert

kleiner als Monatsdurchschnittswert

kleiner als Stunden- und Monatsdurchschnittswert

kleiner als Tages- und Monatsdurchschnittswert

kleiner als Stunde,- Tages- und Monatsdurchschnittswert

Im Grunde baut das Bewertungsystem auf eine unterschiedliche Bewertung der Durchschnittswerte auf. Ein aktueller Preis kleiner als der Stundendurchschnittswert ist nicht so viel wert, wie das Unterschreiten des Tagesdurchschnittswertes. Ein Unterschreiten des Monatsdurchschnittswertes ist dabei natürlich noch besser. Weiter besser wird es entsprechend bei einer Kombination.

Natürlich lässt sich auch ein anderes Bewertungssystem aufbauen. Des Weiteren lassen sich auch die Max- und Minwerte anstelle der Durchschnittswerte nehmen. Wer also ein anderes Bewertungssystem bevorzugt, kann dieses mir gerne in den Kommentaren wissen lassen. Ich bin für jede Möglichkeit offen.

Die dazu benötigte SubRoutine wird einfach in die "99_myUtils.pm" eingetragen.

sub Tankalarm($$) {

# Variablen definieren my ($Tankstelle, $Kraftstoff) = @_;
my $ALIAS = AttrVal($Tankstelle,"alias",$Tankstelle);
my $aktuell = ReadingsVal("$Tankstelle","$Kraftstoff",0); my $alt = ReadingsVal("$Tankstelle","Backup",0);
my $stunde = "stat".$Kraftstoff."HourAvg"; my $tag = "stat".$Kraftstoff."DayAvg"; my $monat = "stat".$Kraftstoff."MonthAvg";
my $hourAVG = ReadingsVal("$Tankstelle","$stunde",0); my $dayAVG = ReadingsVal("$Tankstelle","$tag",0); my $monthAVG = ReadingsVal("$Tankstelle","$monat",0); my $msg = 0;
if($aktuell != $alt) { if($aktuell < $hourAVG) { if($aktuell < $dayAVG) { if($aktuell < $monthAVG) {$msg = "$ALIAS: ★★★★★ - $Kraftstoff: $aktuell € - Aktueller Spritpreis liegt unter dem Stunden- ($hourAVG €), Tages- ($dayAVG €) und Monatsdurchschnitt ($monthAVG €)";} else {$msg = "$ALIAS: ★★★☆☆ - $Kraftstoff: $aktuell € - Aktueller Spritpreis liegt unter dem Stunden- ($hourAVG €) und Tagesdurchschnitt ($dayAVG €)";} } else { if($aktuell < $monthAVG) {$msg = "$ALIAS: ★★★★☆ - $Kraftstoff: $aktuell € - Aktueller Spritpreis liegt unter dem Stunden- ($hourAVG €) und Monatsdurchschnitt ($monthAVG €)";} else {$msg = "$ALIAS: ★☆☆☆☆ - $Kraftstoff: $aktuell € - Aktueller Spritpreis liegt unter dem Stundendurchschnitt ($hourAVG €)";} } } else { if($aktuell < $dayAVG) { if($aktuell < $monthAVG) {$msg = "$ALIAS: ★★★★☆ - $Kraftstoff: $aktuell € - Aktueller Spritpreis liegt unter dem Tages- ($dayAVG €) und Monatsdurchschnitt ($monthAVG €)";} else {$msg = "$ALIAS: ★★☆☆☆ - $Kraftstoff: $aktuell € - Aktueller Spritpreis liegt unter dem Tagesdurchschnitt ($dayAVG €)";} } else { if($aktuell < $monthAVG) {$msg = "$ALIAS: ★★★☆☆ - $Kraftstoff: $aktuell € - Aktueller Spritpreis liegt unter dem Monatsdurchschnitt ($monthAVG €)";} else {$msg = "$ALIAS: ☆☆☆☆☆ - $Kraftstoff: $aktuell € - Kraftstoff aktuell sehr teuer";} } } } else {$msg = "keineAenderung";}
fhem("setreading $Tankstelle Backup $aktuell");
return $msg; }

Der SubRoutine wird das Tankstellen-Device ($Tankstelle) und der zu überwachende Kraftstoff ($Kraftstoff) übergeben. Anschließend werden einige Variablen definiert. Zum Einen die Variablen "stunde,tag,monat" erhalten den Namen der benötigten Readings. Zum Anderen die Variablen "hourAVG,dayAVG,monthAVG", welche die benötigten Readings beinhalten - z.B. für SuperE10: statSuperE10HourAVG, statSuperE10DayAVG, statSuperE10MonthAVG.

Zuerst wird nun überprüft, ob der aktuelle Kraftstoffpreis unterschiedlich zum vorherigen Preis ($alt) ist. Ist dies der Fall, wird in den darauf folgenden if-Abfragen die Variable "msg" mit der entsprechenden Nachricht beschrieben.

Liegt keine Preisänderung vor, so wird die Nachricht auf "keineAenderung" gesetzt.

Zum Schluss wird dann noch der aktueller Preis als Backup in das entsprechende Tankstellen-Device geschrieben und die Nachricht als Rückgabewert zurückgegeben.

Das Aufrufen der SubRoutine erfolgt nun über ein Notify, welches bei einer Preisänderung auslöst.

define SpritkostenNotify notify Tankstelle.*:SuperE10:.* {
my $Nachricht = Tankalarm("$NAME","SuperE10");
if($Nachricht ne "keineAenderung"){
fhem("set Telegram message $Nachricht");}
}

Dieses Notify löst jetzt bei einer Preisänderung des Kraftstoffes "SuperE10" aus. Überwacht werden dabei alle Tankstellen-Devices (Tankstelle.*). Der überwachte Kraftstoff kann natürlich je nach Wunsch angepasst werden.

Beim Auslösen wird dann die SubRoutine aufgerufen und die Variable "Nachricht" mit der entsprechenden Nachricht beschrieben. Liegt eine Tankempfehlung vor, so wird über Telegram der Tankalarm gesendet. Hier lassen sich natürlich auch andere Kommunikationswege einsetzen. Bei der oben beschriebenen Definition des Notify-Devices muss dem Telegram-Device die Empfänger-ID mitgeteilt werden:

attr Telegram defaultPeer 24xxxxxxx 

Wurde alles definiert, erhält man absofort eine Nachricht über Telegram, ob es sich aktuell lohnt, tanken zu fahren. Es kann ein paar Tagen dauern bis die Durchschnittswerte aussagekräftig werden. Erst recht die Monatsdurchschnittswerte brauchen ein paar Tage bis sich ein aussagekräftiger Wert gebildet hat.  

Der eingerichtete Tankalarm kann natürlich auch getestet werden. Dazu einfach über "setreading" den Preis für SuperE10 manuell auf einen niedrigen Wert festlegen.

setreading TankstelleESSO SuperE10 1.10

Da der Literpreis von 1.10 höchstwahrscheinlich alle Durchschnittswerte unterbietet, solltet ihr nun eine 5-Sterne-Tankempfehlung auf euer Handy bekommen. Beim nächsten Aktualisieren der Spritpreise wird der manuell gesetzte Wert wieder durch den richtigen Wert überschrieben. Wer möchte, kann die Aktualisierung auch manuell starten:

set TankstelleESSO reread

Manuelles Abfragen der Preissituation

Neben dem automatischen Tankalarm, kann man sich eine kleine SubRoutine schreiben, um auch ein manuelles Abfragen der Preissituation über Telegram zu ermöglichen. Dazu einfach in der "99_myUtils.pm" eine weitere SubRoutine erstellen.

sub Telegram($$) {
my ($Device, $msgText) = @_;
my $Nachricht = ReadingsVal($Device,$msgText,"0");
my @array = split(/ /,$Nachricht);
if(@array[0] eq "Spritkosten")
{
my $Device = "Tankstelle".@array[1];
my $aktuell = ReadingsVal("$Device","@array[2]",0);
fhem("set Telegram message Aktueller Preis für @array[2] an der @array[1]-Tankstelle: $aktuell €");
}
}

Damit die erstellte SubRoutine auch die empfangene Nachricht erhält, ist das Definieren eines weiteren Notifys nötig:

define TelegramNotify notify Telegram:msgText:.* { Telegram("Telegram","msgText")}

Der SubRoutine "Telegram" wird nun beim Empfangen einer Nachricht der Inhalt dieser übergeben. Innerhalb der Routine wird der empfangende Nachrichtenstring aufgeteilt und in ein Array abgespeichert. Das erste Wort beinhaltet das Steuerungswort "Spritkosten". Das zweite Wort dann die gewünschte Tankstelle und das dritte den gewünschten Kraftstoff. So lassen sich zum Beispiel durch senden der Nachricht "Spritkosten ESSO SuperE10 der entsprechende Preis ausgeben.

Nachrichten nur zu bestimmten Zeiten

Wem die vielen Nachrichten etwas nerven, bzw. nur welche zu bestimmten Zeitpunkten haben möchte, der kann natürlich das Notify nur zu bestimmten Zeitpunkten aktivieren. Dazu kann man sehr gut den WeekdayTimer verwenden, mehr dazu auf meinem Blogbeitrag zum Modul.​

define TimerSprit WeekdayTimer SpritkostenNotify Mo-Fr|16:00|active Mo-Fr|19:00|inactiv

Jetzt wird das Notify, welches für das Versenden der Nachrichten verantwortlich ist, nur von Montag bis Freitag zwischen 16 und 19 Uhr aktiviert. Außerhalb dieser Zeiträume ist es deaktiviert und versendet somit keine Nachrichten.

Spritmonitor in TabletUI einbinden

Neben der readingsGroup und dem Tankalarm lässt der Spritmonitor auch im alternativen FrontEnd TabletUI einbinden.

Der Aufbau ist im Grunde nichts anderes als eine Tabelle. Ähnlich wie ich sie bereits im Abfahrtsmonitor verwende. Den benötigten Code könnt ihr auf meinem Blog-Beitrag über mein TabletUI nachlesen.

Ich hoffe ich konnte euch das Einrichten eines Tankalarms verständlich erklären und euch inspirieren diesen selber umzusetzen. Wie oben schon erwähnt, solltet ihr für das Bewertungssystem eine bessere Idee haben, so lasst sie mir diese gerne über die Kommentare zukommen.

]]>
https://waschto.eu/spritmonitor-und-tankalarm-spritpreise-der-umgebung-per-fhem-ueberwachen/feed 39 2219
Amazon Echo – FHEM-Devices per Alexa steuern https://waschto.eu/amazon-echo-fhem-devices-per-alexa-steuern https://waschto.eu/amazon-echo-fhem-devices-per-alexa-steuern#respond Wed, 08 Feb 2017 19:55:10 +0000 http://waschto.eu/?p=2097 .tve_more_tag {display: none !important}NACHTRAG 13.02.2017: Der Amazon Echo und der Amazon Echo Dot sind absofort ohne Warteliste bestellbar. Endlich war es soweit. Auch ich durfte mir endlich einen Amazon Echo Dot kaufen. Nach wochenlangem warten wurde nun auch mir eine Einladung seitens Amazon zugeschickt. Aufgrund der hohen Nachfrage lassen sich die Amazon Echo und weiterlesen →]]>

NACHTRAG 13.02.2017: Der Amazon Echo und der Amazon Echo Dot sind absofort ohne Warteliste bestellbar. 

Endlich war es soweit. Auch ich durfte mir endlich einen Amazon Echo Dot kaufen. Nach wochenlangem warten wurde nun auch mir eine Einladung seitens Amazon zugeschickt. Aufgrund der hohen Nachfrage lassen sich die Amazon Echo und Echo Dots nämlich nur kaufen, wenn man von Amazon für den Kauf eingeladen wird (Stand Januar 2017). Es scheint jedoch aktuell so zu sein, dass die Wartezeit nur noch knappe zwei Wochen beträgt. Wenn ihr also auch Interesse habt, dann fragt einfach bei Amazon nach einer Einladung und vielleicht habt ihr ja Glück und könnt demnächst auch einen Amazon Echo (Dot) euer Eigen nennen.

Amazon Echo und Echo Dot

Amazon Echo, Schwarz

Amazon - Elektronik

179,99 EUR
Amazon Echo Dot (2. Generation), Schwarz

Amazon - Elektronik

59,99 EUR

Letzte Aktualisierung am 27.05.2017 / Affiliate Links / Bilder von der Amazon Product Advertising API

Ich persönlich habe mich für den  kleineren Amazon Echo Dot entschieden, da ich auf den besseren Lautsprecher seines großen Bruders verzichten kann. Am Echo Dot lässt sich jedoch als Alternative, über einen 3.5mm-Klinke-Anschluss oder über Bluetooth, ein externer Lautsprecher anschließen. Des Weiteren wird die Lautstärke des kleineren Echo Dot über zwei Tasten geregelt (+ und -). Beim großen Echo geschieht dies über ein Drehrad, welches sich unter dem Lichtring befindet. Ansonsten sind die beiden Echo-Geräte identisch.

Beide Versionen verfügen unteranderem über eine Fernfeld-Spracherkennung. Dank den sieben Mikrophonen werden Sprachbefehle aus jeder Richtung erkannt. Die Richtstrahltechnologie und die integrierte Geräuschunterdrückung ermöglichen eine sehr gute Spracherkennung. Die erkannte Richtung aus der die Sprachbefehle kommen, werden über den integrierten Lichtring visuell durch ein grünes Segment im Ring dargestellt.

Durch die Anbindung an Amazons-Clodservice lernt der Echo zudem die Sprachgewohnheiten und führt Befehle mit der Zeit schneller und akkurater aus.​

Die Stromversorung erfolgt beim Echo Dot über ein USB-Netzteil (9W), welches inklusive eines 1,8m langes USB-Kabel mitgeliefert wird. Mehr Infos zu den Features auf der Produktseite zum Amazon Echo bzw. Amazon Echo Dot.

Aber erstmal an den Anfang, wieso habe ich mir eigentlich einen Amazon Echo Dot geholt? Der Grund ist nicht, weil ich gerne per Sprache etwas auf Amazon kaufe oder weil ich mir gerne Witze von Alexa erzählen lasse. Der Grund ist, wie soll es anders sein, das Steuern meines Zuhauses über Sprachbefehle.

Vorteile gegenüber Apples Siri

Der eifrige Blogleser unter euch wird es wissen, ich habe bereits Apples Sprachassistent Siri dazu bewegt, mein Zuhause steuern zu können. Warum bin ich nun also auf Alexa umgestiegen? Der Grund ist der Komfort. Während man bei Siri immer noch den Umweg über ein Handy gehen muss, kann man beim Amazon Echo einfach in den Raum reinsprechen. Des Weiteren ist bei Siri immer noch ein Knopfdruck auf dem Handy notwendig um den Sprachassistenten zum Zuhöhre zu bewegen. Zwar kann man die "Hey Siri-Funktion" aktivieren, welches ebenfalls das automatische Zuhöhren aktiviert, jedoch ist die Erkennung der Sprache in der Hosentasche nicht die Beste und erfordert eine gewisse Nähe zum Handy. Des Weiteren wird diese Funktion nur bei neueren iPhones unterstützt (ab iPhone 6s). Ältere Handys benötigt für diese Funktion eine Stromversorung.

Amazon hat mit den Echo-Geräten diese  Mankos nun beseitigt und stellt ein perfekten Begleiter für die Hausautomation zur Verfgung. Es lassen sich bereits viele Marken einbinden. Von Phillips-Hue, über Osrams Lightfy bis hin zu den Innogy-Geräten. Sind die Geräte erstmal mit den Echo-Geräte verbunden, lassen sich alle eingebundenen Geräte per Sprachbefehle steuern.

  • "Schalte das Licht im Flur an"
  • "Dimme das Licht im Wohnzimmer auf 20%"

Alexa und FHEM

Und das Beste komm nun, dank dem Modul-Entwickler "justme1968" lassen sich nun auch FHEM-Devices mit den Echo-Geräten verbinden und darüber steuern. Möglich macht es die von ihm entwickelte Schnittstelle "Alexa-FHEM".

Zurzeit (Stand 01/2017) tut sich eine Menge in Sachen Alexa-FHEM. Die Community ist eifrig am Diskutieren und es kommen regelmäßig Updates und Anpassung raus. Wer sich dieser Diskussion anschließend möchte, der kann gerne im entsprechenden Forum-Eintrag vorbeischauen.

Aufgrund der Tatsache, dass sich das Projekt "Alexa-FHEM" noch im Aufbau befindet, werde ich hier im Blog-Beitrag keine Anleitung schreiben, wie ihr Alexa-FHEM einrichtet, da sich hier stetig etwas ändert. Dieser Beitrag soll lediglich dazu dienen, euch meine Erfahrungen mit Amazons neuen Sprachassistenen Alexa mitzuteilen. 

Einrichtung

Wie oben schon erwähnt, werde ich nicht selber auf die Einrichtung von Alexa-FHEM eingehen. Ich werde euch jedoch gerne erzählen, an welche Anleitung ich mich gehalten habe.

Ich persönlich habe mich an die Video-Anleitung von "haus-automatisierung.com" gehalten. Zusammen mit dessen Blog-Beitrag hat die Einrichtung perfekt und problemlos geklappt.

Die Einrichtung ist zwar ein regelrechter Konfigurationsmarathon, doch durch das Video leicht nachvollziehbar.

Nachtrag 22.02.2017 - Version 0.30

Inzwischen gibt es bereits die Version 0.30 des Alexa-Moduls. Die Einrichtung auf dem Raspberry hat sich deswegen etwas geändert.

Voraussetzung

Die aktuelle Version von NodeJS (LTS) ist Voraussetzung:

wget https://nodejs.org/dist/v6.10.0/node-v6.10.0-linux-armv7l.tar.xz 
tar -xvf node-v6.10.0-linux-armv6l.tar.xz
cd node-v6.10.0-linux-armv6l/
sudo cp -R * /usr/local/
cd
rm -r node-v6.10.0-linux-armv7l
rm node-v6.10.0-linux-armv7l.tar.xz

Installation von Version 0.30

Die Version 0.30 lässt sich aus dem FHEM-Forum herunterladen - Version 0.30. Diese in das Home-Verzeichnis auf den Raspberry laden und anschließend entpacken:

tar -xzf alexa-fhem-0.30.tgz

Den entstandenden Ordner umbenennen und in den Ordner wechseln:

mv package alexa-fhem
cd alexa-fhem

Anschließend können die benötigten Pakete installiert werden und das Sicherheits-Zertifikat erstellt werden:

npm install
./createKey.sh

Danach kann die benötigte Config-Datei erstellt werden:

mkdir ~/.alexa 
cd alexa-fhem/
cp config-sample.json ~/.alexa/config.json

Wie dieses Config-File aussehen soll, könnt ihr oben im Video sehen. Die Einrichtung auf den Amazon-Seiten ist unverändert geblieben und kann wie im Video vorgenommen werden.

Mein Alltagseinsatz

Wie bereits erwähnt, habe ich mich für den kleineren Amazon Echo Dot entschieden. Da ich den Dot überwiegend zum Steuern meiner Smart-Home-Gräte verwende, reicht der integrierte Lautsprecher vollkommend aus.

Aktuell verwende ich nur den Standard "Home-Automation-Skill" von Amazon. Für die einfache Steuerung von Licht oder Funksteckdosen reicht dieser Standard-Skill aus.

  • "Finde meine Geräte"
  • "Schalte das Licht im Flur an"
  • "Dimme das Licht im Wohnzimmer auf 20%"
  • "Schalte die Kaffemaschine ein"
  • "Schalte den Ventilator auf 75%"
  • "Schalte die Außensteckdose ein"
  • "Stelle die Haustemperatur auf 20 Grad"
  • "Senke die Temperatur im Schlafzimmer"
  • "Schalte Filmezeit ein"
  • "Schalte Energie ins Wohnzimmer ein"

Diese Sprachbefehle funktionieren erstaunlich gut. Nachdem ich meine PCA301- und die Intertechno-Funksteckdosen in FHEM dem Raum "Alexa" zugeordnet habe, wurden alle Geräte problemlos nach einem Neustart von Alexa-FHEM erkannt.

Sehr positiv erfand ich, dass innerhalb von Alexa auch das alias-Attribut von FHEM erkannt wurde. Die Devices wurden somit in Alexa nicht als "WZ_Papierlampe" eingebunden, sonder direkt als "Papierlampe", bzw. "Fernsehr" anstelle von "WZ_TV". Befehle wie "Schalte die Papierlampe an" funktionieren dementsprechend problemlos. Auch das Steuern meiner MiLight-Lampen klappt im Grunde auch, jedoch lässt sich Lampe nur mit dem Sprachbefehl "Schalte die Hängelampe auf 0%" wieder ausschalten. Aber ich denke, dass lässt sich noch entsprechnd konfigurieren.

Mein nächster Schritt wird das Einrichten von den sogenannten Custom-Skills sein. Dies erlaubt dann ein tieferes Konfigurieren der Befehle und somit das Einbinden weiterer FHEM-Devices. Ich werde euch natürlich in diesem Blog-Beitrag über mein Setting informieren.


Enter your text here...

]]>
https://waschto.eu/amazon-echo-fhem-devices-per-alexa-steuern/feed 0 2097
Stromkosten als Diagramm darstellen https://waschto.eu/stromkosten-als-diagramm-darstellen https://waschto.eu/stromkosten-als-diagramm-darstellen#comments Mon, 06 Feb 2017 18:03:11 +0000 http://waschto.eu/?p=2123 .tve_more_tag {display: none !important}Schaltbare Steckdosen spielen in FHEM eine große Rolle. Einige von ihnen sind jedoch nicht nur zum einfachen Schalten da, sondern messen zusätzlich auch die aktuelle Leistung und den Stromverbrauch des angeschlossenen Gerätes. Ein Beispiel ist da die PCA301-Steckdose von ELV oder der Zwischenstecker von HomeMatic. HomeMatic Funk-Schaltaktor Zwischenstecker 1fach, 130248A0 weiterlesen →]]> Schaltbare Steckdosen spielen in FHEM eine große Rolle. Einige von ihnen sind jedoch nicht nur zum einfachen Schalten da, sondern messen zusätzlich auch die aktuelle Leistung und den Stromverbrauch des angeschlossenen Gerätes. Ein Beispiel ist da die PCA301-Steckdose von ELV oder der Zwischenstecker von HomeMatic.

Letzte Aktualisierung am 27.05.2017 / Affiliate Links / Bilder von der Amazon Product Advertising API

Da liegt es doch Nahe, aus den gemessenen Werte sich den Stromverbrauch des angeschlossenen Gerätes zu errechnen und in einem Balkendiagram darzustellen. Genau darum wird es in diesem Blogbeitrag gehen. Ich werde euch zeigen, wir ihr die Readings einer PCA301-Steckdose auswertet und euch daraus ein Dummy mit den Tages-, Monats, Jahres- und Gesamtverbrauch und den jeweiligen Stromkosten erstellt.

Vorbereitung

Bevor man mit dem Auswerten der Readings beginnen kann, muss natürlich die Steckdose selbst eingebunden werden. Mehr Infos dazu auf meinem Blogbeitrag. Folgende Anweisungen beziehen sich auf die Readings der PCA301-Steckdosen. Solltet ihr andere Leistungsmessgeräte verwenden, müsst ihr die Readings entsprechend anpassen.

Einrichtung in FHEM

Der komplette Aufbau besteht aus je einem Dummy für die Gesamt-, Jahres-, Monats, und Tageswerte. Die Dummys besitzen dann je ein Reading für den Verbrauch und für die Stromkosten. Die Dummys für die Gesamt-, Jahren- und Monatswerte besitzen zudem ein Reading für den Tagesverbrauch. Aus diesem Reading wird dann entsprechend der Gesamt-, Jahres- bzw. Monatswert errechnet.

Das Reading Tagesverbrauch wird dann über ein at-Device mit dem gemessen Wert der Steckdose beschrieben. Die anderen Readings werden jeweils im Dummy über das userReadings-Attribut selbst erzeugt. 

Zusätzlich wird im at-Device das aktuelle Datum abgefragt, um zu überprüfen, ob eines der Readings zurückgesetzt werden muss. Am ersten Tag eines Monats wird zum Beispiel das Reading Verbrauch des Monats-Dummys auf Null gesetzt.

Zum Schluss wird noch eine readingsGroup erstellt, um die Werte in einem Device zusammen zu haben.

Dummys

Wie oben bereits erwähnt, wird je ein Dummy für die Gesamt-, Jahres-, Monats- und Tageswerte erstellt.

define WZStromkostenGesamt dummy
define WZStromkostenJahr dummy
define WZStromkostenMonat dummy
define WZStromkostenTag dummy

Damit die später eingerichteten Readings ordnungsgemäß verarbeitet und angezeigt werden, werden den Dummys ein paar Attribute mitgegeben. Angefangen mit dem Gesamt-Dummy.

Attribut "alias", damit der unschöne Name überschrieben wird:

attr WZStromkostenGesamt alias Gesamt

Attribut "room" für die Raumzuordnung:

attr WZStromkostenGesamt room Stromkosten

Mit dem Attribut "group" werden die Dummys zusammengefasst:

attr WZStromkostenGesamt group WZ-Stromkosten

Die Attribute "alias", "room" und "group" können natürlich je nach Wunsch angepasst werden.

Attribut "stateFormat" fügt die Readings in die Device-Übersicht:

attr WZStromkostenGesamt stateFormat {sprintf("%.2f kWh - %.2f €",
ReadingsVal("WZStromkostenGesamt", "Verbrauch",0),
ReadingsVal("WZStromkostenGesamt","Kosten",0))}

Attribut "userReadings" fügt das Reading "Verbrauch" hinzu, welches den Tageswert stetig aufaddiert und das Reading "Kosten", welches den Verbrauchswert mit dem aktuellen Strompreis multipliziert.

attr WZStromkostenGesamt userReadings Verbrauch monotonic 
{ReadingsVal("WZStromkostenGesamt","Tagesverbrauch",0)}, Kosten {ReadingsVal("WZStromkostenGesamt","Verbrauch",0)*0.2507}

Diese Attribute anschließend auch für die beiden Dummys "WZStromkostenJahr" und "WZStromkostenMonat" einrichten. Bei den Attributen "stateFormat" und "userReadings" entsprechend die Devices im ReadingsVal anpassen. 

Für das Dummy "WZStromkostenTag" können die Attribute "alias", "room" und "stateFormat" ebenfalls übernommen werden. Das Attribut "userReadings" wird jedoch etwas abgewandelt:

attr WZStromkostenTag userReadings Kosten {
ReadingsVal("WZStromkostenTag","Verbrauch",0)*0.2507}

Hier wird nur noch das Reading "Kosten" erstellt. Das Verbrauchs-Reading wird später über das at-Device erzeugt.

at-Device

Nachdem die Dummys erstellt wurden, kann man damit beginnen, diese mit Leben zu füllen. Verwendet wird dafür ein at-Device, welches zunächst wie folgt definiert wird:

define atWZStromkosten at +*00:01:00 a

Über den DEF-Editor passen wir das at-Device nun an:

+*00:01:00 {
my $a = (ReadingsVal("WZ_Entertainment","consumption",0));

fhem("setreading WZStromkostenTag Verbrauch $a");
fhem("setreading WZStromkostenMonat Tagesverbrauch $a");
fhem("setreading WZStromkostenJahr Tagesverbrauch $a");
fhem("setreading WZStromkostenGesamt Tagesverbrauch $a");

if(($hour==0) && ($min==0)){
fhem("set WZ_Entertainment reset")}

if(($hour==0) && ($min==0) && ($mday==1)){
fhem("setreading WZStromkostenMonat Verbrauch 0")}

if(($hour==0) && ($min==0) && ($yday==1)){
fhem("setreading WZStromkostenJahr Verbrauch 0")}
}

Nachtrag 01.03.2017: Heute zum 1. des Monats, habe ich festgestellt, dass das Zurücksetzen am Anfang des Monats nicht geklappt hat. Grund war der Einsatz von "elsif". Es wird dann nämlich nur die erste Bedienung ausgeführt (die Tageszurücksetzung). Die anderen Abfragen werden dann gar nicht mehr überprüft. Durch den Einsatz von drei getrennten if-Abfragen sollte es nun aber klappen. Der Code oben wurde bereits angepasst.

Zuerst wird die Variable "a" erzeugt, diese beinhaltet den gemessenen Stromverbrauch der PCA301-Steckdose. Solltet ihr hier andere Devices für die Messung verwenden, mit eventuell anderen Readings, müsst ihr diesen Eintrag entsprechend anpassen.

Anschließend wird das Reading "Verbrauch" vom Tages-Dummy mit diesem Wert gesetzt. Die anderen Dummys bekommen diesen Wert als Reading "Tagesverbrauch". Aus diesem Reading wird innerhalb der Dummys zum Beispiel der Jahresverbrauch erstellt, siehe Attribut "userReadings" der Dummys.

Nachdem die Readings gefüttert wurden, beginnt die Zeitabfrage. Zuerst wird nach der Uhrzeit "00:00" gefragt. Ist dies der Fall, wird die Verbrauchsmessung der PCA301-Steckdose ("WZ_Entertainment") auf Null gesetzt. Die zweite Abfrage überprüft, ob ein neuer Monat begonnen hat. In diesem Fall, wird der Monatsverbrauch auf Null gesetzt. Die letzte Abfrage ist für den Jahreswechsel zuständig. Bei einem Jahreswechsel wird das Jahresverbrauch entsprechend auf Null gesetzt.

Wurde das ordnungsgemäß at-Device eingerichtet, werden die Dummys nun mit den entsprechenden Werten gespeißt und die Berechnung des Monats-, Jahres- und Gesamtverbrauch beginnt.

Zu Beginn sieht es noch etwas unspektakulär aus, da es zwischen den Zeiträumen keinen Unterschied gibt. Aber das wird sich ja mit der Zeit ändern.

readingsGroup

Wer möchte, kann die Readings noch in einer "readingsGroup" zusammen fassen. Dies erleichtert zum Beispiel ein späteres Verschieben in einen anderen Raum, da nur noch für die "readingsGroup" das room-Attribut angepasst werden muss. Des Weiteren lässt sich diese Gruppe visuell besser anpassen als eine Gruppierung über das group-Attribut.

define GroupWZStromkosten readingsGroup < >,<Verbrauch>,<Kosten> 
WZStromkostenGesamt:Verbrauch,Kosten
WZStromkostenJahr:Verbrauch,Kosten
WZStromkostenMonat:Verbrauch,Kosten
WZStromkostenTag:Verbrauch,Kosten

Anstatt nun die ganzen Dummys in den Raum "Wohnzimmer" zu verschieben, muss ich nun nur diese Gruppe in den gewünschten Raum verschieben.

attr GroupWZStromkosten room Wohnzimmer

Auch hier setze ich wieder das alias-Attribut:

attr GroupWZStromkosten alias Stromkosten

Wer möchte kann gerne noch das Aussehen der Gruppe anpassen. Ich zum Beispiel habe die Schriftgröße auf 18px erhöht und Wertebereiche den Farben grün, orange und rot zugeordnet.

attr GroupWZStromkosten valueStyle {
if($DEVICE eq "WZStromkostenJahr" && $READING eq "Verbrauch" && $VALUE > 1800)
{'style="color:red"'} elsif($DEVICE eq "WZStromkostenJahr" && $READING eq "Verbrauch" && $VALUE > 1080)
{'style="color:orange"'} elsif($DEVICE eq "WZStromkostenJahr" && $READING eq "Verbrauch" && $VALUE > 0)
{'style="color:green"'} elsif($DEVICE eq "WZStromkostenJahr" && $READING eq "Kosten" && $VALUE > 460)
{'style="color:red"'} elsif($DEVICE eq "WZStromkostenJahr" && $READING eq "Kosten" && $VALUE > 275)
{'style="color:orange"'} elsif($DEVICE eq "WZStromkostenJahr" && $READING eq "Kosten" && $VALUE > 0)
{'style="color:green"'}
elsif($DEVICE eq "WZStromkostenMonat" && $READING eq "Verbrauch" && $VALUE > 150)
{'style="color:red"'} elsif($DEVICE eq "WZStromkostenMonat" && $READING eq "Verbrauch" && $VALUE > 90)
{'style="color:orange"'} elsif($DEVICE eq "WZStromkostenMonat" && $READING eq "Verbrauch" && $VALUE > 0)
{'style="color:green"'} elsif($DEVICE eq "WZStromkostenMonat" && $READING eq "Kosten" && $VALUE > 38)
{'style="color:red"'} elsif($DEVICE eq "WZStromkostenMonat" && $READING eq "Kosten" && $VALUE > 23)
{'style="color:orange"'} elsif($DEVICE eq "WZStromkostenMonat" && $READING eq "Kosten" && $VALUE > 0)
{'style="color:green"'}
elsif($DEVICE eq "WZStromkostenTag" && $READING eq "Verbrauch" && $VALUE > 5)
{'style="color:red"'} elsif($DEVICE eq "WZStromkostenTag" && $READING eq "Verbrauch" && $VALUE > 3)
{'style="color:orange"'} elsif($DEVICE eq "WZStromkostenTag" && $READING eq "Verbrauch" && $VALUE > 0)
{'style="color:green"'} elsif($DEVICE eq "WZStromkostenTag" && $READING eq "Kosten" && $VALUE > 1.25)
{'style="color:red"'} elsif($DEVICE eq "WZStromkostenTag" && $READING eq "Kosten" && $VALUE > 0.75)
{'style="color:orange"'} elsif($DEVICE eq "WZStromkostenTag" && $READING eq "Kosten" && $VALUE > 0)
{'style="color:green"'} }

Die Wertebereiche könnt ihr natürlich entsprechend anpassen.

attr GroupWZStromkosten style style="font-size:18px"

Zum Schluss wird noch das Format der Werte angepasst und die Einheit hinzugefügt.

attr GroupWZStromkosten valueFormat {Kosten => "%.2f €", Verbrauch => "%.2f kWh"}

FileLog

Damit später auch ein Diagramm erstellt werden kann, müssen die Werte in ein FileLog gespeichert werden. Ich habe mich für ein extra FileLog für die Stromkosten entschieden.

define StromkostenLOG FileLog ./log/StromkostenLOG-%Y-%m.log 
WZStromkostenGesamt:.*|WZStromkostenJahr:.*|WZStromkostenMonat:.*|WZStromkostenTag:.*

Wer möchte, kann natürlich die Werte auch in ein vorhandenes FileLog schreiben.

Für das Diagramm wird später der Kosten-Wert vom Dummy "WZStromkostenGesamt" verwendet. Dennoch schreibe ich auch die Tages-, Monats- und Jahreswerte in das LogFile. Dies erleichtert zum Beispiel, dass spätere Erstellen von einem Monatsdiagramm. Am Anfang ist dies jedoch aufgrund der geringen Anzahl an Werten nicht zu empfehlen.

Balkendiagramm

Nachdem das FileLog erstellt wurde, kann mit dem Definieren des Diagramms begonnen werden. Wie oben schon erwähnt, habe ich mir zuerst nur ein Diagramm aus den Tageswerten erstellt.

define SVGStromkosten SVG StromkostenLOG:SVG_StromkostenLOG:CURRENT

Das Erstellen des SVG-Plots geht natürlich auch über das LogFile und dann über "Create SVG Plot".

Bevor man nun das Diagramm weiter definiert, ist für eine korrekte Anzeige notwendig den Zeitraum auf einen Monat festzulegen.

attr SVGStromkosten fixedrange month

Optional kann noch die Größe des Diagramms, der Raum und ein Alias festgelegt werden. Ich verwende eine einheitliche Größe von 800x200 Pixel.

attr SVGStromkosten plotsize 800,200
attr SVGStromkosten room Wohnzimmer
attr SVGStromkosten alias Stromkosten

Um nun das gewünschte Balkendiagramm angezeigt zu bekommen, habe ich folgende Einstellungen vorgenommen. Wie oben schon erwähnt, verwende ich den Kosten-Werte vom Dummy "WZStromkostenGesamt".

Wichtig ist hier der Eintrag im Feld "functions". "delta-d" sorgt dafür, dass aus dem Gesamt-Kostenwert immer nur die Kosten des Tages angezeigt werden, bzw. die Differenz von den Gesamtkosten gegenüber des Wertes vom letzten Tag. Kurz gesagt, die anfallenden Kosten eines Tages.

Wer möchte, kann nun natürlich auch ein Diagramm für den täglichen Verbrauch in kWh erstellen. Oder anstelle von Tagesdiagrammen ein Stundendiagramm erstellen. Dazu einfach die Function "delta-d" zu "delta-h" ändern. Achtet jedoch darauf, dass für jedes Diagramm ein seperates FileLog benötigt wird.

Absofort wird von jedem Tag ein Balken mit den angefallenen täglichen Stromkosten des gemessenen Gerätes erstellt. Zusammen mit der readingsGroup hat man nun eine sehr gute Übersicht über die angefallenden Stromkosten.

Messdaten mehrerer Steckdosen zusammenfügen

Die oben beschriebene Anleitung beschreibt das Visualisieren von Messdaten eines Messgerätes. In diesem Fall eine PCA-301-Steckdose. Hat man jedoch mehrere Mess-Steckdosen im Einsatz, kann es nützlich sein, alle Messwerte zusammenzuführen und somit den Gesamtverbrauch aller Steckdosen anzeigen zu lassen.

In meinem Fall habe ich zuerst die oben beschriebenen Schritte auch für meine zweite PCA-310-Steckdose im Arbeitszimmer durchgefüht und besitze nun folgende Dummys:

  • WZStromkostenGesamt
  • WZStromkostenJahr
  • WZStromkostenMonat
  • WZStromkostenTag
  • AZStromkostenGesamt
  • AZStromkostenJahr
  • AZStromkostenMonat
  • AZStromkostenTag

Die neu hinzugekommenen Dummys (AZStromkostenGesamt ...) werden ebenfalls durch ein at-Device mit den Werten gefüttert und innerhalb der Dummys werden die Kosten berechnet. Mehr dazu in den oberen Schritten. Das Anlegen einer readingsGroup, FileLog und eines Diagramms sind optional und werden für folgende Schritte nicht unbedingt benötigt.

Für die Zusammenfassung der Messwert werden ebenfalls vier Dummys angelegt.

define StromkostenGesamt dummy
define StromkostenJahr dummy
define StromkostenMonat dummy
define StromkostenTag dummy

Auch diese Dummys bekommen wieder ein paar Attribute. Jeweils für die einzelnen Dummys entsprechend anpassen.

attr StromkostenGesamt alias Gesamt
attr StromkostenGesamt room Stromkosten
attr StromkostenGesamt group Gesamt-Stromkosten
attr StromkostenGesamt stateFormat {sprintf("%.2f kWh - %.2f €",
ReadingsVal("StromkostenGesamt", "Verbrauch",0),
ReadingsVal("StromkostenGesamt","Kosten",0))}

Im Gegensatz zu den Dummys für die einzelnen Geräte, muss bei den Gesamt-Dummys der Verbrauch nicht über "monotonic" errechnet werden. Hier erhalten alle Dummys den Verbrauchswert später über das at-Device, welches ja nur noch die einzelnen Werte zusammen zählen muss. Die Kosten könnte man auch über das at-Device zusammen zählen lassen, ich habe mich jedoch dafür entschieden, diese wieder im Dummy selber zu errechnen.

attr StromkostenGesamt userReadings Kosten {
ReadingsVal("StromkostenGesamt","Verbrauch",0)*0.2507}

Genau wie bei den beiden einzelnen Messgeräte (PCA301-Steckdose) werden für die Dummys des Gesamtverbrauches ebenfalls ein at-Device angelegt.

define atGesamtStromkosten at +*00:01:00 a

Über den DEF-Editor wird das at-Device nun mit Leben befüllt:

+*00:01:00 {
my $a = (ReadingsVal("WZStromkostenGesamt","Verbrauch",0));
my $b = (ReadingsVal("WZStromkostenJahr","Verbrauch",0));
my $c = (ReadingsVal("WZStromkostenMonat","Verbrauch",0));
my $d = (ReadingsVal("WZStromkostenTag","Verbrauch",0));
my $e = (ReadingsVal("AZStromkostenGesamt","Verbrauch",0));
my $f = (ReadingsVal("AZStromkostenJahr","Verbrauch",0));
my $g = (ReadingsVal("AZStromkostenMonat","Verbrauch",0));
my $h = (ReadingsVal("AZStromkostenTag","Verbrauch",0));

my $Gesamt = $a + $e;
my $Jahr = $b + $f;
my $Monat = $c + $g;
my $Tag = $d + $h;

fhem("setreading StromkostenGesamt Verbrauch $Gesamt");
fhem("setreading StromkostenJahr Verbrauch $Jahr");
fhem("setreading StromkostenMonat Verbrauch $Monat");
fhem("setreading StromkostenTag Verbrauch $Tag");
}

Das at-Device besorgt sich nun die Werte der beiden PCA301-Steckdosen und rechnet die jeweils zusammen. Anschließend übermittelt es die errechneten Werte an die vier Gesamt-Dummys.

Absofort werden die Messwerte (Gesamt, Jahr, Monat und Tag) der beiden Mess-Steckdosen zusammengerechnet und in in den erstellen Dummys übersichtlich dargestellt. Wer möchte kann natürlich auch von den Gesamt-Dummys eine readingsGroup oder ein Diagramm erstellen. Mehr Infos dazu, entnehmt ihr aus den vorangegangenen Schritten.

Mir ist zwar bewusst, dass es eine Menga zu definieren gibt. Das Ergebniss hat mich jedoch überzeugt. Ich habe somit einen guten Überblick über die angefallenen Stromkosten. Hat man nun zum Beispiel eine Mess-Steckdose über, so kann man diese ja als mobiles Messgerät definieren und somit Langzeittests von unterschiedichen Geräten durchführen. Stromfresser hat man dann schnell ermittelt. 

Ich hoffe ich konnte euch meine Idee der Stromkosten- und Verbrauchsanalyse etwas näher bringen. Solltet ihr Ideen haben, wie man dies eleganter reallisiert, könnt ihr gerne ein Kommentar hinterlassen. Ich bin für jede Idee dankbar.

]]>
https://waschto.eu/stromkosten-als-diagramm-darstellen/feed 8 2123
Wetterdienste in FHEM einbinden https://waschto.eu/wetterdienste-in-fhem-einbinden https://waschto.eu/wetterdienste-in-fhem-einbinden#comments Sun, 22 Jan 2017 17:49:00 +0000 http://waschto.eu/?p=1939 weiterlesen →]]> Temperatur- und Luftfeuchtigkeitssensoren spielen in einem smarten Zuhause eine große und wichtige Rolle. Sei es zum Beispiel die MySensor-Sensoren oder die kleinen WeMos-Boards mit ESPEasy. Es gibt viele Möglichkeiten Umwelt-Sensoren in FHEM zu integrieren. Nicht immer liefern diese Selbstbausensoren jedoch korrekte Werte. Gründe dafür gibt es viele. Sei es, dass der Sensor von Schnee bedeckt ist oder in der prallen Sonne liegt. Im Sommer misst so der Sensor auf dem Balkon schnell mal 60 Grad. Für einen aussagekräftigen Temperaturverlauf eher unvorteilhaft. Aus diesem Grund kann es sinnvoll sein, sich neben den selbst gemessenen Werten auch offizielle Wetterdaten zu holen. FHEM stellt dafür eine Vielzahl an Modulen parat. In diesem Beitrag möchte ich euch folgende Module vorstellen und euch die Entscheidung somit etwas erleichtern.

Der erfahrende FHEM-Nutzer wird sich direkt fragen, warum ich zum Beispiel nicht auf das Modul WUNDERGROUND oder WWO eingehe. Der Grund ist, dass diese Module nicht ohne eine Anmeldung auf der entsprechenden Homepage funktionieren. Ich habe mich deswegen für diesen Beitrag auf Anmeldefreie-Module konzentriert. Dies sichert ein schnelles und unkomplizertes Einbinden in FHEM.

  • Weather
  • UWZ
  • PROPLANTA
  • YR

Aktuell gibt es zwar noch kein Modul, um die Wetterdaten vom norwegischen Wetterdienst YR in FHEM einzubinden, aber für Wetterdaten gibt es ja bereits eine Menge an Alternativen. Also warum hat es dieser Wetterdienst in diese Auflistung geschafft? Der Grund ist deren ansprechendes Wetterdiagram.

Ein weiterer Vorteil von YR ist, dass es Wetterdaten für sehr viele Ortschaften gibt. Auch innerhalb Deutschlands. Über die Startseite von YR lässt sich über ein Suchfeld der gewünschte Ort suchen. Die Sprache lässt sich oben rechts auf Englisch stellen.

Aufgrund der großen Anzahl an Ortschaften, kann sich die Suche etwas schwierig erweisen. Also genau schauen, dass ihr den richtigen Ort auswählt.

Habt ihr den passenden Ort gefunden, gelangt man auf die Übersichtsseite des gewünschten Ortes. In der linken Menüleiste gelangt man nun über "Hour by hour" zum Wetterdiagram.

Für Einbindung als WebLink speichert man sich nun die URL des Diagramms ab. Für Karlsruhe zum Beispiel lautet die URL wie folgt:

http://www.yr.no/place/Germany/Baden-W%c3%bcrttemberg/Karlsruhe/meteogram.png​

Der WebLink lässt sich dann wie folgt definieren:

define WetterYR weblink image http://www.yr.no/place/Germany/Baden-W%c3%bcrttemberg/Karlsruhe/meteogram.png

Über ein Attribut lässt sich das Diagram noch ein bisschen anpassen:

attr WetterYR htmlattr width="100%" height="300" frameborder="0" marginheight="0" marginwidth="0"

Wie ihr seht, gibt es auch genug Möglichkeiten Wetterdaten einzubinden, ohne sich auf Websiten anmelden zu müssen. Sie bieten eine Vielzahl von Wetter-Daten und lassen im Grunde keine Wünsche übrig. Das Modul WEATHER oder PROPLANTA im Zusammenhang mit ein paar Wetterkarten von UWZ runden das "Wetter-Paket" ab.

Ich persönlich habe mir ein SVG-Plot erstellt, in dem ich die Temperatur meines 1-Wire-Sensors und die Temperatur vom Proplanta-Modul anzeigen lasse. Zusätzlich lasse ich die Luftfeuchtigkeit von Proplante anzeigen. Ich kann somit sehr gut den selbstgemessenen und den offiziellen Wert miteinander vergleichen. Im Sommer lassen sich somit auch sehr gut Temperaturspitzen aufgrund direkter Sonneneinstrahlung rausfiltern.

]]>
https://waschto.eu/wetterdienste-in-fhem-einbinden/feed 5 1939
WifiLight – LED-Leuchtmittel in FHEM einbinden https://waschto.eu/wifilight-led-leuchtmittel-in-fhem-einbinden https://waschto.eu/wifilight-led-leuchtmittel-in-fhem-einbinden#comments Sun, 08 Jan 2017 20:07:13 +0000 http://waschto.eu/?p=1871 weiterlesen →]]> In diesem Beitrag möchte ich euch gerne eine weitere Möglichkeit zeigen, Lampen in FHEM einzubinden. Um genauer zu sein, geht es in diesem Beitrag um einen RGBW-LED-Streifen. Ich werde euch zeigen, wie ihr diesen über den Controller LD382 in FHEM einbindet. Der Controller LD382, besser bekannt als „LED Magic UFO“, lässt sich in FHEM mit dem Modul WifiLight einbinden.

Neben dem hier erwähnten LD382-Controller, lassen sich mit dem Modul auch weitere LED-Leuchtmittel einbinden. Unteranderem werden Leuchtmittel von MiLight, IVY, sengled oder LW12 unterstützt. Für die MiLight-Lampen empfehle ich euch jedoch das eigenständige Modul „MiLight“. Mehr dazu in meinem Blogbeitrag.

allgemeine Definition

Bevor man mit der Definition beginnt, sollte man sich die aktuellste Version des WifiLight-Moduls herunterladen. Dies geht am einfachsten über die Kommandozeile:

update force https://raw.githubusercontent.com/herrmannj/wifilight/master/controls_wifilight.txt

Das MiLight-Modul lässt sich dann wie folgt definieren:

define <name> WifiLight <Leuchtmitteltyp> <bridgetyp>:<IP|FQDN>

Wie man bereits an der Definition erkennt, muss bereits bei der Definition der Leuchtmitteltyp angegeben werden. Gemeint ist hiermit, ob es sich um einen einfachen RGB-Leuchtmittel handelt oder um ein RGBW-Leuchtmittel, also ein Leuchtmittel, welches extra weiße LEDs besitzt und die Farbe nicht durch Mischen erzeugt. Je nach Leuchtmittel kann es auch zusätzliche Leuchtmitteltypen geben. Wie zum Beispiel RGBW1 und RGBW2 bei den MiLight-Lampen. Mehr dazu im FHEM-Wiki.

Mit dem zweiten Parameter („bridgetyp“) wird der eigentliche Typ des Controllers angegeben – LW12, LW12HX, LD382, LD316 etc..

In diesem Beitrag werde ich erklären, wie sich der Controller LD382 in FHEM einbinden lässt. Die Einbindung anderer Controller lässt sich jedoch auf ähnliche Weise durchführen. Einfach entsprechend den Leuchtmittel- und bridgetyp entsprechend anpassen.

LD382 – LED Magic UFO

Der LD382 LED Magic UFO-Controller ist ein LED-Controller für RGB(W)-LED-Streifen. In der FHEM-Community ist er auch bekannt als „LED Magic UFO“ oder einfach nur als „UFO“. Das sogenannte „UFO“ ist relativ günstig in der Anschaffung und lässt sich einfach ins eigene Netzwerk einbinden. Es handelt sich zwar um ein typisches „China-Produkt“, die Verarbeitung ist jedoch dem Preis entsprechend gut.

Letzte Aktualisierung am 27.05.2017 / Affiliate Links / Bilder von der Amazon Product Advertising API

Der passende LED-Streifen

Mit diesem Controller lassen sich sowohl RGBW-Streifen als auch einfache RGB-Streifen steuern. Die einzige Voraussetzung ist, dass der Streifen einen gemeinsamen Plus-Pol besitzt.

Letzte Aktualisierung am 27.05.2017 / Affiliate Links / Bilder von der Amazon Product Advertising API

Die maximale Länge (ohne zusätzliche Verstärker) ist begrenzt durch die maximale Leistung des Controllers. Der Hersteller gibt diese mit 96W an. Das ergibt bei 12V Eingangsspannung 2A pro Kanal bei vier Kanälen (rot, grün, blau, weiß). Geht man von einem Stromverbrauch von maximal 20mA pro LED (Farbe) aus, so sind maximal 100 LEDs pro Kanal erlaubt.

Es lassen sich natürlich auch mehr LEDs betreiben. Man sollte jedoch die maximale Eingangsleistung (max. 96W) nicht übertreffen. Verwendet man nun doch mehr als 100 Leds pro Kanal, kann es zu Helligkeitseinbüßen kommen.

Das passende Netzteil

Die externe Spannungsversorgung kann entweder über zwei Schraubklemmen oder über eine 2,5mm-Anschluss eingespeist werden. Der Controller lässt sich mit einer Versorgungsspannung von 12V bis 24V betreiben.

Da ich noch ein Schaltnetzteil rumliegen hatte, habe ich mir für den Weg über die zwei Schraubklemmen entschieden.

Letzte Aktualisierung am 27.05.2017 / Affiliate Links / Bilder von der Amazon Product Advertising API

Da man bei diesem Schaltnetzteil jedoch auch die 230V-Zuleitung über offenliegende Schraubklemmen anschließt, ist diese Variante nur etwas für ausgebildete Fachkräfte. Für den Hobby-Anwendet empfehle ich die Variante über den 2,5mm-Anschluss. Ein handelsübliches Netzteil mit 2,5mm-Anschluss und 12V Ausgangsspannung gibt es bereits zu Hauf im Internet.

Sale
LEICKE Netzteil 60W 12V 5A 5,5*2,5mm für LCD TFT Bildschirm...

Leicke - Elektronik

19,99 EUR - 4,00 EUR 15,99 EUR

Letzte Aktualisierung am 27.05.2017 / Affiliate Links / Bilder von der Amazon Product Advertising API

Das Netzteil muss natürlich der gewünschten Leitungslänge angepasst werden. Ein Leistungsstärkeres Netzteil (max. 96 Watt) geht natürlich immer.

Anschluss des LED-Streifens

Der LED-Controller stellt für den Anschluss des LED-Streifens sechs Schraubklemmen zur Verfügung. Zwei für den Plus-Pol des Streifens, drei für GND der Fabre rot, grün, blau und ein GND-Anschluss für die Farbe weiß.

In einigen Foren-Beiträge habe ich gelesen, dass die Beschriftung der Anschlüsse nicht der Realität entspricht. Bei mir war dies jedoch nicht der Fall. Ich habe demnach den Anschluss „R“ mit dem Lötpad „R“ vom Streifen verbunden usw. Die spätere Farbeinstellung hat mit der eigentlichen Farbe des Streifen übereingestimmt. Solltet ihr also später bemerken, dass zum Beispiel anstatt Rot die Farbe Blau dargestellt wird, einfach mal die Anschlussbelegung überprüfen.

manuelle Ersteinrichtung über die APP

Der Controller lässt sich natürlich auch ohne FHEM steuern. Möglich macht dies die App „Magic Home WiFi“.

Magic Home WiFi (Kostenlos, App Store) →

Magic Home WiFi (Kostenlos, Google Play) →

Neben dem Steuern des Controllers, wird die App auch für die Ersteinrichtung benötigt.

Nachdem man den LED-Streifen und die Spannungsversorgung an das „UFO“ angeschlossen hat, beginnt es ein eigenes WLAN-Netzwerk aufzubauen. In meinem Fall eines mit dem Namen „LEDnet5F6E18“

Hat man sich mit diesem Verbunden hat, kann man mit der oben genannte App die Ersteinrichtung starten. Im Normalfall öffnet sich der Einrichtungsprozess automatisch.

Sollte anstelle des Einrichtungsmenüs die Auflistung des Controllers angezeigt werden, lässt sich der Einrichtungsvorgang auch über die Einstellungen starten. Dazu einfach über das Zahnrad oben links die Einstellungen öffnen.

Nun kann der Controller über „Mit Netzwerk verbinden“ ins eigene Netzwerk eingebunden werden. Eine weitere Möglichkeit ist, dass man auf den gefunden Controller klickt und den Schieberegler bei „Mit Drathlosnetzwerk verbinden“ aktiviert.

Der Controller beginnt nun mit der Suche nach vorhandenen Netzwerken. Nach der Eingabe des Netzwerkschlüssels wird der Controller neu gestartet und befindet sich nun im eigenen Netzwerk. Der LED-Streifen kann nun bereits über die App gesteuert werden. Es stehen unterschiedliche Modi zu Verfügung. Einfach ein bisschen experimentieren.

automatische Ersteinrichtung über WPS

Wer sich den Umweg über die App ersparen möchte, kann den Controller auch über WPS ins eigene Heimnetz einbinden. Dafür einfach auf eurem Router WPS aktivieren (Push-Button Methode) und anschließend den Button in der Mitte vom Controller drücken. Der Controller befindet sich nun im eigenen Heimnetz und kann über die App gesteuert werden.

ACHTUNG: Aus Sicherheitsgründen solltet ihr WPS nach dem Einrichten wieder deaktivieren. Dauerhaft aktiviertes WPS stellt ein großes Sicherheitsrisiko dar.

Definition in FHEM

Wie oben bereits erwähnt, lassen sich mit dem MiLight-Modul eine Vielzahl an Controller-Typen einbinden. Im folgenden erkläre ich euch die Einbindung des Controllers LD382.

define LEDLeiste WifiLight RGBW LD382A:192.168.2.102

Ältere Versionen des LD382 werden ggf. über den „bridgetyp“ LD382 eingebunden. Die IP-Adresse ist entsprechend anzupassen. Sollte man „nur“ ein RGB-Streifen verweden, dann entsprechend RGBW zu RGB ändern.

Nachdem der Controller in FHEM eingebunden wurde, kann man über ein set-Befehl die gewünschte Farbe einstellen. Die Farbe wird dabei als HEX-Wert übergeben.

set LEDLeiste RGB RRGGBB

RRGGBB muss dabei durch einen gültigen Farbwert ausgetauscht werden. Für ein Rot zum Beispiel:

set LEDLeiste RGB FF0000

Wer mit den HEX-Werten nicht gut zurecht kommt, kann durch ein Attribut ein RGB-Farbfeld hinzufügen, welches die Farbauswahl vereinfacht.

attr LEDLeiste webCmd RGB
attr LEDLeiste widgetOverride RGB:colorpicker,RGB

Nun kann die Farbe über das Eingabefeld innerhalb des „DeviceOverview“ mit einem Farbfeld ausgewählt werden.

 

Nachdem der Controller in FHEM eingebunden wurde, kann man sich daran machen, die nun über FHEM steuerbare LED-Leiste weiter ins smarte Zuhause einbinden. Sei es zum Beispiel sie mit weiteren LED-Lampen zu koppeln oder sie als Anzeige für eingehende Anrufe zu verwenden. Die Möglichkeiten sind vielfältig.

]]>
https://waschto.eu/wifilight-led-leuchtmittel-in-fhem-einbinden/feed 3 1871
LightScene – Erstellen von Lichtszenen https://waschto.eu/lightscene-erstellen-von-lichtszenen https://waschto.eu/lightscene-erstellen-von-lichtszenen#respond Thu, 05 Jan 2017 15:44:43 +0000 http://waschto.eu/?p=1831 weiterlesen →]]> Je länger man sich mit FHEM beschäftigt, desto mehr Devices hat man eingebunden. Dies führt früher oder später dazu, dass man auch mehrere Licht-Devices eingebunden hat. Sei es eine einfache Stehlampe, die man über eine Funksteckdose schaltet, eine MiLight-LED-Lampe oder ein RGB-LED-Streifen. Die Anzahl an smartem Licht wächst und wächst und man gelangt an einen Punkt, in dem man die einzelnen Lampen miteinander verknüpfen will. Sobald sich zum Beispiel die Hängelampe auf rot schaltet, soll die LED-Leiste in der Vitrine sich ebenfalls auf rot schalten. Um dies zu realisieren, kann man natürlich mit DOIFs oder Notifys arbeiten. Diese Lösung ist jedoch nicht gerade komfortabel. In diesem Beitrag möchte ich euch deshalb eine elegantere Lösung zeigen. Der Einsatz des Hilfsmoduls „LightScene“.

Mit diesem Modul lassen sich sogenannte Lichtszenen abspeichern und durch ein einzigen set-Befehl wieder aufrufen. So lassen sich komplexe Lichtszenen erstellen ohne sich Gedanken über den korrekten Aufbau eines DOIFs oder Notifys zu machen.

Definition

Das Hilfsmodul definiert sich wie folgt:

define <name> LightScene [<dev1>] [<dev2>] [<dev3>] ...

Bereits während der Definition können alle beteiligten Devices der gewünschten Lichtszene angegeben werden. Zusätzliche Geräte lassen sich natürlich später durch den DEF-Editor hinzufügen. Für eine Lichtszene mit der oben genannten MiLight-LED-Lampe und der LED-Leiste lautet die Definition wie folgt:

define Lichtszene LightScene WZ_Haengelampe LEDLeiste

Mit diesem erstellten Device lassen sich nun die gewünschten Lichtszenen einrichten.

Lichtszenen einrichten

Bevor man nun die Lichtszene definiert, sollte man die gewünschte Lichtszene einstellen. Das heißt die Devices, welche dem Device Lichtszene zugeordnet wurden, wie gewünscht einstellen. In meinem Fall wird das Device „Lichtleiste“ mit der Farbe blau und das Device „WZ_Haengelampe“ mit der Farbe grün eingeschaltet.

Das Einrichten einer Lichtszene geschieht dann über ein set-Befehl. Über das Drop-Down-Menü lässt sich der Eintrag „save“ auswählen.

Über das nebenstehende Eingabefeld lässt sich nun der Name der Lichtszene eingeben. In diesem Fall wird die Lichtszene den Namen „Lichtszene1“ bekommen.

Klickt man nun auf „set“, dann wird der aktuelle Status der beiden Devices (Lichtleiste und WZ_Haengelampe) in die Lichtszene „Lichtszene1“ abgespeichert. Es lassen sich natürlich auch mehrere Lichtszenen einrichten. Einfach die gewünschte Szene einstellen und dann wieder über „set“ abspeichern. Alle eingerichteten Szenen erscheinen nun an oberer Stelle in der Detailseite des LightScene-Devices.

Eine neue Lichtszene lässt sich natürlich auch über die Kommandozeile erstellen:
set Lichtszene save Lichtszene1

„Lichtszene“ beschreibt dabei das LightScene-Device und „Lichtszene1“ den Namen der ein zurichteten Lichtszene.

Lichtszenen aktivieren

Die eingerichteten Lichtszenen lassen sich über verschiedene Wege aktivieren. Bei geöffneter Detailseite lassen sich die einzelnen Lichtszenen durch anklicken auf den entsprechenden Namen aktivieren.

Die zweite Möglichkeit ist das Setzen der Lichtszene über ein set-Befehl. Dieser set-Befehl kann einfach über das Drop-Down-Menü ausgewählt werden. Über ein weiteres Drop-Down-Menü lässt sich dann die gewünschte Szene auswählen und über „set“ aktivieren.

Der set-Befehl kann natürlich auch über die Kommandozeile eingegeben werden. Dieser lässt sich dann auch zum Beispiel in Notifys einbauen.
set Lichtszene scene Lichtszene1

„Lichtszene“ steht dabei für das oben definierte LightScene-Device. Mit „Lichtszene1“ gibt man die gewünschte Lichtszene an.

Die dritte Möglichkeit ist das nacheinander durchschalten aller Szenen. Dies geschieht entweder ebenfalls über das Drop-Down-Menü oder über einen set-Befehl:

set Lichtszene nextScene

set Lichtszene previousScene

Mit diesen Befehlen kann entweder die nächste (nextScene) oder die vorherige (previousScene) Lichtszene aktiviert werden. Ist aktuell keine Szene aktiv, dann wird entweder die erste Szene (nextScene) oder die letzte Szene (previousScene) aktiviert.

Lichtszenen bearbeiten

Eingerichteten Szenen lassen sich natürlich auch bearbeiten. Am einfachsten geht dies über das Drop-Down-Menü „Edit scene“.

Es öffnet sich der Szenen-Editor. Hier werden nun alle Devices aufgelistet, welche der Lichtszene zugeordnet sind. Über ein weiteres Drop-Down-Menü lässt sich nun der Reiter „set“ oder „setcmd“ auswählen.

Bei ausgewähltem „set“, lässt sich im nebenstehenden Eingabefeld der auszuführende Befehl editieren. In meinem Fall wird zum Beispiel unteranderem beim aktivieren der „Lichtszene1“ das Device „LEDLeiste“ mit dem Befehel „RGB 0000FF“ eingeschaltet.

Über das Eingabefeld lässt sich dieser Befehl nun editieren. Der Syntax muss dabei so befolgt werden, dass der eingegebene Befehl vom Device auch als set-Befehl akzeptiert wird. Im Fall der „LEDLeiste“ wäre es zum Beispiel folgender set-Befehl:

set LEDLeiste RGB 0000FF

Wählt man dagegen „setcmd“ aus, so lassen sich komplexere Befehle eingeben. Es lassen sich dann auch andere bzw. zusätzliche Devices schalten, welche eigentlich nicht zur Lichtszene zugehören. Mehrere Befehle müssen durch ein Semikolon voneinander getrennt sein. Des Weiteren muss bei „setcmd“ der komplette Befehl ausgeschrieben werden.
set WZ_Haengelampe rgb 0000FF; set WZ_Papierlampe off

Das Bearbeiten kann natürlich auch direkt über die Kommandozeile erfolgen:

set Lichtszene set Lichtszene1 LEDLeiste RGB 00FFFF

bzw.
set Lichtszene setcmd Lichtszene1 set WZ_Haengelampe rgb 00FFFF;; set WZ_Papierlampe on

Beim Absenden über die Kommandozeile muss jedoch auf das doppelte Semikolon geachtet werden.

Lichtszenen löschen

Eingerichtete Lichtszenen können selbstverständlich auch wieder gelöscht werden, ohne das ganze Device löschen zu müssen. Dies kann, wie das Editieren von Lichtszenen, über das set-Drop-Down-Menü erledigt werden. Dazu einfach „remove“ auswählen und den Namen der zu löschenden Lichtszene über das nebenstehende Drop-Down-Menü auswählen.

Dies kann natürlich auch über die Kommandozeile erledigt werden:
set Lichtszene remove Lichtszene2

Auch hier steht „Lichtszene“ wieder für das LightSzene-Device und „Lichtszene2“ für die zu löschende Lichtszene.

Lichtszenen umbenennen

Neben dem Bearbeiten und dem Löschen von Lichtszenen, lassen sich diese auch umbenennen. Dies geschieht ebenfalls über das Drop-Down-Menü. Einfach „rename“ auswählen und im nebenstehenden Eingabefeld den alten, gefolgt vom neuen Namen eingeben.

In diesem Fall wird die Lichtszene „Lichtszene2“ in „lesen“ umbenannt.

Der dazu äquivalente set-Befehl lautet wie folgt:
set Lichtszene rename Lichtszene2 lesen

Auch hier steht „Lichtszene“ wieder für das LightSzene-Device.  „Lichtszene2“ ist der alte Name und „lesen“ der neue Name.

Lichtszenen auslesen

Möchte man zu einem späteren Zeitpunkt einmal kontrollieren, welche Einstellungen eine Lichtszene beinhaltet, dann lässt sich über ein get-Befehl die Lichtszene auslesen. Am einfachsten geht dies über das get-Drop-Down-Menü. Über den Eintrag „scene“ und der ausgewählten gewünschten Lichtszene erhält man durch klicken auf „get“ die mit der Lichtszene verbundenen Einstellungen.
Dies klappt natürlich auch über die Kommandozeile:
get Lichtszene scene Lichtszene1

Es werden die Einstellungen der „Lichtszene1“ ausgegeben.

Lichtszenen auflisten

Über einen weiteren get-Befehl lassen sich alle vorhandenen Lichtszenen auslesen. Dazu einfach „scenes“ im Menü auswählen.

get Lichtszene Scenes

Man erhält nun eine Auflistung aller vorhandener Szenen. Diese Auflistung lässt sich zum Beispiel verwenden, um in selbst geschriebenen Skripte (99_myUtils.pm) die vorhandenen Lichtszene auszulesen und mit diesen dann weiter arbeiten zu können.

Attribute

Wie jedes Modul, hat auch das LightScene-Modul einige spezielle Attribute. Im folgenden werde ich die wichtigsten Attribute etwas näher drauf eingehen. Wer mehr Infos zu den verfügbaren Attributen braucht, dem empfehle ich das Commando-Ref von FHEM.

async_delay

Mit dem Attribut „async_delay“ lässt sich eine Zeitverzögerung zwischen den einzelnen Befehlen einstellen. Hat man zum Beispiel wie in meinem Fall zwei Devices eingebunden (Lichtleiste und WZ_Haengelampe), so werden beim Aktivieren der Lichtszene mindestens zwei Befehle abgesetzt.

Mit dem Attribut „async_delay“ lässt sich die Zeit zwischen Absetzen des ersten und des zweiten Befehls angeben. Es lässt sich aber nur die Zeit zwischen den Befehlen der Devices einstellen. Hat man aber zum Beispiel durch „setcmd“ weitere Befehle innerhalb eines Devices eingerichtet, so werden diese ohne Zeitverzögerung abgearbeitet. Hier eine kleine Abbildung zur Veranschaulichung:

attr Lichtszene async_delay 3

Die Zeitangabe erfolgt dabei in Sekunden.

lightSceneParamsToSave

Standardmäßig wird beim Abspeichern einer Lichtszene nur das state-Reading in die abgespeicherte Lichtszene eingebunden.

Es kann jedoch auch sein, dass man weitere Readings mit abspeichern möchte. Wie zum Beispiel der Farbraum „hsv“, anstellte von „rgb“. Mit dem Attribut „lightSceneParamsToSave“ lassen sich diese zusätzlichen Readings mit einbinden. Das Attribut wird dabei beim Device selber gesetzt. Mehrere Readings lassen sich durch ein Komma trennen.
attr WZ_Haengelampe lightSceneParamsToSave hsv

Je nach Device-Typ wird dieses Attribut auch automatisch gesetzt. Zum Beispiel der Farbraum „hsv“ der MiLight-Lampen wird automatisch durch setzen des Attribut „lightSceneParamsToSave“ eingebunden.

Mit LightScene lassen sich somit komfortabel Lichtszenen einrichten und sie mit nur einem einzigen Befehl aktivieren. Das Modul lässt sich natürlich auch zweckentfremden und andere Devices als Lichter einbinden. So lässt sich zum Beispiel sein HomeCinema mit diesem Modul komfortabel einrichten. Dazu einfach alle benötigten Devices einbinden. Zum Beispiel:
define HomeCinema LightScene TV,Pioneer,Lampe

Anschließend alle gewünschten Einstellungen vornehmen und diese als eine Szene abspeichern.

Ich hoffe ich konnte euch das Modul etwas näher bringen und euch helfen eure eigenen Lichtszenen einzurichten. Bei Fragen könnt ihr gerne ein Kommentar hinterlassen.
]]>
https://waschto.eu/lightscene-erstellen-von-lichtszenen/feed 0 1831
PIONEERAVR, ONKYO_AVR, DENON_AVR, YAMAHA_AVR – AV-Receiver in FHEM einbinden https://waschto.eu/pioneeravr-onkyo_avr-denon_avr-yamaha_avr-av-receiver-in-fhem-einbinden https://waschto.eu/pioneeravr-onkyo_avr-denon_avr-yamaha_avr-av-receiver-in-fhem-einbinden#comments Fri, 30 Dec 2016 21:36:25 +0000 http://waschto.eu/?p=1776 weiterlesen →]]> FHEM bietet bereits die Möglichkeit eine Vielzahl von Geräten einzubinden. Sei es zum Beispiel die FritzBox oder Android-Geräte. In diesem Beitrag möchte ich euch eine weitere Gerätegruppe vorstellen, die ihr in FHEM einbinden könnt. Die Rede ist von AV-Receiver. Heutige AV-Receiver besitzen fast alle eine Netzwerkschnittstelle und lassen sich somit in das heimische Netzwerk einbinden. Da liegt es doch nahe, diese auch in FHEM einzubinden.

Dieser Beitrag wird sich mit dem Einbinden von AV-Receivern der Marke Pioneer, Onkyo, Denon, Marantz und Yamaha beschäftigen. Er soll als eine Art Auflistung der aktuell unterstützen AV-Receiver gesehen werden. Wer mehr Infos zu den einzelnen Modulen haben möchte, der kann sich gerne im entsprechenden FHEM-Wiki bzw. FHEM-Command-Ref informieren. Die Links dazu habe ich jeweils mit angegeben.

Pioneer

Für Receiver der Marke Pioneer gibt es zwei Module. Das Modul „PIONEERAVR“ für die Hauptzone und das Modul „PIONEERAVRZONE“ für zusätzliche Zonen.

PIONEERAVR

Die Hauptzone wird wie folgt definiert:

define <name> PIONEERAVR telnet <IPAddress:Port>

define PioneerReceiver PIONEERAVR telnet 192.168.2.122

Die Verbindung wird über „Telnet“ hergestellt. Um das Modul zu definieren, ist die IP-Adresse des Receiver notwendig. Der Port ist standardmäßig auf 23 eingestellt, kann aber durch die Angabe eines anderes Ports geändert werden. Natürlich entsprechend der Einstellung vom Receiver.

Anstelle einer telnet-Verbindung ist auch die Verbindung über einen seriellen Anschluss möglich, vorausgesetzt der Receiver besitzt eine solche. Über einen Seriell-USB-Adapter lässt sich diese dann mit dem Raspberry verbinden.

define <name> PIONEERAVR serial <SerialDevice>[<@BaudRate>]

define PioneerReceiver PIONEERAVR serial /dev/ttyUSB0@9600

USB0 entsprechend anpassen.

Ist der Receiver definiert, lassen sich nun viele verschiedene Einstellungen vornehmen. Eine Auflistung aller möglichen Befehle findet ihr in der Command-Ref von FHEM.

PIONEERAVRZONE

Um eine zusätzliche Zone einzurichten, stellt FHEM das Modul „PIONEERAVRZONE“ zur Verfügung. Definiert wird eine Zone wie folgt:

define <name> PIONEERAVRZONE <Zone>

Das Definieren einer Zone setzt die Definition einer Hauptzone voraus. Ist dies der Fall, lässt sich eine zweite Zone wie folgt definieren:

define PioneerReceiverZone2 PIONEERAVRZONE zone2

Mögliche Zonen sind „zone2“, „zone3“ und „hdZone“. Standardmäßig wird das letzte Pioneer-Device als Hauptzone bzw. Steuergerät verwendet. Sollten mehrere Pioneer-Receiver definiert sein, kann über das Attribut „IODev“ das Steuerdevice ausgewählt werden:

attr PioneerReceiverZone2 IODev PioneerReceiver

Auch hier sind dann wieder eine Vielzahl an Befehlen vorhanden. Mehr dazu im Command-Ref von FHEM.

Nachteil und eventuelle Probleme:

mehrere Verbindung über einen Port

Da die Verbindung zwischen FHEM und dem Receiver über telnet läuft, lässt sich immer nur eine Verbindung pro Port aufbauen. Hat sich also FHEM über den Port 23 mit dem Receiver verbunden, kann sich zum Beispiel kein Smartphone über den selben Port verbinden.

Einige Pioneer-Receiver unterstützen das gleichzeitige Benutzen mehrere Ports. Pioneer selbst gibt dabei folgende Port-Nummern an: 23 oder 49152-65535. So lässt sich zum Beispiel das FHEM -Device mit einem alternativen Port definieren:

define PioneerReceiver PIONEERAVR telnet 192.168.2.122:49152

Der Port muss entsprechend im Receiver eingestellt sein.

Einbindung neuerer Receiver (Modelle ab 2015)

Durch den Zusammenschluss von Onkyo und Pioneer im Frühjahr 2015, werden einige Modelle von Pioneer von Onkyo gebaut. Dies führt dazu, dass einige Modell von Pioneer nicht mit dem Modul „PIONEERAVRZONE“ in FHEM eingebunden werden können. Die Lösung ist jedoch relativ simpel. Anstelle den Receiver über das Pioneer-Modul zu definieren, muss der Receiver über das ONKYO-Modul eingebunden werden. Ein Beispiel ist da zum Beispiel der AVR-Receiver VSX-1131 von Pioneer. Dieser wurde von Onkyo gebaut und wird deswegen über das Onkyo-Modul in FHEM definiert.

Echtzeit

Mit dem Pioneer-Modul lassen sich eine Vielzahl von Receivern einbinden. Es lassen sich jedoch nicht mit jedem Receiver die selben Einstellungen vornehmen.

Ein wichtiger Unterschied ist die Statusrückmeldung. Um einen wirklich praktischen Vorteil der Einbindung zu bekommen, ist eine Statusrückmeldung des Receivers in Echtzeit notwendig. Dies gibt es jedoch nicht bei jedem. Ein Receiver der über eine „Echtzeit-Kommunikation“ verfügt, ist der Pioneer VSX-830. Ich vermute, dass die Nachfolger dies dann ebenfalls unterstützen (z.B. VSX-831, VSX-923 etc.).

Onkyo

Ähnlich wie bei den Pioneer-Receiver, gibt es auch für die Onkyo-Receiver zwei Module. Ein Hauptmodul „ONKYO_AVR“ für die Hauptzone und ein Modul für weitere Zonen – „ONKYO_AVR_ZONE“

Die Verbindung zwischen dem Receiver und FHEM läuft dabei über eine einfache Netzwerk-Verbindung in Echtzeit. Das Problem der Ports ist somit im Gegensatz zum Pioneer-Modul nicht vorhanden.

ONKYO_AVR

define <name> ONKYO_AVR <ip-address-or-hostname[:PORT]> [<protocol-version>]

define OnkyoReceiver ONKYO_AVR 192.168.2.122

Bei Bedarf kann der Port und das Protokoll angepasst werden. Mehr Infos dazu in der Command-Ref von FHEM.

Bei einem vorhanden Seriellen-Anschluss kann der Receiver auch über diesen eingebunden werden:

define <name> ONKYO_AVR <devicename[@baudrate]> [<protocol-version>]

define OnkyoReceiver ONKYO_AVR serial /dev/ttyUSB0@9600

Ist der Receiver definiert, lassen sich genau so wie beim Pioneer allmögliche Einstellungen vornehmen. Eine Auflistung aller möglichen Befehle findet ihr in der Command-Ref von FHEM.

ONKYO_AVR_ZONE

Ähnlich wie beim Pioneer, lassen sich auch beim Onkyo zusätzliche Zonen definieren. Dies geschieht über das Module „ONKYO_AVR_ZONE“.

define <name> ONKYO_AVR_ZONE [<zone-id>]

define OnkyoReceiverZone2 ONKYO_AVR_ZONE 2

Im Unterschied zum Pioneer-Modul werden hier die Zonen durch eine einfache Zahl definiert.

Auch hier sind dann wieder eine Vielzahl an Befehlen vorhanden. Mehr dazu im Command-Ref von FHEM.

Denon

Der dritte Receiver-Hersteller ist Denon, auch für dessen Receiver stellt FHEM zwei Module bereit. „DENON_AVR“ für die Hauptzone und „DENON_AVR_ZONE“ für zusätzliche Zonen.

Diese beiden Module sind aktuell noch nicht offiziell in FHEM integriert (Stand Dez. 16). Sie lassen sich jedoch aus dem FHEM-Forum downloaden. Mehr dazu im Post-Beitrag vom Modul-Hersteller.

Da sich das Modul noch in der Test-Phase befindet, gehe ich hier nur kurz auf die Definition ein. Für mehr Infos bitte im entsprechenden FHEM-Forum nachschauen.

DENON_AVR

Die Hauptzone wird ähnlich wie bei den Onkyo-Receiver über die IP-Adresse definiert:

define <name> DENON_AVR <ip-address-or-hostname[:PORT]>

define DenonReceiver DENON_AVR 192.168.2.122

Laut Modul-Hersteller bietet das Modul diverse Readings für Audio- und Videoeinstellungen. Des Weiteren wird eine breite Palette an Set-Befehlen unterstützt. Mehr dazu im FHEM-Forum.

DENON_AVR_ZONE

Zusätzliche Zonen lassen sich über das Modul „DENON_AVR_ZONE“ definieren:

define <name> DENON_AVR_ZONE <Zone>

define DenonReceiverZone2 DENON_AVR_ZONE 2

Mehr Infos zum Modul im FHEM-Forum.

Marantz

AV-Receiver der Marke Marantz werden ebefalls über das DENON-Modul eingebunden. Der Unterschied zwischen den Marantz- und den Denon-Receiver ist die Bezeichnung der Quick-Select (Denon) bzw. der Smart-Select-Tasten (Marantz) auf der Fernbedienung. Über das Attribut „brand“ kann die Marke ausgewählt werden.

attr MarantzReceiver brand Marantz

Die Set-Befehle der oben genannten Tasten werden dann entsprechend angepasst.

Yamaha

Im Gegensatz zu den oben genannten Modulen, gibt es für die Yamaha-Receiver nur ein Modul. Über dieses Modul wird die Hauptzone und die zusätzlichen Zonen definiert.

define <name> YAMAHA_AVR <IP-Addresse> [<Zone>] [<Status_Interval>]

Ohne die Angabe eine Zone wird die Hauptzone definiert.

define YamahaReceiver YAMAHA_AVR 192.168.2.122

Durch die Angabe einer Zone lassen sich zusätzliche Zonen definieren:

define YamahaReceiverZone2 YAMAHA_AVR 192.168.2.122 zone2

Es lassen sich insgesamt drei zusätzliche Zonen definieren – zone2, zone3 und zone4

Genau wie bei den anderen Modulen lässt sich dann eine große Anzahl an Readings auslesen und diverse Befehle absetzen. Mehr dazu in der FHEM-Command-Ref.

Mein Alltagseinsatz

Ich persönlich verwende den Pioneer VSX-1131.

Sale
Pioneer VSX-1131-B 7.2 Netzwerk-Mehrkanal Receiver (160 Watt...

Dietmar Binger - Pioneer & Onkyo Europe GmbH Zweigniederlassung Willich - Elektronik - Deutsch

649,00 EUR - 194,00 EUR 455,00 EUR

Letzte Aktualisierung am 27.05.2017 / Affiliate Links / Bilder von der Amazon Product Advertising API

Da dieser Receiver von Onkyo gebaut wird, habe ich den AV-Receiver über das Onkyo-Modul eingebunden:

define PioneerReceiver ONKYO_AVR 192.168.2.122

Durch das Einbinden habe ich nun die Möglichkeit den AV-Receiver in unterschiedlichen Aktionen einzubinden. Eine sinnvolle Integration ist zum Beispiel die Lautstärke bei einem eingehenden Anruf zu minimieren.

CallMonitor:event:.ring set PioneerReceiver volume 50

Problem bei der Lautstärkeregelung ist die unterschiedliche Skala. Während man beim FHEM die Lautstärke in Prozent (0-100) angibt, wird die Lautstärke beim Receiver selbst standardmäßig in Dezibel angezeigt. Die Lautstärke 50% ergibt ein Lautstärke von -57dB.

Voraussetzung ist natürlich, dass die FritzBox und der CallMonitor eingerichtet sind. Wer mehr Infos zum Thema „Verwendung von Anrufe als Auslöser“ haben möchte, der kann gerne auf meinem Blog-Beitrag dazu vorbeischauen.

Wie man sieht, lassen sich bereits eine große Anzahl an AV-Receiver einbinden. Dadurch lassen sich eine Menge an nützlicher Funktionen realisieren und den AV-Receiver mehr ins eigene smarte Zuhause integrieren.

]]>
https://waschto.eu/pioneeravr-onkyo_avr-denon_avr-yamaha_avr-av-receiver-in-fhem-einbinden/feed 2 1776