MSwitch: Unterschied zwischen den Versionen

Aus FHEMWiki
K (Aktuelle Modulversion 4.1)
 
(134 dazwischenliegende Versionen von 5 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:


[[MSwitch]] ist ein Hilfsmodul, welches das Event- und/oder zeitgesteuerte Schalten von mehreren Devices oder das Ausführen von benutzerdefinierten Befehlssequenzen erlaubt.
{{Hinweis|Das Modul wurde vom Modulautor aus dem FHEM-SVN entfernt. Download des Moduls unter https://github.com/Byte009/Fhem-MSwitch. Support erfolgt laut github-Seite derzeit über Whatsapp.}}


Die Stärke bzw. das Unterscheidungsmerkmal dieses Moduls liegt in der Konfigurierbarkeit über ein Webinterface. Diese Konfiguration kann jederzeit geändert oder erweitert werden.  
Achtung: Das Wiki entspricht nicht mehr der aktuellen Modulversion ( V4.1 )


Byte09: ''Die Grundidee zu MSwitch kam mir, weil ich bei der Arbeit mit FHEM für meinen Geschmack zu viele Module für die verschiedenen Aufgaben brauchte - zu allem Überfluss alle mit unterschiedlicher Syntax. Zwar ist DOIF hiervon ausgenommen (da hiermit wohl auch fast jede Aufgabe lösbar ist), aber ich konnte mich leider nicht daran gewöhnen und somit wurde jedes DOIF für mich zu einem echten Projekt. Was ich wollte war ein Modul, mit dem ich alles erledigen kann. Daher entschloss ich mich schon nach fast einem knappen Jahr FHEM-Nutzung mein eigenes Modul zu schreiben, welches diese Anforderung erfüllt. MSwitch beinhaltet die Funktionalität aller bisherigen Hilfsmodule wie z.B. Notify, Doif, Watchdog, Dummy,( ab Modulversion 2.2 auch Sequenz ) es lassen sich all deren Funktionen umsetzen.''
Hilfe zu allen Befehlen , Einstellungen etc. ist direkt über das Frontend eines MSwitch-Devices verfügbar.


''MSwitch wird permanent - vorrangig nach meinen Bedürfnissen - weiterentwickelt, gerne nehme ich aber auch Anregungen von anderen Nutzern auf.''
Eine Aktualisierung des Wikis erfolgt in den kommenden Tagen.
 
[[MSwitch]] ist ein Hilfsmodul, welches das Event- und/oder zeitgesteuerte Schalten von mehreren Devices oder das Ausführen von benutzerdefinierten Befehlssequenzen erlaubt. Hauptmerkmale sind die fast vollständige und die sehr umfangreiche Konfigurierbarkeit über das Webinterface.


{{Infobox Modul
{{Infobox Modul
|ModPurpose=MSwitch
|ModPurpose=MSwitch
|ModType=h
|ModType=x
|ModForumArea=Automatisierung
|ModForumArea=Automatisierung
|ModTechName=98_MSwitch.pm
|ModTechName=98_MSwitch.pm
|ModOwner=Byte09}}
|ModOwner=Byte09 (aus dem Forum abgemeldet)}}


== Grundsätzliche Überlegungen ==
{{Randnotiz | RNTyp=y | RNText=Byte09: ''Die Grundidee zu MSwitch kam mir, weil ich bei der Arbeit mit FHEM für meinen Geschmack zu viele Module für die verschiedenen Aufgaben brauchte - zu allem Überfluss alle mit unterschiedlicher Syntax. Zwar ist DOIF hiervon ausgenommen (da hiermit wohl auch fast jede Aufgabe lösbar ist), aber ich konnte mich leider nicht daran gewöhnen und somit wurde jedes DOIF für mich zu einem echten Projekt. Was ich wollte war ein Modul, mit dem ich alles erledigen kann. Daher entschloss ich mich schon nach fast einem knappen Jahr FHEM-Nutzung mein eigenes Modul zu schreiben, welches diese Anforderung erfüllt. MSwitch beinhaltet die Funktionalität aller bisherigen Hilfsmodule wie z.B. Notify, Doif, Watchdog, Dummy,( ab Modulversion 2.2 auch Sequenz ) es lassen sich all deren Funktionen umsetzen.''
Um das Modul zu nutzen, muss man zuerst folgende Fragen beantworten:


* Welches Gerät soll auslösen oder zu welcher Zeit soll eine Auslösung erfolgen
''MSwitch wird permanent - vorrangig nach meinen Bedürfnissen - weiterentwickelt, gerne nehme ich aber auch Anregungen von anderen Nutzern auf.''
: Dies ist der Trigger. Jedes Event aus dem Eventmonitor kann als Trigger dienen. Will man mehrere Geräte als gleichzeitige Auslöser betreiben, so muss das Device GLOBAL gewählt und die entsprechenden Geräte angegeben werden (dies erzeugt höhere Systemlast und ist nur im Expert-Modus verfügbar). Weiterhin kann auch zu fest definierten Zeiten, Zufallszeiten oder Intervallen, unabhängig von einem Trigger, geschaltet werden; auch eine Kombination beider Varianten ist möglich. Diese Einstellungen erfolgen im ersten Teil des Webinterfaces.


* Welche Bedingungen sollen bei Auslösung erfüllt sein?
[[Datei:1-2-3-4.png|rahmenlos]]
: Wenn diese Bedingungen erfüllt sind, werden Kommandos ausgelöst. Die Bedingungen werden im zweiten Teil des Webinterfaces eingegeben. Dabei unterscheidet das Modul zwischen zwei Kommandokanälen (cmd1 und cmd2) und den dazugehörigen Geräten.
}}


* Welche Kommandos sollen ausgelöst werden?
: Im dritten Teil des Webinterfaces werden dann die konkreten Kommandos eingegeben. Typischerweise wählt man dabei aus einer Liste der Kommandos aus, die die zugehörigen Geräte insgesamt aufweisen (also so, wie man auf den Geräteseiten selber Kommandos auswählt). Es gibt zudem ein so genanntes FreeCmd, das ein Geräteunabhängiges Kommando zulässt, beispielsweise reinen Perl-Code.


* Welche weiteren Bedingungen sollen noch gelten?
: Hier sind ereignisgesteuerte wie auch zeitgesteuerte Bedingungen möglich. Diese Bedingungen werden auch in dem dritten Teil des Webinterfaces eingetragen. So sind Verzögerungen und Wiederholungen und weitere Bedingungen möglich.


== Voraussetzungen, Installation und Grundbefehle ==
== Grundsätzliche Überlegungen ==
Das MSwitch-Modul ist ohne weitere Voraussetzungen nutzbar und wird derzeit in der Version 2.08 über FHEM Update verteilt.  
{{Randnotiz | RNTyp=y | RNText=Will man mehrere Geräte als gleichzeitige Auslöser betreiben, so muss das Device GLOBAL gewählt und die entsprechenden Geräte angegeben werden (dies erzeugt höhere Systemlast und ist nur im Expert-Modus verfügbar).}}


=== Definition und Einrichtung ===
1. Welches Gerät soll auslösen oder zu welcher Zeit soll eine Auslösung erfolgen?
Mit Hilfe von MSwitch kann man mehrere Devices gleichzeitig schalten. Diese Schaltungen befinden sich in zwei möglichen Zweigen bei MSwitch. Dabei unterscheidet man im Modul zwischen den beiden Kommandos cmd1 und cmd2. Die zu einem Kommando gehörenden Geräte werden wir auch Zweig nennen. Die einzelnen Devices jedes Zweiges können mit weiteren Schaltbedingungen versehen werden (zeit- oder ereignisgesteuert).  
[[Datei:MSwitch basic.svg|mini|240px|Stark vereinfachtes Struktogramm]]
Im Rahmen 1 des Webinterfaces lässt sich der Trigger (Auslöser) bzw. eine Zeitabhängigkeit konfigurieren:


Folgende Möglichkeiten zum definieren des MSwitch Devices stehen zur Verfügung:
** jedes Event aus dem Eventmonitor,
:<code>define <name> MSwitch</code>
** triggerunabhängige Zeiten,
Es wird ein leeres Device angelegt, das dann komplett über das Webinterface konfigurierbar ist.
** triggerunabhängige Zufallszeiten,
** triggerunabhängige Intervalle,
** Kombinationen aus Triggern und Zeiten.


Das define eines MSwitch Devices generiert lediglich eine 'leere Hülle'. Alle relevante Einstellungen werden in Readings und/oder Hashes gespeichert. Daher stehen relevanten Daten ''nicht'' in der fhem.cfg! Vielmehr finden sich diese Daten in der Datei fhem.save (die Speicherung erfolgt durch den Befehl Fhemsave).
2. Welche Bedingungen sollen bei Auslösung erfüllt sein?
: Ersten Rahmen: Wenn diese Bedingungen erfüllt sind, werden Kommandos ausgelöst. Die Bedingungen werden im zweiten Teil des Webinterfaces eingegeben. Dabei unterscheidet das Modul zwischen zwei Kommando-Kanälen (cmd1 und cmd2) und den dazugehörigen Geräten.


=== set-Befehle ===
3. Welche Kommandos sollen ausgelöst werden?
Es sind derzeit die folgenden set-Befehle implementiert.
: Im vierten Rahmen des Webinterfaces werden dann die konkreten Kommandos eingegeben. Man wählt dabei aus einer Liste wie auf der Geräteseite Kommandos aus. FreeCmd erlaubt geräteunabhängige Kommandos, beispielsweise reinen Perl-Code.


==== set active ====
4. Welche weiteren Bedingungen sollen noch gelten?
Setzt das Device in den Status 'active'.
: Zusätzlich pro Gerät eine oder mehrere Instanzen des vierten Rahmens:
** ereignisgesteuerte Bedingungen,
** zeitgesteuerte Bedingungen,
** Verzögerungen,
** Wiederholungen etc.


==== set inactive ====
==Definition und Einrichtung =={{Randnotiz | RNTyp=y | RNText=Alle relevante Einstellungen werden in Readings und/oder Hashes gespeichert. Daher stehen relevanten Daten ''nicht'' in der fhem.cfg! Vielmehr finden sich diese Daten in der Datei fhem.save. Die Speicherung erfolgt durch den Befehl Fhemsave.
Setzt das Device in den Status 'inactive', es werden keine Befehle mehr ausgeführt. Dieser Status entspricht dem Attribut 'disable', ist aber nicht mit dem roten Fragezeichen (fhem save) verbunden.
}}
 
Das MSwitch-Modul ist ohne weitere Voraussetzungen nutzbar und wird in der aktuellen Version über FHEM Update verteilt. MSwitch kann mehrere Devices gleichzeitig schalten. Diese Schaltungen befinden sich in den zwei möglichen Zweigen entsprechend der Kommandos cmd1 und cmd2. Die einzelnen Devices jedes Zweiges können mit weiteren Schaltbedingungen versehen werden (zeit- oder ereignisgesteuert). Das define eines MSwitch Devices generiert lediglich eine 'leere Hülle':
==== set on/off [<parameter>]====
:<code>define <name> MSwitch</code>
Setzt das Device in den Status 'on' oder 'off'. Alle Befehle der 'on/off-Zweige' werden ausgeführt.
Es wird ein leeres Device angelegt, das dann komplett über das Webinterface konfigurierbar ist.
Optional kann den Befehlen 'on' und 'off' ein weiterer Parameter mit übergeben werden. Dieser wird im Reading 'Parameter' hinterlegt und es kann sofort in 'Freecmds' oder 'Conditions' darauf zugegriffen werden.
 
==== set reload_timer ====
Alle gesetzten Timer werden gelöscht und neu berechnet.
 
==== set change_renamed <oldname> <newname> ====
Sollten sich Devicenammen im ausführenden Teil geändert habe (affected Devices, Conditions, etc.) so kann das MSwitch mit diesem Befehl angepasst werden , ohne alle Einstellungen neu einstellen zu müssen.
 
==== set exec_cmd1 / set exec_cmd1 ID [<ID>] ====
Bewirkt das sofortige Ausführen des entsprechenden Befehlszweiges. Bei Angabe einer ID werden nur die Befehle mit der entsprechenden ID ausgeführt.
 
==== set MSwitch_backup ====
Erstellt eine Backup-Datei aller MSwitch Devices unter ./fhem/MSwitch_backup.cfg.
 
Daten dieser Datei können im Bedarfsfall für einzelne oder gleichzeitig alle MSwitch Devices wieder zurückgespielt (hergestellt) werden.
 
==== set del_delays ====
Löscht alle anstehenden, verzögerten Befehle (delays).
 
==== set reset_cmd_count:1,2 ====
Löscht das entsprechende EVT_CMD_COUNT - Reading (entspricht Rückstellung auf '0').
 
==== set fakeevent [<device>]:<reading>:<arg> ====
Beispiel: <device> fakeevent state:on<br>
 
Ob der Name (<device>) angegeben werden muss, oder nicht, ist abhängig davon, ob auf ein einzelnes Device, oder GLOBAL getriggert wird. Bei GLOBALEN Triggern muss das Device mit angegeben werden, Wird auf ein Device getriggert, so wird das Device automatisch gesetzt.
 
Mit diesem Befehl kann das MSwitch Device neu getriggert werden, indem hier ein Event 'gefaked' wird. Das MSwitch Device reagiert dann so, als wäre dieses Event vom getriggerten Gerät generiert worden.
 
Dieses kann nötig sein, um z.B. einen Watchdog zu realisieren, in dem es nötig ist, dass sich das MSwitch Device mit einem bestimmten Event selber neu triggert - ggf. mit einem entsprechenden Delay (affected Device muss dafür u.A. des MSwitch Device selber sein).
 
Es wird hierbei KEIN echtes Event generiert welches das System beeinflusst, sondern ausschließlich ein MSwitch-Interner Befehl umgesetzt!
 
Bei dem Einsatz dieser Möglichkeit sollte das Attribut 'MSwitch_Safemode' UNBEDINGT aktiviert sein, da 'Experimente' hier schnell in einer Endlosschleife enden können, die nur durch ein Reboot unterbrochen werden kann.
 
Ggf. werde ich hier sogar eine entsprechende Änderung vornehmen, dass dieser Befehl nur zur Verfügung steht, wenn Safemode aktiviert ist.
 
=== get-Befehle ===
==== get show_timer [<show><delete>] ====
;Show
:Zeigt alle anstehenden (gesetzten) Timer des Devices, die aus zeitabhängigen oder verzögerten Schaltbefehlen resultieren.
;Delete
:Löscht alle anstehenden (gesetzten) Timer des Devices, die aus zeitabhängigen oder verzögerten Schaltbefehlen resultieren. Schaltbefehle basierend auf rein zeitabhängigen Angaben werden neu berechnet und gesetzt.
 
==== get restore_MSwitch_data [<this_device><all_devices>] ====
;this_device
:Stellt die Daten des Devices aus der Backupdatei wieder her, sofern diese in der Backupdatei gefunden werden (gesucht wird hier nach dem Namen des Devices).
;all_devices
:Stellt die Daten aller MSwitch Devices wieder her, sofern diese in der Backupdatei vorhanden sind. Diese Aktion kann einige Zeit in Anspruch nehmen und wird daher im Hintergrund (nonblocking) ausgeführt. Nach Beendigung erfolgt eine Benachrichtigung.
 
Die Devices sind nach einem Restore funktionsfähig. Empfohlen wird ein Neustart von FHEM.
 
==== get_config ====
Zeigt die Konfigurationsdatei des MSwitchdevices an; diese kann in dem Fenster editiert werden. Das sollte nur von erfahrenen Usern getan werden! Im Normalfall sollte das Device nur über die Weboberfläche konfiguriert werden und eine falsche Konfiguration kann hier zu einem FHEM Absturz führen.
 
==== get_support_info ====
Öffnet ein Fenster mit einer formatierten Ansicht aller Einstellungen des Devices. Bei Supportanfragen sollte dieses immer mit geposted werden.
 
==== get_MSwitch_preconf ====
Lädt vorkonfigurierte MSwitch-Devices. Diese Option ist nur dann vorhanden , wenn das Aktualisieren dieser vorkonfigurierten Devices im FHEM Update aktiviert ist.
 
diese kann durch einmaliges Update erfolgen mit:
:<code>update all https://raw.githubusercontent.com/Byte009/MSwitch_Addons/master/controls_mswitchaddons.txt</code>


== Webinterface ==
== Webinterface ==
MSwitch wird im Wesentlichen über das Webinterface eingerichtet. Wählt man das folgende Attribut
MSwitch wird über das Webinterface eingerichtet. Es besteht aus vier Teilen. Änderungen in einem Abschnitt müssen auch dort gespeichert werden, bevor ein weiterer Teil bearbeitet wird, sonst gehen Änderungen verloren.{{Randnotiz | RNTyp=y | RNText=<code>attr <name> MSwitch_Help 1</code> führt dazu, dass im Modul selber eine sehr umfangreiche kontextsensitive Hilfe in Form von Fragezeichensymbolen angezeigt wird.}}
:<code>attr <name> MSwitch_Help 1</code>
so wird im Modul selber eine sehr umfangreiche Hilfe angezeigt. Über das gesamte Webinterface hinweg erscheinen kleine Fragezeichen, die man anklicken kann und die beschreiben, was in dem jeweiligen Textfeld sinnvollerweise einzugeben ist bzw. was das Modul an dieser Stelle erwartet.


Das Webinterface besteht aus vier Teilen. Änderungen in jedem Abschnitt müssen in dem jeweiligen Teil bestätigt werden und auch nur diese werden gespeichert. Bevor ein weiterer Teil bearbeitet wird, sollten Änderungen gespeichert werden, sie gehen sonst verloren.
[[Datei:1-2-3-4.png|rahmenlos|Webinterface]]
 
=== Rahmen 1: Trigger Device und Trigger Time ===
=== Trigger device/time ===
==== Trigger Device ====
==== Trigger Device ====
In diesem Feld wird das Device ausgewählt, dessen Events eine Aktion auslösen sollen. Dazu werden alle verfügbaren Devices in einem Dropdownfeld angeboten.
{{Randnotiz | RNTyp=y | RNText=Wenn das Attribut 'MSwitch_Expert' gesetzt ist kann man 'GLOBAL' auswählen. Dann werden '''alle''' von FHEM generierten Events durch das MSwitch Device weiterverarbeitet, eine weitere Begrenzung kann (und sollte) dann in einem folgenden Eingabefeld erfolgen, um die Systemlast zu reduzieren.
 
Zusätzlich gibt es eine Auswahl 'GLOBAL', wenn das Attribut 'MSwitch_Expert' gesetzt ist. Bei Auswahl dieser Option werden '''alle''' von FHEM generierten Events durch das MSwitch Device weiterverarbeitet, eine weitere Begrenzung der aktivierenden Events kann (und sollte) dann in einem folgenden Eingabefeld erfolgen, um die Systemlast zu reduzieren.
 
==== Trigger Device Global Whitelist ====
==== Trigger Device Global Whitelist ====
Dieses Feld ist nur verfügbar, wenn als Trigger 'GLOBAL' gewählt wurde.
Damit kann die Liste eingehender Events weiter eingeschränkt werden. Sobald mindestens ein Eintrag vorhanden sind, werden nur noch Events der hier benannten Devices verarbeitet. Zulässig ind Devicenamen und DeviceTypen (z.B. TYPE=FS20). Mehrere Angaben sind durch Komma zu trennen.


Hier kann die Liste eingehender Events weiter eingeschränkt werden. Es handelt sich um eine Whitelist, d.h., wenn es keine Einträge gibt, werden Events aller Devices verarbeitet. Sobald ein oder mehrere Einträge gemacht werden, werden nur noch Events der hier benannten Devices verarbeitet. Als Angabe können hier Devices benannt werden oder ganze DeviceTypen (z.B. TYPE=FS20). Mehrere Angaben sind durch Komma zu trennen.
Im unten gezeigten Beispiel wurde GLOBAL gewählt, weil nicht ein einzelnes Device, sondern eine Kombination aus zwei Geräten auslösen soll. Es werden alle Ereignisse betrachtet, wobei die Whitelist dann auf die Devices Schlafzimmer (ein Temperaturmessgerät) und Schlafzimmerfenster (ein [[HM-Sec-SCo Tür-Fensterkontakt, optisch|optischer Kontakt]]) einschränkt.}}In diesem Feld wird das Device per Dropdownfeld gewählt, dessen Events eine Aktion auslösen sollen.


[[Datei:MSwitchWebinterface1.png|400px|thumb|right|Webinterface, oben]]
[[Datei:MSwitchWebinterface1.png|400px|thumb|right|Webinterface, oben]]
Im gezeigten Beispiel wurde GLOBAL gewählt, weil nicht ein einzelnes Device, sondern eine Kombination aus zwei Geräten auslösen soll. Es werden also alle Ereignisse betrachtet, wobei die Whitelist dann auf die Devices Schlafzimmer (ein Temperaturmessgerät) und Schlafzimmerfenster (ein [[HM-Sec-SCo Tür-Fensterkontakt, optisch|optischer Kontakt]]) einschränkt.


==== Trigger time ====  
==== Trigger Time ====  
Es besteht die Möglichkeit, das Modul (neben den Events) zu festen Zeiten auszulösen. Dann wären in die leer stehenden Zeilen bei "at" entsprechende Termine einzutragen. Zeitangaben erfolgen durch [STUNDEN:MINUTEN|TAGE], wobei die Tage von 1-7 gezählt werden (1 steht für Montag, 7 für Sonntag usw.).  
Trigger time bietet die Möglichkeit einer zeitabhängigen Steuerung. Dazu wird in die "at"-Zeile ein Termin in der Form [STUNDEN:MINUTEN|TAGE] eingetragen. Die Tage werden ab Montag von 1-7 gezählt. Mehrere Zeitvorgaben können direkt hintereinander geschrieben werden. Beispiele:
Mehrere Zeitvorgaben können direkt aneinandergereiht werden.
* <code>[17:00|1][18:30|23]</code> löst montags um 17 Uhr und dienstags sowie mittwochs um 18:30 Uhr aus.
* <code>[00:10*20:00-21:00]</code> führt den Schaltbefehl von 20 Uhr bis 21 Uhr alle 10 Minuten aus.
* <code>[?20:00-21:00]</code> schaltet zu einem zufälligen Zeitpunkt zwischen 20 und 21 Uhr einmalig. 
* <code>[20:00|$we]</code> nur am Wochenende um 20:00 wird geschaltet.


Beispielsweise würde [17:00|1][18:30|23] den Trigger montags um 17 Uhr auslösen und dienstags sowie mittwochs um 18:30 Uhr.
==== Trigger Conditions ====
Bei [00:10*20:00-21:00] würde der Schaltbefehl von 21 Uhr bis 21 Uhr alle 10 Minuten ausgeführt. Bei [?20:00-21:00] würde der Schaltbefehl zu einem zufälligen Zeitpunkt zwischen 20 und 21 Uhr ausgeführt.  [20:00|$we] bedeutet, dass nur am Wochenende um 20:00 geschaltet wird.
 
==== Trigger conditions ====
Hier kann die Angabe von Bedingungen erfolgen, die zusätzlich zu dem triggernden Device erfüllt sein müssen.
Diese Bedingungen sind eng an DOIF-Syntax angelehnt. Die Kombination mehrerer Bedingungen und Zeiten ist durch AND oder OR möglich.
 
Wird in diesem Feld keine Angabe gemacht, so erfolgt der Schaltvorgang nur durch das triggernde Device ohne weitere Bedingungen.
 
;Zeitabhängigkeit
:[19:10-23:00] - Trigger des Devices erfolgt nur in angegebenem Zeitraum
;Readingabhängige Trigger
:[Devicename:Reading] =/>/< X oder [Devicename:Reading] eq "x" - Trigger des Device erfolgt nur bei erfüllter Bedingung.
:Werden Readings mit Strings abgefragt (on,off,etc.), ist statt des Gleichheitszeichens "=" der Operator "eq" zu nutzen, der String muss in Anführungszeichen "" gesetzt werden.
;mehrere Beispiele
:[19:10-23:00] AND [Devicename:Reading] = 10 - beide Bedingungen müssen erfüllt sein.
:[19:10-23:00] OR [Devicename:Reading] = 10 - eine der Bedingungen muss erfüllt sein.
:[10:00-11:00|13] - schaltet Montag und Mittwoch zwischen 10 Uhr und 11 Uhr.
:[{ sunset() }-23:00] - von Sonnenuntergang bis 23:00 Uhr.
:{ !$we } löst den Schaltvorgang nur Werktagen an aus.
:{ $we } löst den Schaltvorgang nur an Wochenenden, Feiertagen aus.


Optionale zusätzliche Bedingungen in diesem Feld gelten nur für auslösende Device Trigger. Trigger Times haben keinen Einfluss, es sei denn, das Attribut MSwitch_Condition_Time ist gesetzt. Man kann mit AND / OR verknüpfte Bedingungen für die Auslösung in an DOIF angelehnter Syntax angeben. Leere Felder werden ignoriert. Werden Readings mit Strings wie 'on' oder 'off' abgefragt, ist statt des Gleichheitszeichens "=" der Operator "eq" zu nutzen, der String muss in Anführungszeichen "" gesetzt werden. Beispiele:{{Randnotiz | RNTyp=y | RNText=Überschreitet die Zeitangabe die Tagesgrenze (24:00 Uhr), so gelten die angegebenen Tage noch bis zum Ende der angegebenen Schaltzeit (beispielsweise würde dann am Mittwoch noch der Schaltvorgang erfolgen, obwohl als Tagesvorgabe Dienstag gesetzt wurde).}}
* <code>[19:10-23:00] AND [Devicename:Reading] = 10</code> beide Bedingungen müssen erfüllt sein.
* <code>[19:10-23:00] OR [Devicename:Reading] eq "on"</code> eine der Bedingungen muss erfüllt sein.
* <code>[10:00-11:00|13]</code> schaltet Montag und Mittwoch zwischen 10 Uhr und 11 Uhr.
* <code>[{ sunset() }-23:00]</code> von Sonnenuntergang bis 23:00 Uhr.
* <code>{ !$we }</code> löst den Schaltvorgang nur Werktagen an aus.
* <code>{ $we }</code> löst den Schaltvorgang nur an Wochenenden, Feiertagen aus.
Es ist auf korrekte Eingabe der Leerzeichen zu achten.
Es ist auf korrekte Eingabe der Leerzeichen zu achten.


Überschreitet die Zeitangabe die Tagesgrenze (24:00 Uhr), so gelten die angegebenen Tage noch bis zum Ende der angegebenen Schaltzeit (beispielsweise würde dann am Mittwoch noch der Schaltvorgang erfolgen, obwohl als Tagesvorgabe Dienstag gesetzt wurde).
=== Rahmen 2: Trigger Details ===
 
Bedingungen in diesem Feld gelten nur für auslösende Trigger eines Devices und haben keinen Einfluss auf zeitgesteuerte Auslöser.
 
=== Trigger details ===
[[Datei:MSwitchWebinterface2.png|600px|thumb|right|Webinterface, Mitte]]
[[Datei:MSwitchWebinterface2.png|600px|thumb|right|Webinterface, Mitte]]
Während im obigen Feld das Device ausgewählt  werden konnte, wird hier das Ereignis festgelegt. Das Eingabefeld besteht aus mehreren Einzelfeldern.
Der Inhalt des zweiten Rahmens wird mit dem gewählten Trigger aus dem ersten Rahmen initialisiert. Events können zugeordnet werden. Im Beispiel wird cmd1 ausgelöst, wenn das Fenster offen ist. Cmd2 wird bei Temperaturunterschreitung ausgelöst.


Im abgebildeten Fall wird cmd1 ausgelöst, wenn der Zustand des Schlafzimmerfenster-Sensors meldet, dass das Fenster offen ist. Cmd2 wird ausgelöst, wenn die Temperatur des Schlafzimmersensors unter einen bestimmten Wert fallen wird.
==== execute ====
Diese vier Zeilen legen fest, welches ankommende Event welchen Befehlszweig auslösen soll. Die Event-Drop-Down-Liste enthält alle empfangenen Events dieses Devices. Fehlende Events können manuell hinzugefügt werden.


==== execute 'cmd1/cmd2====
* switch <MSwitch> on + execute 'cmd1' - MSwitch Statusänderung auf 'on'; cmd1 soll ausgeführt werden
Hier kann  aus einer vorbelegten Dropdownliste ausgewählt werden, welches ankommende Event den entsprechenden Befehlszweig auslösen soll. In dieser Liste werden bei entsprechender Einstellung alle ankommenden Events eines vorher definierten Devices gespeichert. In einem weiteren Feld (siehe unten) können Events manuell zugefügt werden.
* switch <MSwitch> off + execute 'cmd2' - MSwitch Statusänderung auf 'off'; cmd2 soll ausgeführt werden;
* execute 'cmd1' only - keine Statusänderung; cmd1 soll ausgeführt werden
* execute 'cmd2' only - keine Statusänderung; cmd2 soll ausgeführt werden


==== Save incomming events ====
==== Save incomming events ====
Bei Aktivierung dieser Option werden alle ankommenden Events des oben definierten Devices (oder Global) gespeichert und in entsprechenden Dropdownlisten angeboten.
Alle ankommenden Events der konfigurierten Geräte werden für die Dropdownlisten gespeichert. Nach erfolgreicher Konfiguration sollte diese Option entfernt werden, um die Datenmenge zu reduzieren. Falls das Device Events während der Konfiguration nicht liefert, können sie manuell als kommagetrennte Liste hinzugefügt werden.
 
Da hier doch erhebliche Datenmengen anfallen können (je nach Device) wird empfohlen, diese Option nach der Konfiguration des Devices zu deaktivieren.


==== add event ====
==== add event ====
hier besteht die Möglichkeit, unabhängig von der Option, ankommende Events automatisch zu speichern, manuell Events anzulegen, die in den Dropdownliste zur Auswahl angeboten werden, ohne das entsprechendes Event erst vom Device geliefert werden muss.
{{Randnotiz | RNTyp=y | RNText=Falls auf 'GLOBALE' Events getriggert wird, muss das auslösende Device vorangestellt werden:
 
- *                                                          - alle auftretende Events des entsprechenden Device
Es können mehrere Events gleichzeitig eingegeben werden, eine Trennung erfolgt durch " , ".
- device:reading:wert  (z.B. device:state:on )                      - nur für das Event "device:state:on"
 
- device:reading:*      (z.B. device:state:* )                      - Events "device:state:(on,off,etc.)
Hier ist zu unterscheiden, ob das gewählte triggernde Device ein einfaches Device ist oder ob der Trigger 'GLOBAL' ist.
- device:reading:(wert1/wert2/wert3) (z.b. device:state:(left/right) - Events "device:state:left" oder "devicestate:right" etc.
Bei triggernden Devices können Events in folgendem Formaten zugefügt werden:
 
- *                                                    - Aktion erfolgt auf alle auftretende Events des entsprechenden Device<br>
- reading:wert  (z.b. state:on )                      - Aktion erfolgt nur auf das Event "state:on"<br>
- reading:*      (z.b. state:* )                      - Aktion erfolgt auf die Events "state:(on,off,etc.)<br>
- reading:(wert1/wert2/wert3) (z.b. state:(left/right) - Aktion erfolgt nur auf Events "state:left" oder "state:right" etc.<br>
<br>
Falls auf 'GLOBALE' Events getriggert wird, muss das auslösende Device vorangestellt werden:<br>
<br>
- *                                                          - Aktion erfolgt auf alle auftretende Events des entsprechenden Device<br>
- device:reading:wert  (z.b. device:state:on )                      - Aktion erfolgt nur auf das Event "device:state:on"<br>
- device:reading:*      (z.b. device:state:* )                      - Aktion erfolgt auf die Events "device:state:(on,off,etc.)<br>
- device:reading:(wert1/wert2/wert3) (z.b. device:state:(left/right) - Aktion erfolgt nur auf Events "device:state:left" oder "devicestate:right" etc.<br><br>


Das Device kann auch hier gegen "*" ersetzt werden (*:state:on). In diesem Fall erfolgt eine Aktion auf alle Events die z.B. "state:on" enthalten, egal welches Device triggert.
Das Device kann auch hier gegen "*" ersetzt werden (*:state:on). In diesem Fall erfolgt eine Aktion auf alle Events die z.B. "state:on" enthalten, egal welches Device triggert.
 
}}
* *                                                    - alle auftretende Events des entsprechenden Device
* reading:wert  (z.B. state:on )                      - nur auf das Event "state:on"
* reading:*      (z.B. state:* )                      - Events "state:(on,off,etc.)
* reading:(wert1/wert2/wert3) (z.b. state:(left/right) - Events "state:left" oder "state:right" etc.
==== test event ====
==== test event ====
Dieses Feld wird angeboten, wenn entsprechende vom Triggerdevice gelieferte Events gespeichert wurden.
Stehen Events zur Auswahl, kann die Konfiguration getestet werden. Durch Klick wird das Event simuliert und die dafür definierte Aktion ausgelöst.  
 
Durch Auslösen dieser Funktion wird das Event simuliert und entsprechende definierte Aktionen ausgelöst. Diese Funktion dient ausschließlich zum Testen der eingestellten Konfiguration. Alle entsprechenden Befehle werden ausgeführt, als würde das Event real eintreffen.


==== apply filter to saved events ====
==== apply filter to saved events ====
Beschreibung folgt
Beschreibung folgt???


==== clear saved event ====
==== clear saved event ====
Es werden alle gespeicherten Events gelöscht.
Es werden die nicht als Trigger wirkenden Events aus der Liste gelöscht.


Ausnahme: Events, die als Trigger eingestellt sind, bleiben erhalten.
=== Rahmen 3: Affected devices ===
 
{{Randnotiz | RNTyp=y | RNText=In dem Auswahlfeld werden alle Devices angeboten, die eines der folgenden Kriterien erfüllen:
=== Affected devices ===
[[Datei:MSwitch_Screen_5.png|mini|rechts|affected devices]]
Dieser Abschnitt beinhaltet die Auswahl der Devices, die auf ein Event reagieren sollen.
 
In dem Auswahlfeld werden alle Devices angeboten, die eines der folgenden Kriterien erfüllen:
# Die Abfrage "set Device ?" liefert einen Befehlssatz
# Die Abfrage "set Device ?" liefert einen Befehlssatz
# Das Attribut 'webcmd' des Devices enthält Einträge
# Das Attribut 'webcmd' des Devices enthält Einträge
Zeile 230: Zeile 135:
Einzige Ausnahme ist der erste Listeneintrag 'FreeCMD'. Die Auswahl dieses Eintrages bietet später die Möglichkeit Befehle auszuführen, die nicht an ein Device gebunden sind. Der Code in einem FreeCmd kann entweder reiner FHEM-Code sein ( set device on ) oder reiner Perl-Code. Wenn es sich um reinen Perl-Code handelt, ist dieser in geschweifte Klammen zu setzen { Perl-Code }.
Einzige Ausnahme ist der erste Listeneintrag 'FreeCMD'. Die Auswahl dieses Eintrages bietet später die Möglichkeit Befehle auszuführen, die nicht an ein Device gebunden sind. Der Code in einem FreeCmd kann entweder reiner FHEM-Code sein ( set device on ) oder reiner Perl-Code. Wenn es sich um reinen Perl-Code handelt, ist dieser in geschweifte Klammen zu setzen { Perl-Code }.


=== Device actions ===
}}
[[Datei:MSwitch_Screen_5.png|mini|rechts|affected devices]]
Auswahl der Devices, die auf die oben konfigurierten Events reagieren sollen. Um unbeabsichtigte Änderungen zu vermeiden ist die direkte Mehrfachauswahl gesperrt.
 
=== Rahmen 4: Device Actions ===
 
[[Datei:Webinterface3.png|mini|rechts|device_actions]]
[[Datei:Webinterface3.png|mini|rechts|device_actions]]
Hier stellt man die auszuführenden Aktionen der eingestellten Devices ein. Im ersten Abschnitt oben befindet sich ein FreeCmd, mit dem beliebige Kommandos eingetragen werden können. Im abgebildeten Beispiel ist dies sogar selbst definierter Perl-Code (die Funktion DebianMail sendet eine Mail).  
Die auszuführenden Aktionen der im dritten Rahmen gewählten Geräte. Leere Felder werden ignoriert.


==== MSwitch cmd1/cmd2:  ====
==== MSwitch cmd1/cmd2:  ====
Man wählt den Befehl aus dem betreffenden Device aus. Bei freien Textfeldern (wie im Fall des FreeCmd) wird der Befehl eingegeben.
{{Randnotiz | RNTyp=y | RNText=Im Beispiel befindet sich ein FreeCmd, mit dem beliebige Kommandos eingetragen werden können. Im abgebildeten Beispiel ist dies sogar selbst definierter Perl-Code (die Funktion DebianMail sendet eine Mail).
}}
Man wählt den gewünschten Befehl aus den gespeicherten verfügbaren Möglichkeiten des betreffenden Device aus.  


Es werden alle verfügbaren Befehle des Devices zur Auswahl angeboten. Je nach Attribut-Einstellungen werden Einträge aus entsprechenden 'webcmds" oder 'MSwitchcmds' einbezogen. In Abhängigkeit des Befehls stehen unter Umständen weitere Felder oder Widgets zur Verfügung.
* Im Sonderfall FreeCmd wird der Befehl als String eingegeben.  
* Das Attribut MSwitch_Extensions ergänzt die Schaltoption 'MSwitchToggle' in der Liste, um die Toggle-Funktion bei Geräten die sie nicht von Haus aus anbieten nachzurüsten.  


05.04.2018 NEU: Auswahlfeld 'MSwitchtoggle' -> Beschreibung wird noch ergänzt !
{{Randnotiz | RNTyp=y | RNText=Je nach Attribut-Einstellungen werden Einträge aus entsprechenden 'webcmds" oder 'MSwitchcmds' einbezogen. In Abhängigkeit des Befehls stehen unter Umständen weitere Felder oder Widgets zur Verfügung.
).
}}


==== cmd1/cmd2 condition  ====
==== cmd1/cmd2 condition  ====
Mit diesem Feld kann die Ausführung des Befehls von weiteren Bedingungen abhängig gemacht werden. Bei der Abfrage von Readings nach Strings (on, off, etc.) ist statt "=" "eq" zu nutzen und der String muss in "x" gesetzt werden. Es ist auf korrekte Eingabe der Leerzeichen zu achten.
#Zeitabhängiges schalten: [19:10-23:00] - Schaltbefehl erfolgt nur in angegebenem Zeitraum
#Readingabhängiges schalten [Devicename:Reading] =/>/< X oder [Devicename:Reading] eq "x" - Schaltbefehl erfolgt nur bei erfüllter Bedingung.
Soll nur an bestimmten Wochentagen geschaltet werden, muss eine Zeitangabe gemacht werden.
Beispielsweise würde [10:00-11:00|13] den Schaltvorgang nur Montag und Mittwoch zwischen 10 Uhr und 11 Uhr auslösen. Hierbei zählen die Wochentage von 1-7 für Montag-Sonntag.
Die Kombination mehrerer Bedingungen und Zeiten ist durch AND oder OR möglich:
* [19:10-23:00] AND [Devicename:Reading] = 10 - beide Bedingungen müssen erfüllt sein.
* [19:10-23:00] OR [Devicename:Reading] = 10 - eine der Bedingungen muss erfüllt sein.
* [{sunset()}-23:00] - von Sonnenuntergang bis 23:00 Uhr.
* { !$we } löst den Schaltvorgang nur Werktagen aus
* { $we } löst den Schaltvorgang nur Wochenenden, Feiertagen aus


{{Randnotiz | RNTyp=y | RNText=Bei der Abfrage von Readings nach Strings (on, off, etc.) ist statt "=" "eq" zu nutzen und der String muss in "x" gesetzt werden. Es ist auf korrekte Eingabe der Leerzeichen zu achten.
'''Achtung:''' Bei Anwendung der geschweiften Klammern zur Einleitung eines Perl Ausdrucks ist unbedingt auf die Leerzeichen hinter und vor der Klammer zu achten.
'''Achtung:''' Bei Anwendung der geschweiften Klammern zur Einleitung eines Perl Ausdrucks ist unbedingt auf die Leerzeichen hinter und vor der Klammer zu achten.


Überschreitet die Zeitangabe die Tagesgrenze (24:00 Uhr), so gelten die angegebenen Tage noch bis zum Ende der angegebenen Schaltzeit (zum Beispiel würde auch am Mittwoch noch der Schaltvorgang erfolgen, wenn als Tagesvorgabe Dienstag gesetzt wurde).
Überschreitet die Zeitangabe die Tagesgrenze (24:00 Uhr), so gelten die angegebenen Tage noch bis zum Ende der angegebenen Schaltzeit (zum Beispiel würde auch am Mittwoch noch der Schaltvorgang erfolgen, wenn als Tagesvorgabe Dienstag gesetzt wurde).
}}
Die Ausführung der Befehle kann '''pro gewählten Gerät''' analog Rahmen 1 von weiteren Bedingungen abhängig gemacht werden. Es gelten die gleichen Regeln und Beispiele wie im 'Rahmen 1 Trigger Conditions'. Sie können sinngemäß übernommen werden.


; $EVENT:
Die Variable <code>$EVENT</code> enthält den auslösenden Trigger. Wenn unter 'Rahmen 1 Trigger Conditions' ein Wildcard verwendet wurde, kann nun feingefiltert werden, indem das konkrete Ereignis angegeben wird.  
: Die Variable EVENT enthält den auslösenden Trigger, d.h. es kann eine Reaktion in direkter Abhängigkeit zum auslösenden Trigger erfolgen.


[$EVENT] eq "state:on" würde den Kommandozweig nur dann ausführen, wenn der auslösende Trigger "state:on" war. Wichtig ist dieses, wenn bei den Triggerdetails nicht schon auf ein bestimmtes Event getriggert wird, sondern hier durch die Nutzung eines Wildcards (*) auf alle Events getriggert wird, oder auf alle Events eines Readings z.B. (state:*).
Beispiel: <code>[$EVENT] eq "state:on"</code> würde den Kommandozweig nur dann ausführen, wenn der auslösende Trigger "state:on" war.


==== cmd1/cmd2 delay  ====
==== cmd1/cmd2 delay  ====
Ein Eintrag in diesem Feld führt zur verzögerten Ausführung des Befehls nach Eintreffen des Events. Dabei kann der Befehl ohne weitere Prüfung der Bedingung ausgelöst werden. Es ist aber auch möglich, dass die Bedingung bei Ausführung erneut geprüft wird. Die Zeitangabe muss im Format hh:mm:ss vorliegen.
Ein Eintrag in diesem Feld führt zur verzögerten Ausführung des Befehls nach Eintreffen des Events. Dabei kann der Befehl ohne weitere Prüfung der Bedingung ausgelöst werden. Es ist aber auch möglich, dass die Bedingung bei Ausführung erneut geprüft wird. Die Zeitangabe muss im Format hh:mm:ss vorliegen. Einzelheiten enthält auch das Funktions-Struktogramm.


Statt einer unmittelbaren Zeitangabe kann hier auch ein Verweis auf ein Reading eines Devices erfolgen :<br>
Statt einer direkten Zeitangabe kann hier auch auf eine verwiesen werden, indem in der Form [NAME.reading] ein Reading eines Devices wie z.B. [dummy.state] angegeben wird.
[NAME.reading] des Devices ->z.B. [dummy.state]


==== add action  ====
==== add action  ====
Mit diesem Button kann ein weiteres Eingabefeld für das entsprechende Device angelegt werden, um z.B. einen weiteren Befehl (ggf.) zeitverzögert auszuführen.
Mit diesem Button kann ein weiterer Rahmen 4 als Rahmen 4.1 für das gleiche Device angelegt werden, um z.B. einen weiteren Befehl gegebenenfalls zeitverzögert auszuführen.


==== delete this action  ====
==== delete this action  ====
Mit diesem Button wird der entsprechende Befehl für das Device gelöscht.
Mit diesem Button wird der gewählte Rahmen 4 für das Device gelöscht.


==== check condition  ====
==== check condition  ====
Zeile 284: Zeile 185:


==== Repeat und Repeatdelay ====
==== Repeat und Repeatdelay ====
Man kann mehrfache Wiederholungen erzwingen. Repeat gibt dabei an, wie oft das Kommando wiederholt wird (Anzahl). Repeatdelay gibt an, wie viel Sekunden zwischen einzelnen Wiederholungen liegen sollen.


== Attribute ==
Die Felder 'Repeats', 'Repeatdelay in s' und 'priority' stehen zur Verfügung, wenn das Attribut MSwitch_Expert gesetzt wurde. Diese bewirken eine n-fache Wiederholung des gesetzten Befehls mit m Sekunden Verzögerung. Das Auswahlfeld 'priority' erscheint bei jedem 'affectes device'. So kann die Reihenfolge der Befehlsabarbeitung beeinflusst werden.
Folgende Attribute stehen zur Verfügung:


=== MSwitch_Debug (0:1:2:3:4) ===
== Erweiterte Konfiguration ==
0 - Abgeschaltet<br>
1 - Schaltet Felder zum testen der Conditionstrings etc. an<br>
2 - Alle ausgehenden Befehle werden nur simuliert und nicht ausgeführt. Es erfolgt eine Protokollierung in einer separaten Datei . Diese wird direkt im Device angezeigt<br>
2 - Es erfolgt eine Protokollierung in einer separaten Datei . Diese wird direkt im Device angezeigt<br>
4 - erweiterte Debugfunktion (nur für Entwicklung - wechselnde Funktion )<br>


=== MSwitch_Expert (0:1) ===
=== Set-Befehle ===
In der Liste der möglichen Trigger erscheint das Selectfeld 'GLOBAL'. Dieses ermöglicht das Setzen eines Triggers auf alle Events und damit nicht nur auf einzelne Devices. In einem weiteren Feld kann eine weitere Selektion der triggernden Events erfolgen.


Es stehen weitere Felder 'Repeats' und 'Repeatdelay in sec' zur Verfügung. Eine hier getätigte Einstellung bewirkt X-fache Wiederholung von gesetzten Befehlen im Abstand der gesetzten Sekunden.
{| class="wikitable sortable"
|-
! Name !! class="unsortable" | Beschreibung
|-
|set active||Setzt das MSwitch-Device in den Status 'active'.
|-
|set inactive||Setzt das Device in den Status 'inactive'. Es werden keine Befehle mehr ausgeführt. Dieser Status entspricht dem Attribut 'disable', ist aber nicht mit dem roten Fragezeichen (fhem save) verbunden.
|-
|set on<nowiki>|</nowiki>off [<parameter>]||Setzt das Device in den Status 'on' oder 'off'. Alle Befehle der 'on/off-Zweige' werden ausgeführt. Optional kann den Befehlen 'on' und 'off' ein weiterer Parameter mit übergeben werden. Dieser wird im Reading 'Parameter' hinterlegt und es kann sofort in 'Freecmds' oder 'Conditions' darauf zugegriffen werden.
|-
|set reload_timer||Alle gesetzten Timer werden gelöscht und neu berechnet.
|-
|set change_renamed <oldname> <newname>||Sollten sich Devicenammen im ausführenden Teil geändert habe (affected Devices, Conditions, etc.) so kann das MSwitch mit diesem Befehl angepasst werden, ohne alle Einstellungen neu einstellen zu müssen.
|-
|set exec_cmd1 <nowiki>|</nowiki> set exec_cmd1 ID [<ID>]||Bewirkt das sofortige Ausführen des entsprechenden Befehlszweiges. Bei Angabe einer ID werden nur die Befehle mit der entsprechenden ID ausgeführt.
|-
|set MSwitch_backup||Erstellt eine Backup-Datei aller MSwitch Devices unter ./fhem/MSwitch_backup.cfg. Daten dieser Datei können im Bedarfsfall für einzelne oder gleichzeitig alle MSwitch Devices wieder zurückgespielt (hergestellt) werden.
|-
|set del_delays <nowiki>|</nowiki> set exec_cmd1 ID [<ID>]||Löscht alle anstehenden, verzögerten Befehle (delays).
|-
|set reset_cmd_count: 1<nowiki>|</nowiki>2||Löscht das entsprechende EVT_CMD_COUNT - Reading; entspricht damit einer Rückstellung auf '0'.
|-
|set fakeevent [<device>]:<reading>:<arg>||Beispiel: <device> fakeevent state:on<br>
Das MSwitch Device reagiert so, als wäre statt des internen "fakes-Befehls" ohne FHEM-Systembeeinflussung dieses Event tatsächlich vom triggernden Gerät generiert worden.  


Weiterhin kann über das Auswahlfeld 'priotity' bei jedem 'affectes device' die Reihenfolge beim abarbeiten der Befehle beeinflusst werden.
Der Name (<device>) muss bei GLOBALEN Triggern mit angegeben werden, sonst wird das Device automatisch gesetzt.
Um z.B. einen Watchdog zu realisieren ist es eventuell nötig, dass sich das MSwitch Device mit einem bestimmten Event selber neu triggert - ggf. mit einem entsprechenden Delay Affected Device. Bei dem Einsatz dieser Möglichkeit sollte das Attribut 'MSwitch_Safemode' UNBEDINGT aktiviert sein, da 'Experimente' hier schnell in einer Endlosschleife enden können, die nur durch ein Reboot unterbrochen werden kann. Möglicherweise steht dieser Befehl zukünftig nur noch zur Verfügung, wenn Safemode aktiviert ist.
|}


=== MSwitch_Sequenz <Suchmuster> ===
=== Get-Befehle ===
In diesem Attribut können ein oder mehrere Suchmuster angegeben werden ,die eine Schaltsequenz darstellen und vom Device erkannt werden.


Die Angabe muss folgende Syntax haben:
{| class="wikitable sortable"
:<code>Device1:reading1:event1 Device1:reading1:event1-2 Device1:reading1:event1-3/..../....</code>
|-
! Name !! class="unsortable" | Beschreibung
|-
|get show_timer [<show><delete>]||
;Show
:Zeigt alle anstehenden (gesetzten) Timer des Devices, die aus zeitabhängigen oder verzögerten Schaltbefehlen resultieren.
;Delete
:Löscht alle anstehenden (gesetzten) Timer des Devices, die aus zeitabhängigen oder verzögerten Schaltbefehlen resultieren. Schaltbefehle basierend auf rein zeitabhängigen Angaben werden neu berechnet und gesetzt.
|-
|get restore_MSwitch_data [<this_device><nowiki>|</nowiki><all_devices>]||
;this_device
:Stellt die Daten des Devices aus der Backupdatei wieder her, sofern diese in der Backupdatei gefunden werden (gesucht wird hier nach dem Namen des Devices).
;all_devices
:Stellt die Daten aller MSwitch Devices wieder her, sofern diese in der Backupdatei vorhanden sind. Diese Aktion kann einige Zeit in Anspruch nehmen und wird daher im Hintergrund (nonblocking) ausgeführt. Nach Beendigung erfolgt eine Benachrichtigung.
Die Devices sind nach einem Restore funktionsfähig. Empfohlen wird ein Neustart von FHEM..
|-
|get_config||Zeigt die Konfigurationsdatei des MSwitchdevices an; diese kann in dem Fenster editiert werden. Das sollte nur von erfahrenen Usern getan werden! Im Normalfall sollte das Device nur über die Weboberfläche konfiguriert werden und eine falsche Konfiguration kann hier zu einem FHEM Absturz führen.
|-
|get_support_info||Öffnet ein Fenster mit einer formatierten Ansicht aller Einstellungen des Devices. Bei Supportanfragen sollte dieses immer mit geposted werden.
|-
|get_MSwitch_preconf||Lädt vorkonfigurierte MSwitch-Devices. Diese Option ist nur dann vorhanden, wenn das Aktualisieren dieser vorkonfigurierten Devices im FHEM Update aktiviert ist.
Diese kann durch ein einmaliges Update erfolgen mit:
:<code>update all https://raw.githubusercontent.com/Byte009/MSwitch_Addons/master/controls_mswitchaddons.txt</code>
|}


mehrere Suchmuster müssen durch "/" getrennt werden.
=== Attribute ===
{| class="wikitable sortable"
|-
! Name !! class="unsortable" | Beschreibung
|-
|MSwitch_Debug <0<nowiki>|</nowiki>1<nowiki>|</nowiki>2<nowiki>|</nowiki>3<nowiki>|</nowiki>4>||
0 - Abgeschaltet<br>
1 - Schaltet Felder zum testen der Conditionstrings an<br>
2 - Alle ausgehenden Befehle werden nur simuliert und nicht ausgeführt. Der Inhalt der Protokolldatei wird direkt im Device angezeigt<br>
3 - Es erfolgt eine Protokollierung in einer separaten Datei. Diese wird direkt im Device angezeigt.<br>
4 - erweitertes Debugfür Entwickler mit wechselnden Funktionen<br>
|-
|MSwitch_Expert <0<nowiki>|</nowiki>1>||
* In der Liste der möglichen Trigger erscheint das Selectfeld 'GLOBAL'. Dieses ermöglicht das Setzen eines Triggers auf alle Events und damit nicht nur auf einzelne Devices. In einem weiteren Feld kann eine weitere Selektion der triggernden Events erfolgen.


Beispiel:
* Die Felder 'Repeats' und 'Repeatdelay in s' stehen zur Verfügung. Dies bewirkt eine n-fache Wiederholung des gesetzten Befehls mit m Sekunden Verzögerung.
:<code>Dummy:state:on Dummy:state:off Dummy:state:on</code>


Erkennt das Device dieses Suchmuster in den Schaltvorgängen des Devices (Dummy), wird das Reading "SEQUENCE" auf "match" gesetzt, das Reading "SEQUENCE_NUMBER" auf die Nummer der gefundenen Sequenz, wenn es mehrere Suchmuster gibt. Beide Readings können in den "Conditions" eines Schaltbefehles abgefragt werden.
* Das Auswahlfeld 'priority' erscheint bei jedem 'affectes device'. So kann die Reihenfolge der Befehlsabarbeitung beeinflusst werden.
|-
|MSwitch_Sequenz <Suchmuster> ??? ||
Eine Schaltsequenz kann durch ein oder mehrere durch '/' getrennte Suchmuster angegeben werden. Die Angabe muss folgende Syntax haben:
:<code>Device1:reading1:event1 Device1:reading1:event1-2 Device1:reading1:event1-3/..../....</code>


=== MSwitch_Expert <Zeit in Sekunden> ===
Beispiel: <code>Dummy:state:on Dummy:state:off Dummy:state:on</code>
Beinhaltet die Zeit in Sekunden, die es dauern darf, um eine Sequenz vollständig auszuführen.


=== MSwitch_Extensions (0:1) ===
Erkennt das Device dieses Suchmuster in den Schaltvorgängen des Devices (Dummy), wird das Reading "SEQUENCE" auf "match" gesetzt, das Reading "SEQUENCE_NUMBER" auf die Nummer der gefundenen Sequenz, wenn es mehrere Suchmuster gibt. Beide Readings können in den "Conditions" eines Schaltbefehles abgefragt werden. Eine Angabe muss in folgendem Format gemacht werden:
Es wird eine zusätzliche Schaltoption 'MSwitchToggle' in den Geräten angeboten. Diese kann genutzt werden, wenn zuschaltende Geräte eine Togglefunktion nicht von Haus aus anbieten.
 
Eine Angabe muss in folgendem Format gemacht werden:
:<code>on/off/state/suchmuster1/suchmuster2</code>, wobei die letzten drei Angaben optional sind.
:<code>on/off/state/suchmuster1/suchmuster2</code>, wobei die letzten drei Angaben optional sind.


Funktion: Bei Ausführung des Befehls wird das Gerät 'on' oder 'off' geschaltet (on/off), Voraussetzung ist, dass der 'state' dieses Gerätes auch den 'state on' oder 'off' annimmt. Sollte dieses nicht der Fall sein, so kann mit dem Feld 'state' angegeben werden, in welchem Reading der aktuelle Status vorkommt und wie dieser lautet (suchmuster1/suchmuster2). Dieses 'state' kann mehrere Angaben enthalten, das Vorkommen der Suchmuster ist aber Voraussetzung.
Funktion: Bei Ausführung des Befehls wird das Gerät 'on' oder 'off' geschaltet (on/off), Voraussetzung ist, dass der 'state' dieses Gerätes auch den 'state on' oder 'off' annimmt. Sollte dieses nicht der Fall sein, so kann mit dem Feld 'state' angegeben werden, in welchem Reading der aktuelle Status vorkommt und wie dieser lautet (suchmuster1/suchmuster2). Dieses 'state' kann mehrere Angaben enthalten, das Vorkommen der Suchmuster ist aber Voraussetzung.
|-
|MSwitch_Sequence_time <Zeit in Sekunden>||Maximalzeit in Sekunden, um eine Sequenz vollständig auszuführen. (Was wenn diese Zeit überschritten wird???)
|-
|MSwitch_Extensions <0<nowiki>|</nowiki>1>||Es wird zusätzlich zu 'on' und 'off' die Schaltoption 'MSwitchToggle' in der Liste angeboten, um die Toggle-Funktion bei Geräten die sie nicht von Haus aus anbieten nachzurüsten.
|-
|MSwitch_Delete_Delays <0<nowiki>|</nowiki>1>||Eins bewirkt das Löschen aller anstehende Delays bei dem Auftreten eines erneuten passenden Events. Bei der Option '0' bleiben bereits gesetzte Delays aus einem vorher getriggerten Event erhalten und werden ausgeführt. Empfohlene Einstellung: 1
|-
|MSwitch_Include_Devicecmds <0<nowiki>|</nowiki>1>||Bewirkt die Aufnahme aller Devices die bei Abfrage mit 'set DEVICE ?' einen eigenen Befehlssatz liefern in die Auswahlliste 'Affected Devices'. Bei Option '0' werden diese Devices in der Liste nicht mehr angeboten. Empfohlene Einstellung: 1
|-
|MSwitch_Include_Webcmds <0<nowiki>|</nowiki>1>||Bewirkt die Aufnahme aller Devices in die Auswahlliste 'Affected Devices', die einen eigenen Befehlssatz in dem Attribut Webcmd hinterlegt haben. Die in Webcmd hinterlegten 'Befehle' werden in den Auswahlfeldern angeboten. Bei gesetzter Option '0' werden diese Devices nicht mehr angeboten, es sei denn, sie liefern mit 'set DEVICE ?' einen eigenen Befehlssatz. Empfohlene Einstellung: 0, Einsatz nach Bedarf.
|-
|MSwitch_Activate_MSwitchcmds <0<nowiki>|</nowiki>1>||Fügt jedem vorhandenen Device das Attribut 'MSwitchcmd' hinzu.
|-
|MSwitch_Include_MSwitchcmds <0<nowiki>|</nowiki>1> ||Bewirkt die Aufnahme aller Devices in die Auswahlliste 'Affected Devices', die einen eigenen Befehlssatz in dem Attribut MSwitchcmds hinterlegt haben. Die in MSwitchcmds hinterlegten 'Befehle' werden in den Auswahlfeldern angeboten. Bei gesetzter Option '0' werden diese Devices nicht mehr angeboten, wenn sie nicht zusätzlich einen eigenen Befehlssatz mit 'set DEVICE ?' liefern. Empfohlene Einstellung: 0, Einsatz nach Bedarf.
|-
|MSwitch_Lock_Quickedit <0<nowiki>|</nowiki>1>||Voreinstellung für die Auswahlliste 'Affected Devices'. Bei der Option '1' ist diese voreingestellt gesperrt und kann nur über einen zusätzlichen Button geändert werden, um versehentliche Änderungen zu vermeiden. Die Auswahl einer Option ohne betätigte <Strg>-Taste bewirkt das Löschen aller bereits gesetzten Optionen. Empfohlene Einstellung: 1
|-
|MSwitch_Startdelay <0<nowiki>|</nowiki>10<nowiki>|</nowiki>20<nowiki>|</nowiki>30<nowiki>|</nowiki>60> ||MSwitch ignoriert nach einem FHEM-Neustart für die angegebene Zeit in Sekunden alle eingehenden Events um u.a. Startverzögerungen zu vermeiden. Bei nicht gesetztem Attribut gilt hier eine Zeit von 30 Sekunden. Diese sollte auch nur in Ausnahmefällen geändert werden. Empfohlene Einstellung: 30
|-
|MSwitch_Ignore_Types||Beinhaltet eine durch Leerzeichen getrennte Liste von Device-''Typen'' welche nicht geschaltet werden oder nicht geschaltet werden können. Sie werden dann in den Auswahllisten ''nicht'' dargestellt, um die Auswahllisten übersichtlich zu halten.Voreinstellung: notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul.


=== MSwitch_Delete_Delays (0:1) ===
???Wenn statt des Devicetyps ein devspec z.B. "TYPE=watchdog" angegeben wird, ist zu beachten, dass alle Geräte in die Ignoreliste einbezogen werden, die NICHT der devspec entsprechen. Weiterhin muss die devspec in Anführungszeichen gesetzt werden!???
Bewirkt das Löschen aller anstehende Timer (Delays) bei dem Auftreten eines erneuten, passenden Events. Bei der Option '0' bleiben bereits gesetzte Delays aus einem vorherigen, getriggertem Event erhalten und werden ausgeführt.
 
Empfohlene Einstellung (1)
 
=== MSwitch_Include_Devicecmds (0:1) ===
Bewirkt die Aufnahme aller Devices in die Auswahlliste 'Affected Devices', die einen eigenen Befehlssatz liefern (bei Abfrage set DEVICE ?).
 
Bei gesetzter Option (0) werden diese Devices nicht mehr berücksichtigt und somit nicht mehr angeboten.
 
Empfohlene Einstellung (1).
 
=== MSwitch_Include_Webcmds (0:1) ===
Bewirkt die Aufnahme aller Devices in die Auswahlliste 'Affected Devices', die einen eigenen Befehlssatz in dem Attribut Webcmd hinterlegt haben. Die in Webcmd hinterlegten 'Befehle' werden in den Auswahlfeldern angeboten.
 
Bei gesetzter Option (0) werden diese Devices nicht mehr berücksichtigt und somit nicht mehr angeboten, wenn sie nicht zusätzlich einen eigenen Befehlssatz (set DEVICE ?) liefern.
 
Empfohlene Einstellung (0), Einsatz nach Bedarf.
 
=== MSwitch_Activate_MSwitchcmds (0:1) ===
Fügt jedem vorhandenen Device as Attribut 'MSwitchcmd' hinzu.
 
=== MSwitch_Include_MSwitchcmds (0:1) ===
Bewirkt die Aufnahme aller Devices in die Auswahlliste 'Affected Devices', die einen eigenen Befehlssatz in dem Attribut MSwitchcmds hinterlegt haben. Die in MSwitchcmds hinterlegten 'Befehle' werden in den Auswahlfeldern angeboten. Bei gesetzter Option (0) werden diese Devices nicht mehr berücksichtigt und somit nicht mehr Angeboten, wenn sie nicht zusätzlich einen eigenen Befehlssatz (set DEVICE ?) liefern.
 
Empfohlene Einstellung (0), Einsatz nach Bedarf.
 
=== MSwitch_Lock_Quickedit (0:1) ===
Voreinstellung für die Auswahlliste 'Affected Devices'. Bei der Option (1) ist diese voreingestellt gesperrt und kann nur über einen zusätzlichen Button geändert werden. Da es sich hier um ein Feld mit der Möglichkeit einer Mehrfacheingabe handelt handelt ist die Voreinstellung 1, um versehentliche nicht gewünschte Änderungen zu vermeiden (Auswahl einer Option ohne 'Strg' bewirkt das löschen aller bereits gesetzten Optionen).
 
Empfohlene Einstellung (1).
 
=== MSwitch_Startdelay (0:10:20:30:60) ===
Diese Einstellung beeinflusst den Start von MSwitch nach einem FHEM Start. MSwitch ignoriert für die angegebene Zeit in Sekunden alle eingehenden Events um u.a. Startverzögerungen zu vermeiden. Bei nicht gesetztem Attribut gilt hier eine Zeit von 30 Sekunden. Diese sollte auch nur in Ausnahmefällen bzw. bei besonderem Bedarf geändert werden.
 
Empfohlene Einstellung (30).
 
=== MSwitch_Ignore_Types ===
Beinhaltet eine Liste von Device''typen'', die in den Auswahllisten ''nicht'' dargestellt werden. Hier ist es sinnvoll, Devicetypen einzutragen, die in aller Regel nicht geschaltet werden oder nicht geschaltet werden können, um die Auswahllisten übersichtlicher zu halten. Einzelne Devicetypen sind durch Leerzeichen zu trennen.
 
Voreinstellung: notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul.


Eine Angabe kann hier in 2 Arten getätigt werden:
|-
# eine Liste von devicetypen.
|MSwitch_Trigger_Filter  ||Beinhaltet eine kommagetrennte Liste von Events, die im Falle ihres Eingangs unberücksichtigt und ungespeichert bleiben. Wildcards wie '*' können angegeben werden. Empfohlene Einstellung: -
# Angabe einer devspec z.B. "TYPE=watchdog". Hier ist zu beachten, dass in diesem Fall alle Geräte in die Ignoreliste einbezogen werden, die NICHT der devspec entsprechen. Weiterhin muss die devspec in Anführungszeichen gesetzt werden!
|-
|MSwitch_Wait <n in Sekunden>||Bei gesetztem Attribut nimmt das MSwitch Device für den eingestellten Zeitraum keine Befehle mehr entgegen und ignoriert eingehende Events.


=== MSwitch_Trigger_Filter ===
|-
Beinhaltet eine Liste von Events, die bei eingehenden Events unberücksichtigt bleiben. Diese werde dann auch nicht gespeichert.
|MSwitch_Event_Id_Distributor|| ??? Voraussetzung ist, dass das Attribut 'MSwitchExpert' auf '1' gesetzt ist. Es können auslösende Events ID-Aktionen umgeleitet werden. Sollte bei den 'trigger details :' in einem Zweig ( cmd1 ) z.B. mehrere getriggert werden (regex state:(on |off)) so werden für beide Events jeweils der Zweig 'cmd1' - alle  Aktionen ohne ID - ausgeführt. Durch entsprechende Einträge kann für entsprechende Events auf eine Aktion umgeleitet werden, für die eine ID definiert ist. Die Syntax lautet: <code>state:on=>cmd1 ID 1,2</code> Entsprechend werden bei auslösendem Event 'state:on' nur die Aktionen aus cmd1 mit den IDs 1 und 2 ausgeführt. Mehrere Angaben sind durch new Line zu trennen. ???


Hier kann mit Wildcards (*) gearbeitet werden. Einzelne Events sind durch Komma ',' zu trennen.
|-
 
|MSwitch_Selftrigger_always <0<nowiki>|</nowiki>1> ||(dieses Attribut steht ab Modulversion 2.5 zur Verfügung)
Empfohlene Einstellung (keine).
 
=== MSwitch_Wait (sec)===
Bei gesetztem Attribut (Zeit in Sekunden) nimmt Das MSwitch Device für den eingestellten Zeitraum keine Befehle mehr entgegen und ignoriert eingehende Events
 
=== MSwitch_Event_Id_Distributor ===
Dieses Attribut hat nur dann eine Funktion, wenn auch das Attribut 'MSwitchExpert' auf '1' gesetzt ist.
Hier können verschiedene auslösende Events auf Aktionen mit angegebenen IDs umgeleitet werden.
 
Sollte bei den 'trigger details :' in einem Zweig ( cmd1 ) z.B. auf mehrere Events getriggert werden ( regex z.B. state:(on|off) ) so werden für beide Events jeweils der Zweig 'cmd1' - alle  Aktionen ohneID - ausgeführt. Durch entsprechende Einträge kann für entsprechende Events auf eine Aktion umgeleitet werden , für die eine ID definierrtt ist. Die Syntax lautet:
:<code>state:on=>cmd1 ID 1,2</code>
 
Hier werden bei auslösendem Event 'state:on' nur die Aktionen aus cmd1 mit den IDs 1 und 2 ausgeführt. Mehrere Angaben sind durch new Line zu trennen.
 
=== MSwitch_Selftrigger_always (0,1)===
(dieses Attribut steht ab Modulversion 2.5 zur Verfügung)
 
Die Aktivierung dieses Attributes (1) bewirkt , dass alle SET Aktionen des Devices einen (internen) Event auslösen, auf die das Device selber reagiert. Diese Option kann zusätzlich zu einem vorhandenen Trigger aktiviert werden.
 
Diese Events sind lediglich Deviceintern , d.H es werden keine Modulübergreifenden Events ausgelöst.
 
Damit auftretende und auswertbare interne Events haben immer folgendes Format und können darüber augewertet weden.


Die Aktivierung dieses Attributes '1' bewirkt, dass alle SET Aktionen des Devices einen internen Event ohne Auswirkungen auf das FHEM-System auslösen, auf die das Device selber reagiert. Diese Option kann zusätzlich zu einem vorhandenen Trigger aktiviert werden. Auftretende auswertbare interne Events haben immer folgendes Format:
MSwitch_Self:aktion:wert  
MSwitch_Self:aktion:wert  
MSwitch_Self:pct:100
MSwitch_Self:pct:100
Es werden nur interne Events für set-Aktionen ausgelöst, die im Attribut setlist hinterlegt sind. Der 'wait' Befehl/Attribut hat keine wirkung.
|-
|MSwitch_Mode <Notify<nowiki>|</nowiki>Full<nowiki>|</nowiki>Toggle<nowiki>|</nowiki>Dummy> ||Schaltet das Modul zwischen angepassten Weboberflächen-Modi um.


Es werden nur interne Events für set-Aktionen ausgelöst , die im Attribut setlist hinterlegt sind.
Notify
 
Das Device kann nicht manuell umgeschaltet werden. Es gibt nur die zwei ausführbaren Zweige "execute 'cmd1' commands" und "execute 'cmd2' commands". Der Status des Devices wird nicht als 'on' oder 'off' angezeigt, sondern lediglich als 'active' Dieser Mode ist ähnlich zu einem FHEM-Notify.
Als weitere Besonderheit unterliegen diese internen Events nicht dem 'wait' Befehl
 
=== MSwitch_Mode (Notify,Full,Toggle,Dummy)===
Schaltet das Modul zwischen verschiedenen Modi um, mit entsprechend angepasster Weboberfläche
* Notify - Das Device kann nicht manuell umgeschaltet werden, es gibt nur zwei ausführbare Zweige (execute 'cmd1' commands und execute 'cmd2' commands). Der Status des Devices wird nicht als 'on' oder 'off' angezeigt, sondern lediglich als 'active'
: Dieser Mode ist am ehesten mit einem Notify zu Vergleichen.
* Full - Es stehen alle Funktionen zur Verfügung.
* Toggle - Sehr vereinfachter Mode. Es stehen keine verschiedenen Zweige zur Verfügung. Hier ist das Device manuell schaltbar und wird bei jedem definierten Event 'Umgeschaltet', entsprechend definierte Befehle für 'cmd1' oder 'cmd2' werden ausgeführt.
* Dummy - entspricht im wesentlichen dem Funktionsumfag eine Dmmys
 
=== MSwitch_Condition_Time (0,1)===
In der Grundeinstellung (0) werden für das zeitgesteuerte Schalten keine definierten Conditionen im Feld 'Trigger condition' überprüft, sondern die Schaltbefehle werden in jedem Fall ausgeführt. Mit der Einstellung (1) wird diese Überprüfung auch für zeitgesteuerte Befehle zugeschaltet.
 
=== MSwitch_Random_Time (HH:MM:SS-HH:MM:SS)===
Bei Aktivierung wird vor jedem Ausführen eines verzögerten Befehls ( Delay ) eine Zufallszeit generiert, die im Rahme der hier angegebenen Zeitspanne liegt. Auf diese Zufallszahl kann in de Delays zugegriffen werden, durch die Angabe '[random]' statt einer direkten Zeitangabe. Bei nicht gesetztem Attribut ergibt die Angabe von ' [random] ' hier immer '00:00:00'
 
=== MSwitch_Random_Number ===
bei Aktivierung dieses Attributes (der Inhalt kann einen beliebige Zahl sein) werden vom Device 2 Readings angelegt (Device:RandomNr) und (Device:RandomNr1). RandomNr wird vor jedem Ausführen eines Befehls aktualisiert und neu generiert, d.H wenn ein MSwitch Device mehrere Geräte schaltet, wird (auch in einem Durchgang) vor jedem Befehl dieses Reading neu gesetzt. RandomNr1 wird lediglich bei Ausführung des MSwitch Devices einmal neu gesetzt, d.h. nicht vor jedem Befehl der ausgeführt wird.
Die Readings werden mit einer Zufallszahl zwischen 0 und dem hier eingestellten Wert gesetzt.
 
Auf diese Readings kann in jeder Condition mit z.B. '[$NAME:ReadingNr1] = 1' zugegriffen werden.
 
D.h., das in der Condition angegebene Reading ( [$NAME:ReadingNr1] ) muss in diesem Fall den Wert 1 angenommen haben, ansonsten wird der Befehl nicht ausgeführt.
Der Befehl wird somit nur mit einer Wahrscheinlichkeit von 1 zu ( gesetzter Wert im Attr. ) ausgeführt.


=== MSwitch_Reset_EVT_CMD1(2)_COUNT ===
Full
Bei Aktivierung dieses Attributes steht in den Readings das Reading 'EVT_CMD1_COUNT' bzw. 'EVT_CMD2_COUNT' zur Verfügung. Dieses kann in den Conditions genutzt werden, um z.B. nur bei jedem x-ten Eintreffen eines auslösenden Events einen Befehl auszuführen. Bei jedem Eintreffen eines gültigen Events werden die Zähler um 1 erhöht (für den jeweiligen Zweig).  
Es stehen alle Funktionen zur Verfügung.
Ist hier der Wert '0' eingetragen, wird der Zähler fortlaufend (endlos) erhöht. Wird ein Wert größer 0 eingetragen, wird der Zähler mit Erreichen dieses Wertes automatisch wieder auf Null gesetzt.
Toggle
Sehr vereinfachter Mode. Es stehen keine verschiedenen Zweige zur Verfügung. Hier ist das Device manuell schaltbar und wird bei jedem definierten Event 'umgeschaltet', ??? entsprechend definierte Befehle für 'cmd1' oder 'cmd2' werden ausgeführt. ???
Dummy
ACHTUNG: Funktionsänderung mit V2.61 Der Mode 'Dummy' ist ein eingeschränkter Modus. Dieser bietet die Funktionalität eines Dummys kombiniert mit der Funktionalität eines Notifys und kann somit die gerne genutzte Kombination Dummy-Notify gegen ein Device ersetzen. Der Dummy-Mode kann nur in einem neu angelegten leeren MSwitch aktiviert und auch nicht wieder verlassen werden! Sobald ein angelegtes MSwitch einmal verändert wurde (modify trigger etc.) sind Umschalt-Optionen nicht mehr verfügbar.


Mit Löschen dieses Attributes werden die entsprechenden Readings ebenfalls gelöscht.
|-
|MSwitch_Condition_Time <0<nowiki>|</nowiki>1> ||In der Grundeinstellung '0' werden für das zeitgesteuerte Schalten keine definierten Conditionen im Feld 'Trigger condition' überprüft, sondern die Schaltbefehle werden in jedem Fall ausgeführt. Mit der Einstellung '1' wird diese Überprüfung wie für Events zugeschaltet.


=== MSwitch_Safemode (0:1)===
|-
Bietet einen (gewissen) Schutz vor falschen Konfigurationen und somit entstehenden Endlosschleifen.
|MSwitch_Random_Time <HH:MM:SS-HH:MM:SS> || Bei Aktivierung wird vor jedem Ausführen eines verzögerten Befehls (Delay) eine Zufallszeit generiert, die im Rahmen der hier angegebenen Zeitspanne liegt. Auf diese Zufallszahl kann in den Delays zugegriffen werden, durch die Angabe '[random]' statt einer direkten Zeitangabe. Bei nicht gesetztem Attribut ergibt die Angabe von '[random]' immer '00:00:00'
Bei aktiviertem Attribut (1) erkennt das Modul Endlosschleifen eines Devices und beendet diese.


In diesem Fall erfolgt ein Logeintrag und das Device wird per Attribut auf 'Disabled' gesetzt.
|-
Es wird ein letztes Event generiert, auf das reagiert werden kann:
|MMSwitch_Random_Number <n> ||Bei Aktivierung dieses Attributes mit einer beliebigen ganzen Zahl, werden vom Device die zwei Readings  'RandomNr' und 'RandomNr1' und mit Werten zwischen null und n angelegt. RandomNr wird vor jedem Ausführen eines Befehls, auch für unterschiedliche Geräte in einem Durchgang, neu generiert. RandomNr1 bleibt nach der Initialisierung konstant. Wenn auf dieses Readings in einer Condition mit z.B. '[$NAME:ReadingNr1] = 1' zugegriffen wird, wird der Befehl nur ausgeführt, wenn ReadingNr1 gerade = 1 ist. Der Befehl wird somit nur mit einer Wahrscheinlichkeit von eins zu n ausgeführt.
:<code>2018-05-31 09:39:21 MSwitch <NAME> Safemode: on</code>
Im Webinterface erfolgt bei betroffenem Device ein entsprechender Hinweis.


In der Grundkonfiguration ist dieses Attribut nicht gesetzt, es empfiehlt sich aber, bei neuen (komplizierten) Devices, dieses - zumindest anfänglich - zu aktivieren.
|-
|MSwitch_Reset_EVT_CMD1(2)_COUNT ||Bei Aktivierung dieses Attributes steht in den Readings das Reading 'EVT_CMD1_COUNT' bzw. 'EVT_CMD2_COUNT' zur Verfügung. Dieses kann in den Conditions genutzt werden, um z.B. nur bei jedem x-ten Eintreffen eines auslösenden Events einen Befehl auszuführen. Bei jedem Eintreffen eines gültigen Events werden die Zähler um 1 erhöht (für den jeweiligen Zweig). Ist hier der Wert '0' eingetragen, wird der Zähler fortlaufend (endlos) erhöht. Wird ein Wert größer 0 eingetragen, wird der Zähler mit Erreichen dieses Wertes automatisch wieder auf Null gesetzt. Mit Löschen dieses Attributes werden die entsprechenden Readings ebenfalls gelöscht.


=== MSwitch_Read_Log(0:1)===
|-
Ermöglicht den Zugriff auf das Logfile als Trigger.
|MSwitch_Safemode <0<nowiki>|</nowiki>1> ||Bietet einen gewissen Schutz vor falschen Konfigurationen und dadurch entstehenden Endlosschleifen. Bei aktiviertem Attribut '1' beendet das Modul Endlosschleifen eines Devices. In diesem Fall erfolgt ein Logeintrag und das Device wird per Attribut auf 'Disabled' gesetzt. Es wird ein letztes Event generiert, auf das reagiert werden kann <code>2018-05-31 09:39:21 MSwitch <NAME> Safemode: on</code> Im Webinterface erfolgt bei betroffenem Device ein entsprechender Hinweis. In der Grundkonfiguration ist dieses Attribut nicht gesetzt. Es empfiehlt sich aber, bei neuen bzw. komplizierten Devices, dieses zumindest anfänglich zu aktivieren.
|-
|MSwitch_Read_Log<0<nowiki>|</nowiki>1> ||Ermöglicht den Zugriff auf das Logfile als Trigger.


Hier gibt es mehrere Konfigurationsmöglichkeiten:
* Bei aktiviertem Attribut enthält die Auswahl des Triggerdevices die Option 'LOGFILE'. Bei dieser Auswahl werde alle Logeinträge erkannt und in ein internes Event umgewandelt, auf das regiert werden kann.
* Bei aktiviertem Attribut enthält die Auswahl des Triggerdevices die Option'LOGFILE'. Bei dieser Auswahl werde alle Logeinträger erkannt und in ein internes Event umgewandelt, auf das regiert werden kann.
* bei aktiviertem Attribut und der Auswahl 'GLOBAL' im 'Trigger_Device' wird auf ALLE Events und alle Logeinträge reagiert.
* bei aktiviertem Attribut und der Auswahl 'GLOBAL' im 'Trigger_Device' wird auf ALLE Events und alle Logeinträge reagiert.
* bei aktiviertem Attribut und der Auswahl eines bestimmten Devices im 'Trigger_Device' wird auf alle Events  und auf alle Logeinträge des gewählten Devices reagiert. Hier ist zu beachten, dass Fhem mir keine Möglichkeit bietet, wirklich herauszufinden, welches Device denn nun einen Logeintrag generiert hat, d.h., dieses wird vom Vorhandensein des Namens im Logeintrag abhängig gemacht und MSwitch reagiert nur dann auf einen Logeintrag, wenn der Name des Devices in diesem Eintrag vorhanden ist.
* bei aktiviertem Attribut und der Auswahl eines bestimmten Devices im 'Trigger_Device' wird auf alle Events  und auf alle Logeinträge des gewählten Devices reagiert. Der im Logeintrag vorhandene Devicename ist Bedingung für die Funktion.
 
|-
=== MSwitch_Help(0:1)===
|MSwitch_Help<0<nowiki>|</nowiki>1> ||Schaltet Hilfebuttons zu den einzelnen Eingabefeldern an oder aus.
Schaltet Hilfebuttons zu den einzelnen Eingabefeldern an oder aus.


=== MSwitch_Comments(0:1)===
|-
Schaltet Kommentarfelder zu den einzelnen 'affected_devices an.
|MSwitch_Comments<0<nowiki>|</nowiki>1> ||Schaltet Kommentarfelder zu den einzelnen 'affected_devices an.


=== MSwitch_generate_Events(0:1)===
|-
Reduziert bei Einstellung '1' die vom MSwitch-Devices erzeugten Events auf ein absolutes Minimum. Insbesondere bei Verwendung von 'MSwitch_Read_Log' zu empfehlen.
|MSwitch_generate_Events<0<nowiki>|</nowiki>1> ||Reduziert bei Einstellung '1' die vom MSwitch-Devices erzeugten Events auf ein Minimum. Insbesondere bei Verwendung von 'MSwitch_Read_Log' zu empfehlen.


=== MSwitch_Startdelay ===
|-
Bestimmt die Verzögerungszeit des MSwitches nach FHEM-Start in Sekunden. In diesem Zeitraum reagiert das ??Event??(Red: ist hier "Device" gemeint?) nicht auf Events. Die Vorgabe ist hier zehn Sekunden. Diese wird auch dann angenommen, wenn das Attribut nicht gesetzt ist.
|MSwitch_Startdelay||???Bestimmt die Verzögerungszeit des MSwitches nach FHEM-Start in Sekunden. In diesem Zeitraum reagiert das Device nicht auf Events. Die Vorgabe ist hier zehn Sekunden. Diese wird auch dann angenommen, wenn das Attribut nicht gesetzt ist.??? (Hatten wir das nicht schon?)


=== MSwitch_Inforoom ===
|-
Mit diesem Attribut wird die Raumansicht eines mit dem Attribut bestimmten Raumes verändert. Dadurch sollen die wichtigsten Informationen aller MSwitch-Devices auf eine Seite dargestellt werden. Zur Nutzung sollten alle MSwitch-Devices (zusätzlich) in einen Raum sortiert werden und dieser Raum im Attribut eingestellt werden.
|MSwitch_Inforoom ||Mit diesem Attribut wird die Raumansicht eines mit dem Attribut bestimmten Raumes verändert. Dadurch sollen die wichtigsten Informationen aller MSwitch-Devices auf eine Seite dargestellt werden. Zur Nutzung sollten alle MSwitch-Devices (zusätzlich) in einen Raum sortiert werden und dieser Raum im Attribut eingestellt werden.


Wichtig: Eine Änderung dieses Attributes bewirkt immer eine Änderung dieses Attributes in ''allen'' MSwitch devices: Es muss nur in einem Device gesetzt oder gelöscht werden um alle Devices zu erfassen.
Wichtig: Eine Änderung dieses Attributes bewirkt immer eine Änderung dieses Attributes in ''allen'' MSwitch devices: Es muss nur in einem Device gesetzt oder gelöscht werden um alle Devices zu erfassen.
Zeile 485: Zeile 378:
* State des Devices
* State des Devices


== integrierte Funktionen ==
|}
 
=== Average ===
=== Tendency ===
=== Difference ===
=== INCREASE ===
 
== Tipps, Tricks, Kurzbeispiele ==
wird stetig ergänzt .
 
=== Blinken - falls nicht im Device vorhanden ===
[[Datei:MSwitch MSwitchblink.png|center|704px]]
<br clear=all>
lässt ein beliebiges Device 5 mal togglen, mit einem Intervall von 0.5 Sekunden (Blinkzeit somit 2,5 Sekunden)<br>
Die MSwitchtoggle-Funktion muss per ATTR aktiviert werden.<br>
Die Repeatfunktion ist nur im Expertmode verfügbar, auch per ATTR einstellbar.
 
=== Linearschalter ===
Umsetzung eines Linearschalters mit MSwitch.
 
Eingang: beliebiges Reading als numerischer Wert


Ausgang: wird entsprechend Linear / oder umgekehrt Linear zum Eingang geschaltet.
== Integrierte Funktionen ==


Folgend die Rawdefinition des MSwitchdevices und zweier Dummys (selbsterklärend)
{| class="wikitable sortable"
|-
! Name !! class="unsortable" | Beschreibung
|-
|Average||???
|-


Alle Devices werden im Raum Lineartest angelegt, die Dummy müssen zuerst angelegt werden.
|Difference||
* Syntax: [DIFF<wert>:<reading>] > <differenz>
* Beispiel: [DIFF2:countdown] > 0
* Reading: entspricht dem getriggerten Reading.
* Wert: gespeicherter Wert (in diesem Fall der vorletzte).
* Differenz: geforderte Differenz zwischen aktuellem und vorletztem Wert.
* Schaltung erfolg wenn diese Bedingung 'wahr' ist.
Folgende Readings werden zur Verfügung gestellt:
* DIFFERENCE (true/false) - Schaltbedingung erkannt ja/nein
* DIFFDIRECTION (up/down) - Richtung der erkannten Bedingung (steigend/fallend)
|-
|Increase||???
|-
|Tendency||
*Syntax: [TEND<wert>:<reading>] > <Mindestwert>
*Beispiel: [TEND2:countdown] > 2
*Reading: entspricht dem getriggerten Reading.
*Wert: Es wird jeweils der Durchschnitt von 2 Wertepaaren gebildet. In diesem Fall werden die letzten 4 Werte herangezogen. Paar 1 = Aktueller und letzter Wert, Paar 2 = Die 2 vorherigen Werte. Bei TEND3 werden die letzten 6 Werte zur Paarbildung genutzt.
*Mindestwert: Der Wertunterschied zwischen den Wertepaaren, der minimal erreicht sein muss, um eine Tendenz zu erkennen.


<pre>defmod linearausgang dummy
Rechenzeichen (><):
attr linearausgang room Lineartest
Dieses ist hier nicht als Rechenzeichen zu werten, sonder als Tendenz-Anzeige. ( < es wird nach fallender Tendenz gesucht / > sucht nach steigender Tendenz).
attr linearausgang setList state:slider,0,1,100
attr linearausgang webCmd state
setstate linearausgang state 57
setstate linearausgang 2018-06-06 18:06:12 state state 57</pre>


<pre>defmod lineareingang dummy
Schaltung erfolgt einmalig bei Erkennung der gesuchten Tendenz.
attr lineareingang room Lineartest
Danach erfolgt keine Schaltung mehr, solange bis eine Tendenz-Umkehr erfolgt ist.
attr lineareingang setList state:slider,0,1,15000
Erst dann erfolgt wieder eine Schaltung bei erneuter Tendenz-Umkehr in gesuchte Richtung.
attr lineareingang webCmd state
|}
setstate lineareingang 6422
setstate lineareingang 2018-06-06 18:06:12 state 6422</pre>


<pre>defmod Linearschalter MSwitch lineareingang  # linearausgang FreeCmd
== Funktions-Struktogramm ==
attr Linearschalter MSwitch_Debug 0
[[Datei:MSwitch full.svg|Struktogramm des Funktionsprinzips]]
attr Linearschalter MSwitch_Delete_Delays 1
attr Linearschalter MSwitch_Expert 0
attr Linearschalter MSwitch_Extensions 0
attr Linearschalter MSwitch_Help 0
attr Linearschalter MSwitch_Ignore_Types notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
attr Linearschalter MSwitch_Include_Devicecmds 1
attr Linearschalter MSwitch_Include_MSwitchcmds 0
attr Linearschalter MSwitch_Include_Webcmds 0
attr Linearschalter MSwitch_Inforoom MSwitch
attr Linearschalter MSwitch_Lock_Quickedit 1
attr Linearschalter MSwitch_Mode Notify
attr Linearschalter room Lineartest


setstate Linearschalter active
== Anwendungs-Beispiele ==
setstate Linearschalter 2018-06-06 18:03:50 .Device_Affected FreeCmd-AbsCmd1,FreeCmd-AbsCmd2,linearausgang-AbsCmd1
setstate Linearschalter 2018-06-06 18:04:35 .Device_Affected_Details FreeCmd-AbsCmd1,cmd,cmd,{my $eingang =ReadingsVal( "lineareingang"## "state"## 0 );;my $emin=0;;my $emax=15000;;my $amin=100;;my $amax=0;;$eingang = $emin if $eingang < $emin;;$eingang = $emax if $eingang > $emax;;my $y= (($amax-$amin)/($emax-$emin)*($eingang-$emin))+$amin;;readingsSingleUpdate( $hash## "to_set"## int ($y)## 1 );;},,delay1,delay1,000000,000000,,,0,0|FreeCmd-AbsCmd2,cmd,cmd,,,delay1,delay1,000000,000000,,,0,0|linearausgang-AbsCmd1,state,no_action,[Linearschalter:to_set],,delay1,delay1,000000,000000,,,0,0
setstate Linearschalter 2018-06-06 18:06:12 .Device_Events no_trigger
setstate Linearschalter 2018-06-04 18:24:21 .First_init done
setstate Linearschalter 2018-06-06 18:00:47 .Trigger_cmd_off no_trigger
setstate Linearschalter 2018-06-06 18:00:47 .Trigger_cmd_on *
setstate Linearschalter 2018-06-06 17:58:56 .Trigger_condition
setstate Linearschalter 2018-06-06 18:00:47 .Trigger_off no_trigger
setstate Linearschalter 2018-06-06 18:00:47 .Trigger_on no_trigger
setstate Linearschalter 2018-06-06 17:58:56 .Trigger_time
setstate Linearschalter 2018-06-04 18:24:21 .V_Check V 0.3
setstate Linearschalter 2018-06-06 18:06:12 EVENT state: 6422
setstate Linearschalter 2018-06-06 18:06:12 EVTFULL lineareingang:state: 6422
setstate Linearschalter 2018-06-06 18:06:12 EVTPART1 lineareingang
setstate Linearschalter 2018-06-06 18:06:12 EVTPART2 state
setstate Linearschalter 2018-06-06 18:06:12 EVTPART3  6422
setstate Linearschalter 2018-06-06 18:06:12 Exec_cmd set linearausgang state [Linearschalter:to_set]
setstate Linearschalter 2018-06-06 17:58:56 Trigger_device lineareingang
setstate Linearschalter 2018-06-06 18:00:47 Trigger_log off
setstate Linearschalter 2018-06-06 18:06:12 last_event state: 6422
setstate Linearschalter 2018-06-04 18:39:56 state active
setstate Linearschalter 2018-06-06 18:06:12 to_set 57</pre>


MSwitch -Configfile (bei Bedarf)
=== [[Blinken - Rechteckgenerator]] ===
<pre>#V V1.54
=== [[Blinken - Impulsgenerator mit variablem Tastgrad]] ===
#S .Device_Affected -> FreeCmd-AbsCmd1,FreeCmd-AbsCmd2,linearausgang-AbsCmd1
=== [[Schmitt-Trigger - Temperaturabhängiges Schalten]] ===
#S .Device_Affected_Details -> FreeCmd-AbsCmd1,cmd,cmd,{my $eingang =ReadingsVal( "lineareingang"## "state"## 0 )[S]my $emin=0[S]my $emax=15000[S]my $amin=100[S]my $amax=0[S]$eingang = $emin if $eingang < $emin[S]$eingang = $emax if $eingang > $emax[S]my $y= (($amax-$amin)/($emax-$emin)*($eingang-$emin))+$amin[S]readingsSingleUpdate( $hash## "to_set"## int ($y)## 1 )[S]},,delay1,delay1,000000,000000,,,0,0|FreeCmd-AbsCmd2,cmd,cmd,,,delay1,delay1,000000,000000,,,0,0|linearausgang-AbsCmd1,state,no_action,[Linearschalter.to_set],,delay1,delay1,000000,000000,,,0,0
=== [[Linearschalter]] ===
#S .Device_Events -> no_trigger
#S .First_init -> done
#S .Trigger_Whitelist -> undef
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> *
#S .Trigger_condition ->
#S .Trigger_off -> no_trigger
#S .Trigger_on -> no_trigger
#S .Trigger_time ->
#S .V_Check -> V 0.3
#S Trigger_device -> lineareingang
#S Trigger_log -> off
#S last_event -> state: 6422
#S state -> active
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A MSwitch_Include_MSwitchcmds -> 0
#A MSwitch_Debug -> 0
#A MSwitch_Help -> 0
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Extensions -> 0
#A MSwitch_Include_Webcmds -> 0
#A room -> Lineartest
#A MSwitch_Inforoom -> MSwitch
#A MSwitch_Expert -> 0
#A MSwitch_Lock_Quickedit -
</pre>


== Links ==
== Links ==
Zeile 605: Zeile 435:
* {{Link2Forum|Topic=100949|Message=944284|LinkText=Über Dummy-Schalter ein Timer (EIN/AUS) aktivieren}}
* {{Link2Forum|Topic=100949|Message=944284|LinkText=Über Dummy-Schalter ein Timer (EIN/AUS) aktivieren}}
* {{Link2Forum|Topic=103083|Message=967710|LinkText=Ladezeit von Akku ermitteln u. Steckdose entsprechend schalten}}
* {{Link2Forum|Topic=103083|Message=967710|LinkText=Ladezeit von Akku ermitteln u. Steckdose entsprechend schalten}}
* {{Link2Forum|Topic=86199|Message=990265|LinkText=Bewegungsmelder}}
* {{Link2Forum|Topic=86199|Message=974592|LinkText=Rauch und Hitzemelder steuern}}

Aktuelle Version vom 4. Oktober 2020, 19:40 Uhr


Info blue.png
Das Modul wurde vom Modulautor aus dem FHEM-SVN entfernt. Download des Moduls unter https://github.com/Byte009/Fhem-MSwitch. Support erfolgt laut github-Seite derzeit über Whatsapp.


Achtung: Das Wiki entspricht nicht mehr der aktuellen Modulversion ( V4.1 )

Hilfe zu allen Befehlen , Einstellungen etc. ist direkt über das Frontend eines MSwitch-Devices verfügbar.

Eine Aktualisierung des Wikis erfolgt in den kommenden Tagen.

MSwitch ist ein Hilfsmodul, welches das Event- und/oder zeitgesteuerte Schalten von mehreren Devices oder das Ausführen von benutzerdefinierten Befehlssequenzen erlaubt. Hauptmerkmale sind die fast vollständige und die sehr umfangreiche Konfigurierbarkeit über das Webinterface.


MSwitch
Zweck / Funktion
MSwitch
Allgemein
Typ Inoffiziell
Details
Dokumentation siehe Forum
Support (Forum) Automatisierung
Modulname 98_MSwitch.pm
Ersteller Byte09 (aus dem Forum abgemeldet)
Wichtig: sofern vorhanden, gilt im Zweifel immer die (englische) Beschreibung in der commandref!


Emblem-question-yellow.svgByte09: Die Grundidee zu MSwitch kam mir, weil ich bei der Arbeit mit FHEM für meinen Geschmack zu viele Module für die verschiedenen Aufgaben brauchte - zu allem Überfluss alle mit unterschiedlicher Syntax. Zwar ist DOIF hiervon ausgenommen (da hiermit wohl auch fast jede Aufgabe lösbar ist), aber ich konnte mich leider nicht daran gewöhnen und somit wurde jedes DOIF für mich zu einem echten Projekt. Was ich wollte war ein Modul, mit dem ich alles erledigen kann. Daher entschloss ich mich schon nach fast einem knappen Jahr FHEM-Nutzung mein eigenes Modul zu schreiben, welches diese Anforderung erfüllt. MSwitch beinhaltet die Funktionalität aller bisherigen Hilfsmodule wie z.B. Notify, Doif, Watchdog, Dummy,( ab Modulversion 2.2 auch Sequenz ) es lassen sich all deren Funktionen umsetzen.

MSwitch wird permanent - vorrangig nach meinen Bedürfnissen - weiterentwickelt, gerne nehme ich aber auch Anregungen von anderen Nutzern auf.

1-2-3-4.png



Grundsätzliche Überlegungen

Emblem-question-yellow.svgWill man mehrere Geräte als gleichzeitige Auslöser betreiben, so muss das Device GLOBAL gewählt und die entsprechenden Geräte angegeben werden (dies erzeugt höhere Systemlast und ist nur im Expert-Modus verfügbar).


1. Welches Gerät soll auslösen oder zu welcher Zeit soll eine Auslösung erfolgen?

Stark vereinfachtes Struktogramm

Im Rahmen 1 des Webinterfaces lässt sich der Trigger (Auslöser) bzw. eine Zeitabhängigkeit konfigurieren:

    • jedes Event aus dem Eventmonitor,
    • triggerunabhängige Zeiten,
    • triggerunabhängige Zufallszeiten,
    • triggerunabhängige Intervalle,
    • Kombinationen aus Triggern und Zeiten.

2. Welche Bedingungen sollen bei Auslösung erfüllt sein?

Ersten Rahmen: Wenn diese Bedingungen erfüllt sind, werden Kommandos ausgelöst. Die Bedingungen werden im zweiten Teil des Webinterfaces eingegeben. Dabei unterscheidet das Modul zwischen zwei Kommando-Kanälen (cmd1 und cmd2) und den dazugehörigen Geräten.

3. Welche Kommandos sollen ausgelöst werden?

Im vierten Rahmen des Webinterfaces werden dann die konkreten Kommandos eingegeben. Man wählt dabei aus einer Liste wie auf der Geräteseite Kommandos aus. FreeCmd erlaubt geräteunabhängige Kommandos, beispielsweise reinen Perl-Code.

4. Welche weiteren Bedingungen sollen noch gelten?

Zusätzlich pro Gerät eine oder mehrere Instanzen des vierten Rahmens:
    • ereignisgesteuerte Bedingungen,
    • zeitgesteuerte Bedingungen,
    • Verzögerungen,
    • Wiederholungen etc.

==Definition und Einrichtung ==

Emblem-question-yellow.svgAlle relevante Einstellungen werden in Readings und/oder Hashes gespeichert. Daher stehen relevanten Daten nicht in der fhem.cfg! Vielmehr finden sich diese Daten in der Datei fhem.save. Die Speicherung erfolgt durch den Befehl Fhemsave.

Das MSwitch-Modul ist ohne weitere Voraussetzungen nutzbar und wird in der aktuellen Version über FHEM Update verteilt. MSwitch kann mehrere Devices gleichzeitig schalten. Diese Schaltungen befinden sich in den zwei möglichen Zweigen entsprechend der Kommandos cmd1 und cmd2. Die einzelnen Devices jedes Zweiges können mit weiteren Schaltbedingungen versehen werden (zeit- oder ereignisgesteuert). Das define eines MSwitch Devices generiert lediglich eine 'leere Hülle':

define <name> MSwitch

Es wird ein leeres Device angelegt, das dann komplett über das Webinterface konfigurierbar ist.

Webinterface

MSwitch wird über das Webinterface eingerichtet. Es besteht aus vier Teilen. Änderungen in einem Abschnitt müssen auch dort gespeichert werden, bevor ein weiterer Teil bearbeitet wird, sonst gehen Änderungen verloren.

Emblem-question-yellow.svgattr <name> MSwitch_Help 1 führt dazu, dass im Modul selber eine sehr umfangreiche kontextsensitive Hilfe in Form von Fragezeichensymbolen angezeigt wird.


Webinterface

Rahmen 1: Trigger Device und Trigger Time

Trigger Device

Emblem-question-yellow.svgWenn das Attribut 'MSwitch_Expert' gesetzt ist kann man 'GLOBAL' auswählen. Dann werden alle von FHEM generierten Events durch das MSwitch Device weiterverarbeitet, eine weitere Begrenzung kann (und sollte) dann in einem folgenden Eingabefeld erfolgen, um die Systemlast zu reduzieren.

Trigger Device Global Whitelist

Damit kann die Liste eingehender Events weiter eingeschränkt werden. Sobald mindestens ein Eintrag vorhanden sind, werden nur noch Events der hier benannten Devices verarbeitet. Zulässig ind Devicenamen und DeviceTypen (z.B. TYPE=FS20). Mehrere Angaben sind durch Komma zu trennen.

Im unten gezeigten Beispiel wurde GLOBAL gewählt, weil nicht ein einzelnes Device, sondern eine Kombination aus zwei Geräten auslösen soll. Es werden alle Ereignisse betrachtet, wobei die Whitelist dann auf die Devices Schlafzimmer (ein Temperaturmessgerät) und Schlafzimmerfenster (ein optischer Kontakt) einschränkt.

In diesem Feld wird das Device per Dropdownfeld gewählt, dessen Events eine Aktion auslösen sollen.

Webinterface, oben

Trigger Time

Trigger time bietet die Möglichkeit einer zeitabhängigen Steuerung. Dazu wird in die "at"-Zeile ein Termin in der Form [STUNDEN:MINUTEN|TAGE] eingetragen. Die Tage werden ab Montag von 1-7 gezählt. Mehrere Zeitvorgaben können direkt hintereinander geschrieben werden. Beispiele:

  • [17:00|1][18:30|23] löst montags um 17 Uhr und dienstags sowie mittwochs um 18:30 Uhr aus.
  • [00:10*20:00-21:00] führt den Schaltbefehl von 20 Uhr bis 21 Uhr alle 10 Minuten aus.
  • [?20:00-21:00] schaltet zu einem zufälligen Zeitpunkt zwischen 20 und 21 Uhr einmalig.
  • [20:00|$we] nur am Wochenende um 20:00 wird geschaltet.

Trigger Conditions

Optionale zusätzliche Bedingungen in diesem Feld gelten nur für auslösende Device Trigger. Trigger Times haben keinen Einfluss, es sei denn, das Attribut MSwitch_Condition_Time ist gesetzt. Man kann mit AND / OR verknüpfte Bedingungen für die Auslösung in an DOIF angelehnter Syntax angeben. Leere Felder werden ignoriert. Werden Readings mit Strings wie 'on' oder 'off' abgefragt, ist statt des Gleichheitszeichens "=" der Operator "eq" zu nutzen, der String muss in Anführungszeichen "" gesetzt werden. Beispiele:

Emblem-question-yellow.svgÜberschreitet die Zeitangabe die Tagesgrenze (24:00 Uhr), so gelten die angegebenen Tage noch bis zum Ende der angegebenen Schaltzeit (beispielsweise würde dann am Mittwoch noch der Schaltvorgang erfolgen, obwohl als Tagesvorgabe Dienstag gesetzt wurde).
  • [19:10-23:00] AND [Devicename:Reading] = 10 beide Bedingungen müssen erfüllt sein.
  • [19:10-23:00] OR [Devicename:Reading] eq "on" eine der Bedingungen muss erfüllt sein.
  • [10:00-11:00|13] schaltet Montag und Mittwoch zwischen 10 Uhr und 11 Uhr.
  • [{ sunset() }-23:00] von Sonnenuntergang bis 23:00 Uhr.
  • { !$we } löst den Schaltvorgang nur Werktagen an aus.
  • { $we } löst den Schaltvorgang nur an Wochenenden, Feiertagen aus.

Es ist auf korrekte Eingabe der Leerzeichen zu achten.

Rahmen 2: Trigger Details

Webinterface, Mitte

Der Inhalt des zweiten Rahmens wird mit dem gewählten Trigger aus dem ersten Rahmen initialisiert. Events können zugeordnet werden. Im Beispiel wird cmd1 ausgelöst, wenn das Fenster offen ist. Cmd2 wird bei Temperaturunterschreitung ausgelöst.

execute

Diese vier Zeilen legen fest, welches ankommende Event welchen Befehlszweig auslösen soll. Die Event-Drop-Down-Liste enthält alle empfangenen Events dieses Devices. Fehlende Events können manuell hinzugefügt werden.

  • switch <MSwitch> on + execute 'cmd1' - MSwitch Statusänderung auf 'on'; cmd1 soll ausgeführt werden
  • switch <MSwitch> off + execute 'cmd2' - MSwitch Statusänderung auf 'off'; cmd2 soll ausgeführt werden;
  • execute 'cmd1' only - keine Statusänderung; cmd1 soll ausgeführt werden
  • execute 'cmd2' only - keine Statusänderung; cmd2 soll ausgeführt werden

Save incomming events

Alle ankommenden Events der konfigurierten Geräte werden für die Dropdownlisten gespeichert. Nach erfolgreicher Konfiguration sollte diese Option entfernt werden, um die Datenmenge zu reduzieren. Falls das Device Events während der Konfiguration nicht liefert, können sie manuell als kommagetrennte Liste hinzugefügt werden.

add event

Emblem-question-yellow.svgFalls auf 'GLOBALE' Events getriggert wird, muss das auslösende Device vorangestellt werden:

- * - alle auftretende Events des entsprechenden Device - device:reading:wert (z.B. device:state:on ) - nur für das Event "device:state:on" - device:reading:* (z.B. device:state:* ) - Events "device:state:(on,off,etc.) - device:reading:(wert1/wert2/wert3) (z.b. device:state:(left/right) - Events "device:state:left" oder "devicestate:right" etc.

Das Device kann auch hier gegen "*" ersetzt werden (*:state:on). In diesem Fall erfolgt eine Aktion auf alle Events die z.B. "state:on" enthalten, egal welches Device triggert.
  • * - alle auftretende Events des entsprechenden Device
  • reading:wert (z.B. state:on ) - nur auf das Event "state:on"
  • reading:* (z.B. state:* ) - Events "state:(on,off,etc.)
  • reading:(wert1/wert2/wert3) (z.b. state:(left/right) - Events "state:left" oder "state:right" etc.

test event

Stehen Events zur Auswahl, kann die Konfiguration getestet werden. Durch Klick wird das Event simuliert und die dafür definierte Aktion ausgelöst.

apply filter to saved events

Beschreibung folgt???

clear saved event

Es werden die nicht als Trigger wirkenden Events aus der Liste gelöscht.

Rahmen 3: Affected devices

Emblem-question-yellow.svgIn dem Auswahlfeld werden alle Devices angeboten, die eines der folgenden Kriterien erfüllen:
  1. Die Abfrage "set Device ?" liefert einen Befehlssatz
  2. Das Attribut 'webcmd' des Devices enthält Einträge
  3. Das Attribut 'MSwitch_Activate_MSwitchcmds' ist aktiviert und das Attribut 'MSwitchcmds' des betreffenden Devices enthält einen Befehlssatz
Einzige Ausnahme ist der erste Listeneintrag 'FreeCMD'. Die Auswahl dieses Eintrages bietet später die Möglichkeit Befehle auszuführen, die nicht an ein Device gebunden sind. Der Code in einem FreeCmd kann entweder reiner FHEM-Code sein ( set device on ) oder reiner Perl-Code. Wenn es sich um reinen Perl-Code handelt, ist dieser in geschweifte Klammen zu setzen { Perl-Code }.
affected devices

Auswahl der Devices, die auf die oben konfigurierten Events reagieren sollen. Um unbeabsichtigte Änderungen zu vermeiden ist die direkte Mehrfachauswahl gesperrt.

Rahmen 4: Device Actions

device_actions

Die auszuführenden Aktionen der im dritten Rahmen gewählten Geräte. Leere Felder werden ignoriert.

MSwitch cmd1/cmd2:

Emblem-question-yellow.svgIm Beispiel befindet sich ein FreeCmd, mit dem beliebige Kommandos eingetragen werden können. Im abgebildeten Beispiel ist dies sogar selbst definierter Perl-Code (die Funktion DebianMail sendet eine Mail).

Man wählt den gewünschten Befehl aus den gespeicherten verfügbaren Möglichkeiten des betreffenden Device aus.

  • Im Sonderfall FreeCmd wird der Befehl als String eingegeben.
  • Das Attribut MSwitch_Extensions ergänzt die Schaltoption 'MSwitchToggle' in der Liste, um die Toggle-Funktion bei Geräten die sie nicht von Haus aus anbieten nachzurüsten.
Emblem-question-yellow.svgJe nach Attribut-Einstellungen werden Einträge aus entsprechenden 'webcmds" oder 'MSwitchcmds' einbezogen. In Abhängigkeit des Befehls stehen unter Umständen weitere Felder oder Widgets zur Verfügung. ).


cmd1/cmd2 condition

Emblem-question-yellow.svgBei der Abfrage von Readings nach Strings (on, off, etc.) ist statt "=" "eq" zu nutzen und der String muss in "x" gesetzt werden. Es ist auf korrekte Eingabe der Leerzeichen zu achten.

Achtung: Bei Anwendung der geschweiften Klammern zur Einleitung eines Perl Ausdrucks ist unbedingt auf die Leerzeichen hinter und vor der Klammer zu achten.

Überschreitet die Zeitangabe die Tagesgrenze (24:00 Uhr), so gelten die angegebenen Tage noch bis zum Ende der angegebenen Schaltzeit (zum Beispiel würde auch am Mittwoch noch der Schaltvorgang erfolgen, wenn als Tagesvorgabe Dienstag gesetzt wurde).

Die Ausführung der Befehle kann pro gewählten Gerät analog Rahmen 1 von weiteren Bedingungen abhängig gemacht werden. Es gelten die gleichen Regeln und Beispiele wie im 'Rahmen 1 Trigger Conditions'. Sie können sinngemäß übernommen werden.

Die Variable $EVENT enthält den auslösenden Trigger. Wenn unter 'Rahmen 1 Trigger Conditions' ein Wildcard verwendet wurde, kann nun feingefiltert werden, indem das konkrete Ereignis angegeben wird.

Beispiel: [$EVENT] eq "state:on" würde den Kommandozweig nur dann ausführen, wenn der auslösende Trigger "state:on" war.

cmd1/cmd2 delay

Ein Eintrag in diesem Feld führt zur verzögerten Ausführung des Befehls nach Eintreffen des Events. Dabei kann der Befehl ohne weitere Prüfung der Bedingung ausgelöst werden. Es ist aber auch möglich, dass die Bedingung bei Ausführung erneut geprüft wird. Die Zeitangabe muss im Format hh:mm:ss vorliegen. Einzelheiten enthält auch das Funktions-Struktogramm.

Statt einer direkten Zeitangabe kann hier auch auf eine verwiesen werden, indem in der Form [NAME.reading] ein Reading eines Devices wie z.B. [dummy.state] angegeben wird.

add action

Mit diesem Button kann ein weiterer Rahmen 4 als Rahmen 4.1 für das gleiche Device angelegt werden, um z.B. einen weiteren Befehl gegebenenfalls zeitverzögert auszuführen.

delete this action

Mit diesem Button wird der gewählte Rahmen 4 für das Device gelöscht.

check condition

check

Die angegebenen 'conditions' werden in Zusammenhang mit ggf. ausgewählten Devices auf Syntax und Ergebnis geprüft. Es erfolgt eine Ausgabe des Prüfungsergebnisses.

Repeat und Repeatdelay

Die Felder 'Repeats', 'Repeatdelay in s' und 'priority' stehen zur Verfügung, wenn das Attribut MSwitch_Expert gesetzt wurde. Diese bewirken eine n-fache Wiederholung des gesetzten Befehls mit m Sekunden Verzögerung. Das Auswahlfeld 'priority' erscheint bei jedem 'affectes device'. So kann die Reihenfolge der Befehlsabarbeitung beeinflusst werden.

Erweiterte Konfiguration

Set-Befehle

Name Beschreibung
set active Setzt das MSwitch-Device in den Status 'active'.
set inactive Setzt das Device in den Status 'inactive'. Es werden keine Befehle mehr ausgeführt. Dieser Status entspricht dem Attribut 'disable', ist aber nicht mit dem roten Fragezeichen (fhem save) verbunden.
set on|off [<parameter>] Setzt das Device in den Status 'on' oder 'off'. Alle Befehle der 'on/off-Zweige' werden ausgeführt. Optional kann den Befehlen 'on' und 'off' ein weiterer Parameter mit übergeben werden. Dieser wird im Reading 'Parameter' hinterlegt und es kann sofort in 'Freecmds' oder 'Conditions' darauf zugegriffen werden.
set reload_timer Alle gesetzten Timer werden gelöscht und neu berechnet.
set change_renamed <oldname> <newname> Sollten sich Devicenammen im ausführenden Teil geändert habe (affected Devices, Conditions, etc.) so kann das MSwitch mit diesem Befehl angepasst werden, ohne alle Einstellungen neu einstellen zu müssen.
set exec_cmd1 | set exec_cmd1 ID [<ID>] Bewirkt das sofortige Ausführen des entsprechenden Befehlszweiges. Bei Angabe einer ID werden nur die Befehle mit der entsprechenden ID ausgeführt.
set MSwitch_backup Erstellt eine Backup-Datei aller MSwitch Devices unter ./fhem/MSwitch_backup.cfg. Daten dieser Datei können im Bedarfsfall für einzelne oder gleichzeitig alle MSwitch Devices wieder zurückgespielt (hergestellt) werden.
set del_delays | set exec_cmd1 ID [<ID>] Löscht alle anstehenden, verzögerten Befehle (delays).
set reset_cmd_count: 1|2 Löscht das entsprechende EVT_CMD_COUNT - Reading; entspricht damit einer Rückstellung auf '0'.
set fakeevent [<device>]:<reading>:<arg> Beispiel: <device> fakeevent state:on

Das MSwitch Device reagiert so, als wäre statt des internen "fakes-Befehls" ohne FHEM-Systembeeinflussung dieses Event tatsächlich vom triggernden Gerät generiert worden.

Der Name (<device>) muss bei GLOBALEN Triggern mit angegeben werden, sonst wird das Device automatisch gesetzt. Um z.B. einen Watchdog zu realisieren ist es eventuell nötig, dass sich das MSwitch Device mit einem bestimmten Event selber neu triggert - ggf. mit einem entsprechenden Delay Affected Device. Bei dem Einsatz dieser Möglichkeit sollte das Attribut 'MSwitch_Safemode' UNBEDINGT aktiviert sein, da 'Experimente' hier schnell in einer Endlosschleife enden können, die nur durch ein Reboot unterbrochen werden kann. Möglicherweise steht dieser Befehl zukünftig nur noch zur Verfügung, wenn Safemode aktiviert ist.

Get-Befehle

Name Beschreibung
get show_timer [<show><delete>]
Show
Zeigt alle anstehenden (gesetzten) Timer des Devices, die aus zeitabhängigen oder verzögerten Schaltbefehlen resultieren.
Delete
Löscht alle anstehenden (gesetzten) Timer des Devices, die aus zeitabhängigen oder verzögerten Schaltbefehlen resultieren. Schaltbefehle basierend auf rein zeitabhängigen Angaben werden neu berechnet und gesetzt.
get restore_MSwitch_data [<this_device>|<all_devices>]
this_device
Stellt die Daten des Devices aus der Backupdatei wieder her, sofern diese in der Backupdatei gefunden werden (gesucht wird hier nach dem Namen des Devices).
all_devices
Stellt die Daten aller MSwitch Devices wieder her, sofern diese in der Backupdatei vorhanden sind. Diese Aktion kann einige Zeit in Anspruch nehmen und wird daher im Hintergrund (nonblocking) ausgeführt. Nach Beendigung erfolgt eine Benachrichtigung.

Die Devices sind nach einem Restore funktionsfähig. Empfohlen wird ein Neustart von FHEM..

get_config Zeigt die Konfigurationsdatei des MSwitchdevices an; diese kann in dem Fenster editiert werden. Das sollte nur von erfahrenen Usern getan werden! Im Normalfall sollte das Device nur über die Weboberfläche konfiguriert werden und eine falsche Konfiguration kann hier zu einem FHEM Absturz führen.
get_support_info Öffnet ein Fenster mit einer formatierten Ansicht aller Einstellungen des Devices. Bei Supportanfragen sollte dieses immer mit geposted werden.
get_MSwitch_preconf Lädt vorkonfigurierte MSwitch-Devices. Diese Option ist nur dann vorhanden, wenn das Aktualisieren dieser vorkonfigurierten Devices im FHEM Update aktiviert ist.

Diese kann durch ein einmaliges Update erfolgen mit:

update all https://raw.githubusercontent.com/Byte009/MSwitch_Addons/master/controls_mswitchaddons.txt

Attribute

Name Beschreibung
MSwitch_Debug <0|1|2|3|4>

0 - Abgeschaltet
1 - Schaltet Felder zum testen der Conditionstrings an
2 - Alle ausgehenden Befehle werden nur simuliert und nicht ausgeführt. Der Inhalt der Protokolldatei wird direkt im Device angezeigt
3 - Es erfolgt eine Protokollierung in einer separaten Datei. Diese wird direkt im Device angezeigt.
4 - erweitertes Debugfür Entwickler mit wechselnden Funktionen

MSwitch_Expert <0|1>
  • In der Liste der möglichen Trigger erscheint das Selectfeld 'GLOBAL'. Dieses ermöglicht das Setzen eines Triggers auf alle Events und damit nicht nur auf einzelne Devices. In einem weiteren Feld kann eine weitere Selektion der triggernden Events erfolgen.
  • Die Felder 'Repeats' und 'Repeatdelay in s' stehen zur Verfügung. Dies bewirkt eine n-fache Wiederholung des gesetzten Befehls mit m Sekunden Verzögerung.
  • Das Auswahlfeld 'priority' erscheint bei jedem 'affectes device'. So kann die Reihenfolge der Befehlsabarbeitung beeinflusst werden.
MSwitch_Sequenz <Suchmuster> ???

Eine Schaltsequenz kann durch ein oder mehrere durch '/' getrennte Suchmuster angegeben werden. Die Angabe muss folgende Syntax haben:

Device1:reading1:event1 Device1:reading1:event1-2 Device1:reading1:event1-3/..../....

Beispiel: Dummy:state:on Dummy:state:off Dummy:state:on

Erkennt das Device dieses Suchmuster in den Schaltvorgängen des Devices (Dummy), wird das Reading "SEQUENCE" auf "match" gesetzt, das Reading "SEQUENCE_NUMBER" auf die Nummer der gefundenen Sequenz, wenn es mehrere Suchmuster gibt. Beide Readings können in den "Conditions" eines Schaltbefehles abgefragt werden. Eine Angabe muss in folgendem Format gemacht werden:

on/off/state/suchmuster1/suchmuster2, wobei die letzten drei Angaben optional sind.

Funktion: Bei Ausführung des Befehls wird das Gerät 'on' oder 'off' geschaltet (on/off), Voraussetzung ist, dass der 'state' dieses Gerätes auch den 'state on' oder 'off' annimmt. Sollte dieses nicht der Fall sein, so kann mit dem Feld 'state' angegeben werden, in welchem Reading der aktuelle Status vorkommt und wie dieser lautet (suchmuster1/suchmuster2). Dieses 'state' kann mehrere Angaben enthalten, das Vorkommen der Suchmuster ist aber Voraussetzung.

MSwitch_Sequence_time <Zeit in Sekunden> Maximalzeit in Sekunden, um eine Sequenz vollständig auszuführen. (Was wenn diese Zeit überschritten wird???)
MSwitch_Extensions <0|1> Es wird zusätzlich zu 'on' und 'off' die Schaltoption 'MSwitchToggle' in der Liste angeboten, um die Toggle-Funktion bei Geräten die sie nicht von Haus aus anbieten nachzurüsten.
MSwitch_Delete_Delays <0|1> Eins bewirkt das Löschen aller anstehende Delays bei dem Auftreten eines erneuten passenden Events. Bei der Option '0' bleiben bereits gesetzte Delays aus einem vorher getriggerten Event erhalten und werden ausgeführt. Empfohlene Einstellung: 1
MSwitch_Include_Devicecmds <0|1> Bewirkt die Aufnahme aller Devices die bei Abfrage mit 'set DEVICE ?' einen eigenen Befehlssatz liefern in die Auswahlliste 'Affected Devices'. Bei Option '0' werden diese Devices in der Liste nicht mehr angeboten. Empfohlene Einstellung: 1
MSwitch_Include_Webcmds <0|1> Bewirkt die Aufnahme aller Devices in die Auswahlliste 'Affected Devices', die einen eigenen Befehlssatz in dem Attribut Webcmd hinterlegt haben. Die in Webcmd hinterlegten 'Befehle' werden in den Auswahlfeldern angeboten. Bei gesetzter Option '0' werden diese Devices nicht mehr angeboten, es sei denn, sie liefern mit 'set DEVICE ?' einen eigenen Befehlssatz. Empfohlene Einstellung: 0, Einsatz nach Bedarf.
MSwitch_Activate_MSwitchcmds <0|1> Fügt jedem vorhandenen Device das Attribut 'MSwitchcmd' hinzu.
MSwitch_Include_MSwitchcmds <0|1> Bewirkt die Aufnahme aller Devices in die Auswahlliste 'Affected Devices', die einen eigenen Befehlssatz in dem Attribut MSwitchcmds hinterlegt haben. Die in MSwitchcmds hinterlegten 'Befehle' werden in den Auswahlfeldern angeboten. Bei gesetzter Option '0' werden diese Devices nicht mehr angeboten, wenn sie nicht zusätzlich einen eigenen Befehlssatz mit 'set DEVICE ?' liefern. Empfohlene Einstellung: 0, Einsatz nach Bedarf.
MSwitch_Lock_Quickedit <0|1> Voreinstellung für die Auswahlliste 'Affected Devices'. Bei der Option '1' ist diese voreingestellt gesperrt und kann nur über einen zusätzlichen Button geändert werden, um versehentliche Änderungen zu vermeiden. Die Auswahl einer Option ohne betätigte <Strg>-Taste bewirkt das Löschen aller bereits gesetzten Optionen. Empfohlene Einstellung: 1
MSwitch_Startdelay <0|10|20|30|60> MSwitch ignoriert nach einem FHEM-Neustart für die angegebene Zeit in Sekunden alle eingehenden Events um u.a. Startverzögerungen zu vermeiden. Bei nicht gesetztem Attribut gilt hier eine Zeit von 30 Sekunden. Diese sollte auch nur in Ausnahmefällen geändert werden. Empfohlene Einstellung: 30
MSwitch_Ignore_Types Beinhaltet eine durch Leerzeichen getrennte Liste von Device-Typen welche nicht geschaltet werden oder nicht geschaltet werden können. Sie werden dann in den Auswahllisten nicht dargestellt, um die Auswahllisten übersichtlich zu halten.Voreinstellung: notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul.

???Wenn statt des Devicetyps ein devspec z.B. "TYPE=watchdog" angegeben wird, ist zu beachten, dass alle Geräte in die Ignoreliste einbezogen werden, die NICHT der devspec entsprechen. Weiterhin muss die devspec in Anführungszeichen gesetzt werden!???

MSwitch_Trigger_Filter Beinhaltet eine kommagetrennte Liste von Events, die im Falle ihres Eingangs unberücksichtigt und ungespeichert bleiben. Wildcards wie '*' können angegeben werden. Empfohlene Einstellung: -
MSwitch_Wait <n in Sekunden> Bei gesetztem Attribut nimmt das MSwitch Device für den eingestellten Zeitraum keine Befehle mehr entgegen und ignoriert eingehende Events.
MSwitch_Event_Id_Distributor off)) so werden für beide Events jeweils der Zweig 'cmd1' - alle Aktionen ohne ID - ausgeführt. Durch entsprechende Einträge kann für entsprechende Events auf eine Aktion umgeleitet werden, für die eine ID definiert ist. Die Syntax lautet: state:on=>cmd1 ID 1,2 Entsprechend werden bei auslösendem Event 'state:on' nur die Aktionen aus cmd1 mit den IDs 1 und 2 ausgeführt. Mehrere Angaben sind durch new Line zu trennen. ???
MSwitch_Selftrigger_always <0|1> (dieses Attribut steht ab Modulversion 2.5 zur Verfügung)

Die Aktivierung dieses Attributes '1' bewirkt, dass alle SET Aktionen des Devices einen internen Event ohne Auswirkungen auf das FHEM-System auslösen, auf die das Device selber reagiert. Diese Option kann zusätzlich zu einem vorhandenen Trigger aktiviert werden. Auftretende auswertbare interne Events haben immer folgendes Format: MSwitch_Self:aktion:wert MSwitch_Self:pct:100 Es werden nur interne Events für set-Aktionen ausgelöst, die im Attribut setlist hinterlegt sind. Der 'wait' Befehl/Attribut hat keine wirkung.

MSwitch_Mode <Notify|Full|Toggle|Dummy> Schaltet das Modul zwischen angepassten Weboberflächen-Modi um.

Notify Das Device kann nicht manuell umgeschaltet werden. Es gibt nur die zwei ausführbaren Zweige "execute 'cmd1' commands" und "execute 'cmd2' commands". Der Status des Devices wird nicht als 'on' oder 'off' angezeigt, sondern lediglich als 'active' Dieser Mode ist ähnlich zu einem FHEM-Notify.

Full Es stehen alle Funktionen zur Verfügung. Toggle Sehr vereinfachter Mode. Es stehen keine verschiedenen Zweige zur Verfügung. Hier ist das Device manuell schaltbar und wird bei jedem definierten Event 'umgeschaltet', ??? entsprechend definierte Befehle für 'cmd1' oder 'cmd2' werden ausgeführt. ??? Dummy ACHTUNG: Funktionsänderung mit V2.61 Der Mode 'Dummy' ist ein eingeschränkter Modus. Dieser bietet die Funktionalität eines Dummys kombiniert mit der Funktionalität eines Notifys und kann somit die gerne genutzte Kombination Dummy-Notify gegen ein Device ersetzen. Der Dummy-Mode kann nur in einem neu angelegten leeren MSwitch aktiviert und auch nicht wieder verlassen werden! Sobald ein angelegtes MSwitch einmal verändert wurde (modify trigger etc.) sind Umschalt-Optionen nicht mehr verfügbar.

MSwitch_Condition_Time <0|1> In der Grundeinstellung '0' werden für das zeitgesteuerte Schalten keine definierten Conditionen im Feld 'Trigger condition' überprüft, sondern die Schaltbefehle werden in jedem Fall ausgeführt. Mit der Einstellung '1' wird diese Überprüfung wie für Events zugeschaltet.
MSwitch_Random_Time <HH:MM:SS-HH:MM:SS> Bei Aktivierung wird vor jedem Ausführen eines verzögerten Befehls (Delay) eine Zufallszeit generiert, die im Rahmen der hier angegebenen Zeitspanne liegt. Auf diese Zufallszahl kann in den Delays zugegriffen werden, durch die Angabe '[random]' statt einer direkten Zeitangabe. Bei nicht gesetztem Attribut ergibt die Angabe von '[random]' immer '00:00:00'
MMSwitch_Random_Number <n> Bei Aktivierung dieses Attributes mit einer beliebigen ganzen Zahl, werden vom Device die zwei Readings 'RandomNr' und 'RandomNr1' und mit Werten zwischen null und n angelegt. RandomNr wird vor jedem Ausführen eines Befehls, auch für unterschiedliche Geräte in einem Durchgang, neu generiert. RandomNr1 bleibt nach der Initialisierung konstant. Wenn auf dieses Readings in einer Condition mit z.B. '[$NAME:ReadingNr1] = 1' zugegriffen wird, wird der Befehl nur ausgeführt, wenn ReadingNr1 gerade = 1 ist. Der Befehl wird somit nur mit einer Wahrscheinlichkeit von eins zu n ausgeführt.
MSwitch_Reset_EVT_CMD1(2)_COUNT Bei Aktivierung dieses Attributes steht in den Readings das Reading 'EVT_CMD1_COUNT' bzw. 'EVT_CMD2_COUNT' zur Verfügung. Dieses kann in den Conditions genutzt werden, um z.B. nur bei jedem x-ten Eintreffen eines auslösenden Events einen Befehl auszuführen. Bei jedem Eintreffen eines gültigen Events werden die Zähler um 1 erhöht (für den jeweiligen Zweig). Ist hier der Wert '0' eingetragen, wird der Zähler fortlaufend (endlos) erhöht. Wird ein Wert größer 0 eingetragen, wird der Zähler mit Erreichen dieses Wertes automatisch wieder auf Null gesetzt. Mit Löschen dieses Attributes werden die entsprechenden Readings ebenfalls gelöscht.
MSwitch_Safemode <0|1> Bietet einen gewissen Schutz vor falschen Konfigurationen und dadurch entstehenden Endlosschleifen. Bei aktiviertem Attribut '1' beendet das Modul Endlosschleifen eines Devices. In diesem Fall erfolgt ein Logeintrag und das Device wird per Attribut auf 'Disabled' gesetzt. Es wird ein letztes Event generiert, auf das reagiert werden kann 2018-05-31 09:39:21 MSwitch <NAME> Safemode: on Im Webinterface erfolgt bei betroffenem Device ein entsprechender Hinweis. In der Grundkonfiguration ist dieses Attribut nicht gesetzt. Es empfiehlt sich aber, bei neuen bzw. komplizierten Devices, dieses zumindest anfänglich zu aktivieren.
MSwitch_Read_Log<0|1> Ermöglicht den Zugriff auf das Logfile als Trigger.
  • Bei aktiviertem Attribut enthält die Auswahl des Triggerdevices die Option 'LOGFILE'. Bei dieser Auswahl werde alle Logeinträge erkannt und in ein internes Event umgewandelt, auf das regiert werden kann.
  • bei aktiviertem Attribut und der Auswahl 'GLOBAL' im 'Trigger_Device' wird auf ALLE Events und alle Logeinträge reagiert.
  • bei aktiviertem Attribut und der Auswahl eines bestimmten Devices im 'Trigger_Device' wird auf alle Events und auf alle Logeinträge des gewählten Devices reagiert. Der im Logeintrag vorhandene Devicename ist Bedingung für die Funktion.
MSwitch_Help<0|1> Schaltet Hilfebuttons zu den einzelnen Eingabefeldern an oder aus.
MSwitch_Comments<0|1> Schaltet Kommentarfelder zu den einzelnen 'affected_devices an.
MSwitch_generate_Events<0|1> Reduziert bei Einstellung '1' die vom MSwitch-Devices erzeugten Events auf ein Minimum. Insbesondere bei Verwendung von 'MSwitch_Read_Log' zu empfehlen.
MSwitch_Startdelay ???Bestimmt die Verzögerungszeit des MSwitches nach FHEM-Start in Sekunden. In diesem Zeitraum reagiert das Device nicht auf Events. Die Vorgabe ist hier zehn Sekunden. Diese wird auch dann angenommen, wenn das Attribut nicht gesetzt ist.??? (Hatten wir das nicht schon?)
MSwitch_Inforoom Mit diesem Attribut wird die Raumansicht eines mit dem Attribut bestimmten Raumes verändert. Dadurch sollen die wichtigsten Informationen aller MSwitch-Devices auf eine Seite dargestellt werden. Zur Nutzung sollten alle MSwitch-Devices (zusätzlich) in einen Raum sortiert werden und dieser Raum im Attribut eingestellt werden.

Wichtig: Eine Änderung dieses Attributes bewirkt immer eine Änderung dieses Attributes in allen MSwitch devices: Es muss nur in einem Device gesetzt oder gelöscht werden um alle Devices zu erfassen.

Es werden folgende Informationen bereitgestellt:

  • Infobutton zeigt den im Device gespeicherten Textes des Attributes 'comment'
  • Device und Events, die das Device triggern
  • Zeiten, zu denen verschiedene Zweige des Devices ausgeführt werden
  • Devices, die durch das MSwitch Device geschaltet werden
  • State des Devices

Integrierte Funktionen

Name Beschreibung
Average ???
Difference
  • Syntax: [DIFF<wert>:<reading>] > <differenz>
  • Beispiel: [DIFF2:countdown] > 0
  • Reading: entspricht dem getriggerten Reading.
  • Wert: gespeicherter Wert (in diesem Fall der vorletzte).
  • Differenz: geforderte Differenz zwischen aktuellem und vorletztem Wert.
  • Schaltung erfolg wenn diese Bedingung 'wahr' ist.

Folgende Readings werden zur Verfügung gestellt:

  • DIFFERENCE (true/false) - Schaltbedingung erkannt ja/nein
  • DIFFDIRECTION (up/down) - Richtung der erkannten Bedingung (steigend/fallend)
Increase ???
Tendency
  • Syntax: [TEND<wert>:<reading>] > <Mindestwert>
  • Beispiel: [TEND2:countdown] > 2
  • Reading: entspricht dem getriggerten Reading.
  • Wert: Es wird jeweils der Durchschnitt von 2 Wertepaaren gebildet. In diesem Fall werden die letzten 4 Werte herangezogen. Paar 1 = Aktueller und letzter Wert, Paar 2 = Die 2 vorherigen Werte. Bei TEND3 werden die letzten 6 Werte zur Paarbildung genutzt.
  • Mindestwert: Der Wertunterschied zwischen den Wertepaaren, der minimal erreicht sein muss, um eine Tendenz zu erkennen.

Rechenzeichen (><): Dieses ist hier nicht als Rechenzeichen zu werten, sonder als Tendenz-Anzeige. ( < es wird nach fallender Tendenz gesucht / > sucht nach steigender Tendenz).

Schaltung erfolgt einmalig bei Erkennung der gesuchten Tendenz. Danach erfolgt keine Schaltung mehr, solange bis eine Tendenz-Umkehr erfolgt ist. Erst dann erfolgt wieder eine Schaltung bei erneuter Tendenz-Umkehr in gesuchte Richtung.

Funktions-Struktogramm

Struktogramm des Funktionsprinzips

Anwendungs-Beispiele

Blinken - Rechteckgenerator

Blinken - Impulsgenerator mit variablem Tastgrad

Schmitt-Trigger - Temperaturabhängiges Schalten

Linearschalter

Links