Modul 98_MSwitch.pm (vorher 98_Absent.pm)

[Byte09]

Bei dem Modul MSwitch handelt es sich un ein multifunktionales Hilfsmodul, welches sowohl ereignissgesteuertes- sowie zeitgesteuertes Schalten von (mehreren) Devices in verschiedenen Zweigen erlaubt. Die Konfiguration ist in jedem Zweig separat möglich. Die Einstellungen erfolgen komplett im Webinterface. Zudem sind weitere Abhängigkeiten und Konditionen an verschiedenen Stellen einstellbar.

Somit vereint das Modul Funktionen von diversen Hilfsmodulen ( Notify,at,Watchdog,Doif, etc. )


die hier folgende Beschreibung bezieht sich noch auf das VorgängerModul 98_Absent.pm.
die Beschreibung für Modul 98_MSwitch.pm ist im Wiki zu lesen , vorläufig unter:
https://wiki.fhem.de/wiki/Benutzer:Byte09


Hi Zusammen,

Eigentlich wollte ich mir ein Modul schreiben, was in erster Linie die Steuerung des Hauses bei Abwesenheit übernimmt und möglichst realistisch die Anwesenheit simuliert - daraus resultiert der Modulname Absent. Ich musste schnell Feststellen, das das Modul dafür so viele Funktionen benöltigt , das nun ( erstmal ) ein Modul herausgekommen ist, welches Teilfunktionen von at, notify ,doif, watchdog, etc. vereint und komplett über das Webinterface konfigurierbar ist.
Somit kann das Modul einige Aktionen steuern, für die ansonsten ggf. eine Kombination aus mehreren Devices notwendig wäre.

  .......nur das eigentliche Ziel , die Anwesenheitssimulation , ist bisher zu kurz gekommen  , aber erstmal egal, ich arbeite ja noch an dem Modul.

Zum gegenwärtigen Zeitpunkt kann das Modul alle in Fhem konfigurierte Devices schalten, in Abhängigkeit von getriggerten Events eines Devices oder Zeitgesteuert , oder beide Varianten parallel . Hierbei sind jeweils weiter 'conditions' möglich.

Das Modul hat noch nicht den Anspruch Fehlerfrei zu sein , es steckt wirklich noch in den Kinderschuhen, bietet aber umfangreiche Möglichkeiten , die es aber erfordern , sich mit dem Modul auseinanderzusetzen (aber darin unterscheidet es sich ja nicht von anderen Modulen wie z.B. Doif) .

Falls besondere Anwendungsfälle vorhanden sind, die das Modul nicht ausführen kann , aber in das Konzept passsen würden , dann bitte gerne anfragen, ich schaue dann ob es umsetzbar ist . Hier muss es natürlich Verallgemeinbar sein und auch für das Modulkonzept Sinn machen ( d.H es sollten Fälle sein, die immer mal wieder , auch bei anderen Nutzern auftreten könnten ).

Einrichtung des Moduls:

Solange das Modul noch nicht in Fhem enthalten ist, muss es manuell eingebunden werden. Dazu die Datei 98_Absent.pm in den Ordner /FHEM kopieren und die erforderlichen Rechte setzen : Gruppe: dialout  Eigentümer: fhem.
Danach das Modul in Fhem entweder durch Neustart oder durch Nachladen des Moduls aktivieren.
Neustart : shutdown restart
Nachladen : reload 98_Absent.pm

Definition des Moduls/Devices :

Defininition: define [NAME] Absent

- hier sind keine weiteren Angaben nötig, sämtliche Konfigurationen erfolgen später im Webinterface

Das Modulbietet jeweils 2 Varianten für einen Schaltvorgang an, d.H einmal kann ein reines Notify abgearbeitet werden, weiterhin besteht die Möglichkeit die Befehle abarbeiten zu lassen und das Device Absent selber dabei an- oder abzuschalten. Hier werden alle verfügbaren Devices auf die reagiert werden kann in einem Dropdownfeld zur Auswahl angeboten. Zusätzlich gibt es die Möglichkeit , auf alle Events zu reagieren und die Aktion entsprechende Aktion erst in den Kommandozweigen auf bestimmte Events zu selektieren. Diese Option muss durch eine Einstellung in den DeviceAttributen aktiviert werden , dazu später mehr.

