Raspberry ausschalten mit FHEM

Man kann den Raspberry einfach so vom Strom ziehen - aber schön ist das nicht!
Wenn man schon FHEM drauf hat, kann man sich auch einen Ausschaltknopf auf der Oberfläche machen.

Achtung: Der Raspberry kann kein WOL oder ähnliches. Aus ist Aus. Baut man das mit dem "halt"
wirklich auf die Weboberfläche muss man sich auch über einen Neustart Gedanken machen!

Als erstes muss der User fhem (der User unter dem FHEM läuft) ein reboot oder halt des Systems auch dürfen. Im raspbian kann man dafür einfach eine Textdatei im Pfad /etc/sudoers.d/ ablegen, man braucht die eigentliche sudoers Datei nicht mit visudo zu editieren (ist mittlerweile in vielen anderen Systemen Standard).
Hinweis:
Der Benutzer Pi bekommt über genau diesen Weg seine sudo Rechte, einfach mal anschauen:

sudo cat /etc/sudoers.d/010_pi-nopasswd

Rechte für User fhem setzen

Wie immer mache ich das gern mit einem Script (welches mit sudo ausgeführt werden muss):

#!/bin/bash
# ergänze eine Datei zum sudoers Script Verzeichnis /etc/sudoers.d/
File="011_fhem-nopasswd"
echo "fhem ALL=(ALL) NOPASSWD: /sbin/reboot, /sbin/shutdown, /sbin/halt" >/etc/sudoers.d/$File
chmod 0440 /etc/sudoers.d/$File

Man kann den Erfolg sofort testen, aber vorher save nicht vergessen, falls man gerade in FHEM etwas geändert hat!
Wenn man in der FHEM Befehlszeile "sudo /sbin/reboot" eingibt, sollte der Raspberry jetzt neu starten. Ein umfangreiches Manual zum Syntax in der Datei findet man hier.

Bedienelemente in FHEM

Damit man einen Knopf in der Oberfläche von FHEM bekommt, kann man es analog zu diesem Beitrag machen. Dazu braucht man allerdings erstmal einen FHEM Befehl:

define s1 cmdalias reboot AS "sudo /sbin/reboot"

Das kann man wieder sofort testen, in dem man reboot in der Kommandozeile von FHEM eingibt - man muss nur aufpassen, dass dem Raspberry nicht schwindelig wird.

define Systembefehle weblink cmdList Restart:Restart-Fhem:shutdown+restart Restart:Restart-System:reboot Update:Update-Check:update+check Update:Update-Now:update Shutdown:Shutdown-System:halt

Der aufmerksame Leser hat gemerkt: hier fehlt noch etwas! Der alias für halt:

define s2 cmdalias halt AS "sudo /sbin/halt"

Optisch sieht das Ganze so aus:

Mit diesem Befehl kann man den Ausschalter auch links ins Menü packen:

attr WEB menuEntries System-Halt,/fhem?cmd=halt

Ein Script zum Einrichten

Für den ganz Eiligen habe ich hier noch alles in einem Script. Damit man das nicht erst noch ausführbar machen muss, kann man es einfach mit sudo bash <scriptname> starten

#!/bin/bash
# System Befehle für FHEM
File="011_fhem-nopasswd"
echo "fhem ALL=(ALL) NOPASSWD: /sbin/reboot, /sbin/shutdown, /sbin/halt" >/etc/sudoers.d/$File
chmod 0440 /etc/sudoers.d/$File
perl /opt/fhem/fhem.pl 7072 '
define s1 cmdalias reboot AS "sudo /sbin/reboot"
define s2 cmdalias halt AS "sudo /sbin/halt"
define Systembefehle weblink cmdList Restart:Restart-Fhem:shutdown+restart Restart:Restart-System:reboot Update:Update-Check:update+check Update:Update-Now:update Shutdown:Shutdown-System:halt
attr WEB menuEntries System-Befehle,/fhem?detail=Systembefehle
save
'

Kleiner Makel

Beim Restart von FHEM (und damit auch beim Restart System) ist danach der csrf Token vom Link nicht mehr gültig. Der Kontakt von FHEM kehrt also nicht allein zurück. Mit der zurück taste im Browser geht es wieder ins Menü.

Inhalt der sudoers Datei

Die durch Komma getrennten Werte in der Datei haben folgende Bedeutung und benötigen immer den vollen Pfad!

