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

Begonnen von Byte09, 16 Dezember 2017, 09:34:28

Vorheriges Thema - Nächstes Thema

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.
LG
det.

Byte09

Zitat von: det. am 17 Dezember 2017, 22:12:41
.............................................
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
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

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

Zitat von: herrmannj am 18 Dezember 2017, 23:01:12
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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Byte09

#11
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

#12
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:
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

#13
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

#14
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


Byte09

#15
da ich im Moment davon ausgehe, das dieses Modul nicht auf Interesse stösst und ggf. am Bedarf vorbei geht , werde ich hier vorerst keine weitere Dokumentation mehr einstellen. Ich entwickel das Modul für meinen privaten Bedarf aber weiter und das angehängte File halte ich weiterhin auf dem Laufenden , falls es doch jemand nutzt .

Bei Fragen stehe ich natürlich auch zur Verfügung .

Gruss Byte09

det.

Hallo Byte09,


da ich Dein Modul nun schon einige Zeit testen durfte und inzwischen auch recht glücklich damit bin - sieh es mal nicht so negativ. Das einzige unglückliche ist m.E. die Namensgebung. Auf Absent und Present ist das kaum zu reduzieren. Was Du da geschaffen hast, ist ein "MultiSwitch" Modul, was bei einem Event, oder einer definierbaren Zeit (+Bedingungen) mehrere (auch nachträglich über webinterface einfach hinzufügbare und änderbare) Device schalten kann. Das geht alles sehr leicht und übersichtlich.
LG
det.

Byte09

hi det,

nein , ich sehe es nicht negativ und ich bleibe auch dran am modul , ist viel zu sehr hobby , als das ich nicht dranbleiben würde. Nur ist der monolog hier derzeit ja unnötig , da ja  direkt im modul über die buttons fast alles dokumentiert ist . Und mit denen die es nutzen stehe ich anderweitig in Kontakt.

dankk dir und Gruss Byte09

PS: wenn du zeit hast wäre es nett, wenn du mir nochmal wass zu der SONOS gechichte schreibst

Byte09

Hi

ich habe die Weiterentwicklung von Absent in vorliegender Form eingestellt, und die Datei im ersten Post entfernt.

Das Modul wurde mittlerweile als 'MSwitch' deutlich weiterentwickelt , ggf werde ich es in absehbarer veröffentlichen.

Gruss Byte09

andies