Dieses bietet diverse Möglichkeiten bei der Überwacheng von Vorgängen etc, hat aber bisher keine weiteren Unterschiede. Diese Möglichkeit wird aber für den weiteren Ausbaus des Moduls benötigt, da einige Funktionen darauf aufbauen werden.

Beim An/Ausschalten des angelegten Absent Devices werden die Kommandozweige "switch Absent off + execute 'off' commands at :" und "switch Absent on + execute 'on' commands at :" ausgeführt , auch wenn kein Trigger definiert ist. DAs ermöglicht es , durch entsprechende Definition eine ganze Kommandokette auszulösen , nur durch Schalten des einen Absent_Devices.
Die Kommandozweige "execute 'on' commands only at :" und "execute 'off' commands only at :" werden dabei nicht ausgeführt , diese können nur durch definiertes Event ( Device oder Zeit ) ausgelöst werden.

Somit entstehen 4 Kommandozweige , die einzeln belegt werden können .

Das Webinterface:

trigger device/time:

hier erfolgen alle Einstelllungen zu den auslösenden Events eines Devices oder den auslösenden Zeitschaltpunkten
Hier besteht die Möglichkeit entweder ein zu Überwachendes Device zu definieren, auf desseb Events reagiert werden soll, oder es können Zeiten für jeden Kommandozweig definiert werden, zu denen entsprechender Zweig ausgeführt werden soll. Es ist auch ein Parallelbetrieb beider Varianten möglich.
Bei der Reaktion auf Events eines Devices ist es möglich weitere Konditionen zu definieren , von denen das auslösen des Kommandozweiges abhängig ist:

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 Devicec erfolgt nur bei erfüllter Bedingung.
sunset:    [{sunset()}-23:00] Bedingungen werden mit zusätzlichen {} eingefügt

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.
Es ist auf korrekte Eingabe der Leerzeichen zu achten.

Soll nur an bestimmten Wochentagen geschaltet werden, muss eine Zeitangsbe gemacht werden und durch z.B. |135 ergänzt werden.
[10:00-11:00|13] würde den Schaltvorgang z.B nur Montag und Mitwoch zwischen 10 uhr und 11 uhr auslösen. Hierbei zählen die Wochentage von 1-7 für Montag-Sonntag.
Achtung: Überschreitet die Zeitangabe die Tagesgrenze (24.00 Uhr ), so gelten die angegebenen Tage noch bis zum ende der angegebenen Schaltzeit,
d.H. es würde auch am Mitwoch noch der schaltvorgang erfolgen, obwohl als Tagesvorgabe Dienstag gesetzt wurde.

trigger details :

Einstellungen zu dem triggernden Device

switch Absent on + execute 'on' commands:      dropdownfeld zur Auswahl des Events welches die Befehlskette 'on' auslösen soll. Zusätzlich wird das Absentdevice selbst auf 'on' gesetzt.
switch Absent off + execute 'off' commands:      siehe oben .
Diese Kommandoketten werden auch beim"manuellen" an- oder ausschalten des Absentevices ausgeführt

execute 'on' commands only:      dropdownfeld zur Auswahl des Events welches die Befehlskette 'on' auslösen soll. Das Device Absent selber bleibt unbeeinflusst.
execute 'off' commands only:   siehe oben .
Diese Kommandozweige were nur über einen Trigger ausgelöst , nicht beim manuellen an- oder abschalten des Absentdevices.