/usr/sbin -> für alles im Verzeichnis
/usr/sbin/service * -> für alle Parameter
/usr/sbin/service apache2 * -> für alle weiteren Parameter
/usr/sbin/service apache2 reload -> genau nur hierfür

Der Aufruf in FHEM muss dann genau dem Schema entsprechen:

"sudo /usr/sbin/service apache2 reload"

Elektrodrachen und so

Fertige IoT Module mit dem ESP Modul gibt es mittlerweile Einige. Von SonOff eine ganze Palette, dazu gibt es auch schon Anleitungen im FHEM Wiki.
Eine Alternative mit nicht so breiter Palette liefert Electrodragon. Ich habe mir zwei Module (SPDT und VDC Version ist die Bezeichnung von Electrodragon) von denen bestellt und möchte die Einbindung in FHEM hier kurz vorstellen.
All diesen Modulen gemeinsam ist, dass sie quasi ohne Lötarbeit für FHEM einsatzbereit gemacht werden können, der Interface Stecker zur Programmierung ist schon vorhanden. Die Module enthalten den ESP 12E Baustein mit 4 MB Flash.
Im Gegensatz zu SonOff liefert Electrodragon keine fertige Software und keine App mit. Diese Module sind für den "normalen Anwender" also nicht brauchbar.

Achtung: 

1. Niemals die Module programmieren oder im offenen Zustand betreiben wenn sie mit dem Stromnetz verbunden sind!
2. Die Stromversorgung während der Programmierung erfolgt besser durch eine separate 5 V oder 3,3 Volt Spannungsquelle. Sonst ist der Erfolg beim Flashen nicht gewährleistet. Beim Betrieb mit 3,3 Volt funktionieren die Relais nicht sauber! 
3. Es sind keine Güte- und Prüfsiegel vorhanden! 

Electrodragon liefert derzeit 3 fertige Relais Module, zwei mit SPST Relais (einfacher Schließer) und eines mit SPDT Relais (Umschalter). Leider ist die Beschreibung im Shop relativ dürftig, es sind aber die Schaltpläne verfügbar. Alle Module verfügen über einen bestückten 12 poligen Steckverbinder zum Anschluss der Programmierumgebung und eventuell weitere Komponenten. Sie verfügen weiterhin um einen vorbereiteten Lötanschluss für einen DHT22. Das SPST Modul mit Niederspannungsversorgung hat zusätzlich einen vorbereiteten Lötanschluss für D0-D3 VCC GND.

Verwendungsmöglichkeiten aus meiner Sicht

SPDT Variante

Separates Netzteil zur Speisung 65-250 Volt AC, der Speiseeingang ist nicht mit den Relaiskontakten verbunden! Die Umschaltkontakte der beiden Relais sind separat herausgeführt. Die Kontakte sind damit potentialfrei.

SPST Variante mit Stromversorgung 85-250 Volt AC

Die Schließerkontakte der beiden Relais sind einseitig bereits mit der Speisespannung verbunden. Dieses Modul ist zum Einsatz von Schaltaufgaben mit minimalem Verkabelungsaufwand im Haushalt gedacht. Die Netzspannung kann auf zwei Verbraucher geschaltet werden, sowohl Versorgung als auch Verbraucher haben separate zweipolige Klemmen.

SPST Variante (VDC Version) mit Niederspannung Gleichstromversorgung 5-24 Volt DC

Im Auslieferungszustand sind die Schließerkontakte der beiden Relais einseitig bereits mit der Speisespannung verbunden. Der Pluspol der Speisespannung kann auf zwei Verbraucher geschaltet werden. 

Das Board bietet aber die Möglichkeit den Pluspol der Speisespannung und Schaltspannung zu trennen. Außerdem bietet es die Möglichkeit das Modul separat mit 5 Volt zu versorgen. Dabei ist die Schaltspannung der beiden Relais wählbar (AC oder DC). 

Die Eingangsspannung kann auf zwei Verbraucher geschaltet werden, sowohl Versorgung als auch Verbraucher haben separate zweipolige Klemmen. Man hat damit auch ein Modul mit Niederspannungsversorgung und zwei potentialfreien Schließerkontakten. 

Die Konfiguration der einzelnen Varianten erfolgt mit Jumpern bzw. Lötbrücken.

Praktisches Einsatzbeispiel