Mach mal, hier gibt es sicher viele Leute wie mich die stumm mitlesen und ohne Aufsehen Sachen mitnutzen. Ich habe gelernt, dass schweigen hier Zustimmung (oder, bei Fragen, ,,ich weiß auch nicht") bedeutet. Ablehnung ist das nie - die kommt eher klar, deutlich und schnell. Außerdem sind die Leute hier extrem wohlerzogen. Das meine ich ernst und das gefällt mir auch sehr. Bitte weiter so!


Gesendet von iPhone mit Tapatalk Pro
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Byte09

#20
Zitat von: andies am 06 Februar 2018, 00:10:27
Mach mal, hier gibt es sicher viele Leute wie mich die stumm mitlesen und ohne Aufsehen Sachen mitnutzen. Ich habe gelernt, dass schweigen hier Zustimmung (oder, bei Fragen, ,,ich weiß auch nicht") bedeutet. Ablehnung ist das nie - die kommt eher klar, deutlich und schnell. Außerdem sind die Leute hier extrem wohlerzogen. Das meine ich ernst und das gefällt mir auch sehr. Bitte weiter so!


Gesendet von iPhone mit Tapatalk Pro

werde ich , wird aber noch ein paar tage dauern denke ich .
Das neue Modul läuft bereits stabil , ich habe es seit 2 Wochen in meinem Aktivsystem im Einsatz und alle Notfiys , at, doif etc. ersetzt. Sieht dann recht schick und übersichtlich aus ;-) ( Bild ) .Geht nur noch um einige Schönheitkorrekturen.
Falls du das Modul bisher genutz hast , kannst du das weiterhin tun, das neue Modul enthält eine Funktion , die alte Absent_Devices übernimmt um auf das neue Modul umzustellen.

gruss Byte09


Byte09

Zitat von: andies am 06 Februar 2018, 00:10:27
Mach mal, hier gibt es sicher viele Leute wie mich die stumm mitlesen und ohne Aufsehen Sachen mitnutzen. Ich habe gelernt, dass schweigen hier Zustimmung (oder, bei Fragen, ,,ich weiß auch nicht") bedeutet. Ablehnung ist das nie - die kommt eher klar, deutlich und schnell. Außerdem sind die Leute hier extrem wohlerzogen. Das meine ich ernst und das gefällt mir auch sehr. Bitte weiter so!


Gesendet von iPhone mit Tapatalk Pro


Doku ist zwar noch nicht fertig , aber bei Interesse ist die Downloadadresse und der erste Teil der Doku hier zu finden :
https://wiki.fhem.de/wiki/Benutzer:Byte09

Gruss Byte09


misux

Krass! Bin eben auf dieses Modul gestoßen... Das finde ich klasse!

Möchte mir die Tage über PRESENCE und die Fritzbox eine Anwesenheitserkennung realisieren und dann ist das Absent Modul perfekt als Ergänzung!

Also wenn ich es nutzen will muss ich das MSWitch nehmen und nicht das Absent, richtig?

Vielen Dank für die tolle Arbeit von euch allen!

Byte09

Zitat von: misux am 21 März 2018, 15:14:49
Krass! Bin eben auf dieses Modul gestoßen... Das finde ich klasse!

Möchte mir die Tage über PRESENCE und die Fritzbox eine Anwesenheitserkennung realisieren und dann ist das Absent Modul perfekt als Ergänzung!

Also wenn ich es nutzen will muss ich das MSWitch nehmen und nicht das Absent, richtig?

Vielen Dank für die tolle Arbeit von euch allen!
Ja , Absent entwickel ich nicht weiter, MSwitch ist daraus entstanden.

Gruss Byte09



Gesendet von meinem SM-G900F mit Tapatalk


andies

Zitat von: Byte09 am 20 März 2018, 18:03:11
Downloadadresse und der erste Teil der Doku hier zu finden :
https://wiki.fhem.de/wiki/Benutzer:Byte09

Kann es sein, dass das auch die Überschrift zum Artikel ist? Wäre da nicht MSwitch besser? Ich bin aber nicht so fit im "technischen Teil" des Wiki.
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Byte09

Zitat von: andies am 23 März 2018, 22:33:26
Kann es sein, dass das auch die Überschrift zum Artikel ist? Wäre da nicht MSwitch besser? Ich bin aber nicht so fit im "technischen Teil" des Wiki.

ja, du hast natürlich recht. Ich habe den Artikel einfach unter meinem Usernamen geschrieben. Wenn er fertig ist werde ich das entsprechend ändern.

Gruss Byte09

Benni

Zitat von: Byte09 am 20 März 2018, 18:03:11
Doku ist zwar noch nicht fertig , ...

Klingt erst mal ganz interessant, dein Modul. Muss ich bei Gelegenheit mal testen. :)

Hier noch 2 Anmerkungen auf die Schnelle:

Es müsste im Wiki für die permanente Aufnahme ins update "add" heißen.

Und vielleicht solltest du auch über eine Umbenennung dieses Threads im ersten Post nachdenken.
Bspw. "Modul MSwitch (war 98_Absent.pm)" oder gleich einen neuen Thread für das neue Modul eröffnen.

gb#

Byte09

Zitat von: Benni am 24 März 2018, 07:37:43
Klingt erst mal ganz interessant, dein Modul. Muss ich bei Gelegenheit mal testen. :)

Hier noch 2 Anmerkungen auf die Schnelle:

Es müsste im Wiki für die permanente Aufnahme ins update "add" heißen.

Und vielleicht solltest du auch über eine Umbenennung dieses Threads im ersten Post nachdenken.
Bspw. "Modul MSwitch (war 98_Absent.pm)" oder gleich einen neuen Thread für das neue Modul eröffnen.

gb#

beides geändert, thx.

gruss Byte09

eisman

Zitat von: Byte09 am 09 Januar 2018, 16:33:44
da ich im Moment davon ausgehe, das dieses Modul nicht auf Interesse stösst und ggf. am Bedarf vorbei geht , werde ich hier vorerst keine weitere Dokumentation mehr einstellen. Ich entwickel das Modul für meinen privaten Bedarf aber weiter und das angehängte File halte ich weiterhin auf dem Laufenden , falls es doch jemand nutzt .

Bei Fragen stehe ich natürlich auch zur Verfügung .

Gruss Byte09

hi, laut Namen hätte ich es nicht gebraucht, das habe ich anders gelöst,
und heute habe ich festgestellt das es was anderes macht und ich damit
einige dinge anders lösen kann, dazu muss ich mir erst alles durchlesen
und dann entscheiden. Da es in FHEM viele neu dinge gibt lese ich eigentlich
nur noch den ersten Post und wenn dort steht was es kann, würde die
Entscheidung es zu nutzen, anders ausfallen. Anderes ich müsste den ganzen
Tag mit lesen verbringen und Hätte keine Zeit die schönen Dinge von FHEM
zu nutzen........

gruss

1x FHEM Debian, Homematic,ZigBee,FS20 / 1X Raspberry, ConBee / 5x ESP
1x FHEM Debian, Homematic,ZigBee         / 1X Raspberry, ConBee / 5x ESP
1x FHEM Debian,MQTT                               / 1X Raspberry, i2c,onewire,gpio
1x auf Windows 2012 Hyper-V-S

Byte09

Thema geschlossen, da ich das Modul Absent nicht weiterverfolge. Zum Thread des Nachvolgemoduls 98_MSwitch.pm geht es hier :
https://forum.fhem.de/index.php/topic,86199.0.html

gruss Byte09