Save incomming events:   als triggernde Events bietet das Modul nur Events an, die nach Auswahl[ des triggernden Devices eingetreten sind und vom Modul gespeichert wurden. Um diese auch zu speichern, muss diese Option aktiviert sein, kann aber im Grunde - um Resourcen zu schonen - deaktiviert werden , wenn die entsprechenden Einstellungen und Events vorhanden sind.

Add Event:   Hier könne manuell Events hizugefügt werden , wenn diese noch nicht eingetreten und vom Modul gespeichert wurden. Diese können aus dem Eventmonitor übernommen werden, wobei hier nur das Reading und der Wert zu übernehmen ist: z.B  Aus "2018-01-05 09:21:01 CUL_HM HM_1CA399_Sw_02 level: 100" würde "level: 100" werden da das Device bereits über das TriggerDevice ausgewählt wurde. Hier ist auch der Einsatz von Wildcards (*) möglich, mehr dazu in de Hilfefeldern (?) im Modul selbst.


affected devices:

Dropdownfeld zur Auswahl der betreffenden Devices, die eine odere mehrere Aktion ausführen sollen. Hier ist eine Mehrfachauswahl möglich. Details zu den ausgwählten Devices werden nach dem Speichern in entsprechenden Feldern angeboten.

device actions:

hier erfolgt die Einstellung zu den einzelnen betreffenden Devices. Es werden nur Schaltbefehle angeboten, die das Device auch unterstützt.

Absent on cmd:   Dieser Kommandozweig wird ausgeführt , wenn entweder der Trigger für "switch Absent on + execute 'on' commands" oder "execute 'on' commands only" ausgelöst wird.

Absent on cmd:   Dieser Kommandozweig wird ausgeführt , wenn entweder der Trigger für "switch Absent off + execute 'off' commands" oder "execute 'off' commands only" ausgelöst wird.

In diesen Dropdownfeldern werde alle Befehle aufgeführt , die vom Gerät unterstüzt werden . Je nach Auswahl gibt es Zusatzfelder , die für weitere Angaben genutzt werden können z.B dropdown -> on-for-timer zusatzfeld -> 60 . In angebotenen Zusatzfeldern kann ein Verweis auf Readings anderer Devices genutzt werden , z.B dropdown -> on-for-timer zusatzfeld -> [dummy:state] . für den Verweis auf andere Readings muss folgendes Format genutz werden: [Device:Reading] .

on delay / off delay:   Hier könne fü die beiden Kommandozweige Verzögerungszeiten in Skunden angegeben werden. Sowohl der Befehl , als auch die Konditionsprüfung für den folgenden Befehl werden erst nach Ablauf dieser Zeit geprüft und ggf.ausgeführt .

on condition / on condition:   Angabe von Konditionen , die nach Delayzeit , aber vor Ausführung des Befehls geprüft werden.

Zeitabhängiges schalten:   [19.10-23:00] - Schaltbefehl erfolgt nur in angegebenem Zeitraum
                                 [10:00-11:00|13] würde den Schaltvorgang z.B nur Montag und Mitwoch zwischen 10 uhr und 11 uhr auslösen.
Hierbei zählen die Wochentage von 1-7 für Montag-Sonntag. Überschreitet die Zeitangabe die Tagesgrenze (24.00 Uhr ), so gelten die angegebenen Tage noch bis zum ende der angegebenen Schaltzeit , d.H. es würde auch am Mitwoch noch der Schaltvorgang erfolgen, obwohl als Tagesvorgabe Dienstag gesetzt wurde.

Readingabhängiges schalten [Devicename:Reading] =/>/< X oder [Devicename:Reading] eq "x":   Schaltbefehl erfolgt nur bei erfüllter Bedingung.
Achtung! Bei der Abfrage von Readings nach Strings ( on,off,etc. ) ist statt "=" "eq" zu nutzen und der String muss in "x" gesetzt werden!

$EVENT Variable:   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:*).

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.
Es ist auf korrekte Eingabe der Leerzeichen zu achten.

Check Condition (nur bei ATTR Debug =1):   Hier kann eine Prüfung einer angegebenen Condition erfolgen . es wird sowohl auf die Syntax , als auch auf das Ergebniss geprüft und angezeigt.

Add Action for ...:   fügt einen weiteren Befehlfür gleiches Device zu.
delete Action for ... :   löscht den gewählten Befehl.


Attribute:


Disable:   an/abschalten des Moduls
Help:   an/abschalten der HilfeButtons - Dieses sollte anfänglich auf 1 gesetzt werden , das Modul bietet dann zu den meisten Auswahlmöglichkeiten einen Hilfebutton an.
Trigger_Filter:   erklärung folgt
Debug 0,1,2:   0 -> keine Funktion , 1 -> die Check Condition Felder werden angeboten , 2 -> zusätzlich erweiterteReadings ( nur zur Fehlersuche)
Expert 0,1:   Bei Auswahl der Triggerdevices wird zusätlich GLOBAL angeboten, woduch das Modul auf jedes Event reagiert. Die Selektion erfolgt dann erst in weiteren Details.

.......  wird weiter ergänzt.

Gruss Byte09

ACHTUNG: das Modul ist nicht mehr kompatibel zu Modulversionen < V 0.1 Beta . Devices müssen neu angelegt werden .

Edit:

kommende Funktion:
zukünftige Versionen werden mehrere Optionen zur Anwesenheitssimulation anbieten.

Todo:
Einfügen einer Exit-Option in den Conditionen durch Anhang [EXIT]. Awendungsfall : wird benötigt für eine Togglesimulation ( falls i, device nicht vorhanden )  , um ein doppeltes (Hin, Her) schalten zu vermeiden , da unmittelbar nach dem Schalten die neue option erkannt und ausgeführt wird.

bekannte Fehler:

kommandozweig "off" im 2, 3 ,... Befehl desselben Devices wird nicht ausgeführt ( V0.14 )

Change:

V 1.14:
Über den Button "add Event" in den Triggerdetails kann nun "*" als Wildcard hinzugefügt werden. D.H das Modul reagiert auf jedes Event des überwachten Devices und führt entsprechenden Komandozweig aus. Eine Auswertung des Triggerevents kann dann in den "conditions" des "affected devices" erfolgen . Dort steht es als Variable "$EVENT" zur Verfügung und kann wie folgt verwendert werden: '[$EVENT] eq "state:on"' würde das Kommando nur ausführen, wenn das triggernde Event "state:on" war.  Wildcard für triggernde Events ist nicht gleichzeitig für "switch Dash_Control on + execute 'on' commands" und "switch Dash_Control off + execute 'off' commands" verwendbar.
Anwendungsbeispiel : Überwachung von mehreren Dashbuttons in einem Device ohne für jeden Button ein Notify anzulegen , pro Button verschiedene Aktionen in Abhängigkeit von z.B verschiedenen Zeiten . ( Konfiguratiion gerne auf Anfrage - condition z.B [$EVENT] eq "ac-63-be-8c-d2-8b:short" )

20.12.17 Update V 0.13 Beta - Bufix: unbeabsichtiges  Löschen gesetzter Triggerzeiten nach dem abarbeiten behoben
22.12.17 Update V 0.14 Beta - Add: Wildcardevents für Trigger
23.12.17 Update V 0.15 Beta - Bugfix: Ausführung des "off" Kommandozweiges bei 2,3.... Befehl desselben Devices
25.12.17 Update V 0.17 Beta - some Code-Changes, Fixing some bugs, change Debug function
04.01.18 Update V 0.18 Beta - some Code-Changes, add 'check condition'
07.01.18 Update V 0.19 Beta - Bugfix Time-Format ([24:00])
09.01.18 Update V 0.20 Beta - https://forum.fhem.de/index.php/topic,81130.msg745399.html#msg745399

[det.]

Lass  Dich nicht entmutigen, hier im Forum gibt es einige Module zum download im unfertigen Zustand. Nimm es als Kompliment, dass Dich jemand darauf hingewiesen hat. Das war bei den anderen offenbar nicht der Fall, wegen ,,hat niemanden interessiert"
Bei mir läuft Absent prima.

[Byte09]

.............................................
Bei mir läuft Absent prima.

Freut mich , dank dir für das Testen.

Gruss Byte09

PS: ich habe dir heute morgen die V 0.11 Beta geschickt . Fix - nicht löschbare Triggerzeiten, manuelle Eingabe Triggerevents

[andies]

Kann ich das auch haben?