Mein Freund Steffen hat mit einem SPST Modul einen Zwischenstecker realisiert. Für kleines Geld gibt es z.B. bei conrad ein universelles Gehäuse (TRU COMPONENTS TC-SG 1022 SW203) und einen Dichtring (TRU COMPONENTS TC-SG 1015 SW203).

Programmierung

Electrodragon hat eine Art Demo Software vorinstalliert, mit der man einen MQTT Server anbinden kann. Ich will das Modul mit ESPEasy flashen und an FHEM anbinden.

Notwendige Hardware: 

Eine serielle Schnittstelle mit 3,3 Volt Logikpegel! (z.B. FTDI USB Adapter)

Eine 5 Volt oder 3,3 Volt Stromversorgung die etwa 300 mA liefern kann. 

Achtung!

Der typische FTDI Adapter kann nur 50 mA liefern und eignet sich nicht zur Stromversorgung! 

Man könnte das Modul über den 5 Volt Anschluss direkt vom USB versorgen, allerdings hat mein FTDI Adapter dafür kein Pin. Mit dem CP2102 Adapter geht das.

Ich verwende ein Breadboard, eine 5 / 3,3 Volt Stromversorgung fürs Breadboard und einen USB/seriell Adapter (mit CP2102 oder FTDI Chip aber unbedingt (3,3 Volt !) sowie ein paar Steckbrücken.

• Spannungsversorgung aus!
• Alle Masseanschlüsse werden verbunden, Spannungsanschlüsse am USB/Seriell Wandler werden nicht mit der separaten Versorgung verbunden
• Stromversorgung an das Modul, Aufpassen! Entweder -> 5 V an 5 V ODER 3,3, V an 3,3 V
• RX von der seriellen Schnittstelle an TX vom Modul
• TX  von der seriellen Schnittstelle an RX vom Modul
• USB Stecker an USB seriell Adapter
• Spannungsversorgung ein.

Wird die allgemeine Spannungsversorgung mit verbundenem TX RX aber spannungslosem USB/seriell Wandler hergestellt, kann es sein, dass der ESP nicht richtig startet oder sogar "Factory Reset" durchführt.

Zum flashen muss beim Einschalten der Spannungsversorgung, der BTN2 (BTN) Knopf gedrückt  werden. Als Quittung leuchtet die Status LED dauerhaft. Die Bezeichnung der Knöpfe im Plan und Aufdruck ist nicht ganz konsistent.
Man muss beim Aufbau dafür sorgen, dass man leicht mit einer Hand die Stromversorgung stecken kann (Breadboard und Steckbrücke).
Im Detail ist der Flashvorgang hier beschrieben 

Auf dem SPST/VDC Board ist der zweite Knopf (RST) wirklich der Reset Knopf.
Auf dem SPST (Netzteilversion) /SPDT Board ist der zweite Knopf (BTN1) mit GPIO-02 verbunden. Hier muss der Reset also durch kurze Spannungsunterbrechung erfolgen.

Die Einbindung in FHEM zeige ich in diesem Artikel

Einbindung von ESPEasy Schaltern in FHEM

Die aktuellen Informationen findet man in der Doku  und im Forum.
Hier habe ich schon mal die Einbindung beschrieben.
ESPEasy kennt kein Relais Gerät als Output. Es kennt nur einen Switch Input. Ein GPIO Pin wird in dem Moment, wo man einen logischen Zustand setzt, einfach auf Ausgang gesetzt. Beispiel
in der ESPEasy Weboberfläche gpio,12,1
in FHEM set <ESPEasy Device Name> gpio 12 on
Genau genommen bräuchte man in ESPEasy für FHEM nichts definieren, allerdings würde das ESPEasy Modul dann auch kein Gerät erzeugen. Da man von seinem Schalter ja auch Lebenszeichen erhalten will, konfigurieren wir die Übertragung der Feldstärke (rssi) und als Status Rückmeldung einen Switch Input. Der eigentliche Schaltvorgang wird über eine eventMap erzeugt.
Durch die Wahl des Namen auf den Deviceseiten erzeugt man in FHEM ein oder mehrere Geräte. Der Name muss also nicht Unikat sein und soll es für diesen Fall auch nicht! Bei gleichen Namen erzeugt FHEM einfach ein weiteres Reading. Der Name im Feld Value bestimmt den Namen des Reading.

ESPEasy konfigurieren

Nach der WLAN Konfiguration mit dem Smartphone (mit ESP_0 verbinden) kommt man mit http://newdevice auf die Weboberfläche. Ich habe diesmal mit der Version 2.0.0 dev10 gearbeitet.
Die einzelnen Konfigurationsschritte (Seiten) immer mit Submit abschicken und das Häkchen bei Enabled nicht vergessen!

Config
Den Namen setzen: EDSPST1
Der neue Name ist im Browser sofort sichtbar, wirkt als Hostname aber erst nach dem nächsten Neustart.

Controllers
Hier ist ein Wert per default vorkonfiguriert, den ändern wir mit Edit.
Hinweis: Das Feld für Controller User und Password wird nur ausgefüllt wenn in FHEM bei der espBridge das Attribute authentication auf 1 gesetzt ist und die Werte für user und pass übergeben wurden!

Hardware
Keine Änderung.

Devices
Hier konfiguriert man zunächst zwei Geräte für die Relais, welche mit GPIO-12 und GPIO-13 verdrahtet sind.

Zusätzlich konfiguriert man noch den RSSI Wert, damit hat man eine Information über den WiFi Empfang des Moduls und dieser Wert sorgt für permanente Status Updates. Dieses Gerät erzeugt man zweimal, nur der Name wird unterschiedlich SW1 bzw. SW2.

Zum Schluss sieht die Konfiguration so aus

Pro vergebenen Device Namen (Name Spalte) wird von der espBridge ein Gerät erzeugt. Der Value Name (Value Spalte) erzeugt je ein Reading.
In FHEM sind durch diese Konfiguration zwei Geräte mit je zwei Readings entstanden.

FHEM konfigurieren

Durch die Übertragung der rssi Werte hat die espBridge in FHEM zwei Geräte erzeugt mit dem Namen ESPEasy_EDSPST1_SW1 und ESPEasy_EDSPST1_SW2. Diese muss man jetzt noch so konfigurieren, das die Schalter auch bedient werden können. Das wichtigste ist eine eventMap:

attr ESPEasy_EDSPST1_SW1 eventMap /gpio 12 on:on/gpio 12 off:off/
attr ESPEasy_EDSPST1_SW2 eventMap /gpio 13 on:on/gpio 13 off:off/

Damit entstehen on und off Kommandos für den set Befehl und für webCmd. Jetzt kann man die Schaltfunktion prüfen.

Damit der Status richtig angezeigt wird, braucht man noch ein angepasstes stateFormat

attr ESPEasy_EDSPST1_SW1 stateFormat {ReadingsVal($name,"presence","") eq "absent" ? "absent" : ReadingsVal($name,"Switch","")}

Das sieht jetzt schon mal gut aus, ist aber noch nicht perfekt.

Nur mal zur Vollständigkeit die bis hierher komplette Definition, also das automatisch Erzeugte und Ergänzungen/Änderungen:

defmod ESPEasy_ED230V_SW1 ESPEasy 192.168.178.107 80 espBridge ED230V_SW1
attr ESPEasy_ED230V_SW1 IODev espBridge
attr ESPEasy_ED230V_SW1 Interval 300
attr ESPEasy_ED230V_SW1 eventMap /gpio 12 on:on/gpio 12 off:off/
attr ESPEasy_ED230V_SW1 group ESPEasy Device
attr ESPEasy_ED230V_SW1 presenceCheck 1
attr ESPEasy_ED230V_SW1 readingSwitchText 1
attr ESPEasy_ED230V_SW1 room ESPEasy
attr ESPEasy_ED230V_SW1 setState 3
attr ESPEasy_ED230V_SW1 stateFormat {ReadingsVal($name,"presence","") eq "absent" ? "absent" : ReadingsVal($name,"Switch","")}

Mit attr <> setState 0 kann man die interne Erzeugung des state Readings ausschalten. Nun kann man mit verschiedenen Methoden z.B. einem userReadings sein eigenes state erzeugen.
state {ReadingsVal($name,"Switch","") }

Noch die Idee aus dem Forum für on-for-timer muss ich noch probieren

attr <deinEsp> eventMap /longpulse 5 on:on-for-timer/longpulse 5 off:off-for-timer/gpio 5 on:on/gpio 12 off:off/status gpio 15:check/

Hier wird noch gearbeitet ...

csrf Token und FHEM

Wenn ich es richtig verstanden habe, gibt es eine Bedrohung wenn man im Browser mehrere Seiten offen hat und eine davon ist "böse". Diese Seite könnte die aktive Anmeldung an einem anderen Webserver ausnutzen und diesen angreifen. Heise hat das hier ganz gut beschrieben.

In FHEM wurde Anfang des Jahres mit der Version 5.8 der csrfToken als eine Abwehr Maßnahme scharf geschaltet. Was leider dazu führt, dass man nicht mehr mit einem einfachen http Link auf das FHEMWEB zugreifen kann.
Was bisher einfach so ging:

curl http://localhost:8083/fhem?cmd=set%20Office%20on

muss jetzt um den Token ergänzt werden. Man beachte auch: die URL muss dafür in Anführungszeichen stehen!

curl "http://localhost:8083/fhem?cmd=set%20Office%20on&fwcsrf="

Mit dem Einzeiler

curl -s -D - 'http://localhost:8083/fhem?XHR=1' | awk '/X-FHEM-csrfToken/{print $2}'

kann man den aktuellle csrfToken aus dem Header extrahieren und muss ihn nur noch an den Aufruf anhängen. Das Ganze mit einmaliger Angabe des Hostnamen(IP) und dem FHEM Befehl mit normalen Leerzeichen, sieht so aus:

h='host:Port'; c='FHEM Befehl'; curl --data "fwcsrf=$(curl -s -D - http://$h/fhem?XHR=1 | awk '/X-FHEM-csrfToken/{print $2}')" http://$h/fhem?cmd=$(echo $c|sed 's/ /%20/g')

Da bei Headerfeldern immer ein cr+lf angehängt wird (danke für den Hinweis unten im Kommentar), kann man den ermittelten Token nicht so wie hier kurz gezeigt direkt anhängen.  Diese Zeile

curl "http://localhost:8083/fhem?cmd=set%20Office%20on&XHR=1&fwcsrf="`curl -s -D - 'http://localhost:8083/fhem?XHR=1' | awk '/X-FHEM-csrfToken/{print $2}'`

oder auch diese Schreibweise:

curl "http://localhost:8083/fhem?cmd=set%20Office%20on&XHR=1&fwcsrf="$(curl -s -D - 'http://localhost:8083/fhem?XHR=1' | awk '/X-FHEM-csrfToken/{print $2}')

führt zu dem Fehler: curl: (3) Illegal characters found in URL

So wird cr+lf verhindert ( Diskussion im Forum ):

curl "http://fhem.example.org:8083/fhem?cmd=set%20Office%20on&XHR=1&fwcsrf="`curl -s -D - 'http://fhem.example.org:8083/fhem?XHR=1' | awk '/X-FHEM-csrfToken/{print $2}' | tr -d "\r\n"`

Mir persönlich gefällt die Variante mit -d (--data) besser.

Der csrfToken wird bei einem Neustart von FHEM neu generiert. Bis dahin bleibt er gültig. Hat man mehrere Anweisungen in Folge, genügt es den Token einmal auszulesen und zu speichern. Hier zwei Varianten.
Bash Script:

token=$(curl -s -D - 'http://<host>:8083/fhem?XHR=1' | awk '/X-FHEM-csrfToken/{print $2}')
curl --data "fwcsrf=$token" http://<host>:8083/fhem?cmd=set%20Aktor1%20off

Powershell:

# Wenn man mehr aus dem Request herausziehen will, erstmal in ein Objekt
# UseBasicParsing verhindert die Verwendung des IE und dessen Securityabfragen
$wp=Invoke-WebRequest -UseBasicParsing -Uri "http://<host>:8083/fhem?XHR=1"
$token = $wp.Headers["X-FHEM-csrfToken"]
# Alternativ nur der Token
$token = Invoke-WebRequest -UseBasicParsing -Uri "http://<host>:8083/fhem?XHR=1" | %{$_.Headers["X-FHEM-csrfToken"]}
$URL="http://<host>:8083/fhem?cmd=set%20Aktor1%20on&fwcsrf=$token"
Invoke-WebRequest -UseBasicParsing -Uri $URL | out-null

Um den Zugriff im internen Netzwerk zu vereinfachen, kann man auch ein separates "API Web" ohne Token einrichten:

define WEBapi FHEMWEB <Port> global
attr WEBapi csrfToken none
attr WEBapi allowFrom 192.168.x.x|127.0.0.1

Im Attribute allowfrom wird wird mit einem regEx der IP Adressbereich angegeben. Einzelne Adressen kann man einfach mit | (oder) trennen, Bereiche werden etwas aufwendiger.
Ich würde es aber lesbar und übersichtlich halten, eine Hand voll Adressen geht einfach so:
192.168.178.(1|20|203|124)
Wichtig: Dieses Web für den Zugriff von Maschinen einzurichten, an denen man vom Browser aus arbeitet ist am Thema vorbei!

FHEM - die Kommandozeile wird groß

Entwicklungen laufen ja manchmal unbemerkt an einem vorbei. Die Entwickler haben sich was gutes überlegt reden aber meist wenig darüber.
Seit einiger Zeit gibt es unter jeder definierten "Entität" den Punkt Raw definition

Wenn man da drauf klickt öffnet sich ein Fenster mit der Definition und allen zu Attributen und Status Informationen. Man kann die kopieren und an andere Stelle weiterverwenden Sehr einfach und praktisch.
Man kann aber auch einfach etwas verändern, oder auch alles rauslöschen und etwas völlig neues hineinschreiben/kopieren. In dem Moment wo man dies tut, erscheint unten ein neuer Button:

Execute commands. Das kann man wörtlich nehmen, es passiert in diesem Moment nichts unmittelbar in dieser Definition wo man steht, sondern die Zeilen werden geprüft und in FHEM übernommen! Man braucht also kein Telnet Fenster mehr um ganze Code Blöcke zu übernehmen, man muss dazu auch nicht die fhem.cfg direkt editieren (gar nicht zu empfehlen). Im Wiki ist die Sache näher beschrieben. Der kleine Codeblock zum ausprobieren erzeugt einen neuen Menüeintrag im FHEM Web

um schnell auf einen Eingabe Dummy zu springen.

define Import dummy
attr Import group Entwicklung
attr Import room Entwicklung
attr WEB menuEntries CodeImport,/fhem?detail=Import#

Diese Ergänzung wandert direkt in meine Standard Installation.

EasyBox zerflashed - und nun?

Ich wollte schon immer mal OpenWrt auf einen alten Router flashen. Um zu sehen wie OpenWrt so geht ...
Man kann ja die alten Dinger durchaus einfach noch zum AccessPoint umkonfigurieren. Sie liegen eh in der Kiste und bevor man was neues kauft!?
Ok, die kleinen Repeater verbrauchen nur um die 2 Watt, so eine EasyBox verbraucht ca. 7 Watt. Die Wirtschaftlichkeit schwindet also innerhalb von 2 Jahren.
Die Anleitungen zum EasyBox 803A flashen sind schon etwas alt, nicht mehr ganz aktuell und die Quellen zu manchen Dateien ziemlich versteckt. Aber nicht nur das, ich habe auch erstmal nicht richtig kapiert was zu tun ist. Ein falscher Befehl und Box bootet nicht mehr, deswegen ein kurzes HowTo mit dem was ich getan habe.
Aktuell Juni 2018: Es gibt eine neues OpenWrt Seite und einen überarbeiteten Artikel, der ist wesentlich besser lesbar als der Alte und ich hoffe die Links sind aktuell.

Ein Remote Taster in FHEM mit Rückmeldung

HowTo

Einfacher Taster

Zielstellung

Ein Dummy mit klickbarem Symbol für die Weboberfläche als "Taster" für verschiedenen Aktionen.

Als erste Komponente stattet man einen dummy mit dem Attribute devStateIcon aus:

define testdummy dummy
attr testdummy devStateIcon _start:on:stop _stop:off:start
attr testdummy event-on-change-reading state
set testdummy _stop

Als Zweites braucht man ein notify welches nur auf die Events start und stop vom testdummy reagiert:

define nty_test notify testdummy:(start|stop) set $NAME _$EVENT

Diese Konstruktion wirkt wie ein toggle Schalter, das Symbol beim dummy ist klickbar und bei jedem Klick schaltet es sichtbar on und off.

Die Rückmeldung des Schalters ist damit vorhanden nur er tut nicht wirklich etwas. Zur Demonstration lassen wir "noch etwas tun":

defmod nty_test notify testdummy:(start|stop) sleep 2;;set $NAME _$EVENT

Jetzt erfolgt die Reaktion auf den Klick mit kurzer Pause, stattdessen kann man natürlich auch etwas sinnvolles tun.

Remote Taster mit Rückmeldung

Zielstellung

Ein "Taster" in der Weboberfläche, der auf einem Remote System z.B. einen Dienst startet oder beendet. Mein Taster soll erst reagieren, wenn der Befehl vom Remote System ausgeführt wurde.

Die System sind mit ssh "gekoppelt", wie das geht steht in meinem vorherigen Beitrag.

Achtung! Seit  März 2017 funktioniert die hier beschriebene Steuerung von FHEM über die Webschnittstelle nicht mehr so einfach. Bitte meinen Beitrag im März beachten.

Demo Script

Auf dem Remote System wird ein Script im Home Verzeichnis des verwendeten Remote Benutzers erzeugt/abgelegt und mit chmod +x test.sh ausführbar gemacht:

#!/bin/sh
# Parameter Übergabe
host=$1
name=$2
event=$3
# Kontrollausgabe zum Test aktivieren
# echo $host $name $event
# Zur Demo ein Sleep
sleep 3
# Abfrage und Verzweigung
case "$event" in
    start)
 # hier kann etwas spezifisches bei Start passieren
    ;;

    stop)
 # hier kann etwas spezifisches bei Stop passieren
    ;;
    *)
       exit 1
    ;;