Gesendet von iPad mit Tapatalk Pro

[Byte09]

ich werde den ersten post die tage überarbeiten und stelle es dann ein , vorab kannst du mir gerne deine maiadresse geben ( PM ) , ich schicke es dann.

gruss Byte09

[herrmannj]

Hi Byte09,

wenn ich "etwas" habe das ich (von der Qualität/eigener Anspruch) noch nicht "offiziell" einchecken möchte, was aber auf der anderen Seite schon getestet werden kann, dann erstelle ich manchmal ein GIT und "parke" das dort bis es "reif" ist.

Vorteil GIT: wer mag kann das GIT zur seinem FHEM update hunzufügen und kann die Voreile des FHEM Updates trotzdem geniessen. (Ich bin mir nicht sicher ob das bekannt ist). Dann kannst Du auch die cmdref machen wenn es für Dich soweit ist.

Wenn Du Details möchtest, kurze post.

vg und viel Erfolg!
Joerg

[Byte09]

Hi Byte09,

wenn ich "etwas" habe das ich (von der Qualität/eigener Anspruch) noch nicht "offiziell" einchecken möchte, was aber auf der anderen Seite schon getestet werden kann, dann erstelle ich manchmal ein GIT und "parke" das dort bis es "reif" ist.

Vorteil GIT: wer mag kann das GIT zur seinem FHEM update hunzufügen und kann die Voreile des FHEM Updates trotzdem geniessen. (Ich bin mir nicht sicher ob das bekannt ist). Dann kannst Du auch die cmdref machen wenn es für Dich soweit ist.

Wenn Du Details möchtest, kurze post.

vg und viel Erfolg!
Joerg

Hallo Joerg,

gerne würde ich es entsprechend deinem Post "parken", leider ist GIT für mich ein Buch mit 7 Siegeln und mit entsprchenden Helps in Englisch tue ich mich doch recht schwer. Einrichtung vom SVN war für mich schon ... naja ... langwierig 

hast du da ggf. ein Link , wo ich mich auf Deutsch einlesen könnte , ich werde da nicht wirklich fündig ?

Gruss Byte09

[herrmannj]

War ja nur ein Vorschlag.

Du müsstest mal googlen, gibt es bestimmt. Ansonsten ist Github in den Basics genau wie svn: checkout und commit. Kannst sogar mit svn Clients arbeiten.

[betateilchen]

Das Einbinden von git in den FHEM Update Prozess funktioniert nur bei den Anwendern, die den "normalen" Updateprozess von FHEM verwenden.

Ich parke Module während ihrer Entwicklungsphase immer in einem eigenen Ordner in ./contrib und meine FHEM-Installationen werden alle per cmdalias über svn aktualisiert.

Grundsätzlich wäre ich ja immer noch dafür, dass man dem regulären update-Prozess per Attribut mitgeben kann, dass er auch contrib aktualisieren soll.

[herrmannj]

@Betateilchen

Du kannst doch im svn/contrib genauso controls_foo.txt anlegen / hinterlegen und ins update aufnehmen.

[betateilchen]

Natürlich. Aber die Idee mit dem Attribut wäre sicher für weniger os-affine Anwender die einfachste Lösung, um auch ./contrib updaten zu können.

[Byte09]

ich habe mal versucht, mich in das github reinzufinden,  hoffnungslos für mich . Im FHEM SVN kenne ich mich zuwenig aus, um da irgendwelche ordner irgendwo anzulegen - möchte mir da auch nicht auf die Finger hauen lassen  , von daher muss ich es dabei belassen, hier den ersten Beitrag jeweils zu aktualisieren auch wenn es wohl die umständlichste Variante ist .

Gruss Byte09

PS: Update auf V 0.14 BETA im ersten Post

[Byte09]

leider hat sich in der Version V 0.18 Beta ein Fehler eingeschlichen, der dazu führt , das Fhem sich komplett verabschiedet.
Dieser Fehler tritt bei der Verwendung von Zeitgesteuerten Events auf, wenn als Angabe in den 'Conditions' 24.00 angegeben wird.