esac
# Web Kommando an FHEM absetzen
h=$host':8083'; c='set '$name' '$status; curl --data "fwcsrf=$(curl -s -D - http://$h/fhem?XHR=1 | awk '/X-FHEM-csrfToken/{print $2}')" http://$h/fhem?cmd=$(echo $c|sed 's/ /%20/g')

exit 0

Zum Test kann man dieses Script mit ./test.sh <FHEM hostname> testdummy start aufrufen. Dabei muss sich der Status unseres Dummy ändern.

Funktioniert dieser Test, wird das notify geändert, die hostnamen müssen angepasst werden:

defmod nty_test notify testdummy:(start|stop) "ssh pi@<remote hostname> ./test.sh <FHEM hostname>  $NAME $EVENT"

An der Reaktion des Dummy hat sich nicht viel geändert, da ich im Script sleep 3 gesetzt habe dauert es jetzt 1 Sekunde länger. Dafür passiert aber etwas auf einem anderen System!

Praktische Verwendung

Das Demo Script kann so als Grundgerüst verwendet werden. Im einfachsten Fall fügt man an den entsprechende Stellen einfach nur Befehle ein. Komplizierter wird es, wenn man z.B. vor Rückkehr (absetzen des Befehls an FHEM) wirklich überprüfen will/muss ob die gewünschet Aktion auch gelaufen ist.
Das notify kann für mehrere dummy verwendet werden.

Dienst steuern

Um einen Dienst zu starten und zu stoppen muss das Script und der dummy etwas angepasst werden. Zum Testen habe ich meinen Dienst aus diesem Beitrag genommen. Der Name muss entsprechend angepasst werden. Man könnte den Dienstnamen auch im notify übergeben.
Der Steuerbefehl (event) wird nochmal überprüft und übergeben. Nach kurzer Wartezeit wird der Status abgefragt und dieser direkt an FHEM übergeben. Der Status ist also direkt im dummy sichtbar

#!/bin/sh
# Parameter Übergabe
host=$1
name=$2
event=$3
service=<Dienst Name>
# Abfrage und Verzweigung
case "$event" in
    start|stop)
   # Sicherstellen das nur zulässige Events verwendet werden
   sudo systemctl $event $service 
   sleep 2
          status=$(systemctl is-active $service)
   # Web Kommando an FHEM absetzen (neu mit csrfToken)
   h=$host':8083'; c='set '$name' '$status; curl --data "fwcsrf=$(curl -s -D - http://$h/fhem?XHR=1 | awk '/X-FHEM-csrfToken/{print $2}')" http://$h/fhem?cmd=$(echo $c|sed 's/ /%20/g')

    ;;

    *)
      exit 1
    ;;

esac

exit 0

Wenn der Dienst läuft wird er als active erkannt, wenn er gestoppt ist liefert er unknown zurück. Das Mapping des devStateIcon wird einfach angepasst.

attr testdummy devStateIcon active:on:stop unknown:off:start