Fehlermeldung:

Code Auswählen Erweitern

Hour '24' out of range 0..23 at ./FHEM/98_Absent.pm line 2520.

Ich werde das noch heute fixen, bis zur kommenden Version diese Angabe bitte bis dahin ändern in entweder 23:59 oder 00.01.

Gruss Byte09

@ det. :  danke für die Info

[Byte09]

V 0.19 Beta

04.01.18 Fix V 0.19 Beta - Bugfix Time-Format ([24:00])


falls eine Angabe "24:xx" enthält , wird diese nun intern in "00:xx" geändert . In der Anzeige bleibt "24:xx".

gruss Byte09

[Byte09]

V 0.20 Beta  ( im ertsen Beitrag aktualisiert )

- Bugfix: nutzung des '+' Zeichens in den Bedingungen führt nicht mehr zum Crash

- $we : nutzung der globalen Variable $we ist in den Bedingungen nun möglich ( Format bitte dem Hilfe-Button im Modul entnehmen )

- Namensänderung ALLER Attribute : Zur besseren Übersichtlichkeit habe ich die Namen aller Moduleigenen Attribute geändert. Da es sich noch nicht um Funktionsrelevante Attribute handelt ist hier ein problemloses löschen der alten Attribute, und Definition der neuen Attribute möglich .

- Neue Attribute: Absent_Activate_Absentcmds, Absent_Include_Absentcmds, Absent_Include_Devicecmds, Absent_Include_Webcmds, Absent_Delete_Delays und absentcmds (global)

Absent_Activate_Absentcmds 0,1:
aktiviert das globale Attribut "absentcmds". Dieses steht danach in jedem Device zur Verfügung und wird auch bei jedem Neustart neu zur Verfügung gestellt. Die Einstellung "0" bewirkt lediglich , dass bei Fhemneustart diese Attribut von diesem Device nicht mehr zur Verfügung gestellt wird. Zum endgültigen Entfernen muss das userattr in den globalen einstellungen manuell gelöscht werden und darf auch nicht von einem weiteren Absent-Device wieder aktiviert werden.
Diese Möglichkeit habe ich eingebaut, um nicht zwangsläufig ein globales Attribut bei Nutzung des Moduls hinzufügen zu müssen ( die Listen sind ja lang genug ), und eine Nutzung des ATTR 'absentcmds" nur in Ausnahmefällen nötig ist .

Absent_Include_Devicecmds 0,1:
aktiviert in den "affected devices" alle Geräte, die auf die Systemanfrage "set DEVICE ? " einen Befehlssatz liefern. Diese Befehle werden entsprechend in den 'device actions' angeboten.

Absent_Include_Webcmds 0,1:
aktiviert in den "affected devices" alle Geräte, die auf die Systemanfrage "set DEVICE ? " keinen Befehlssatz liefern , aber einen Befehlssatz in dem Attribut 'webCms' hinterlegt haben. Diese Befehle werden entsprechend in den 'device actions' angeboten.
( kann genutzt werden , um auch dummys zu Erkennen - und Bedienen , diesebesitzen keinen eigenen 'Befehlssatz' und werden nicht erkannt, wenn hier keine Befehle hinterlegt sind. )

Absent_Include_Absentcmds 0,1:
aktiviert in den "affected devices" zusätlich alle Geräte, die in dem globalen Attribut 'absentcmds' einen Befehlssatz hinterlegt haben . Alle Befehle aus diesem Attribut werden in den 'device actions' zusätlich zu evt. vorhanden Befehlen angeboten.
( kann z.B ebenso genutzt werden , um auch dummys zu Erkennen - und Bedienen , diesebesitzen keinen eigenen 'Befehlssatz' und werden nicht erkannt, wenn hier keine Befehle hinterlegt sind. )

absentcmds:
Hinterlegung eines Befehls oder Befehlssatzen analog zu WebCmd :  z.B on:off: ......  .
einzelne Befehlesind durch : zu trennen. Die Befehle müssen von entsprechendem Device 'verstanden' werden.

Gruss Byte09