FHEM Forum

FHEM => Automatisierung => Thema gestartet von: Byte09 am 25 März 2018, 12:19:58

Titel: 98_MSwitch - Support
Beitrag von: Byte09 am 25 März 2018, 12:19:58
Bechreibung im FhemWiki:
https://wiki.fhem.de/wiki/MSwitch (https://wiki.fhem.de/wiki/MSwitch)



V2.08
Version_Datenstruktur V2.00

- neu  ATTR MSwitch_Read_Log (0/1)

diese Funktion ermöglicht den Zugriff auf das Logfile , um darauf zu reagieren , wenn das ATTR auf 1 gesetzt ist. Da dieses schnell sehr systemlastig werden kann sollte es nur in Ausnahmefällen eingesetzt werden.
Es gibt 3 Funktionsvarianten , abhängig von den Einstellungen:

1. bei gesetztem ATTR gibt es in dem Feld 'Trigger device: ' eine neue Option 'Logfile'. Wird dieses gewählt reagiert das MSwitch auf alle Einträge in dem Log , und generiert hieraus ein internes EVENT.

2. wird in dem Feld 'Trigger device: ' die Option 'GLOBAL' gewählt , reagiert MSwitch auf alle EVENTS - in Abhängigkeit der 'Whitelist' -und alle Logeinträge (bitte nur bei unvermeidlichem Bedarf einsetzen) .

3. bei gesetztem ATTR und der Auswahl eines Devices im Feld 'Trigger device: ' reagiert MSwitch auf alle EVENTS des angegebenen Devices und auf alle ( vermeintlichen ) Logeinträge dieses Devices.

'Vermeintlich' daher bedingt, das ich keine Möglichkeit habe ( zumindest habe ich bisher keine gefunden ) zu ermitteln, welches Device denn wirklich einen Logeintrag erzeugt hat ( hierfür müssste die fhem.pl angepasst werden ) . Als 'Notlösung' wird auf das Vorkommen des Namens des Devices in dem Logeintrag gefiltert und die Annahme vorausgesetzt , das bei Vorhandensein des Namens , der Eintrag von diesem Devive erzeugt wurde. Leider bedeutet das im Umkehrschluss, das ein Logeintrag ohne Vorkommen des Names nicht berücksichtigt wird !

Eine Auswertung 'eigener' Logeinträge ist nicht möglich , da dieses fast unweigerlich in einer Endlosschleife enden würde. Daher bleiben eigene Logeinträge unberücksichtigt und lösen keine Reaktion des MSwitches aus.
er noch eine Änderung machen , die ein aktivieren dieser Option generell nur in einem MSwitch pro Installation zulässt .

update auf die Testversion im GIT  ( Achtung dieses ist immer eine aktuelle Entwicklerversion ohne Anspruch auf Fehlerfreiheit ):
update all https://raw.githubusercontent.com/Byte009/FHEM-MSwitch/master/controls_mswitch.txt
eine Rückkehr von der Testversion zur SVN-Version ist in der Regl problemlos möglich . Im Einzelfall ( je nach Stand der Entwicklungsversion) kann es aber zu Kompatibilitätsproblemen kommen, insbesondere dann , wenn sich die Version_Datenstruktur unterscheidet. In diesem Fall bei Bedarf bitte kurz Anfragen.


gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 28 März 2018, 16:36:40
@det.

hi det. ,

wie schaut es denn bei dir mit den perlwarnings aus seit dem letzten Update ? Habe da einiges gemacht und hoffe das das gröbste raus ist ?

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: det. am 28 März 2018, 19:02:56
 :) ist bedeutend besser geworden, seit dem letzten update !!!
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 31 März 2018, 07:21:15
Die Modulbeschreibung ist ab sofort hier zu finden:

https://wiki.fhem.de/wiki/MSwitch.pm (https://wiki.fhem.de/wiki/MSwitch.pm)


gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 02 April 2018, 08:35:42
Für eine zukünftige Änderung ist es Notwendig geworden , die Struktur der gespeicherten Daten aller MSwitchdevices zu ändern. Dieses geschieht automatisch mit dem Update, das ich eben abgelegt habe.

Nach Fhemneustart werden entsprechende Daten geändert , die interne Prüfziffer 'V_Check' wird von V 0.2 auf V 0.3 geändert. Nach dem Update ist ein Fhemneustart zwingend erforderlich .

Backupdateien, die vor diesem Update gemacht wurden sind danach nicht mehr verwendbar, d.H es sollte dann dringend die Funktion 'backup_mswitch' ausgeführt werden.

gruss Byte09



Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 03 April 2018, 19:06:58
kommendes update:

mit kommendem Update , was ab morgen früh verfügbar sein wird , gibt es folgende Änderungen:

- deutliche entschlackung des codes
- vollständeige Überarbeitung aller "conditions" betreffender Programmteile und deren RegEx , somit sind u.A. vollständige Sunset - Angaben möglich (z.B. [{sunset(0,"17:00","20:00")}]
- zusätliche Anzeige der "Klar" Schaltzeiten bei allen "Check Condition" funktionen zur besseren Kontrolle

Nötige Änderunge der Datenstruktur wurden bereits mit dem letzten Update vorgenommen , ansonsten wird die Änderung mit diesem Update durchgeführt.

Das Modul läuft mittlerweile ohne gravierende Fehler und kann meines Erachtens daher auch von weniger erfahrenen Usern genutzt werden, da es durchaus eine Alternative für User darstellen kann , die sich mit diversen anderen ( sehr guten ) Hilfsmodulen schwer tun.

Gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 04 April 2018, 06:56:10
ich habe das angekündigte update eben im git abgelegt.

Da ich hier leider gar keine Resonanz bekomme frage ich einfach mal in die Runde ob denn mal jemand das Modul getestet hat ?

Gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: misux am 04 April 2018, 12:43:40
Ich bin fast mit meiner Konfig fertig... Danach werde ich mich mit dem Modul beschäftigen, aber vorweg eine Frage:

Die schon erstellten DOIFs/ats etc... die man Manuell erstellt hat, werden diese ins Modul übernommen? oder muss man diese im Modul neu erstellen wenn man nur auf das Modul umsteigen möchte?

Gruß und vielen Dank für deine Mühe!
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 04 April 2018, 13:03:04
Ich bin fast mit meiner Konfig fertig... Danach werde ich mich mit dem Modul beschäftigen, aber vorweg eine Frage:

Die schon erstellten DOIFs/ats etc... die man Manuell erstellt hat, werden diese ins Modul übernommen? oder muss man diese im Modul neu erstellen wenn man nur auf das Modul umsteigen möchte?

Gruß und vielen Dank für deine Mühe!

Hi Misux,

eine "übernahme" von doifs, notifys etc. ist nicht möglich. Ich hatte das mal angedacht , rudimentär war die Funktion auch schon vorhanden. Ich habe das aber mit dem Update vom 23.03.18 "remove function 'absorb'" rausgenommen da es zum ersten das Modul unnötig aufgebläht hat und ich es aus mehrfacher Hinsicht als ... naja ... , sagen wir mal "doof" befunden habe.

Doifs, Notifys, at etc. - vergleichbare Funktionen sind aber schnell eingerichtet , auch komplexere , wenn man sich mal reingefunden hat .

Nur noch zur Info, da dieine Frage ein Missverständniss vermuten lässt . MSwitch ist kein Gerüst um bestehende Doifs etc. herum , sondern ein komplett eigenständiges Modul , was alles benötigte selber mitbringt - ich habe mein System im Dezember komplett umgestellt und komme seit dem mit MSwitch 'only' aus (Bildanhang).

Gruss Byte09.

Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: misux am 04 April 2018, 13:51:22
Okay, dann kommt noch ganz schön Arbeit auf mich zu... und man sollte auf jeden Fall das DOIF was man im Modul erstellt hat löschen bzw. deaktivieren nehme ich an...
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 04 April 2018, 13:58:48
Okay, dann kommt noch ganz schön Arbeit auf mich zu... und man sollte auf jeden Fall das DOIF was man im Modul erstellt hat löschen bzw. deaktivieren nehme ich an...

richtig, sonst reagieren ggf. beide module , was eher unerwünscht ist .

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Esjay am 04 April 2018, 14:49:22
Donnerwetter, wusste gar nicht, dass es so etwas gibt. Sobald ich etwas Luft habe, werde ich mir das Ganze genauer Anschauen. Schonmal vorweg, danke für das Modul!

Grüße
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 05 April 2018, 12:08:49
update vom 05.04.18

die Ansicht im 'MSwitch Inforoom' wurde geändert :

- es wird jetzt zusätzliuch der aktuelle state des devices inc. datum und zeit dargestellt (aktualisierung bei änderung)
- falls das device 'disabled' ist wird das entsprechend dargestellt
- falls weder trigger noch schaltzeiten eingestellt sind wird das device als 'Multiswitch only' deklariert

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: mark79 am 05 April 2018, 15:52:27
Hallo,

ich habe das Modul auch mal installiert und etwas damit rumgespielt.
Ich finde die Übersicht sehr gut, besser als die ganzen DOIF und Notifys wo ich manchmal den Überblick darüber verliere.

Da ich auch einige Dashbuttons habe und damit schalte, habe ich eine Frage bzgl. des Toggles. Im Grunde suche ich nach einer Möglichkeit, das ganze zu vereinfachen...

Bisher habe ich das über ein Notify gelöst:

defmod Dash_AfriCola notify DashButton:68-37-e9-61-39-xx..short { if (ReadingsVal("WZ_TV","state","") eq "ON") { fhem("set WZ_Kodi off;; sleep 20;; set WZ_TV off") } else { fhem("set WZ_TV on") } }
Wenn der Dash Button gedrückt wird, schaut das notify erstmal ob der TV an ist, wenn ja fährt er Kodi herunter und schaltet nach 20 Sekunden den TV bzw. die Steckdosenleiste aus.
Sofern der TV aus ist, wird nur der TV bzw. die Steckdosenleiste eingeschaltet.

Wie würde das mit MSwitch funktionieren? Im Wiki habe ich gesehen, das du ein Toggle im Device (CUL_HM_HM_LC_Dim1TPBU_FM_3387C3) drin hast. Wie hast du das umgesetzt? Bei mir gibt es nur "on" und "off".

Ich habe einige Sonoff Geräte per Tasmota angebunden und WZ_TV ist eine davon.

Würde es gehen, wenn ich unter "device actions" - "on condition" und "off condition" die MAC Adresse des DashButton eintrage, um so ein Toggle umzusetzen?
Wahrscheinlich nicht, oder? :D


Grüße
Mark
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 05 April 2018, 16:05:07
Hi Mark


lege für das device "wz_tv" einfach eine zweite aktion an mit dem button "add action for wz_tv".

mit der ersten aktin schaltest du 'ON' , mit der zweiten 'OFF' ( beides im gleichen zweig - z.B 'MSwitch on cmd').

in den Conditions jeweils :

im ersten ( on condition: ) : [WZ_TV :state] eq "OFF"
im zweiten ( on condition: ) : [WZ_TV :state] eq "ON"

dann nutz er immer nur die aktion , die gerade zutrifft.
habe dir zur verdeutlichung mal ein bilder angehangen , bei denen ich ein sonoff entsprechend schalte.

die Schaltung erfolgt wenn ein Trigger den ON-Zweig auslöst .

ich hoffe es ist verständlich , ansonsten gib nochmal bescheid.

gruss Byte09


nachtrag : nochmal zwei sceens aus meiner entsprechenden Dashbutton Steuerung :
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 05 April 2018, 17:48:09
Hallo,

ich habe das Modul auch mal installiert und etwas damit rumgespielt.
Ich finde die Übersicht sehr gut, besser als die ganzen DOIF und Notifys wo ich manchmal den Überblick darüber verliere.

Da ich auch einige Dashbuttons habe und damit schalte, habe ich eine Frage bzgl. des Toggles. Im Grunde suche ich nach einer Möglichkeit, das ganze zu vereinfachen...

Bisher habe ich das über ein Notify gelöst:

defmod Dash_AfriCola notify DashButton:68-37-e9-61-39-xx..short { if (ReadingsVal("WZ_TV","state","") eq "ON") { fhem("set WZ_Kodi off;; sleep 20;; set WZ_TV off") } else { fhem("set WZ_TV on") } }
Wenn der Dash Button gedrückt wird, schaut das notify erstmal ob der TV an ist, wenn ja fährt er Kodi herunter und schaltet nach 20 Sekunden den TV bzw. die Steckdosenleiste aus.
Sofern der TV aus ist, wird nur der TV bzw. die Steckdosenleiste eingeschaltet.

Wie würde das mit MSwitch funktionieren? Im Wiki habe ich gesehen, das du ein Toggle im Device (CUL_HM_HM_LC_Dim1TPBU_FM_3387C3) drin hast. Wie hast du das umgesetzt? Bei mir gibt es nur "on" und "off".

Ich habe einige Sonoff Geräte per Tasmota angebunden und WZ_TV ist eine davon.

Würde es gehen, wenn ich unter "device actions" - "on condition" und "off condition" die MAC Adresse des DashButton eintrage, um so ein Toggle umzusetzen?
Wahrscheinlich nicht, oder? :D


Grüße
Mark

ich habe darüber nachgedacht, das 'problem' wird wohl immer wieder vorkommen mit devices die kein toggle anbieten . Ich werde dafür eine eigene Funkion integrieren , quasi eim MSwitchToggle cmd1/cmd2 .

denke bis morgen oder übermorgen habe ich das.

Gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: mark79 am 05 April 2018, 18:27:14
lege für das device "wz_tv" einfach eine zweite aktion an mit dem button "add action for wz_tv".

mit der ersten aktin schaltest du 'ON' , mit der zweiten 'OFF' ( beides im gleichen zweig - z.B 'MSwitch on cmd').

in den Conditions jeweils :

im ersten ( on condition: ) : [WZ_TV :state] eq "OFF"
im zweiten ( on condition: ) : [WZ_TV :state] eq "ON"

dann nutz er immer nur die aktion , die gerade zutrifft.
habe dir zur verdeutlichung mal ein bilder angehangen , bei denen ich ein sonoff entsprechend schalte.

die Schaltung erfolgt wenn ein Trigger den ON-Zweig auslöst .

Danke dir erstmal für die Erklärung! :)
Ich glaube ich habe es verstanden, nur warum ich die zweite Regel nicht bei "off condition" reinschreiben kann, verstehe ich noch nicht ganz.

Aber wenn ich das ausprobiere, wird mir das bestimmt klarer. Geht aber erstmal morgen, bin aktuell nicht Vorort.

Zitat von: Byte09
ich habe darüber nachgedacht, das 'problem' wird wohl immer wieder vorkommen mit devices die kein toggle anbieten . Ich werde dafür eine eigene Funkion integrieren , quasi eim MSwitchToggle cmd1/cmd2 .

denke bis morgen oder übermorgen habe ich das.

Wenn du so was einbauen würdest, was die Sache vereinfacht, wäre das schon toll! :)
So ein Toggle könnte man noch nachrüsten. Aber dann hätte man wieder ein Device mehr und je mehr das wird, umso unübersichtlich wird es, finde ich.


Grüße
Mark
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 05 April 2018, 18:40:42
das kommt darauf an , was dein trigger auslöst .

wenn er z.b den zweig 'switch wz_tv on + execute 'on' commands' auslöst , dann arbeitet das modul nur diesen zweig ab.

wenn du nu möchtest, dass ein gerät bei eintreffen dieses triggers toggelt, welches kein toggel hat , müssen auch beide kommandos ( von denen eins ausgeführt werden soll ) in diesem zweig 'device actions MSwitch on cmd:' stehen .

jetzt prüft er den state des zu schaltenden devices [device:state] eq "ON" oder "OFF" und führt den befehl aus, wenn die Bedingung zutrifft .

.. aber ich habe das MSwitchtoggel bereits zur Hälfte fertig , es wird morgen im laufe des Tages ein Update geben. Dann ist Bei der Befehlsauswahl ein zusätzliches Feld "MSwitchtoggel [cmd1] [cmd2]" vorhanden und dann sollte es passen

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 05 April 2018, 20:15:00
kommendes update:

mit kommendem Update , was ab morgen früh verfügbar sein wird , gibt es folgende Änderungen:

- neues Attribut "MSwitch_Extensions"

wenn hier "1" gesetzt wird , gibt es in den BefehlsDropdownfeldern ein zusätzliches Auswahlfeld "MSwitchtoggle".
bei Auswahl dieser Option muss in Nebenstehendem Feld die Angabe gemacht werden , zwischen welchen Befehlen er 'toggeln' soll, z.B ( ON/OFF ). Beim ausführen dieses Befehls schaltet das betreffende Device abwechseln ON und OFF mit jedem erneuten Aufruf.
Überprüft wird hier derzeit nur der Zustand des Readings 'state' . Sollte 'state' keinen der beiden Zustände 'ON/OFF' haben, so wird beim Aufruf der erste gesetzte Befehl des Auswahlfeldes (ON/OFF) gesetzt , in diesem Fall 'ON'.

( Funktion wird weiter ergänzt )

die Version läuft bei mir heute Nacht noch zur Probe , wenn ales OK ist stelle ich Sie morgen früh in das Git

Gruss Byte09

update soeben eingespielt !
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: mark79 am 06 April 2018, 20:19:20
Hi,

ich habe das Update eingespielt und ein paar Stunden damit verbracht, bis die Freundin kam...

Was funktioniert, ist ein Toggle mit einem Dash Button ("DashButton:Playboy:.short") über zwei Action Devices der eine Sonoff Steckdose (WZ_Lampe) schaltet.

Nur habe ich ein kleines Problem, das dass MSwitch State Icon, also die Glühbirne nicht mit umschaltet. Schalte ich über on/off über das Webinterface im MSwitch dann schaltet das Glühbirnen State Icon mit um.

Das neue MSwitchToggle hingegen, kriege ich irgendwie gar nicht zum laufen.
Aber das liegt wohl eher daran, das ich das Modul noch nicht so recht verstehe.

Ich habe von beiden Screenshots erstellt...

Vielleicht kannst du noch mal drüber schauen... wenn ich erstmal was lauffähiges habe, dann fällt mir das auch einfacher es zu verstehen.


Grüße
Mark
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 06 April 2018, 20:44:44
hi mark ,

kann ich dich mal anders kontakten ? whatsapp, etc. ?

gruss Byte09


das zweite bild sieht okaus , aber zwischen ON und OFF im MSwitchtoggle muss ein /  ... also ON/OFF.

oben die Triggercondition nimm mal ganz raus ( erstmal ).

setz mal das attribut MSwitch_Help auf 1 , dann bekommst du buttons, in denen die formatierung jeweils erklärt wird.
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: mark79 am 07 April 2018, 00:59:46
Hallo Byte09,

>>kann ich dich mal anders kontakten ? whatsapp, etc. ?
Klar, ich schreibe dir eine PN. :)

>>das zweite bild sieht ok aus , aber zwischen ON und OFF im MSwitchtoggle muss ein /  ... also ON/OFF.
Das war es, mit dem / funktioniert der MSwitchToggle und auch mit und ohne Triggercondition. Ich habe zwei Screenshoots angehangen.
Was noch nicht geht ist das MSwitch Icon bei OFF (es bleibt auf ON stehen).
Aber das schalten funktioniert sowohl am Dash Button und Webinterface.

Ich werde das morgen mal auf ein Device ändern, was täglich in Benutzung ist.

Grüße
Mark
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 07 April 2018, 10:20:12
guten morgen zusammen

ich habe heute morgen ein wichtiges update eingespielt , da sich die Conditionabfrage im zusammenhang mit der variable !$we falsch verhalten hat  ( was heute morgen leider zu ungewollt geöffneten rolläden geführt hat - sorry hierfür )

das update sollte so bald wie möglich gemacht werden .

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 07 April 2018, 11:01:13
...
Was noch nicht geht ist das MSwitch Icon bei OFF (es bleibt auf ON stehen).
...
Grüße
Mark

Hi Mark,

ja, das kommt daher , da du das MSwitch durch den gewählten Triggerzweig 'nur' anschaltest.

du kannst  den gesetzten trigger bei 'switch XXX on + execute 'on' commands' rausnehmen und stattdessen bei 'execute 'on' commands only' setzen , dann schaltet  das MSwitchDevice gar nicht erst in den Status 'on' , sondern es wird nur der 'on-Zweig' abgearbeitet.

alternativ musst du das device wieder abschalten:

dafür musst du das MSwitch-device selber ( du hast es wohl 'test' genannt ) bei 'affected devices :' zufügen .
unter 'device actions : ' wählst du dann bei  'MSwitch on cmd:' -> Set off  und unter 'on delay:' -> 00:00:01

damit schaltet das MSwitch device 'test' dann nach 1 sekunde wieder in den Status 'off'

ist hier nochmal erklärt : https://wiki.fhem.de/wiki/MSwitch.pm#Dashbuttons (https://wiki.fhem.de/wiki/MSwitch.pm#Dashbuttons)

gruss Byte09


Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 07 April 2018, 19:27:02
um einfacher und besser support leisten zu können gibt es seit der letzten Version die Option "get [name] config". Diese öffnet ein Fenster mit dem kompletten configfile des Devices in folgender form:

#S .Device_Affected -> Kueche_Licht-AbsCmd1,Kueche_Licht-AbsCmd2,Kueche_Licht_Motion_Ctrl-AbsCmd1
#S .Device_Affected_Details -> Kueche_Licht-AbsCmd1,on,no_action,,,nein,nein,000000,000000,off~eq~"off"~AND~off~eq~"off",|Kueche_Licht-AbsCmd2,off,no_action,,,nein,nein,000130,000000,off~eq~"off"~AND~off~eq~"off",|Kueche_Licht_Motion_Ctrl-AbsCmd1,off,no_action,,,nein,nein,000045,000000,,
#S .Device_Events -> no_trigger|state:on
#S .First_init -> done
#S .Trigger_Whitelist -> undef
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> no_trigger
#S .Trigger_condition -> ([{~sunset("-5000")~}-{~sunrise()~}]~OR~[Aussenpflanze.lux]~<~500)~AND~([Kueche_Arbeitsplatte.state]~eq~"off"~AND~[Kueche_Dunsthaube.state]~eq~"off")~~AND~[Kueche_Licht_Motion_Ctrl.state]~eq~"off"
#S .Trigger_off -> no_trigger
#S .Trigger_on -> state:on
#S .Trigger_time ->
#S .V_Check -> V 0.3
#S Exec_cmd ->
#S Trigger_device -> IT_1527xac68c
#S Trigger_log -> off
#S last_event -> Stamptime:20.0169160366058
#S state -> off
#A MSwitch_Debug -> 0
#A MSwitch_Inforoom -> MSwitch
#A room -> MSwitch
#A MSwitch_Expert -> 0
#A comment -> Licht Bewegungssteuerung
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A MSwitch_Help -> 0
#A MSwitch_Delete_Delays -> 1
#A MSwitch_Include_Webcmds -> 0
#A MSwitch_Include_MSwitchcmds -> 0
#A MSwitch_Lock_Quickedit -> 0

Ab der nächsten Version lässt sich das File in diesem Fenster auch direkt bearbeiten und komplett oder in Teilen speichern.

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 10 April 2018, 18:53:47
Update auf V1.1 verfügbar ab morgen früh.

Neu: Befehl set del_delays ( löscht alle anstehenden - verzögerten Befehle eines Devices  )
ähnlich der bisherigen funktion 'get active_timer delete', aber als Set Befehl hinterlegt und somit aus MSwitch Devices aufrufbar
Neu: Aufruf des Configfiles eines Devices
Neu: editieren und Speichern des Configfiles ist nun möglich ( hauptsächlich um einfacher support leisten zu können )

Bugfix: Restore all Devices
Bugfix: some Perl Warnings

.. intern diverse änderungen

Gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: mark79 am 17 April 2018, 23:48:21
Hallo Byte,

ich habe heute weiter mit deinem Modul gespielt und was umgesetzt.

Ist zwar was einfaches, aber ich bin begeistert. Ich konnte ein Dummy und Notify einsparen und dazu nun, mit einem Gerät (WZ_TV MSwitch) den Zustand für on/off auf verschiedene Geräte bzw. Aktionen vereinen.

Es geht darum, das ich im Wohnzimmer,
ein TV habe und ein ESP8266 mit IR Transmitter, zum ein und ausschalten des TVs (im Screenshot, FreeCmd das sendet einfach nur ein http Befehl an den ESP),
ein Raspberry mit Kodi (WZ_KODI) und
eine Sonoff Steckdose (WZ_TV_Sonoff) wo auch die Lautsprecher dran hängen.

Wenn ich den TV ausschalten will, soll zuerst der Kodi RPi sauber heruntergefahren werden und zugleich über den IR Transmitter der TV ausgeschaltet werden.
Dann wird 15 Sekunden gewartet bis der Raspberry heruntergefahren ist und wenn beides aus ist, soll die Sonoff Steckdose den Strom ausschalten.

Zum anschalten wird nur die Sonoff Steckdose eingeschaltet, der rest geht von alleine an.

Das ging mit deinem Modul echt leicht umzusetzen und das ganze ist nun auch einfacher in den DashButtons und anderen Logiken zu intregieren. Jetzt reicht ein einfach WZ_TV on/off

Nur das mit dem DashButton und dem Toggle habe ich bisher nicht hinbekommen, anstatt des DOIFs... das ist noch zu komplex für mich. Werde dich dazu aber noch mal in Whatsapp anschreiben. :)


Viele Grüße
Mark
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 30 April 2018, 18:29:28
@Bäschdler

gib in der cmd von Fhem folgendes ein:
update add https://raw.githubusercontent.com/Byte009/FHEM-MSwitch/master/controls_mswitch.txtdamit nimmt er das modul mit in das update von fhem auf.

danach bitte ein
update in der cmd und dann ein
shutdown restart
damit ist das Modul dann istalliert und wird bei bedarf upgedatet.

dann öffnest du erstmal irgend ein device , und gehst unten auf RAWdefinition . dort alles löschen, folgendes reinkopieren und speichern
defmod Schalter MSwitch # dummy3 dummy1 dummy2
attr Schalter room test

defmod dummy1 dummy
attr dummy1 room test
attr dummy1 setList on off

defmod dummy2 dummy
attr dummy2 room test
attr dummy2 setList 1 2 100 150
attr dummy2 webCmd 1:2:100:150

defmod dummy3 dummy
attr dummy3 room test
attr dummy3 webCmd on:off

damit werden 4 devices im raum test angelegt - 3 dummys und ein MSwitch device.
wenn du das hast gehst du auf das MSwitch Device Schalter und dort auf get Schalter get_config.

in dem Feld was sich öffnet bitte alles löschen , und folgendes reinkopieren:

#S .Device_Affected -> dummy3-AbsCmd1,dummy3-AbsCmd2
#S .Device_Affected_Details -> dummy3-AbsCmd1,on,no_action,,,nein,nein,000000,000000,[dummy2:state]~>~100~AND~[dummy1:state]~eq~"on",|dummy3-AbsCmd2,off,no_action,,,nein,nein,000004,000000,,
#S .Device_Events -> dummy2:state:1|*:state:*|dummy2:state:100|dummy1:state:off|dummy2:state:190|dummy2:state:2|no_trigger|dummy2:state:150|dummy1:state:on
#S .First_init -> done
#S .Trigger_Whitelist -> dummy1,dummy2
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> *:state:*
#S .Trigger_condition -> undef
#S .Trigger_off -> no_trigger
#S .Trigger_on -> no_trigger
#S .Trigger_time -> undef
#S .V_Check -> V 0.3
#S Exec_cmd -> set dummy3 off
#S Trigger_device -> all_events
#S Trigger_log -> on
#S last_event -> state:150
#S state -> off
#A MSwitch_Include_Webcmds -> 1
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A MSwitch_Lock_Quickedit -> 1
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Help -> 1
#A MSwitch_Extensions -> 0
#A room -> test
#A MSwitch_Include_MSwitchcmds -> 0
#A MSwitch_Delete_Delays -> 1
#A MSwitch_Expert -> 1
#A MSwitch_Debug -> 1

und "save changes" drücken

wenn du das hast , melde dich nochmal, dann kann es weitergehen .

gruss Byte09



Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Bäschdler am 03 Mai 2018, 14:38:42
Hallo Byte09,

das habe ich jetzt alles soweit gemacht und es hat auch alles funktioniert.
Von mir aus kann's weitergehen - ich bin schon ganz gespannt :-)

Viele Grüsse
Bäschdler
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 03 Mai 2018, 19:26:49
Hallo Byte09,

das habe ich jetzt alles soweit gemacht und es hat auch alles funktioniert.
Von mir aus kann's weitergehen - ich bin schon ganz gespannt :-)

Viele Grüsse
Bäschdler

Hi ,

im Grunde hast du damit alles was du brauchst . dummy1 und dummy2 sind die gertriggerten devises . jede stateänderung eines dieser dummys bewirkt , das der Teil 'device acctions' ausgeführt wird .
*:state:*
diese dummys musst du ersetzen , durch geräte deiner wahl , du bekommst ja alle in der Liste 'trigger device/time:' angezeigt.

wenn nun eine stateänderung eintritt wird dummy3 angeschaltet, aber nur dann wenn dummy1 > 100 und dummy2 'on' ist
[dummy2:state] > 100 AND [dummy1:state] eq "on"
dummy3 musst du ersetzen durch ein device deiner wahl ( und eine aktion deiner wahl ) - bei standartgeräten werden mögliche Befehle ja ebenfalls in der Dropdownliste angeboten. , werden ja ebenfalls alle gelistet in 'device actions :'

wenn du ein wenig experimentierst wirst du schnell dahinter kommen, das configfile kannst du ja jederzeit wieder einspielen 'get_config' -> 'save'

ansonsten ist in der configuration ja das attr 'MSwitch_Help' ja auf 1 gesetzt und somit stehen ja auch die Hilfebuttons zur verfügung '?'. ( schadet nicht , sich die Texte der belegten Felder mal anzuschauen )

wenn du dich in das modul etwas eingearbeitet hast gibt es im Grunde nur sehr wenig , was du nicht configurieren kannst .

bei konkreten Fragen und problemen gerne nachfragen .

gruss Byte09

PS : sollte dummy3 auf änderungen von dummy2 und dummy1 noch nicht reagieren , bitte einmal 'modify Trigger Device' anklicken , damit er die 'NOTIFYDEV' nach einspielen des configfiles richtig setzt

Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 06 Mai 2018, 07:53:11
Bitte unbedingt ein Update des Moduls machen , die bisherige Version hatte einen Fehler im Auswerteverhalten von Events, der sich zwar nur bei GLOBALEN Events als Trigger ( Expertmode) in Verbindung mit weiteren Conditionen in den Affected Devices bemerkbar gemacht hat , dann aber zu völligem Fehlverhalten führte.

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 06 Mai 2018, 08:30:46
@Maista  @Andies

danke für die Wiki Korrekturen

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Maista am 06 Mai 2018, 10:32:38
Moin Byte09

Gerne  :) Opera hilft  ;D

Schönen Sonntag

Gerd
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: andies am 06 Mai 2018, 10:41:20
Danke für das Modul!


Gesendet von iPhone mit Tapatalk Pro
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 07 Mai 2018, 18:25:25
mit heutigem update sind die Variablen $we und !$we in den zeitgesteuerten Triggern

    switch MSwitch on + execute 'on' commands at :
    switch MSwitch off + execute 'off' commands at :
    execute 'on' commands only at :
    execute 'off' commands only at :

verfügbar.

Syntax (neu): [20:00|$we] - Schaltet nur an Wochenenden um 20.00 Uhr
Syntax (neu): [20:00|!$we] - Schaltet nur an Wochentagen 20.00 Uhr
Syntax: [20:00|12] - Schaltet nur an Montagen und Dienstagen 20.00 Uhr
etc. ...

Feiertage etc. werden einbezogen,  wenn entsprechend holiday konfiguriert ist

Hilfetext im Webinterface wurde ergänzt, Änderung im Wiki folgt.

Gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: andies am 07 Mai 2018, 18:28:42
Ich mache da irgendwas falsch:
2018.05.07 18:27:51 1 : UPD FHEM/98_MSwitch.pm
2018.05.07 18:27:51 1 : Got 160916 bytes for FHEM/98_MSwitch.pm, expected 160077
2018.05.07 18:27:51 1 : aborting
bei
update all https://raw.githubusercontent.com/Byte009/FHEM-MSwitch/master/controls_mswitch.txt
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 07 Mai 2018, 18:32:02
Ich mache da irgendwas falsch:
2018.05.07 18:27:51 1 : UPD FHEM/98_MSwitch.pm
2018.05.07 18:27:51 1 : Got 160916 bytes for FHEM/98_MSwitch.pm, expected 160077
2018.05.07 18:27:51 1 : aborting
bei
update all https://raw.githubusercontent.com/Byte009/FHEM-MSwitch/master/controls_mswitch.txt

bitte einfach nochmal probieren , ich habe es im github gerade erst geändert , hast wohl genau dann zugegriffen ... denke ich

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: andies am 07 Mai 2018, 18:35:26
Looft.
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Bäschdler am 07 Mai 2018, 23:55:43
Hallo,

ich habe jetzt mal ein bisschen "rumgespielt", das Tool ist ja echt mächtig - aber für mich noch immer ein bisschen verwirrend...

Zum einen habe ich noch nicht verstanden wozu in dem oben genannten Beispiel (für mich) der "Schalter" da ist, die Eingangsbedingungen sind doch die dummy's 1 & 2 und das Device das damit geschaltet wird ist der dummy3.

Dann würde ich mir bei der Konfiguration der device actions irgend eine optische Trennung der (zuvor ausgewählten) devices wünschen. Im Beispiel erscheint ja dummy3 dort schon 2 mal. Ich habe jetzt noch einen weiteren dummy4 mit dazu konfiguriert, aber da dummy3 bzw. dummy4 dort zentriert vor den Bedingungen steht muss ich immer erst suchen was jetzt zum ersten dummy3, zum zweiten dummy3, zum ersten dummy4,... gehört. Das finde ich als (noch nicht so geübter in diesem Modul) ziemlich unübersichtlich. Eine Leerzeile unterhalb der Buttons "add action ..." / "delete this action ....", ein Strich, eine Zeile Sternchen oder so was würde mir da sehr viel weiterhelfen.

Gruss Bäschdler
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 08 Mai 2018, 05:25:51
Hallo,

ich habe jetzt mal ein bisschen "rumgespielt", das Tool ist ja echt mächtig - aber für mich noch immer ein bisschen verwirrend...

Zum einen habe ich noch nicht verstanden wozu in dem oben genannten Beispiel (für mich) der "Schalter" da ist, die Eingangsbedingungen sind doch die dummy's 1 & 2 und das Device das damit geschaltet wird ist der dummy3.

in der tat kann das etwas verwirrend sein und ist ggf. noch nicht optimal gelöst. das es so ist hat aber seinen hintergrund. schreibe dir heute abend etwas dazu , bin jetzt auf dem sprung zur arbeit.

z.B ich nutze ich viele MSwitch-Devices als quasi Zentralschalter , d.H ich definiere gar keine Einschaltebedingungen, sondern ich ziehe einfach x definierte Devices mit, wenn ich das MSwitch-device manuell ( über den Schalter ) an- oder ausschalte um z.B diesen Schalter dann in Alexa etc. zu integrieren und mit einem Befehl eine beliebige Reihe von Aktionen auszuführen . Dahe werden Geräte , die keine Einschalbedingungen definiert haben in der MSwitch Raumansicht als im  'Multiswitchmode' dargestellt.
 
Ein weiterer hintergund ist z.B eine Kontrollfunktion, die ich darüber realisieren kann . Siehst du , wenn du dir in dem WIKI das Konfigurationsbeispiel Dashbuttons anschaust. Da wird beim schalten das Device auf 'on' gesetz und für einen gewissen Zeitraum kein weiterer Schaltvorgang bzw. Trigger mehr akzeptiert, bis sich das Device nach einer gewissen Zeit selber wieder auf 'off' setzt.
Werde mir aber gedanken machen , ob ich das irgendwie intuitiver lösen ( und vor allen anzeigen ) kann.


Dann würde ich mir bei der Konfiguration der device actions irgend eine optische Trennung der (zuvor ausgewählten) devices wünschen. Im Beispiel erscheint ja dummy3 dort schon 2 mal. Ich habe jetzt noch einen weiteren dummy4 mit dazu konfiguriert, aber da dummy3 bzw. dummy4 dort zentriert vor den Bedingungen steht muss ich immer erst suchen was jetzt zum ersten dummy3, zum zweiten dummy3, zum ersten dummy4,... gehört. Das finde ich als (noch nicht so geübter in diesem Modul) ziemlich unübersichtlich. Eine Leerzeile unterhalb der Buttons "add action ..." / "delete this action ....", ein Strich, eine Zeile Sternchen oder so was würde mir da sehr viel weiterhelfen.

Gruss Bäschdler

einen optische trennung werde ich einbauen.

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 08 Mai 2018, 21:08:40
update verfügbar: kleinere designänderungen

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: mark79 am 08 Mai 2018, 22:15:20
Ich blick bei den Events auch noch nicht wirklich durch, besonders bei dem Dash Button Bespiel. :o Da würde ich mir mehr Bespiele wünschen, am besten erstmal einfache Dinge. :) Sonst bin ich echt zufrieden damit.
Maista, also Gerd hat mich gefragt, ob du nicht mal ein Bespiel für eine IT Fernbedienung posten könntest? :) Die z.B. ein Sonoff Device oder ähnliches über ein Event schaltet.

Ich nutze MSwitch derzeit für 3 Geräte, 2x TV und einmal meinen Xiaomi Staubsauger. Um mit einer MSwitch Aktion mehrere Geräte zeitversetzt zu schalten.
Da finde ich die Übersicht und die Einfachheit der Konfigurationsmöglichkeit sehr gut, besser als bei einem DOIF.

Z.B. TV anschalten: Bei ON, geht die Sonoff Steckdose an. Dazu schaltet ein IR ESP8266 Device den TV an und nach 10 Sekunden wechselt Kodi bei einer bestimmten Uhrzeit direkt auf den gewünschten Kanal.
Bei TV OFF: geht der TV per IR Device aus und der Raspberry mit Kodi wird heruntergefahren. Nach 30 Sekunden geht die Sonoff Steckdose aus...


Viele Grüße
Mark
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 09 Mai 2018, 05:45:30
das lange wochenende steht ja vor der tür, da werde ich die Beispiele entsprechend ergänzen .

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Bäschdler am 09 Mai 2018, 10:46:25
Hi,

jetzt habe ich mir den "Schalter" aus dem Beispiel umbenannt und andere Bedingungen ausgewählt. Damit fehlt mir jetzt das Beispiel. Also habe ich mir gedacht, ich lege es einfach nochmal so an wie beschrieben. Aber da läuft irgendwas schief: beim neu angelegten Schalte ssteht beim dummy3 unter off condition "150 > 100 AND on eq "on"" - es fehlen die Devices dazu.

Dann gleich noch eine andere Frage: ich habe das Twilight Modul und möchte daraus den azimith-Wert als Bedingung mit verknüpfen. Aber das ist ja kein Device was dadurch angelegt wird. Kann ich das dann einfach so mit ([myLocation:azimuth]<20) eintragen oder muss ich da noch was in eine (white-)liste eintragen oder sonst irgendwo?

Danke
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 09 Mai 2018, 16:07:17
Hi,

jetzt habe ich mir den "Schalter" aus dem Beispiel umbenannt und andere Bedingungen ausgewählt. Damit fehlt mir jetzt das Beispiel. Also habe ich mir gedacht, ich lege es einfach nochmal so an wie beschrieben. Aber da läuft irgendwas schief: beim neu angelegten Schalte ssteht beim dummy3 unter off condition "150 > 100 AND on eq "on"" - es fehlen die Devices dazu.

Dann gleich noch eine andere Frage: ich habe das Twilight Modul und möchte daraus den azimith-Wert als Bedingung mit verknüpfen. Aber das ist ja kein Device was dadurch angelegt wird. Kann ich das dann einfach so mit ([myLocation:azimuth]<20) eintragen oder muss ich da noch was in eine (white-)liste eintragen oder sonst irgendwo?

Danke

ja , kannst du in den conditions für 'on' oder 'off' einsetzen , allerdings ohne runde klammern:

[myLocation:azimuth] < 20
nachtrag: schädlich sind die runden Klammern aber auch nicht

du kannst auch mal deas attribut 'MSwitch_Help' auf 1 setzen, dann bekommst du entsprechende Buttons für Hilfetexte angezeigt . Da sind solche Dinge beschrieben.

zum ersten Absatz : schaue ich mir heute abend an , ob da etwas quer läuft.

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: outhouse am 10 Mai 2018, 08:25:49
Hallo

Die Möglichkeiten dieses Moduls gefallen mir sehr. Herzlichen Dank für die Bereitstellung!

Seit dem heutigen Update erhalte ich - nach erfolgter Schaltung - folgende Fehlermeldung:
PERL WARNING: Use of uninitialized value $args[0] in concatenation (.) or string at ./FHEM/98_MSwitch.pm line 558
Zusätzlich gelingt es mir aktuell nicht, eine Device anhand von Readings UND Zeit zu schalten:

Beispiel:

Das Device "Lamp" soll wie folgt einschalten wenn:

 a) der Dämmerungsschalter zwischen 16:30 und 22:00 einschaltet per sofort
 b) der Dämmerungsschalter vor 16:30 auf "on" schaltet, erst ab 16:30

Punkt a) erreiche ich mit "on condition" [16:30-22:00], wie kann ich Punkt b) umsetzen?

Gruss

Chris
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 10 Mai 2018, 08:32:13
Ich blick bei den Events auch noch nicht wirklich durch, besonders bei dem Dash Button Bespiel. :o Da würde ich mir mehr Bespiele wünschen, am besten erstmal einfache Dinge. :) Sonst bin ich echt zufrieden damit.
Maista, also Gerd hat mich gefragt, ob du nicht mal ein Bespiel für eine IT Fernbedienung posten könntest? :) Die z.B. ein Sonoff Device oder ähnliches über ein Event schaltet.


ich habe entsprechendes Beispiel im Wiki zugefügt , hoffe es ist verständlich ( bei einem eigenen Modul tritt schnell eine gewisse Betriebsblindheit auf )

https://wiki.fhem.de/wiki/MSwitch_Konfigurationsbeispiele#MSwitch_IT_to_Sonoff (https://wiki.fhem.de/wiki/MSwitch_Konfigurationsbeispiele#MSwitch_IT_to_Sonoff)

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 10 Mai 2018, 08:42:29
Hallo

Die Möglichkeiten dieses Moduls gefallen mir sehr. Herzlichen Dank für die Bereitstellung!

Seit dem heutigen Update erhalte ich - nach erfolgter Schaltung - folgende Fehlermeldung:
PERL WARNING: Use of uninitialized value $args[0] in concatenation (.) or string at ./FHEM/98_MSwitch.pm line 558
Zusätzlich gelingt es mir aktuell nicht, eine Device anhand von Readings UND Zeit zu schalten:

Beispiel:

Das Device "Lamp" soll wie folgt einschalten wenn:

 a) der Dämmerungsschalter zwischen 16:30 und 22:00 einschaltet per sofort
 b) der Dämmerungsschalter vor 16:30 auf "on" schaltet, erst ab 16:30

Punkt a) erreiche ich mit "on condition" [16:30-22:00], wie kann ich Punkt b) umsetzen?

Gruss

Chris

Hi Chris

es handelt sich erstmal "nur" um eine Warnung , somit unschön aber kein Problem. Ich schaue mir das Heute an und behebe es.

zu b:  das ist wohl konfigurierbar, aber etwas "von hinten durch die Brust ins Auge" und wahrscheinlich nur für jemanden, der das Modul aus dem FF kennt ( reduziert das ganze dann wohl auf mich  ::) ). Ich werde eine entsprechende Anpassung des Moduls vornehmen, so das dieses einfacher zu bewerkstelligen ist , wird aber wohl bis morgen dauern.

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: outhouse am 10 Mai 2018, 08:51:34
Zitat
Ich werde eine entsprechende Anpassung des Moduls vornehmen, so das dieses einfacher zu bewerkstelligen ist , wird aber wohl bis morgen dauern.

Byte09

Besten Dank für die rasche Antwort. Nur nicht hetzen mit der Anpassung des Moduls. Habe noch genug anderes zu entdecken!!

Danke
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 10 Mai 2018, 09:07:46
Byte09

Besten Dank für die rasche Antwort. Nur nicht hetzen mit der Anpassung des Moduls. Habe noch genug anderes zu entdecken!!

Danke

habe mir kurz gedanken gemacht, letztendlich fehlt dem Modul eine Funktion äquivalent zur at-funktion :

d.H wenn dieses oder jenes eintrifft ( in deinem Fall ein Event des Sensors vor 16:00 uhr, dann schalte dieses oder jenes , aber erst um 16:00 uhr.

Im grunde ähnlich eines "delays" ( Verzögerung des Befehles ) , nur so nicht Nutzbar, da du die Zeitverzögerung  die gebraucht würde um 16:00 Uhr zu erreichen nicht so einfach berechnen kannst.

d.H ich werde weitere Felder einbauen ,  (ggf. nur im" Expertmodus" ) die dann ähnlich der delays "on at" und "off at" heissen. Damit sollte es dann relativ einfach realisierbar sein.

gruss Byte09

edit: das ganze wird dann wohl wie auf dem Bild im Anhang aussehen .
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 10 Mai 2018, 11:46:59

Zusätzlich gelingt es mir aktuell nicht, eine Device anhand von Readings UND Zeit zu schalten:

Beispiel:

Das Device "Lamp" soll wie folgt einschalten wenn:

 a) der Dämmerungsschalter zwischen 16:30 und 22:00 einschaltet per sofort
 b) der Dämmerungsschalter vor 16:30 auf "on" schaltet, erst ab 16:30

Punkt a) erreiche ich mit "on condition" [16:30-22:00], wie kann ich Punkt b) umsetzen?

Gruss

Chris

mir ist gerade noch ein weiterer Lösungsweg eingefallen:

wahrscheinlich hast du ja bei  'trigger device/time:   ' einen Trigger angegeben , der die schaltung auslöst - vermutlich 'Dämmerungsschalter'.

trage in dem Feld 'execute 'on' commands only at :' zusätzlich
[16:30]ein und erweitere deine "on condition" von  [16:30-22:00] auf:
[16:30-22:00] AND [Dämmerungsschalter:state] eq "on"
eine OR Verknüpfung sollte in diesem Fall ebenfalls funktionieren

[16:30-22:00] OR [Dämmerungsschalter:state] eq "on"
Dämmerungsschalter:state muss natütlich deinem Namen und dem reading entsprechen , den der Dämmerungsschalte angenommen hat , ich nehme an das ist 'state'.

damit wird ( zusätlich zur vorhandenen Konfiguration ) um 16:30 Uhr geprüft ob es zwischen 16:30 und 22:00 uhr ist ( logisch , ist es ) und ob der state des Dämmerungsschalters 'on' ist . wenn es zutrifft wird die Schaltung ausgelöst.

sollte Funktionieren - ungeprüft .

der zusätzliche Auslöser um 16:30 ersetzt dann im Grunde nur das Event des Dämmerungschalter, das ja nicht kommt , da der Dämmerungsschalter schon zu einem vorherigen Zeitpunkt 'ausgelöst' hat .

kannst mir ja mal Bescheid geben , ob es klappt , ich möchte das jetzt bei mirt nicht alles anlegen.

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: outhouse am 10 Mai 2018, 15:52:42
Hallo Byte09

Also. Habe das Ganze mal getestet.

Die Anweisung mit OR funktioniert nicht, da ja die zweite Bedingung immer zutrifft. Heisst, sobald der Dämmerungsschalter auf on geht, schaltet das Licht ein.

Und jetzt wird es komisch. Nach dem Modifizieren von "on condition" erhalte ich bei "check condition"
If Anweisung Perl Klarzeiten:
if ((14:40 < 15:36 && 15:36 < 22:00) && ReadingsVal('WZ_Daemmerung', 'state', 'undef') eq "on"){$answer = 'true';} else {$answer = 'false';}

Bedingung ist nicht Wahr und wird nicht ausgeführt

Setze ich den Dämmerungsschalter nun manuell auf "on", schaltet das Licht ebenfalls sofort ein. "check condition" ergibt:
If Anweisung Perl Klarzeiten:
if ((14:40 < 15:36 && 15:36 < 22:00) && ReadingsVal('WZ_Daemmerung', 'state', 'undef') eq "on"){$answer = 'true';} else {$answer = 'false';}

Bedingung ist Wahr und wird ausgeführt


Schalte ich jetzt das Licht manuell aus (nicht den Dämmerungsschalter), funktioniert der (automatische) Einschaltbefehl punkt 14:40 Uhr.

Noch klappte es also nicht ganz.

Gruss Chris
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 10 Mai 2018, 16:26:53
ok , so etwas schwierig.

drück im device bitte mal "get DEVICE get_config" und poste mal das conffile hier.


mit der OR-Verknüpfung hast du natürlich recht !
 
habe es eben mal in meinem System konfiguriert, es geht mit der UND Verknüfung. Macht von der Logik auch Sinn.

'WZ_Daemmerung' habe ich dazu durch einen Dummy ersetzt , der den state 'on' oder 'off' annimmt, geschaltet wird ein weiterer dummy.

nur das wir nicht aneinander vorbei reden :

folgendes passiert nun bei mir :

wenn der 'WZ_Daemmerung' im definierten Zeitraum auf 'on' geht wird geschaltet
wenn der Zeitpunkt 16:30 erreicht ist UND der state des 'WZ_Daemmerung' bereits auf 'ON' steht wird geschaltet.
wenn der Zeitpunkt 16:30 erreicht ist UND der state des 'WZ_Daemmerung' NICHT auf 'ON' steht wird NICHT geschaltet sonder erst dann , wenn der 'WZ_Daemmerung' das nächste mal auf 'on' geht

d.H schaltet der 'WZ_Daemmerung' vor dem definierten Zeitraum auf 'on' , dann aber wieder auf 'off' wird nicht geschaltet. ( geschaltet wird nur , wenn er auch auf 'on' stehen bleibt , bzw zu dem Zeitpunkt 16:30 auf 'on' steht )

Macht ja nur so sinn, da ja davon auszugehen ist , das das Licht wieder ausreichend ist, wenn der 'WZ_Daemmerung' um 16:30 wieder auf 'off' steht 

...... es sei denn , der 'WZ_Daemmerung' sendet quasi nur einen 'on' - impuls und schaltet dann wieder auf off, egal wie das licht ist , um nach x min wieder einen Impuls zu schicken ?!?

poste mir bitte zusätlich mal ein List und ein raw-definition deines 'WZ_Daemmerung'.

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 11 Mai 2018, 08:21:28
Update auf V1.3

Im laufe des Tages werde ich das Update auf die Version 1.3 bereit stellen, diese läuft im Moment bei mir zur Probe.

Dieses Update bringt eine gravierende Änderung mit sich , die das Verhalten bei der Konfiguration von verzögerten Befehlen (delays) betrifft.

Das bisherige verhalten bei einem delays war so, das eine Prüfung der 'on' oder 'off' Conditionen (falls angegeben) nicht bei Eintreffen des triggernden Events , sondern erst nach der Verzögerung, und somit erst unmittelbar vor der Befehlsausführung stattfand.

Neues Verhalten:

die Überprüfung der Conditionen findet jetzt in jedem Fall sofort mit eintreffen des Events statt !
weiterhin wurde die Option 'delays' durch Dropdownfelder ergänzt und es können folgende Einstellungen gewählt werden:

Die zweite Prüfung kann notwendig sein , um das Verhalten eines Watchdogs bieten zu können, ist in anderen Fälen aber ggf. unerwünscht.

delay with Cond-check: +
delay without Cond-check: +
at without Cond-check:
at with Cond-check:


delay with Cond-check: +
Diese Einstellung entsprich weitestgehend der bekannten Funktion und es dürften sich keine Unterschiede zu bisherigem Verhalten ergeben.
Es findet eine erneute Prüfung der Conditionen unmittelbar vor Befehlsausführung statt

delay without Cond-check: +
Es findet keine erneute Prüfung der Conditionen vor Befehlsausführung statt

at without Cond-check:
Es erfolgt keine Angabe einer Verzögerungszeit , sondern ein konkreter Zeitpunkt zur Befehlsausführung. Ist dieser Zeitpunkt am laufenden Tag überschritten , wird dieser Zeitpunkt des kommenden Tages angenommen.
Es findet keine erneute Prüfung der Conditionen unmittelbarvor Befehlsausführung statt

at with Cond-check:
Es erfolgt keine Angabe einer Verzögerungszeit , sondern ein konkreter Zeitpunkt zur Befehlsausführung. Ist dieser Zeitpunkt am laufenden Tag überschritten , wird dieser Zeitpunkt des kommenden Tages angenommen.
Es findet eine erneute Prüfung der Conditionen unmittelbar vor Befehlsausführung statt

Bei bisherigen Konfigurationen wird automatisch diese Option gesetzt : delay with Cond-check: + .
Somit entspricht das Verhalten ohne Eingriff dem bisherigen Verhalten.
Zur sofortigen Befehlsausführung ist diese Option mit der Angabe 00:00:00 zu wählen , diese Entspricht ebenfalls den bisherigen Vorgaben.

sonstige Änderungen: Fix Perl Warnings

allgemeine Info:
da diese Frage einige male aufkam: Wenn in dem Modul bei den triggernden Events Schaltzeitpunkte gesetzt sind, werden diese bei der Ausführung von "get active timer_show" angezeigt.
Das allerdings nur dann , wenn diese Timer noch am aktuellen Tag (bis 24:00) greifen.
Alle Timer, die erst am Folgetag greifen würden werden nicht angezeigt. Bedingt ist das daher, das das Modul aus verschiedenen Gründen nur Timer bis 24:00 Uhr berechnet (eine Ausnahme bilden hier Timer aus delays oder at) . Um 00:01 erfolgt grundsätzlich eine Neuberechnung für den dann aktuellen Tag.

Eine Neuberechnung findet ebenfalls bei Modifikationen der Konfiguration, dem manuellem Löschen aller Timer und einem Modul(Fhem) Neustart statt.

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Maista am 11 Mai 2018, 14:15:35
Hallo Byte09,

danke für das Sonoff-Beispiel.
Bin nun aber erst einmal unterwegs. Hoffe das dann am Abend probieren zu können!

 ;D

Gruss Gerd
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: outhouse am 11 Mai 2018, 15:08:25
Byte09

ok , so etwas schwierig.

drück im device bitte mal "get DEVICE get_config" und poste mal das conffile hier.

Komme frühestens heute Abend dazu. Aber wie es scheint, ändert sich das mit dem V1.3 eh.....

Chris
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 11 Mai 2018, 16:27:32
Ich habe soeben die Version 1.3 im git abgelegt. Ich empfehle dringend, vor dem Update ein Backupfile der gesamten MSwitch-Konfigurationsdatei zu machen:

in irgend einem MSwitch-Device:

set DEVICE backup_Mswitch all_devices
gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: mark79 am 11 Mai 2018, 23:34:09
Hi Byte09,

danke dir auch für das IT-Beispiel. :)

Habe heute und gestern damit rumgespielt und bei mir musste ich das ein wenig abändern. Weil der Funk Taster bei mir on und off sendet und das IT Device sich dabei nicht verändert. Das funktioniert soweit, siehe Screenshot 1.
Es ist ein Smartwares Doppelwandschalter, 2-Kanal, SH5-TSW-B der einen Sonoff Lichtschalter mit ESPeasy schaltet.

Die neue 1.3 Version läuft bei mir gut. Die alten Timer mit "delay with Cond-check" wurden korrekt übernommen. :)


Wo ich aber noch Probleme habe ist z.B. das mit dem Toggle.

Ich habe ein Xiaomi Taster, der sendet ein "click" und damit würde ich z.B. ein Sonoff WZ_Lichtschalter toggeln, also on und off schalten mit nur einem Event.
Das kriege ich aber irgendwie nicht gebacken. :(  Wie müsste ich das konfigurieren?
Bei dem DashButton Beispiel blicke ich noch nicht durch.. hatte das auch mal versucht nachzustellen, aber das hat nicht geklappt. :(

Das Event für den Xiaomi Taster sieht so aus:
2018-05-11 22:33:53 XiaomiSmartHome_Device Xiaomi_Taster click
Wenn ich MSwitch on cmd: auf Set on setze geht es, aber wie schalte ich es dann aus?

Setze ich es so, dann passiert nichts:
MSwitch on cmd: Set MSwitchtoogle [WZ_Lichtschalter:0]
MSwitch off cmd: Set MSwitchtoogle [WZ_Lichtschalter:1]

So schaltet er nur ein, aber nicht off. (Off mit einem delay von 2 Sekunden.)
MSwitch on cmd: Set 1 [WZ_Lichtschalter:0]
MSwitch off cmd: Set 0 [WZ_Lichtschalter:1]

Habe davon ein einen zweiten Screenshot angehangen...


Viele Grüße
Mark
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 12 Mai 2018, 08:09:09
ich werde nachher noch ein Beispiel für SOnoff mit toggle im Wiki schreiben.



aber auf die schnelle:

da dein Taster nur ein Event gereriert musst du auch nur einen Kanal belegen, d.H setze 'execute 'off' commands only' auf 'no_trigger'.
'execute 'on' commands only' lass wie es ist.

in den 'Device Actions' setzt du:
 
'MSwitch on cmd: Set MSwitch_toggle 1/0'   .... wenn ich davon ausgehe das die Schaltbefehle 'set WZ_Lichtschalter 1' und 'set WZ_Lichschalter 0' lauten.

'MSwitch off cmd: Set no_action'
damit sollte es gehen.

was anderes , was für einen Style nutzt du ? das sieht im Feld 'Device Actions' so merkwürdig verrissen aus ?

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: mark79 am 12 Mai 2018, 12:16:11
Hallo, danke dir das funktioniert nun auch. :) Ich hatte das mit 1 0 probiert, anstatt mit 1/0.  ::)

Gibt es noch eine Möglichkeit das Icon bzw. den State vom MSwitch Device mit ändern zu lassen?
Jetzt steht immer nur "on" und das Icon wird als eingeschaltet angezeigt, auch wenn der toggle für "off" ausgeführt wurde.

Der blaue Style heißt "f18", der ist ziemlich neu bei Fhem mit dabei und ist mit Javascript.
https://forum.fhem.de/index.php?topic=82351.0


Viele Grüße
Mark
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 12 Mai 2018, 13:50:11
Hallo, danke dir das funktioniert nun auch. :) Ich hatte das mit 1 0 probiert, anstatt mit 1/0.  ::)

Gibt es noch eine Möglichkeit das Icon bzw. den State vom MSwitch Device mit ändern zu lassen?
Jetzt steht immer nur "on" und das Icon wird als eingeschaltet angezeigt, auch wenn der toggle für "off" ausgeführt wurde.

Der blaue Style heißt "f18", der ist ziemlich neu bei Fhem mit dabei und ist mit Javascript.
https://forum.fhem.de/index.php?topic=82351.0


Viele Grüße
Mark

Hi Mark,

im Grunde sollte diese Funktion im reinen Notifymode betrieben werden , d.H den Trigger nur in den feldern 'execute 'on' commands only' oder 'execute 'off' commands only' gesetzt wird, somit würde sich das Icon des MSwitch devices gar nicht verändern. Leider habe ich einen ziemlich ätzenden Bug reingearbeitet ( auf deinen Post hin gefunden ) , der dafür sorgt, das das Togglen gar nicht geht , wenn du den Trigger in geanu diesen Feldern definierst , sondern nur in 'switch All_Off_Dev on + execute 'on' commands' bzw. 'switch All_Off_Dev on + execute 'off' commands'. Ich nehme an das du genau das gemacht hast , sonst würde es gar nicht gehen.

ich werde mich heute Nachmittag mit diesem Fehler beschaäftigen und ein Update einstellen , danach mehr dazu .

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: mark79 am 12 Mai 2018, 17:51:45
Hallo Byte,

das ist auch eher nur ein kosmetisches Problem. :) Aber vielleicht kommt das irgendwann mal später. :D
Das man z.B. bei einem affected devices anhaken kann, das sich der state vom MSwitch Device mit ändern soll, wenn das affected devices geschaltet wird.

Den Bug kann ich bestätigen, mit on + execute gehts:
switch <test> on + execute 'on' commands
Und nur bei execute , schaltet er nur aus, aber nicht mehr ein.
execute 'on' commands only
Aber zuvor lag der Fehler bei mir, das ich es nicht mit dem Schrägstrich eingerichtet habe, sondern nur versucht habe mit "1 0" und "1:0"...

Werde nun mal weiter testen.. vielen Dank dir für die Hilfe!


Viele Grüße
Mark
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 12 Mai 2018, 18:15:27
habe eben das Update v1.31 eingespielt Ich hoffe der Bug ist damit behoben.

das Wikibeispiel kommt daher heute leider zu kurz, mache ich morgen  :(

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 13 Mai 2018, 12:27:50
Hallo Byte,

das ist auch eher nur ein kosmetisches Problem. :) Aber vielleicht kommt das irgendwann mal später. :D
Das man z.B. bei einem affected devices anhaken kann, das sich der state vom MSwitch Device mit ändern soll, wenn das affected devices geschaltet wird.
...........


in der nächsten Version wird es eine Lösung für das Problem geben .

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm v1.4
Beitrag von: Byte09 am 14 Mai 2018, 19:16:19
Update auf V1.4 verfügbar:

Änderungen:

in den 'on condition:' und 'off condition:' sind nun folgende Variablen verfügbar

[$EVENT]
[$EVENTFULL]
[$EVTPART1]
[$EVTPART2]
[$EVTPART3]


Zusätzliches Attribut 'MSwitch_Mode' verfügbar.

Mode 'Full' : Device ist in vollem, bisherigem Funktionsumfang verfügbar.
Mode 'Notify' : Device befindet sich im 'Notify' Mode. d.H folgende Optionen sind nicht verfügbar und werden nicht ausgeführt.

'switch MSwitch on + execute 'on' commands at :'
'switch MSwitch off + execute 'on' commands at :'
'switch DEVICE on + execute 'on' commands'
'switch DEVICE on + execute 'on' commands'

desweiteren hat des MSwitch Device in diesem Mode keine set on/off Option und kein devstateicon mehr, sondern wird lediglich als 'active' dargestellt, falls es nicht 'disabled' ist. Somit vergleichbar der Darstellung von Notify, Doif etc.

Wenn dieses Attribut nicht gesetzt ist , wird die Einstellung 'Full' angenommen.
Bei neuen Devices wird das Attribut beim ersten Define auf 'Full' gesetzt .

gruss Byte09


Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 15 Mai 2018, 10:35:43
Ich habe in der aktuellen Version leider vergessen ein log0 auf log5 zu ändern , d.h es werden ohne ende logeinträge generiert . Ich ändere das sobald ich Zuhause bin .

Sorry und Gruss Byte09

Gesendet von meinem SM-G900F mit Tapatalk
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 15 Mai 2018, 16:47:51
update auf V1.41 verfügbar.

fix LOG
add ATTR 'MSwitch_Wait'


das Logproblem (LOG 0 ) wurde behoben. Aus Eigenbedarf habe ich ein Attribut 'MSwitch_Wait' eingebaut . Wenn dieses Attribut gesetzt ist ( Zeit in Sekunden ) reagiert das MSwitch-Device für den gesetzten Zeitraum auf keine weiteren Events, nachdem ein Event positiv getriggert wurde.

Wird dieses Attribut nicht oder auf '0' gesetzt, entspricht das Verhalten dem bisherigen Verhalten .

gruss Byte09

@det. - Danke für den Hinweis  ;)
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 16 Mai 2018, 05:33:04
@mark79

ich habe das MSwitch Toggle heute morgen mit einigen Geräten probiert , mit veerschiedenen Kombinationen ( 0/1 , on/off , ON/OFF ) etc. Diese gingen alle ohne Probleme - von daher kann ich nicht nachvollziehen, warum es mit der Yeelight nicht geht. Kannst du mir bitte mal ein LOG einstellen, was beim Schaltvorgang passiert ( verbose 5 ) und ein List der Yeelight ?

was steht denn im reading 'state' der Yeelight ? wird das der aktuelle Zustand on oder off abgebildet ?

Gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: mark79 am 16 Mai 2018, 10:38:46
Hallo Byte,

ups du hast recht, das liegt am State der Yeelight. Sorry. :)
Dort steht als state "opened" und dadurch sendet das MSwitch immer ein on an die Yeelight.

Das power Reading wäre dann das richtige im Yeelight Device, dort steht entweder "on" oder "off" als State.

Kannst du mir helfen, wie ich mit MSwitch auf das power Reading, reagieren lassen kann? Das kommt dann sicherlich in den on condition, aber wie?
Oder ich schreibe den "State" in der Yeelight um. Komme aber erst später dazu, weiter zu machen...

Internals:
   DEF        192.168.2.67
   DeviceName 192.168.2.67:55443
   FD         49
   HOST       192.168.2.67
   ID         192.168.2.67
   NAME       YeeLight
   NOTIFYDEV  global
   NR         410
   NTFY_ORDER 50-YeeLight
   PARTIAL   
   PORT       55443
   PROTO      1
   STATE      opened
   TYPE       YeeLight
   READINGS:
     2018-05-15 21:31:46   bright          100
     2018-05-15 21:31:46   color_flow      off
     2018-05-15 21:31:46   color_mode      color temperature
     2018-05-15 21:31:46   ct              3500
     2018-05-15 21:31:46   flow_params     
     2018-05-15 21:31:46   hue             359
     2018-05-15 21:31:46   music_mode      off
     2018-05-15 21:31:46   name           
     2018-05-16 10:22:29   power           on
     2018-05-15 21:31:46   rgb             FF0000
     2018-05-15 21:31:46   rgb_blue        0
     2018-05-15 21:31:46   rgb_green       0
     2018-05-15 21:31:46   rgb_red         255
     2018-05-15 21:31:46   sat             100
     2018-05-15 21:31:46   sleeptimer      0
     2018-05-16 10:21:05   state           opened
   helper:
     CommandSet on off toggle on-for-timer off-for-timer intervals bright dimup dimdown name default:noArg reopen:noArg close:noArg statusrequest:noArg hsv hue sat rgb color ct start_cf stop_cf scene circlecolor:noArg blink
     AnsQue:
     ErrQue:
     SendQue:
Attributes:
   DbLogExclude .*
   devStateIcon {my $power=ReadingsVal($name,"power","off");my $mode=ReadingsVal($name,"color_mode","RGB");if($power eq "off"){Color::devStateIcon($name,"rgb","rgb","power");}else{if($mode eq "RGB"){Color::devStateIcon($name,"rgb","rgb","bright");}elsif($mode eq "color temperature"){Color::devStateIcon($name,"rgb",undef,"bright");}}}
   room       YeeLight
   webCmd     rgb:bright:ct:rgb ffffff:rgb ff0000:rgb 00ff00:rgb 0000ff:on:off
   widgetOverride bright:colorpicker,BRI,0,1,100 ct:colorpicker,CT,1700,10,6500 rgb:colorpicker,RGB


root@rock64:/opt/fhem/log# tail -f fhem-2018-05.log |grep test
2018.05.16 10:25:41 5:   test state: click
2018.05.16 10:25:41 5: test MSwitch_Notify: einzeleventtest ende L:1605
2018.05.16 10:25:41 5: test MSwitch_Notif: var set für folgenden Befehlsaufruf ->  on - state:click 1651
2018.05.16 10:25:41 3: test MSwitch_Notif: Befehlsausfuehrung -> set test on state:click 1667
2018.05.16 10:25:41 3: test MSwitch_Set: aufruf MSwitch_checkcondition L:1002
2018.05.16 10:25:41 5: test MSwitch_checkcondition: ->  3705
2018.05.16 10:25:41 3: test MSwitch_Set: Befehlsausfuehrung -> set YeeLight MSwitchtoggle on/off L:1011
2018.05.16 10:25:41 5: test MSwitch_Set:  set YeeLight MSwitchtoggle on/off 1226
2018.05.16 10:25:41 5: test MSwitch_Set:  set YeeLight MSwitchtoggle on/off 1229
2018.05.16 10:25:41 5: test MSwitch_toggle:  set YeeLight MSwitchtoggle on/off 1249
2018.05.16 10:25:41 5: test MSwitch_toggle:  xsetx 1252
2018.05.16 10:25:41 5: test MSwitch_toggle:  xYeeLightx 1253
2018.05.16 10:25:41 5: test MSwitch_toggle:  x x 1254
2018.05.16 10:25:41 5: test MSwitch_toggle:  xonx 1255
2018.05.16 10:25:41 5: test MSwitch_toggle:  xoffx 1256
2018.05.16 10:25:41 5: test MSwitch_toggle: testnew -> opened 1270
2018.05.16 10:25:41 5: test MSwitch_toggle: cmd1 -> set YeeLight on 1271
2018.05.16 10:25:41 5: test MSwitch_toggle: cmd2 -> set YeeLight off 1272
2018.05.16 10:25:41 5: test MSwitch_toggle: neuer befehl -> set YeeLight on 1273
2018.05.16 10:25:41 5: test errechneter befehl:  set YeeLight on 1233

2018.05.16 10:25:49 5:   test state: click
2018.05.16 10:25:49 5: test MSwitch_Notify: einzeleventtest ende L:1605
2018.05.16 10:25:49 5: test MSwitch_Notif: var set für folgenden Befehlsaufruf ->  on - state:click 1651
2018.05.16 10:25:49 3: test MSwitch_Notif: Befehlsausfuehrung -> set test on state:click 1667
2018.05.16 10:25:49 3: test MSwitch_Set: aufruf MSwitch_checkcondition L:1002
2018.05.16 10:25:49 5: test MSwitch_checkcondition: ->  3705
2018.05.16 10:25:49 3: test MSwitch_Set: Befehlsausfuehrung -> set YeeLight MSwitchtoggle on/off L:1011
2018.05.16 10:25:49 5: test MSwitch_Set:  set YeeLight MSwitchtoggle on/off 1226
2018.05.16 10:25:49 5: test MSwitch_Set:  set YeeLight MSwitchtoggle on/off 1229
2018.05.16 10:25:49 5: test MSwitch_toggle:  set YeeLight MSwitchtoggle on/off 1249
2018.05.16 10:25:49 5: test MSwitch_toggle:  xsetx 1252
2018.05.16 10:25:49 5: test MSwitch_toggle:  xYeeLightx 1253
2018.05.16 10:25:49 5: test MSwitch_toggle:  x x 1254
2018.05.16 10:25:49 5: test MSwitch_toggle:  xonx 1255
2018.05.16 10:25:49 5: test MSwitch_toggle:  xoffx 1256
2018.05.16 10:25:49 5: test MSwitch_toggle: testnew -> opened 1270
2018.05.16 10:25:49 5: test MSwitch_toggle: cmd1 -> set YeeLight on 1271
2018.05.16 10:25:49 5: test MSwitch_toggle: cmd2 -> set YeeLight off 1272
2018.05.16 10:25:49 5: test MSwitch_toggle: neuer befehl -> set YeeLight on 1273
2018.05.16 10:25:49 5: test errechneter befehl:  set YeeLight on 1233
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 16 Mai 2018, 11:22:20
Das geht mit dem toggle im moment gar nicht , dieses kann nur dascreading state abfragen und entsprechend reagieren. Habe mir das heute morgen schon gedacht und mir Gedanken dazu gemacht.

Ich werde die toggle Routine heute abend entsprechend ändern/erweitern , so dass hier auf ein beliebiges , definierbares reading  reagiert werden kann

Gruss Bytr09

Gesendet von meinem SM-G900F mit Tapatalk

Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 16 Mai 2018, 18:42:02
ich werde nachher ein Update auf V1.42 einspielen.

Änderung:
Funktionsänderung/erweiterung MSwitchToggle.

Bisher konnte Toggle nur auf das Reading 'state' eines Devices auswerten und entsprechend reagieren.

set [name] MSwitchtoggle on/off
hier wurde einfach derZustand des Readings 'state' des betreffenden Devices geprüft.
war dieser 'on' wurde ein set off gesendet,
war dieser 'off' wurde ein set oon gesendet.

das funktionierte nur dann , wenn der 'state' genau die im MSwitch-device gespeicherte Befehle beinhaltete.


Neue Funktion :

die alte Syntax bleibt erhalten und entspricht in der Funktion genau dem bisherigen Verhalten.
zusätzlich ist folgende Syntax möglich
set [name] MSwitchtoggle on/off/reading/suchmuster1/suchmuster2wird nur
set [name] MSwitchtoggle on/off/
angegeben , so entspricht das dieser neuen Syntax  (wird dann intern ergänzt)
set [name] MSwitchtoggle on/off/state/on/off

erklärung :
wird im state von [name] 'on'(suchmuster1)  gefunden, so wird der Befehl 'off' gesendet,
wird im state von [name] 'off'(suchmuster1)  gefunden, so wird der Befehl 'on' gesendet

gruss Byty09

@mark79

set YeeLight MSwitchtoggle on/off/power/on/off
alternativ wird wohl auch :
set YeeLight MSwitchtoggle on/off/state/opened/closed
funftionieren, wenn der state zwischen opened und closed (ggf. opened und closed rumdrehen ) wechselt ?!


Konfigbeispiel Playbulb Sphere - Farbe togglen:

set Sphere MSwitchtoggle rgb ff0000/rgb 0000ff/rgb/ff0000/0000ff

Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 16 Mai 2018, 20:11:24
update auf V1.42 verfügbar.

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: mark79 am 16 Mai 2018, 23:03:57
Hallo Byte,

das ist ja genial, update eingespielt und es funktioniert. Vielen Dank! :)

set YeeLight MSwitchtoggle on/off/power/on/off
set YeeLight MSwitchtoggle rgb FF0000/rgb 0000FF/rgb/FF0000/0000FF

Damit kann ich eine Nachtischlampe mit der Yeelight umsetzen.. später soll die auch als Lichtwecker fungieren. Aber da überlege ich noch, wie ich das am besten umsetze.

set YeeLight MSwitchtoggle on/off/state/opened/closed
Funktioniert bei mir nicht und ich habe es mit verschiedenen Variationen ausprobiert.


Viele Grüße
Mark
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: andies am 17 Mai 2018, 21:26:12
Also, das ist mir jetzt peinlich - ich habe ja im wikieintrag herumgeschrieben, aber bis jetzt das Modul noch nicht im Einsatz, weil ich ein paar elementare Dinge nicht kapiere.

Es heißt ja, dass „Zweige“ steuerbar sind. Kann man das auch so beschreiben, dass mehrere FHEM-Befehle zusammengefasst und durch einen einzigen Befehl im Modul (bzw. einen trigger oder einen Zeitpunkt) ausgelöst werden? Ist dann also ein Zweig so eine Art Menge von Befehlen?

Bisher sehe ich nur on und off als mögliche Zweige. Oder übersehe ich da was?
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 17 Mai 2018, 21:56:11
Also, das ist mir jetzt peinlich - ich habe ja im wikieintrag herumgeschrieben, aber bis jetzt das Modul noch nicht im Einsatz, weil ich ein paar elementare Dinge nicht kapiere.

Es heißt ja, dass „Zweige“ steuerbar sind. Kann man das auch so beschreiben, dass mehrere FHEM-Befehle zusammengefasst und durch einen einzigen Befehl im Modul (bzw. einen trigger oder einen Zeitpunkt) ausgelöst werden? Ist dann also ein Zweig so eine Art Menge von Befehlen?

Bisher sehe ich nur on und off als mögliche Zweige. Oder übersehe ich da was?

Hi Andies ,

die Grundidee des Moduls war ja eine ganz andere , aus dieser resultiert das Grundgerüst des Modules , so wie es ist. Irgendwann hat sich diese Grundidee aber als Sackgasse erwiesen und irgendo viel mal der Satz 'aber ein cooles Mutiswitch-device" , ich glaube von det.

Ab da war die Intention, ein Modul zu schreiben , was alles kann , sprich ich aufkeine anderen Module mehr angewiesen bin.

Zu den Zweigen:

Das "grund"-Mswitch device ist ja schaltbar , On oder Off. Nun kann ich eine beliebige Zahl von Geräten definieren , die eine Aktion ausführen sollen , wenn das MSwitch device geschaltet wird .
der 'on-zweig' - was tun die devices , wenn das MSwitch auf On schaltet
der 'off-zweig' - was tun die Geräte , wenn das MSwitch device auf Off schaltet

beim manuellen schalten des MSwich werden die entsprechenden zweige abgearbeitet
 , wobei jedes device in jedem Zweig mit einer vielzahl von Bedingungen verknüpft werden kann  ( "on", oder "offconditions"

alternativ zum manuellen schalten kann das schalten des MSwiches auch durch einen Trigger oder eine feste Zeit ausgelöst werden .

alternativ dazu kann auch jeder zweig durch ein trigger aussgelöst werden , der state des Mswitches ändert sich aber nicht ( notify - mode )

und zuguter letzt können diese alternativen auch gleichzeitig , nebenher belegt werden in einem Device.

so ergeben sich eine Variation von Schaltmöglichkeiten , die - zumindest für mich - jedes weitere 'Schalt'-Modul unnötig machen.

Ist etwas schwierig zu erklären in schriftform. Wenn du lust hast können wir gerne mal dazu telefonieren. Aber das beste wäre es wohl einfach mal ein Device anzulegen und damit zu spielen  ;)

Gruss Thomas


Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: mark79 am 18 Mai 2018, 17:27:39
Ich habe ein Bespiel (Screenshot) für meinen TV in der Küche, allerdings nicht über ein trigger, sondern mittels on/off.

Das MSwitch KU_TV fasst alle Aktionen zusammen die ich haben möchte und schalten tue ich es mit einem DashButton, oder Alexa (ha-bridge), oder morgens über einen Motion Sensor, oder aber direkt über Fhem Webinterface.

Es sind bei dem MSwitch KU_TV Device 3 Geräte involviert. Einmal die Sonoff Steckdose, wo alles dran hängt.
Sprich der TV, ein Raspberry mit Libreelec (Kodi) und noch ein NodeMCU mit IR Transmitter (FreeCmd), um den TV ein & auszuschalten.

Bei "set KU_TV off" geht der TV via IR Transmitter in den Standby und der Raspberry wird herunterfahren (shutdown) und nach einigen Sekunden geht die Sonoff Steckdose aus.
Aus dem Grund, damit das Dateisystem vom RPi nicht kaputt geht und der TV nicht hart ausgeschaltet wird, wenn die Sonoff Steckdose ausgeschaltet wird.

Mit einem MSwitch Device (KU_TV) kann ich alle 3 Geräte Zeitversetzt steuern und auch zu verschiedenen Uhrzeiten unterschiedliche Aktionen ausführen.
Wie z.B. Werktags morgens, soll die Lautstärke runter geregelt werden und automatisch SAT1 eingeschaltet werden. Wir schauen gerne Frühstücksfernsehen... :)

MSwitch finde ich einfacher zu konfigurieren, man kann sich das leicht zurecht klicken und man hat alles in einem Device.
Dazu kann man das Device auch mit on/off schalten, also mit Buttons.

Danke an Thomas für das Modul! :)
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: andies am 18 Mai 2018, 19:20:52
die Grundidee des Moduls war ja eine ganz andere , aus dieser resultiert das Grundgerüst des Modules , so wie es ist. Irgendwann hat sich diese Grundidee aber als Sackgasse erwiesen und irgendo viel mal der Satz 'aber ein cooles Mutiswitch-device" , ich glaube von dir.
Ja, ja, ich weiß  ;D

Ich habe das nun im Wiki geändert, weil endlich der Groschen gefallen ist. Ich hatte ja eigentlich vor, etwas anderes zu machen. Ich wollte ein device, das zeitgesteuert bestimmte Dinge auslöst (konkret: Abwesenheitssimulation) und mir war nicht klar, wie das geht.

Also wenn ich beispielsweise das reading eines dummy auf "Ich bin abwesend" stelle, sollten die Lampen A und B um 7:03 bis 7:20 angehen und um 8:10 und 8:20 ausgehen usw usf. Wenn dagegen "Ich bin anwesend" stand, sollte nichts passieren. Mir war nicht klar, dass ich dazu entweder einen Trigger definieren muss, der dann selbst zeitabhängig  einschaltet oder via GLOBAL gehe. Jetzt habe ich das kapiert.
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 18 Mai 2018, 20:05:30
Ich habe ein Bespiel (Screenshot) für meinen TV in der Küche, allerdings nicht über ein trigger, sondern mittels on/off.

Das MSwitch KU_TV fasst alle Aktionen zusammen die ich haben möchte und schalten tue ich es mit einem DashButton, oder Alexa (ha-bridge), oder morgens über einen Motion Sensor, oder aber direkt über Fhem Webinterface.

Es sind bei dem MSwitch KU_TV Device 3 Geräte involviert. Einmal die Sonoff Steckdose, wo alles dran hängt.
Sprich der TV, ein Raspberry mit Libreelec (Kodi) und noch ein NodeMCU mit IR Transmitter (FreeCmd), um den TV ein & auszuschalten.

Bei "set KU_TV off" geht der TV via IR Transmitter in den Standby und der Raspberry wird herunterfahren (shutdown) und nach einigen Sekunden geht die Sonoff Steckdose aus.
Aus dem Grund, damit das Dateisystem vom RPi nicht kaputt geht und der TV nicht hart ausgeschaltet wird, wenn die Sonoff Steckdose ausgeschaltet wird.

Mit einem MSwitch Device (KU_TV) kann ich alle 3 Geräte Zeitversetzt steuern und auch zu verschiedenen Uhrzeiten unterschiedliche Aktionen ausführen.
Wie z.B. Werktags morgens, soll die Lautstärke runter geregelt werden und automatisch SAT1 eingeschaltet werden. Wir schauen gerne Frühstücksfernsehen... :)

MSwitch finde ich einfacher zu konfigurieren, man kann sich das leicht zurecht klicken und man hat alles in einem Device.
Dazu kann man das Device auch mit on/off schalten, also mit Buttons.

Danke an Thomas für das Modul! :)

Hi Mark,

nur aus Neugier : was machen denn die drei dash notifys bzw das doif , die mit dem device 'verbunden' sind ?
ggf, kannst du die sparen ( je nach ddem ) .

gruss Thomas
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: mark79 am 19 Mai 2018, 00:38:27
Hallo Thomas,

Verbessern kann man bestimmt einiges. :) Allerdings das mit Dash Button Bespiel im Wiki habe ich bei mehreren Versuchen nicht hinbekommen. Aber das ist auch schon etwas her und war am Anfang wohl etwas zu komplex...
Ich werde das später noch mit einem einfaches Device ausprobieren.

>>nur aus Neugier : was machen denn die drei dash notifys bzw das doif , die mit dem device 'verbunden' sind ?

Mit dem "Dash_Power" Button wird der KU_TV bzw. das MSwitch Device an oder ausgeschaltet (Toggle notify)
defmod Dash_Power notify DashButton:18-74-2e-6b-0c-32..short { if (ReadingsVal("KU_TV","state","") eq "on") { fhem("set KU_TV off") } else { fhem("set KU_TV on") } }
Dash_Mentos ist ein Dashbutton im Flur, womit ich einige Geräte beim verlassen der Wohnung, oder beim schlafen gehen ausschalte:
defmod Dash_Mentos notify DashButton:18-74-2e-a2-fc-51:.short {fhem("set WZ_Lichtschalter off;; set WZ_Bilderrahmen off;; set WZ_Stehlampe off;; set KU_Schranklicht off;; set KU_Kaffee off;; set WZ_TV off;; set KU_TV off")}
Das DOIF ist ein IT Bewegungsmelder, der im Moment eigentlich nur morgens beim aufstehen das Küchenlicht, Kaffeemaschine und TV anschaltet. Irgendwann später soll der Sensor, ein Wecker ausschalten und ein Nachtlicht schalten...
defmod Flur_motion_kueche_morgens DOIF ([05:50 - 07:30|Mo Di Mi Do Fr] and [Pearl_Motion:"^on$"]) (set KU_Kaffee on)(set KU_Schranklicht on)(set KU_TV on)DOELSEIF([00:00])
Wozu das DashButton_notify_1 existiert, weiß ich allerdings auch nicht mehr. :D
defmod DashButton_notify_1 notify DashButton:18-74-2e-a2-fc-51:.short {("set WZ_Lichtschalter off;;;; set WZ_Bilderrahmen off;;;; set WZ_Stehlampe off;;;; set KU_Schranklicht off;;;; set KU_Kaffee off;;;; set WZ_TV off;;;; set KU_TV off")}
Das war bestimmt ein Test Device, was ich wohl vergessen habe zu löschen. Oder das schaltet in Wirklichkeit Dash_Mentos. Muss ich mir später noch mal genauer anschauen.

Das meiste ist auch noch aus meiner Anfangszeit und wenn es funktioniert, verändert man es erstmal nicht.
Aber bisher habe ich 3 DOIFs und ein paar Dummys durch MSwitch ersetzt.


Viele Grüße
Mark
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 19 Mai 2018, 08:04:58
kommendes Update auf V1.43

das kommende Update wird folgende Änderungen enthalten:

- diverse kleinere Fehler behoben

- gravierenden fehler in Zusammenhang Notify-Mode und Delays behoben

- Funktionserweiterung Events: bisher boten die triggerbaren Events nur in der 'letzten Stelle' die Möglichkeit von Mehrfachangaben  z.B.
state:(on/off) Hier wird es Möglich sein , auch bei dem Readingnamen Mehrfachangaben zu machen  , in dieser Form (state/rgb):(on/off) Dieses zielt insbesondere auf die komfotablerer Einbindung von Dashbuttons ab, da damit folgende Eventabfragen Möglich werden , ohne das in den jeweiligen 'affected devices' nochmals eine Conditionabfrage gemacht werden muss :
(ac-63-be-8c-d2-X1/ac-63-be-8c-d2-X2/ac-63-be-8c-d2-X3):short
- Funktionserweiternug MSwitch_Mode: zu den bisherigen Modes 'Full' und 'Notif' wird der Mode 'Toggle' kommen. In diesm Mode wird in den Triggerdetails statt der bisherigen Felder "execute 'on' commands, execute 'off' commands' ... " nur ein Feld verfügbar sein , 'toggle Mswitch and execute comands". Bei eintreffen des hier definierten Events Toggelt sich das MSwitch Device selber und führt alle Kommandos des dann aktiven Zweiges aus - manuelles umschalten über webcmd ist ebenfalls möglich.

gruss Byt09



Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: andies am 19 Mai 2018, 10:04:30
Man kommt ja mit dem Wikischreiben gar nicht hinterher :D
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 19 Mai 2018, 10:46:58
Man kommt ja mit dem Wikischreiben gar nicht hinterher :D

 ;D

ja ,sry  ;), da das modul jetzt doch hier und da im einsatz ist stellt sich doch schnell verbesserungsbedarf dar.
die letzten Änderungen beruhen z.B fast ausschliesslich auf dem letzten post von Mark und dem daraus resultierendem vereinfachungspotential

Gruss Thomas
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: andies am 19 Mai 2018, 12:22:01
Was hältst du von der Idee, einen Text für die commandref innerhalb des Moduls (also am Ende) entwerfen? Ich finde das immer gut, wenn man unten auf „device help“ klickt und gleich was sieht, das passiert dann nämlich.  Soll ich mal versuchen?
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 19 Mai 2018, 12:29:46
Was hältst du von der Idee, einen Text für die commandref innerhalb des Moduls (also am Ende) entwerfen? Ich finde das immer gut, wenn man unten auf „device help“ klickt und gleich was sieht, das passiert dann nämlich.  Soll ich mal versuchen?

hi andies

sehr sehr gerne ,

genau diese fehlende commandref ist eigentlich auch der grund, warum ich zur zeit nicht mal daran denke , das Modul offiziell zu machen.

traue es mich ja kaum es zu sagen , aber das ist mir im moment zu zeitaufwendig ( und schreibarbeit ist eh nicht so meins )  :o

gruss Thomas
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 19 Mai 2018, 20:20:20
Hallo Thomas,

nach deinem Hinweis eben auf dieses Modul habe ich mir nun die 6 Seiten hier durchgelesen und auch das wiki mal überflogen. Ist für mich heute irgendwie schwere Kost.

Nun eine bitte an dich:

Ich habe einen HM-PB-2-WM55 (Flur_Taster1_01:.*Short.*(Licht an), Flur_Taster1_02:.*Short.*(Licht aus)) als Taster, einen HM-Sen-MDIR-WM55 (Flur_Taster2_01:.*Short.*(Licht an), Flur_Taster2_02:.*Short.*(Licht aus), Flur_Taster2_Motion(Bewegungsmelder)) als Taster mit Bewegungsmelder und beide schalten einen HM-LC-DIM1T-FM (Flur_Lampe) wo eine Lampe angeschlossen ist. Der Bewegungsmelder schaltet die Lampe nur in der Zeit von 18 Uhr bis 6 Uhr.

Kannst du mir das mal als Beispiel für dein Modul machen? Vielleicht verstehe ich dann den ganzen Zusammenhang.

Vielen Dank schonmal

Gruß Torsten
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: andies am 19 Mai 2018, 20:37:37
also ich kann das auch nicht auf die Schnelle, aber man muss da ungefähr wie folgt herangehen. Du brauchst ein Gerät, das auslöst. Das könnte im Zweifel ein dummy sein, muss aber nicht. Das Gerät hat on und off. Dieses Gerät ist der trigger.

Und dann überlegst du dir, was nach dem on oder dem off geschaltet werden soll. Das sind die Geräte, die du dann im webinterface anlegst. Die Geräte stehen dann in den Zweigen, also dem on-Zweig bzw. dem off-Zweig.

Jetzt klarer?
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 19 Mai 2018, 20:48:11
...
Jetzt klarer?

Leider nein
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 19 Mai 2018, 20:56:50
Leider nein
Hi

Heute leider nicht mehr ... bin unterwegs und habe gerade ein schönes Bier vor mir stehen.

Mache ich morgen früh.

Gruss Byte09

Kurz da mobil

Gesendet von meinem SM-G900F mit Tapatalk

Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 19 Mai 2018, 20:57:50
Hi

Heute leider nicht mehr ... bin unterwegs und habe gerade ein schönes Bier vor mir stehen.

Mache ich morgen früh.

Gruss Byte09

Kurz da mobil

Gesendet von meinem SM-G900F mit Tapatalk

Super, vielen Dank. Dann noch Prost!
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: andies am 19 Mai 2018, 21:07:09
Leider nein
Kannst du wenigstens sagen, wieso? Sonst hole ich mir auch ein Bier ;-)
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 19 Mai 2018, 21:08:58
Liegt wahrscheinlich daran, dass ich heute eine ziemlich lange Leitung habe. Dazu kommt, dass ich noch Anfänger bin und noch nicht den Durchblick habe.
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: mark79 am 19 Mai 2018, 21:12:37
Hallo Thomas und Prost, :)

die Neuerungen hören sich toll an und so was habe ich noch vermisst, sofern ich das richtig verstehe...

Das heißt also, das es mit der V1.43 und dem neuen MSwitch_Mode: 'Toggle' es dann Möglich ist, auf ein Event zu triggern und zugleich könnte man das Device auch im Webinterface schalten?
In beiden fällen, würde sich dann auch der State des MSwitch Device mit ändern? Das wäre super und dadurch könnte man sich auch die notifys und DOIFs sparen...


Viele Grüße
Mark
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 19 Mai 2018, 21:15:09
Auf den Punkt gebracht ;-)

Gruss Thomas

Gesendet von meinem SM-G900F mit Tapatalk

Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: andies am 19 Mai 2018, 21:34:20
So, hier kommen mal meine ersten Gehversuche mit Hilfe. Du musst, Thomas, den Text in dem Codeblock einfach nach der 1 am (derzeitigen) Ende des Modulfiles hinzufügen. Danach erscheinen ein paar Dinge, die auch im Wiki und so stehen, unter "device specific help". Englisch schaffe ich momentan nicht, vielleicht ist einer schneller.


=pod
=item device
=item summary    controls several devices using a trigger device
=item summary_DE kontrolliert mehrere Geraete mit Hilfe eines Trigger-Geraetes
=begin html
=end html
=begin html_DE

<!-- ================================ -->
<a name="MSwitch"></a>
<h3>MSwitch</h3>

<ul>MSwitch ist ein Hilfsmodul. Es erlaubt das gleichzeitige Schalten von mehreren devices. Weitere Abhängigkeiten und Bedingungen wie ereignisgesteuertes und/oder zeitgesteuertes Schalten einzelner devices sind einstellbar.<br>

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).

<br><br>
 
<b>Vorbereitungen</b> <br><br>
Um das Modul zu nutzen, muss man sich zuerst drei Dinge überlegen:
<ol>
<li>Welches Gerät soll auslösen? Dies ist der Trigger. Ein Trigger muss on- und off-Befehle haben.</li>
<li>Wenn der Trigger ausgelöst hast, welche nachfolgenden Geräte sollen dann geschaltet werden? Dabei unterscheidet das Modul zwischen den Geräten, die bei einem on-Befehl (auch 'on-Zweig'), und den Geräten, die bei einem off-Befehl (auch 'off-Zweig') ausgelöst werden.</li>
<li> Welche weiteren Bedingungen sollen für die Geräte, die im on- bzw off-Zweig liegen, noch gelten? Hier sind ereignisgesteuerte woe auch zeitgesteuerte Bedingungen möglich.</li>
</ol>
<br><br>
<b>Define</b>
  <ul>
    <br>

    <code>define &lt;name&gt; MSwitch</code>
    <br><br>
    <code>&lt;name&gt;</code> ist Name des Moduls. Es sind weder Trigger noch Geräte in den Zweigen definiert, dies geschieht durch die Weboberfläche.<br>
<br><br>
</ul>

  <b>Set</b>
    <br><br>
   <ul>
     <b>on/off</b>     
     <ul><code>set &lt;name&gt; on/off
      </code><br>
Schaltet das Gerät on bzw off und löst damit diejenigen Geräte aus, die sich im on- bzw off-Zweig befinden.</ul>
   </ul>
   <ul>
     <b> MSwitch_backup</b>     
     <ul><code>set &lt;name&gt; MSwitch_backup
      </code><br>
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ück gespielt (hergestellt) werden. </ul>

    <b>Get</b>
    <br><br>
   <ul>
     <b>show_timer</b>
     <ul><code>get &lt;name&gt; show_timer
      </code><br>
      Zeigt alle anstehenden (gesetzten) Timer des Devices, die aus zeitabhängigen oder verzögerten Schaltbefehlen resultieren.
     </ul>
</ul>
   <ul>
     <b>delete_timer</b>
     <ul><code>get &lt;name&gt; delete_timer
      </code><br>
  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.
 </ul>
     </ul>
</ul>

<b>Attribute</b>
    <br><br>
   <ul>

     <b>MSwitch_Help (0:1)</b>   
     <ul><code>attr &lt;name&gt; MSwitch_Help 1
   </code><br>
Schaltet Hilfebuttons zu den einzelnen Eingabefeldern an oder aus.<br><br>
     </ul>

     <b>MSwitch_Debug (0:1:2)</b>   
     <ul><code>attr &lt;name&gt; MSwitch_Debug 1
   </code><br>
0 - Abgeschaltet<br>
1 - Schaltet Felder zum testen der Conditionstrings etc. an<br>
2 - erweiterte Debugfunktion (nur für Entwicklung)<br><br>
     </ul>

     <b>MSwitch_Expert (0:1)</b>   
     <ul><code>attr &lt;name&gt; MSwitch_Expert 1
   </code><br>
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.<br><br>
     </ul>

     <b>MSwitch_Delete_Delays (0:1)</b>   
     <ul><code>attr &lt;name&gt; MSwitch_Delete_Delays 1
   </code><br>
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.<br><br>
     </ul>

     <b>MSwitch_Include_Devicecmds (0:1)</b>   
     <ul><code>attr &lt;name&gt; MSwitch_Include_Devicecmds 1
   </code><br>
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.<br><br>
     </ul>

     </ul>


<!-- ================================ -->
=end html_DE
=cut
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: det. am 19 Mai 2018, 21:55:00
Hallo Thomas und @all,
Erst mal ist Pfingsten und die Dixielandmeile und Biergärten stehen im Vordergrund.


Das Modul läuft seit einiger Zeit bei mir prima. Nur wächst langsam die Sorge, dass durch immer neue Ideen einzelner User, die Thomas vorbildlich und schnell einbaut und umsetzt, sich das Konstrukt in eine Eierlegendewollmilchsau verwandelt. So was hat Damian mit DOIF leider inzwischen auch geschafft.
Wenn man dann zur (optimal auf die Aufgabenstellung abgestimmten) Konfiguration  einer einzelnen Instanz ein FHEM spezifisches Informatik Studium braucht, wird das Ganze wieder irgendwie Sinnlos und man kommt mit at und notify letztendlich einfacher, intuitiver und schneller zum Ziel.


Meine Message - bitte treibt den Entwickler nicht vor Euch her - Thomas macht das schon!

Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: mark79 am 19 Mai 2018, 21:55:26
Liegt wahrscheinlich daran, dass ich heute eine ziemlich lange Leitung habe. Dazu kommt, dass ich noch Anfänger bin und noch nicht den Durchblick habe.

Du hast schon sehr viele Devices und mit den Triggern bei MSwitch, bin ich selber noch ein Newbie.  :-\

Ich würde dir erstmal empfehlen, es nur mit einem trigger Device umzusetzen, um das Modul zu verstehen.

Wichtig ist dort das "Save incomming events" an zu haken und mit "modify" zu bestätigen. Das braucht man aber nur zu machen, wenn man nur ein Trigger Device hat.

Danach das zu triggernde Device (z.B. HM-PB-2-WM55) betätigen und nun kannst du das Event bzw. den State des Devices unter "trigger details" in der Dropdown-Liste auswählen. Jeweils bei on & off und auch wieder mit modify bestätigen..

Bei affected devices muss dann noch das zu schaltende Device hinzugefügt werden. Wie z.B. HM-LC-DIM1T-FM (Flur_Lampe).

Unten bei "device actions" (HM-LC-DIM1T-FM) kannst du dann bei "MSwitch on cmd: Set" auswählen was bei on/off passieren soll. Also Lampe on und off schalten.

Bei mehreren trigger Devices müsstes du meiner Meinung nach, das oberste "Trigger device" auf GLOBAL setzen und bei "switch MSwitch on + execute 'on' commands at" die zu triggernde Geräte rein schreiben. Das selbe bei "switch MSwitch off...".
Bei affected devices das zu schaltene Device hinzufügen. Aber ab dort bin ich auch raus... weil ich das selber noch nicht mit so vielen trigger Devices umgesetzt habe.


Viele Grüße
Mark


Auf den Punkt gebracht ;-)

Gruss Thomas
Darauf bin ich schon gespannt, werde dann noch so einige Devices ersetzen. :)
Danke dir schon mal, das du das doch umgesetzt hast! :)

Kannst du wenigstens sagen, wieso? Sonst hole ich mir auch ein Bier ;-)
Ein Bier geht um diese Uhrzeit doch immer... Prost ;D
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 19 Mai 2018, 22:06:35
...
Ich würde dir erstmal empfehlen, es nur mit einem trigger Device umzusetzen, um das Modul zu verstehen.

Wichtig ist dort das "Save incomming events" an zu haken und mit "modify" zu bestätigen. Das braucht man aber nur zu machen, wenn man nur ein Trigger Device hat.

Danach das zu triggernde Device (z.B. HM-PB-2-WM55) betätigen und nun kannst du das Event bzw. den State des Devices unter "trigger details" in der Dropdown-Liste auswählen. Jeweils bei on & off und auch wieder mit modify bestätigen..

...
Da fangen meine Probleme schon an, siehe Fotos. Anscheinend habe ich was falsch eingetragen
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 19 Mai 2018, 22:09:52
Hallo Thomas und @all,
Erst mal ist Pfingsten und die Dixielandmeile und Biergärten stehen im Vordergrund.


Das Modul läuft seit einiger Zeit bei mir prima. Nur wächst langsam die Sorge, dass durch immer neue Ideen einzelner User, die Thomas vorbildlich und schnell einbaut und umsetzt, sich das Konstrukt in eine Eierlegendewollmilchsau verwandelt. So was hat Damian mit DOIF leider inzwischen auch geschafft.
Wenn man dann zur (optimal auf die Aufgabenstellung abgestimmten) Konfiguration  einer einzelnen Instanz ein FHEM spezifisches Informatik Studium braucht, wird das Ganze wieder irgendwie Sinnlos und man kommt mit at und notify letztendlich einfacher, intuitiver und schneller zum Ziel.


Meine Message - bitte treibt den Entwickler nicht vor Euch her - Thomas macht das schon!
Diese sorge hatte ich auch schon selber , aber alle Funktionen die in letzter zeit gekommen sind oder kommen weden entweder durch attr zugeschaltet z.b expertmode oder sind im Grunde nicht sichtbar , wenn man sie nicht weiss. Insofern wird sich das 'sichtbare ' grundmodul in der grundkonfiguratin nicht mehr ändern ( Änderung der delays ausgenommen ;-) )

Gruss Thomss

Gesendet von meinem SM-G900F mit Tapatalk

Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 19 Mai 2018, 22:12:32
Das event ist im normalmode nur zweistellig , also state.*  ... nicht *.state.*

Einfacher ist es wenn du die event speichern lässt.

Gruss Byte09
Da fangen meine Probleme schon an, siehe Fotos. Anscheinend habe ich was falsch eingetragen

Gesendet von meinem SM-G900F mit Tapatalk

Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 19 Mai 2018, 22:14:18
Das event ist im normalmode nur zweistellig , also state.*  ... nicht *.state.*

Einfacher ist es wenn du die event speichern lässt.

Gruss Byte09
Gesendet von meinem SM-G900F mit Tapatalk

im dropdown wird mir nur *.state.* und no_trigger angeboten
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 19 Mai 2018, 22:17:39
Markiert mal 'Save incommig events'  und bestätige das mit modify.  Dann scalte mal alle Optionen des zu triggernden devices durch. Danach das mswitch Device aktualisieren . Dann sollten alle aufgetretenen events in der liste sein.

Gruss byte09

Gesendet von meinem SM-G900F mit Tapatalk

Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 19 Mai 2018, 22:22:38
Markiert mal 'Save incommig events'  und bestätige das mit modify.  Dann scalte mal alle Optionen des zu triggernden devices durch. Danach das mswitch Device aktualisieren . Dann sollten alle aufgetretenen events in der liste sein.

Gruss byte09

Gesendet von meinem SM-G900F mit Tapatalk

Habe es mehrfach versucht mit modify, werden immer nur die beiden möglichkeiten angezeigt
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 19 Mai 2018, 22:23:24
Verschieben wir das auf morgen, möchte dich nicht von deinem Bier abhalten  ;)
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 19 Mai 2018, 22:25:47
Top , so machen wirres ;-)

Gruss Thomas

Gesendet von meinem SM-G900F mit Tapatalk

Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: mark79 am 19 Mai 2018, 22:51:00
Habe es mehrfach versucht mit modify, werden immer nur die beiden möglichkeiten angezeigt

Ich habe ein Bespiel Device angelegt. Siehe Screenshot.

Das ist ein Xiaomi Funk Taster der mehrere Events produziert: "click" und "double_click"
2018-05-19 22:40:59 XiaomiSmartHome_Device Xiaomi_Taster click
2018-05-19 22:43:14 XiaomiSmartHome_Device Xiaomi_Taster double_click

Um die aufzunehmen muss man "Save incomming events" anhaken und einmal in dem Bereich (trigger details) auf modify klicken.
Danach den Taster bedienen und dann die Fhem Seite im Browser mit der F5 Taste neu laden, dann solltest du die Events wie im Sceenshot zu sehen ist auswählen können.

Weiter unten habe ich ein WZ_Lichtschalter Device mit dem Xiaomi_Taster verknüpft, das schaltet dann einfach das Wohnzimmer Licht mit "click" und double_click" an und aus.
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 20 Mai 2018, 07:28:04
Habe es jetzt mal versucht, siehe Screenshots. Aber wenn ich den Taster betätige passiert nichts
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 20 Mai 2018, 09:23:13
joooooo,

du hast es richtig konfiguriert , aber ... wie soll ich sagen ... probiert und Fehler gefunden , der jetzt 6 Monate nicht aufgefallen ist . Das Modul kommt mit den () im Event nicht klar.

kannst du erstmal auf ein anderes verfügbares Event Triggern - ohne Klammern im Event ?

ich Fixe das mit der Version die heute kommt.

Gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 20 Mai 2018, 09:32:21
ich spiele in der nächsten Stunde ein Zwischenupdate ein , das diesen Fehler behebt.

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 20 Mai 2018, 09:35:29
Ich habe state nur mit (to broadcast)
und auf trigger:Short reagiert es nicht
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 20 Mai 2018, 10:36:05
Ich habe state nur mit (to broadcast)
und auf trigger:Short reagiert es nicht

ich habe eben ein Update ( nur ein Fix ) eingespielt und hoffe das dieses Problem damit behoben ist . Somit sollte dein obiges Beispiel nun gehen

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 20 Mai 2018, 11:22:16
ich habe eben ein Update ( nur ein Fix ) eingespielt und hoffe das dieses Problem damit behoben ist . Somit sollte dein obiges Beispiel nun gehen

gruss Byte09

bekomme ich den fix mit update oder muß ich den vom git runterladen? Kannst du mir dann den link geben?
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 20 Mai 2018, 11:37:35
bekomme ich den fix mit update oder muß ich den vom git runterladen? Kannst du mir dann den link geben?

in der fhem befehlszeile eingeben:

update all https://raw.githubusercontent.com/Byte009/FHEM-MSwitch/master/controls_mswitch.txt
Gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 20 Mai 2018, 11:45:25
So, hier kommen mal meine ersten Gehversuche mit Hilfe. Du musst, Thomas, den Text in dem Codeblock einfach nach der 1 am (derzeitigen) Ende des Modulfiles hinzufügen. Danach erscheinen ein paar Dinge, die auch im Wiki und so stehen, unter "device specific help". Englisch schaffe ich momentan nicht, vielleicht ist einer schneller.


=pod
=item device
=item summary    controls several devices using a trigger device
=item summary_DE kontrolliert mehrere Geraete mit Hilfe eines Trigger-Geraetes
=begin html
=end html
=begin html_DE

<!-- ================================ -->
<a name="MSwitch"></a>
<h3>MSwitch</h3>

<ul>MSwitch ist ein Hilfsmodul. Es erlaubt das gleichzeitige Schalten von mehreren devices. Weitere Abhängigkeiten und Bedingungen wie ereignisgesteuertes und/oder zeitgesteuertes Schalten einzelner devices sind einstellbar.<br>

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).

<br><br>
 
<b>Vorbereitungen</b> <br><br>
Um das Modul zu nutzen, muss man sich zuerst drei Dinge überlegen:
<ol>
<li>Welches Gerät soll auslösen? Dies ist der Trigger. Ein Trigger muss on- und off-Befehle haben.</li>
<li>Wenn der Trigger ausgelöst hast, welche nachfolgenden Geräte sollen dann geschaltet werden? Dabei unterscheidet das Modul zwischen den Geräten, die bei einem on-Befehl (auch 'on-Zweig'), und den Geräten, die bei einem off-Befehl (auch 'off-Zweig') ausgelöst werden.</li>
<li> Welche weiteren Bedingungen sollen für die Geräte, die im on- bzw off-Zweig liegen, noch gelten? Hier sind ereignisgesteuerte woe auch zeitgesteuerte Bedingungen möglich.</li>
</ol>
<br><br>
<b>Define</b>
  <ul>
    <br>

    <code>define &lt;name&gt; MSwitch</code>
    <br><br>
    <code>&lt;name&gt;</code> ist Name des Moduls. Es sind weder Trigger noch Geräte in den Zweigen definiert, dies geschieht durch die Weboberfläche.<br>
<br><br>
</ul>

  <b>Set</b>
    <br><br>
   <ul>
     <b>on/off</b>     
     <ul><code>set &lt;name&gt; on/off
      </code><br>
Schaltet das Gerät on bzw off und löst damit diejenigen Geräte aus, die sich im on- bzw off-Zweig befinden.</ul>
   </ul>
   <ul>
     <b> MSwitch_backup</b>     
     <ul><code>set &lt;name&gt; MSwitch_backup
      </code><br>
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ück gespielt (hergestellt) werden. </ul>

    <b>Get</b>
    <br><br>
   <ul>
     <b>show_timer</b>
     <ul><code>get &lt;name&gt; show_timer
      </code><br>
      Zeigt alle anstehenden (gesetzten) Timer des Devices, die aus zeitabhängigen oder verzögerten Schaltbefehlen resultieren.
     </ul>
</ul>
   <ul>
     <b>delete_timer</b>
     <ul><code>get &lt;name&gt; delete_timer
      </code><br>
  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.
 </ul>
     </ul>
</ul>

<b>Attribute</b>
    <br><br>
   <ul>

     <b>MSwitch_Help (0:1)</b>   
     <ul><code>attr &lt;name&gt; MSwitch_Help 1
   </code><br>
Schaltet Hilfebuttons zu den einzelnen Eingabefeldern an oder aus.<br><br>
     </ul>

     <b>MSwitch_Debug (0:1:2)</b>   
     <ul><code>attr &lt;name&gt; MSwitch_Debug 1
   </code><br>
0 - Abgeschaltet<br>
1 - Schaltet Felder zum testen der Conditionstrings etc. an<br>
2 - erweiterte Debugfunktion (nur für Entwicklung)<br><br>
     </ul>

     <b>MSwitch_Expert (0:1)</b>   
     <ul><code>attr &lt;name&gt; MSwitch_Expert 1
   </code><br>
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.<br><br>
     </ul>

     <b>MSwitch_Delete_Delays (0:1)</b>   
     <ul><code>attr &lt;name&gt; MSwitch_Delete_Delays 1
   </code><br>
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.<br><br>
     </ul>

     <b>MSwitch_Include_Devicecmds (0:1)</b>   
     <ul><code>attr &lt;name&gt; MSwitch_Include_Devicecmds 1
   </code><br>
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.<br><br>
     </ul>

     </ul>


<!-- ================================ -->
=end html_DE
=cut

thx, nehme ich mit in die v1.43

gruss Thomas
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 20 Mai 2018, 11:59:58
aus irgendeinem Grund passiert leider nichts. Habe mit filezilla nachgeschaut die Datei ist 180.783 groß und heute geändert. Im Event Monitor steht:
2018-05-20 11:58:17 CUL_HM Flur_4_fach_Taster battery: ok
2018-05-20 11:58:17 CUL_HM Flur_4_fach_Taster Flur_Klingel Short
2018-05-20 11:58:17 dummy Klingel_dummy Klingel: 1
2018-05-20 11:58:17 dummy Klingel_dummy Klingel: 1
2018-05-20 11:58:17 CUL_HM Flur_Klingel Short 1_109 (to broadcast)
2018-05-20 11:58:17 CUL_HM Flur_Klingel trigger: Short_109
2018-05-20 11:58:17 CUL_HM Flur_Klingel trigger_cnt: 109
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 20 Mai 2018, 12:04:33
aus irgendeinem Grund passiert leider nichts. Habe mit filezilla nachgeschaut die Datei ist 180.783 groß und heute geändert. Im Event Monitor steht:
2018-05-20 11:58:17 CUL_HM Flur_4_fach_Taster battery: ok
2018-05-20 11:58:17 CUL_HM Flur_4_fach_Taster Flur_Klingel Short
2018-05-20 11:58:17 dummy Klingel_dummy Klingel: 1
2018-05-20 11:58:17 dummy Klingel_dummy Klingel: 1
2018-05-20 11:58:17 CUL_HM Flur_Klingel Short 1_109 (to broadcast)
2018-05-20 11:58:17 CUL_HM Flur_Klingel trigger: Short_109
2018-05-20 11:58:17 CUL_HM Flur_Klingel trigger_cnt: 109

hast du nach dem Update fhem neu gestartet oder ein reload 98_MSwitch.pm in der befehlszeile eingegeben ?

.... ansonsten arbeitet fhem noch mit der alten Modulversion !
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 20 Mai 2018, 12:08:06
und ich sehe gerade dass sich das Event 'Short 1_109 (to broadcast)'  von dem von dir getriggertem Event 'Short 1_XX (to broadcast)' unterscheidet .

warum , was bedeutet die Zahl im Event in diesem Fall ?

bekommst du nicht dieses Event '2018-05-20 11:58:17 CUL_HM Flur_4_fach_Taster Flur_Klingel Short' zur auswahl ? darauf solltest du triggern.

mach mal im MSwitch device ein get get_config und poste mal die daten bitte
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 20 Mai 2018, 12:14:44
hast du nach dem Update fhem neu gestartet oder ein reload 98_MSwitch.pm in der befehlszeile eingegeben ?

.... ansonsten arbeitet fhem noch mit der alten Modulversion !

ich habe ein shutdown restart durchgeführt.
Zitat
und ich sehe gerade dass sich das Event 'Short 1_109 (to broadcast)'  von dem von dir getriggertem Event 'Short 1_XX (to broadcast)' unterscheidet .

warum , was bedeutet die Zahl im Event in diesem Fall ?

bekommst du nicht dieses Event '2018-05-20 11:58:17 CUL_HM Flur_4_fach_Taster Flur_Klingel Short' zur auswahl ? darauf solltest du triggern.

Ok, Fehler erkannt und beseitigt.

Läuft jetzt
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 20 Mai 2018, 12:15:43
alternativ lege mal das state mit 'add even't an :
trigger_cnt:*
und wähle das dann in der dropdownlist , ob es damit geht . das hochzählende event ist etwas merkwürdig.

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 20 Mai 2018, 12:20:59


... das hochzählende event ist etwas merkwürdig.

gruss Byte09

Das liegt wahrscheinlich daran, dass ich als Trigger Device nicht den 4-fach Taster genommen habe sondern den Taster1 davon. Dort wird der State immer hochgetriggert.

Im Screenshot ist zu sehen, wie ich es abgeändert habe, so klappt es nun
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 20 Mai 2018, 12:31:40
Das liegt wahrscheinlich daran, dass ich als Trigger Device nicht den 4-fach Taster genommen habe sondern den Taster1 davon. Dort wird der State immer hochgetriggert.

Im Screenshot ist zu sehen, wie ich es abgeändert habe, so klappt es nun

ok, prima.

am rande: wenn du hochzählende events oder ähnliches hast , solltest du nach der konfiguration die option 'Save incomming events : ' deaktivieren, da er diese daten sonst alle speichert ( ist dann nicht wirklich systemschonend )

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 20 Mai 2018, 12:36:08
ok, bin jetzt noch auf das update gespannt, wegen dem Blinken, was du gestern in meinem anderen Thema angekündigt hast.
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 20 Mai 2018, 12:39:59
wird noch 1 , 2 Stunden dauern  ;)  ..... läuft bei mir zur Probe
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 20 Mai 2018, 12:49:06
Keine Hektik!  ;D

Verstehe ich das Richtig
bei Repeats gebe ich die Anzahl der Wiederholungen an und bei repeatdelay die Pausenlänge?

Wie gebe ich an, wie lange die Lampe an bleiben soll?
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 20 Mai 2018, 13:15:03
Keine Hektik!  ;D

Verstehe ich das Richtig
bei Repeats gebe ich die Anzahl der Wiederholungen an und bei repeatdelay die Pausenlänge?

Wie gebe ich an, wie lange die Lampe an bleiben soll?

in der einfachsten variante ergiebt sich das [blinkzeit = Anzahl der Wiederholungen * Pausenlänge ]

d.H
bei 6 wiederholungen und einer pausenlängevon 1 sec ergiebt sich eine Blinkzeit von 6 sekunden
bei 12 wiederholungen und einer pausenlängevon 0.5 sec ergiebt sich eine Blinkzeit von 6 sekunden
etc..
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 20 Mai 2018, 13:19:16
in der einfachsten variante ergiebt sich das [blinkzeit = Anzahl der Wiederholungen * Pausenlänge ]

d.H
bei 6 wiederholungen und einer pausenlängevon 1 sec ergiebt sich eine Blinkzeit von 6 sekunden
bei 12 wiederholungen und einer pausenlängevon 0.5 sec ergiebt sich eine Blinkzeit von 6 sekunden
etc..

Ok, also stelle ich alles so ein wie in deinem Screenshot
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 20 Mai 2018, 13:21:18
Ok, also stelle ich alles so ein wie in deinem Screenshot

nein , da habe ich etwas anderes probiert kommt ein wenig darauf was du triggerst , aber fast. schreibe ich dir dann
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 20 Mai 2018, 13:52:20
V1.43 im Git verfügbar.

- diverse kleinere Fehler behoben

- gravierenden fehler in Zusammenhang Notify-Mode und Delays behoben

- Funktionserweiterung Events: bisher boten die triggerbaren Events nur in der 'letzten Stelle' die Möglichkeit von Mehrfachangaben  z.B.
state:(on/off) Hier wird es Möglich sein , auch bei dem Readingnamen Mehrfachangaben zu machen  , in dieser Form (state/rgb):(on/off) Dieses zielt insbesondere auf die komfotablerer Einbindung von Dashbuttons ab, da damit folgende Eventabfragen Möglich werden , ohne das in den jeweiligen 'affected devices' nochmals eine Conditionabfrage gemacht werden muss :
(ac-63-be-8c-d2-X1/ac-63-be-8c-d2-X2/ac-63-be-8c-d2-X3):short
- Funktionserweiternug MSwitch_Mode: zu den bisherigen Modes 'Full' und 'Notif' wird der Mode 'Toggle' kommen. In diesm Mode wird in den Triggerdetails statt der bisherigen Felder "execute 'on' commands, execute 'off' commands' ... " nur ein Feld verfügbar sein , 'toggle Mswitch and execute comands". Bei eintreffen des hier definierten Events Toggelt sich das MSwitch Device selber und führt alle Kommandos des dann aktiven Zweiges aus - manuelles umschalten über webcmd ist ebenfalls möglich.

- Funktionserweiternug Expert-Mode : im Expertenmode gibt es nun zusätliche Felder 'Repeats: ' und 'Repeatdelay in sec:' . Die Vorgabe hier ist jeweils 0 , was einem leeren Feld entspricht.
Bei ausgefüllten Feldern wird der jeweilige befehl bei Auslösung um angegebene Anszahl (Repeats)  mit einer Pause von 'Repeatdelay' wiederholt.

- erste Comandref ( Deutsch ) eingefügt, hierfür ein danke an @Andies, der sie erstellt hat.


Da es doch einige Änderungen gibt , stelle ich hier im Anhang die jetzige Version (V1.42) nochmal bereit , nur für den Fall der Fälle.

Gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 20 Mai 2018, 14:27:17
Habe die 98_MSwitch.pm heruntergeladen, in den FHEM-Ordner gepackt und Fhem mit shutdown restart neu gestartet. Irgendwas mache ich falsch  :o . Ich habe immer noch Version 1.42 und die Erweiterung MSwitch fehlt
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 20 Mai 2018, 14:44:47
Zitat
Da es doch einige Änderungen gibt , stelle ich hier im Anhang die jetzige Version (V1.42) nochmal bereit , nur für den Fall der Fälle.

 ;)  ... V1.43 über normales Update falls update all https://raw.githubusercontent.com/Byte009/FHEM-MSwitch/master/controls_mswitch.txt bei Update eingetragen , oder update add https://raw.githubusercontent.com/Byte009/FHEM-MSwitch/master/controls_mswitch.txt über Fhem Befehlszeile.

@Thorsten :
wenn du die neuen Funktionen nutzen willst musst du das attribut MSwitch_Expert dann auf 1 setzen.

Gruss Byte09
 
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 20 Mai 2018, 14:45:56
wer lesen kann ist klar im vorteil  ::)
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 20 Mai 2018, 15:12:30
Ich habe jetzt alles so wie auf den beiden Screenshots eingestellt und habe folgenden Effekt:

a)
Taster Flur_Klingel: Licht geht an
anschließend
Taster Klingel_deaktiviert: Licht blinkt 10x im gleichen Rhythmus und geht aus.

b)
Taster Klingel_deaktiviert: nichts passiert
anschließend
Taster Flur_Klingel:  Licht blinkt 10x unregelmäßig und Licht bleibt an


EDIT:

ok, hab´s kapiert. Habe den MSwitch on cmd: Set noch auf toggle gesetzt
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: mark79 am 20 Mai 2018, 20:43:04
Hallo Thomas,

zuerst mal danke für das Update. :)

Ich habe die neue Version heute ausprobiert, aber irgendwie bekomme ich das nicht so richtig hin. Kannst du bitte drüber schauen, habe ein Screenshot angehangen und dazu unten Logs.

Das Problem ist, das ich das Trigger Device, also z.B. ein Dash Button jeweils zwei mal betätigen muss, um das Device ein oder aus zu schalten.
Es sieht so aus, als ob das MSwitch Device zuerst seinen eigenen State schaltet, jedoch nicht das eigentliche Device wie ein LED z.B. "on"  schaltet.

Erst beim zweiten drücken des Dash Buttons schaltet es das LED Licht "on", jedoch ist dann der State von MSwitch auf "off". Als entgegen gesetzt.

Das ist ein bisschen kompliziert zu erklären, ich schreib einfach den Verlauf hier nieder, um das besser zu verstehen:

Ich habe ein Dash_Button im MSwitchToggle Modus zum schalten. Dazu ist die neue Funktion MSwitch_Mode: Toggle aktiviert.

Ausganssituation:
WZ_Bilderrahmen State: OFF und duracell_dash_MSwitch State: off

Dann erfolgt ein Event durch drücken des Dash_Button und folendes passiert... (bis hier noch alles normal)
WZ_Bilderrahmen State: ON und duracell_dash_MSwitch State: on

Ab hier geht es dann los... drücke ich noch mal auf den Dash Button, sollte das WZ_Bilderrahmen Device auch aus gehen, tut es aber nicht.
Sondern nur das MSwitch Device geht aus:
WZ_Bilderrahmen State: ON und duracell_dash_MSwitch State: off

Drücke ich noch noch mal auf den Dash Button, dann passiert folgendes:
WZ_Bilderrahmen State: OFF und duracell_dash_MSwitch State: on

Ein weiteres Event vom Dash_Button:
WZ_Bilderrahmen State: OFF und duracell_dash_MSwitch State: off

Ich habe das mit dem Dash Button und dem Xiaomi Taster ausprobiert, jeweils bei unterschiedlichen Sonoff Steckdosen, einmal mit ESPeasy (0/1) und Tasmota (ON/OFF).

Dazu ist mir noch aufgefallen, das man das MSwitch WEBcmd also on/off nur "on" funktioniert und "off" ohne Funktion ist.

Wäre super, wenn du Zeit hast dort noch mal drüber schauen könntest.. :)

Hier noch ein Log vom Xiaomi Taster:
Fhem log mit Verbose 5 und Xiaomi_Taster click:

2018.05.20 18:13:44 3: Xiaomi_GW: DEV_Read> Name: Xiaomi_Taster SID: 158d00016d7946 Type: switch Status: click
2018.05.20 18:13:44 5: SUB  main::MSwitch_Notify
2018.05.20 18:13:44 5:   xiaomi_ku_licht state: click
2018.05.20 18:13:44 5: xiaomi_ku_licht MSwitch_Notify: triggeron -> state:click  L:1615
2018.05.20 18:13:44 5: xiaomi_ku_licht MSwitch_Notify: triggeroff -> no_trigger  L:1616
2018.05.20 18:13:44 5: xiaomi_ku_licht MSwitch_Notify: triggercmdon -> no_trigger  L:1617
2018.05.20 18:13:44 5: xiaomi_ku_licht MSwitch_Notify: triggercmdoff -> no_trigger  L:1618
2018.05.20 18:13:44 5: Trigger: state  . L:4760
2018.05.20 18:13:44 5: Trigger: state  . L:4796
2018.05.20 18:13:44 5: Trigger: 0 L:4797
2018.05.20 18:13:44 5: Trigger: state . L:4798
2018.05.20 18:13:44 5: Trigger-state-state-: wahr . L:4805
2018.05.20 18:13:44 5: Trigger: click  . L:4760
2018.05.20 18:13:44 5: Trigger: click  . L:4796
2018.05.20 18:13:44 5: Trigger: 0 L:4797
2018.05.20 18:13:44 5: Trigger: click . L:4798
2018.05.20 18:13:44 5: Trigger-click-click-: wahr . L:4805
2018.05.20 18:13:44 5: Toggle -> 0 L:1670
2018.05.20 18:13:44 5:  set -> on L:1671
2018.05.20 18:13:44 5: xiaomi_ku_licht MSwitch_Notify: Togglemode ->schalte MSwitch device  L:1676
2018.05.20 18:13:44 5: xiaomi_ku_licht MSwitch_Notify: Togglemode -> statetest -> -on-   L:1679
2018.05.20 18:13:44 5: xiaomi_ku_licht MSwitch_Notify: Togglemode-cmd -> set xiaomi_ku_licht off  L:1684
2018.05.20 18:13:44 5: args
2018.05.20 18:13:44 5: SUB  main::MSwitch_Set
2018.05.20 18:13:44 5: SUB  main::MSwitch_makeCmdHash
2018.05.20 18:13:44 5: MSwitch_makeCmdHash: KU_Schranklicht-AbsCmd1,MSwitchtoggle,no_action,ON/OFF,,delay1,delay1,000000,000000,,,0,0 L:3469
2018.05.20 18:13:44 5: MSwitch_makeCmdHash: KU_Schranklicht-AbsCmd1 MSwitchtoggle no_action ON/OFF  delay1 delay1 000000 000000   0 0 L:3475
2018.05.20 18:13:44 5: MSwitch_makeCmdHash: KU_Schranklicht-AbsCmd1_delayatonorg ->  000000 L:3485
2018.05.20 18:13:44 5: MSwitch_makeCmdHash:  L:3488
2018.05.20 18:13:44 5: MSwitch_makeCmdHash:  L:3501
2018.05.20 18:13:44 5: MSwitch_makeCmdHash: array12 -0- L:3526
2018.05.20 18:13:44 5: args
2018.05.20 18:13:44 5: SUB  main::MSwitch_Set
2018.05.20 18:13:44 5: SUB  main::MSwitch_Cmd
2018.05.20 18:13:44 5: SUB  main::MSwitch_makeCmdHash
2018.05.20 18:13:44 5: MSwitch_makeCmdHash: KU_Schranklicht-AbsCmd1,MSwitchtoggle,no_action,ON/OFF,,delay1,delay1,000000,000000,,,0,0 L:3469
2018.05.20 18:13:44 5: MSwitch_makeCmdHash: KU_Schranklicht-AbsCmd1 MSwitchtoggle no_action ON/OFF  delay1 delay1 000000 000000   0 0 L:3475
2018.05.20 18:13:44 5: MSwitch_makeCmdHash: KU_Schranklicht-AbsCmd1_delayatonorg ->  000000 L:3485
2018.05.20 18:13:44 5: MSwitch_makeCmdHash:  L:3488
2018.05.20 18:13:44 5: MSwitch_makeCmdHash:  L:3501
2018.05.20 18:13:44 5: MSwitch_makeCmdHash: array12 -0- L:3526

Fhem log mit Verbose 5 und Xiaomi_Taster click:
2018.05.20 18:14:27 3: Xiaomi_GW: DEV_Read> Name: Xiaomi_Motion SID: 158d0001d926ca Type: motion Status: motion
2018.05.20 18:14:28 3: Xiaomi_GW: DEV_Read> Name: Xiaomi_Taster SID: 158d00016d7946 Type: switch Status: click
2018.05.20 18:14:28 5: SUB  main::MSwitch_Notify
2018.05.20 18:14:28 5:   xiaomi_ku_licht state: click
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_Notify: triggeron -> state:click  L:1615
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_Notify: triggeroff -> no_trigger  L:1616
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_Notify: triggercmdon -> no_trigger  L:1617
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_Notify: triggercmdoff -> no_trigger  L:1618
2018.05.20 18:14:28 5: Trigger: state  . L:4760
2018.05.20 18:14:28 5: Trigger: state  . L:4796
2018.05.20 18:14:28 5: Trigger: 0 L:4797
2018.05.20 18:14:28 5: Trigger: state . L:4798
2018.05.20 18:14:28 5: Trigger-state-state-: wahr . L:4805
2018.05.20 18:14:28 5: Trigger: click  . L:4760
2018.05.20 18:14:28 5: Trigger: click  . L:4796
2018.05.20 18:14:28 5: Trigger: 0 L:4797
2018.05.20 18:14:28 5: Trigger: click . L:4798
2018.05.20 18:14:28 5: Trigger-click-click-: wahr . L:4805
2018.05.20 18:14:28 5: Toggle -> 0 L:1670
2018.05.20 18:14:28 5:  set -> on L:1671
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_Notify: Togglemode ->schalte MSwitch device  L:1676
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_Notify: Togglemode -> statetest -> -off-   L:1679
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_Notify: Togglemode-cmd -> set xiaomi_ku_licht on  L:1684
2018.05.20 18:14:28 5: args
2018.05.20 18:14:28 5: SUB  main::MSwitch_Set
2018.05.20 18:14:28 5: SUB  main::MSwitch_makeCmdHash
2018.05.20 18:14:28 5: MSwitch_makeCmdHash: KU_Schranklicht-AbsCmd1,MSwitchtoggle,no_action,ON/OFF,,delay1,delay1,000000,000000,,,0,0 L:3469
2018.05.20 18:14:28 5: MSwitch_makeCmdHash: KU_Schranklicht-AbsCmd1 MSwitchtoggle no_action ON/OFF  delay1 delay1 000000 000000   0 0 L:3475
2018.05.20 18:14:28 5: MSwitch_makeCmdHash: KU_Schranklicht-AbsCmd1_delayatonorg ->  000000 L:3485
2018.05.20 18:14:28 5: MSwitch_makeCmdHash:  L:3488
2018.05.20 18:14:28 5: MSwitch_makeCmdHash:  L:3501
2018.05.20 18:14:28 5: MSwitch_makeCmdHash: array12 -0- L:3526
2018.05.20 18:14:28 3: xiaomi_ku_licht MSwitch_Set: aufruf MSwitch_checkcondition L:1016
2018.05.20 18:14:28 5: SUB  main::MSwitch_checkcondition
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_checkcondition: ->  3970
2018.05.20 18:14:28 3: xiaomi_ku_licht MSwitch_Set: Befehlsausfuehrung -> set KU_Schranklicht MSwitchtoggle ON/OFF L:1025
2018.05.20 18:14:28 5: args
2018.05.20 18:14:28 5: SUB  main::MSwitch_Set
2018.05.20 18:14:28 5: SUB  main::MSwitch_Cmd
2018.05.20 18:14:28 5: SUB  main::MSwitch_makeCmdHash
2018.05.20 18:14:28 5: MSwitch_makeCmdHash: KU_Schranklicht-AbsCmd1,MSwitchtoggle,no_action,ON/OFF,,delay1,delay1,000000,000000,,,0,0 L:3469
2018.05.20 18:14:28 5: MSwitch_makeCmdHash: KU_Schranklicht-AbsCmd1 MSwitchtoggle no_action ON/OFF  delay1 delay1 000000 000000   0 0 L:3475
2018.05.20 18:14:28 5: MSwitch_makeCmdHash: KU_Schranklicht-AbsCmd1_delayatonorg ->  000000 L:3485
2018.05.20 18:14:28 5: MSwitch_makeCmdHash:  L:3488
2018.05.20 18:14:28 5: MSwitch_makeCmdHash:  L:3501
2018.05.20 18:14:28 5: MSwitch_makeCmdHash: array12 -0- L:3526
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_Set:  set KU_Schranklicht MSwitchtoggle ON/OFF|KU_Schranklicht-AbsCmd1 1251
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_Set:  cmds -> set KU_Schranklicht MSwitchtoggle ON/OFF 1257
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_Set:  device -> KU_Schranklicht-AbsCmd1 1258
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_Set:  set KU_Schranklicht MSwitchtoggle ON/OFF 1263
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_toggle:  set KU_Schranklicht MSwitchtoggle ON/OFF 1337
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_toggle 1:  set 1340
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_toggle 2:  KU_Schranklicht 1341
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_toggle 3:    1342
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_toggle 4:  ON/OFF 1343
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_toggle cmd0:  ON 1351
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_toggle cmd1:  OFF 1352
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_toggle cmd2:  state 1353
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_toggle cmd3:  ON 1354
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_toggle cmd4:  OFF 1355
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_toggle: cmd1 -> set KU_Schranklicht ON 1360
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_toggle: cmd2 -> set KU_Schranklicht OFF 1361
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_toggle: test reading state -> OFF 1367
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_toggle: neuer befehl -> set KU_Schranklicht ON 1383
2018.05.20 18:14:28 5: xiaomi_ku_licht errechneter befehl:  set KU_Schranklicht ON 1267
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_Exec_Notif:Repeater 0 1276
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_Exec_Notif:Repeater 0 1277
2018.05.20 18:14:28 5: args
2018.05.20 18:14:28 5: SUB  main::MSwitch_Set


Fhem log mit Verbose 5 und Xiaomi_Taster click:

2018.05.20 18:15:32 3: Xiaomi_GW: DEV_Read> Name: Xiaomi_Taster SID: 158d00016d7946 Type: switch Status: click
2018.05.20 18:15:32 5: SUB  main::MSwitch_Notify
2018.05.20 18:15:32 5:   xiaomi_ku_licht state: click
2018.05.20 18:15:32 5: xiaomi_ku_licht MSwitch_Notify: triggeron -> state:click  L:1615
2018.05.20 18:15:32 5: xiaomi_ku_licht MSwitch_Notify: triggeroff -> no_trigger  L:1616
2018.05.20 18:15:32 5: xiaomi_ku_licht MSwitch_Notify: triggercmdon -> no_trigger  L:1617
2018.05.20 18:15:32 5: xiaomi_ku_licht MSwitch_Notify: triggercmdoff -> no_trigger  L:1618
2018.05.20 18:15:32 5: Trigger: state  . L:4760
2018.05.20 18:15:32 5: Trigger: state  . L:4796
2018.05.20 18:15:32 5: Trigger: 0 L:4797
2018.05.20 18:15:32 5: Trigger: state . L:4798
2018.05.20 18:15:32 5: Trigger-state-state-: wahr . L:4805
2018.05.20 18:15:32 5: Trigger: click  . L:4760
2018.05.20 18:15:32 5: Trigger: click  . L:4796
2018.05.20 18:15:32 5: Trigger: 0 L:4797
2018.05.20 18:15:32 5: Trigger: click . L:4798
2018.05.20 18:15:32 5: Trigger-click-click-: wahr . L:4805
2018.05.20 18:15:32 5: Toggle -> 0 L:1670
2018.05.20 18:15:32 5:  set -> on L:1671
2018.05.20 18:15:32 5: xiaomi_ku_licht MSwitch_Notify: Togglemode ->schalte MSwitch device  L:1676
2018.05.20 18:15:32 5: xiaomi_ku_licht MSwitch_Notify: Togglemode -> statetest -> -on-   L:1679
2018.05.20 18:15:32 5: xiaomi_ku_licht MSwitch_Notify: Togglemode-cmd -> set xiaomi_ku_licht off  L:1684
2018.05.20 18:15:32 5: args
2018.05.20 18:15:32 5: SUB  main::MSwitch_Set
2018.05.20 18:15:32 5: SUB  main::MSwitch_makeCmdHash
2018.05.20 18:15:32 5: MSwitch_makeCmdHash: KU_Schranklicht-AbsCmd1,MSwitchtoggle,no_action,ON/OFF,,delay1,delay1,000000,000000,,,0,0 L:3469
2018.05.20 18:15:32 5: MSwitch_makeCmdHash: KU_Schranklicht-AbsCmd1 MSwitchtoggle no_action ON/OFF  delay1 delay1 000000 000000   0 0 L:3475
2018.05.20 18:15:32 5: MSwitch_makeCmdHash: KU_Schranklicht-AbsCmd1_delayatonorg ->  000000 L:3485
2018.05.20 18:15:32 5: MSwitch_makeCmdHash:  L:3488
2018.05.20 18:15:32 5: MSwitch_makeCmdHash:  L:3501
2018.05.20 18:15:32 5: MSwitch_makeCmdHash: array12 -0- L:3526
2018.05.20 18:15:32 5: args
2018.05.20 18:15:32 5: SUB  main::MSwitch_Set
2018.05.20 18:15:32 5: SUB  main::MSwitch_Cmd
2018.05.20 18:15:32 5: SUB  main::MSwitch_makeCmdHash
2018.05.20 18:15:32 5: MSwitch_makeCmdHash: KU_Schranklicht-AbsCmd1,MSwitchtoggle,no_action,ON/OFF,,delay1,delay1,000000,000000,,,0,0 L:3469
2018.05.20 18:15:32 5: MSwitch_makeCmdHash: KU_Schranklicht-AbsCmd1 MSwitchtoggle no_action ON/OFF  delay1 delay1 000000 000000   0 0 L:3475
2018.05.20 18:15:32 5: MSwitch_makeCmdHash: KU_Schranklicht-AbsCmd1_delayatonorg ->  000000 L:3485
2018.05.20 18:15:32 5: MSwitch_makeCmdHash:  L:3488
2018.05.20 18:15:32 5: MSwitch_makeCmdHash:  L:3501
2018.05.20 18:15:32 5: MSwitch_makeCmdHash: array12 -0- L:3526


Fhem log mit Verbose 5 und Xiaomi_Taster click:

2018.05.20 18:15:49 3: Xiaomi_GW: DEV_Read> Name: Xiaomi_Taster SID: 158d00016d7946 Type: switch Status: click
2018.05.20 18:15:49 5: SUB  main::MSwitch_Notify
2018.05.20 18:15:49 5:   xiaomi_ku_licht state: click
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_Notify: triggeron -> state:click  L:1615
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_Notify: triggeroff -> no_trigger  L:1616
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_Notify: triggercmdon -> no_trigger  L:1617
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_Notify: triggercmdoff -> no_trigger  L:1618
2018.05.20 18:15:49 5: Trigger: state  . L:4760
2018.05.20 18:15:49 5: Trigger: state  . L:4796
2018.05.20 18:15:49 5: Trigger: 0 L:4797
2018.05.20 18:15:49 5: Trigger: state . L:4798
2018.05.20 18:15:49 5: Trigger-state-state-: wahr . L:4805
2018.05.20 18:15:49 5: Trigger: click  . L:4760
2018.05.20 18:15:49 5: Trigger: click  . L:4796
2018.05.20 18:15:49 5: Trigger: 0 L:4797
2018.05.20 18:15:49 5: Trigger: click . L:4798
2018.05.20 18:15:49 5: Trigger-click-click-: wahr . L:4805
2018.05.20 18:15:49 5: Toggle -> 0 L:1670
2018.05.20 18:15:49 5:  set -> on L:1671
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_Notify: Togglemode ->schalte MSwitch device  L:1676
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_Notify: Togglemode -> statetest -> -off-   L:1679
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_Notify: Togglemode-cmd -> set xiaomi_ku_licht on  L:1684
2018.05.20 18:15:49 5: args
2018.05.20 18:15:49 5: SUB  main::MSwitch_Set
2018.05.20 18:15:49 5: SUB  main::MSwitch_makeCmdHash
2018.05.20 18:15:49 5: MSwitch_makeCmdHash: KU_Schranklicht-AbsCmd1,MSwitchtoggle,no_action,ON/OFF,,delay1,delay1,000000,000000,,,0,0 L:3469
2018.05.20 18:15:49 5: MSwitch_makeCmdHash: KU_Schranklicht-AbsCmd1 MSwitchtoggle no_action ON/OFF  delay1 delay1 000000 000000   0 0 L:3475
2018.05.20 18:15:49 5: MSwitch_makeCmdHash: KU_Schranklicht-AbsCmd1_delayatonorg ->  000000 L:3485
2018.05.20 18:15:49 5: MSwitch_makeCmdHash:  L:3488
2018.05.20 18:15:49 5: MSwitch_makeCmdHash:  L:3501
2018.05.20 18:15:49 5: MSwitch_makeCmdHash: array12 -0- L:3526
2018.05.20 18:15:49 3: xiaomi_ku_licht MSwitch_Set: aufruf MSwitch_checkcondition L:1016
2018.05.20 18:15:49 5: SUB  main::MSwitch_checkcondition
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_checkcondition: ->  3970
2018.05.20 18:15:49 3: xiaomi_ku_licht MSwitch_Set: Befehlsausfuehrung -> set KU_Schranklicht MSwitchtoggle ON/OFF L:1025
2018.05.20 18:15:49 5: args
2018.05.20 18:15:49 5: SUB  main::MSwitch_Set
2018.05.20 18:15:49 5: SUB  main::MSwitch_Cmd
2018.05.20 18:15:49 5: SUB  main::MSwitch_makeCmdHash
2018.05.20 18:15:49 5: MSwitch_makeCmdHash: KU_Schranklicht-AbsCmd1,MSwitchtoggle,no_action,ON/OFF,,delay1,delay1,000000,000000,,,0,0 L:3469
2018.05.20 18:15:49 5: MSwitch_makeCmdHash: KU_Schranklicht-AbsCmd1 MSwitchtoggle no_action ON/OFF  delay1 delay1 000000 000000   0 0 L:3475
2018.05.20 18:15:49 5: MSwitch_makeCmdHash: KU_Schranklicht-AbsCmd1_delayatonorg ->  000000 L:3485
2018.05.20 18:15:49 5: MSwitch_makeCmdHash:  L:3488
2018.05.20 18:15:49 5: MSwitch_makeCmdHash:  L:3501
2018.05.20 18:15:49 5: MSwitch_makeCmdHash: array12 -0- L:3526
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_Set:  set KU_Schranklicht MSwitchtoggle ON/OFF|KU_Schranklicht-AbsCmd1 1251
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_Set:  cmds -> set KU_Schranklicht MSwitchtoggle ON/OFF 1257
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_Set:  device -> KU_Schranklicht-AbsCmd1 1258
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_Set:  set KU_Schranklicht MSwitchtoggle ON/OFF 1263
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_toggle:  set KU_Schranklicht MSwitchtoggle ON/OFF 1337
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_toggle 1:  set 1340
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_toggle 2:  KU_Schranklicht 1341
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_toggle 3:    1342
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_toggle 4:  ON/OFF 1343
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_toggle cmd0:  ON 1351
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_toggle cmd1:  OFF 1352
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_toggle cmd2:  state 1353
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_toggle cmd3:  ON 1354
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_toggle cmd4:  OFF 1355
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_toggle: cmd1 -> set KU_Schranklicht ON 1360
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_toggle: cmd2 -> set KU_Schranklicht OFF 1361
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_toggle: test reading state -> ON 1367
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_toggle: neuer befehl -> set KU_Schranklicht OFF 1383
2018.05.20 18:15:49 5: xiaomi_ku_licht errechneter befehl:  set KU_Schranklicht OFF 1267
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_Exec_Notif:Repeater 0 1276
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_Exec_Notif:Repeater 0 1277
2018.05.20 18:15:49 5: args
2018.05.20 18:15:49 5: SUB  main::MSwitch_Set

Viele Grüße
Mark
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 20 Mai 2018, 21:37:56
Schaffe es erst morgen früh mir das anzuschauen.

Dazu ist mir noch aufgefallen, das man das MSwitch WEBcmd also on/off nur "on" funktioniert und "off" ohne Funktion ist.
definitiv ein fehler, die felder müssen ausgeblendet werden im togglemode
siehe nächsten post !

Gruss thomas

Gesendet von meinem SM-G900F mit Tapatalk

Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 20 Mai 2018, 21:53:40
Hallo Thomas,

zuerst mal danke für das Update. :)

Ich habe die neue Version heute ausprobiert, aber irgendwie bekomme ich das nicht so richtig hin. Kannst du bitte drüber schauen, habe ein Screenshot angehangen und dazu unten Logs.

Das Problem ist, das ich das Trigger Device, also z.B. ein Dash Button jeweils zwei mal betätigen muss, um das Device ein oder aus zu schalten.
Es sieht so aus, als ob das MSwitch Device zuerst seinen eigenen State schaltet, jedoch nicht das eigentliche Device wie ein LED z.B. "on"  schaltet.

Erst beim zweiten drücken des Dash Buttons schaltet es das LED Licht "on", jedoch ist dann der State von MSwitch auf "off". Als entgegen gesetzt.

Das ist ein bisschen kompliziert zu erklären, ich schreib einfach den Verlauf hier nieder, um das besser zu verstehen:

Ich habe ein Dash_Button im MSwitchToggle Modus zum schalten. Dazu ist die neue Funktion MSwitch_Mode: Toggle aktiviert.

Ausganssituation:
WZ_Bilderrahmen State: OFF und duracell_dash_MSwitch State: off

Dann erfolgt ein Event durch drücken des Dash_Button und folendes passiert... (bis hier noch alles normal)
WZ_Bilderrahmen State: ON und duracell_dash_MSwitch State: on

Ab hier geht es dann los... drücke ich noch mal auf den Dash Button, sollte das WZ_Bilderrahmen Device auch aus gehen, tut es aber nicht.
Sondern nur das MSwitch Device geht aus:
WZ_Bilderrahmen State: ON und duracell_dash_MSwitch State: off

Drücke ich noch noch mal auf den Dash Button, dann passiert folgendes:
WZ_Bilderrahmen State: OFF und duracell_dash_MSwitch State: on

Ein weiteres Event vom Dash_Button:
WZ_Bilderrahmen State: OFF und duracell_dash_MSwitch State: off

Ich habe das mit dem Dash Button und dem Xiaomi Taster ausprobiert, jeweils bei unterschiedlichen Sonoff Steckdosen, einmal mit ESPeasy (0/1) und Tasmota (ON/OFF).

Dazu ist mir noch aufgefallen, das man das MSwitch WEBcmd also on/off nur "on" funktioniert und "off" ohne Funktion ist.

Wäre super, wenn du Zeit hast dort noch mal drüber schauen könntest.. :)

Hier noch ein Log vom Xiaomi Taster:
Fhem log mit Verbose 5 und Xiaomi_Taster click:

2018.05.20 18:13:44 3: Xiaomi_GW: DEV_Read> Name: Xiaomi_Taster SID: 158d00016d7946 Type: switch Status: click
2018.05.20 18:13:44 5: SUB  main::MSwitch_Notify
2018.05.20 18:13:44 5:   xiaomi_ku_licht state: click
2018.05.20 18:13:44 5: xiaomi_ku_licht MSwitch_Notify: triggeron -> state:click  L:1615
2018.05.20 18:13:44 5: xiaomi_ku_licht MSwitch_Notify: triggeroff -> no_trigger  L:1616
2018.05.20 18:13:44 5: xiaomi_ku_licht MSwitch_Notify: triggercmdon -> no_trigger  L:1617
2018.05.20 18:13:44 5: xiaomi_ku_licht MSwitch_Notify: triggercmdoff -> no_trigger  L:1618
2018.05.20 18:13:44 5: Trigger: state  . L:4760
2018.05.20 18:13:44 5: Trigger: state  . L:4796
2018.05.20 18:13:44 5: Trigger: 0 L:4797
2018.05.20 18:13:44 5: Trigger: state . L:4798
2018.05.20 18:13:44 5: Trigger-state-state-: wahr . L:4805
2018.05.20 18:13:44 5: Trigger: click  . L:4760
2018.05.20 18:13:44 5: Trigger: click  . L:4796
2018.05.20 18:13:44 5: Trigger: 0 L:4797
2018.05.20 18:13:44 5: Trigger: click . L:4798
2018.05.20 18:13:44 5: Trigger-click-click-: wahr . L:4805
2018.05.20 18:13:44 5: Toggle -> 0 L:1670
2018.05.20 18:13:44 5:  set -> on L:1671
2018.05.20 18:13:44 5: xiaomi_ku_licht MSwitch_Notify: Togglemode ->schalte MSwitch device  L:1676
2018.05.20 18:13:44 5: xiaomi_ku_licht MSwitch_Notify: Togglemode -> statetest -> -on-   L:1679
2018.05.20 18:13:44 5: xiaomi_ku_licht MSwitch_Notify: Togglemode-cmd -> set xiaomi_ku_licht off  L:1684
2018.05.20 18:13:44 5: args
2018.05.20 18:13:44 5: SUB  main::MSwitch_Set
2018.05.20 18:13:44 5: SUB  main::MSwitch_makeCmdHash
2018.05.20 18:13:44 5: MSwitch_makeCmdHash: KU_Schranklicht-AbsCmd1,MSwitchtoggle,no_action,ON/OFF,,delay1,delay1,000000,000000,,,0,0 L:3469
2018.05.20 18:13:44 5: MSwitch_makeCmdHash: KU_Schranklicht-AbsCmd1 MSwitchtoggle no_action ON/OFF  delay1 delay1 000000 000000   0 0 L:3475
2018.05.20 18:13:44 5: MSwitch_makeCmdHash: KU_Schranklicht-AbsCmd1_delayatonorg ->  000000 L:3485
2018.05.20 18:13:44 5: MSwitch_makeCmdHash:  L:3488
2018.05.20 18:13:44 5: MSwitch_makeCmdHash:  L:3501
2018.05.20 18:13:44 5: MSwitch_makeCmdHash: array12 -0- L:3526
2018.05.20 18:13:44 5: args
2018.05.20 18:13:44 5: SUB  main::MSwitch_Set
2018.05.20 18:13:44 5: SUB  main::MSwitch_Cmd
2018.05.20 18:13:44 5: SUB  main::MSwitch_makeCmdHash
2018.05.20 18:13:44 5: MSwitch_makeCmdHash: KU_Schranklicht-AbsCmd1,MSwitchtoggle,no_action,ON/OFF,,delay1,delay1,000000,000000,,,0,0 L:3469
2018.05.20 18:13:44 5: MSwitch_makeCmdHash: KU_Schranklicht-AbsCmd1 MSwitchtoggle no_action ON/OFF  delay1 delay1 000000 000000   0 0 L:3475
2018.05.20 18:13:44 5: MSwitch_makeCmdHash: KU_Schranklicht-AbsCmd1_delayatonorg ->  000000 L:3485
2018.05.20 18:13:44 5: MSwitch_makeCmdHash:  L:3488
2018.05.20 18:13:44 5: MSwitch_makeCmdHash:  L:3501
2018.05.20 18:13:44 5: MSwitch_makeCmdHash: array12 -0- L:3526

Fhem log mit Verbose 5 und Xiaomi_Taster click:
2018.05.20 18:14:27 3: Xiaomi_GW: DEV_Read> Name: Xiaomi_Motion SID: 158d0001d926ca Type: motion Status: motion
2018.05.20 18:14:28 3: Xiaomi_GW: DEV_Read> Name: Xiaomi_Taster SID: 158d00016d7946 Type: switch Status: click
2018.05.20 18:14:28 5: SUB  main::MSwitch_Notify
2018.05.20 18:14:28 5:   xiaomi_ku_licht state: click
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_Notify: triggeron -> state:click  L:1615
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_Notify: triggeroff -> no_trigger  L:1616
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_Notify: triggercmdon -> no_trigger  L:1617
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_Notify: triggercmdoff -> no_trigger  L:1618
2018.05.20 18:14:28 5: Trigger: state  . L:4760
2018.05.20 18:14:28 5: Trigger: state  . L:4796
2018.05.20 18:14:28 5: Trigger: 0 L:4797
2018.05.20 18:14:28 5: Trigger: state . L:4798
2018.05.20 18:14:28 5: Trigger-state-state-: wahr . L:4805
2018.05.20 18:14:28 5: Trigger: click  . L:4760
2018.05.20 18:14:28 5: Trigger: click  . L:4796
2018.05.20 18:14:28 5: Trigger: 0 L:4797
2018.05.20 18:14:28 5: Trigger: click . L:4798
2018.05.20 18:14:28 5: Trigger-click-click-: wahr . L:4805
2018.05.20 18:14:28 5: Toggle -> 0 L:1670
2018.05.20 18:14:28 5:  set -> on L:1671
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_Notify: Togglemode ->schalte MSwitch device  L:1676
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_Notify: Togglemode -> statetest -> -off-   L:1679
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_Notify: Togglemode-cmd -> set xiaomi_ku_licht on  L:1684
2018.05.20 18:14:28 5: args
2018.05.20 18:14:28 5: SUB  main::MSwitch_Set
2018.05.20 18:14:28 5: SUB  main::MSwitch_makeCmdHash
2018.05.20 18:14:28 5: MSwitch_makeCmdHash: KU_Schranklicht-AbsCmd1,MSwitchtoggle,no_action,ON/OFF,,delay1,delay1,000000,000000,,,0,0 L:3469
2018.05.20 18:14:28 5: MSwitch_makeCmdHash: KU_Schranklicht-AbsCmd1 MSwitchtoggle no_action ON/OFF  delay1 delay1 000000 000000   0 0 L:3475
2018.05.20 18:14:28 5: MSwitch_makeCmdHash: KU_Schranklicht-AbsCmd1_delayatonorg ->  000000 L:3485
2018.05.20 18:14:28 5: MSwitch_makeCmdHash:  L:3488
2018.05.20 18:14:28 5: MSwitch_makeCmdHash:  L:3501
2018.05.20 18:14:28 5: MSwitch_makeCmdHash: array12 -0- L:3526
2018.05.20 18:14:28 3: xiaomi_ku_licht MSwitch_Set: aufruf MSwitch_checkcondition L:1016
2018.05.20 18:14:28 5: SUB  main::MSwitch_checkcondition
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_checkcondition: ->  3970
2018.05.20 18:14:28 3: xiaomi_ku_licht MSwitch_Set: Befehlsausfuehrung -> set KU_Schranklicht MSwitchtoggle ON/OFF L:1025
2018.05.20 18:14:28 5: args
2018.05.20 18:14:28 5: SUB  main::MSwitch_Set
2018.05.20 18:14:28 5: SUB  main::MSwitch_Cmd
2018.05.20 18:14:28 5: SUB  main::MSwitch_makeCmdHash
2018.05.20 18:14:28 5: MSwitch_makeCmdHash: KU_Schranklicht-AbsCmd1,MSwitchtoggle,no_action,ON/OFF,,delay1,delay1,000000,000000,,,0,0 L:3469
2018.05.20 18:14:28 5: MSwitch_makeCmdHash: KU_Schranklicht-AbsCmd1 MSwitchtoggle no_action ON/OFF  delay1 delay1 000000 000000   0 0 L:3475
2018.05.20 18:14:28 5: MSwitch_makeCmdHash: KU_Schranklicht-AbsCmd1_delayatonorg ->  000000 L:3485
2018.05.20 18:14:28 5: MSwitch_makeCmdHash:  L:3488
2018.05.20 18:14:28 5: MSwitch_makeCmdHash:  L:3501
2018.05.20 18:14:28 5: MSwitch_makeCmdHash: array12 -0- L:3526
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_Set:  set KU_Schranklicht MSwitchtoggle ON/OFF|KU_Schranklicht-AbsCmd1 1251
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_Set:  cmds -> set KU_Schranklicht MSwitchtoggle ON/OFF 1257
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_Set:  device -> KU_Schranklicht-AbsCmd1 1258
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_Set:  set KU_Schranklicht MSwitchtoggle ON/OFF 1263
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_toggle:  set KU_Schranklicht MSwitchtoggle ON/OFF 1337
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_toggle 1:  set 1340
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_toggle 2:  KU_Schranklicht 1341
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_toggle 3:    1342
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_toggle 4:  ON/OFF 1343
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_toggle cmd0:  ON 1351
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_toggle cmd1:  OFF 1352
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_toggle cmd2:  state 1353
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_toggle cmd3:  ON 1354
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_toggle cmd4:  OFF 1355
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_toggle: cmd1 -> set KU_Schranklicht ON 1360
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_toggle: cmd2 -> set KU_Schranklicht OFF 1361
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_toggle: test reading state -> OFF 1367
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_toggle: neuer befehl -> set KU_Schranklicht ON 1383
2018.05.20 18:14:28 5: xiaomi_ku_licht errechneter befehl:  set KU_Schranklicht ON 1267
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_Exec_Notif:Repeater 0 1276
2018.05.20 18:14:28 5: xiaomi_ku_licht MSwitch_Exec_Notif:Repeater 0 1277
2018.05.20 18:14:28 5: args
2018.05.20 18:14:28 5: SUB  main::MSwitch_Set


Fhem log mit Verbose 5 und Xiaomi_Taster click:

2018.05.20 18:15:32 3: Xiaomi_GW: DEV_Read> Name: Xiaomi_Taster SID: 158d00016d7946 Type: switch Status: click
2018.05.20 18:15:32 5: SUB  main::MSwitch_Notify
2018.05.20 18:15:32 5:   xiaomi_ku_licht state: click
2018.05.20 18:15:32 5: xiaomi_ku_licht MSwitch_Notify: triggeron -> state:click  L:1615
2018.05.20 18:15:32 5: xiaomi_ku_licht MSwitch_Notify: triggeroff -> no_trigger  L:1616
2018.05.20 18:15:32 5: xiaomi_ku_licht MSwitch_Notify: triggercmdon -> no_trigger  L:1617
2018.05.20 18:15:32 5: xiaomi_ku_licht MSwitch_Notify: triggercmdoff -> no_trigger  L:1618
2018.05.20 18:15:32 5: Trigger: state  . L:4760
2018.05.20 18:15:32 5: Trigger: state  . L:4796
2018.05.20 18:15:32 5: Trigger: 0 L:4797
2018.05.20 18:15:32 5: Trigger: state . L:4798
2018.05.20 18:15:32 5: Trigger-state-state-: wahr . L:4805
2018.05.20 18:15:32 5: Trigger: click  . L:4760
2018.05.20 18:15:32 5: Trigger: click  . L:4796
2018.05.20 18:15:32 5: Trigger: 0 L:4797
2018.05.20 18:15:32 5: Trigger: click . L:4798
2018.05.20 18:15:32 5: Trigger-click-click-: wahr . L:4805
2018.05.20 18:15:32 5: Toggle -> 0 L:1670
2018.05.20 18:15:32 5:  set -> on L:1671
2018.05.20 18:15:32 5: xiaomi_ku_licht MSwitch_Notify: Togglemode ->schalte MSwitch device  L:1676
2018.05.20 18:15:32 5: xiaomi_ku_licht MSwitch_Notify: Togglemode -> statetest -> -on-   L:1679
2018.05.20 18:15:32 5: xiaomi_ku_licht MSwitch_Notify: Togglemode-cmd -> set xiaomi_ku_licht off  L:1684
2018.05.20 18:15:32 5: args
2018.05.20 18:15:32 5: SUB  main::MSwitch_Set
2018.05.20 18:15:32 5: SUB  main::MSwitch_makeCmdHash
2018.05.20 18:15:32 5: MSwitch_makeCmdHash: KU_Schranklicht-AbsCmd1,MSwitchtoggle,no_action,ON/OFF,,delay1,delay1,000000,000000,,,0,0 L:3469
2018.05.20 18:15:32 5: MSwitch_makeCmdHash: KU_Schranklicht-AbsCmd1 MSwitchtoggle no_action ON/OFF  delay1 delay1 000000 000000   0 0 L:3475
2018.05.20 18:15:32 5: MSwitch_makeCmdHash: KU_Schranklicht-AbsCmd1_delayatonorg ->  000000 L:3485
2018.05.20 18:15:32 5: MSwitch_makeCmdHash:  L:3488
2018.05.20 18:15:32 5: MSwitch_makeCmdHash:  L:3501
2018.05.20 18:15:32 5: MSwitch_makeCmdHash: array12 -0- L:3526
2018.05.20 18:15:32 5: args
2018.05.20 18:15:32 5: SUB  main::MSwitch_Set
2018.05.20 18:15:32 5: SUB  main::MSwitch_Cmd
2018.05.20 18:15:32 5: SUB  main::MSwitch_makeCmdHash
2018.05.20 18:15:32 5: MSwitch_makeCmdHash: KU_Schranklicht-AbsCmd1,MSwitchtoggle,no_action,ON/OFF,,delay1,delay1,000000,000000,,,0,0 L:3469
2018.05.20 18:15:32 5: MSwitch_makeCmdHash: KU_Schranklicht-AbsCmd1 MSwitchtoggle no_action ON/OFF  delay1 delay1 000000 000000   0 0 L:3475
2018.05.20 18:15:32 5: MSwitch_makeCmdHash: KU_Schranklicht-AbsCmd1_delayatonorg ->  000000 L:3485
2018.05.20 18:15:32 5: MSwitch_makeCmdHash:  L:3488
2018.05.20 18:15:32 5: MSwitch_makeCmdHash:  L:3501
2018.05.20 18:15:32 5: MSwitch_makeCmdHash: array12 -0- L:3526


Fhem log mit Verbose 5 und Xiaomi_Taster click:

2018.05.20 18:15:49 3: Xiaomi_GW: DEV_Read> Name: Xiaomi_Taster SID: 158d00016d7946 Type: switch Status: click
2018.05.20 18:15:49 5: SUB  main::MSwitch_Notify
2018.05.20 18:15:49 5:   xiaomi_ku_licht state: click
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_Notify: triggeron -> state:click  L:1615
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_Notify: triggeroff -> no_trigger  L:1616
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_Notify: triggercmdon -> no_trigger  L:1617
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_Notify: triggercmdoff -> no_trigger  L:1618
2018.05.20 18:15:49 5: Trigger: state  . L:4760
2018.05.20 18:15:49 5: Trigger: state  . L:4796
2018.05.20 18:15:49 5: Trigger: 0 L:4797
2018.05.20 18:15:49 5: Trigger: state . L:4798
2018.05.20 18:15:49 5: Trigger-state-state-: wahr . L:4805
2018.05.20 18:15:49 5: Trigger: click  . L:4760
2018.05.20 18:15:49 5: Trigger: click  . L:4796
2018.05.20 18:15:49 5: Trigger: 0 L:4797
2018.05.20 18:15:49 5: Trigger: click . L:4798
2018.05.20 18:15:49 5: Trigger-click-click-: wahr . L:4805
2018.05.20 18:15:49 5: Toggle -> 0 L:1670
2018.05.20 18:15:49 5:  set -> on L:1671
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_Notify: Togglemode ->schalte MSwitch device  L:1676
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_Notify: Togglemode -> statetest -> -off-   L:1679
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_Notify: Togglemode-cmd -> set xiaomi_ku_licht on  L:1684
2018.05.20 18:15:49 5: args
2018.05.20 18:15:49 5: SUB  main::MSwitch_Set
2018.05.20 18:15:49 5: SUB  main::MSwitch_makeCmdHash
2018.05.20 18:15:49 5: MSwitch_makeCmdHash: KU_Schranklicht-AbsCmd1,MSwitchtoggle,no_action,ON/OFF,,delay1,delay1,000000,000000,,,0,0 L:3469
2018.05.20 18:15:49 5: MSwitch_makeCmdHash: KU_Schranklicht-AbsCmd1 MSwitchtoggle no_action ON/OFF  delay1 delay1 000000 000000   0 0 L:3475
2018.05.20 18:15:49 5: MSwitch_makeCmdHash: KU_Schranklicht-AbsCmd1_delayatonorg ->  000000 L:3485
2018.05.20 18:15:49 5: MSwitch_makeCmdHash:  L:3488
2018.05.20 18:15:49 5: MSwitch_makeCmdHash:  L:3501
2018.05.20 18:15:49 5: MSwitch_makeCmdHash: array12 -0- L:3526
2018.05.20 18:15:49 3: xiaomi_ku_licht MSwitch_Set: aufruf MSwitch_checkcondition L:1016
2018.05.20 18:15:49 5: SUB  main::MSwitch_checkcondition
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_checkcondition: ->  3970
2018.05.20 18:15:49 3: xiaomi_ku_licht MSwitch_Set: Befehlsausfuehrung -> set KU_Schranklicht MSwitchtoggle ON/OFF L:1025
2018.05.20 18:15:49 5: args
2018.05.20 18:15:49 5: SUB  main::MSwitch_Set
2018.05.20 18:15:49 5: SUB  main::MSwitch_Cmd
2018.05.20 18:15:49 5: SUB  main::MSwitch_makeCmdHash
2018.05.20 18:15:49 5: MSwitch_makeCmdHash: KU_Schranklicht-AbsCmd1,MSwitchtoggle,no_action,ON/OFF,,delay1,delay1,000000,000000,,,0,0 L:3469
2018.05.20 18:15:49 5: MSwitch_makeCmdHash: KU_Schranklicht-AbsCmd1 MSwitchtoggle no_action ON/OFF  delay1 delay1 000000 000000   0 0 L:3475
2018.05.20 18:15:49 5: MSwitch_makeCmdHash: KU_Schranklicht-AbsCmd1_delayatonorg ->  000000 L:3485
2018.05.20 18:15:49 5: MSwitch_makeCmdHash:  L:3488
2018.05.20 18:15:49 5: MSwitch_makeCmdHash:  L:3501
2018.05.20 18:15:49 5: MSwitch_makeCmdHash: array12 -0- L:3526
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_Set:  set KU_Schranklicht MSwitchtoggle ON/OFF|KU_Schranklicht-AbsCmd1 1251
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_Set:  cmds -> set KU_Schranklicht MSwitchtoggle ON/OFF 1257
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_Set:  device -> KU_Schranklicht-AbsCmd1 1258
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_Set:  set KU_Schranklicht MSwitchtoggle ON/OFF 1263
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_toggle:  set KU_Schranklicht MSwitchtoggle ON/OFF 1337
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_toggle 1:  set 1340
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_toggle 2:  KU_Schranklicht 1341
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_toggle 3:    1342
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_toggle 4:  ON/OFF 1343
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_toggle cmd0:  ON 1351
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_toggle cmd1:  OFF 1352
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_toggle cmd2:  state 1353
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_toggle cmd3:  ON 1354
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_toggle cmd4:  OFF 1355
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_toggle: cmd1 -> set KU_Schranklicht ON 1360
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_toggle: cmd2 -> set KU_Schranklicht OFF 1361
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_toggle: test reading state -> ON 1367
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_toggle: neuer befehl -> set KU_Schranklicht OFF 1383
2018.05.20 18:15:49 5: xiaomi_ku_licht errechneter befehl:  set KU_Schranklicht OFF 1267
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_Exec_Notif:Repeater 0 1276
2018.05.20 18:15:49 5: xiaomi_ku_licht MSwitch_Exec_Notif:Repeater 0 1277
2018.05.20 18:15:49 5: args
2018.05.20 18:15:49 5: SUB  main::MSwitch_Set

Viele Grüße
Mark

doch nochmal drübergeschaut .

im togglemode musst du den off zweig in den deviceactions auc belegen. entweder auch mit einem MSwitchtoggle ( im grunde dasselbe ) oder du belegst den onzweig mit 'on' und den offzweig mit 'off'.

im togglemode führt er , wenn er off schaltet , den offzweig aus. wenn der nicht belegt ist passiert nichts.

gruss thomas
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: mark79 am 20 Mai 2018, 22:53:04
Danke, das war die Lösung. :) Jetzt funktionieren die beiden Taster und auch das WEB MSwitch on/off korrekt.

Bin davon ausgegangen, man müsste das auch mit "MSwitchToggle" in den "device actions" umsetzen, da lag der Fehler... Aber nun weiß ich bescheid.

Werde mich dann mal ran machen und ein paar Devices ersetzen... danke dir nochmals, das macht einiges einfacher! :)


Viele Grüße
Mark
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 21 Mai 2018, 08:21:15
Update auf V1.44

Fehler in der Webansicht behoben ( Auswahl der Eventfelder in den 'trigger details :' war Fehlerhaft )

Gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 21 Mai 2018, 12:16:54
Da ich hier im Forum fast alles Mitlese und mir irgendwie angewöhnt habe, zu versuchen, alle aufkommenden Fragen bezüglich "Umsetzung Dieses und Jenes" für mich versuche über MSwitch zu lösen - da ich schon seit einiger Zeit ausschliesslich MSwitch nutze - werde ich im Wiki einen neuen Punkt "Tipps und Tricks" anhängen , in dem ich Lösungansätze, Möglichkeiten , Tricks, etc. mehr oder weniger zusammenhanglos ,stichpunktartig hinterlege. Lohnt sich bestimmt , ab und an mal reinzuschauen.

https://wiki.fhem.de/wiki/MSwitch.pm#Tipps.2C_Tricks.2C_Kurzbeispiele (https://wiki.fhem.de/wiki/MSwitch.pm#Tipps.2C_Tricks.2C_Kurzbeispiele)

Gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 23 Mai 2018, 05:23:00
mit kommendem Update ( wohl erst am WE ) werden in den Schaltzeit-Angaben folgende Konstruktionen möglich sein:

[?21:00-22:00|123]löst den Schaltbefehl zu einem zufälligen Zeitpunkt zwischen 21 und22 Uhr aus (Mo,Di,Mi).

[00:00:10*21:00-22:00|123]löst den Schaltbefehl zwischen 21 Uhr und 22 Uhr alle 10 Minuten aus

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 23 Mai 2018, 19:35:15
Im Anhang eine Testversion , bei der das zufällige schalten in einem definierten Zeitraum möglich sein sollte. Die Intervallschaltoption ist hier noch nicht integriert.

Syntax:[?19:05-19:07|123]
Info: Der reale Schaltzeitpunkt wird für den definierten Zeitraum nur einmal - bei modify - berechnet und für den laufenden Tag gesetzt . Auch bei einem erneuten 'Modify' bleibt dieser SchaltZEITPUNKT dann erhalten , wenn der Zeitraum nicht geändert wurde . Dieser wird dann erst wieder am Folgetag um 00:01 neu berechnet und gesetzt.

der reale Zeitpunkt ist in einem 'list DEVICE' zu sehen ( unter helper/randomtimer/(<definierter zeitraum>) ).

Internals:
   CFGFN     
   NAME       timertest
   NEXT_TIMERCHECK 2018-05-24 00:00:01
   NEXT_TIMEREVENT 2018-05-23 20:40:00
   NOTIFYDEV  no_trigger
   NR         208
   NTFY_ORDER 45-timertest
   STATE      on
   TYPE       MSwitch
   Version    1.44
   OLDREADINGS:
   READINGS:
     2018-05-23 18:39:12   Next_Time_Event 1527100800.50871-1
     2018-05-23 18:39:12   Trigger_device  no_trigger
     2018-05-22 17:39:24   Trigger_log     off
     2018-05-22 23:00:00   state           on
   helper:
     events:
       no_trigger:
         no_trigger on
     randomtimer:
       20:01-21:16 21:11
       20:02-21:16 20:40
     timer:
       HASH(0x1adb278) 1527100800.50871
.
.
.

falls es jemand peobiert, wäre ich über eine Info , ob es richtig funktioniert dankbar.

Gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: mark79 am 23 Mai 2018, 22:19:06
Hallo Thomas,

wo genau aktiviert man das "zufällige schalten" und wofür könnte man das verwenden?
Kann man es z.B. dafür verwenden, wenn man nicht anwesend ist, das Abends z.B. das Licht zufällig geschaltet wird? Zur Abschreckung von Einbrechern z.B.

Ich habe es über ein neues Device (random_wz_bilderrahmen), über die "on condition" und "off condition" ausprobiert: [?19:05-19:07|123] und auch alles Mögliche versucht zu aktivieren (1).
Aber ich krieg es nicht hin... Ein attr dazu finde ich auch nicht. Die MSwitch Testversion habe ich eingebunden und wird auch angezeigt.


Was mir aber aufgefallen ist, das beim vorgestrigen Wohnzimmer Device unter "trigger details" und "toggle Wohnzimmer_MSwitch + execute commands" der DashButton verschwunden ist. Eigentlich sollte dort "afri_cola:short" stehen. Siehe Screenshot 2.
Das schalten geht aber trotzdem noch und ein anderer DashButton kommt dem auch nicht in die Quere.
Das Dashbutton Event wird nur nicht mehr in der Dropdown Liste angezeigt. Es steht nur noch "no_trigger" und "state:stopped" zur Auswahl. Screenshot 1
Ein neu anlernen klappt auch nicht, es kommen keine neue Trigger Devices hinzu.

Der MSwitch_Mode Toggle funktioniert übrigens prima, habe ein MSwitch Wohnzimmer Device mit Twilight umgesetzt, das nur ab einer bestimmten Dunkelheit und Tagen die Beleuchtung spezifisch schaltet.

Für die Küche muss ich das noch umsetzten.. nur da fehlt mir derzeit die Zeit und Ruhe dafür.
Dort habe ich mehrere unterschiedliche Trigger Devices und ich frage mich schon die ganze Zeit, ob das mit Trigger Device "Global" und MSwitch_Mode Toggle so funktioniert. Aber versuch macht klug. :)


Viele Grüße
Mark
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 24 Mai 2018, 05:21:30
hi mark

Zitat
Ich habe es über ein neues Device (random_wz_bilderrahmen), über die "on condition" und "off condition" ausprobiert: [?19:05-19:07|123] und auch alles Mögliche versucht zu aktivieren (1).
Aber ich krieg es nicht hin... Ein attr dazu finde ich auch nicht. Die MSwitch Testversion habe ich eingebunden und wird auch angezeigt.

du musst das in den schaltzeiten eintragen : trigger device/time: - switch MSwitch on + execute 'on' commands at : ...

Zitat
Was mir aber aufgefallen ist, das beim vorgestrigen Wohnzimmer Device unter "trigger details" und "toggle Wohnzimmer_MSwitch + execute commands" der DashButton verschwunden ist. Eigentlich sollte dort "afri_cola:short" stehen. Siehe Screenshot 2.
Das schalten geht aber trotzdem noch und ein anderer DashButton kommt dem auch nicht in die Quere.
Das Dashbutton Event wird nur nicht mehr in der Dropdown Liste angezeigt. Es steht nur noch "no_trigger" und "state:stopped" zur Auswahl. Screenshot 1
Ein neu anlernen klappt auch nicht, es kommen keine neue Trigger Devices hinzu.

ja, der fehler ist mir auch aufgefallen, ich muss schauen , woher das kommt. drück bitte einfach mal auf 'clear saved events" , dann dollte e wieder da sein. Da ich das nicht bewusst reproduzieren kann , muss ich erstmal abwarten , bis das bei mir wieder auftritt .

habe das Problem behoben (hoffe ich - schlecht reproduzierbar, das es nur unter ganz bestimmte umständen eintritt), stelle ich heute abend noch in das GIT

thx und gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 25 Mai 2018, 15:49:18
Hallo Thomas,

zurück aus meinem Kurzurlaub wollte ich gleich nochmal mit deinem Modul was spielen. Ist echt super, aber ich scheitere anscheinend wieder an einer kleinigkeit. Ich habe es hinbekommen, dass über dein Modul meine Lampe im Flur mit dem Bewegungsmelder geschaltet wird, das soll aber nur abends passieren. Soweit ich es verstanden habe könnte ich es wie folgt machen:

Im device action bei on codition: einfach z.B. [18:00-06:00] schreiben.

Das wäre mir aber zu einfach ::) .

Ich kann über meine Tablet UI die 2 Zeiten (von/bis) einstellen. Diese 2 Zeiten werden im Dummy Flur_Lampe_Dummy in den Readings Licht_an & Licht_aus abgelegt. Wie kann ich das einbinden?

Gruß Torsten


EDIT:

Eine Zusatzfrage:

Der Aktor ist ein Dimmer, wie bekomme ich es hin, dass das Licht bei Schalten über motion z.B. nur mit 30% angeht?

Momentan habe ich bei device action: MSwitch on cmd: Set on-for-timer 30 stehen
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 25 Mai 2018, 17:34:25
Ich habe da direkt nochwas. Der Bewegungsmelder ist in einem Taster Homematic HM-Sen-MDIR-WM55 integriert. Den Sensor habe ich als Trigger Device Flur_Taster2_Motion genommen, der Funktioniert problemlos. Der andere Taster im Flur ist ein HM-PB-2-WM55 den konnte ich problemlos einbinden. Den 2. Taster ( wo der Sensor integriert ist) aber aus irgendeinem Grund nicht.

Als Trigger Device habe ich Flur_Taster2 ausgewählt, aber bei trigger details bekomme ich im Pulldown nur no_trigger & battery:ok aber kein state.

Beim Taster 1 wird mir state:Flur_Taster1_01 Short & Flur_Taster1_02 Short angezeigt.

Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 26 Mai 2018, 06:29:41
Ho Torsten,

Zitat
Soweit ich es verstanden habe könnte ich es wie folgt machen:

Im device action bei on codition: einfach z.B. [18:00-06:00] schreiben.


du kannst das entweder bei den 'Trigger condition: ' eingeben ( genau wie geschrieben ) , damit wird der gesamte Trigger nur in dieser Zeit 'abgearbeitet, oder du kannst es wie von dir gechrieben in den 'device actions ,on-off conditions' angeben, dann wird der Trigger zwar abgearbeitet, aber dieser Befehl nur in angegebenen Zeiten geschaltet.

Zitat
Ich kann über meine Tablet UI die 2 Zeiten (von/bis) einstellen. Diese 2 Zeiten werden im Dummy Flur_Lampe_Dummy in den Readings Licht_an & Licht_aus abgelegt. Wie kann ich das einbinden?

geht in dieser version leider nicht so einfach , müsste dann über freecmd gemacht werden. Ich werde für die nächste version( noch am WE ) eine jkleine änderung machen , sa dass er in den conditions eine solche syntax erkennt :

[[dummy1:state]-[dummy2:state]]
gruss Byte

Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 26 Mai 2018, 06:31:19
Ich habe da direkt nochwas. Der Bewegungsmelder ist in einem Taster Homematic HM-Sen-MDIR-WM55 integriert. Den Sensor habe ich als Trigger Device Flur_Taster2_Motion genommen, der Funktioniert problemlos. Der andere Taster im Flur ist ein HM-PB-2-WM55 den konnte ich problemlos einbinden. Den 2. Taster ( wo der Sensor integriert ist) aber aus irgendeinem Grund nicht.

Als Trigger Device habe ich Flur_Taster2 ausgewählt, aber bei trigger details bekomme ich im Pulldown nur no_trigger & battery:ok aber kein state.

Beim Taster 1 wird mir state:Flur_Taster1_01 Short & Flur_Taster1_02 Short angezeigt.

schau doch bitte mal im eventmonitor, was für ein event generiert wird, wenn der schalter sich meldet.

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 26 Mai 2018, 07:56:03
schau doch bitte mal im eventmonitor, was für ein event generiert wird, wenn der schalter sich meldet.

gruss Byte09

folgendes wird mir im Eventmonitor bei betätigung der beiden Taster des Schalters2 angezeigt

2018-05-26 07:46:33 CUL_HM Flur_Taster2_01 Short 1_27 (to broadcast)
2018-05-26 07:46:33 CUL_HM Flur_Taster2_01 trigger: Short_27
2018-05-26 07:46:33 CUL_HM Flur_Taster2_01 trigger_cnt: 27


2018-05-26 07:47:15 CUL_HM Flur_Taster2_02 Short 1_33 (to broadcast)
2018-05-26 07:47:15 CUL_HM Flur_Taster2_02 trigger: Short_33
2018-05-26 07:47:15 CUL_HM Flur_Taster2_02 trigger_cnt: 33
2018-05-26 07:47:21 CUL_HM Flur_Taster2 battery: ok

beim funktionierenden Schalter sieht es so aus
2018-05-26 07:53:13 CUL_HM Flur_Taster1 battery: ok
2018-05-26 07:53:13 CUL_HM Flur_Taster1 Flur_Taster1_01 Short
2018-05-26 07:53:13 CUL_HM Flur_Taster1_01 Short 1_12 (to broadcast)
2018-05-26 07:53:13 CUL_HM Flur_Taster1_01 trigger: Short_12
2018-05-26 07:53:13 CUL_HM Flur_Taster1_01 trigger_cnt: 12


2018-05-26 07:54:17 CUL_HM Flur_Taster1 battery: ok
2018-05-26 07:54:17 CUL_HM Flur_Taster1 Flur_Taster1_02 Short
2018-05-26 07:54:17 CUL_HM Flur_Taster1_02 Short 1_21 (to broadcast)
2018-05-26 07:54:17 CUL_HM Flur_Taster1_02 trigger: Short_21
2018-05-26 07:54:17 CUL_HM Flur_Taster1_02 trigger_cnt: 21
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 26 Mai 2018, 08:08:01
bei dem taster wo es nicht geht kommen ja wieder nur diese hochzählenden events, die niemals gleich sind. da der andere ja passende events liefert muss es ja irgendwie an den einstellungen des tasters liegen ?! leider habe ich einen solchen taster nicht .

im zweilfe gib doch bei 'add event' mal einen stern (trigger_cnt.*) ein und dann auf 'add event' klicke. dann hast du diesen wildcard in der eventauswahlliste und er triggert auf dieses Event. sollte auch gehen, das er dieses event ja bei jedem druck liefert

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 26 Mai 2018, 08:56:15
...

im zweilfe gib doch bei 'add event' mal einen stern (trigger_cnt.*) ein und dann auf 'add event' klicke. dann hast du diesen wildcard in der eventauswahlliste und er triggert auf dieses Event. sollte auch gehen, das er dieses event ja bei jedem druck liefert

gruss Byte09

Funktioniert leide nicht

Edit:

Beim funktionierenden Schalter habe ich ja bei Flur_Taster1 (a: t:CUL_HM) ausgewählt und bei trigger details dann state:Flur_Taster1_01 Short (für on) bzw. state:Flur_Taster1_02 Short (für off) ausgewählt.

CUL_HM Flur_Taster1 Flur_Taster1_01 Short
CUL_HM Flur_Taster1 Flur_Taster1_02 Short

Beim anderen Schalter habe ich dann Flur_Taster2 (a: t:CUL_HM) ausgewählt. Aber im Eventmonitor steht ja dieser Taster nicht sondern

CUL_HM Flur_Taster2_01 Short 1_27 (to broadcast)
CUL_HM Flur_Taster2_01 trigger: Short_27
CUL_HM Flur_Taster2_01 trigger_cnt: 27


CUL_HM Flur_Taster2_02 Short 1_33 (to broadcast)
CUL_HM Flur_Taster2_02 trigger: Short_33
CUL_HM Flur_Taster2_02 trigger_cnt: 33
CUL_HM Flur_Taster2 battery: ok
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 26 Mai 2018, 09:24:33
Funktioniert leide nicht

ich stelle das gerade mal mit einem dummy nach , melde mich dann.

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 26 Mai 2018, 09:26:51
ich stelle das gerade mal mit einem dummy nach , melde mich dann.

gruss Byte09

Siehe Edit ein Post drüber
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 26 Mai 2018, 10:06:41
Siehe Edit ein Post drüber

ich habe mal einen Dummy angelegt, der mir folgende Events liefert:
2018-05-26 10:02:53 dummy eventtest on
2018-05-26 10:02:53 dummy eventtest triggercount: 41
2018-05-26 10:02:53 dummy eventtest trigger: Short_ 41

als zu triggerndes event habe ich mit 'add Event' folgendes Event angelegt:
trigger:Short* ... bitte das Wildcart am ende beachten.

MSwitch schaltet nun bei jedem Event, was folgenden Inhalt hat
trigger:Short<egal_was_hier_steht>
geht einwandfrei .

gruss Byte09


zum nachstellen
raw des dummys:
defmod eventtest dummy
attr eventtest room test
attr eventtest userReadings triggercount:* {ReadingsVal("$NAME","triggercount",0)+1;;;;},\
trigger:* { "Short_ ".ReadingsVal("$NAME","triggercount",0)}
attr eventtest webCmd on:off

setstate eventtest off
setstate eventtest 2018-05-26 10:08:04 state off
setstate eventtest 2018-05-26 10:08:04 trigger Short_ 54
setstate eventtest 2018-05-26 10:08:04 triggercount 54

configfile des MSwitch
#S .Device_Affected -> no_device
#S .Device_Affected_Details -> undef
#S .Device_Events -> trigger:short*|no_trigger
#S .First_init -> done
#S .Trigger_Whitelist -> undef
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> no_trigger
#S .Trigger_condition ->
#S .Trigger_off -> no_trigger
#S .Trigger_on -> trigger:short*
#S .Trigger_time ->
#S .V_Check -> V 0.3
#S Exec_cmd -> undef
#S Trigger_device -> eventtest
#S Trigger_log -> off
#S last_event -> undef
#S state -> off
#A MSwitch_Include_MSwitchcmds -> 0
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Expert -> 0
#A MSwitch_Extensions -> 0
#A MSwitch_Help -> 0
#A MSwitch_Mode -> Toggle
#A MSwitch_Delete_Delays -> 1
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A MSwitch_Include_Webcmds -> 0
#A room -> test
#A MSwitch_Lock_Quickedit -> 1
#A MSwitch_Debug -> 0


Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 26 Mai 2018, 10:20:56
danke für deine Bemühungen @Thomas,

ich habe es jetzt so gemacht wie auf dem Foto


aber das Problem was ich habe liegt nicht daran, dass Problem ist, ich müßte bei Trigger device: Flur_Taster1_01 mit deinem Vorschlag umsetzen für Einschalten und einen Trigger device: Flur_Taster1_02 für das Ausschalten einsetzen, da der Trigger ja auf diese beiden liegt und nicht auf Flur_Taster2. Also müßte ich ja dann 2 MSwitch machen und das ist nicht praktikabel.
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 26 Mai 2018, 10:32:33
danke für deine Bemühungen @Thomas,

ich habe es jetzt so gemacht wie auf dem Foto


aber das Problem was ich habe liegt nicht daran, dass Problem ist, ich müßte bei Trigger device: Flur_Taster1_01 mit deinem Vorschlag umsetzen für Einschalten und einen Trigger device: Flur_Taster1_02 für das Ausschalten einsetzen, da der Trigger ja auf diese beiden liegt und nicht auf Flur_Taster2. Also müßte ich ja dann 2 MSwitch machen und das ist nicht praktikabel.

das geht auch über ein MSwitch Device,da müsstest du aber GLOBAL triggern, da du auf 2 Geräte triggern willst . Ich mache dir dazu nochmal ein Beispiel und poste es . Das sprengt hier den Rahmen es so zu erklären. Bei interesse kannst du mich auch gerna mal anrufen, würde dir die Nummer dann privat schicken.

Gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 26 Mai 2018, 10:40:50
taster 1 (dummy)
defmod eventtest dummy
attr eventtest room test
attr eventtest userReadings triggercount:* {ReadingsVal("$NAME","triggercount",0)+1;;;;},\
trigger:* { "Short_ ".ReadingsVal("$NAME","triggercount",0)}
attr eventtest webCmd on

setstate eventtest on
setstate eventtest 2018-05-26 10:38:24 state on
setstate eventtest 2018-05-26 10:38:24 trigger Short_ 93
setstate eventtest 2018-05-26 10:38:24 triggercount 93

taster2 (dummy)
defmod eventtest1 dummy
attr eventtest1 room test
attr eventtest1 userReadings triggercount:* {ReadingsVal("$NAME","triggercount",0)+1;;;;},\
trigger:* { "Short_ ".ReadingsVal("$NAME","triggercount",0)}
attr eventtest1 webCmd on

setstate eventtest1 on
setstate eventtest1 2018-05-26 10:38:24 state on
setstate eventtest1 2018-05-26 10:38:24 trigger Short_ 9
setstate eventtest1 2018-05-26 10:38:24 triggercount 9

configfile MSwitch ( die dummys müssen erst angelegt werden )
#S .Device_Affected -> no_device
#S .Device_Affected_Details -> undef
#S .Device_Events -> eventtest:trigger:short*|eventtest1:trigger:short*|no_trigger
#S .First_init -> done
#S .Trigger_Whitelist -> eventtest,eventtest1
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> no_trigger
#S .Trigger_condition ->
#S .Trigger_off -> eventtest1:trigger:short*
#S .Trigger_on -> eventtest:trigger:short*
#S .Trigger_time ->
#S .V_Check -> V 0.3
#S Exec_cmd -> undef
#S Trigger_device -> all_events
#S Trigger_log -> off
#S last_event -> eventtest1:trigger:Short_
#S state -> off
#A MSwitch_Include_MSwitchcmds -> 0
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Expert -> 1
#A MSwitch_Extensions -> 0
#A MSwitch_Help -> 1
#A MSwitch_Mode -> Full
#A MSwitch_Delete_Delays -> 1
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A MSwitch_Include_Webcmds -> 0
#A room -> test
#A MSwitch_Lock_Quickedit -> 1
#A MSwitch_Debug -> 0

nach de speichern des configfiles musst du einmal auf 'modify trigger device' drücken , da das Modul intern den Mode wechseln muss, das tut er nicht automatisch beim einspielen des files.


gruss Thomas
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 26 Mai 2018, 14:01:13
Zu den dummys habe ich noch eine Frage:

in den Bereichen vom ReadingsVal habe ich für $Name Flur_Taster2_01 bzw. Flur_Taster2_02 eingesetzt. Was muß ich bei triggercount eingeben? Weil weder triggercount, trigger_cnt noch trigger funktioniert.

Hier mal die list von Flur_Taster2_01

Internals:
   DEF        57C3AE01
   NAME       Flur_Taster2_01
   NOTIFYDEV  global
   NR         60
   NTFY_ORDER 50-Flur_Taster2_01
   STATE      Short 1_60 (to broadcast)
   TYPE       CUL_HM
   chanNo     01
   device     Flur_Taster2
   READINGS:
     2018-05-25 16:50:00   motion          off
     2018-05-26 13:58:08   state           Short 1_60 (to broadcast)
     2018-05-26 13:58:08   trigger         Short_60
     2018-05-26 13:58:08   trigger_cnt     60
   helper:
     BNO        60
     BNOCNT     1
     regLst     ,1,4p
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     role:
       chn        1
     tmpl:
Attributes:
   model      HM-Sen-MDIR-WM55
   peerIDs    00000000,
   room       Flur->Licht
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 26 Mai 2018, 14:18:26
Zu den dummys habe ich noch eine Frage:

in den Bereichen vom ReadingsVal habe ich für $Name Flur_Taster2_01 bzw. Flur_Taster2_02 eingesetzt. Was muß ich bei triggercount eingeben? Weil weder triggercount, trigger_cnt noch trigger funktioniert.

Hier mal die list von Flur_Taster2_01

Internals:
   DEF        57C3AE01
   NAME       Flur_Taster2_01
   NOTIFYDEV  global
   NR         60
   NTFY_ORDER 50-Flur_Taster2_01
   STATE      Short 1_60 (to broadcast)
   TYPE       CUL_HM
   chanNo     01
   device     Flur_Taster2
   READINGS:
     2018-05-25 16:50:00   motion          off
     2018-05-26 13:58:08   state           Short 1_60 (to broadcast)
     2018-05-26 13:58:08   trigger         Short_60
     2018-05-26 13:58:08   trigger_cnt     60
   helper:
     BNO        60
     BNOCNT     1
     regLst     ,1,4p
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     role:
       chn        1
     tmpl:
Attributes:
   model      HM-Sen-MDIR-WM55
   peerIDs    00000000,
   room       Flur->Licht

die dummys hatte ich nur angelegt , da ich keinen entsprechenden taster habe, anstatt der Taster.

du kannst doch direkt auf die beiden taster ( die beiden namen der dummys gegen die beiden namen der taster in 'Trigger Device Global Whitelist: ' ändern ) triggern .

grundsätzlich: $NAME musst du gar nicht ändern , das wird automatisch von fhem ersetzt gegen den Namen ders Gerätes in dem (in diesem fall) das Userreading steht.

ggf. kann ich dir aber gerade auch nur nicht folgen ?

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 26 Mai 2018, 14:32:08
Ok, jetzt ist mir ein Licht aufgegangen  ::) Nicht nur sprichwörtlich.

Habe es jetzt so umgesetzt und hinbekommen:

Trigger device: GLOBAL
Trigger Device Global Whitelist Flur_Taster2_01,Flur_Taster2_02

Bei triggerdetails habe ich von Hand Flur_Taster2_01:trigger:Short* und Flur_Taster2_02:trigger:Short* hinzugefügt und für on und off ausgewählt.

FUNKTIONIERT!!

TOP TOOL!!


EDIT:

Bin jetzt nurnoch gespannt ob du das auch hinbekommst

...
geht in dieser version leider nicht so einfach , müsste dann über freecmd gemacht werden. Ich werde für die nächste version( noch am WE ) eine jkleine änderung machen , sa dass er in den conditions eine solche syntax erkennt :

[[dummy1:state]-[dummy2:state]]
gruss Byte

Das wäre echt super! Aber keine Kektik ;)


EDIT2:

...
Eine Zusatzfrage:

Der Aktor ist ein Dimmer, wie bekomme ich es hin, dass das Licht bei Schalten über motion z.B. nur mit 30% angeht?

Momentan habe ich bei device action: MSwitch on cmd: Set on-for-timer 30 stehen

Darauf bist du bisher garnicht eingegangen, dann gehe ich mal davon aus, dass dafür keine Möglichkeit gibt. Es ist nämlich so, dass ich gerne das Licht gedimmt für 30sek. eingeschaltet haben möchte, wenn der Bewegungsmelder abends/nachts schaltet
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 26 Mai 2018, 14:47:44

Bin jetzt nurnoch gespannt ob du das auch hinbekommst

Das wäre echt super! Aber keine Kektik ;)

.
.
.. Es ist nämlich so, dass ich gerne das Licht gedimmt für 30sek. eingeschaltet haben möchte, wenn der Bewegungsmelder abends/nachts schaltet

ich habe es schon hinbekommen, läuft bei mir und ist in der kommenden version vorhanden.  ;)

zum zweiten punkt schreibe ich dir nachher was, bin jetzt erstmal kindertaxi. geht aber auch

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 26 Mai 2018, 15:00:01
Hat keine Eile!!

Sitze auch im Garten, genieße die Sonne und spiele etwas nebenbei mit Fhem  ;D . Gleich kommen noch Gäste, dann wird lecker gegrillt  8)
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 26 Mai 2018, 17:34:14
ich habe es schon hinbekommen, läuft bei mir und ist in der kommenden version vorhanden.  ;)

zum zweiten punkt schreibe ich dir nachher was, bin jetzt erstmal kindertaxi. geht aber auch

gruss Byte09

im grunde musst du hier 2 befehle ausführen lassen , beide im on- zweig , da der dimmer es nicht unterstützt ( on for timer und einen pct wert gleichzeitig zu setzen zu setzen  - glaube ich .

anbei einfach ein bild mit der config.

gruss thomas
Titel: kommendes Update auf V 1.5
Beitrag von: Byte09 am 27 Mai 2018, 07:18:49
das kommende Update auf V1.5 wird folgende Änderungen/Neuerungen beinhalten.

der Code wurde vollkommen überarbeitet, diverse Routinen von Grund auf neu geschrieben.

neue Attribute:

MSwitch_Condition_Time (0,1)
- bewirkt die überprüfung der 'Trigger condition' auch für zeitgesteuertes Schalten . 0 entspricht dem bisherigen Verhalten

MSwitch_RandomTime (00:00:01-00:00:10)
 - bewirkt die berechnung einer Zufallszeit zwischen 1 und 10 Sekunden vor JEDER Ausführung von Delays. Auf diese kann durch Angabe von '[random]' im Delayfeld zugegriffen werden. Delays werden entsprechend zufällig mit einer Verzögerung zwischen 0 und 10 Sekunden ausgeführt (je nach belegung des Attributes). Leeres oder nicht vorhandenes Attibut entspricht dem bisherigem verhalten.

MSwitch_RandomNumber ( 0 - 100)
- bewirkt die Berechnung einer Zufallszahl  in angegebenem Rahmen vor JEDER Befehlsausführung . Auf diese kann in den 'conditions' zugegriffen werden , und es besteht so die Möglichkeit einen Befehl nur mit einer bestimmten Wahrscheinlichkeit ausführen zu lassen (weitere Erklärung folgt). Leeres oder nicht vorhandenes Attibut entspricht dem bisherigem verhalten.

MSwitch_Conditions (ggf. erst ab V1.51)
- bietet die Möglichkeit , häufig genutzte Conditions in einer Liste zu hinterlegen, um diese in den Conditions Feldern über ein Kürzel aufzurufen, genaue Syntax folgt.

neue (zusätzliche) Syntax in den Schaltzeiten:

[?20:00-21:00|1]
der Schaltzeitpunkt wird zufällig gewählt , in diesem Fall Montags zwischen 20:00 Uhr und 21:00 Uhr

[00:10*20:00-21:00]
der Schaltbefehl wird zwischen 20 Uhr und 21 Uhr alle 10 Minuten ausgeführt


neu in Conditions

in den conditions ( in diesem Falll für angegebene Schaltzeiten ) kann jetzt auf 'fremde' Readings zugegriffen werden.
folgende Syntax z.B bewirkt , das der Befehl nur in Zeitraum ausgeführt wird, der in den states entsprechender Dummys etc. hinterlegt ist. Dabei muss das Format in folgender Form vorliegen HH:MM.
Syntax [[dummy1:state]-[dummy2:state]]

diverse Fehler behoben

eine Kombination dieser neuen Optionen ergiebt die komfortable Möglichkeit einer Anwesenheitssimulation in einem MSwitch-Device für alle beteiligten Geräte.

gruss Byte09

Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 27 Mai 2018, 08:47:57
Ich bin begeistert  ;D

Dein Modul ist super, pass nur auf, daß es nicht zur Eierlegendenwollmilchsau wird, dann wird es zu unübersichtlich!

Durch dein Modul ist es bei mir jetzt etwas übersichtlicher geworden.

Um nochmal auf gestern mit den Dummsy zurück zu kommen. Da du geschrieben hattest:
Zitat
...configfile MSwitch ( die dummys müssen erst angelegt werden )...

Habe ich gedacht, ich brauche die!

Aber es läuft jetzt perfekt!
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 27 Mai 2018, 09:11:06
Ich bin begeistert  ;D

Dein Modul ist super, pass nur auf, daß es nicht zur Eierlegendenwollmilchsau wird, dann wird es zu unübersichtlich!

Durch dein Modul ist es bei mir jetzt etwas übersichtlicher geworden.

Um nochmal auf gestern mit den Dummsy zurück zu kommen. Da du geschrieben hattest:
Habe ich gedacht, ich brauche die!

Aber es läuft jetzt perfekt!


nein , brauchst du nicht. damit konntest du die funktion nur am besten nachvollziehen . das
Zitat
...configfile MSwitch ( die dummys müssen erst angelegt werden )...
war nur darauf bezogen , das sich das configfile nicht einspielen lässt , wenn die dummys nicht da sind, da sich alles auf diese dummys bezieht.

zur wollmilchsau :

es ist in der Tat so , dass  es eine solche werden muss ( fast ist ), da ich z.B nichts anderes mehr nutze , kein notify,kein watchdog, kein at, kein doif etc. pp . in meinem system gibt es ausschliesslich MSwitch , da ich alle Automatisierungen übersichtlich - auf einer Seite - einsehen können will , und das ist nunmal bisher nur im MSwitch - Inforoom gegeben (Anhang).
Sozusagen ein Alleinstellungsmerkmal  ;)

Insofern muss/soll es alles können. Aber da det. ja schon ähnliche bedenken geäussert hat bleibt die Grundfunktion und Konfiguration so , wie sie jetzt ist . Alles weiter sind/werden Funktionen , die entweder komplett im Hintergrund laufen , oder die Zuschalbar sind , nach Bedarf, und somit nicht auffallen , wenn sie nicht aktiviert werden.

gruss thomas
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: andies am 27 Mai 2018, 09:22:56
Hmm. Da brauchen wir so was wie eine richtige Einführung über mehrere Seiten, damit das möglichst viele verstehen. Eine Einleitung von Grund auf, meine ich. Das ist Arbeit ✍️


Gesendet von iPad mit Tapatalk Pro
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 27 Mai 2018, 09:24:54
Hmm. Da brauchen wir so was wie eine richtige Einführung über mehrere Seiten, damit das möglichst viele verstehen. Eine Einleitung von Grund auf, meine ich. Das ist Arbeit ✍️


Gesendet von iPad mit Tapatalk Pro

das ist es in jedem Fall  :o .....und ich sträube mich sowas von .. dagegen  ;) ;) ;)

gruss Thomas
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 27 Mai 2018, 10:57:46

...
zur wollmilchsau :

es ist in der Tat so , dass  es eine solche werden muss ( fast ist ), da ich z.B nichts anderes mehr nutze , kein notify,kein watchdog, kein at, kein doif etc. pp . in meinem system gibt es ausschliesslich MSwitch , da ich alle Automatisierungen übersichtlich - auf einer Seite - einsehen können will , und das ist nunmal bisher nur im MSwitch - Inforoom gegeben (Anhang).
Sozusagen ein Alleinstellungsmerkmal  ;)

Insofern muss/soll es alles können. Aber da det. ja schon ähnliche bedenken geäussert hat bleibt die Grundfunktion und Konfiguration so , wie sie jetzt ist . Alles weiter sind/werden Funktionen , die entweder komplett im Hintergrund laufen , oder die Zuschalbar sind , nach Bedarf, und somit nicht auffallen , wenn sie nicht aktiviert werden.

gruss thomas

Das stimmt schon und erleichtert vieles auf anhieb, aber die Anfälligkeit für Fehler wird immer größer.

Im Grunde bin ich auch für ein Modul das alles kann, aber es kann auch zu Problemen führen.


Noch eine Frage:

Wie komme ich an den Inforoom? Kann ihn irgendwie nicht finden
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 27 Mai 2018, 12:10:39
Das stimmt schon und erleichtert vieles auf anhieb, aber die Anfälligkeit für Fehler wird immer größer.

Im Grunde bin ich auch für ein Modul das alles kann, aber es kann auch zu Problemen führen.


Noch eine Frage:

Wie komme ich an den Inforoom? Kann ihn irgendwie nicht finden

du musst alle MSwitch Devices (zusätlich) in einen Raum sortieren (da sollten nur MSwitch Devices drinnen sein) z.B  Room MSwitch.

Dann stellst du in einem MSwitch Device das Attribut 'MSwitch_Inforoom' auf diesen Raum (MSwitch). Das Modul setzt dann in allen MSwitch Devices dieses Attribut automatisch .

Wenn du dann auf diesen Raum gehst hast du entsprechende Ansicht.

https://wiki.fhem.de/wiki/MSwitch.pm#MSwitch_Inforoom (https://wiki.fhem.de/wiki/MSwitch.pm#MSwitch_Inforoom)

wenn du das Attribut in einem Device löscht (änderst) , wird dieses Attribut automatisch in allen MSwitch Devices ebenfalls gelöscht (geändert)

gruss Thomas
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 27 Mai 2018, 12:41:08
im grunde musst du hier 2 befehle ausführen lassen , beide im on- zweig , da der dimmer es nicht unterstützt ( on for timer und einen pct wert gleichzeitig zu setzen zu setzen  - glaube ich .

anbei einfach ein bild mit der config.

gruss thomas

Wie gerade gemerkt, hat die Sache leider einen negativen Effekt.

Zur Erklärung der ganzen Struktur.

Im Flur habe ich eine Lampe (Flur_Lampe) und 2 Taster (Flur_Taster1 & Flur_Taster2). Im Flur_Taster2 ist noch ein Bewegungsmelder integriert.

Ich habe nun 3 MSwitch um dieses zu schalten:


MSwitch: Flur_Licht_S1

Trigger device:
[b]Flur_Taster1[/b]

trigger details :
[b]execute 'on' commands Trigger Flur_Taster1 :[/b] state:Flur_Taster1_01 Short
[b]execute 'off' commands Trigger Flur_Taster1 :[/b] state:Flur_Taster1_02 Short

device actions :
Flur_Lampe   

[b]MSwitch on cmd: Set on[/b]
[b]MSwitch off cmd: Set off[/b]


MSwitch: Flur_Licht_S2

Trigger device:
[b]GLOBAL[/b]
Trigger Device Global Whitelist:
[b]Flur_Taster2_01,Flur_Taster2_02[/b]

trigger details :
[b]execute 'on' commands Trigger all_events :[/b] Flur_Taster2_01:trigger:Short
[b]execute 'off' commands Trigger all_events :[/b] Flur_Taster2_02:trigger:Short

device actions :
Flur_Lampe   

[b]MSwitch on cmd: Set on[/b]
[b]MSwitch off cmd: Set off[/b]


MSwitch: Flur_Licht_motion

Trigger device:
[b]Flur_Taster1_motion[/b]

trigger details :
[b]execute 'on' commands Trigger Flur_Taster1 :[/b] state:motion
[b]execute 'off' commands Trigger Flur_Taster1 :[/b] no_trigger

device actions :
Flur_Lampe   

[b]MSwitch on cmd: Set pct[/b]  60
[b]MSwitch off cmd: Set no_action[/b]
[b]on condition:[/b] [18:00-6:00]

Flur_Lampe   

[b]MSwitch on cmd: Set off[/b]
[b]MSwitch off cmd: Set no_action[/b]
[b]on delay with cond-check: +[/b] 00:00:30

Nun zu meinem Problem.

Der Befehl im 3. MSwitch mit dem ausschalten nach 30sek hat leider auch auswirkung auf das Licht, wenn ich dieses mit einem der beiden Taster einschalte. In diesem Fall sollte das Licht aber nur ausgehen, wenn es von Hand ausgeschaltet wird.
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 27 Mai 2018, 13:06:07
Wie gerade gemerkt, hat die Sache leider einen negativen Effekt.

Zur Erklärung der ganzen Struktur.

Im Flur habe ich eine Lampe (Flur_Lampe) und 2 Taster (Flur_Taster1 & Flur_Taster2). Im Flur_Taster2 ist noch ein Bewegungsmelder integriert.

Ich habe nun 3 MSwitch um dieses zu schalten:


MSwitch: Flur_Licht_S1

Trigger device:
[b]Flur_Taster1[/b]

trigger details :
[b]execute 'on' commands Trigger Flur_Taster1 :[/b] state:Flur_Taster1_01 Short
[b]execute 'off' commands Trigger Flur_Taster1 :[/b] state:Flur_Taster1_02 Short

device actions :
Flur_Lampe   

[b]MSwitch on cmd: Set on[/b]
[b]MSwitch off cmd: Set off[/b]


MSwitch: Flur_Licht_S2

Trigger device:
[b]GLOBAL[/b]
Trigger Device Global Whitelist:
[b]Flur_Taster2_01,Flur_Taster2_02[/b]

trigger details :
[b]execute 'on' commands Trigger all_events :[/b] Flur_Taster2_01:trigger:Short
[b]execute 'off' commands Trigger all_events :[/b] Flur_Taster2_02:trigger:Short

device actions :
Flur_Lampe   

[b]MSwitch on cmd: Set on[/b]
[b]MSwitch off cmd: Set off[/b]


MSwitch: Flur_Licht_motion

Trigger device:
[b]Flur_Taster1_motion[/b]

trigger details :
[b]execute 'on' commands Trigger Flur_Taster1 :[/b] state:motion
[b]execute 'off' commands Trigger Flur_Taster1 :[/b] no_trigger

device actions :
Flur_Lampe   

[b]MSwitch on cmd: Set pct[/b]  60
[b]MSwitch off cmd: Set no_action[/b]
[b]on condition:[/b] [18:00-6:00]

Flur_Lampe   

[b]MSwitch on cmd: Set off[/b]
[b]MSwitch off cmd: Set no_action[/b]
[b]on delay with cond-check: +[/b] 00:00:30

Nun zu meinem Problem.

Der Befehl im 3. MSwitch mit dem ausschalten nach 30sek hat leider auch auswirkung auf das Licht, wenn ich dieses mit einem der beiden Taster einschalte. In diesem Fall sollte das Licht aber nur ausgehen, wenn es von Hand ausgeschaltet wird.

ok, etwas schwierig zu folgen :

also erstmal benötigst du dafür nur ein Device. würde dir nochmal ein beispiel basteln , mit dummys , muss aber genau wissen , was - wann pasiieren soll.

mein verständniss:

taster 1 und zwei schalten an und aus , jeder beides - also im grunde wechselschaltung .
bewegungsmeder schaltet für 30 sek an  . nur wenn licht noch aus . wenn das licht schon an ist , durch taster geschaltet soll es nicht ausgehen nach den 30 sekunden ?

passt das so ?

gruss Thomas

Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 27 Mai 2018, 13:14:58
...
mein verständniss:

taster 1 und zwei schalten an und aus , jeder beides - also im grunde wechselschaltung .
bewegungsmeder schaltet für 30 sek an  . nur wenn licht noch aus . wenn das licht schon an ist , durch taster geschaltet soll es nicht ausgehen nach den 30 sekunden ?

passt das so ?

gruss Thomas

Bingo, zusätzlich soll der Bewegungsmelder in diesem Fall nur zw. 18Uhr und 6Uhr schalten. Wobei ich das ja gerne Variabel halten würde über meine Tablet UI und dummy

Ich kann über meine Tablet UI die 2 Zeiten (von/bis) einstellen. Diese 2 Zeiten werden im Dummy Flur_Lampe_Dummy in den Readings Licht_an & Licht_aus abgelegt. Wie kann ich das einbinden?
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 27 Mai 2018, 13:30:06
gib mir 10 minuten , poste dan die beispielkonfig.

gruss Thomas
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 27 Mai 2018, 13:31:16
gib mir 10 minuten , poste dan die beispielkonfig.

gruss Thomas

kein Sress!
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 27 Mai 2018, 13:38:19
kein Sress!

beispielkonfiguration - wird alles im raum bsp angelegt.
bitte erst die dummys anlegen, dann ein leeres MSwitch Device anlegen und das MSwitch Configfile einspielen.
danach 'modify trigger device' drücken.

schau es dir einfach an , bei fragen melden  ;)

defmod Dummy_taster2 dummy
attr Dummy_taster2 room bsp
attr Dummy_taster2 webCmd on

setstate Dummy_taster2 on
setstate Dummy_taster2 2018-05-27 13:28:11 state on

defmod Dummy_taster1 dummy
attr Dummy_taster1 room bsp
attr Dummy_taster1 webCmd on

setstate Dummy_taster1 on
setstate Dummy_taster1 2018-05-27 13:28:40 state on

defmod Dummy_Lampe dummy
attr Dummy_Lampe room bsp
attr Dummy_Lampe webCmd on:off

setstate Dummy_Lampe off
setstate Dummy_Lampe 2018-05-27 13:32:07 state off

defmod Dummy_Bewegungsmelder dummy
attr Dummy_Bewegungsmelder room bsp
attr Dummy_Bewegungsmelder webCmd on

setstate Dummy_Bewegungsmelder on
setstate Dummy_Bewegungsmelder 2018-05-27 13:32:14 state on


#S .Device_Affected -> Dummy_Lampe-AbsCmd1,Dummy_Lampe-AbsCmd2,Dummy_Lampe-AbsCmd3
#S .Device_Affected_Details -> Dummy_Lampe-AbsCmd1,on,no_action,,,delay1,delay1,000000,000000,[$EVENT]~eq~"Dummy_Bewegungsmelder:state:on"~AND~[Dummy_Lampe:state]~eq~"off"~AND~[18:00-06:00],,0,0|Dummy_Lampe-AbsCmd2,off,no_action,,,delay0,delay1,000010,000000,[$EVENT]~eq~"Dummy_Bewegungsmelder:state:on"~AND~[Dummy_Lampe:state]~eq~"off"~AND~[18:00-06:00],,0,0|Dummy_Lampe-AbsCmd3,MSwitchtoggle,no_action,on/off,,delay1,delay1,000000,000000,[$EVENT]~eq~"Dummy_taster1:state:on"~OR~[$EVENT]~eq~"Dummy_taster2:state:on",,0,0
#S .Device_Events -> no_trigger|*:state:on|Dummy_Bewegungsmelder:state:on|Dummy_taster2:state:on|Dummy_taster1:state:on
#S .First_init -> done
#S .Trigger_Whitelist -> Dummy_taster1,Dummy_taster2,Dummy_Bewegungsmelder
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> no_trigger
#S .Trigger_condition ->
#S .Trigger_off -> no_trigger
#S .Trigger_on -> *:state:on
#S .Trigger_time ->
#S .V_Check -> V 0.3
#S Exec_cmd -> set Dummy_Lampe on
#S Trigger_device -> all_events
#S Trigger_log -> on
#S last_event -> Dummy_Bewegungsmelder:state:on
#S state -> on
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Debug -> 1
#A MSwitch_Extensions -> 1
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A MSwitch_Lock_Quickedit -> 1
#A room -> bsp
#A MSwitch_Include_MSwitchcmds -> 0
#A MSwitch_Delete_Delays -> 1
#A MSwitch_Mode -> Full
#A MSwitch_Expert -> 1
#A MSwitch_Include_Webcmds -> 1
#A MSwitch_Help -> 1

ziemlich schnell zusammengeklickt , denke aber das es geht .

gruss Thomas

EDIT : dummy_bewegungsmelder schaltet nur zwischn 18 und 6 uhr , findest du in den conditions
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 27 Mai 2018, 13:48:42
nachtrag:

im Feld 'switch Mswitch on + execute 'on' commands' kannst du auch alle events durchlassen  , add event * und den dann auswählen.

Auf die einzelevents wird ja nochmal bei den conditions unterschieden.

gruss thomas
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 27 Mai 2018, 13:52:00
ok, viel Futter für Papa  :o

Muß ich jetzt die Dummys anlegen und mit den Tastern belegen, oder statt der dummys die Taster/Lampe eintragen?
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 27 Mai 2018, 13:54:59
ok, viel Futter für Papa  :o

Muß ich jetzt die Dummys anlegen und mit den Tastern belegen, oder statt der dummys die Taster/Lampe eintragen?
Genau , die Dummys und die von denen generierten events musst du durch deine Geräte und deren events ersetzen.

Gruss thomas

Gesendet von meinem SM-G900F mit Tapatalk

EDIT:

es kann hier zu problemen kommen , wenn das event des bewegungsmelder kommt, und quasi im selben moment das manuelle anschalten . das kannst du mit dem attribut MSwitch_Wait umgehen. wenn das gesetzt ist  nimmt das modul nach einem event für gesetzte zeit keine weiteren events an , um fhem und MSwitch zeit zu geben , alle zustaände richtig herzustellen.

Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 27 Mai 2018, 14:25:30
Funktioniert leider nicht. Anbei mal die config von dem MSwitch wie ich ihn angepasst habe

#S .Device_Affected -> Flur_Lampe-AbsCmd1,Flur_Lampe-AbsCmd2,Flur_Lampe-AbsCmd3
#S .Device_Affected_Details -> Flur_Lampe-AbsCmd1,on,no_action,,,delay1,delay1,000000,000000,[$EVENT]~eq~"Flur_Taster2_Motion:state:motion"~AND~off~eq~"off"~AND~[18:00-06:00],,0,0|Flur_Lampe-AbsCmd2,off,no_action,,,delay1,delay1,000000,000000,[$EVENT]~eq~"Flur_Taster2_Motion:state:motion"~AND~off~eq~"off"~AND~[18:00-06:00],,0,0|Flur_Lampe-AbsCmd3,MSwitchtoggle,no_action,on/off,,delay1,delay1,000000,000000,[$EVENT]~eq~"Flur_Taster1:state:*Short"~OR~[$EVENT]~eq~"Flur_Taster2_01:trigger:Short*"~OR~[$EVENT]~eq~"Flur_Taster2_02:trigger:Short*",,0,0
#S .Device_Events -> no_trigger|*
#S .First_init -> done
#S .Trigger_Whitelist -> Flur_Taster1,Flur_Taster2_01,Flur_Taster2_02,Flur_Taster2_Motion
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> no_trigger
#S .Trigger_condition ->
#S .Trigger_off -> no_trigger
#S .Trigger_on -> *
#S .Trigger_time ->
#S .V_Check -> V 0.3
#S Exec_cmd -> set Dummy_Lampe on
#S Trigger_device -> all_events
#S Trigger_log -> off
#S last_event -> Flur_Taster2_Motion:trigger_cnt:204
#S state -> on
#A room -> bsp
#A MSwitch_Include_MSwitchcmds -> 0
#A MSwitch_Inforoom -> MSwitch
#A MSwitch_Mode -> Full
#A MSwitch_Help -> 1
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Expert -> 1
#A MSwitch_Extensions -> 1
#A MSwitch_Delete_Delays -> 1
#A MSwitch_Debug -> 1
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A MSwitch_Lock_Quickedit -> 1
#A MSwitch_Include_Webcmds -> 1

Bin jetzt aber auch erstmal unterwegs.
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: andies am 27 Mai 2018, 14:30:13
Ich habe mal angefangen, eine Einführung zu entwerfen. Eventuell fixieren wir die auch im ersten Post? Ich brauche, glaube ich, da mithilfe von der Community. Ist das, was da bisher steht, überhaupt richtig? Was sollte als nächstes kommen?
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 27 Mai 2018, 14:35:43
Funktioniert leider nicht. Anbei mal die config von dem MSwitch wie ich ihn angepasst habe

#S .Device_Affected -> Flur_Lampe-AbsCmd1,Flur_Lampe-AbsCmd2,Flur_Lampe-AbsCmd3
#S .Device_Affected_Details -> Flur_Lampe-AbsCmd1,on,no_action,,,delay1,delay1,000000,000000,[$EVENT]~eq~"Flur_Taster2_Motion:state:motion"~AND~off~eq~"off"~AND~[18:00-06:00],,0,0|Flur_Lampe-AbsCmd2,off,no_action,,,delay1,delay1,000000,000000,[$EVENT]~eq~"Flur_Taster2_Motion:state:motion"~AND~off~eq~"off"~AND~[18:00-06:00],,0,0|Flur_Lampe-AbsCmd3,MSwitchtoggle,no_action,on/off,,delay1,delay1,000000,000000,[$EVENT]~eq~"Flur_Taster1:state:*Short"~OR~[$EVENT]~eq~"Flur_Taster2_01:trigger:Short*"~OR~[$EVENT]~eq~"Flur_Taster2_02:trigger:Short*",,0,0
#S .Device_Events -> no_trigger|*
#S .First_init -> done
#S .Trigger_Whitelist -> Flur_Taster1,Flur_Taster2_01,Flur_Taster2_02,Flur_Taster2_Motion
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> no_trigger
#S .Trigger_condition ->
#S .Trigger_off -> no_trigger
#S .Trigger_on -> *
#S .Trigger_time ->
#S .V_Check -> V 0.3
#S Exec_cmd -> set Dummy_Lampe on
#S Trigger_device -> all_events
#S Trigger_log -> off
#S last_event -> Flur_Taster2_Motion:trigger_cnt:204
#S state -> on
#A room -> bsp
#A MSwitch_Include_MSwitchcmds -> 0
#A MSwitch_Inforoom -> MSwitch
#A MSwitch_Mode -> Full
#A MSwitch_Help -> 1
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Expert -> 1
#A MSwitch_Extensions -> 1
#A MSwitch_Delete_Delays -> 1
#A MSwitch_Debug -> 1
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A MSwitch_Lock_Quickedit -> 1
#A MSwitch_Include_Webcmds -> 1

Bin jetzt aber auch erstmal unterwegs.

wenn du es noch schaffdt, mach doch bitte im device mal 'save events' an , löse jedes beteiligte gerät mal aus und schicke mir dann nochmal die config. dann habe ich auch alle generierten events und kann es mir anschauen.

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 27 Mai 2018, 14:36:36
Ich habe mal angefangen, eine Einführung zu entwerfen. Eventuell fixieren wir die auch im ersten Post? Ich brauche, glaube ich, da mithilfe von der Community. Ist das, was da bisher steht, überhaupt richtig? Was sollte als nächstes kommen?

bekommen jetzt auch erstmal besuch , ich schaue es mir später an . thx.

gruss thomas
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 27 Mai 2018, 19:29:36
Ich habe mal angefangen, eine Einführung zu entwerfen. Eventuell fixieren wir die auch im ersten Post? Ich brauche, glaube ich, da mithilfe von der Community. Ist das, was da bisher steht, überhaupt richtig? Was sollte als nächstes kommen?

Das liest sich doch schonmal gut  :) .... ich denke es sollte hier ähnlich wiki schritt für schritt vorgegangen werden , attr, sets , gets und webinterface ...stück für stück.

gruss Thomas
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 27 Mai 2018, 19:59:47
wenn du es noch schaffdt, mach doch bitte im device mal 'save events' an , löse jedes beteiligte gerät mal aus und schicke mir dann nochmal die config. dann habe ich auch alle generierten events und kann es mir anschauen.

gruss Byte09

Habe das jetzt vom Handy gemacht, da alle PC's besetzt. Hoffe ist komplett.

#S .Device_Affected -> Flur_Lampe-AbsCmd1,Flur_Lampe-AbsCmd2,Flur_Lampe-AbsCmd3
#S .Device_Affected_Details -> Flur_Lampe-AbsCmd1,on,no_action,,,delay1,delay1,000000,000000,[$EVENT]~eq~"Flur_Taster2_Motion:state:motion"~AND~off~eq~"off"~AND~[18:00-06:00],,0,0|Flur_Lampe-AbsCmd2,off,no_action,,,delay1,delay1,000000,000000,[$EVENT]~eq~"Flur_Taster2_Motion:state:motion"~AND~off~eq~"off"~AND~[18:00-06:00],,0,0|Flur_Lampe-AbsCmd3,MSwitchtoggle,no_action,on/off,,delay0,delay1,000030,000000,[$EVENT]~eq~"Flur_Taster1:state:on"~OR~[$EVENT]~eq~"Flur_Taster2_01:state:on"~OR~[$EVENT]~eq~"Flur_Taster2_02:state:on",,0,0
#S .Device_Events -> global:INITIALIZED|testmswitch:state:on|testmswitch:EVENT:global:INITIALIZED|testmswitch1:EVTPART3:on|testmswitch:last_event:global:INITIALIZED|testmswitch1:EVTPART2:state|testmswitch1:EVTPART1:testmswitch|testmswitch1:state:on|testmswitch:EVTPART1:global|testmswitch:EVTPART2:global|*|testmswitch:EVTPART3:INITIALIZED|testmswitch1:EVTFULL:testmswitch:state:on|testmswitch:EVTFULL:global:global:INITIALIZED|testmswitch1:EVENT:testmswitch:state:on|testmswitch1:last_event:testmswitch:state:on
#S .First_init -> done
#S .Trigger_Whitelist -> Flur_Taster1,Flur_Taster2_01,Flur_Taster2_02,Flur_Taster2_Motion
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> no_trigger
#S .Trigger_condition ->
#S .Trigger_off -> no_trigger
#S .Trigger_on -> *
#S .Trigger_time ->
#S .V_Check -> V 0.3
#S Exec_cmd -> set Dummy_Lampe on
#S Trigger_device -> all_events
#S Trigger_log -> on
#S last_event -> testmswitch1:state:on
#S state -> on
#A MSwitch_Expert -> 1
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A MSwitch_Mode -> Full
#A MSwitch_Debug -> 1
#A MSwitch_Extensions -> 1
#A MSwitch_Lock_Quickedit -> 1
#A MSwitch_Inforoom -> MSwitch
#A MSwitch_Include_MSwitchcmds -> 0
#A MSwitch_Delete_Delays -> 1
#A MSwitch_Include_Webcmds -> 1
#A room -> bsp
#A MSwitch_Help -> 1
#A MSwitch_Include_Devicecmds -> 1

Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 27 Mai 2018, 20:21:56
Habe das jetzt vom Handy gemacht, da alle PC's besetzt. Hoffe ist komplett.

#S .Device_Affected -> Flur_Lampe-AbsCmd1,Flur_Lampe-AbsCmd2,Flur_Lampe-AbsCmd3
#S .Device_Affected_Details -> Flur_Lampe-AbsCmd1,on,no_action,,,delay1,delay1,000000,000000,[$EVENT]~eq~"Flur_Taster2_Motion:state:motion"~AND~off~eq~"off"~AND~[18:00-06:00],,0,0|Flur_Lampe-AbsCmd2,off,no_action,,,delay1,delay1,000000,000000,[$EVENT]~eq~"Flur_Taster2_Motion:state:motion"~AND~off~eq~"off"~AND~[18:00-06:00],,0,0|Flur_Lampe-AbsCmd3,MSwitchtoggle,no_action,on/off,,delay0,delay1,000030,000000,[$EVENT]~eq~"Flur_Taster1:state:on"~OR~[$EVENT]~eq~"Flur_Taster2_01:state:on"~OR~[$EVENT]~eq~"Flur_Taster2_02:state:on",,0,0
#S .Device_Events -> global:INITIALIZED|testmswitch:state:on|testmswitch:EVENT:global:INITIALIZED|testmswitch1:EVTPART3:on|testmswitch:last_event:global:INITIALIZED|testmswitch1:EVTPART2:state|testmswitch1:EVTPART1:testmswitch|testmswitch1:state:on|testmswitch:EVTPART1:global|testmswitch:EVTPART2:global|*|testmswitch:EVTPART3:INITIALIZED|testmswitch1:EVTFULL:testmswitch:state:on|testmswitch:EVTFULL:global:global:INITIALIZED|testmswitch1:EVENT:testmswitch:state:on|testmswitch1:last_event:testmswitch:state:on
#S .First_init -> done
#S .Trigger_Whitelist -> Flur_Taster1,Flur_Taster2_01,Flur_Taster2_02,Flur_Taster2_Motion
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> no_trigger
#S .Trigger_condition ->
#S .Trigger_off -> no_trigger
#S .Trigger_on -> *
#S .Trigger_time ->
#S .V_Check -> V 0.3
#S Exec_cmd -> set Dummy_Lampe on
#S Trigger_device -> all_events
#S Trigger_log -> on
#S last_event -> testmswitch1:state:on
#S state -> on
#A MSwitch_Expert -> 1
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A MSwitch_Mode -> Full
#A MSwitch_Debug -> 1
#A MSwitch_Extensions -> 1
#A MSwitch_Lock_Quickedit -> 1
#A MSwitch_Inforoom -> MSwitch
#A MSwitch_Include_MSwitchcmds -> 0
#A MSwitch_Delete_Delays -> 1
#A MSwitch_Include_Webcmds -> 1
#A room -> bsp
#A MSwitch_Help -> 1
#A MSwitch_Include_Devicecmds -> 1


ja, ist alles drinnen was ich brauche. schaffe es aber erst morgen abend, dir ein entsprechended configfile ( auf deine geräte bezogen ) zu machen , muss jetzt gleich noch weg.

gruss Byte09

edit:
ggf.kannst du dir das beispiel ja auch nochmal anscheuen, in deiner version ist einiges quer, insbesondere bei den events.
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 27 Mai 2018, 20:30:45
Da ich diese Woche Spätschicht habe, kann ich das dann erst Dienstag Vormittag testen
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 28 Mai 2018, 10:15:21
Habe es hinbekommen

#S .Device_Affected -> Flur_Lampe-AbsCmd1,Flur_Lampe-AbsCmd2,Flur_Lampe-AbsCmd3
#S .Device_Affected_Details -> Flur_Lampe-AbsCmd1,on,no_action,,,delay1,delay1,000000,000000,[$EVTPART1]~eq~"Flur_Taster2_Motion"~AND~off~eq~"off"~AND~[18:00-06:00],,0,0|Flur_Lampe-AbsCmd2,off,no_action,,,delay0,delay1,000030,000000,[$EVTPART1]~eq~"Flur_Taster2_Motion"~AND~off~eq~"off"~AND~[18:00-06:00],,0,0|Flur_Lampe-AbsCmd3,MSwitchtoggle,no_action,on/off,,delay1,delay1,000000,000000,[$EVENT]~eq~"Flur_Taster1:state:Flur_Taster1_01"~OR~[$EVENT]~eq~"Flur_Taster1:state:Flur_Taster1_02"~OR~[$EVTPART1]~eq~"Flur_Taster2_01"~OR~[$EVTPART1]~eq~"Flur_Taster2_02",,0,0
#S .Device_Events -> Flur_Taster1:battery:ok|Flur_Taster2_01:trigger_cnt:74|Flur_Taster2_01:trigger_cnt:73|Flur_Taster2_Motion:state:motion|Flur_Taster2_01:state:Short 1_73 (to broadcast)|Flur_Taster2_Motion:trigger_cnt:122|Flur_Taster2_01:trigger:Short_74|Flur_Taster1:state:Flur_Taster1_02 Short|Flur_Taster2_02:trigger_cnt:79|Flur_Taster2_Motion:motion:on (to broadcast)|Flur_Taster2_01:state:Short 1_74 (to broadcast)|Flur_Taster2_Motion:motion:off|Flur_Taster2_Motion:brightness:110|Flur_Taster1:state:Flur_Taster1_01 Short|Flur_Taster2_Motion:motionCount:122_next:30s|Flur_Taster2_01:trigger:Short_73|no_trigger|*|Flur_Taster2_Motion:state:noMotion|Flur_Taster2_02:trigger:Short_79|Flur_Taster2_Motion:motionDuration:32|Flur_Taster2_02:state:Short 1_79 (to broadcast)
#S .First_init -> done
#S .Trigger_Whitelist -> Flur_Taster1,Flur_Taster2_01,Flur_Taster2_02,Flur_Taster2_Motion
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> no_trigger
#S .Trigger_condition ->
#S .Trigger_off -> no_trigger
#S .Trigger_on -> *
#S .Trigger_time ->
#S .V_Check -> V 0.3
#S Exec_cmd -> set Flur_Lampe off
#S Trigger_device -> all_events
#S Trigger_log -> off
#S last_event -> Flur_Taster2_Motion:state:noMotion
#S state -> on
#A MSwitch_Delete_Delays -> 1
#A MSwitch_Help -> 1
#A MSwitch_Include_Devicecmds -> 1
#A room -> Flur->Licht
#A MSwitch_Include_Webcmds -> 1
#A MSwitch_Inforoom -> MSwitch
#A MSwitch_Lock_Quickedit -> 1
#A MSwitch_Include_MSwitchcmds -> 0
#A MSwitch_Extensions -> 1
#A MSwitch_Mode -> Full
#A MSwitch_Debug -> 1
#A MSwitch_Expert -> 1
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul


Nur das mit dem Bewegungsmelder habe ich noch nicht getestet

Jetzt funktioniert es wieder nicht. Suche später warum
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 28 Mai 2018, 10:59:12
Habe es hinbekommen

#S .Device_Affected -> Flur_Lampe-AbsCmd1,Flur_Lampe-AbsCmd2,Flur_Lampe-AbsCmd3
#S .Device_Affected_Details -> Flur_Lampe-AbsCmd1,on,no_action,,,delay1,delay1,000000,000000,[$EVTPART1]~eq~"Flur_Taster2_Motion"~AND~off~eq~"off"~AND~[18:00-06:00],,0,0|Flur_Lampe-AbsCmd2,off,no_action,,,delay0,delay1,000030,000000,[$EVTPART1]~eq~"Flur_Taster2_Motion"~AND~off~eq~"off"~AND~[18:00-06:00],,0,0|Flur_Lampe-AbsCmd3,MSwitchtoggle,no_action,on/off,,delay1,delay1,000000,000000,[$EVENT]~eq~"Flur_Taster1:state:Flur_Taster1_01"~OR~[$EVENT]~eq~"Flur_Taster1:state:Flur_Taster1_02"~OR~[$EVTPART1]~eq~"Flur_Taster2_01"~OR~[$EVTPART1]~eq~"Flur_Taster2_02",,0,0
#S .Device_Events -> Flur_Taster1:battery:ok|Flur_Taster2_01:trigger_cnt:74|Flur_Taster2_01:trigger_cnt:73|Flur_Taster2_Motion:state:motion|Flur_Taster2_01:state:Short 1_73 (to broadcast)|Flur_Taster2_Motion:trigger_cnt:122|Flur_Taster2_01:trigger:Short_74|Flur_Taster1:state:Flur_Taster1_02 Short|Flur_Taster2_02:trigger_cnt:79|Flur_Taster2_Motion:motion:on (to broadcast)|Flur_Taster2_01:state:Short 1_74 (to broadcast)|Flur_Taster2_Motion:motion:off|Flur_Taster2_Motion:brightness:110|Flur_Taster1:state:Flur_Taster1_01 Short|Flur_Taster2_Motion:motionCount:122_next:30s|Flur_Taster2_01:trigger:Short_73|no_trigger|*|Flur_Taster2_Motion:state:noMotion|Flur_Taster2_02:trigger:Short_79|Flur_Taster2_Motion:motionDuration:32|Flur_Taster2_02:state:Short 1_79 (to broadcast)
#S .First_init -> done
#S .Trigger_Whitelist -> Flur_Taster1,Flur_Taster2_01,Flur_Taster2_02,Flur_Taster2_Motion
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> no_trigger
#S .Trigger_condition ->
#S .Trigger_off -> no_trigger
#S .Trigger_on -> *
#S .Trigger_time ->
#S .V_Check -> V 0.3
#S Exec_cmd -> set Flur_Lampe off
#S Trigger_device -> all_events
#S Trigger_log -> off
#S last_event -> Flur_Taster2_Motion:state:noMotion
#S state -> on
#A MSwitch_Delete_Delays -> 1
#A MSwitch_Help -> 1
#A MSwitch_Include_Devicecmds -> 1
#A room -> Flur->Licht
#A MSwitch_Include_Webcmds -> 1
#A MSwitch_Inforoom -> MSwitch
#A MSwitch_Lock_Quickedit -> 1
#A MSwitch_Include_MSwitchcmds -> 0
#A MSwitch_Extensions -> 1
#A MSwitch_Mode -> Full
#A MSwitch_Debug -> 1
#A MSwitch_Expert -> 1
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul


Nur das mit dem Bewegungsmelder habe ich noch nicht getestet

Jetzt funktioniert es wieder nicht. Suche später warum
Kurz da Handy  . Da stimmt mit deinen condition was nicht .  Irgendwo taucht da sinngemäß auf  ... wenn off dann off ... .
Scalte doch mal das Attribut debug auf 1 , dann kannst du jedes event bei jeder bondition testen und siehst welches er wie beantwortet.

Gruss thomas

Gesendet von meinem SM-G900F mit Tapatalk

Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 28 Mai 2018, 11:31:28
die condition habe ich so von dir übernommen und nur die dummys durch meine Geräte ersetzt.

Was mir aber jetzt auffällt, die readings EVENT, EVTPART1, EVTPART2 & EVTPART3 werden nicht mehr gefüttert

In der CUL_HM kann ich aber sehen, dass die Taster noch senden und die Signale empfangen werden
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 28 Mai 2018, 12:10:19
#S .Device_Affected -> Flur_Lampe-AbsCmd1,Flur_Lampe-AbsCmd2,Flur_Lampe-AbsCmd3
#S .Device_Affected_Details -> Flur_Lampe-AbsCmd1,on,no_action,,,delay1,delay1,000000,000000,[$EVENT]~eq~"Flur_Taster2_Motion:state:motion"~AND~off~eq~"off"~AND~[18:00-06:00],,0,0|Flur_Lampe-AbsCmd2,off,no_action,,,delay0,delay1,000030,000000,[$EVENT]~eq~"Flur_Taster2_Motion:state:motion"~AND~off~eq~"off"~AND~[18:00-06:00],,0,0|Flur_Lampe-AbsCmd3,MSwitchtoggle,no_action,on/off,,delay1,delay1,000000,000000,,,,
#S .Device_Events -> Flur_Taster2_01:trigger_cnt:105|*|Flur_Taster2_02:state:Short 1_108 (to broadcast)|Flur_Taster1:state:Flur_Taster1_02 Short|no_trigger|Flur_Taster2_01:state:Short 1_105 (to broadcast)|Flur_Taster2_02:trigger:Short_108|Flur_Taster2_01:trigger:Short_105|Flur_Taster2_02:trigger_cnt:108|Flur_Taster1:state:Flur_Taster1_01 Short|Flur_Taster1:battery:ok
#S .First_init -> done
#S .Trigger_Whitelist -> Flur_Taster1,Flur_Taster2_01,Flur_Taster2_02,Flur_Taster2_Motion
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> no_trigger
#S .Trigger_condition ->
#S .Trigger_off -> no_trigger
#S .Trigger_on -> *
#S .Trigger_time ->
#S .V_Check -> V 0.3
#S Exec_cmd -> set Flur_Lampe on
#S Trigger_device -> all_events
#S Trigger_log -> off
#S last_event -> Flur_Taster2_Motion:trigger_cnt:196
#S state -> on
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Extensions -> 1
#A MSwitch_Lock_Quickedit -> 1
#A MSwitch_Expert -> 1
#A MSwitch_Mode -> Full
#A MSwitch_Include_Webcmds -> 1
#A MSwitch_Inforoom -> MSwitch
#A MSwitch_Delete_Delays -> 1
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A room -> Flur->Licht
#A MSwitch_Include_MSwitchcmds -> 0
#A disable -> 0
#A MSwitch_Help -> 1
#A MSwitch_Debug -> 1

Damit funktioniert es erstmal, habe leider keine Zeit mehr zum weitersuchen. Das einzige Problem ist, dass momentan der Bewegungsmelder immer die Lampe einschaltet, das ausschalten nach 30sek funktioniert auch
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 28 Mai 2018, 17:47:21
habe mich jetzt gerade mal an dein configfile gesetzt , da ist einiges im argen ,z.b. hier : 'on condition'

[$EVENT] eq "Flur_Taster2_Motion:state:motion" AND off eq "off" AND [18:00-06:00]

das macht so keinen sinnn und war auch in dem file den ich dir geposted habe nicht so , ich habe diesen eben selber nochmal eingespielt.

Wie dem auch sei , ich mache dir nachher die konfig, komme aber mit denen devices noch nicht ganz klar. was solle folgende devices bewirken?

Flur_Taster1 - an/aus denke ich
Flur_Taster2_01 - ?
Flur_Taster2_02 - ?
Flur_Taster2_Motion -  ist klar

gruss Byte


Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 28 Mai 2018, 21:15:07
Testversion V1.50a im Anhang.

da diese Version massiv überarbeitet ist , ist ein vorheriges Backup mit Sicherheit ratsam. Die Version ist zwar getestet , aber sicher ist sicher. Wenn ich hier keine Fehler mitgeteilt bekomme , werde ich die Version in den kommenden Tagen in das GIT laden.

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 29 Mai 2018, 06:49:19
...Flur_Taster1 - an/aus denke ich
Flur_Taster2_01 - ?
Flur_Taster2_02 - ?
Flur_Taster2_Motion -  ist klar

gruss Byte

Der Flur_Taster2 wird ja leider nicht als solcher erkannt, haben wir die Tage ja festgestellt, deswegen frage ich direkt die 2Kanäle ab. 01 nehme ich zum einschalten, 02 zum ausschalten.

Das mit den on condition finde ich seltsam. Habe es 3x von hier kopiert und jedesmal diesen Eintrag gehabt.

EDIT:

Gerade nochmal wegen dem on conditon einen MSwitch erstellt, siehe Foto.

Aber ich blicke da sowieso noch nicht ganz durch
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 29 Mai 2018, 07:29:17
Der Fehler der config entsteht beim einspielen des config Files habe ich heute morgen gesehen ... beheben ich heute abend.

Das File poste ich dir dann heute abend

Gruss thomas

Gesendet von meinem SM-G900F mit Tapatalk

Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 29 Mai 2018, 08:37:11
V1.50 bekannte Fehler. ..

- Fehler beim Rückspiegel eines config Files
- Fehler im löschverhalten von delays unter best.  Umständen

Gruss Byte09

Gesendet von meinem SM-G900F mit Tapatalk

Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 29 Mai 2018, 19:43:47
V1.50 bekannte Fehler. ..

- Fehler beim Rückspiegel eines config Files
- Fehler im löschverhalten von delays unter best.  Umständen

Gruss Byte09

Gesendet von meinem SM-G900F mit Tapatalk

beide Fehler behoben , Version 1.50b im Anhang.
Achtung: Configfiles aus vorherigen Versionen sind nicht mehr kompatibel !!

Backups sind davon nicht betroffen und sind weiterhin nutzbar.

Gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 30 Mai 2018, 11:41:17
Habe jetzt nochmal ein bisschen rum gespielt und anscheinend habe ich es hinbekommen.

Hier die config:
#V V1.50b
#S .Device_Affected -> Flur_Lampe-AbsCmd1,Flur_Lampe-AbsCmd2
#S .Device_Affected_Details -> Flur_Lampe-AbsCmd1,MSwitchtoggle,no_action,on/off,,delay1,delay1,000000,000000,[$EVENT]~eq~"state.~Flur_Taster1_02~Short"~OR~[$EVENT]~eq~"state.~Flur_Taster1_01~Short"~OR~[$EVTPART1]~eq~"Flur_Taster2_01"~OR~[$EVTPART1]~eq~"Flur_Taster2_02",,0,0|Flur_Lampe-AbsCmd2,on-for-timer,no_action,2,,delay1,delay1,000000,000000,[$EVTPART1]~eq~"Flur_Taster2_Motion"~AND~[18.00-06.00],,0,0
#S .Device_Events -> *|no_trigger
#S .First_init -> done
#S .Trigger_Whitelist -> Flur_Taster1,Flur_Taster2_01,Flur_Taster2_02,Flur_Taster2_Motion
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> no_trigger
#S .Trigger_condition ->
#S .Trigger_off -> no_trigger
#S .Trigger_on -> *
#S .Trigger_time ->
#S .V_Check -> V 0.3
#S Exec_cmd -> set Flur_Lampe on
#S Trigger_device -> all_events
#S Trigger_log -> off
#S last_event -> trigger_cnt: 45
#S state -> on
#A disable -> 0
#A MSwitch_Include_Webcmds -> 1
#A MSwitch_Delete_Delays -> 1
#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_Extensions -> 1
#A room -> test
#A MSwitch_Inforoom -> MSwitch
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Lock_Quickedit -> 1
#A MSwitch_Help -> 1
#A MSwitch_Expert -> 1
#A MSwitch_Debug -> 1
#A MSwitch_Mode -> Full

Aber es wird sich im laufe des Tages herausstellen, ob wirklich alles so klappt, wie ich es gerne hätte.

Bei V1.44 war mir noch ein Problem aufgefallen und zwar hatte ich ein paarmal das Problem gehabt, dass einzelne "MSwitch" "eingefroren" waren. Es gab keine Reaktion und auch in den Readings hat sich bei EVENT, EVTFULL, EVTPART1, EVTPART2 & EVTPART3 nichts mehr getan, die Schalter haben aber fleißig gesendet. Wenn das Problem nochmal auftritt melde ich mich morgen.
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 30 Mai 2018, 11:59:34
Kurze Frage nochmal dazu:


...
Ich kann über meine Tablet UI die 2 Zeiten (von/bis) einstellen. Diese 2 Zeiten werden im Dummy Flur_Lampe_Dummy in den Readings Licht_an & Licht_aus abgelegt. Wie kann ich das einbinden?

Gruß Torsten
...


geht in dieser version leider nicht so einfach , müsste dann über freecmd gemacht werden. Ich werde für die nächste version( noch am WE ) eine jkleine änderung machen , sa dass er in den conditions eine solche syntax erkennt :

[[dummy1:state]-[dummy2:state]]
gruss Byte

Mein Dummy heißt Flur_Lampe_Dummy
Reading für Zeitpunkt Licht ein Licht_an
Reading für Zeitpunkt Licht aus Licht_aus

Muß ich dann bei on condition statt [18:00-6:00] folgendes eintragen:

[[Flur_Lampe_Dummy:Licht_an]-[Flur_Lampe_Dummy:Licht_aus]]

Keine Zeit zum Testen, darum die kurze Frage.
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 30 Mai 2018, 12:27:14
Ja , so sollte es gehen. Aber bitte darauf achten , dass die Zeit in den Dummys such dieses Format hh:mm haben.


Der freeze mit den nicht mehr aktualisierenden events sollte nicht mehr passieren .... eigentlich.

Gruss byte09

Gesendet von meinem SM-G900F mit Tapatalk

Titel: MSwitch V1.5
Beitrag von: Byte09 am 31 Mai 2018, 06:24:19
Ich habe die Version V1.5 eben in das GIT geladen , sie ist somit über das Update verfügbar .
Das Wiki wurde entsprechend angepasst.

Die Vorgängerversion ist im Anhang des ersten Beitrages zu finden.

Gruss Byte09

PS: Uber die neuen Attribute und Schaltmöglichkeiten ist relativ einfach eine komplexe Anwesenheitssimulation zu realisieren.
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 31 Mai 2018, 09:42:38
ATTR Safemode hinzugefügt.

Da es mit einem MSwitch Device durchaus möglich ist ... ist mir selber schon mehr als einmal passiert .... , bei entsprechender Konfiguration, das Device und somit Fhem in eine Endlosschleife zu schicken , die nur noch durch einen Neustart zu beenden ist - insbesondere daher, das sich ein MSwitch device selber togglen kann - habe ich ab sofort das Attribut 'MSwitch_Safemode (0,1)' eingeführt .

Bei aktiviertem Attribut (1) beendet das Device den Vorgang bei Verdacht auf eine Endlosschleife.
In diesem Fall erfolgt ein Logeintrag
2018.05.31 10:38:43 0: Das Device Aborttest wurde automatisch deaktiviert ( Safemode )und das Device wird automatisch auf ATTR disable gesetzt. Meim nächsten Aufruf des Devices erfolgt ein Hinweis in der Webansicht .

Vor dem deaktivieren des Devices wird ein letztes Event generiert, auf das reagiert werden kann :
2018-05-31 09:39:21 MSwitch dummytest Safemode: on
Bei Neuanlage eines (komplizierten) Devices ist die Aktivierung dieses Attributes somit durchaus empfehlenswert.

Sollte die Erkennung einer Schleife zu eng gesteckt sein , bitte kurze Info, dann erweitere ich das etwas.

gruss Byte09


Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 31 Mai 2018, 20:45:57
habe gerade update all durchgeführt und diese Meldung bekommen

2018.05.31 20:43:22 1 : UPD FHEM/98_MSwitch.pm
2018.05.31 20:43:22 1 : open ./FHEM/98_MSwitch.pm failed: Permission denied, trying to restore the previous version and aborting the update

Habe auch schon das Problem gehabt, wenn ich über FileZilla das Modul einladen möchte, dass ich das alte erstmal vom RPi löschen muß bevor ich das neue speichern kann

EDIT:

habe jetzt 98_mswitch.pm über FileZilla gelöscht, dann ging update
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 31 Mai 2018, 20:57:49
Irgendwie ist da noch der Wurm drin.

Gestern hat alles wunderbar funktioniert. Als wir eben nach Hause kamen, hat der Bewegungsmelder nicht "reagier" also Licht ging nicht an. Im On Condition steht [$EVTPART1] eq "Flur_Taster2_Motion" AND [18:00-06:00] als ich es auf [$EVTPART1] eq "Flur_Taster2_Motion" geändert habe, ging der Bewegungsmelder, als ich die Zeit wieder eingefügt habe nichtmehr. Nun habe ich noch das update gemacht, jetzt geht der MSwitch komplett nicht mehr  :o

Im reading steht jetzt auch was ganz anderes, siehe Foto
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 31 Mai 2018, 21:39:07
Irgendwie ist da noch der Wurm drin.

Gestern hat alles wunderbar funktioniert. Als wir eben nach Hause kamen, hat der Bewegungsmelder nicht "reagier" also Licht ging nicht an. Im On Condition steht [$EVTPART1] eq "Flur_Taster2_Motion" AND [18:00-06:00] als ich es auf [$EVTPART1] eq "Flur_Taster2_Motion" geändert habe, ging der Bewegungsmelder, als ich die Zeit wieder eingefügt habe nichtmehr. Nun habe ich noch das update gemacht, jetzt geht der MSwitch komplett nicht mehr  :o

Im reading steht jetzt auch was ganz anderes, siehe Foto

zu deinem ersten post : das ist/war ein rechteproblem - hast da ja wohl behoben

zum zweiten: ich habe die gesamte funktion ( kombi aus zeit und readingbedingung ) eben geprüft und kann keinen Fehler feststellen.

kannst du mir bitte den configfile schicken ?

EDIT on:
Falls du Fhem nach dem löschen der 98_Mswitch.pm neu gestartet hast , ohne das Modul , kann es sein das du die Config des MSwitch-Devices 'zerstört' hast . Diese ist dann zwar noch vorhanden und wird angezeigt , aber nicht mehr richtig eingelesen. Mit einem Klick auf 'modify device' kannst du das beheben. Ich spiele heute Nachmitag eine Version ein , die dieses in einem solchen Fall automatisch macht ( auch nach einspielen eine Configfiles - da gab es ein ähnliches Problem . Konkret: in diesen Fällen wurde das Internal 'NOTIFYDEV' nicht neu Belegt und somit nicht Korrekt getriggert)

ich weiss aber nicht ob dieses das Problem ist - nur ein Verdacht
EDIT off

Das Event , das im Reading steht, ist das letzte Event , was die Trigger-Condition passiert hat .

Gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 01 Juni 2018, 11:32:18
Ok, nach modify Device funktioniert es wieder, auch der Bewegungsmelder. Nur schaltet er jetzt das Licht 2x

#V V1.51
#S .Device_Affected -> Flur_Lampe-AbsCmd1,Flur_Lampe-AbsCmd2
#S .Device_Affected_Details -> Flur_Lampe-AbsCmd1,MSwitchtoggle,no_action,on/off,,delay1,delay1,000000,000000,[$EVENT]~eq~"state.~Flur_Taster1_02~Short"~OR~[$EVENT]~eq~"state.~Flur_Taster1_01~Short"~OR~[$EVTPART1]~eq~"Flur_Taster2_01"~OR~[$EVTPART1]~eq~"Flur_Taster2_02",,0,0|Flur_Lampe-AbsCmd2,on-for-timer,no_action,30,,delay1,delay1,000000,000000,[$EVTPART1]~eq~"Flur_Taster2_Motion"~AND~[11.00-06.00],,0,0
#S .Device_Events -> no_trigger
#S .First_init -> done
#S .Trigger_Whitelist -> Flur_Taster1,Flur_Taster2_01,Flur_Taster2_02,Flur_Taster2_Motion
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> no_trigger
#S .Trigger_condition ->
#S .Trigger_off -> no_trigger
#S .Trigger_on -> *
#S .Trigger_time ->
#S .V_Check -> V 0.3
#S Exec_cmd -> set Flur_Lampe on-for-timer 30
#S Trigger_device -> all_events
#S Trigger_log -> off
#S last_event -> Flur_Taster2_Motion:state:noMotion
#S state -> on
#A disable -> 0
#A MSwitch_Expert -> 1
#A MSwitch_Delete_Delays -> 1
#A room -> Flur->Licht,MSwitch
#A MSwitch_Help -> 1
#A MSwitch_Extensions -> 1
#A MSwitch_Debug -> 1
#A MSwitch_Lock_Quickedit -> 1
#A MSwitch_Mode -> Full
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Inforoom -> MSwitch
#A MSwitch_Include_MSwitchcmds -> 0
#A MSwitch_Include_Webcmds -> 1
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul

Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 01 Juni 2018, 11:47:59
Bin in 2 Std wieder zuhause ... schaue es mir dann an .

Gruss Byte09

Gesendet von meinem SM-G900F mit Tapatalk

Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 01 Juni 2018, 11:58:15
Ok, bin in 30min zur Arbeit. Bin also erst ab morgen wieder erreichbar
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 02 Juni 2018, 07:10:20
Ok, bin in 30min zur Arbeit. Bin also erst ab morgen wieder erreichbar

Hi Torsten,

ich habe mich jetzt recht lange damit beschäftigt . Entgegen meiner bisherigen Aussage ist es über ein Device aus verschiedenen Gründen nicht lösbar ( zumindest nicht ohne einen weiteren Dummy ):
1. die Devices liefern teilweise gleiche events, was eine trennung in einem MSwitch echt schwierig macht
2. wenn es über ein MSwitch gelöst wird kann das MSwitch nicht prüfen , wodurch das Licht angeschaltet wurde  ( manuell ? ) und somit nicht entscheiden, ob der bewegungsmelder nun aktiv sein soll oder nicht .

Also Fakt ist - es werden 2 Devices benötigt.

Die angehängten Configfiles setzen V1.52 und folgende Devices als vorhanden voraus:
Flur_Taster1
Flur_Taster2_01
Flur_Taster2_Motion
Flur_Lampe

und sollten wie folgt heissen :

Lampenschalter (MSwitch für taster)
Bewegungschalter (MSwitch für Bewegungsmelder)
bei anderer Namensgebung muss entsprechend anders konfiguriert werden.


das erste Device: ( hier: Lampenschalter)
mit diesem reagierst du nur auf die Taster. Um eine Kontrollmöglichkeit zu haben , ob das Licht durch die Taster angeschaltet wurde betreibst du dieses MSwitch im Togglemode. Somit kann durch das zweite Device später der Zustand dieses Devices abgefragt werden und somit der Bewegungsmelder aktiviert werden / oder eben nicht.
Getriggert werden muss in diesem Device GLOBAL, da du auf mehrere Geräte ( Taster ) reagieren willst.
Der Togglemode des MSwitcdevices bewirkt, das sich bei jedem getriggerten Event der Zustand des MSwitches toggelt und alle eingetragenen Geräte ( Lampe ) mit in den Zustand des MSwitches schalten.
Konfiguration im Anhang 1
File:
#V V1.52
#S .Device_Affected -> Flur_Lampe-AbsCmd1
#S .Device_Affected_Details -> Flur_Lampe-AbsCmd1,on,off,,,delay1,delay1,000000,000000,,,0,0
#S .Device_Events -> *:*:Short*|no_trigger
#S .First_init -> done
#S .Trigger_Whitelist -> Flur_Taster1,Flur_Taster2_01
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> no_trigger
#S .Trigger_condition ->
#S .Trigger_off -> no_trigger
#S .Trigger_on -> *:*:Short*
#S .Trigger_time ->
#S .V_Check -> V 0.3
#S Exec_cmd -> set Flur_Lampe off
#S Trigger_device -> all_events
#S Trigger_log -> off
#S last_event -> trigger: Short_12
#S state -> off
#A room -> Flur->Licht,MSwitch
#A MSwitch_Extensions -> 1
#A MSwitch_Mode -> Toggle
#A MSwitch_Debug -> 1
#A MSwitch_Lock_Quickedit -> 1
#A MSwitch_Delete_Delays -> 1
#A disable -> 0
#A MSwitch_Help -> 1
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Include_MSwitchcmds -> 0
#A MSwitch_Inforoom -> MSwitch
#A MSwitch_Expert -> 1
#A MSwitch_Include_Webcmds -> 1
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul


das zweite Device: ( Bewegungschalter )
dieses Devive betreibst du im Notifymode und es Triggert nur auf den Bewegungsmeder , und schaltet die Lampe für 30 sekunden an , aber nur dann , wenn das erste Device auf 'off' steht und die Lampen somit ebenfalls aus sind . Als weitere Bedingung schaltet es nur zwischen xx und xx Uhr.
Steht das erste Device auf an , d.H die Lampen wurden manuell angeschaltet , reagiert das zweite Device gar nicht .
Konfiguration im Anhang 2.
File:
#V V1.52
#S .Device_Affected -> Flur_Lampe-AbsCmd1
#S .Device_Affected_Details -> Flur_Lampe-AbsCmd1,on-for-timer,no_action,5,,delay1,delay1,000000,000000,,,0,0
#S .Device_Events -> motion:on|no_trigger
#S .First_init -> done
#S .Trigger_Whitelist -> undef
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> motion:on
#S .Trigger_condition -> [Lampenschalter.state]~eq~"off"~AND~[16.00-22.00]
#S .Trigger_off -> no_trigger
#S .Trigger_on -> no_trigger
#S .Trigger_time ->
#S .V_Check -> V 0.3
#S Exec_cmd -> set Flur_Lampe on-for-timer 5
#S Trigger_device -> Flur_Taster2_Motion
#S Trigger_log -> off
#S last_event -> trigger:Short_45
#S state -> active
#A MSwitch_Extensions -> 0
#A MSwitch_Mode -> Notify
#A MSwitch_Debug -> 0
#A MSwitch_Lock_Quickedit -> 1
#A room -> Flur->Licht
#A MSwitch_Include_MSwitchcmds -> 0
#A MSwitch_Inforoom -> MSwitch
#A MSwitch_Expert -> 0
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A MSwitch_Include_Webcmds -> 0
#A MSwitch_Delete_Delays -> 1
#A MSwitch_Help -> 0
#A MSwitch_Include_Devicecmds -> 1

Bitte auf die Abhängigkeiten - insbesondere in der Namensgebung - achten und anpassen.

Gruss Byte
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 02 Juni 2018, 11:13:37
Wenn ich jetzt nichts übersehen habe, habe ich es mit einem MSwitch und einem Dummy hinbekommen
Warte aber jetzt noch heute Abend ab, wenn der Timer greift:

#V V1.51
#S .Device_Affected -> Flur_Lampe-AbsCmd1,Flur_Lampe-AbsCmd2,Flur_Lampe_Dummy-AbsCmd1
#S .Device_Affected_Details -> Flur_Lampe-AbsCmd1,MSwitchtoggle,no_action,on/off,,delay1,delay1,000000,000000,[$EVENT]~eq~"Flur_Taster1.state.Flur_Taster1_02"~OR~[$EVENT]~eq~"Flur_Taster1.state.Flur_Taster1_01"~OR~[$EVTPART1]~eq~"Flur_Taster2_01"~OR~[$EVTPART1]~eq~"Flur_Taster2_02",,0,0|Flur_Lampe-AbsCmd2,on-for-timer,no_action,30,,delay1,delay1,000000,000000,[$EVTPART1]~eq~"Flur_Taster2_Motion"~AND~[$EVTPART2]~eq~"trigger_cnt"~AND~[Flur_Lampe_Dummy.off]~AND~[18.00-06.00],,0,0|Flur_Lampe_Dummy-AbsCmd1,MSwitchtoggle,no_action,on/off,,delay1,delay1,000000,000000,[$EVENT]~eq~"Flur_Taster1.state.Flur_Taster1_02"~OR~[$EVENT]~eq~"Flur_Taster1.state.Flur_Taster1_01"~OR~[$EVTPART1]~eq~"Flur_Taster2_01"~OR~[$EVTPART1]~eq~"Flur_Taster2_02",,0,0
#S .Device_Events -> *state*|no_trigger|*
#S .First_init -> done
#S .Trigger_Whitelist -> Flur_Taster1,Flur_Taster2_01,Flur_Taster2_02,Flur_Taster2_Motion
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> no_trigger
#S .Trigger_condition ->
#S .Trigger_off -> no_trigger
#S .Trigger_on -> *
#S .Trigger_time ->
#S .V_Check -> V 0.3
#S Exec_cmd -> set Flur_Lampe on-for-timer 30
#S Trigger_device -> all_events
#S Trigger_log -> off
#S last_event -> Flur_Taster2_Motion:trigger_cnt:78
#S state -> on
#A disable -> 0
#A MSwitch_Expert -> 1
#A MSwitch_Delete_Delays -> 1
#A room -> Flur->Licht,MSwitch
#A MSwitch_Help -> 1
#A MSwitch_Extensions -> 1
#A MSwitch_Debug -> 1
#A MSwitch_Lock_Quickedit -> 1
#A MSwitch_Mode -> Full
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Inforoom -> MSwitch
#A MSwitch_Include_MSwitchcmds -> 0
#A MSwitch_Include_Webcmds -> 1
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 02 Juni 2018, 12:16:42
Wenn ich jetzt nichts übersehen habe, habe ich es mit einem MSwitch und einem Dummy hinbekommen
Warte aber jetzt noch heute Abend ab, wenn der Timer greift:

#V V1.51
#S .Device_Affected -> Flur_Lampe-AbsCmd1,Flur_Lampe-AbsCmd2,Flur_Lampe_Dummy-AbsCmd1
#S .Device_Affected_Details -> Flur_Lampe-AbsCmd1,MSwitchtoggle,no_action,on/off,,delay1,delay1,000000,000000,[$EVENT]~eq~"Flur_Taster1.state.Flur_Taster1_02"~OR~[$EVENT]~eq~"Flur_Taster1.state.Flur_Taster1_01"~OR~[$EVTPART1]~eq~"Flur_Taster2_01"~OR~[$EVTPART1]~eq~"Flur_Taster2_02",,0,0|Flur_Lampe-AbsCmd2,on-for-timer,no_action,30,,delay1,delay1,000000,000000,[$EVTPART1]~eq~"Flur_Taster2_Motion"~AND~[$EVTPART2]~eq~"trigger_cnt"~AND~[Flur_Lampe_Dummy.off]~AND~[18.00-06.00],,0,0|Flur_Lampe_Dummy-AbsCmd1,MSwitchtoggle,no_action,on/off,,delay1,delay1,000000,000000,[$EVENT]~eq~"Flur_Taster1.state.Flur_Taster1_02"~OR~[$EVENT]~eq~"Flur_Taster1.state.Flur_Taster1_01"~OR~[$EVTPART1]~eq~"Flur_Taster2_01"~OR~[$EVTPART1]~eq~"Flur_Taster2_02",,0,0
#S .Device_Events -> *state*|no_trigger|*
#S .First_init -> done
#S .Trigger_Whitelist -> Flur_Taster1,Flur_Taster2_01,Flur_Taster2_02,Flur_Taster2_Motion
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> no_trigger
#S .Trigger_condition ->
#S .Trigger_off -> no_trigger
#S .Trigger_on -> *
#S .Trigger_time ->
#S .V_Check -> V 0.3
#S Exec_cmd -> set Flur_Lampe on-for-timer 30
#S Trigger_device -> all_events
#S Trigger_log -> off
#S last_event -> Flur_Taster2_Motion:trigger_cnt:78
#S state -> on
#A disable -> 0
#A MSwitch_Expert -> 1
#A MSwitch_Delete_Delays -> 1
#A room -> Flur->Licht,MSwitch
#A MSwitch_Help -> 1
#A MSwitch_Extensions -> 1
#A MSwitch_Debug -> 1
#A MSwitch_Lock_Quickedit -> 1
#A MSwitch_Mode -> Full
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Inforoom -> MSwitch
#A MSwitch_Include_MSwitchcmds -> 0
#A MSwitch_Include_Webcmds -> 1
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul

jetzt nur mal schnell drüber geflogen . Diese condition :
[$EVENT] eq "Flur_Taster1:state:Flur_Taster1_02" OR [$EVENT] eq "Flur_Taster1:state:Flur_Taster1_01" OR [$EVTPART1] eq "Flur_Taster2_01" OR [$EVTPART1] eq "Flur_Taster2_02"
reagiert nur daher überhaupt, da diese Teile greifen:

OR [$EVENT] eq "OR [$EVTPART1] eq "Flur_Taster2_01" OR [$EVTPART1] eq "Flur_Taster2_02"
die zwei ausdrücke davor werden nie greifen , da es sich bei deiner abfrage 'Flur_Taster1:state:Flur_Taster1_02'  nicht um events handeln, die jemals eintreten.

Ich sehe zwar wie du es dir gedacht hast , hat aber - selbst wenn es funktioniert - den nachteil , das der bewegungsmelder nicht mehr "nach"schaltet , wenn er einmal angeschaltet hat , sprich : das licht muss erst ausgehen und erst dann kann der bewegungsmelder es wieder anschalten. warum machst du es nicht wie oben von mir beschrieben ,  so schaltet der bewegungsmelder den on-for-timer immer wieder neu , solange bewegung erkannt wird und das licht geht nicht aus, solange sich jemand im flur? aufhält.

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 02 Juni 2018, 12:37:30
Alle Events kommen so wie eingetragen, mache später mal Screenshots bin gerade unterwegs
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 02 Juni 2018, 12:45:15
Alle Events kommen so wie eingetragen, mache später mal Screenshots bin gerade unterwegs

hm, ok  ...... muss mir glaube ich unbedingt mal so einen taster / bewegungsmelder kaufen !
kannst du mir mal die bezeichnung von den teilen geben ?

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 02 Juni 2018, 12:56:51
... Der Bewegungsmelder ist in einem Taster Homematic HM-Sen-MDIR-WM55 integriert. Den Sensor habe ich als Trigger Device Flur_Taster2_Motion genommen, der Funktioniert problemlos. Der andere Taster im Flur ist ein HM-PB-2-WM55 ...
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 02 Juni 2018, 17:35:55
Hier mal die Screenshots von meinen Events
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 02 Juni 2018, 21:13:51
Habe jetzt mal versucht statt einem festen Wert [18:00-06:00]
die Variablen Werte aus dem Dummy zu nehmen [[Flur_Lampe_Dummy:Licht_an]-[Flur_Lampe_Dummy:Licht_aus]]

Aber leider scheint es nicht zu funktionieren.

Anbei Foto vom on condition
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Ranseyer am 02 Juni 2018, 22:00:26
Hi,

MSwitch habe ich über einen anderen Thread kennengelernt.

Ich habe mal versucht das Thema Markise damit abzubilden (weil ich daran gerade war).

Aufgefallen ist mir: Ein List auf das Device gibt mir auch ein paar Infos:
Internals:
   CFGFN     
   DEF        WG_Steuerung # WG_Steuerung
   NAME       Test
   NOTIFYDEV  WG_Steuerung
   NR         521
   NTFY_ORDER 45-Test
   STATE      on
   TYPE       MSwitch
   Version    V1.52
   OLDREADINGS:
   READINGS:
     2018-06-02 21:38:45   EVENT           down2:
     2018-06-02 21:38:45   EVTFULL         WG_Steuerung:down2:
     2018-06-02 21:38:45   EVTPART1        WG_Steuerung
     2018-06-02 21:38:45   EVTPART2        down2
     2018-06-02 21:38:45   EVTPART3         
     2018-06-02 21:38:45   Exec_cmd        set WG_Steuerung down2
     2018-06-02 21:43:46   Trigger_device  WG_Steuerung
     2018-06-02 20:25:04   Trigger_log     off
     2018-06-02 21:38:45   last_event      down2:
     2018-06-02 21:38:45   state           on
   helper:
     eventfrom  WG_Steuerung
     events:
       WG_Steuerung:
         no_trigger on
     savemodeblock:
     timer:
       1527976810 1527976810-5
Attributes:
   DbLogExclude .*
   MSwitch_Debug 0
   MSwitch_Delete_Delays 1
   MSwitch_Expert 0
   MSwitch_Extensions 0
   MSwitch_Help 0
   MSwitch_Ignore_Types notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
   MSwitch_Include_Devicecmds 1
   MSwitch_Include_MSwitchcmds 0
   MSwitch_Include_Webcmds 0
   MSwitch_Lock_Quickedit 1
   MSwitch_Mode Full

Aber in der RAW-Definition steht z.B. auch:
Zitat
setstate Test 2018-06-02 21:49:35 .Trigger_time on[00:30:00*8:00-19:00]~off~ononly~offonly
Das ist mir nur so aufgefallen und für jetzt weniger ein Problem.

Warum ich es im Moment nicht für diesen Zweck verwenden kann ist dass ich meinen Schaltbefehl nicht eintragen kann:"set WG_Steuerung:FILTER=percentage2<100 percentage2 100"
Vermutlich unwissenheit bei mir.

Und: Könnte ich falls das Problem zu lösen ist auch noch die Frage: Kann ich on/off durch andere Bezeichnungen ersetzen (Oben / Unten) ?

PS: Weitere Hinweise: Speichern laut Wikitext/CMDRef ist mir unklar:
Zitat
Unknown command Fhemsave, try help.
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 03 Juni 2018, 05:47:41
Habe jetzt mal versucht statt einem festen Wert [18:00-06:00]
die Variablen Werte aus dem Dummy zu nehmen [[Flur_Lampe_Dummy:Licht_an]-[Flur_Lampe_Dummy:Licht_aus]]

Aber leider scheint es nicht zu funktionieren.

Anbei Foto vom on condition

gib mir bitte mal die raw definition eines der summys in dem du die zeiten stehen hast .

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 03 Juni 2018, 06:02:35
Hi,

MSwitch habe ich über einen anderen Thread kennengelernt.

Ich habe mal versucht das Thema Markise damit abzubilden (weil ich daran gerade war).

Aufgefallen ist mir: Ein List auf das Device gibt mir auch ein paar Infos:
Internals:
   CFGFN     
   DEF        WG_Steuerung # WG_Steuerung
   NAME       Test
   NOTIFYDEV  WG_Steuerung
   NR         521
   NTFY_ORDER 45-Test
   STATE      on
   TYPE       MSwitch
   Version    V1.52
   OLDREADINGS:
   READINGS:
     2018-06-02 21:38:45   EVENT           down2:
     2018-06-02 21:38:45   EVTFULL         WG_Steuerung:down2:
     2018-06-02 21:38:45   EVTPART1        WG_Steuerung
     2018-06-02 21:38:45   EVTPART2        down2
     2018-06-02 21:38:45   EVTPART3         
     2018-06-02 21:38:45   Exec_cmd        set WG_Steuerung down2
     2018-06-02 21:43:46   Trigger_device  WG_Steuerung
     2018-06-02 20:25:04   Trigger_log     off
     2018-06-02 21:38:45   last_event      down2:
     2018-06-02 21:38:45   state           on
   helper:
     eventfrom  WG_Steuerung
     events:
       WG_Steuerung:
         no_trigger on
     savemodeblock:
     timer:
       1527976810 1527976810-5
Attributes:
   DbLogExclude .*
   MSwitch_Debug 0
   MSwitch_Delete_Delays 1
   MSwitch_Expert 0
   MSwitch_Extensions 0
   MSwitch_Help 0
   MSwitch_Ignore_Types notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
   MSwitch_Include_Devicecmds 1
   MSwitch_Include_MSwitchcmds 0
   MSwitch_Include_Webcmds 0
   MSwitch_Lock_Quickedit 1
   MSwitch_Mode Full

Aber in der RAW-Definition steht z.B. auch:Das ist mir nur so aufgefallen und für jetzt weniger ein Problem.

Warum ich es im Moment nicht für diesen Zweck verwenden kann ist dass ich meinen Schaltbefehl nicht eintragen kann:"set WG_Steuerung:FILTER=percentage2<100 percentage2 100"
Vermutlich unwissenheit bei mir.

Und: Könnte ich falls das Problem zu lösen ist auch noch die Frage: Kann ich on/off durch andere Bezeichnungen ersetzen (Oben / Unten) ?

PS: Weitere Hinweise: Speichern laut Wikitext/CMDRef ist mir unklar:

hier habe ich leider einen fehler in derm wiki gemacht . die zeitangabe für mehrfaches schalten darf nicht wie von dir angegeben ' [00:30:00*8:00-19:00] 'sein , sondern die intervallangabe darf nur 4 stellig sein . Richtig ist: '[00:30*8:00-19:00]'.

grundsätlich kannst du alle schaltbefehle verwenden, die das zu schaltende Device verstehst , im grunde sollten die dir im webinterface auch angeboten werden.

bei dem rest kann ich noch nicht genau folgen. kannst du bitte nochmal erklären was genau du wann schalten willst ?

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 03 Juni 2018, 08:44:54
gib mir bitte mal die raw definition eines der summys in dem du die zeiten stehen hast .

gruss Byte09


defmod Flur_Lampe_Dummy dummy
attr Flur_Lampe_Dummy disable 0
attr Flur_Lampe_Dummy room Flur->Licht
attr Flur_Lampe_Dummy setList on off
attr Flur_Lampe_Dummy webCmd on:off

setstate Flur_Lampe_Dummy off
setstate Flur_Lampe_Dummy 2018-05-26 10:16:30 Dummy_Lampe_Flur off
setstate Flur_Lampe_Dummy 2018-06-02 20:53:39 Licht_an 19:00
setstate Flur_Lampe_Dummy 2018-06-02 20:53:43 Licht_aus 07:00
setstate Flur_Lampe_Dummy 2018-06-02 17:21:45 state off
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 03 Juni 2018, 09:21:16

defmod Flur_Lampe_Dummy dummy
attr Flur_Lampe_Dummy disable 0
attr Flur_Lampe_Dummy room Flur->Licht
attr Flur_Lampe_Dummy setList on off
attr Flur_Lampe_Dummy webCmd on:off

setstate Flur_Lampe_Dummy off
setstate Flur_Lampe_Dummy 2018-05-26 10:16:30 Dummy_Lampe_Flur off
setstate Flur_Lampe_Dummy 2018-06-02 20:53:39 Licht_an 19:00
setstate Flur_Lampe_Dummy 2018-06-02 20:53:43 Licht_aus 07:00
setstate Flur_Lampe_Dummy 2018-06-02 17:21:45 state off

ok, da habe ich einen fehler in der regex , sonderzeichen werden im namen nicht zugelassen - ich korrigiere das und stelle den fix gleich online .

gruss Thomas
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 03 Juni 2018, 09:50:25
ich habe gerade ein update in das git gestellt, damit geht es.

gruss thomas
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 03 Juni 2018, 10:05:41
ich habe gerade ein update in das git gestellt, damit geht es.

gruss thomas

Teste es heute Abend, da ich en ganzen Tag unterwegs bin
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 03 Juni 2018, 14:55:44
einfach mal ein Tipp !

Umsetzung eines Linearschalters mit MSwitch :
 
https://forum.fhem.de/index.php/topic,88331.msg807985.html#msg807985 (https://forum.fhem.de/index.php/topic,88331.msg807985.html#msg807985)

werde ich die Tage als Tipp in das Wiki übernehmen ( mit Raw definition als Beispiel ).

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 03 Juni 2018, 17:37:11
Teste es heute Abend, da ich en ganzen Tag unterwegs bin

Funktioniert leider immer noch nicht

EDIT:
Habe gerade festgestellt, dass der ganze MSwitch nicht mehr geht

EDIT2:
Nachdem ich nochmal Modify trigger Device durchgeführt habe klappt alles
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 03 Juni 2018, 18:30:45
Funktioniert leider immer noch nicht

EDIT:
Habe gerade festgestellt, dass der ganze MSwitch nicht mehr geht

EDIT2:
Nachdem ich nochmal Modify trigger Device durchgeführt habe klappt alles

ok, super.

ich kann das Problem noch nicht ganz nachvollziehen, wann er den Trigger verliert, sprich du den modify drücken musst, kannst du das ggf. nachvollziehen, was du vorher tust , das es das verliert ( backup einspielen , config einspielen etc. )

gruss Byte09

Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 03 Juni 2018, 18:43:19
ok, super.

ich kann das Problem noch nicht ganz nachvollziehen, wann er den Trigger verliert, sprich du den modify drücken musst, kannst du das ggf. nachvollziehen, was du vorher tust , das es das verliert ( backup einspielen , config einspielen etc. )

gruss Byte09

Leider nein, ich habe nur gesehen, dass der letzte Eintrag in den Events heute morgen war und irgendwas mit "Init..." in den Readings bei EVENT stand. Falls es nochmal passiert mache ich ein paar Screenshots
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 03 Juni 2018, 18:52:08
Habe gerade festgestellt, dass eine Sache nicht funktioniert.

Als ich für mein Flurlicht noch 3 MSwitch hatte und in dem für den Dimmer das on-for-timer und pct hatte, hat die Lampe abends gedimmt geschaltet. Das Dimmen funktioniert jetzt in dem zusammengelegten Switch seltsamer weise nicht mehr, obwohl ich bei bei beiden on condition das gleiche eingetragen habe.
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 03 Juni 2018, 19:01:01
Habe gerade festgestellt, dass eine Sache nicht funktioniert.

Als ich für mein Flurlicht noch 3 MSwitch hatte und in dem für den Dimmer das on-for-timer und pct hatte, hat die Lampe abends gedimmt geschaltet. Das Dimmen funktioniert jetzt in dem zusammengelegten Switch seltsamer weise nicht mehr, obwohl ich bei bei beiden on condition das gleiche eingetragen habe.

so schwer zu beurteilen so  . da kann ggf ein gemeinsames event ( dadurch das du nur teile auswertest ) ? Auf der sicheren und einfacheren seite bist du wirklich wenn du es trennst .

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 06 Juni 2018, 18:40:29
Wiki wurde um den Tipp 'Linearschalter' ergänzt:

https://wiki.fhem.de/wiki/MSwitch.pm#Lienearschalter (https://wiki.fhem.de/wiki/MSwitch.pm#Lienearschalter)

Gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: mark79 am 10 Juni 2018, 12:42:09
Hallo Byte,

ich habe ein neues Spielzeug, ein Xiaomi Cube und versuche mit MSwitch eine Multifunktion umzusetzen.
https://youtu.be/iPMrfjilYzU?t=50s & https://forum.fhem.de/index.php/topic,84790.0.html

Komme da aber nicht recht weiter, wenn ich das MSwitch Device erweitere, funktioniert es nicht mehr und zudem springt immer der Safemode an. Habe diesen nun deaktiviert...

Der Würfel hat 7 Funktionen bzw. Events: shake, rotate_left, rotate_ride, tap, slide, flip90, flip180, fall

Ich möchte damit die Kodi Lautstärke regeln und das Schranklicht dimmen. Über rotate_left, rotate_ride

Mit "shake" schaltet MSwitch ein Dummy auf KU_KODI/KU_Schranklicht im Toggle Modus um, was auch funktioniert.

Und über AND [KU_MSwitch_Dummy] eq "KU_Schranklicht" möchte ich in den einzelnen MSwitch Devices selektieren, was beim drehen des Würfels passieren soll:
KU_LED_Stripe_Schrank
MSwitch on cmd: Set > dimdown 10
on condition: [$EVENT] eq "KU_Cube:action:rotate_left" AND [KU_MSwitch_Dummy] eq "KU_Schranklicht"

Nur das  mit dem Dummy und dem Filtern nach "KU_KODI/KU_Schranklicht" funktioniert nicht. Ich habe davon zwei Screenshots angelegt.

Der erste Screenshot zeigt ein MSwitch Device welches funktioniert ohne die AND Regel.
Der zweite Screenshot zeigt das Device, was ich eigentlich umsetzen möchte und was nicht funktioniert.

Eventlog:
2018-06-10 12:39:22 MSwitch KU_Cube_MSwitch last_event: transmission-state: incoming publish received
2018-06-10 12:39:22 MSwitch KU_Cube_MSwitch last_event: KU_Cube:transmission-state:incomingpublishreceived
2018-06-10 12:39:22 MSwitch KU_Cube_MSwitch last_event: KU_Cube:transmission-state:incomingpublishreceived
2018-06-10 12:39:22 MSwitch KU_Cube_MSwitch last_event: KU_Cube:transmission-state:incomingpublishreceived
2018-06-10 12:39:22 MSwitch KU_Cube_MSwitch last_event: KU_Cube:transmission-state:incomingpublishreceived
2018-06-10 12:39:22 MSwitch KU_Cube_MSwitch last_event: KU_Cube:transmission-state:incomingpublishreceived
2018-06-10 12:39:22 XiaomiMQTTDevice KU_Cube transmission-state: incoming publish received
2018-06-10 12:39:22 MSwitch KU_Cube_MSwitch last_event: voltage: 3005
2018-06-10 12:39:22 MSwitch KU_Cube_MSwitch last_event: KU_Cube:voltage:3005
2018-06-10 12:39:22 MSwitch KU_Cube_MSwitch last_event: KU_Cube:voltage:3005
2018-06-10 12:39:22 MSwitch KU_Cube_MSwitch last_event: KU_Cube:voltage:3005
2018-06-10 12:39:23 MSwitch KU_Cube_MSwitch last_event: KU_Cube:voltage:3005
2018-06-10 12:39:23 MSwitch KU_Cube_MSwitch last_event: KU_Cube:voltage:3005
2018-06-10 12:39:23 MSwitch KU_Cube_MSwitch last_event: battery_level: 100.00
2018-06-10 12:39:23 MSwitch KU_Cube_MSwitch last_event: KU_Cube:battery_level:100.00
2018-06-10 12:39:23 MSwitch KU_Cube_MSwitch last_event: KU_Cube:battery_level:100.00
2018-06-10 12:39:23 MSwitch KU_Cube_MSwitch last_event: KU_Cube:battery_level:100.00
2018-06-10 12:39:23 MSwitch KU_Cube_MSwitch last_event: KU_Cube:battery_level:100.00
2018-06-10 12:39:23 MSwitch KU_Cube_MSwitch last_event: KU_Cube:battery_level:100.00
2018-06-10 12:39:23 MSwitch KU_Cube_MSwitch last_event: battery: ok
2018-06-10 12:39:23 MSwitch KU_Cube_MSwitch last_event: KU_Cube:battery:ok
2018-06-10 12:39:23 MSwitch KU_Cube_MSwitch last_event: KU_Cube:battery:ok
2018-06-10 12:39:23 MSwitch KU_Cube_MSwitch last_event: KU_Cube:battery:ok
2018-06-10 12:39:23 MSwitch KU_Cube_MSwitch last_event: KU_Cube:battery:ok
2018-06-10 12:39:23 MSwitch KU_Cube_MSwitch last_event: KU_Cube:battery:ok
2018-06-10 12:39:23 MSwitch KU_Cube_MSwitch last_event: action: rotate_left
2018-06-10 12:39:23 MSwitch KU_Cube_MSwitch last_event: KU_Cube:action:rotate_left
2018-06-10 12:39:23 MSwitch KU_Cube_MSwitch last_event: KU_Cube:action:rotate_left
2018-06-10 12:39:23 MSwitch KU_Cube_MSwitch last_event: KU_Cube:action:rotate_left
2018-06-10 12:39:23 MSwitch KU_Cube_MSwitch last_event: KU_Cube:action:rotate_left
2018-06-10 12:39:23 MSwitch KU_Cube_MSwitch last_event: KU_Cube:action:rotate_left
2018-06-10 12:39:23 MSwitch KU_Cube_MSwitch last_event: angle: -89.05
2018-06-10 12:39:23 MSwitch KU_Cube_MSwitch last_event: KU_Cube:angle:-89.05
2018-06-10 12:39:23 MSwitch KU_Cube_MSwitch last_event: KU_Cube:angle:-89.05
2018-06-10 12:39:23 MSwitch KU_Cube_MSwitch last_event: KU_Cube:angle:-89.05
2018-06-10 12:39:23 MSwitch KU_Cube_MSwitch last_event: KU_Cube:angle:-89.05
2018-06-10 12:39:23 MSwitch KU_Cube_MSwitch last_event: KU_Cube:angle:-89.05
2018-06-10 12:39:23 XiaomiMQTTDevice KU_Cube voltage: 3005
2018-06-10 12:39:23 XiaomiMQTTDevice KU_Cube battery_level: 100.00
2018-06-10 12:39:23 XiaomiMQTTDevice KU_Cube battery: ok
2018-06-10 12:39:23 XiaomiMQTTDevice KU_Cube action: rotate_left
2018-06-10 12:39:23 XiaomiMQTTDevice KU_Cube angle: -89.05

Wäre super wenn du da mal drüber schauen könntest und wenn du ne bessere Idee hast, immer her damit. :)


Viele Grüße
Mark
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: mark79 am 10 Juni 2018, 13:05:31
Ich habe den Fehler gefunden, bei KU_MSwitch_Dummy fehlt das "state".  ::)
Also so: KU_MSwitch_Dummy:state
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 10 Juni 2018, 13:27:35
Ich habe den Fehler gefunden, bei KU_MSwitch_Dummy fehlt das "state".  ::)
Also so: KU_MSwitch_Dummy:state

OT: braucht du dafür ein Gateway, oder kann er direkt mit fhem ?

Gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: mark79 am 10 Juni 2018, 14:02:02
OT: braucht du dafür ein Gateway, oder kann er direkt mit fhem ?

Gruss Byte09

Entweder das orginale Gateway oder ein Zigbee Stick: https://github.com/Koenkk/zigbee2mqtt/wiki/Supported-sniffer-devices
Würde dir ein CC2530 empfehlen, wegen der größeren Reichweite. Man muss diesen aber in beiden Fällen noch umflashen.

Der Vorteil daran ist, man benötigt das originale GW nicht, also ohne Xiaomi Cloud. Man kann mehr Geräte anbinden, ich glaube bis zu 50 und die Devices haben teilweise mehr Funktionen als mit dem org. Gateway. Und dazu kann man noch Ikea und Hue etc. anbinden: https://github.com/Koenkk/zigbee2mqtt/wiki/Supported-devices

EDIT: Der Würfel ist im Moment auch noch im Angebot: https://www.mydealz.de/deals/xiaomi-aqara-cube-remote-controller-fur-6-aktionen-gateway-wird-benotigt-1177426
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 10 Juni 2018, 14:26:26
Entweder das orginale Gateway oder ein Zigbee Stick: https://github.com/Koenkk/zigbee2mqtt/wiki/Supported-sniffer-devices
Würde dir ein CC2530 empfehlen, wegen der größeren Reichweite. Man muss diesen aber in beiden Fällen noch umflashen.

Der Vorteil daran ist, man benötigt das originale GW nicht, also ohne Xiaomi Cloud. Man kann mehr Geräte anbinden, ich glaube bis zu 50 und die Devices haben teilweise mehr Funktionen als mit dem org. Gateway. Und dazu kann man noch Ikea und Hue etc. anbinden: https://github.com/Koenkk/zigbee2mqtt/wiki/Supported-devices

EDIT: Der Würfel ist im Moment auch noch im Angebot: https://www.mydealz.de/deals/xiaomi-aqara-cube-remote-controller-fur-6-aktionen-gateway-wird-benotigt-1177426

dank dir, ich habe mir das ganze Zeugs gerade bestellt .... jetzt heisst es warten.

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 10 Juni 2018, 14:38:53
MSwitch - Fhem SVN

ich habe mich heute entschlossen, das Modul MSwitch leider auch längerfristig nicht in das Fhem SVN zu übernehmen.
Ein Modul, welches in das SVN soll muss eine comandref beinhalten ( auch eine Englische Version ist Voraussetzung ).
Da dieses Modul ständig in der Weiterentwicklung ist und  der Funktionsumfang deutlich zu Gross ist, um ihn nur in der Commandref zu beschreiben habe ich angefangen das Wiki zu schreiben und versuche dieses auf dem laufenden zu halten , weiterhin versuche ich die modulinternen Hilfetexte permanent zu aktualisieren.

Da ich denke das das Wiki unverzichbar ist,  macht mir die zusätzliche nötige Aktualisierung der Commandref ( noch dazu in 2 Sprachen ) den doppelten und dreifachen  Arbeitsaufwand - und dazu habe ich, schlicht und ergreifend, derzeit keine Motivation ( die Zeit stecke ich lieber in das Modul ) .

von daher bleibt die derzeitige 'GIT' Lösung weiterhin so bestehen. Ich denke das ist für die User, die es gerne nutzen, und  da es sich ohnehin irgendwie um ein 'Nischenmodul ' handelt, eine nicht unüberwindbare Hürde.

Gruss Byte09

PS:seit der letzten Version ist im übrigen das komplette Einspielen einer RAW-Definition eines MSwitch Devices möglich und es muss insofern nicht mehr zwingend über ein Config-File eingespielt werden.
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: mark79 am 10 Juni 2018, 16:13:05
dank dir, ich habe mir das ganze Zeugs gerade bestellt .... jetzt heisst es warten.

gruss Byte09

Gern geschehen und ich bin schon gespannt, was du mit dem Würfel umsetzt ;)
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 10 Juni 2018, 16:13:23
Hallo Byte,

.......

Hi Mark,

warum triggerst du in deiner obigen Config 'GLOBAT' und filterst dann in der 'Whitelist' nur auf den Würfel ?
das ist deutlich systemlastiger , als wenn du direkt auf den Würfel triggern würdest .
Den Trigger auf GLOBAL zu setzen , würde ich nur dann machen , wenn ich in einem Devive gerne mehrere Trigger nutzen würde ( verschiedene Geräte  ).

gruss Byte09

edit: aber achtung wenn du das änderst . wenn du direkt auf ein Gerät triggerst , ist das event nur noch '2stellig' , also ohne gerätenamen . Das ist dann in den Conditions zu beachten !
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: mark79 am 10 Juni 2018, 16:40:21
Mhh gute Frage :D
Ich bin noch in der Lernphase und teste viel rum. Ich habe vorher noch nicht mit der Global und $EVENT Funktion gearbeitet.

Ich habe es aber jetzt umgestellt:
Trigger device: KU_Cube (a: t:XiaomiMQTTDevice)
[$EVENT] eq "action:rotate_right" AND [KU_MSwitch_Dummy:state] eq "KU_KODI"

Funktioniert auch :)

Ich werde das aber wohl noch umändern auf Free Cmd und dann noch ein TTS mit einbauen. Wo man eine Bestätigung erhält, auf welches Dummy Device (Kodi oder LED Schranklicht) es gerade umgeschaltet hat.

Noch eine Frage.. Kann man eigentlich auch bei...
execute 'on' commands only
execute 'off' commands only

auf beiden mit "*" triggern? und bei den zu schaltenen Devices mit "on" "off" arbeiten.
Also z.B. bei on volumedown und bei off auf volumedown?
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 10 Juni 2018, 18:55:56
Mhh gute Frage :D
Ich bin noch in der Lernphase und teste viel rum. Ich habe vorher noch nicht mit der Global und $EVENT Funktion gearbeitet.

Ich habe es aber jetzt umgestellt:
Trigger device: KU_Cube (a: t:XiaomiMQTTDevice)
[$EVENT] eq "action:rotate_right" AND [KU_MSwitch_Dummy:state] eq "KU_KODI"

Funktioniert auch :)

Ich werde das aber wohl noch umändern auf Free Cmd und dann noch ein TTS mit einbauen. Wo man eine Bestätigung erhält, auf welches Dummy Device (Kodi oder LED Schranklicht) es gerade umgeschaltet hat.

Noch eine Frage.. Kann man eigentlich auch bei...
execute 'on' commands only
execute 'off' commands only

auf beiden mit "*" triggern? und bei den zu schaltenen Devices mit "on" "off" arbeiten.
Also z.B. bei on volumedown und bei off auf volumedown?
Bei den 'only' zweigen geht das triggern in beiden zweigen auf Wildcard '*'. In den beiden zweigen in denen das Device auch umschaltet 'switch mswitch Device and execute ...' geht es nicht .  Die Auswertung des events muss dann in den condition der Schaltzweige erfolgen.

Am besten das mswitch in den notifymode setzen , dann hast du eh nur noch die beiden zweigen , in denen das geht

Gruss Byte09

Gesendet von meinem SM-G900F mit Tapatalk
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 12 Juni 2018, 16:22:53
Da ich ja gerne hätte, dass abends das Licht gedämmt ist, wenn es vom Bewegungsmelder eingeschaltet wird, habe ich wieder ein seperates MSwitch dafür angelegt, so wie es schonmal funktioniert hat (Hoffe ich habe da nichts vergessen). Aber aus irgendeinem Grund funktioniert es nicht mehr. Der On-for-Timer funktioniert, aber nicht der pct. Einzeln funktioniert es, zusammen aber nicht

#V V1.54
#S .Device_Affected -> Flur_Lampe-AbsCmd1,Flur_Lampe-AbsCmd2
#S .Device_Affected_Details -> Flur_Lampe-AbsCmd1,pct,no_action,20,,delay1,delay1,000000,000000,,,0,0|Flur_Lampe-AbsCmd2,on-for-timer,no_action,30,,delay1,delay1,000000,000000,,,0,0
#S .Device_Events -> no_trigger|state:motion
#S .First_init -> done
#S .Trigger_Whitelist -> undef
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> no_trigger
#S .Trigger_condition ->
#S .Trigger_off -> no_trigger
#S .Trigger_on -> state:motion
#S .Trigger_time ->
#S .V_Check -> V 0.3
#S Trigger_device -> Flur_Taster2_Motion
#S Trigger_log -> off
#S last_event -> state: noMotion
#S state -> on
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A MSwitch_Help -> 0
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Include_Webcmds -> 0
#A MSwitch_Extensions -> 0
#A MSwitch_Include_MSwitchcmds -> 0
#A MSwitch_Delete_Delays -> 1
#A MSwitch_Lock_Quickedit -> 1
#A MSwitch_Inforoom -> MSwitch
#A MSwitch_Mode -> Full
#A MSwitch_Expert -> 0
#A MSwitch_Debug -> 0
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 12 Juni 2018, 17:53:14
Da ich ja gerne hätte, dass abends das Licht gedämmt ist, wenn es vom Bewegungsmelder eingeschaltet wird, habe ich wieder ein seperates MSwitch dafür angelegt, so wie es schonmal funktioniert hat (Hoffe ich habe da nichts vergessen). Aber aus irgendeinem Grund funktioniert es nicht mehr. Der On-for-Timer funktioniert, aber nicht der pct. Einzeln funktioniert es, zusammen aber nicht

#V V1.54
#S .Device_Affected -> Flur_Lampe-AbsCmd1,Flur_Lampe-AbsCmd2
#S .Device_Affected_Details -> Flur_Lampe-AbsCmd1,pct,no_action,20,,delay1,delay1,000000,000000,,,0,0|Flur_Lampe-AbsCmd2,on-for-timer,no_action,30,,delay1,delay1,000000,000000,,,0,0
#S .Device_Events -> no_trigger|state:motion
#S .First_init -> done
#S .Trigger_Whitelist -> undef
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> no_trigger
#S .Trigger_condition ->
#S .Trigger_off -> no_trigger
#S .Trigger_on -> state:motion
#S .Trigger_time ->
#S .V_Check -> V 0.3
#S Trigger_device -> Flur_Taster2_Motion
#S Trigger_log -> off
#S last_event -> state: noMotion
#S state -> on
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A MSwitch_Help -> 0
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Include_Webcmds -> 0
#A MSwitch_Extensions -> 0
#A MSwitch_Include_MSwitchcmds -> 0
#A MSwitch_Delete_Delays -> 1
#A MSwitch_Lock_Quickedit -> 1
#A MSwitch_Inforoom -> MSwitch
#A MSwitch_Mode -> Full
#A MSwitch_Expert -> 0
#A MSwitch_Debug -> 0

eweriss jetzt gerade nicht wie du es schonmal hattest, aber ich habe ähnlich probleme mit meinen dimmern gehabt ( konnte kein on-for-timer gleichzeitig mit dem pct auslösen ) . Ich habe es so gelöst , dass ich den dimmer nicht auf on-for-timer setze, sondern auf pct 20.  Mit einem zweiten Befehl für den Dimmer ( im selben MSwitch Device - auch im 'on' zweig ) setze ich den Dimmer dann zeitverzögert ( delay without conditioncheck ) wieder auf 'off' . Delay entspricht dann der Zeit , die das Licht anbleibt.

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 12 Juni 2018, 17:58:13
Ich meine, ich hatte es damals genau so wie im oberen Post gemacht
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 12 Juni 2018, 18:02:29
Ich meine, ich hatte es damals genau so wie im oberen Post gemacht

gib mir doch bitte mal eine Raw - definition , incl aller beteiligten Geräte 'Dump "Probably associated with" too' , dann muss ich es nicht mit Dummys nachbauen.

Gruss Byte09


Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 12 Juni 2018, 18:23:37
@Torsten_MG

habe mich gerade nochmal reingelesen :
versuch mal statt on for timer folgenden Befehl zu setzen

set device pct 30 10
sollte den dimmer für 10 sekunden auf 30% schalten ( zumindest geht es bei meinem Homematic )

gruss Byte09

edit: die Ramptime könntest du durch die Angabe eines dritten wertes ändern . z.B: 30 10 0.1
dann dimmt er niocht langsam hoch , sondern erreicht den sollwert innerhalb 0.1 sekunden
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 12 Juni 2018, 19:21:31
@Torsten_MG

habe mich gerade nochmal reingelesen :
versuch mal statt on for timer folgenden Befehl zu setzen

set device pct 30 10
sollte den dimmer für 10 sekunden auf 30% schalten ( zumindest geht es bei meinem Homematic )

gruss Byte09

edit: die Ramptime könntest du durch die Angabe eines dritten wertes ändern . z.B: 30 10 0.1
dann dimmt er niocht langsam hoch , sondern erreicht den sollwert innerhalb 0.1 sekunden

Funktioniert einwandfrei!

Sowohl in einem separaten MSwitch als auch in meinem zusammengefassten!
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 13 Juni 2018, 18:43:33
Update auf 1.54 verfügbar:

Änderungen :
die Schaltzweige 'on...' und 'off...' wurden umbenannt in 'cmd1' und'cmd2' da die benennung doch zu verwirrung geführt hat und die Schaltzweige nicht zwangsläufig mit on und off verbunden sein müssen.

neue set befehle :

set MSwitch exec_cmd1 und exec_cmd2
die entsprechenden Schaltzweige werde ohne Eventprüfung sofort ausgeführt.
ACHTUNG in diesem Fall steht kein auswertbarebs Event zur Verfügung

Diverse interne Änderungen , insbesondere bei der Erzeugung der MSwitch Events ( reduziert ) .

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 13 Juni 2018, 18:52:00
@Andies

hier die Rawdefinition , wie besprochen.

Ich hoffe, ich habe bei den Devices überall deine Namensgebung getroffen , sonst wird es nicht gehen.

Funktion :

es wird auf 2 Geräte getriggert,  Fenster offen oder zu und Temperatur.
bei einer Änderung wird geprüft ob fenster offen und temp < 12 Grad . In diesem Fall wird eine Mail ausgegeben und und der CMD1 Zweig wird nach 10 minuten erneut abgearbeitet . Sind die bedingungen nicht erfüllt, wird cmd1 nicht erneut abgearbeitet.

im cmd2 prüfe ich nur auf die temperatur bei entsprechendem event , ist diese unter 12 grad, wird sofort cmd1 ausgelöst ( prüfung auf zustand offen und < 12 grad )

Zustandsänderung des Fensters (cmd1) führt direkt den cmd1 aus incl Prüfung .ö

Mailangaben musst du an dich anpassen ! Das Device wird im Raum MSwitchtest angelegt.

Bitte MSwitch erst Updaten ! ... bei MSwitchdevices , die sich seöber aufrufen und ändern bitte unbedingt Safemode = 1 setzen !

Gruss Byte09

defmod TMail MSwitch Schlafzimmerfenster    # FreeCmd TMail
attr TMail MSwitch_Debug 0
attr TMail MSwitch_Delete_Delays 1
attr TMail MSwitch_Expert 1
attr TMail MSwitch_Extensions 0
attr TMail MSwitch_Help 0
attr TMail MSwitch_Ignore_Types notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
attr TMail MSwitch_Include_Devicecmds 1
attr TMail MSwitch_Include_MSwitchcmds 0
attr TMail MSwitch_Include_Webcmds 1
attr TMail MSwitch_Inforoom MSwitch
attr TMail MSwitch_Lock_Quickedit 1
attr TMail MSwitch_Mode Notify
attr TMail MSwitch_Safemode 1
attr TMail room MSwitchtest

setstate TMail active
setstate TMail 2018-06-13 15:33:34 .Device_Affected FreeCmd-AbsCmd1,TMail-AbsCmd1
setstate TMail 2018-06-13 18:49:08 .Device_Affected_Details FreeCmd-AbsCmd1,cmd,cmd,{DebianMail("xxx\@web.de"##"Fenster offen!"##"Das Fenster im Schlafzimmer ist seit zwölf Minuten offen! Dort sind es jetzt ".sprintf("%.0f°C"##ReadingsVal("Schlafzimmer"##"Temperature"##""))." und das ist KALT. Bitte schließen."##"")},,delay1,delay1,000000,000000,[Schlafzimmer:Temperature]~<~12~AND~[Schlafzimmerfenster:state]~eq~"open",,0,0|TMail-AbsCmd1,exec_cmd1,exec_cmd1,,,delay0,delay1,001000,000000,[Schlafzimmer:Temperature]~<~12~AND~[Schlafzimmerfenster:state]~eq~"open",[Schlafzimmer:Temperature]~<~12~AND~[Schlafzimmerfenster:state]~eq~"open",0,0
setstate TMail 2018-06-13 18:20:49 .Device_Events testproxy:off|myBroker:connection:connecting|TMail:state:active
setstate TMail 2018-06-13 13:56:59 .First_init done
setstate TMail 2018-06-13 18:08:01 .Trigger_Whitelist Schlafzimmer,Schlafzimmerfenster
setstate TMail 2018-06-13 17:43:44 .Trigger_cmd_off Schlafzimmer:Temperature:*
setstate TMail 2018-06-13 17:43:44 .Trigger_cmd_on Schlafzimmerfenster:state:open
setstate TMail 2018-06-13 18:08:01 .Trigger_condition
setstate TMail 2018-06-13 17:43:44 .Trigger_off no_trigger
setstate TMail 2018-06-13 17:43:44 .Trigger_on no_trigger
setstate TMail 2018-06-13 18:08:01 .Trigger_time
setstate TMail 2018-06-13 13:56:59 .V_Check V 0.3
setstate TMail 2018-06-13 17:59:32 EVENT Schlafzimmer:Temperature:13
setstate TMail 2018-06-13 17:59:32 EVTFULL Schlafzimmer:Temperature:13
setstate TMail 2018-06-13 17:59:32 EVTPART1 Schlafzimmer
setstate TMail 2018-06-13 17:59:32 EVTPART2 Temperature
setstate TMail 2018-06-13 17:59:32 EVTPART3 13
setstate TMail 2018-06-13 17:59:32 Exec_cmd
setstate TMail 2018-06-13 18:20:46 Trigger_device all_events
setstate TMail 2018-06-13 17:43:44 Trigger_log on
setstate TMail 2018-06-13 17:59:32 last_event Schlafzimmer:Temperature:13
setstate TMail 2018-06-13 18:50:11 state active

EDIT : wäre auch möglich gewesen alles in einem Schaltzweig zusammenzufassen , aber so ist es glaube ich einfacher, nachzuvollziehen, was passiert.
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: mark79 am 14 Juni 2018, 08:40:02
die Schaltzweige 'on...' und 'off...' wurden umbenannt in 'cmd1' und'cmd2' da die benennung doch zu verwirrung geführt hat und die Schaltzweige nicht zwangsläufig mit on und off verbunden sein müssen.

Wenn ich ein Update mache, funktionieren denn noch die alten Configs also mit on/off? Oder muss man das überall umschreiben?

Ich habe noch ein Problem mit dem Datum/Zeit Trigger bzw. in Verwendung mit "on condition": [5:30-8:00|12345]
Diese condition sollte eigentlich nur werktags und morgens zwischen 5:30-8:00 eintreffen.
Das setzt die Kodi Lautstärke auf 61 und schaltet auf Sat1 (openchannelid 117) um.

Aber es schaltet sporadisch zu anderen Zeiten. Gestern z.B. um 17:42, schaltet Kodi einfach auf Sat1 um.
Das ist schon öfters passiert. Habe ich da irgendwo ein Fehler drin? Weil ganz früher war das nicht so.

Hier mal das Log:
2018-06-13 17:42:33 MSwitch KU_TV last_event: KU_KODI-AbsCmd2_conditionon
2018-06-13 17:42:33 KODI KU_KODI openchannelid 117
2018-06-13 17:42:33 MSwitch KU_TV Exec_cmd: set KU_KODI openchannelid 117
2018-06-13 17:42:34 KODI KU_KODI jsonResponse: {"jsonrpc":"2.0","method":"Player.OnResume","params":{"data":{"item":{"channeltype":"tv","id":111,"title":"Kabel1","type":"channel"},"player":{"playerid":1,"speed":1}},"sender":"xbmc"}}
2018-06-13 17:42:35 KODI KU_KODI jsonResponse: {"jsonrpc":"2.0","method":"Player.OnPlay","params":{"data":{"item":{"channeltype":"tv","id":117,"title":"Sat.1","type":"channel"},"player":{"playerid":1,"speed":1}},"sender":"xbmc"}}
2018-06-13 17:42:35 KODI KU_KODI currentTitle:
2018-06-13 17:42:35 KODI KU_KODI label:
2018-06-13 17:42:35 KODI KU_KODI type:
2018-06-13 17:42:35 KODI KU_KODI year:
2018-06-13 17:42:35 KODI KU_KODI jsonResponse: {"id":249,"jsonrpc":"2.0","result":{"muted":false,"name":"Kodi","version":{"major":18,"minor":0,"revision":"cd6c3fa","tag":"alpha","tagversion":"2"},"volume":71}}
2018-06-13 17:42:35 KODI KU_KODI jsonResponse: {"id":250,"jsonrpc":"2.0","result":{"fullscreen":true,"skin":{"id":"skin.estuary","name":"Estuary"},"stereoscopicmode":{"label":"Deaktiviert","mode":"off"}}}
2018-06-13 17:42:35 KODI KU_KODI jsonResponse: {"id":"251","jsonrpc":"2.0","result":[{"playerid":1,"type":"video"}]}
2018-06-13 17:42:35 KODI KU_KODI jsonResponse: {"id":"252","jsonrpc":"2.0","result":[{"playerid":1,"type":"video"}]}
2018-06-13 17:42:35 KODI KU_KODI jsonResponse: {"jsonrpc":"2.0","method":"Player.OnAVChange","params":{"data":{"item":{"channeltype":"tv","id":117,"title":"Sat.1","type":"channel"},"player":{"playerid":1,"speed":1}},"sender":"xbmc"}}
2018-06-13 17:42:35 KODI KU_KODI jsonResponse: {"id":253,"jsonrpc":"2.0","result":{"partymode":false,"repeat":"off","shuffled":false,"speed":1,"time":{"hours":0,"milliseconds":0,"minutes":12,"seconds":35},"totaltime":{"hours":0,"milliseconds":0,"minutes":30,"seconds":0}}}
2018-06-13 17:42:35 KODI KU_KODI time: 00:12:35.000
2018-06-13 17:42:35 KODI KU_KODI totaltime: 00:30:00.000
2018-06-13 17:42:35 KODI KU_KODI jsonResponse: {"id":254,"jsonrpc":"2.0","result":{"item":{"id":117,"label":"Sat.1","thumbnail":"image://https%3a%2f%2fmedia.cinergy.ch%2ft_station%2f360%2ficon320_dark.png/","title":"Schicksale - und plötzlich ist alles anders","type":"channel","year":2010}}}
2018-06-13 17:42:35 KODI KU_KODI year: 2010
2018-06-13 17:42:35 KODI KU_KODI thumbnail: image://https%3a%2f%2fmedia.cinergy.ch%2ft_station%2f360%2ficon320_dark.png/
2018-06-13 17:42:35 KODI KU_KODI currentTitle: Schicksale - und plötzlich ist alles anders
2018-06-13 17:42:35 KODI KU_KODI label: Sat.1
2018-06-13 17:42:35 KODI KU_KODI type: channel
2018-06-13 17:42:35 KODI KU_KODI id: 117
2018-06-13 17:42:35 KODI KU_KODI jsonResponse: {"jsonrpc":"2.0","method":"Player.OnAVChange","params":{"data":{"item":{"channeltype":"tv","id":117,"title":"Sat.1","type":"channel"},"player":{"playerid":1,"speed":1}},"sender":"xbmc"}}
2018-06-13 17:42:35 KODI KU_KODI jsonResponse: {"jsonrpc":"2.0","method":"Player.OnAVStart","params":{"data":{"item":{"channeltype":"tv","id":117,"title":"Sat.1","type":"channel"},"player":{"playerid":1,"speed":1}},"sender":"xbmc"}}

Readings:
Readings
EVENT
FreeCmd-AbsCmd1_conditionon
2018-06-04 06:07:27
EVTFULL
myBroker:FreeCmd-AbsCmd1_conditionon
2018-06-04 06:07:27
EVTPART1
myBroker
2018-06-04 06:07:27
EVTPART2
FreeCmd-AbsCmd1_conditionon
2018-06-04 06:07:27
Exec_cmd
set KU_KODI openchannelid 117
2018-06-13 17:42:33
Trigger_log
off
2018-06-04 22:42:00
last_event
KU_KODI-AbsCmd2_conditionon
2018-06-13 17:42:33
state
on
2018-06-13 17:29:13


Viele Grüße
Mark
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 14 Juni 2018, 08:44:59
Hi Mark,

Das update kannst du machen , es sind nur die Bezeichnungen die sich geändert haben.

Zum Rest .... das schaue ich mir heute abend an ... den Screenshot sehe ich auf dem Handy nur verwaschen dank tapatalk .... , wenn ich von der Arbeit komme und melde mich dann

Stell mir bitte mal den config file des mswitch devices hier ein.

Gruss byte09

Gesendet von meinem SM-G900F mit Tapatalk
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 14 Juni 2018, 08:55:51
Nachtrag :

Mach die Zeitangaben Bitte mal in diesem Format hh:mm statt h:mm.

Aber jetzt nur eine Vermutungen.

Gruss Bytr09

Gesendet von meinem SM-G900F mit Tapatalk
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: mark79 am 14 Juni 2018, 08:59:19
Hi Mark,

Das update kannst du machen , es sind nur die Bezeichnungen die sich geändert haben.

Zum Rest .... das schaue ich mir heute abend an ... den Screenshot sehe ich auf dem Handy nur verwaschen dank tapatalk .... , wenn ich von der Arbeit komme und melde mich dann

Stell mir bitte mal den config file des mswitch devices hier ein.

Gruss byte09

Gesendet von meinem SM-G900F mit Tapatalk

Hallo Byte09,

ahh ok nur die Bezeichnung, dann kann ich sorglos ein update machen, danke. :)

Die Config hänge ich an, ich habe aber mittlerweile ein "Probably associated with" (KU_morgens_motion) gelöscht, falls das wichtig ist. Das war nur ein leeres MSwitch Device.
#V V1.54
#S .Device_Affected -> FreeCmd-AbsCmd1,KU_KODI-AbsCmd1,KU_KODI-AbsCmd2,KU_TV_Sonoff-AbsCmd1
#S .Device_Affected_Details -> FreeCmd-AbsCmd1,cmd,cmd,{system "/opt/fhem/script/KU_KodiTV.sh&"},{system~"/opt/fhem/script/KU_KodiTV.sh&"},delay0,delay1,000013,000000,[KU_KODI.state]~ne~"opened",,0,0|KU_KODI-AbsCmd1,volume,shutdown,61,,delay1,delay1,000030,000000,[5.30-8.00(DAYS)12345],,0,0|KU_KODI-AbsCmd2,openchannelid,no_action,117,,delay1,delay1,001320,000000,[5.30-8.00(DAYS)12345],,0,0|KU_TV_Sonoff-AbsCmd1,ON,OFF,,,delay1,delay1,000000,000030,,,0,0
#S .Device_Events -> no_trigger
#S .First_init -> done
#S .Trigger_Whitelist -> undef
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> no_trigger
#S .Trigger_condition -> undef
#S .Trigger_off -> no_trigger
#S .Trigger_on -> no_trigger
#S .Trigger_time -> undef
#S .V_Check -> V 0.3
#S Trigger_device -> undef
#S Trigger_log -> off
#S last_event -> KU_KODI-AbsCmd1_conditionon
#S state -> off
#A alias -> TV Küche
#A MSwitch_Delete_Delays -> 1
#A MSwitch_Expert -> 0
#A DbLogExclude -> .*
#A group -> TV
#A room -> 2_Kueche,MSwitch
#A MSwitch_Help -> 0
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Lock_Quickedit -> 1
#A MSwitch_Extensions -> 0
#A disable -> 0
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A icon -> rc_TV
#A MSwitch_Include_Webcmds -> 0
#A MSwitch_Include_MSwitchcmds -> 0
#A verbose -> 0
#A MSwitch_Inforoom -> MSwitch
#A MSwitch_Debug -> 0
#A userattr -> lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0

Die Zeitangaben werde ich ändern.. werde berichten, wenn es noch mal auftritt.
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: andies am 14 Juni 2018, 16:13:35
@Andies

hier die Rawdefinition , wie besprochen.
Vielen, vielen Dank. Ich muss aber leider einiges nachfragen, weil das genau die Dinge sind, die ich nicht kapiere (und die ich gern auch in dem Wiki eintrage). Also mal los:
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 14 Juni 2018, 16:45:36
Vielen, vielen Dank. Ich muss aber leider einiges nachfragen, weil das genau die Dinge sind, die ich nicht kapiere (und die ich gern auch in dem Wiki eintrage). Also mal los:
  • Warum wird als device GLOBAL genommen (mit Whiteliste und zwei devices) und nicht Schlafzimmerfenster alleine? Denn nur das Fenster soll doch etwas auslösen?
  • trigger details enthält jetzt zwei cmds. Sind das die Kommandos, die früher on und off hießen? Also  'cmd1' wird vom rechts davon stehenden trigger ausgelöst, korrekt?

    Rein theoretisch könnte man das auch auf mehrere erweitern, wenn man denn das für sinnvoll hielte - richtig?
  • cmd1 und cmd2 sind erst einmal unabhängig voneinander? Oder kommt cmd2 nur dann, wenn cmd1 ausgelöst wurde?
  • Die eigentlichen Kommandos werden unter FreeCmd definiert, richtig? Aber wieso fehlt da cmd2? Und wieso ist cmd2 nicht SchlafzimmerfensterMail?

Hi Andies,

zu 1.
ja, das ist richtig. ich wollte damit nur vermeiden , das wenn das fenster offen ist , alle 10 minuten das MSwitch nachschauen muss, wie denn nun die Temperatur ist , so wird nur dann ausgelöst , wenn auch die temperatur unter die 12 grad fällt. nur wenn das der fall ist , fällt das MSwitch in den 10 minuten tournuss, um die mail zu senden . Trifft eine von den beiden Bedingungen nicht mehr zu , findet keine weiteres intervall mehr statt.

Ausserdem ist nur so gewährleistet , das wenn das Fenster geöffnet ist und die Temperatur unter 12 grad fällt sofort benachrichtigt wird. Andernfalls könnte es passieren, das erst ( im maximalfall ) 10 minuten später benachrichtigt wird.

zu 2.
genau so ist es  ;)

ja, das kann man beliebig erweitern . cmd1 und cmd2 sindunabhängig und werden durch den jeweils definierten trigger ausgelöst.

das cmd2 triggert in diesem Fall nur auf eine statusänderung der Temperatur und startet im <12 grad fall sofort cmd1 ( dort wird dann geprüft ob beide bedingungen vorliegen , ggf. die mail gesendet und ein erneutes ausführen von cmd1 gesetzt ( wenn beide bedingungen erfüllt sind )

ist eine bedingung nicht mehr erfüllt , wird erst wieder gestartet durch definierten Trigger .

Gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: andies am 14 Juni 2018, 20:56:30
OK, ins Wiki übernommen. Noch eine Nachfrage zu dem unteren Teil im Webinterface. FreeCmd ist das eigentlich auszulösende Kommando? Aber warum steht das nur in cmd1 und nicht in cmd2?

Ich überlege auch, ob der device-help in der Datei nicht vielleicht besser einen Link auf den Wiki enthält? Soll ich das mal anpassen und Dir posten?

Noch eine Frage. Ich habe ganz viele Logeinträge:
2018.06.14 19:25:06 3: SchlafzimmerfensterMail MSwitch_Notif: Befehlsausfüehrung ->    4216
2018.06.14 19:25:06 3: SchlafzimmerfensterMail MSwitch_Restartcm: Befehlsausfuehrung ->    4222
2018.06.14 19:25:21 3: SchlafzimmerfensterMail MSwitch_Notif: Befehlsausfüehrung ->    4216
2018.06.14 19:25:21 3: SchlafzimmerfensterMail MSwitch_Restartcm: Befehlsausfuehrung ->    4222
2018.06.14 19:25:21 3: SchlafzimmerfensterMail MSwitch_Notif: Befehlsausfüehrung ->    4216
2018.06.14 19:25:21 3: SchlafzimmerfensterMail MSwitch_Restartcm: Befehlsausfuehrung ->    4222
2018.06.14 19:25:21 3: SchlafzimmerfensterMail MSwitch_Notif: Befehlsausfüehrung ->    4216
2018.06.14 19:25:21 3: SchlafzimmerfensterMail MSwitch_Restartcm: Befehlsausfuehrung ->    4222
2018.06.14 19:25:36 3: SchlafzimmerfensterMail MSwitch_Notif: Befehlsausfüehrung ->    4216
2018.06.14 19:25:36 3: SchlafzimmerfensterMail MSwitch_Restartcm: Befehlsausfuehrung ->    4222
2018.06.14 19:25:36 3: SchlafzimmerfensterMail MSwitch_Notif: Befehlsausfüehrung ->    4216
2018.06.14 19:25:36 3: SchlafzimmerfensterMail MSwitch_Restartcm: Befehlsausfuehrung ->    4222
2
Ist das normal?
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 14 Juni 2018, 22:06:03
OK, ins Wiki übernommen. Noch eine Nachfrage zu dem unteren Teil im Webinterface. FreeCmd ist das eigentlich auszulösende Kommando? Aber warum steht das nur in cmd1 und nicht in cmd2?

Ich überlege auch, ob der device-help in der Datei nicht vielleicht besser einen Link auf den Wiki enthält? Soll ich das mal anpassen und Dir posten?

Noch eine Frage. Ich habe ganz viele Logeinträge:
2018.06.14 19:25:06 3: SchlafzimmerfensterMail MSwitch_Notif: Befehlsausfüehrung ->    4216
2018.06.14 19:25:06 3: SchlafzimmerfensterMail MSwitch_Restartcm: Befehlsausfuehrung ->    4222
2018.06.14 19:25:21 3: SchlafzimmerfensterMail MSwitch_Notif: Befehlsausfüehrung ->    4216
2018.06.14 19:25:21 3: SchlafzimmerfensterMail MSwitch_Restartcm: Befehlsausfuehrung ->    4222
2018.06.14 19:25:21 3: SchlafzimmerfensterMail MSwitch_Notif: Befehlsausfüehrung ->    4216
2018.06.14 19:25:21 3: SchlafzimmerfensterMail MSwitch_Restartcm: Befehlsausfuehrung ->    4222
2018.06.14 19:25:21 3: SchlafzimmerfensterMail MSwitch_Notif: Befehlsausfüehrung ->    4216
2018.06.14 19:25:21 3: SchlafzimmerfensterMail MSwitch_Restartcm: Befehlsausfuehrung ->    4222
2018.06.14 19:25:36 3: SchlafzimmerfensterMail MSwitch_Notif: Befehlsausfüehrung ->    4216
2018.06.14 19:25:36 3: SchlafzimmerfensterMail MSwitch_Restartcm: Befehlsausfuehrung ->    4222
2018.06.14 19:25:36 3: SchlafzimmerfensterMail MSwitch_Notif: Befehlsausfüehrung ->    4216
2018.06.14 19:25:36 3: SchlafzimmerfensterMail MSwitch_Restartcm: Befehlsausfuehrung ->    4222
2
Ist das normal?


muss ich mir morgen anschauen , was es mit den logs auf sich hat . stell das verbose solange mal auf 2 oder 1, das es dir das log nicht zumüllt. ist aber nichts dramatisches.

klar, kannst du mir gerne schicken.

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: andies am 16 Juni 2018, 17:49:22
So, hier kommen mal meine ersten Gehversuche mit Hilfe. Du musst, Thomas, den Text in dem Codeblock einfach nach der 1 am (derzeitigen) Ende des Modulfiles hinzufügen. Danach erscheinen ein paar Dinge, die auch im Wiki und so stehen, unter "device specific help". Englisch schaffe ich momentan nicht, vielleicht ist einer schneller.
Ich habe den Text angepasst. Die Änderungen sind jetzt: Es stehen eher allgemeine Dinge da, es wird auf die vielen Hilfebuttons im Modul selber und vor allem auf den Wiki-Artikel verwiesen. Letzterer kann dann unabhängig vom Modul bearbeitet werden.

Ich hätte auch noch ein, zwei Tipps bei den Hilfetexten im Modul selber. Nur weiß ich nicht, wie ich das sinnvollerweise mitteilen soll. Ich meine: Wenn ich da ein falsches Anführungszeichen mache und Du fügst das ein, geht schon gar nichts mehr  :-\  Also wenn Du da eine Idee hast...


=pod
=item device
=item summary    controls several devices using a trigger device
=item summary_DE kontrolliert mehrere Geraete mit Hilfe eines Trigger-Geraetes
=begin html
=end html
=begin html_DE

<!-- ================================ -->
<a name="MSwitch"></a>
<h3>MSwitch</h3>

<ul>
<b>&Uuml;bersicht</b> <br><br>
MSwitch ist ein Hilfsmodul. Es erlaubt das gleichzeitige Schalten von mehreren devices. Weitere Abhängigkeiten und Bedingungen wie ereignisgesteuertes und/oder zeitgesteuertes Schalten einzelner devices sind einstellbar.<br>

Das define eines MSwitch Devices generiert lediglich eine 'leere H&uuml;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).

<br><br>
 
<b>Hilfe</b> <br><br>
Derzeit sind zwei Hilfemöglichkeiten implementiert. Das Attribut

<code>attr &lt;name&gt; MSwitch_Help 1 </code><br>
schaltet Hilfebuttons zu den einzelnen Eingabefeldern an oder aus. Die dort angegebenen Hilfen sind sehr umfangreich.<br>
    <br>

Alternativ findet man auf der Wiki-Seite des Moduls weitere <a href="https://wiki.fhem.de/wiki/MSwitch.pm">Hinweise</a>.
</ul>
<!-- ================================ -->
=end html_DE
=cut
[/quote]
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: andies am 16 Juni 2018, 18:11:47
@Andies

hier die Rawdefinition , wie besprochen.
Ich habe das jetzt ein wenig anders definiert, kannst Du mal drüberschauen:
#V V1.54
#S .Device_Affected -> FreeCmd-AbsCmd1
#S .Device_Affected_Details -> FreeCmd-AbsCmd1,cmd,cmd,set TelegramBot _msg Schlafzimmerfenster offen[S]{DebianMail("mail@adresse.com"##"Fenster offen!"##"der Roman"##"/opt/fhem/www/snapshots/SchlafzimmerFensterOffen.jpg")},,delay1,delay1,001200,000000,,,600,720
#S .Device_Events -> Schlafzimmerfenster:state:open|no_trigger
#S .First_init -> done
#S .Trigger_Whitelist -> Schlafzimmerfenster
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> Schlafzimmerfenster:state:open
#S .Trigger_condition -> [BresserTemeo_1.temperature]~<~12
#S .Trigger_off -> no_trigger
#S .Trigger_on -> no_trigger
#S .Trigger_time ->
#S .V_Check -> V 0.3
#S Trigger_device -> all_events
#S Trigger_log -> on
#S last_event -> state:Hum:37.20Tem:27.20
#S state -> active
#A verbose -> 1
#A MSwitch_Lock_Quickedit -> 1
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A MSwitch_Inforoom -> MSwitch
#A MSwitch_Mode -> Notify
#A MSwitch_Include_Webcmds -> 1
#A MSwitch_Expert -> 1
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Extensions -> 0
#A MSwitch_Safemode -> 1
#A room -> MSwitchtest
#A MSwitch_Include_MSwitchcmds -> 0
#A MSwitch_Delete_Delays -> 1
#A MSwitch_Help -> 1
#A MSwitch_Debug -> 0
Ich lasse nur auf offenes Fenster triggern und löse dann aus, wenn die Außentemperatur unter 12 Grad ist. Und "Repeats" ist was genau? Also was ist der Unterschied zu Repeatdelay? Oder ist das Anzahl der Repeats - was wäre dann unendlich?

Letzte Frage: Ich wollte bei Auslösung noch die Heizung runterdrehen, das füge ich einfach hinzu. Das könnte ich doch so machen, dass bei Fenster-zu die Heizung wieder hochfährt, oder?
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 16 Juni 2018, 19:02:12
Ich habe das jetzt ein wenig anders definiert, kannst Du mal drüberschauen:
#V V1.54
#S .Device_Affected -> FreeCmd-AbsCmd1
#S .Device_Affected_Details -> FreeCmd-AbsCmd1,cmd,cmd,set TelegramBot _msg Schlafzimmerfenster offen[S]{DebianMail("mail@adresse.com"##"Fenster offen!"##"der Roman"##"/opt/fhem/www/snapshots/SchlafzimmerFensterOffen.jpg")},,delay1,delay1,001200,000000,,,600,720
#S .Device_Events -> Schlafzimmerfenster:state:open|no_trigger
#S .First_init -> done
#S .Trigger_Whitelist -> Schlafzimmerfenster
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> Schlafzimmerfenster:state:open
#S .Trigger_condition -> [BresserTemeo_1.temperature]~<~12
#S .Trigger_off -> no_trigger
#S .Trigger_on -> no_trigger
#S .Trigger_time ->
#S .V_Check -> V 0.3
#S Trigger_device -> all_events
#S Trigger_log -> on
#S last_event -> state:Hum:37.20Tem:27.20
#S state -> active
#A verbose -> 1
#A MSwitch_Lock_Quickedit -> 1
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A MSwitch_Inforoom -> MSwitch
#A MSwitch_Mode -> Notify
#A MSwitch_Include_Webcmds -> 1
#A MSwitch_Expert -> 1
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Extensions -> 0
#A MSwitch_Safemode -> 1
#A room -> MSwitchtest
#A MSwitch_Include_MSwitchcmds -> 0
#A MSwitch_Delete_Delays -> 1
#A MSwitch_Help -> 1
#A MSwitch_Debug -> 0
Ich lasse nur auf offenes Fenster triggern und löse dann aus, wenn die Außentemperatur unter 12 Grad ist. Und "Repeats" ist was genau? Also was ist der Unterschied zu Repeatdelay? Oder ist das Anzahl der Repeats - was wäre dann unendlich?

Letzte Frage: Ich wollte bei Auslösung noch die Heizung runterdrehen, das füge ich einfach hinzu. Das könnte ich doch so machen, dass bei Fenster-zu die Heizung wieder hochfährt, oder?

das geht so in die hosen.
zum ersten wird nur geprüft , wenn du das fenster öffnest und es unter 12 grad ist . wenn es zu diesem zeitpunkt wärmer ist , findet keine weitere prüfung mehr statt, selbst wenn das wasser gerfiert.  ;D

und mit den reppeats hast du dir eine gemeine schleife eingebaut , die nichtmal durch den safemode erkannt wird . die wirst du nur durch einen Fhemneustart unterprechen können, wenn einmal ausgelöst . Ansonsten bekommst du 600 mal die mitteilung über bot, alle 720 sekunden

wenn du lust hast , gib mir doch mal per pm deine telenummer, dann rufe ich dich mal an - ist einfacher.

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: andies am 16 Juni 2018, 21:30:24
Ich glaube, ich habe es kapiert. Repeats ist unabhängig von der Condition. Und wenn ich ehrlich bin: Da reicht eine Nachricht, meine Frau wird sonst im Dreieck springen. Also mache ich das so:

#V V1.54
#S .Device_Affected -> FreeCmd-AbsCmd1
#S .Device_Affected_Details -> FreeCmd-AbsCmd1,cmd,cmd,{fhem("set TelegramBot _msg Schlafzimmerfenster offen")[S]DebianMail("ich@mail.de"##"Fenster offen!"##"Der Roman"##"/opt/fhem/www/snapshots/SchlafzimmerFensterOffen.jpg")},,delay1,delay1,001200,000000,,,0,0
#S .Device_Events -> SchlafzimmerfensterMail:state:active|Schlafzimmerfenster:state:set_reset|Schlafzimmerfenster:state:closed|Schlafzimmerfenster:Activity:alive|Schlafzimmerfenster:state:open|Flic:state:connected|ActionDetector:state:alive:1 dead:0 unkn:0 off:0|Mosquitto:connection:connecting|VCCU:state:WLAN_HmUART:disconnected,|Schlafzimmerfenster:contact:closed (to broadcast)|Schlafzimmerfenster:trigger_cnt:64|Schlafzimmerthermostat:Activity:alive|Flic:state:disconnected|Schlafzimmerfenster:NACK|Schlafzimmerfenster:battery:ok|no_trigger|ActionDetector:state:alive:2 dead:0 unkn:0 off:0|Schlafzimmerfenster:sabotageError:off|Schlafzimmerfenster:state:Nack|Schlafzimmerfenster:alive:yes|Schlafzimmerfenster:trigger_cnt:63|Schlafzimmerfenster:trigDst_broadcast:noConfig|Schlafzimmerfenster:trigger_cnt:62|Schlafzimmerfenster:contact:open (to broadcast)
#S .First_init -> done
#S .Trigger_Whitelist -> Schlafzimmerfenster
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> Schlafzimmerfenster:state:open
#S .Trigger_condition -> ([Schlafzimmerfenster.state]~eq~"open")~AND~([BresserTemeo_1.temperature]<12)
#S .Trigger_off -> no_trigger
#S .Trigger_on -> no_trigger
#S .Trigger_time ->
#S .V_Check -> V 0.3
#S Trigger_device -> all_events
#S Trigger_log -> on
#S last_event -> trigger_cnt:64
#S state -> active
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Lock_Quickedit -> 1
#A room -> hidden
#A MSwitch_Include_Webcmds -> 1
#A MSwitch_Mode -> Notify
#A MSwitch_Help -> 1
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A MSwitch_Inforoom -> MSwitch
#A MSwitch_Extensions -> 0
#A MSwitch_Include_MSwitchcmds -> 0
#A MSwitch_Safemode -> 1
#A MSwitch_Debug -> 0
#A MSwitch_Delete_Delays -> 1
#A MSwitch_Expert -> 1
#A verbose -> 1
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 17 Juni 2018, 06:34:32
Ich glaube, ich habe es kapiert. Repeats ist unabhängig von der Condition. Und wenn ich ehrlich bin: Da reicht eine Nachricht, meine Frau wird sonst im Dreieck springen. Also mache ich das so:

#V V1.54
#S .Device_Affected -> FreeCmd-AbsCmd1
#S .Device_Affected_Details -> FreeCmd-AbsCmd1,cmd,cmd,{fhem("set TelegramBot _msg Schlafzimmerfenster offen")[S]DebianMail("ich@mail.de"##"Fenster offen!"##"Der Roman"##"/opt/fhem/www/snapshots/SchlafzimmerFensterOffen.jpg")},,delay1,delay1,001200,000000,,,0,0
#S .Device_Events -> SchlafzimmerfensterMail:state:active|Schlafzimmerfenster:state:set_reset|Schlafzimmerfenster:state:closed|Schlafzimmerfenster:Activity:alive|Schlafzimmerfenster:state:open|Flic:state:connected|ActionDetector:state:alive:1 dead:0 unkn:0 off:0|Mosquitto:connection:connecting|VCCU:state:WLAN_HmUART:disconnected,|Schlafzimmerfenster:contact:closed (to broadcast)|Schlafzimmerfenster:trigger_cnt:64|Schlafzimmerthermostat:Activity:alive|Flic:state:disconnected|Schlafzimmerfenster:NACK|Schlafzimmerfenster:battery:ok|no_trigger|ActionDetector:state:alive:2 dead:0 unkn:0 off:0|Schlafzimmerfenster:sabotageError:off|Schlafzimmerfenster:state:Nack|Schlafzimmerfenster:alive:yes|Schlafzimmerfenster:trigger_cnt:63|Schlafzimmerfenster:trigDst_broadcast:noConfig|Schlafzimmerfenster:trigger_cnt:62|Schlafzimmerfenster:contact:open (to broadcast)
#S .First_init -> done
#S .Trigger_Whitelist -> Schlafzimmerfenster
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> Schlafzimmerfenster:state:open
#S .Trigger_condition -> ([Schlafzimmerfenster.state]~eq~"open")~AND~([BresserTemeo_1.temperature]<12)
#S .Trigger_off -> no_trigger
#S .Trigger_on -> no_trigger
#S .Trigger_time ->
#S .V_Check -> V 0.3
#S Trigger_device -> all_events
#S Trigger_log -> on
#S last_event -> trigger_cnt:64
#S state -> active
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Lock_Quickedit -> 1
#A room -> hidden
#A MSwitch_Include_Webcmds -> 1
#A MSwitch_Mode -> Notify
#A MSwitch_Help -> 1
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A MSwitch_Inforoom -> MSwitch
#A MSwitch_Extensions -> 0
#A MSwitch_Include_MSwitchcmds -> 0
#A MSwitch_Safemode -> 1
#A MSwitch_Debug -> 0
#A MSwitch_Delete_Delays -> 1
#A MSwitch_Expert -> 1
#A verbose -> 1

zumindest ist kein grundsätzlicher fehler drinnen, aber:

er löst die message nur einmal aus , in dem moment , wenn du das fenster öffnest , weil nur dann das even t'state:open' eintritt. ist in diesem moment die temperatur < 12 grad, bekommst du 12 minuten später ( delay 12 )  die nachricht, wenn dann das Fenster noch auf ist und die temp immer noch < 12 grad ist ( delay with cond-check ).

wenn das Fenster offen ist , und die temperatur dann fällt ( unter 12 Grad ) wird kein Event getriggert und du wirst nicht benachrichtigt.

grundsätzlich: wenn nur auf ein device getriggert wird, sollte das device direkt angewählt werden , und nicht über GLOBAL und dann per Whitelist gefiltert , da das Triggern auf GLOBAL deutlich systemlastiger ist .

den telegram_bot musst du nicht über freecmd ansprechen ( geht aber auch ) , er sollte in der liste der 'affected devices' direkt verfügbar sein ?!

Ich melde mich nachher bei dir.

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: andies am 17 Juni 2018, 08:44:07
Die Temperatur, die ich messe, ist die Außentemperatur - das habe ich nicht klar genug gesagt.

Liegt aber auch daran, weil ich gar nicht wüsste, wie ich dass mit der Innentemperatur machen könnte  ;)
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 17 Juni 2018, 10:18:44
Die Temperatur, die ich messe, ist die Außentemperatur - das habe ich nicht klar genug gesagt.

Liegt aber auch daran, weil ich gar nicht wüsste, wie ich dass mit der Innentemperatur machen könnte  ;)

Ah ...ok, ich ging die ganze zeit von der innentemperatur aus. Wäre aber trotzdem besser, wenn du die benachrichtigung auch dann erhäst, wenn die aussentemperatur fällt , und das Fenster bereits offen ist.
ist ja nur eine kleinigkeit, nimm einfach den temperaturfühler wieder mit als trigger auf , den rest kannst du dann ja so lassen.

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 24 Juni 2018, 12:35:49
Bin bis jetzt super begeistert mit dem Modul, Super gemacht!!!

Jetzt habe ich noch eine Sache die gerne damit machen möchte weiß aber nicht ob das geht, und wenn ja, wie ich es umsetze.

Hier mein bisheriger aufbau:

Ich habe 3 at´s die wie folgt aufgebaut sind:

Frühschicht
*13:55:00 {if ((ReadingsVal("vKalender_Schicht","t_001_summary","") eq "Frühschicht") && (ReadingsVal("vKalender_Schicht","c-today","") eq "1")) {Fahrtstrecke()}}
Spätschicht
*21:55:00 {if ((ReadingsVal("vKalender_Schicht","t_001_summary","") eq "Spätschicht") && (ReadingsVal("vKalender_Schicht","c-today","") eq "1")) {Fahrtstrecke()}}
Nachtschicht
*05:55:00 {if ((ReadingsVal("vKalender_Schicht","t_001_summary","") eq "Nachtschicht") && (ReadingsVal("vKalender_Schicht","c-today","") eq "1")) {Fahrtstrecke()}}
{Fahrtstrecke()}
sub
Fahrtstrecke()
{
my @Strecke1 = "";
my @Strecke1a = "";
my @Strecke1b = "";
my @Strecke2 = "";
my @Strecke2a ="";
my @Strecke2b ="";

@Strecke1 =  ReadingsVal("Fahrtzeit_Arbeit","duration_in_traffic","");
@Strecke2 =  ReadingsVal("Arbeit_ohne_Autobahn","duration_in_traffic","");
@Strecke1a = split(/ /,@Strecke1);
@Strecke2a = split(/ /,@Strecke2);

if (@Strecke2a[0]<@Strecke1a[0])
{
fhem("set teleBot send Alternative Strecke @Strecke2")}
else
{
fhem("set teleBot send Standard Strecke @Strecke1")}
}

Damit sende ich mir zum feierabend per Telegramm, welche Strecke die schnellere ist.

Funktioniert so, aber ich würde gerne mein System etwas aufräumen.
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 24 Juni 2018, 13:55:33
Kurz da Handy. ..

Die 3 at kannst du in jedem Fall in ein mswitch packen . ... im Grunde mit gleichem Inhalt ( mswitch Syntax halt )..


Theoretisch kannst du auch die ganze sub in das gleiche mswitch in ein freecmd packen ... muss ich aber selber probieren ob er das frisst .

Melde mich , wenn ich Zuhause bin .

Gruss Byte09

Gesendet von meinem SM-G900F mit Tapatalk

Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 24 Juni 2018, 15:09:43
@Torsten_MG

ich habe dir jetzt nur mal schnell die 3 at in ein MSwitch zusammengefasst. Ich hoffe , dass die devicenamen alle stimmen. Das ganze habe ich nicht getestet , hätte sonst nen haufen dummys anlegen müssen. probier einfach mal ob es geht . im zweiten schritt könnte man die gasamte sub dann mit in das device übernehmen.

gruss Byte09


Zitat
#V V1.61
#S .Device_Affected -> FreeCmd-AbsCmd1
#S .Device_Affected_Details -> FreeCmd-AbsCmd1,cmd,cmd,{Fahrtstrecke()},,delay1,delay1,000000,000000,([13.50-13.59]~AND~[vKalender_Schicht.t_001_summary]~eq~"Frühschicht")~OR~([21.50-21.59]~AND~[vKalender_Schicht.t_001_summary]~eq~"Spätschicht")~OR~([05.50-05.59]~AND~[vKalender_Schicht.t_001_summary]~eq~"Nachtschicht"),,0,0
#S .Device_Events -> no_trigger|state:on|state:off
#S .First_init -> done
#S .Trigger_Whitelist -> undef
#S .Trigger_cmd_off -> state:off
#S .Trigger_cmd_on -> state:on
#S .Trigger_condition -> [vKalender_Schicht.c-today"]~eq~"1"
#S .Trigger_off -> no_trigger
#S .Trigger_on -> no_trigger
#S .Trigger_time -> on~off~ononly[13:55][21:55][05:55]~offonly
#S .V_Check -> V 0.3
#S Trigger_device -> no_trigger
#S Trigger_log -> off
#S last_event -> state:off
#S state -> active
#A MSwitch_Include_Webcmds -> 0
#A MSwitch_Delete_Delays -> 1
#A room -> Test
#A MSwitch_Include_MSwitchcmds -> 0
#A MSwitch_Help -> 0
#A MSwitch_Mode -> Notify
#A MSwitch_Extensions -> 0
#A MSwitch_Lock_Quickedit -> 1
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A MSwitch_Condition_Time -> 1
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Safemode -> 1
#A MSwitch_Expert -> 0
#A MSwitch_Debug -> 0
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 24 Juni 2018, 18:41:03
Danke erstmal, bin gespannt ob´s funktioniert. Werde es morgen früh sehen, da ich gleich Nachtschicht habe.

Verstehe ich das mit dem Trigger device richtig, dass immer zu den Zeiten im execute cmd die Trigger condition abgefragt wird und wenn diese übereinstimmt, dann wird der device action ausgelöst
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 24 Juni 2018, 18:49:18
Da ist aber ein Fehler drin, siehe Foto. Da ist ein " zu viel
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 24 Juni 2018, 19:51:18
Danke erstmal, bin gespannt ob´s funktioniert. Werde es morgen früh sehen, da ich gleich Nachtschicht habe.

Verstehe ich das mit dem Trigger device richtig, dass immer zu den Zeiten im execute cmd die Trigger condition abgefragt wird und wenn diese übereinstimmt, dann wird der device action ausgelöst

ja,

zu den 3 betreffenden zeiten
Zitat
[13:55][21:55][05:55]
wird der cmdzweig 1 ausgelöst , aber nur dann, wenn [vKalender_Schicht:c-today] eq "1"
in der condition wird dann geprüft, ob, und welcher zeitraum/reading Kombination passt :
Zitat
([13:50-13:59] AND [vKalender_Schicht:t_001_summary] eq "Frühschicht") OR ...

passt der auslüsende zeitpunkt zu einer der 3 kombinationen , wird der befehl
Zitat
{Fahrtstrecke()}
ausgeführt.

aber wie gesagt, ich habe es selber nicht getestet und mit dem Fehler hast du natürlich recht , ist "copy and paste" geschuldet   ;)

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 25 Juni 2018, 06:13:08
Danke erstmal, bin gespannt ob´s funktioniert. Werde es morgen früh sehen, da ich gleich Nachtschicht habe.

Verstehe ich das mit dem Trigger device richtig, dass immer zu den Zeiten im execute cmd die Trigger condition abgefragt wird und wenn diese übereinstimmt, dann wird der device action ausgelöst

falls es bis hierhin funktioniert - etwas erweitert:

manuelle anfrage über telebot möglich , mit der Anfrage "Weg" über telegram.
schickt dir den besten weg , falls du mal abweichend der vorgegebenen zeiten fährst.

kurz langeweile gehabt  ;)
gruss Byte09

#V V1.6
#S .Device_Affected -> FreeCmd-AbsCmd1
#S .Device_Affected_Details -> FreeCmd-AbsCmd1,cmd,cmd,{Fahrtstrecke()},{Fahrtstrecke()},delay1,delay1,000000,000000,([13.50-13.59]~AND~[vKalender_Schicht.t_001_summary]~eq~"Frühschicht")~OR~([21.50-21.59]~AND~[vKalender_Schicht.t_001_summary]~eq~"Spätschicht")~OR~([05.50-05.59]),,0,0
#S .Device_Events -> msgText:Weg|no_trigger
#S .First_init -> done
#S .Trigger_Whitelist -> undef
#S .Trigger_cmd_off -> msgText:Weg
#S .Trigger_cmd_on -> no_trigger
#S .Trigger_condition -> [vKalender_Schicht.c-today]~eq~"1"
#S .Trigger_off -> no_trigger
#S .Trigger_on -> no_trigger
#S .Trigger_time -> on~off~ononly[13:55][21:55][05:55][[05:58]]~offonly
#S .V_Check -> V 0.3
#S Trigger_device -> teleBot
#S Trigger_log -> off
#S last_event -> state:off
#S state -> active
#A MSwitch_Debug -> 0
#A MSwitch_Lock_Quickedit -> 1
#A MSwitch_Mode -> Notify
#A MSwitch_Help -> 1
#A MSwitch_Expert -> 0
#A MSwitch_Condition_Time -> 1
#A MSwitch_Safemode -> 1
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A MSwitch_Extensions -> 0
#A MSwitch_Include_MSwitchcmds -> 0
#A MSwitch_Delete_Delays -> 1
#A MSwitch_Include_Webcmds -> 0
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 25 Juni 2018, 06:34:11
Guten Morgen, sieht erstmal gut aus. Um 5:55Uhr kam die Nachricht per Telegramm. Den Zusatz schau ihr mir heute Nachmittag an, gehe jetzt erstmal schlafen.

Gesendet von meinem SM-J730F mit Tapatalk

Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 25 Juni 2018, 16:26:08
falls es bis hierhin funktioniert - etwas erweitert:

manuelle anfrage über telebot möglich , mit der Anfrage "Weg" über telegram.
schickt dir den besten weg , falls du mal abweichend der vorgegebenen zeiten fährst.

kurz langeweile gehabt  ;)
gruss Byte09

Funktioniert soweit, nur bekomme ich den Text 3x zugeschickt. Kann aber auch mit dem anderen Code zusammenhängen.
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 25 Juni 2018, 16:35:48
Funktioniert soweit, nur bekomme ich den Text 3x zugeschickt. Kann aber auch mit dem anderen Code zusammenhängen.

immer, also auch bei zeitauslösung, oder wenn du ihn 'abrufst' ?

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 25 Juni 2018, 16:38:11
immer, also auch bei zeitauslösung, oder wenn du ihn 'abrufst' ?

gruss Byte09

Nur bei manuellem abruf
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 25 Juni 2018, 16:42:28
Nur bei manuellem abruf

ja, habe es gerade probiert, liegt am MSwitch ... schaue mir das gerade an
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 25 Juni 2018, 17:28:32
Nur bei manuellem abruf

ich habe das problem gefunden und spiele nachher ein update ein , in dem das behoben ist.

V1.61 neu:

-code bereinigt
-einstellung 'priority' im expertenmodus.

diese auswahl ermöglicht die reihenfolge der abarbeitung der einzelnen 'affected defices' zu beeinflussen , ohne mit delays arbeiten zu müssen . hierbei hat eins die höchste Priorität . Es steht eine Anzahl von Stufen bereit , die der Anzahl der 'affected defices entsprich't. Gleiche Einstellungen werden willkürlich abgearbeitet , das muss nicht der reihenfplge der darstellung entsprechen . ist der Expertenmodus abgeschaltet, entspricht die Reihenfolge immer der Reihenfolge der Darstellung. ( siehe anhang)

-verfeinerung in der auswahl der delays
-set MSwitch wait <sek>

bewirkt das ignorieren von events für vorgegebenen zeitraum in sekunden ( einmalig ).

- diverses

gruss Byte09

Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 25 Juni 2018, 18:11:09
Testweise die Version V1.61 erstmal im Anhang.

Da ich morgen für ein paar Tage weg fahre bin ich mir noch nicht sicher , ob ich diese Version schon in das GIT stellen möchte. Wäre cool, wenn sie trotzdem jemand testet.


Gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 25 Juni 2018, 18:13:47
Bin gerade unterwegs und gleich zur Arbeit. Werde heute nicht mehr testen können

Gesendet von meinem SM-J730F mit Tapatalk

Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 27 Juni 2018, 14:18:49
Habe es gestern runtergeladen und eingefügt. Das einzige was mir aufgefallen ist, dass ich jetzt die automatischen Telegramm-Nachricht mit der besten Strecke 2x bekomme.
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 01 Juli 2018, 09:07:04
Update auf V1.62 verfügber.

- einige kleinere Fehler behoben
- eingabemaske für FreeCmd geändert ( Zeilenumbrüche sind jetzt möglich , für eine bessere Übersichtlichkeit bei grösseren FreeCMDs

Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 01 Juli 2018, 10:22:37
Habe es gestern runtergeladen und eingefügt. Das einzige was mir aufgefallen ist, dass ich jetzt die automatischen Telegramm-Nachricht mit der besten Strecke 2x bekomme.

sorry für die späte antwort, war ein paar tage im urlaub.

kann ich so nicht nachvollziehen . ggf. ein fehler in der 1.61 . du kannst mir ja bitte mal bescheid geben , ob es mit der 1.62 immer noch ist , dann müssen wir schauen.

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 02 Juli 2018, 20:17:40
immer, also auch bei zeitauslösung, oder wenn du ihn 'abrufst' ?

gruss Byte09

Da ich seit heute Frühschicht habe, hätte die Nachricht um 13:55Uhr kommen müssen. Kam aber trotzdem schon um 5:55Uhr und jetzt mit V1.62 nur 1x und nicht 2x
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 02 Juli 2018, 20:52:09
Da ich seit heute Frühschicht habe, hätte die Nachricht um 13:55Uhr kommen müssen. Kam aber trotzdem schon um 5:55Uhr und jetzt mit V1.62 nur 1x und nicht 2x
Bist du sicher , dass deine Readings stimmen ?

Ist das mswitch config genau so , wie ich es dir gegeben habe ?

Gruss Byte09


Edit : ich baue das nachher mal mit Dummys nach

Gesendet von meinem SM-G900F mit Tapatalk
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 02 Juli 2018, 20:59:48
Hier der Code:

#V V1.62
#S .Device_Affected -> FreeCmd-AbsCmd1
#S .Device_Affected_Details -> FreeCmd-AbsCmd1,cmd,cmd,{Fahrtstrecke()},,delay1,delay1,000000,000000,([13.50-13.59]~AND~[vKalender_Schicht.t_001_summary]~eq~"Frühschicht")~OR~([21.50-21.59]~AND~[vKalender_Schicht.t_001_summary]~eq~"Spätschicht")~OR~([05.50-05.59]~AND~[vKalender_Schicht.t_001_summary]~eq~"Nachtschicht"),,0,0
#S .Device_Events -> no_trigger|state:on|state:off
#S .First_init -> done
#S .Trigger_Whitelist -> undef
#S .Trigger_cmd_off -> state:off
#S .Trigger_cmd_on -> state:on
#S .Trigger_condition -> [vKalender_Schicht.daysleft]~eq~"0"~OR~[vKalender_Schicht.daysleft]~eq~"-1"
#S .Trigger_off -> no_trigger
#S .Trigger_on -> no_trigger
#S .Trigger_time -> on~off~ononly[13:55][21:55][05:55]~offonly
#S .V_Check -> V 0.3
#S Trigger_device -> no_trigger
#S Trigger_log -> off
#S last_event -> state:off
#S state -> active
#A MSwitch_Lock_Quickedit -> 1
#A MSwitch_Extensions -> 0
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A MSwitch_Debug -> 0
#A MSwitch_Include_Webcmds -> 0
#A MSwitch_Condition_Time -> 1
#A MSwitch_Expert -> 0
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Safemode -> 1
#A MSwitch_Help -> 0
#A MSwitch_Include_MSwitchcmds -> 0
#A MSwitch_Delete_Delays -> 1
#A MSwitch_Inforoom -> MSwitch
#A room -> Draussen->Fahren
#A MSwitch_Mode -> Notify


Habe überprüft und keine Unterschiede festgestellt.

Gesendet von meinem SM-J730F mit Tapatalk

Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 02 Juli 2018, 21:02:17
Ich habe nur die Trigger conditions geändert, da der ursprüngliche Eintrag nicht bei Datumübergreifenen Terminen (Nachtschicht) funktioniert

Gesendet von meinem SM-J730F mit Tapatalk

Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 03 Juli 2018, 07:14:09
Ich habe das ganze jetzt mal mit dummys nachgestellt und kann den Fehler nicht nachvollziehen .
es wäre wichtig zu wissen , ob das reading setreading "vKalender_Schicht:t_001_summary" denn wirklich den richtigen Wert hat im Moment der Schaltzeit.

Leg doch bitte einfach mal ein zweites affected device an , wie auf dem Bild . Dieses schickt dann bei jeder schaltzeit den Inhalt des Readings , dann kann man hier zumindest ausschliessen oder eben nicht.


#V V1.62
#S .Device_Affected -> FreeCmd-AbsCmd1,teleBot-AbsCmd1
#S .Device_Affected_Details -> FreeCmd-AbsCmd1,cmd,cmd,{Fahrtstrecke()},,delay1,delay1,000000,000000,([13.50-13.59]~AND~[vKalender_Schicht.t_001_summary]~eq~"Frühschicht")~OR~([21.50-21.59]~AND~[vKalender_Schicht.t_001_summary]~eq~"Spätschicht")~OR~([05.50-05.59]~AND~[vKalender_Schicht.t_001_summary]~eq~"Nachtschicht"),,0,0,1|teleBot-AbsCmd1,_msg,no_action,[vKalender_Schicht.t_001_summary],,delay1,delay1,000000,000000,,,,,1
#S .Device_Events -> no_trigger|state:on|state:off
#S .First_init -> done
#S .Trigger_Whitelist -> undef
#S .Trigger_cmd_off -> state:off
#S .Trigger_cmd_on -> state:on
#S .Trigger_condition -> [vKalender_Schicht.daysleft]~eq~"0"~OR~[vKalender_Schicht.daysleft]~eq~"-1"
#S .Trigger_off -> no_trigger
#S .Trigger_on -> no_trigger
#S .Trigger_time -> on~off~ononly[13:55][21:55][05:55]~offonly
#S .V_Check -> V 0.3
#S Trigger_device -> no_trigger
#S Trigger_log -> off
#S last_event -> state:off
#S state -> active
#A MSwitch_Safemode -> 1
#A MSwitch_Include_MSwitchcmds -> 0
#A MSwitch_Expert -> 0
#A room -> Draussen->Fahren
#A MSwitch_Debug -> 0
#A MSwitch_Condition_Time -> 1
#A MSwitch_Lock_Quickedit -> 1
#A MSwitch_Include_Webcmds -> 0
#A MSwitch_Help -> 0
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A MSwitch_Mode -> Notify
#A MSwitch_Extensions -> 0
#A MSwitch_Inforoom -> MSwitch
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Delete_Delays -> 1


gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 03 Juli 2018, 11:35:14
Ich habe gestern Abend die Triggrtime geändert und heute morgen keine Meldung bekommen.

Vorher:[13:55][21:55][05:55]
Nahher:[05:55][13:55][21:55]

Gesendet von meinem SM-J730F mit Tapatalk

Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 03 Juli 2018, 12:43:48
Ich habe gestern Abend die Triggrtime geändert und heute morgen keine Meldung bekommen.

Vorher:[13:55][21:55][05:55]
Nahher:[05:55][13:55][21:55]

Gesendet von meinem SM-J730F mit Tapatalk

ok , muss aber an etwas anderem gelegen haben , die triggerzeiten werden gleich angelegt, egal wierum du sie eingiebst. Das kannst du sehen, wenn du auf get active_timer show klickst.


eingabe: [13:55][21:55][05:55]

Schaltzeiten (at - kommandos).
2018-07-03 13:55:00 execute 'on' commands only
2018-07-03 21:55:00 execute 'on' commands only
2018-07-04 00:00:10 neuberechnung aller Schaltzeiten


eingabe [05:55][13:55][21:55]

Schaltzeiten (at - kommandos).
2018-07-03 13:55:00 execute 'on' commands only
2018-07-03 21:55:00 execute 'on' commands only
2018-07-04 00:00:10 neuberechnung aller Schaltzeiten

die 05:55 hat er jetzt nur unterschlagen , da es sich um einen bereits vergangenen Zeitpunkt handelt.

Gruss Byte09

Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 03 Juli 2018, 16:45:52
Habe den Msitch von Post 828 angelegt. Mal schauen was passiert.

Achso, um 13:55Uhr habe ich auch keine Nachricht bekommen.


EDIT:

Habe den Fehler gefunden:

Habe [vKalender_Schicht:daysleft] statt [vKalender_Schicht:t_001_daysleft] eingegeben
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 04 Juli 2018, 19:00:12
Scheint jetzt zu funktionieren, habe um 13:55Uhr die Nachricht bekommen.

Jetzt noch eine Frage, in deinem Screenshot steht ja bei telebot MSwitch 'cmd1' hinten dran _001_summary als ich deine Config übernommen habe, ist es bei mir nicht erschienen. Siehe Foto
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 04 Juli 2018, 20:05:15
Scheint jetzt zu funktionieren, habe um 13:55Uhr die Nachricht bekommen.

Jetzt noch eine Frage, in deinem Screenshot steht ja bei telebot MSwitch 'cmd1' hinten dran _001_summary als ich deine Config übernommen habe, ist es bei mir nicht erschienen. Siehe Foto
Erstmal gut das es jetzt geht . Sitze aber gerade im Musical (pause) ... Insofern melde ich mich morgen . ;-)

Gruss Byte09

Gesendet von meinem SM-G900F mit Tapatalk

Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 04 Juli 2018, 20:05:57
Erstmal gut das es jetzt geht . Sitze aber gerade im Musical (pause) ... Insofern melde ich mich morgen . ;-)

Gruss Byte09

Gesendet von meinem SM-G900F mit Tapatalk

Kein Stress und viel Spaß
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 05 Juli 2018, 19:09:40
Scheint jetzt zu funktionieren, habe um 13:55Uhr die Nachricht bekommen.

Jetzt noch eine Frage, in deinem Screenshot steht ja bei telebot MSwitch 'cmd1' hinten dran _001_summary als ich deine Config übernommen habe, ist es bei mir nicht erschienen. Siehe Foto

das scheint mir ein problem mit dem darkstyle zu sein . die textarea-felder werden extrem weit auseinandergezogen und dadurch schiebt sich das entsprechende feld sehr weit nach rechts. schau mal , ob du die seite nach rechts scrollen kannst, dann sollte es zu dsehen sein.

ich passe das an.

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 06 Juli 2018, 08:46:01
das problem mit dem DarkStyle sollte behoben sein.

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 06 Juli 2018, 18:17:44
das problem mit dem DarkStyle sollte behoben sein.

gruss Byte09

Funktioniert!

Super!
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 06 Juli 2018, 18:56:12
Eine Frage noch.

Im device action rufe ich ja mit {Fahrtstrecke()} den Code in den 99_myUtils auf.
Du wolltest mal schauen, ob man das auch direkt in den MSwitch einbinden kann.

Hier nochmal der Code:
sub
Fahrtstrecke()
{
my @Strecke1 = "";
my @Strecke1a = "";
my @Strecke2 = "";
my @Strecke2a ="";

@Strecke1 =  ReadingsVal("Fahrtzeit_Arbeit","duration_in_traffic","");
@Strecke2 =  ReadingsVal("Abbelen_ohne_Arbeit","duration_in_traffic","");
@Strecke1a = split(/ /,@Strecke1);
@Strecke2a = split(/ /,@Strecke2);

if (@Strecke2a[0]<@Strecke1a[0])
{
fhem("set teleBot send Alternative Strecke @Strecke2")}
else
{
fhem("set teleBot send Standard Strecke @Strecke1")}
}
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 06 Juli 2018, 19:25:02
Eine Frage noch.

Im device action rufe ich ja mit {Fahrtstrecke()} den Code in den 99_myUtils auf.
Du wolltest mal schauen, ob man das auch direkt in den MSwitch einbinden kann.

Hier nochmal der Code:
sub
Fahrtstrecke()
{
my @Strecke1 = "";
my @Strecke1a = "";
my @Strecke2 = "";
my @Strecke2a ="";

@Strecke1 =  ReadingsVal("Fahrtzeit_Arbeit","duration_in_traffic","");
@Strecke2 =  ReadingsVal("Abbelen_ohne_Arbeit","duration_in_traffic","");
@Strecke1a = split(/ /,@Strecke1);
@Strecke2a = split(/ /,@Strecke2);

if (@Strecke2a[0]<@Strecke1a[0])
{
fhem("set teleBot send Alternative Strecke @Strecke2")}
else
{
fhem("set teleBot send Standard Strecke @Strecke1")}
}

es sollte gehen, wenn du den code genau so :
{
my @Strecke1 = "";
my @Strecke1a = "";
my @Strecke2 = "";
my @Strecke2a ="";
@Strecke1 =  ReadingsVal("Fahrtzeit_Arbeit","duration_in_traffic","");
@Strecke2 =  ReadingsVal("Abbelen_ohne_Arbeit","duration_in_traffic","");
@Strecke1a = split(/ /,@Strecke1);
@Strecke2a = split(/ /,@Strecke2);
if (@Strecke2a[0]<@Strecke1a[0])
{
fhem("set teleBot send Alternative Strecke @Strecke2")}
else
{
fhem("set teleBot send Standard Strecke @Strecke1")}
}

in das cmd1 eingiebst , anstatt des aufrufes der routine.

ungetestet  - bin gerade auf dem sprung . probier es einfach mal .


gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 06 Juli 2018, 19:30:06
...
in das cmd1 eingiebst , anstatt des aufrufes der routine.

ungetestet  - bin gerade auf dem sprung . probier es einfach mal .


gruss Byte09

Scheint zu funktionieren!

Super!

Also einfach den Code aus myUtils übernehmen!
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 15 Juli 2018, 20:16:31
Ich habe mir heute ein neues MSwitch gemacht und da nochmal eine Frage.

Ich habe als Trigger device meinen Bewegungsmelder genommen. Zusätzlich habe ich bei Trigger condition folgendes eingetragen: [Handy_Torsten:state] eq "absent" AND [Handy_Tanja:state] eq "absent" AND [Handy_Ben:state] eq "absent" AND [Handy_Denise:state] eq "absent". Bei trigger details habe ich bei cmd1 state:motion ausgewählt

Als affected device habe ich den teleBot ausgewählt und bei cmd1 Set msg Bewegungsmelder aktiv eingetragen.

Es funktioniert soweit alles gut. Was mir nur etwas stört ist, dass es ein paar min. dauert bis die Handy´s auf present stehen und so bekomme ich, wenn jemand nach Hause kommt (die 1. Person) sofort die Nachricht geschickt wird. Gibt es eine Möglichkeit in dem MSwitch noch einen Timer einzubinden? Etwa so, dass nachdem der Bewegungsmelder etwas registriert hat, eine Zeit gewartet wird, bis er auf Anwesenheit der Handy´s prüft und dann gegebenenfalls die Nachricht rausschickt.

Hier noch die config:
#V V1.62
#S .Device_Affected -> teleBot-AbsCmd1
#S .Device_Affected_Details -> teleBot-AbsCmd1,msg,no_action,Bewegungsmelder aktiv,,delay1,delay1,000000,000000,,,,,1
#S .Device_Events -> motion:off|motion:on (to broadcast)|state:noMotion|no_trigger|motionCount:89_next:30s|brightness:75|state:motion|motionDuration:32|trigger_cnt:89
#S .First_init -> done
#S .Trigger_Whitelist -> undef
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> state:motion
#S .Trigger_condition -> [Handy_Torsten.state]~eq~"absent"~AND~[Handy_Tanja.state]~eq~"absent"~AND~[Handy_Ben.state]~eq~"absent"~AND~[Handy_Denise.state]~eq~"absent"
#S .Trigger_off -> no_trigger
#S .Trigger_on -> no_trigger
#S .Trigger_time ->
#S .V_Check -> V 0.3
#S Trigger_device -> FL_Taster2_Motion
#S Trigger_log -> off
#S last_event -> state:motion
#S state -> active
#A room -> Sicherheit
#A MSwitch_Mode -> Notify
#A MSwitch_Delete_Delays -> 1
#A MSwitch_Inforoom -> MSwitch
#A MSwitch_Expert -> 0
#A MSwitch_Debug -> 0
#A MSwitch_Lock_Quickedit -> 1
#A MSwitch_Condition_Time -> 1
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A MSwitch_Include_Webcmds -> 0
#A MSwitch_Include_Devicecmds -> 1
#A disable -> 0
#A MSwitch_Include_MSwitchcmds -> 0
#A MSwitch_Help -> 0
#A MSwitch_Extensions -> 0
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 15 Juli 2018, 20:26:20
Ich habe mir heute ein neues MSwitch gemacht und da nochmal eine Frage.

Ich habe als Trigger device meinen Bewegungsmelder genommen. Zusätzlich habe ich bei Trigger condition folgendes eingetragen: [Handy_Torsten:state] eq "absent" AND [Handy_Tanja:state] eq "absent" AND [Handy_Ben:state] eq "absent" AND [Handy_Denise:state] eq "absent". Bei trigger details habe ich bei cmd1 state:motion ausgewählt

Als affected device habe ich den teleBot ausgewählt und bei cmd1 Set msg Bewegungsmelder aktiv eingetragen.

Es funktioniert soweit alles gut. Was mir nur etwas stört ist, dass es ein paar min. dauert bis die Handy´s auf present stehen und so bekomme ich, wenn jemand nach Hause kommt (die 1. Person) sofort die Nachricht geschickt wird. Gibt es eine Möglichkeit in dem MSwitch noch einen Timer einzubinden? Etwa so, dass nachdem der Bewegungsmelder etwas registriert hat, eine Zeit gewartet wird, bis er auf Anwesenheit der Handy´s prüft und dann gegebenenfalls die Nachricht rausschickt.

Hier noch die config:
#V V1.62
#S .Device_Affected -> teleBot-AbsCmd1
#S .Device_Affected_Details -> teleBot-AbsCmd1,msg,no_action,Bewegungsmelder aktiv,,delay1,delay1,000000,000000,,,,,1
#S .Device_Events -> motion:off|motion:on (to broadcast)|state:noMotion|no_trigger|motionCount:89_next:30s|brightness:75|state:motion|motionDuration:32|trigger_cnt:89
#S .First_init -> done
#S .Trigger_Whitelist -> undef
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> state:motion
#S .Trigger_condition -> [Handy_Torsten.state]~eq~"absent"~AND~[Handy_Tanja.state]~eq~"absent"~AND~[Handy_Ben.state]~eq~"absent"~AND~[Handy_Denise.state]~eq~"absent"
#S .Trigger_off -> no_trigger
#S .Trigger_on -> no_trigger
#S .Trigger_time ->
#S .V_Check -> V 0.3
#S Trigger_device -> FL_Taster2_Motion
#S Trigger_log -> off
#S last_event -> state:motion
#S state -> active
#A room -> Sicherheit
#A MSwitch_Mode -> Notify
#A MSwitch_Delete_Delays -> 1
#A MSwitch_Inforoom -> MSwitch
#A MSwitch_Expert -> 0
#A MSwitch_Debug -> 0
#A MSwitch_Lock_Quickedit -> 1
#A MSwitch_Condition_Time -> 1
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A MSwitch_Include_Webcmds -> 0
#A MSwitch_Include_Devicecmds -> 1
#A disable -> 0
#A MSwitch_Include_MSwitchcmds -> 0
#A MSwitch_Help -> 0
#A MSwitch_Extensions -> 0

ja , klar.

du trägst bei ''cmd1 condition:' ebenfalls folgendes ein :
[Handy_Torsten:state] eq "absent" AND [Handy_Tanja:state] eq "absent" AND [Handy_Ben:state] eq "absent" AND [Handy_Denise:state] eq "absent".

bei cmd1 (selectfeld) trägst du immidialety and delayed ein und z.b 00:01:00.
so führt er den befehl 1 minute später aus , schaut aber vorher nochmals, ob die bedingung erfüllt ist.
so sollte es eigentlich gehen  ;)

gruss Byte09


edit: die zeit ( 1min) musst du halt entsprechend anpassen , so dass es passt.
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 15 Juli 2018, 20:37:21
ok, vielen Dank. Werde ich gleich einpflegen und beim nächsten Fall merken ob´s dann klappt
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 15 Juli 2018, 20:38:06
nachtrag:

ich würde die 3 telefone aber ggf. in eine structure setzen , das erspart jede menge abfragen.


z:B ... musst du natürlich auf deine devicenamen anpassen
defmod HomeStatus structure home_structure  HandyThomas HandySandra HandyDevon HandyJay  PreseceState
attr HomeStatus clientstate_behavior relative
attr HomeStatus clientstate_priority present absent
attr HomeStatus devStateIcon present:status_available:home absent:control_building_empty:home
attr HomeStatus event-on-change-reading .*
attr HomeStatus group .Home Status
attr HomeStatus icon system_fhem
attr HomeStatus room Anwesenheit

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 15 Juli 2018, 21:04:44
ok, vielen Dank. Werde ich gleich einpflegen und beim nächsten Fall merken ob´s dann klappt

da fällt mir gerade nochwas ein !
du solltest in diesem MSwitch das attribut 'MSwitch_Delete_Delays' unbedingt auf 0 stellen.

wenn dieses nicht auf 0 steht, wird bei jedem neuen event ( innerhalb der minute wartezeit ) das MSwitch im grunde resettet und alle delays ( verzögerungen ) gelöscht und neu gesetzt. d.H bei regelmässigen bewegungen würdest du nur dann eine Nachricht bekommen , wenn es mindestens für die dauer der wartezeit keine neue bewegung gab. das ist wohl nicht sinn der sache .

ist das attribut auf 0 , wird die bereits gesetzte verzögerung nicht gelöscht und eine zusätzliche gesetzt.

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 21 Juli 2018, 16:51:39
update auf v1.66 verfügbar.

change:
-bugfix timespec regex ( führte zu Fehlermeldung bei bestimmten Schaltzeiten )
-add ATTR 'disabledForIntervals'
-fix wrong-timespec bug at at-comands (fhem-crash)
-add EVENT readings - ececute timer or at-comands

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 22 Juli 2018, 12:49:57
wer noch die Version v1.62 einsetzt sollte bitte unbedingt ein update auf V1.65 machen.
die Version V1.62 enthällt einen Fehler, der unter ganz bestimmten Umständen ( bei einsatz von zeitgesteuerten Schaltvorgängen ) zum Fhemcrash führen kann.

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 23 Juli 2018, 21:25:23
ja , klar.

...

bei cmd1 (selectfeld) trägst du immidialety and delayed ein und z.b 00:01:00.
so führt er den befehl 1 minute später aus , schaut aber vorher nochmals, ob die bedingung erfüllt ist.
so sollte es eigentlich gehen  ;)

gruss Byte09


edit: die zeit ( 1min) musst du halt entsprechend anpassen , so dass es passt.

Funktioniert leider nicht.

Ich habe als Zeit zu testzwecken 00:06:00 eingetragen.

Handy aus dem W-Lan genommen gewartet bis absent kommt. Dann das W-Lan wieder eingeschaltet. Nach ca. 3min. schaltete Homestatus auf present. Nachdem die 6min. abgelaufen sind kam trotzdem per TeleBot die Meldung "Bewegungsmelder aktiv"
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 24 Juli 2018, 05:19:23
Funktioniert leider nicht.

Ich habe als Zeit zu testzwecken 00:06:00 eingetragen.

Handy aus dem W-Lan genommen gewartet bis absent kommt. Dann das W-Lan wieder eingeschaltet. Nach ca. 3min. schaltete Homestatus auf present. Nachdem die 6min. abgelaufen sind kam trotzdem per TeleBot die Meldung "Bewegungsmelder aktiv"

ich habe das gerade nochmal bei mir probiert und es geht ohne probleme. schick mir doch bitte mal dei komplette rawdefinition oder den configfile des devices.

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 24 Juli 2018, 08:28:15
ich habe das gerade nochmal bei mir probiert und es geht ohne probleme. schick mir doch bitte mal dei komplette rawdefinition oder den configfile des devices.

gruss Byte09

Hier die config
#V V1.66
#S .Device_Affected -> teleBot-AbsCmd1
#S .Device_Affected_Details -> teleBot-AbsCmd1,msg,no_action,Bewegungsmelder aktiv,,delay1,delay1,000600,000000,,,,,1
#S .Device_Events -> motion:off|motion:on (to broadcast)|state:noMotion|no_trigger|motionCount:89_next:30s|brightness:75|state:motion|motionDuration:32|trigger_cnt:89
#S .First_init -> done
#S .Trigger_Whitelist -> undef
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> state:motion
#S .Trigger_condition -> [HomeStatus.state]~eq~"absent"
#S .Trigger_off -> no_trigger
#S .Trigger_on -> no_trigger
#S .Trigger_time ->
#S .V_Check -> V 0.3
#S Trigger_device -> FL_Taster2_Motion
#S Trigger_log -> off
#S last_event -> state:motion
#S state -> active
#A MSwitch_Debug -> 0
#A MSwitch_Mode -> Notify
#A MSwitch_Expert -> 0
#A MSwitch_Delete_Delays -> 0
#A MSwitch_Include_Webcmds -> 0
#A MSwitch_Condition_Time -> 1
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Lock_Quickedit -> 1
#A disable -> 0
#A MSwitch_Help -> 0
#A MSwitch_Inforoom -> MSwitch
#A MSwitch_Extensions -> 0
#A room -> Sicherheit
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A MSwitch_Include_MSwitchcmds -> 0
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Byte09 am 24 Juli 2018, 17:47:50
Hier die config
#V V1.66
#S .Device_Affected -> teleBot-AbsCmd1
#S .Device_Affected_Details -> teleBot-AbsCmd1,msg,no_action,Bewegungsmelder aktiv,,delay1,delay1,000600,000000,,,,,1
#S .Device_Events -> motion:off|motion:on (to broadcast)|state:noMotion|no_trigger|motionCount:89_next:30s|brightness:75|state:motion|motionDuration:32|trigger_cnt:89
#S .First_init -> done
#S .Trigger_Whitelist -> undef
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> state:motion
#S .Trigger_condition -> [HomeStatus.state]~eq~"absent"
#S .Trigger_off -> no_trigger
#S .Trigger_on -> no_trigger
#S .Trigger_time ->
#S .V_Check -> V 0.3
#S Trigger_device -> FL_Taster2_Motion
#S Trigger_log -> off
#S last_event -> state:motion
#S state -> active
#A MSwitch_Debug -> 0
#A MSwitch_Mode -> Notify
#A MSwitch_Expert -> 0
#A MSwitch_Delete_Delays -> 0
#A MSwitch_Include_Webcmds -> 0
#A MSwitch_Condition_Time -> 1
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Lock_Quickedit -> 1
#A disable -> 0
#A MSwitch_Help -> 0
#A MSwitch_Inforoom -> MSwitch
#A MSwitch_Extensions -> 0
#A room -> Sicherheit
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A MSwitch_Include_MSwitchcmds -> 0

so, ich habe mir das gerade mal angesehen . Ich glaube du hast den Eintrag den du machen solltest ( Antwort #296 ) gar nicht gemacht, zumindest findet er sich im configfile nicht wieder , wieer sein sollte -> siehe Anhang.

entsprechende zeile würde dann so aussehen :
#S .Device_Affected_Details -> teleBot-AbsCmd1,msg,no_action,Bewegungsmelder aktiv,,delay1,delay1,000600,000000,[HomeStatus.state]~eq~"absent",,,,1
ohne diesen Eintrag führt er den befehl einfach aus ( nach 6 minuten ). nur wenn dieser eintrag vorhanden ist prüft er diesen auf "wahr" oder "nicht wahr" - und zwar direkt bei eintreffen des events, und erneut nach ablaufen der 6 minuten und vor ausführung des Befehls ( bei jetziger einstellung ).

gruss Byte09
Titel: Antw:neues modul: 98_MSwitch.pm
Beitrag von: Torsten_MG am 24 Juli 2018, 21:02:01
so, ich habe mir das gerade mal angesehen . Ich glaube du hast den Eintrag den du machen solltest ( Antwort #296 ) gar nicht gemacht, zumindest findet er sich im configfile nicht wieder , wieer sein sollte -> siehe Anhang.

entsprechende zeile würde dann so aussehen :
#S .Device_Affected_Details -> teleBot-AbsCmd1,msg,no_action,Bewegungsmelder aktiv,,delay1,delay1,000600,000000,[HomeStatus.state]~eq~"absent",,,,1
ohne diesen Eintrag führt er den befehl einfach aus ( nach 6 minuten ). nur wenn dieser eintrag vorhanden ist prüft er diesen auf "wahr" oder "nicht wahr" - und zwar direkt bei eintreffen des events, und erneut nach ablaufen der 6 minuten und vor ausführung des Befehls ( bei jetziger einstellung ).

gruss Byte09

Asche auf mein Haupt. Das mit dem Eintrag in den 'cmd1' condition im device actions habe ich total übersehen ::)

Ich habe das nur in den Trigger condition stehen gehabt.

Läuft!! Super Teil!!
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 25 Juli 2018, 19:31:29
kommende version v1.67

mit der kommenden Version werde/habe  ich die Eventverarbeitung nochmals komplett überarbeitet.
d.H bei manuellen hinzufügen von zu erjkennenden Events könne zukünftig Ausdrücke nach den Regeln der PerlRegex angewendet werden. Hierdurch werden die Möglichkeiten auf ( bestimmte ) Events zu reagieren erheblich grösser.
https://wiki.fhem.de/wiki/Regul%C3%A4rer_Ausdruck (https://wiki.fhem.de/wiki/Regul%C3%A4rer_Ausdruck)

die bisherige Formatierung z.B  "state:(on/off)" bleibt erhalten , sollte dann aber nicht mehr verwendet werden.

gruss Byte09

Titel: Antw:98_MSwitch - Support
Beitrag von: Esjay am 29 Juli 2018, 14:39:45
Moin Byte09

ich würde erwarten, dass der Command zu den jeweiligen Zeiten auslöst, aber Pustekuchen. Kannst du mir den Fehler sagen?

#V V1.66
#S .Device_Affected -> Flur-AbsCmd1,ReceiverAxBox4K-AbsCmd1,TelegramBot-AbsCmd1
#S .Device_Affected_Details -> Flur-AbsCmd1,Speak,no_action,45 de Am [myAbfall.next_weekday] wird [ArtikelMuell.state] [myAbfall.next_text] abgeholt heute ist [Wochentag.state],,delay1,delay1,000000,000000,[Haus.state]~eq~"home",,,,1|ReceiverAxBox4K-AbsCmd1,showText,no_action,Am [myAbfall.next_weekday] wird [ArtikelMuell.state] [myAbfall.next_text] abgeholt heute ist [Wochentag.state],,delay1,delay1,000000,000000,[Haus.state]~eq~"home",,,,1|TelegramBot-AbsCmd1,msg,no_action,@#Home Am [myAbfall.next_weekday] wird [ArtikelMuell.state] [myAbfall.next_text] abgeholt heute ist [Wochentag.state],,delay1,delay1,000000,000000,[Haus.state]~ne~"home",,,,1
#S .Device_Events -> no_trigger
#S .First_init -> done
#S .Trigger_Whitelist -> undef
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> no_trigger
#S .Trigger_condition ->
#S .Trigger_off -> no_trigger
#S .Trigger_on -> no_trigger
#S .Trigger_time -> on[14:22|19:30|20:30|1234567]~off~ononly~offonly
#S .V_Check -> V 0.3
#S Trigger_device -> no_trigger
#S Trigger_log -> off
#S last_event -> undef
#S state -> on
#A MSwitch_Debug -> 0
#A MSwitch_Include_MSwitchcmds -> 0
#A MSwitch_Help -> 1
#A MSwitch_Lock_Quickedit -> 1
#A MSwitch_Extensions -> 0
#A MSwitch_Expert -> 0
#A room -> MSwitch,
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A MSwitch_Mode -> Full
#A MSwitch_Delete_Delays -> 1
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Include_Webcmds -> 0

Haus steht auf state--> home

Wäre es eventuell möglich im ausführenden Command sowas möglich zu machen?

set Sonos speak 45 de |Ton| Das sit ein Test
Hier wird nach dem |Ton| einfach alles abgeschnitten.

Grüße
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 29 Juli 2018, 14:57:24
Ich bin heute den ganzen tag unterwegs , schaue mir das dann heute abend an .

Gruss byte09

Gesendet von meinem SM-G900F mit Tapatalk

Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 29 Juli 2018, 18:06:35
Moin Byte09

ich würde erwarten, dass der Command zu den jeweiligen Zeiten auslöst, aber Pustekuchen. Kannst du mir den Fehler sagen?

#V V1.66
#S .Device_Affected -> Flur-AbsCmd1,ReceiverAxBox4K-AbsCmd1,TelegramBot-AbsCmd1
#S .Device_Affected_Details -> Flur-AbsCmd1,Speak,no_action,45 de Am [myAbfall.next_weekday] wird [ArtikelMuell.state] [myAbfall.next_text] abgeholt heute ist [Wochentag.state],,delay1,delay1,000000,000000,[Haus.state]~eq~"home",,,,1|ReceiverAxBox4K-AbsCmd1,showText,no_action,Am [myAbfall.next_weekday] wird [ArtikelMuell.state] [myAbfall.next_text] abgeholt heute ist [Wochentag.state],,delay1,delay1,000000,000000,[Haus.state]~eq~"home",,,,1|TelegramBot-AbsCmd1,msg,no_action,@#Home Am [myAbfall.next_weekday] wird [ArtikelMuell.state] [myAbfall.next_text] abgeholt heute ist [Wochentag.state],,delay1,delay1,000000,000000,[Haus.state]~ne~"home",,,,1
#S .Device_Events -> no_trigger
#S .First_init -> done
#S .Trigger_Whitelist -> undef
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> no_trigger
#S .Trigger_condition ->
#S .Trigger_off -> no_trigger
#S .Trigger_on -> no_trigger
#S .Trigger_time -> on[14:22|19:30|20:30|1234567]~off~ononly~offonly
#S .V_Check -> V 0.3
#S Trigger_device -> no_trigger
#S Trigger_log -> off
#S last_event -> undef
#S state -> on
#A MSwitch_Debug -> 0
#A MSwitch_Include_MSwitchcmds -> 0
#A MSwitch_Help -> 1
#A MSwitch_Lock_Quickedit -> 1
#A MSwitch_Extensions -> 0
#A MSwitch_Expert -> 0
#A room -> MSwitch,
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A MSwitch_Mode -> Full
#A MSwitch_Delete_Delays -> 1
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Include_Webcmds -> 0

Haus steht auf state--> home

Wäre es eventuell möglich im ausführenden Command sowas möglich zu machen?

set Sonos speak 45 de |Ton| Das sit ein Test
Hier wird nach dem |Ton| einfach alles abgeschnitten.

Grüße

du hast die zeiten falsch formatiert:
[14:22|19:30|20:30|1234567]
richtig muss es so heissen:
[14:22][19:30][20:30]
auszug aus dem Hilfetext:
Zitat
[17:00|1][18:30|23] würde den Trigger Montags um 17 Uhr auslösen und Dienstags,Mittwochs um 18 Uhr 30.

die angabe der tage kannst du dier sparen , wenn an allen tagen geschaltet werden soll. Wenn du tage angiebst , müssen sie für jede zeit angegeben werden.


Zitat
Wäre es eventuell möglich im ausführenden Command sowas möglich zu machen?

Code: [Auswählen]

set Sonos speak 45 de |Ton| Das sit ein Test


Hier wird nach dem |Ton| einfach alles abgeschnitten.

Grüße

... wird in der nächsten Version gehen , wahscheinlich morgen im Laufe des Tages.

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 30 Juli 2018, 12:39:55
da ich mit dem fhem-wiki nicht wirklich zurecht komme, und das Modul hier sowieso nicht mehr zum Download bereit steht ( updates wird es unter bekanntem Link weiterhin geben ) habe ich entsprechenden Wikieintrag gelöscht.

Ich werde die komplette WikiSeite überarbeiten und in absehbarer Zeit, bei Interesse, anderweitig zur Verfügung stellen.

Gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: andies am 30 Juli 2018, 12:46:54
Uups. Das ist Schade. Hast Du denn einen github-Account? Den habe ich auf die schnelle nicht gefunden. Kannst Du die bisherigen Einträge nicht da einstellen, es war doch eine Menge Arbeit und Leute wie ich nutzen lieber Wiki als das Forum, weil das so viele Einträge sind.
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 30 Juli 2018, 12:49:28
Uups. Das ist Schade. Hast Du denn einen github-Account? Den habe ich auf die schnelle nicht gefunden. Kannst Du die bisherigen Einträge nicht da einstellen, es war doch eine Menge Arbeit und Leute wie ich nutzen lieber Wiki als das Forum, weil das so viele Einträge sind.

ja, habe ich . Werde mich heute oder morgen mal damit beschäftigen und es dort einstellen.


gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 31 Juli 2018, 07:59:39
ich werde heute mittag die Version V1.67 einspielen.

Leider ist es notwendig geworden , die gesamte Datenstruktur umzustellen.
d.H nach dem Update sind keine MSwitches mehr Funktionsfähig und es werden sich folgende Einträge im Logfile finden:
2018.07.31 07:41:11 0: <Devicename> Versionskonflikt, aktion abgebrochen !  erwartet:V 0.5 vorhanden:V 0.3
Bis zu einem Fhemneustart führen keine MSwitcdevicec mehr Aktionen aus. Mit Fhemneustart werden alle Datensätze automatisch geändert und im Logfile entsprechend dokumentiert:
2018.07.31 07:49:07 0: Backupdatei vor Strukturupdate wird erzeugt: MSwitch_backup_V03.cfg. Für einen Restore muss diese in MSwitch_backup.cfg umbenannt werden.
2018.07.31 07:49:08 0: Strukturupdate V 0.5 fuer MSwitch - Lueftung_Ctrl

Vor der Umstellung der Datensätze wird ein automatisches Backup der Configfiles angelegt :
MSwitch_backup_V03.cfgDieses kann in Notfall verwendet werden , um die die Version V1.66 im Notfall wieder einzuspielen und kann gelöscht werden , wenn es keine Probleme gibt.

Mit V1.67 können in allen Conditionfeldern Bedingungen nach den Regeln der Regex geprüft werden , alte Formatierungen können weiterhin genutzt werden.

ACHTUNG: MSwitchdevices, die auf "disable" stehen , werden nicht automatisch angepasst. Dieses muss bei Bedarf manuell mit dem Befehl set <DEVICE> VUpdate manuell ausgeführt werden, entsprechender Hinweis erfolgt auf der Konfigurationsseite.
Bitte, sofern möglich, das "Disable" für das Update auf 0 setzen.

@Esjay

set Sonos speak 45 de |Ton| Das sit ein Testsollte nun innerhalb eines Freecmds möglich sein .

gruss Byte09


Titel: Antw:98_MSwitch - Support
Beitrag von: Esjay am 01 August 2018, 20:46:58
Moin moin Byte,

Danke für die Umsetzung.
Zur Info:

2018.08.01 20:39:03 1: PERL WARNING: "my" variable $test masks earlier declaration in same scope at ./FHEM/98_MSwitch.pm line 5568, <$fh> line 2030.
2018.08.01 20:39:04 1: PERL WARNING: Use of uninitialized value $test in string ne at ./FHEM/98_MSwitch.pm line 5569.

Grüße
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 01 August 2018, 21:14:25
Ups.... kümmere mich morgen um die Warnungen . Aber es geht hoffe ich ?

Gruss Byte09

Gesendet von meinem SM-G900F mit Tapatalk

Titel: Antw:98_MSwitch - Support
Beitrag von: Esjay am 01 August 2018, 21:27:01
Ja die Funktion ist soweit gegeben 👍
Titel: Antw:98_MSwitch - Support
Beitrag von: Torsten_MG am 03 August 2018, 10:49:25
Habe seit gestern erfolgreich eine Tradfri Lampe (IKEA) über zigbee2mqtt laufen. Ich schalte sie mit einem Homematic Taster. Was mir nur nicht so gefällt ist, daß ich das über freecmd lösen mußte, da wenn ich bei Deviceaction die Lampe auswähle nur no_action, remove & MSwitchtoggle zur verfügung habe. Wenn ich bei mswitchtoggle on/off eingebe, dann wird der Zustand nur bei jeder 2. Schaltung geändert.

Bei der freecmd lösung ist mir noch aufgefallen, dass die Taster on und off oben bei Device overview invertiert sind. Ich habe noch Version 1.66 (!) bei mir laufen da ich momentan nicht genug Zeit habe zu wechseln um gegbenenfalls änderungen vorzunehmen.

Hier mal die Raw von dem mswitch

defmod BD_Licht MSwitch BD_Taster1   # FreeCmd
attr BD_Licht MSwitch_Activate_MSwitchcmds 1
attr BD_Licht MSwitch_Debug 0
attr BD_Licht MSwitch_Delete_Delays 1
attr BD_Licht MSwitch_Expert 1
attr BD_Licht MSwitch_Extensions 1
attr BD_Licht MSwitch_Help 1
attr BD_Licht MSwitch_Ignore_Types notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
attr BD_Licht MSwitch_Include_Devicecmds 1
attr BD_Licht MSwitch_Include_MSwitchcmds 1
attr BD_Licht MSwitch_Include_Webcmds 1
attr BD_Licht MSwitch_Inforoom MSwitch
attr BD_Licht MSwitch_Lock_Quickedit 1
attr BD_Licht MSwitch_Mode Full
attr BD_Licht room 01_Bad
Titel: Antw:98_MSwitch - Support
Beitrag von: Torsten_MG am 03 August 2018, 11:18:43
... ( updates wird es unter bekanntem Link weiterhin geben ) habe ich entsprechenden Wikieintrag gelöscht.
...

Gruss Byte09

Welchen Link meinst du? Den hier? Tue es mir irgendie immer schwer mit den ganzen update Sachen

in der fhem befehlszeile eingeben:

update all https://raw.githubusercontent.com/Byte009/FHEM-MSwitch/master/controls_mswitch.txt
Gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 03 August 2018, 11:40:54
Spendiere der ikea mal ein webcmd on:off .  Im mswitch dann das attr Include_webcmd  auf 1 setzen , dann musst du nicht mehr über freecmd und kannst das Device direkt einstellen .

Kurz da mobil , mehr heute abend.

Gruss byte09

Gesendet von meinem SM-G900F mit Tapatalk

Titel: Antw:98_MSwitch - Support
Beitrag von: Torsten_MG am 03 August 2018, 12:21:51
Spendiere der ikea mal ein webcmd on:off .  Im mswitch dann das attr Include_webcmd  auf 1 setzen , dann musst du nicht mehr über freecmd und kannst das Device direkt einstellen .

Kurz da mobil , mehr heute abend.

Gruss byte09

Gesendet von meinem SM-G900F mit Tapatalk

Hatte ich beides schon gemacht. Ohne Erfolg. Siehe Fotos

Bin jetzt auch weg. Spätschicht.
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 03 August 2018, 12:52:39
Ok , dann schaue ich es mir auch in Ruhe heute abend an.

Gruss Byte09

Gesendet von meinem SM-G900F mit Tapatalk

Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 03 August 2018, 15:48:47
du musst das attr 'MSwitch_Include_Devicecmds' auf 0 setzen , wenn du 'MSwitch_Include_WebCmds'' auf 1 setzt.
das hatte vermutlich mal einen Hintergrund , dasss ich das so gemacht habe .... glaube ich  ..... ich weiss aber absolut nicht mehr warum  :-\  .... und ergiebt jetzt für mich auch keinen sinn mehr  ::).

ich werde das morge ändern , so dasss beide Befehlslisten gleichzeitig einbezogen werden können.

gruss Byte09

Titel: Antw:98_MSwitch - Support
Beitrag von: Torsten_MG am 03 August 2018, 16:29:07
du musst das attr 'MSwitch_Include_Devicecmds' auf 0 setzen , wenn du 'MSwitch_Include_WebCmds'' auf 1 setzt.
das hatte vermutlich mal einen Hintergrund , dasss ich das so gemacht habe .... glaube ich  ..... ich weiss aber absolut nicht mehr warum  :-\  .... und ergiebt jetzt für mich auch keinen sinn mehr  ::).

ich werde das morge ändern , so dasss beide Befehlslisten gleichzeitig einbezogen werden können.

gruss Byte09
Ok, probiere ich morgen aus

Gesendet von meinem SM-J730F mit Tapatalk

Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 03 August 2018, 17:37:45
V1.68 verfügbar

bugfix (DeviceCMD/WebCMD) MQTT  (hoffentlich  :-\)

gruss Byte09

PS: sprung von 1.66 auf 1.68 ist möglich , anpassung erfolgt automatisch ( post #314 )
Titel: Antw:98_MSwitch - Support
Beitrag von: Torsten_MG am 03 August 2018, 18:28:41
V1.68 verfügbar

bugfix (DeviceCMD/WebCMD) MQTT  (hoffentlich  :-\)

gruss Byte09

PS: sprung von 1.66 auf 1.68 ist möglich , anpassung erfolgt automatisch ( post #314 )
Update bekomme ich wie in Post #320 nachgefragt?

Gesendet von meinem SM-J730F mit Tapatalk

Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 03 August 2018, 18:41:56
Update bekomme ich wie in Post #320 nachgefragt?

Gesendet von meinem SM-J730F mit Tapatalk

ja :

update all https://raw.githubusercontent.com/Byte009/FHEM-MSwitch/master/controls_mswitch.txt
gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Torsten_MG am 04 August 2018, 21:02:56
V1.68 verfügbar

bugfix (DeviceCMD/WebCMD) MQTT  (hoffentlich  :-\)

gruss Byte09

PS: sprung von 1.66 auf 1.68 ist möglich , anpassung erfolgt automatisch ( post #314 )

ON und OFF funktionieren jetzt bei mir mit den Einstellungen

MSwitch_Include_Devicecmds 0

MSwitch_Include_Webcmds 1
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 04 August 2018, 21:18:01
Im Grunde sollte es mit v1.69 auch gehen wenn du beides auf 1 setzt ?!

Gruss Byte09
ON und OFF funktionieren jetzt bei mir mit den Einstellungen

MSwitch_Include_Devicecmds 0

MSwitch_Include_Webcmds 1


Gesendet von meinem SM-G900F mit Tapatalk

Titel: Antw:98_MSwitch - Support
Beitrag von: Torsten_MG am 05 August 2018, 08:22:01
update kommen ja schneller als ich laden kann  ;D

Wollte gerade auf v1.69 updaten und muß feststellen, ist ja schon v1.70 :o

Zurück zu meinem Problem:


ON und OFF funktionieren soweit, nur sind die vertauscht  ???

Wenn ich im Device der Lampe auf ON schalte geht die Lampe an und wenn ich auff off schalte geht sie aus. Soweit alles OK.

Wenn ich aber im Mswitch oben im Device overview auf off schalte geht die Lampe an und bei on aus.

Genauso im device action. Bei cmd1 steht off, hier geht die Lampe an und bei cmd2 steht on, hier geht die Lampe aus
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 05 August 2018, 10:31:37
update kommen ja schneller als ich laden kann  ;D


... immer mal wenn ich lust und zeit habe  ;)

ok ,ich glaube nicht das es ein fehler ist , sondern irgendwo in der config etwas nicht in ordnung .  gib mir bitte nochmal die rawdefinitionen von dem mswitch und des geschalteten devices bitte.

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Torsten_MG am 05 August 2018, 11:12:02
MSwitch:

defmod BD_Licht MSwitch BD_Taster1 # BD_Lampe
attr BD_Licht MSwitch_Activate_MSwitchcmds 1
attr BD_Licht MSwitch_Debug 0
attr BD_Licht MSwitch_Delete_Delays 1
attr BD_Licht MSwitch_Expert 1
attr BD_Licht MSwitch_Extensions 1
attr BD_Licht MSwitch_Help 1
attr BD_Licht MSwitch_Ignore_Types notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
attr BD_Licht MSwitch_Include_Devicecmds 0
attr BD_Licht MSwitch_Include_MSwitchcmds 1
attr BD_Licht MSwitch_Include_Webcmds 1
attr BD_Licht MSwitch_Inforoom MSwitch
attr BD_Licht MSwitch_Lock_Quickedit 1
attr BD_Licht MSwitch_Mode Full
attr BD_Licht MSwitchcmd 1
attr BD_Licht disable 1
attr BD_Licht room 01_Bad
attr BD_Licht verbose 0

setstate BD_Licht on
setstate BD_Licht 2018-08-03 22:05:17 .Device_Affected BD_Lampe-AbsCmd1
setstate BD_Licht 2018-08-03 22:06:30 .Device_Affected_Details BD_Lampe-AbsCmd1,off,on,,,delay1,delay1,000000,000000,,,,,1
setstate BD_Licht 2018-08-03 10:39:49 .Device_Events no_trigger|battery:ok|BD_Taster1_02 Short|BD_Taster1_01 Short|state:CMDs_done
setstate BD_Licht 2018-08-02 10:59:11 .First_init done
setstate BD_Licht 2018-08-02 11:25:21 .Trigger_cmd_off no_trigger
setstate BD_Licht 2018-08-02 11:25:21 .Trigger_cmd_on no_trigger
setstate BD_Licht 2018-08-03 21:59:18 .Trigger_condition
setstate BD_Licht 2018-08-02 11:25:21 .Trigger_off BD_Taster1_02 Short
setstate BD_Licht 2018-08-02 11:25:21 .Trigger_on BD_Taster1_01 Short
setstate BD_Licht 2018-08-03 10:33:50 .Trigger_time
setstate BD_Licht 2018-08-03 21:59:18 .V_Check V 0.4
setstate BD_Licht 2018-08-05 08:56:11 .inc_event state: CMDs_done
setstate BD_Licht 2018-08-05 08:56:11 EVENT BD_Taster1_01
setstate BD_Licht 2018-08-05 08:56:11 EVTFULL BD_Taster1:BD_Taster1_01
setstate BD_Licht 2018-08-05 08:56:11 EVTPART1 BD_Taster1
setstate BD_Licht 2018-08-05 08:56:11 EVTPART2 BD_Taster1_01
setstate BD_Licht 2018-08-05 08:56:11 Exec_cmd set BD_Lampe off
setstate BD_Licht 2018-08-05 08:13:26 Trigger_device BD_Taster1
setstate BD_Licht 2018-08-02 11:25:21 Trigger_log off
setstate BD_Licht 2018-08-05 08:56:11 last_event BD_Taster1_01
setstate BD_Licht 2018-08-05 08:56:11 state on

BD_Lampe:
defmod BD_Lampe XiaomiMQTTDevice LED1650R5 0x000b57fffed4ace8
attr BD_Lampe IODev Mosquitto
attr BD_Lampe room 01_Bad,XiaomiMQTTDevice
attr BD_Lampe stateFormat state
attr BD_Lampe verbose 5
attr BD_Lampe webCmd on:off:brightness
attr BD_Lampe widgetOverride brightness:slider,0,15,255

setstate BD_Lampe OFF
setstate BD_Lampe 2018-08-05 11:01:41 brightness 254
setstate BD_Lampe 2018-08-05 11:01:41 state OFF
setstate BD_Lampe 2018-08-05 11:01:41 transmission-state incoming publish received

Ich habe den mswitch momentan deaktiviert und 2 notifys laufen. Habe noch ein anderes Problem dass, wenn die Lampe längere Zeit nicht geschaltet wird, muß ich mehrmals den Taster drücken bis die Lampe angeht. Ich will so herausfinden ob es am mswitch oder an der Lampe selber liegt.
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 05 August 2018, 11:15:03
MSwitch:

defmod BD_Licht MSwitch BD_Taster1 # BD_Lampe
attr BD_Licht MSwitch_Activate_MSwitchcmds 1
attr BD_Licht MSwitch_Debug 0
attr BD_Licht MSwitch_Delete_Delays 1
attr BD_Licht MSwitch_Expert 1
attr BD_Licht MSwitch_Extensions 1
attr BD_Licht MSwitch_Help 1
attr BD_Licht MSwitch_Ignore_Types notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
attr BD_Licht MSwitch_Include_Devicecmds 0
attr BD_Licht MSwitch_Include_MSwitchcmds 1
attr BD_Licht MSwitch_Include_Webcmds 1
attr BD_Licht MSwitch_Inforoom MSwitch
attr BD_Licht MSwitch_Lock_Quickedit 1
attr BD_Licht MSwitch_Mode Full
attr BD_Licht MSwitchcmd 1
attr BD_Licht disable 1
attr BD_Licht room 01_Bad
attr BD_Licht verbose 0

setstate BD_Licht on
setstate BD_Licht 2018-08-03 22:05:17 .Device_Affected BD_Lampe-AbsCmd1
setstate BD_Licht 2018-08-03 22:06:30 .Device_Affected_Details BD_Lampe-AbsCmd1,off,on,,,delay1,delay1,000000,000000,,,,,1
setstate BD_Licht 2018-08-03 10:39:49 .Device_Events no_trigger|battery:ok|BD_Taster1_02 Short|BD_Taster1_01 Short|state:CMDs_done
setstate BD_Licht 2018-08-02 10:59:11 .First_init done
setstate BD_Licht 2018-08-02 11:25:21 .Trigger_cmd_off no_trigger
setstate BD_Licht 2018-08-02 11:25:21 .Trigger_cmd_on no_trigger
setstate BD_Licht 2018-08-03 21:59:18 .Trigger_condition
setstate BD_Licht 2018-08-02 11:25:21 .Trigger_off BD_Taster1_02 Short
setstate BD_Licht 2018-08-02 11:25:21 .Trigger_on BD_Taster1_01 Short
setstate BD_Licht 2018-08-03 10:33:50 .Trigger_time
setstate BD_Licht 2018-08-03 21:59:18 .V_Check V 0.4
setstate BD_Licht 2018-08-05 08:56:11 .inc_event state: CMDs_done
setstate BD_Licht 2018-08-05 08:56:11 EVENT BD_Taster1_01
setstate BD_Licht 2018-08-05 08:56:11 EVTFULL BD_Taster1:BD_Taster1_01
setstate BD_Licht 2018-08-05 08:56:11 EVTPART1 BD_Taster1
setstate BD_Licht 2018-08-05 08:56:11 EVTPART2 BD_Taster1_01
setstate BD_Licht 2018-08-05 08:56:11 Exec_cmd set BD_Lampe off
setstate BD_Licht 2018-08-05 08:13:26 Trigger_device BD_Taster1
setstate BD_Licht 2018-08-02 11:25:21 Trigger_log off
setstate BD_Licht 2018-08-05 08:56:11 last_event BD_Taster1_01
setstate BD_Licht 2018-08-05 08:56:11 state on

BD_Lampe:
defmod BD_Lampe XiaomiMQTTDevice LED1650R5 0x000b57fffed4ace8
attr BD_Lampe IODev Mosquitto
attr BD_Lampe room 01_Bad,XiaomiMQTTDevice
attr BD_Lampe stateFormat state
attr BD_Lampe verbose 5
attr BD_Lampe webCmd on:off:brightness
attr BD_Lampe widgetOverride brightness:slider,0,15,255

setstate BD_Lampe OFF
setstate BD_Lampe 2018-08-05 11:01:41 brightness 254
setstate BD_Lampe 2018-08-05 11:01:41 state OFF
setstate BD_Lampe 2018-08-05 11:01:41 transmission-state incoming publish received

Ich habe den mswitch momentan deaktiviert und 2 notifys laufen. Habe noch ein anderes Problem dass, wenn die Lampe längere Zeit nicht geschaltet wird, muß ich mehrmals den Taster drücken bis die Lampe angeht. Ich will so herausfinden ob es am mswitch oder an der Lampe selber liegt.
Schaue ich mir nachher an .

Im mswitch kannst du ja in den Readings sehen ,  ob er den Befehl abgesetzt hat.  Da gibt es ja nur schwarz oder weiß .

Gruss byte09

Gesendet von meinem SM-G900F mit Tapatalk

Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 05 August 2018, 12:00:30
habe das gerade mal bei mir entsprechend angelegt und kann das verdrehen der on/off schaltungen nicht nachvollziehen.
allerdings habe ich auch einen solchen taster nicht 'BD_Taster1_02 Short' und musste das .. in diesem fall einen cube ... ersetzen.

bei diesem trigger 'BD_Taster1_02 Short' bin ich aber der meinung , das irgendwas nicht passt. hat mswitch dieses Event so gespeichert , oder hast du es manuell angelegt ? das müsste meines erachtens so aussehen 'BD_Taster1_02:Short' . ... aber wenn es so geht ist alle ok

gruss Byte09

edit: kann es doch nachvollziehen.

du hast die cmds vertauscht. im mswitchdevice off führt immer cmd2 aus, im device auf on immer cmd1.
d.H du musst die beiden trigger einfach tauschen , und die cmds in dem affected device tauschen.
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 05 August 2018, 13:19:04
codeschnipsel:


da es mir wiederholt auf die Nerven ging, das MSwitch - wie andere hilfsmodule auch - nicht erkennt, wenn beteiligte Devices umbenannt wurden , habe ich mal ein MSwitch zusammengeklickt , was diesen Umstand behebt.

dieses Device überwacht das system auf namensänderungen und konfiguriert entsprechend alle MSwitch-devices um.

ich habe es gefühlte 100mal getestet und es gab keine Probleme, trotzdem kann ich hier nicht garantieren , das doch mal was 'übersehen' wird, insofern ist vor gravierenden änderungen ein MSwitch-Backup immer eine gute wahl.

Achtung: Das device geht nur mit V1.71 die ab sofort verfügbar ist.

Nach dem einspielen steht das device auf disabled 1 und muss erst aktiviert werden. Das device darf nicht umbenannt werden , bzw. ist in diesem fall eine anpassung im freecmd notwendig.
sinniger weise sollte dieses device nur aktiviert werden , wenn systemänderungen anstehen.

gruss Byte09

defmod Rename_Ctrl MSwitch global # FreeCmd
attr Rename_Ctrl MSwitch_Debug 0
attr Rename_Ctrl MSwitch_Delete_Delays 1
attr Rename_Ctrl MSwitch_Expert 0
attr Rename_Ctrl MSwitch_Extensions 0
attr Rename_Ctrl MSwitch_Help 0
attr Rename_Ctrl MSwitch_Ignore_Types notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
attr Rename_Ctrl MSwitch_Include_Devicecmds 0
attr Rename_Ctrl MSwitch_Include_MSwitchcmds 0
attr Rename_Ctrl MSwitch_Include_Webcmds 0
attr Rename_Ctrl MSwitch_Lock_Quickedit 1
attr Rename_Ctrl MSwitch_Mode Notify
attr Rename_Ctrl disable 1
attr Rename_Ctrl room MSwitch

setstate Rename_Ctrl active
setstate Rename_Ctrl 2018-08-05 13:43:19 .Device_Affected FreeCmd-AbsCmd1
setstate Rename_Ctrl 2018-08-05 13:45:02 .Device_Affected_Details FreeCmd-AbsCmd1,cmd,cmd,{\
my~$ev~=~ReadingsVal(~"Rename_Ctrl"#[ko]~".inc_event"#[ko]~"no_event"~);;\
my~(~$cmd~#[ko]$oldname#[ko]~$newname~)~=~split(~/~/#[ko]~$ev~);;\
foreach~my~$testdevice~(~keys~%{~$modules{MSwitch}{defptr}~}~)~\
~{\
~my~$devhash~=~$defs{$testdevice};;\
~my~$tochange1~=~ReadingsVal(~$testdevice#[ko]~".Device_Affected"#[ko]~""~);;\
~$tochange1~~~~=#[ti]~s/$oldname-/$newname-/g;;\
~readingsSingleUpdate(~$devhash#[ko]~".Device_Affected"#[ko]~$tochange1#[ko]~0~);;\
~$tochange1~=~ReadingsVal(~$testdevice#[ko]~".Device_Affected_Details"#[ko]~""~);;\
~$tochange1~=#[ti]~s/\n/[enl]/g;;\
~~~~my~$x~=~0;;\
~~~~while~(~$tochange1~=#[ti]~m/(.*[^a-zA-Z])(d1)(.*)/)\
{\
my~$firstpart~=~$1;;\
my~$secondpart~=~$2;;\
my~$lastpart~=~$3;;\
$tochange1~=~$firstpart.$newname.$lastpart;;\
$x++;;\
last~if~$x~>~10;;~\
}\
~$tochange1~=#[ti]~s/\[enl\]/\n/g;;\
~readingsSingleUpdate(~$devhash#[ko]~".Device_Affected_Details"#[ko]~$tochange1#[ko]~0~);;\
~$tochange1~=~ReadingsVal(~$testdevice#[ko]~"Trigger_device"#[ko]~""~);;\
~$tochange1~~~~=#[ti]~s/$oldname/$newname/g;;\
~readingsSingleUpdate(~$devhash#[ko]~"Trigger_device"#[ko]~$tochange1#[ko]~0~);;\
~MSwitch_LoadHelper($devhash);;\
~}\
}\
\
,,delay1,delay1,000000,000000,,,,,1
setstate Rename_Ctrl 2018-08-05 12:55:26 .Device_Events RENAMED.*|no_trigger
setstate Rename_Ctrl 2018-08-05 12:31:55 .First_init done
setstate Rename_Ctrl 2018-08-05 12:31:55 .Trigger_cmd_off no_trigger
setstate Rename_Ctrl 2018-08-05 12:31:55 .Trigger_cmd_on RENAMED.*
setstate Rename_Ctrl 2018-08-05 12:31:55 .Trigger_condition [$EVENT]#[sp]=#[ti]#[sp]m/RENAMED(#[pt]*)/
setstate Rename_Ctrl 2018-08-05 12:31:55 .Trigger_off no_trigger
setstate Rename_Ctrl 2018-08-05 12:31:55 .Trigger_on no_trigger
setstate Rename_Ctrl 2018-08-04 16:13:04 .Trigger_time
setstate Rename_Ctrl 2018-08-05 12:31:55 .V_Check V 0.4
setstate Rename_Ctrl 2018-08-05 13:43:17 .inc_event RENAMED d2 d10
setstate Rename_Ctrl 2018-08-05 13:43:17 EVENT RENAMED d2 d10
setstate Rename_Ctrl 2018-08-05 13:43:17 EVTFULL global:RENAMED d2 d10
setstate Rename_Ctrl 2018-08-05 13:43:17 EVTPART1 global
setstate Rename_Ctrl 2018-08-05 13:43:17 EVTPART2 RENAMED d2 d10
setstate Rename_Ctrl 2018-08-05 13:43:19 Exec_cmd   {my $ev = ReadingsVal( "Rename_Ctrl", ".inc_event", "no_event" );;my ( $cmd ,$oldname, $newname ) =....
setstate Rename_Ctrl 2018-08-05 13:43:19 Trigger_device global
setstate Rename_Ctrl 2018-08-05 12:31:55 Trigger_log off
setstate Rename_Ctrl 2018-08-05 13:43:17 last_event RENAMED d2 d10
setstate Rename_Ctrl 2018-08-05 13:45:18 state active


Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 09 August 2018, 17:11:32
im obigen device (rename_ctrl) ist das freecdm leider fehlerhaft und sollte durch das folgende ersetzt werden:

{
my $ev = ReadingsVal( "Rename_Ctrl", ".inc_event", "no_event" );
my ( $cmd ,$oldname, $newname ) = split( / /, $ev );
foreach my $testdevice ( keys %{ $modules{MSwitch}{defptr} } )
 {
 my $devhash = $defs{$testdevice};
 my $tochange1 = ReadingsVal( $testdevice, ".Device_Affected", "" );
 $tochange1    =~ s/$oldname-/$newname-/g;
 readingsSingleUpdate( $devhash, ".Device_Affected", $tochange1, 0 );
 $tochange1 = ReadingsVal( $testdevice, ".Device_Affected_Details", "" );
 $tochange1 =~ s/\n/[enl]/g;
 $tochange1 = "[sta]".$tochange1;
    my $x = 0;
    while ( $tochange1 =~ m/(.*?[^a-zA-Z0-9])($oldname)([^a-zA-Z0-9].*)/)
{
my $firstpart = $1;
my $secondpart = $2;
my $lastpart = $3;
$tochange1 = $firstpart.$newname.$lastpart;
$x++;
last if $x > 10;
}
 $tochange1 =~ s/\[enl\]/\\n/g;
 $tochange1 =~ s/\[sta\]//g;
 readingsSingleUpdate( $devhash, ".Device_Affected_Details", $tochange1, 0 );
 $tochange1 = ReadingsVal( $testdevice, "Trigger_device", "" );
 $tochange1    =~ s/$oldname/$newname/g;
 readingsSingleUpdate( $devhash, "Trigger_device", $tochange1, 0 );
 MSwitch_LoadHelper($devhash);
 }
}

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Torsten_MG am 09 August 2018, 20:27:36
Ich brauche nochmal hilfe beim erstellen eines MSwitch.

Ich möchte, wenn in dem Dummy Reset das reading Reset_on_off auf on gesetzt wird im freecmd folgende Befehle abgesetzt werden:

set Od_Gymn update
setreading Reset Reset_on_off off

Was muß ich alles einstellen?
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 09 August 2018, 20:42:02
Ich brauche nochmal hilfe beim erstellen eines MSwitch.

Ich möchte, wenn in dem Dummy Reset das reading Reset_on_off auf on gesetzt wird im freecmd folgende Befehle abgesetzt werden:

set Od_Gymn update
setreading Reset Reset_on_off off

Was muß ich alles einstellen?

schnell zusammengeklickt , sollte aber gehen. Configfile in ein leeres MSwitchDevice ( V1.71 ) einspielen.

gruss Byte09

#V V1.71
#S .Device_Affected -> FreeCmd-AbsCmd1
#S .Device_Affected_Details -> FreeCmd-AbsCmd1,cmd,cmd,set~Od_Gymn~update[se][cnl]setreading~Reset~Reset_on_off~off[se],,delay1,delay1,000000,000000,,,,,1
#S .Device_Events -> Reset_on_off:on|no_trigger|Reset_on_off:off
#S .First_init -> done
#S .Trigger_Whitelist -> undef
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> Reset_on_off:on
#S .Trigger_condition ->
#S .Trigger_off -> no_trigger
#S .Trigger_on -> no_trigger
#S .Trigger_time ->
#S .V_Check -> V 0.4
#S Trigger_device -> Reset
#S Trigger_log -> on
#S last_event -> Reset_on_off:on
#S state -> active
#A MSwitch_Extensions -> 0
#A MSwitch_Help -> 0
#A MSwitch_Debug -> 0
#A MSwitch_Delete_Delays -> 1
#A MSwitch_Include_MSwitchcmds -> 0
#A MSwitch_Expert -> 0
#A MSwitch_Include_Webcmds -> 0
#A MSwitch_Lock_Quickedit -> 1
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Mode -> Notify
Titel: Antw:98_MSwitch - Support
Beitrag von: Torsten_MG am 09 August 2018, 21:10:57
Danke, probiere ich morgen Nachmittag aus, bin jetzt auf der Arbeit (Nachtschicht)

Gesendet von meinem SM-J730F mit Tapatalk

Titel: Antw:98_MSwitch - Support
Beitrag von: Torsten_MG am 10 August 2018, 14:22:25
schnell zusammengeklickt , sollte aber gehen. Configfile in ein leeres MSwitchDevice ( V1.71 ) einspielen.

gruss Byte09

Super funktioniert!!

Nun habe ich noch eine Bitte, da ich es irgendwie nicht hinbekomme.

5 sek. nachdem die Befehle aus cmd1 abgesetzt wurden,

soll folgender Code aufgerufen werden:

{
my $richtung = "";
my $uhrzeit = "";
my $min = "";
my $linie = "";
my $i = 0;
my $j = 0;
my $k = 0;
{fhem("deletereading richtung_od Bus.*")};
{fhem("deletereading richtung_ry Bus.*")};
do
{
$richtung =  ReadingsVal("Od_Gymn","departure_" . $i . "_text","<undef>");
$uhrzeit =  ReadingsVal("Od_Gymn","departure_" . $i . "_time_human_readable","<undef>");
$linie =  ReadingsVal("Od_Gymn","departure_" . $i . "_number","<undef>");
$min = ReadingsVal("Od_Gymn","departure_" . $i . "_timeInMinutes","<undef>");
{fhem("setreading richtung_od Marker 0")};
{fhem("setreading richtung_ry Marker 0")};
if ($richtung ne "<undef>")
{
if($richtung eq "Mön. Clemens-August-Str." || $richtung eq "Mönchengl Nievelsteinstr." || $richtung eq "MG Rheydt Hbf" || $richtung eq "Mönchengl. Rostocker Straße" || $richtung eq "Mönchengladb. Wickrath Markt" || $richtung eq "MG Regiopark 3")
{fhem("setreading richtung_od Bus$j $richtung");
fhem("setreading richtung_od Bus_zeit$j $uhrzeit");
fhem("setreading richtung_od Bus_linie$j $linie");
fhem("setreading richtung_od Bus_min$j $min");
fhem("setreading richtung_od Marker 1")}
if(ReadingsVal("richtung_od","Marker","") ne "1")
{$j--}
if($richtung eq "Mönchengl. Künkelstraße" || $richtung eq "Mönchengladbach Marienplatz" || $richtung eq "MG Hbf /Europaplatz" || $richtung eq "Mönchengl. Am Hommelsbach" || $richtung eq "Mönchengl. Künkelstraße")
{fhem("setreading richtung_ry Bus$k $richtung");
fhem("setreading richtung_ry Bus_zeit$k $uhrzeit");
fhem("setreading richtung_ry Bus_linie$k $linie");
fhem("setreading richtung_ry Bus_min$k $min");
fhem("setreading richtung_ry Marker 1")}
if(ReadingsVal("richtung_ry","Marker","") ne "1")
{$k--}
}
$i++;
$j++;
$k++;
}while($richtung ne "<undef>")
}

Habe das jetzt erstmal ohne Zeitverzögerung in den MSwitch 'cmd2 eingetragen, aber irgendwie funktioniert es nicht.

#V V1.71
#S .Device_Affected -> FreeCmd-AbsCmd1
#S .Device_Affected_Details -> FreeCmd-AbsCmd1,cmd,cmd,set~Od_Gymn~update[se][cnl]setreading~Reset~Reset_on_off~off[se],{[cnl]my~$richtung~=~""[se][cnl]my~$uhrzeit~=~""[se][cnl]my~$min~=~""[se][cnl]my~$linie~=~""[se][cnl]my~$i~=~0[se][cnl]my~$j~=~0[se][cnl]my~$k~=~0[se][cnl]{fhem("deletereading~richtung_od~Bus.*")}[se][cnl]{fhem("deletereading~richtung_ry~Bus.*")}[se][cnl]do[cnl]{[cnl]$richtung~=~~ReadingsVal("Od_Gymn"#[ko]"departure_"~.~$i~.~"_text"#[ko]"<undef>")[se][cnl]$uhrzeit~=~~ReadingsVal("Od_Gymn"#[ko]"departure_"~.~$i~.~"_time_human_readable"#[ko]"<undef>")[se][cnl]$linie~=~~ReadingsVal("Od_Gymn"#[ko]"departure_"~.~$i~.~"_number"#[ko]"<undef>")[se][cnl]$min~=~ReadingsVal("Od_Gymn"#[ko]"departure_"~.~$i~.~"_timeInMinutes"#[ko]"<undef>")[se][cnl]{fhem("setreading~richtung_od~Marker~0")}[se][cnl]{fhem("setreading~richtung_ry~Marker~0")}[se][cnl]if~($richtung~ne~"<undef>")[cnl]{[cnl]if($richtung~eq~"Mön.~Clemens-August-Str."~#[wa]#[wa]~$richtung~eq~"Mönchengl~Nievelsteinstr."~#[wa]#[wa]~$richtung~eq~"MG~Rheydt~Hbf"~#[wa]#[wa]~$richtung~eq~"Mönchengl.~Rostocker~Straße"~#[wa]#[wa]~$richtung~eq~"Mönchengladb.~Wickrath~Markt"~#[wa]#[wa]~$richtung~eq~"MG~Regiopark~3")[cnl]{fhem("setreading~richtung_od~Bus$j~$richtung")[se][cnl]fhem("setreading~richtung_od~Bus_zeit$j~$uhrzeit")[se][cnl]fhem("setreading~richtung_od~Bus_linie$j~$linie")[se][cnl]fhem("setreading~richtung_od~Bus_min$j~$min")[se][cnl]fhem("setreading~richtung_od~Marker~1")}[cnl]if(ReadingsVal("richtung_od"#[ko]"Marker"#[ko]"")~ne~"1")[cnl]{$j--}[cnl]if($richtung~eq~"Mönchengl.~Künkelstraße"~#[wa]#[wa]~$richtung~eq~"Mönchengladbach~Marienplatz"~#[wa]#[wa]~$richtung~eq~"MG~Hbf~/Europaplatz"~#[wa]#[wa]~$richtung~eq~"Mönchengl.~Am~Hommelsbach"~#[wa]#[wa]~$richtung~eq~"Mönchengl.~Künkelstraße")[cnl]{fhem("setreading~richtung_ry~Bus$k~$richtung")[se][cnl]fhem("setreading~richtung_ry~Bus_zeit$k~$uhrzeit")[se][cnl]fhem("setreading~richtung_ry~Bus_linie$k~$linie")[se][cnl]fhem("setreading~richtung_ry~Bus_min$k~$min")[se][cnl]fhem("setreading~richtung_ry~Marker~1")}[cnl]if(ReadingsVal("richtung_ry"#[ko]"Marker"#[ko]"")~ne~"1")[cnl]{$k--}[cnl]}[cnl]$i++[se][cnl]$j++[se][cnl]$k++[se][cnl]}while($richtung~ne~"<undef>")[cnl]},delay1,delay1,000000,000000,,,,,1
#S .Device_Events -> Reset_on_off:on|no_trigger
#S .First_init -> done
#S .Trigger_Whitelist -> undef
#S .Trigger_cmd_off -> Reset_on_off:on
#S .Trigger_cmd_on -> Reset_on_off:on
#S .Trigger_condition -> [Reset#[dp]Reset_on_off]#[sp]eq#[sp]"on"
#S .Trigger_off -> no_trigger
#S .Trigger_on -> no_trigger
#S .Trigger_time ->
#S .V_Check -> V 0.4
#S Trigger_device -> Reset
#S Trigger_log -> on
#S last_event -> Reset_on_off:on
#S state -> active
#A MSwitch_Include_Webcmds -> 0
#A room -> Draussen->BUS
#A MSwitch_Mode -> Notify
#A MSwitch_Lock_Quickedit -> 1
#A MSwitch_Include_MSwitchcmds -> 0
#A MSwitch_Extensions -> 0
#A MSwitch_Expert -> 0
#A MSwitch_Debug -> 0
#A MSwitch_Condition_Time -> 1
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A MSwitch_Help -> 0
#A MSwitch_Safemode -> 1
#A MSwitch_Inforoom -> MSwitch
#A MSwitch_Delete_Delays -> 1
#A MSwitch_Include_Devicecmds -> 1

Wenn ich den code über {Fahrplan()} aus myUtils aufrufe, funktioniert der direkte Aufruf.
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 10 August 2018, 16:03:37
Super funktioniert!!

Nun habe ich noch eine Bitte, da ich es irgendwie nicht hinbekomme.

5 sek. nachdem die Befehle aus cmd1 abgesetzt wurden,

soll folgender Code aufgerufen werden:

{
my $richtung = "";
my $uhrzeit = "";
my $min = "";
my $linie = "";
my $i = 0;
my $j = 0;
my $k = 0;
{fhem("deletereading richtung_od Bus.*")};
{fhem("deletereading richtung_ry Bus.*")};
do
{
$richtung =  ReadingsVal("Od_Gymn","departure_" . $i . "_text","<undef>");
$uhrzeit =  ReadingsVal("Od_Gymn","departure_" . $i . "_time_human_readable","<undef>");
$linie =  ReadingsVal("Od_Gymn","departure_" . $i . "_number","<undef>");
$min = ReadingsVal("Od_Gymn","departure_" . $i . "_timeInMinutes","<undef>");
{fhem("setreading richtung_od Marker 0")};
{fhem("setreading richtung_ry Marker 0")};
if ($richtung ne "<undef>")
{
if($richtung eq "Mön. Clemens-August-Str." || $richtung eq "Mönchengl Nievelsteinstr." || $richtung eq "MG Rheydt Hbf" || $richtung eq "Mönchengl. Rostocker Straße" || $richtung eq "Mönchengladb. Wickrath Markt" || $richtung eq "MG Regiopark 3")
{fhem("setreading richtung_od Bus$j $richtung");
fhem("setreading richtung_od Bus_zeit$j $uhrzeit");
fhem("setreading richtung_od Bus_linie$j $linie");
fhem("setreading richtung_od Bus_min$j $min");
fhem("setreading richtung_od Marker 1")}
if(ReadingsVal("richtung_od","Marker","") ne "1")
{$j--}
if($richtung eq "Mönchengl. Künkelstraße" || $richtung eq "Mönchengladbach Marienplatz" || $richtung eq "MG Hbf /Europaplatz" || $richtung eq "Mönchengl. Am Hommelsbach" || $richtung eq "Mönchengl. Künkelstraße")
{fhem("setreading richtung_ry Bus$k $richtung");
fhem("setreading richtung_ry Bus_zeit$k $uhrzeit");
fhem("setreading richtung_ry Bus_linie$k $linie");
fhem("setreading richtung_ry Bus_min$k $min");
fhem("setreading richtung_ry Marker 1")}
if(ReadingsVal("richtung_ry","Marker","") ne "1")
{$k--}
}
$i++;
$j++;
$k++;
}while($richtung ne "<undef>")
}

Habe das jetzt erstmal ohne Zeitverzögerung in den MSwitch 'cmd2 eingetragen, aber irgendwie funktioniert es nicht.

#V V1.71
#S .Device_Affected -> FreeCmd-AbsCmd1
#S .Device_Affected_Details -> FreeCmd-AbsCmd1,cmd,cmd,set~Od_Gymn~update[se][cnl]setreading~Reset~Reset_on_off~off[se],{[cnl]my~$richtung~=~""[se][cnl]my~$uhrzeit~=~""[se][cnl]my~$min~=~""[se][cnl]my~$linie~=~""[se][cnl]my~$i~=~0[se][cnl]my~$j~=~0[se][cnl]my~$k~=~0[se][cnl]{fhem("deletereading~richtung_od~Bus.*")}[se][cnl]{fhem("deletereading~richtung_ry~Bus.*")}[se][cnl]do[cnl]{[cnl]$richtung~=~~ReadingsVal("Od_Gymn"#[ko]"departure_"~.~$i~.~"_text"#[ko]"<undef>")[se][cnl]$uhrzeit~=~~ReadingsVal("Od_Gymn"#[ko]"departure_"~.~$i~.~"_time_human_readable"#[ko]"<undef>")[se][cnl]$linie~=~~ReadingsVal("Od_Gymn"#[ko]"departure_"~.~$i~.~"_number"#[ko]"<undef>")[se][cnl]$min~=~ReadingsVal("Od_Gymn"#[ko]"departure_"~.~$i~.~"_timeInMinutes"#[ko]"<undef>")[se][cnl]{fhem("setreading~richtung_od~Marker~0")}[se][cnl]{fhem("setreading~richtung_ry~Marker~0")}[se][cnl]if~($richtung~ne~"<undef>")[cnl]{[cnl]if($richtung~eq~"Mön.~Clemens-August-Str."~#[wa]#[wa]~$richtung~eq~"Mönchengl~Nievelsteinstr."~#[wa]#[wa]~$richtung~eq~"MG~Rheydt~Hbf"~#[wa]#[wa]~$richtung~eq~"Mönchengl.~Rostocker~Straße"~#[wa]#[wa]~$richtung~eq~"Mönchengladb.~Wickrath~Markt"~#[wa]#[wa]~$richtung~eq~"MG~Regiopark~3")[cnl]{fhem("setreading~richtung_od~Bus$j~$richtung")[se][cnl]fhem("setreading~richtung_od~Bus_zeit$j~$uhrzeit")[se][cnl]fhem("setreading~richtung_od~Bus_linie$j~$linie")[se][cnl]fhem("setreading~richtung_od~Bus_min$j~$min")[se][cnl]fhem("setreading~richtung_od~Marker~1")}[cnl]if(ReadingsVal("richtung_od"#[ko]"Marker"#[ko]"")~ne~"1")[cnl]{$j--}[cnl]if($richtung~eq~"Mönchengl.~Künkelstraße"~#[wa]#[wa]~$richtung~eq~"Mönchengladbach~Marienplatz"~#[wa]#[wa]~$richtung~eq~"MG~Hbf~/Europaplatz"~#[wa]#[wa]~$richtung~eq~"Mönchengl.~Am~Hommelsbach"~#[wa]#[wa]~$richtung~eq~"Mönchengl.~Künkelstraße")[cnl]{fhem("setreading~richtung_ry~Bus$k~$richtung")[se][cnl]fhem("setreading~richtung_ry~Bus_zeit$k~$uhrzeit")[se][cnl]fhem("setreading~richtung_ry~Bus_linie$k~$linie")[se][cnl]fhem("setreading~richtung_ry~Bus_min$k~$min")[se][cnl]fhem("setreading~richtung_ry~Marker~1")}[cnl]if(ReadingsVal("richtung_ry"#[ko]"Marker"#[ko]"")~ne~"1")[cnl]{$k--}[cnl]}[cnl]$i++[se][cnl]$j++[se][cnl]$k++[se][cnl]}while($richtung~ne~"<undef>")[cnl]},delay1,delay1,000000,000000,,,,,1
#S .Device_Events -> Reset_on_off:on|no_trigger
#S .First_init -> done
#S .Trigger_Whitelist -> undef
#S .Trigger_cmd_off -> Reset_on_off:on
#S .Trigger_cmd_on -> Reset_on_off:on
#S .Trigger_condition -> [Reset#[dp]Reset_on_off]#[sp]eq#[sp]"on"
#S .Trigger_off -> no_trigger
#S .Trigger_on -> no_trigger
#S .Trigger_time ->
#S .V_Check -> V 0.4
#S Trigger_device -> Reset
#S Trigger_log -> on
#S last_event -> Reset_on_off:on
#S state -> active
#A MSwitch_Include_Webcmds -> 0
#A room -> Draussen->BUS
#A MSwitch_Mode -> Notify
#A MSwitch_Lock_Quickedit -> 1
#A MSwitch_Include_MSwitchcmds -> 0
#A MSwitch_Extensions -> 0
#A MSwitch_Expert -> 0
#A MSwitch_Debug -> 0
#A MSwitch_Condition_Time -> 1
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A MSwitch_Help -> 0
#A MSwitch_Safemode -> 1
#A MSwitch_Inforoom -> MSwitch
#A MSwitch_Delete_Delays -> 1
#A MSwitch_Include_Devicecmds -> 1

Wenn ich den code über {Fahrplan()} aus myUtils aufrufe, funktioniert der direkte Aufruf.

schaue mir das gerne an , dafür musst du mir aber bitte die jeweilige rawdefinition aller beteiligten dummys aus dem code mal einstellen, sonst muss ich die alle nachbauen.

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Torsten_MG am 10 August 2018, 16:15:27
Departure:
defmod Od_Gymn Departure 6000000
attr Od_Gymn departure_departure 20023031
attr Od_Gymn departure_max_readings 20
attr Od_Gymn departure_provider Vrr
attr Od_Gymn disable 0
attr Od_Gymn room Draussen->BUS

setstate Od_Gymn active
setstate Od_Gymn 2018-08-10 14:44:19 departure_0_delay 2
setstate Od_Gymn 2018-08-10 14:44:19 departure_0_number 002
setstate Od_Gymn 2018-08-10 14:44:19 departure_0_text MG Regiopark 3
setstate Od_Gymn 2018-08-10 14:44:19 departure_0_time 2018-08-10T14:46+0200
setstate Od_Gymn 2018-08-10 14:44:19 departure_0_timeInMinutes 2
setstate Od_Gymn 2018-08-10 14:44:19 departure_0_time_human_readable 10.08.2018, 14:46 Uhr
setstate Od_Gymn 2018-08-10 14:44:19 departure_10_delay 0
setstate Od_Gymn 2018-08-10 14:44:19 departure_10_number 002
setstate Od_Gymn 2018-08-10 14:44:19 departure_10_text Mönchengl. Am Hommelsbach
setstate Od_Gymn 2018-08-10 14:44:19 departure_10_time 2018-08-10T15:26+0200
setstate Od_Gymn 2018-08-10 14:44:19 departure_10_timeInMinutes 42
setstate Od_Gymn 2018-08-10 14:44:19 departure_10_time_human_readable 10.08.2018, 15:26 Uhr
setstate Od_Gymn 2018-08-10 14:44:19 departure_11_delay 0
setstate Od_Gymn 2018-08-10 14:44:19 departure_11_number 001
setstate Od_Gymn 2018-08-10 14:44:19 departure_11_text Mön. Clemens-August-Str.
setstate Od_Gymn 2018-08-10 14:44:19 departure_11_time 2018-08-10T15:36+0200
setstate Od_Gymn 2018-08-10 14:44:19 departure_11_timeInMinutes 52
setstate Od_Gymn 2018-08-10 14:44:19 departure_11_time_human_readable 10.08.2018, 15:36 Uhr
setstate Od_Gymn 2018-08-10 14:44:19 departure_12_delay 0
setstate Od_Gymn 2018-08-10 14:44:19 departure_12_number 001
setstate Od_Gymn 2018-08-10 14:44:19 departure_12_text Mönchengl. Künkelstraße
setstate Od_Gymn 2018-08-10 14:44:19 departure_12_time 2018-08-10T15:38+0200
setstate Od_Gymn 2018-08-10 14:44:19 departure_12_timeInMinutes 54
setstate Od_Gymn 2018-08-10 14:44:19 departure_12_time_human_readable 10.08.2018, 15:38 Uhr
setstate Od_Gymn 2018-08-10 14:44:19 departure_13_delay 0
setstate Od_Gymn 2018-08-10 14:44:19 departure_13_number 002
setstate Od_Gymn 2018-08-10 14:44:19 departure_13_text Mönchengl. Rostocker Straße
setstate Od_Gymn 2018-08-10 14:44:19 departure_13_time 2018-08-10T15:44+0200
setstate Od_Gymn 2018-08-10 14:44:19 departure_13_timeInMinutes 60
setstate Od_Gymn 2018-08-10 14:44:19 departure_13_time_human_readable 10.08.2018, 15:44 Uhr
setstate Od_Gymn 2018-08-10 14:44:19 departure_14_delay 0
setstate Od_Gymn 2018-08-10 14:44:19 departure_14_number 002
setstate Od_Gymn 2018-08-10 14:44:19 departure_14_text Mönchengl. Am Hommelsbach
setstate Od_Gymn 2018-08-10 14:44:19 departure_14_time 2018-08-10T15:46+0200
setstate Od_Gymn 2018-08-10 14:44:19 departure_14_timeInMinutes 62
setstate Od_Gymn 2018-08-10 14:44:19 departure_14_time_human_readable 10.08.2018, 15:46 Uhr
setstate Od_Gymn 2018-08-10 14:44:19 departure_15_delay 0
setstate Od_Gymn 2018-08-10 14:44:19 departure_15_number 001
setstate Od_Gymn 2018-08-10 14:44:19 departure_15_text Mön. Clemens-August-Str.
setstate Od_Gymn 2018-08-10 14:44:19 departure_15_time 2018-08-10T15:56+0200
setstate Od_Gymn 2018-08-10 14:44:19 departure_15_timeInMinutes 72
setstate Od_Gymn 2018-08-10 14:44:19 departure_15_time_human_readable 10.08.2018, 15:56 Uhr
setstate Od_Gymn 2018-08-10 14:44:19 departure_16_delay 0
setstate Od_Gymn 2018-08-10 14:44:19 departure_16_number 001
setstate Od_Gymn 2018-08-10 14:44:19 departure_16_text Mönchengl. Künkelstraße
setstate Od_Gymn 2018-08-10 14:44:19 departure_16_time 2018-08-10T15:58+0200
setstate Od_Gymn 2018-08-10 14:44:19 departure_16_timeInMinutes 74
setstate Od_Gymn 2018-08-10 14:44:19 departure_16_time_human_readable 10.08.2018, 15:58 Uhr
setstate Od_Gymn 2018-08-10 14:44:19 departure_17_delay 0
setstate Od_Gymn 2018-08-10 14:44:19 departure_17_number 002
setstate Od_Gymn 2018-08-10 14:44:19 departure_17_text Mönchengl. Rostocker Straße
setstate Od_Gymn 2018-08-10 14:44:19 departure_17_time 2018-08-10T16:04+0200
setstate Od_Gymn 2018-08-10 14:44:19 departure_17_timeInMinutes 80
setstate Od_Gymn 2018-08-10 14:44:19 departure_17_time_human_readable 10.08.2018, 16:04 Uhr
setstate Od_Gymn 2018-08-10 14:44:19 departure_18_delay 0
setstate Od_Gymn 2018-08-10 14:44:19 departure_18_number 002
setstate Od_Gymn 2018-08-10 14:44:19 departure_18_text Mönchengl. Am Hommelsbach
setstate Od_Gymn 2018-08-10 14:44:19 departure_18_time 2018-08-10T16:06+0200
setstate Od_Gymn 2018-08-10 14:44:19 departure_18_timeInMinutes 82
setstate Od_Gymn 2018-08-10 14:44:19 departure_18_time_human_readable 10.08.2018, 16:06 Uhr
setstate Od_Gymn 2018-08-10 14:44:19 departure_19_delay 0
setstate Od_Gymn 2018-08-10 14:44:19 departure_19_number 001
setstate Od_Gymn 2018-08-10 14:44:19 departure_19_text Mön. Clemens-August-Str.
setstate Od_Gymn 2018-08-10 14:44:19 departure_19_time 2018-08-10T16:16+0200
setstate Od_Gymn 2018-08-10 14:44:19 departure_19_timeInMinutes 92
setstate Od_Gymn 2018-08-10 14:44:19 departure_19_time_human_readable 10.08.2018, 16:16 Uhr
setstate Od_Gymn 2018-08-10 14:44:19 departure_1_delay 0
setstate Od_Gymn 2018-08-10 14:44:19 departure_1_number 002
setstate Od_Gymn 2018-08-10 14:44:19 departure_1_text Mönchengl. Am Hommelsbach
setstate Od_Gymn 2018-08-10 14:44:19 departure_1_time 2018-08-10T14:46+0200
setstate Od_Gymn 2018-08-10 14:44:19 departure_1_timeInMinutes 2
setstate Od_Gymn 2018-08-10 14:44:19 departure_1_time_human_readable 10.08.2018, 14:46 Uhr
setstate Od_Gymn 2018-08-10 14:44:19 departure_2_delay 0
setstate Od_Gymn 2018-08-10 14:44:19 departure_2_number 002
setstate Od_Gymn 2018-08-10 14:44:19 departure_2_text MG Hbf /Europaplatz
setstate Od_Gymn 2018-08-10 14:44:19 departure_2_time 2018-08-10T14:56+0200
setstate Od_Gymn 2018-08-10 14:44:19 departure_2_timeInMinutes 12
setstate Od_Gymn 2018-08-10 14:44:19 departure_2_time_human_readable 10.08.2018, 14:56 Uhr
setstate Od_Gymn 2018-08-10 14:44:19 departure_3_delay 0
setstate Od_Gymn 2018-08-10 14:44:19 departure_3_number 001
setstate Od_Gymn 2018-08-10 14:44:19 departure_3_text Mön. Clemens-August-Str.
setstate Od_Gymn 2018-08-10 14:44:19 departure_3_time 2018-08-10T14:56+0200
setstate Od_Gymn 2018-08-10 14:44:19 departure_3_timeInMinutes 12
setstate Od_Gymn 2018-08-10 14:44:19 departure_3_time_human_readable 10.08.2018, 14:56 Uhr
setstate Od_Gymn 2018-08-10 14:44:19 departure_4_delay 0
setstate Od_Gymn 2018-08-10 14:44:19 departure_4_number 001
setstate Od_Gymn 2018-08-10 14:44:19 departure_4_text Mönchengl. Künkelstraße
setstate Od_Gymn 2018-08-10 14:44:19 departure_4_time 2018-08-10T14:58+0200
setstate Od_Gymn 2018-08-10 14:44:19 departure_4_timeInMinutes 14
setstate Od_Gymn 2018-08-10 14:44:19 departure_4_time_human_readable 10.08.2018, 14:58 Uhr
setstate Od_Gymn 2018-08-10 14:44:19 departure_5_delay 0
setstate Od_Gymn 2018-08-10 14:44:19 departure_5_number 002
setstate Od_Gymn 2018-08-10 14:44:19 departure_5_text MG Regiopark 3
setstate Od_Gymn 2018-08-10 14:44:19 departure_5_time 2018-08-10T15:04+0200
setstate Od_Gymn 2018-08-10 14:44:19 departure_5_timeInMinutes 20
setstate Od_Gymn 2018-08-10 14:44:19 departure_5_time_human_readable 10.08.2018, 15:04 Uhr
setstate Od_Gymn 2018-08-10 14:44:19 departure_6_delay 0
setstate Od_Gymn 2018-08-10 14:44:19 departure_6_number 002
setstate Od_Gymn 2018-08-10 14:44:19 departure_6_text Mönchengl. Am Hommelsbach
setstate Od_Gymn 2018-08-10 14:44:19 departure_6_time 2018-08-10T15:06+0200
setstate Od_Gymn 2018-08-10 14:44:19 departure_6_timeInMinutes 22
setstate Od_Gymn 2018-08-10 14:44:19 departure_6_time_human_readable 10.08.2018, 15:06 Uhr
setstate Od_Gymn 2018-08-10 14:44:19 departure_7_delay 0
setstate Od_Gymn 2018-08-10 14:44:19 departure_7_number 001
setstate Od_Gymn 2018-08-10 14:44:19 departure_7_text Mön. Clemens-August-Str.
setstate Od_Gymn 2018-08-10 14:44:19 departure_7_time 2018-08-10T15:16+0200
setstate Od_Gymn 2018-08-10 14:44:19 departure_7_timeInMinutes 32
setstate Od_Gymn 2018-08-10 14:44:19 departure_7_time_human_readable 10.08.2018, 15:16 Uhr
setstate Od_Gymn 2018-08-10 14:44:19 departure_8_delay 0
setstate Od_Gymn 2018-08-10 14:44:19 departure_8_number 001
setstate Od_Gymn 2018-08-10 14:44:19 departure_8_text Mönchengl. Künkelstraße
setstate Od_Gymn 2018-08-10 14:44:19 departure_8_time 2018-08-10T15:18+0200
setstate Od_Gymn 2018-08-10 14:44:19 departure_8_timeInMinutes 34
setstate Od_Gymn 2018-08-10 14:44:19 departure_8_time_human_readable 10.08.2018, 15:18 Uhr
setstate Od_Gymn 2018-08-10 14:44:19 departure_9_delay 0
setstate Od_Gymn 2018-08-10 14:44:19 departure_9_number 002
setstate Od_Gymn 2018-08-10 14:44:19 departure_9_text MG Regiopark 3
setstate Od_Gymn 2018-08-10 14:44:19 departure_9_time 2018-08-10T15:24+0200
setstate Od_Gymn 2018-08-10 14:44:19 departure_9_timeInMinutes 40
setstate Od_Gymn 2018-08-10 14:44:19 departure_9_time_human_readable 10.08.2018, 15:24 Uhr
setstate Od_Gymn 2018-01-24 12:25:26 test 1

Dummy1
defmod richtung_od dummy
attr richtung_od room Draussen->BUS
attr richtung_od verbose 0

setstate richtung_od 2018-08-10 14:41:35 Bus0 MG Regiopark 3
setstate richtung_od 2018-08-10 14:41:35 Bus1 Mön. Clemens-August-Str.
setstate richtung_od 2018-08-10 14:41:35 Bus2 MG Regiopark 3
setstate richtung_od 2018-08-10 14:41:36 Bus3 Mön. Clemens-August-Str.
setstate richtung_od 2018-08-10 14:41:36 Bus4 MG Regiopark 3
setstate richtung_od 2018-08-10 14:41:36 Bus5 Mön. Clemens-August-Str.
setstate richtung_od 2018-08-10 14:41:36 Bus6 Mönchengl. Rostocker Straße
setstate richtung_od 2018-08-10 14:41:36 Bus7 Mön. Clemens-August-Str.
setstate richtung_od 2018-08-10 14:41:36 Bus8 Mönchengl. Rostocker Straße
setstate richtung_od 2018-08-10 14:41:36 Bus9 Mön. Clemens-August-Str.
setstate richtung_od 2018-08-10 14:41:35 Bus_linie0 002
setstate richtung_od 2018-08-10 14:41:35 Bus_linie1 001
setstate richtung_od 2018-08-10 14:41:35 Bus_linie2 002
setstate richtung_od 2018-08-10 14:41:36 Bus_linie3 001
setstate richtung_od 2018-08-10 14:41:36 Bus_linie4 002
setstate richtung_od 2018-08-10 14:41:36 Bus_linie5 001
setstate richtung_od 2018-08-10 14:41:36 Bus_linie6 002
setstate richtung_od 2018-08-10 14:41:36 Bus_linie7 001
setstate richtung_od 2018-08-10 14:41:36 Bus_linie8 002
setstate richtung_od 2018-08-10 14:41:36 Bus_linie9 001
setstate richtung_od 2018-08-10 14:41:35 Bus_min0 5
setstate richtung_od 2018-08-10 14:41:35 Bus_min1 15
setstate richtung_od 2018-08-10 14:41:35 Bus_min2 23
setstate richtung_od 2018-08-10 14:41:36 Bus_min3 35
setstate richtung_od 2018-08-10 14:41:36 Bus_min4 43
setstate richtung_od 2018-08-10 14:41:36 Bus_min5 55
setstate richtung_od 2018-08-10 14:41:36 Bus_min6 63
setstate richtung_od 2018-08-10 14:41:36 Bus_min7 75
setstate richtung_od 2018-08-10 14:41:36 Bus_min8 83
setstate richtung_od 2018-08-10 14:41:36 Bus_min9 95
setstate richtung_od 2018-08-10 14:41:35 Bus_zeit0 10.08.2018, 14:46 Uhr
setstate richtung_od 2018-08-10 14:41:35 Bus_zeit1 10.08.2018, 14:56 Uhr
setstate richtung_od 2018-08-10 14:41:35 Bus_zeit2 10.08.2018, 15:04 Uhr
setstate richtung_od 2018-08-10 14:41:36 Bus_zeit3 10.08.2018, 15:16 Uhr
setstate richtung_od 2018-08-10 14:41:36 Bus_zeit4 10.08.2018, 15:24 Uhr
setstate richtung_od 2018-08-10 14:41:36 Bus_zeit5 10.08.2018, 15:36 Uhr
setstate richtung_od 2018-08-10 14:41:36 Bus_zeit6 10.08.2018, 15:44 Uhr
setstate richtung_od 2018-08-10 14:41:36 Bus_zeit7 10.08.2018, 15:56 Uhr
setstate richtung_od 2018-08-10 14:41:36 Bus_zeit8 10.08.2018, 16:04 Uhr
setstate richtung_od 2018-08-10 14:41:36 Bus_zeit9 10.08.2018, 16:16 Uhr
setstate richtung_od 2018-08-10 14:41:36 Marker 0

Dummy2
defmod richtung_ry dummy
attr richtung_ry room Draussen->BUS
attr richtung_ry verbose 0

setstate richtung_ry 2018-08-10 14:41:35 Bus0 Mönchengl. Am Hommelsbach
setstate richtung_ry 2018-08-10 14:41:35 Bus1 MG Hbf /Europaplatz
setstate richtung_ry 2018-08-10 14:41:35 Bus2 Mönchengl. Künkelstraße
setstate richtung_ry 2018-08-10 14:41:35 Bus3 Mönchengl. Am Hommelsbach
setstate richtung_ry 2018-08-10 14:41:36 Bus4 Mönchengl. Künkelstraße
setstate richtung_ry 2018-08-10 14:41:36 Bus5 Mönchengl. Am Hommelsbach
setstate richtung_ry 2018-08-10 14:41:36 Bus6 Mönchengl. Künkelstraße
setstate richtung_ry 2018-08-10 14:41:36 Bus7 Mönchengl. Am Hommelsbach
setstate richtung_ry 2018-08-10 14:41:36 Bus8 Mönchengl. Künkelstraße
setstate richtung_ry 2018-08-10 14:41:36 Bus9 Mönchengl. Am Hommelsbach
setstate richtung_ry 2018-08-10 14:41:35 Bus_linie0 002
setstate richtung_ry 2018-08-10 14:41:35 Bus_linie1 002
setstate richtung_ry 2018-08-10 14:41:35 Bus_linie2 001
setstate richtung_ry 2018-08-10 14:41:35 Bus_linie3 002
setstate richtung_ry 2018-08-10 14:41:36 Bus_linie4 001
setstate richtung_ry 2018-08-10 14:41:36 Bus_linie5 002
setstate richtung_ry 2018-08-10 14:41:36 Bus_linie6 001
setstate richtung_ry 2018-08-10 14:41:36 Bus_linie7 002
setstate richtung_ry 2018-08-10 14:41:36 Bus_linie8 001
setstate richtung_ry 2018-08-10 14:41:36 Bus_linie9 002
setstate richtung_ry 2018-08-10 14:41:35 Bus_min0 5
setstate richtung_ry 2018-08-10 14:41:35 Bus_min1 15
setstate richtung_ry 2018-08-10 14:41:35 Bus_min2 17
setstate richtung_ry 2018-08-10 14:41:35 Bus_min3 25
setstate richtung_ry 2018-08-10 14:41:36 Bus_min4 37
setstate richtung_ry 2018-08-10 14:41:36 Bus_min5 45
setstate richtung_ry 2018-08-10 14:41:36 Bus_min6 57
setstate richtung_ry 2018-08-10 14:41:36 Bus_min7 65
setstate richtung_ry 2018-08-10 14:41:36 Bus_min8 77
setstate richtung_ry 2018-08-10 14:41:36 Bus_min9 85
setstate richtung_ry 2018-08-10 14:41:35 Bus_zeit0 10.08.2018, 14:46 Uhr
setstate richtung_ry 2018-08-10 14:41:35 Bus_zeit1 10.08.2018, 14:56 Uhr
setstate richtung_ry 2018-08-10 14:41:35 Bus_zeit2 10.08.2018, 14:58 Uhr
setstate richtung_ry 2018-08-10 14:41:35 Bus_zeit3 10.08.2018, 15:06 Uhr
setstate richtung_ry 2018-08-10 14:41:36 Bus_zeit4 10.08.2018, 15:18 Uhr
setstate richtung_ry 2018-08-10 14:41:36 Bus_zeit5 10.08.2018, 15:26 Uhr
setstate richtung_ry 2018-08-10 14:41:36 Bus_zeit6 10.08.2018, 15:38 Uhr
setstate richtung_ry 2018-08-10 14:41:36 Bus_zeit7 10.08.2018, 15:46 Uhr
setstate richtung_ry 2018-08-10 14:41:36 Bus_zeit8 10.08.2018, 15:58 Uhr
setstate richtung_ry 2018-08-10 14:41:36 Bus_zeit9 10.08.2018, 16:06 Uhr
setstate richtung_ry 2018-08-10 14:41:36 Marker 0

Dummy3
defmod Reset dummy
attr Reset room Draussen->BUS

setstate Reset on
setstate Reset 2018-08-10 14:44:18 Reset_on_off off
setstate Reset 2018-08-09 20:14:10 state on
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 10 August 2018, 16:33:19
ich habe mir das jetzt schonmal angeschaut, ohne dummys . ich bin der meinung , das in deiner routine ( zumindest so wie du sie geposted hast ) schliessende Klammern "}" fehlen. kann das sein.

wenn ich die einzelnen if anweisungen etc mal nach und nach rausnehme , bleiben offnende klammern , zu denen es kein gegenstück gibt .

wobei du beachten musst , das die erste { und letzte } nicht zur routine gehört, sondern bei freecmd den perlcode ein/ausleitet .

kannst du das bitte mal prüfen.

poste doch bitten ochmal die routine direkt aus der myutils, ohne irgendwelche änderungen .

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 10 August 2018, 16:39:37
habe dir mal eine PM geschrieben , wenn du willst kannst du mich gerne mal anrufen.

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Torsten_MG am 10 August 2018, 16:48:32
Wenn ich jetzt nichts übersehen habe, sind alle Klammern da.

Hier mal der Code direkt aus der myUtils
sub
Fahrplan()
{
my $richtung = "";
my $uhrzeit = "";
my $min = "";
my $linie = "";
my $i = 0;
my $j = 0;
my $k = 0;
  {fhem("deletereading richtung_od Bus.*")};
{fhem("deletereading richtung_ry Bus.*")};
do
{
        $richtung =  ReadingsVal("Od_Gymn","departure_" . $i . "_text","<undef>");
$uhrzeit =  ReadingsVal("Od_Gymn","departure_" . $i . "_time_human_readable","<undef>");
$linie =  ReadingsVal("Od_Gymn","departure_" . $i . "_number","<undef>");
$min = ReadingsVal("Od_Gymn","departure_" . $i . "_timeInMinutes","<undef>");
{fhem("setreading richtung_od Marker 0")};
{fhem("setreading richtung_ry Marker 0")};

        if ($richtung ne "<undef>")
       {
if($richtung eq "Mön. Clemens-August-Str." || $richtung eq "Mönchengl Nievelsteinstr." || $richtung eq "MG Rheydt Hbf" || $richtung eq "Mönchengl. Rostocker Straße" || $richtung eq "Mönchengladb. Wickrath Markt" || $richtung eq "MG Regiopark 3")
{fhem("setreading richtung_od Bus$j $richtung");
fhem("setreading richtung_od Bus_zeit$j $uhrzeit");
fhem("setreading richtung_od Bus_linie$j $linie");
fhem("setreading richtung_od Bus_min$j $min");
fhem("setreading richtung_od Marker 1")
}
if(ReadingsVal("richtung_od","Marker","") ne "1")
{$j--}
if($richtung eq "Mönchengl. Künkelstraße" || $richtung eq "Mönchengladbach Marienplatz" || $richtung eq "MG Hbf /Europaplatz" || $richtung eq "Mönchengl. Am Hommelsbach" || $richtung eq "Mönchengl. Künkelstraße")
{fhem("setreading richtung_ry Bus$k $richtung");
fhem("setreading richtung_ry Bus_zeit$k $uhrzeit");
fhem("setreading richtung_ry Bus_linie$k $linie");
fhem("setreading richtung_ry Bus_min$k $min");
fhem("setreading richtung_ry Marker 1")
}
if(ReadingsVal("richtung_ry","Marker","") ne "1")
{$k--}
}
$i++;
$j++;
$k++;
}while($richtung ne "<undef>")
}
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 10 August 2018, 17:10:14
Wenn ich jetzt nichts übersehen habe, sind alle Klammern da.

Hier mal der Code direkt aus der myUtils
sub
Fahrplan()
{
my $richtung = "";
my $uhrzeit = "";
my $min = "";
my $linie = "";
my $i = 0;
my $j = 0;
my $k = 0;
  {fhem("deletereading richtung_od Bus.*")};
{fhem("deletereading richtung_ry Bus.*")};
do
{
        $richtung =  ReadingsVal("Od_Gymn","departure_" . $i . "_text","<undef>");
$uhrzeit =  ReadingsVal("Od_Gymn","departure_" . $i . "_time_human_readable","<undef>");
$linie =  ReadingsVal("Od_Gymn","departure_" . $i . "_number","<undef>");
$min = ReadingsVal("Od_Gymn","departure_" . $i . "_timeInMinutes","<undef>");
{fhem("setreading richtung_od Marker 0")};
{fhem("setreading richtung_ry Marker 0")};

        if ($richtung ne "<undef>")
       {
if($richtung eq "Mön. Clemens-August-Str." || $richtung eq "Mönchengl Nievelsteinstr." || $richtung eq "MG Rheydt Hbf" || $richtung eq "Mönchengl. Rostocker Straße" || $richtung eq "Mönchengladb. Wickrath Markt" || $richtung eq "MG Regiopark 3")
{fhem("setreading richtung_od Bus$j $richtung");
fhem("setreading richtung_od Bus_zeit$j $uhrzeit");
fhem("setreading richtung_od Bus_linie$j $linie");
fhem("setreading richtung_od Bus_min$j $min");
fhem("setreading richtung_od Marker 1")
}
if(ReadingsVal("richtung_od","Marker","") ne "1")
{$j--}
if($richtung eq "Mönchengl. Künkelstraße" || $richtung eq "Mönchengladbach Marienplatz" || $richtung eq "MG Hbf /Europaplatz" || $richtung eq "Mönchengl. Am Hommelsbach" || $richtung eq "Mönchengl. Künkelstraße")
{fhem("setreading richtung_ry Bus$k $richtung");
fhem("setreading richtung_ry Bus_zeit$k $uhrzeit");
fhem("setreading richtung_ry Bus_linie$k $linie");
fhem("setreading richtung_ry Bus_min$k $min");
fhem("setreading richtung_ry Marker 1")
}
if(ReadingsVal("richtung_ry","Marker","") ne "1")
{$k--}
}
$i++;
$j++;
$k++;
}while($richtung ne "<undef>")
}

ja, du hast recht .

es gibt einen fehler bei der verarbeitung des perlcodes, und zwar werde "||" intern  falsch behandelt . gib mir eine stunde zeit , ich behebe das.

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Torsten_MG am 10 August 2018, 17:34:46
Zusätzlich muß ja dieser Code um 5sek verzögert abgesetzt werden.
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 10 August 2018, 17:44:40
Zusätzlich muß ja dieser Code um 5sek verzögert abgesetzt werden.

so , nimm den code bitte aus freecmd "cmd2" raus .
drücke dann "add action for freecmd"

dort fügst du den code bitte in "cmd1" ein und gibst darunterbei cmd1 delay 00:00:05 ein.
modify actions drücken.

den trigger für cmd 2 nimmst du bitte ganz raus.

wenn alles gespeichert ist mach bitteein update , ich habe probehalber mal v1.71a eingespielt . reload 98_MSwitch.pm.

danach versuch bitte mal ob es geht und sag mir bescheid.

parallel richt ich jetzt auch mal die ganzen dummys ein

gruss Byte09



Titel: Antw:98_MSwitch - Support
Beitrag von: Torsten_MG am 10 August 2018, 17:58:36
Mit dem Code funktioniert es noch nicht.

Aber mit dem 2. freecmd und den 5sek und den Aufruf {Fahrplan()} funktionierts
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 10 August 2018, 18:04:22
Mit dem Code funktioniert es noch nicht.

Aber mit dem 2. freecmd und den 5sek und den Aufruf {Fahrplan()} funktionierts

ok ,dann lass es bitte erstmal so , ich muss das in ruhe durchtesten. muss dafür aber auch noch module installieren , die ich nicht nutze.

ich melde mich sobald ich es habe.

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Torsten_MG am 10 August 2018, 18:05:48
Kein Streß, es funktioniert ja erstmal!!
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 10 August 2018, 18:39:37
Kein Streß, es funktioniert ja erstmal!!

noch eine kleinigkeit umgebaut, geht jetzt bei mir mit V1.71b.

danke für deine Geduld.

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Torsten_MG am 10 August 2018, 19:02:20
noch eine kleinigkeit umgebaut, geht jetzt bei mir mit V1.71b.
Perfekt! Funktioniert!

danke für deine Geduld.

Kein Problem! Ich habe zu danken, für das super Modul

Titel: Antw:98_MSwitch - Support
Beitrag von: Torsten_MG am 12 August 2018, 06:18:23
Guten morgen,

mir ist da gerade noch ein Problem bei einem schon laufendem MSwitch aufgefallen.

#V V1.71b
#S .Device_Affected -> FL_Lampe-AbsCmd1,FL_Lampe-AbsCmd2,FL_Lampe_D-AbsCmd1,FL_Lampe_D-AbsCmd2
#S .Device_Affected_Details -> FL_Lampe-AbsCmd1,MSwitchtoggle,no_action,on/off,,delay1,delay1,000000,000000,[$EVENT]#[sp]eq#[sp]"FL_Taster1#[dp]state#[dp]FL_Taster1_02"#[sp]OR#[sp][$EVENT]#[sp]eq#[sp]"FL_Taster1#[dp]state#[dp]FL_Taster1_01"#[sp]OR#[sp][$EVTPART1]#[sp]eq#[sp]"FL_Taster2_01"#[sp]OR#[sp][$EVTPART1]#[sp]eq#[sp]"FL_Taster2_02",,0,0,1|FL_Lampe-AbsCmd2,pct,no_action,50 30 0.1,,delay1,delay1,000000,000000,[$EVTPART1]#[sp]eq#[sp]"FL_Taster2_Motion"#[sp]AND#[sp][$EVTPART2]#[sp]eq#[sp]"trigger_cnt"#[sp]AND#[sp][[FL_Lampe_D#[dp]Licht_an]-[FL_Lampe_D#[dp]Licht_aus]]#[sp]AND#[sp][FL_Lampe#[dp]state]#[sp]eq#[sp]"off",,0,0,1|FL_Lampe_D-AbsCmd1,on,no_action,,,delay1,delay1,000000,000000,[FL_Lampe#[dp]state]#[sp]eq#[sp]"on",,0,0,1|FL_Lampe_D-AbsCmd2,off,no_action,,,delay1,delay1,000000,000000,[FL_Lampe#[dp]state]#[sp]eq#[sp]"off",,0,0,1
#S .Device_Events -> no_trigger
#S .First_init -> done
#S .Trigger_Whitelist -> FL_Taster1,FL_Taster2_01,FL_Taster2_02,FL_Taster2_Motion
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> no_trigger
#S .Trigger_condition ->
#S .Trigger_off -> no_trigger
#S .Trigger_on -> *
#S .Trigger_time ->
#S .V_Check -> V 0.4
#S Trigger_device -> all_events
#S Trigger_log -> off
#S last_event -> FL_Taster2_Motion:state:noMotion
#S state -> on
#A MSwitch_Include_MSwitchcmds -> 1
#A MSwitch_Expert -> 1
#A MSwitch_Extensions -> 1
#A MSwitch_Include_Webcmds -> 1
#A MSwitch_Debug -> 0
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A MSwitch_Delete_Delays -> 1
#A MSwitch_Lock_Quickedit -> 1
#A MSwitch_Mode -> Full
#A MSwitch_Activate_MSwitchcmds -> 1
#A room -> 01_Flur->Licht,MSwitch
#A MSwitch_Inforoom -> MSwitch
#A MSwitch_Help -> 0

Und zwar bei dem Bereich wo ich den Bewegungsmelder einsetze.

Ich frage ja mit
[$EVTPART1] eq "FL_Taster2_Motion" AND [$EVTPART2] eq "trigger_cnt" AND [[FL_Lampe_D:Licht_an]-[FL_Lampe_D:Licht_aus]] AND [FL_Lampe:state] eq "off"die Bedingungen ab und Schalte die Lampe mit
MSwitch 'cmd1': Set pct 50 30 1
für 30sek. mit einer leuchtkraft von 50%

Mir ist nun aufgefallen,

daß wenn nach ablauf der 30sek. sich noch jemand im erfassungsbereich des BWM befindet, dann ändert sich der Zustand der Bedingungen nicht, was so auch erwünscht ist. Aber die Lampe geht nicht an. Erst, wenn nach weiteren 30sek, immer noch jemand im Erfassungsbereich ist, geht die Lampe an.

Beispiel:

um 6:10:24 Uhr wird der BWM ausgelöst, die Lampe geht an
um 6:10:54 Uhr geht die Lampe wieder aus, obwohl noch jemand im Erfassungsbereich ist und die Events haben sich nicht geändert.
um 6:11:24 Uhr geht die Lampe wieder an, weil immer noch jemand im Erfassungsbereich des BWM ist.

Am BWM kann es ja nicht liegen, da die Events sich ja nicht ändern. Den minInterval habe ich auch auf 30sek. stehen


EDIT:

Wo holt sich der MSwitch eigentlich die Info FL_Taster2_Motion:trigger_cnt:243 im EVENT her? Das trigger_cnt staht ja auch im [EVTPART2] welches ich abfrage. Ich kann diese Zeile weder im FL_Taster2 noch im FL_Taster2_Motion finden. Ich wollte nämlich mal mit hilfe eines notify ausprobieren, ob es am MSwitch liegt, oder ob ich mit dem notify auch diesen Effekt habe. Aber das trigger_cnt finde ich in beiden devices nicht
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 12 August 2018, 09:12:42
Guten morgen,

mir ist da gerade noch ein Problem bei einem schon laufendem MSwitch aufgefallen.

#V V1.71b
#S .Device_Affected -> FL_Lampe-AbsCmd1,FL_Lampe-AbsCmd2,FL_Lampe_D-AbsCmd1,FL_Lampe_D-AbsCmd2
#S .Device_Affected_Details -> FL_Lampe-AbsCmd1,MSwitchtoggle,no_action,on/off,,delay1,delay1,000000,000000,[$EVENT]#[sp]eq#[sp]"FL_Taster1#[dp]state#[dp]FL_Taster1_02"#[sp]OR#[sp][$EVENT]#[sp]eq#[sp]"FL_Taster1#[dp]state#[dp]FL_Taster1_01"#[sp]OR#[sp][$EVTPART1]#[sp]eq#[sp]"FL_Taster2_01"#[sp]OR#[sp][$EVTPART1]#[sp]eq#[sp]"FL_Taster2_02",,0,0,1|FL_Lampe-AbsCmd2,pct,no_action,50 30 0.1,,delay1,delay1,000000,000000,[$EVTPART1]#[sp]eq#[sp]"FL_Taster2_Motion"#[sp]AND#[sp][$EVTPART2]#[sp]eq#[sp]"trigger_cnt"#[sp]AND#[sp][[FL_Lampe_D#[dp]Licht_an]-[FL_Lampe_D#[dp]Licht_aus]]#[sp]AND#[sp][FL_Lampe#[dp]state]#[sp]eq#[sp]"off",,0,0,1|FL_Lampe_D-AbsCmd1,on,no_action,,,delay1,delay1,000000,000000,[FL_Lampe#[dp]state]#[sp]eq#[sp]"on",,0,0,1|FL_Lampe_D-AbsCmd2,off,no_action,,,delay1,delay1,000000,000000,[FL_Lampe#[dp]state]#[sp]eq#[sp]"off",,0,0,1
#S .Device_Events -> no_trigger
#S .First_init -> done
#S .Trigger_Whitelist -> FL_Taster1,FL_Taster2_01,FL_Taster2_02,FL_Taster2_Motion
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> no_trigger
#S .Trigger_condition ->
#S .Trigger_off -> no_trigger
#S .Trigger_on -> *
#S .Trigger_time ->
#S .V_Check -> V 0.4
#S Trigger_device -> all_events
#S Trigger_log -> off
#S last_event -> FL_Taster2_Motion:state:noMotion
#S state -> on
#A MSwitch_Include_MSwitchcmds -> 1
#A MSwitch_Expert -> 1
#A MSwitch_Extensions -> 1
#A MSwitch_Include_Webcmds -> 1
#A MSwitch_Debug -> 0
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A MSwitch_Delete_Delays -> 1
#A MSwitch_Lock_Quickedit -> 1
#A MSwitch_Mode -> Full
#A MSwitch_Activate_MSwitchcmds -> 1
#A room -> 01_Flur->Licht,MSwitch
#A MSwitch_Inforoom -> MSwitch
#A MSwitch_Help -> 0

Und zwar bei dem Bereich wo ich den Bewegungsmelder einsetze.

Ich frage ja mit
[$EVTPART1] eq "FL_Taster2_Motion" AND [$EVTPART2] eq "trigger_cnt" AND [[FL_Lampe_D:Licht_an]-[FL_Lampe_D:Licht_aus]] AND [FL_Lampe:state] eq "off"die Bedingungen ab und Schalte die Lampe mit
MSwitch 'cmd1': Set pct 50 30 1
für 30sek. mit einer leuchtkraft von 50%

Mir ist nun aufgefallen,

daß wenn nach ablauf der 30sek. sich noch jemand im erfassungsbereich des BWM befindet, dann ändert sich der Zustand der Bedingungen nicht, was so auch erwünscht ist. Aber die Lampe geht nicht an. Erst, wenn nach weiteren 30sek, immer noch jemand im Erfassungsbereich ist, geht die Lampe an.

Beispiel:

um 6:10:24 Uhr wird der BWM ausgelöst, die Lampe geht an
um 6:10:54 Uhr geht die Lampe wieder aus, obwohl noch jemand im Erfassungsbereich ist und die Events haben sich nicht geändert.
um 6:11:24 Uhr geht die Lampe wieder an, weil immer noch jemand im Erfassungsbereich des BWM ist.

Am BWM kann es ja nicht liegen, da die Events sich ja nicht ändern. Den minInterval habe ich auch auf 30sek. stehen


EDIT:

Wo holt sich der MSwitch eigentlich die Info FL_Taster2_Motion:trigger_cnt:243 im EVENT her? Das trigger_cnt staht ja auch im [EVTPART2] welches ich abfrage. Ich kann diese Zeile weder im FL_Taster2 noch im FL_Taster2_Motion finden. Ich wollte nämlich mal mit hilfe eines notify ausprobieren, ob es am MSwitch liegt, oder ob ich mit dem notify auch diesen Effekt habe. Aber das trigger_cnt finde ich in beiden devices nicht

ich muss das nachher mal anhand deiner config durchspielen , hat letztendlich wohl aber damit zu tun , dass die lampe nach 30 sekunden ausgeht , wenn kein neues event mit motion kommt. dieses scheint aber auch erst erneut nach den 30 sekunden zu kommen ?! da muss einfach das timing passen , das heisst , die lampen müssen mindestens solange an sein , bis der melder ( zumindest theoretisch ) en erneutes motion melden kann, est dann kann auch ein erneutes setzen der timer für die lampe erfolgen.

kurz: solange in den 30 sekunden brenndauer kein erneutes event erfolgt , schaltet er die lampen ( richtigerweise ) ab.

ich werde mich aber heute nochmal damit beschäftigen und melde mich dann nochmal , stehe aber gerade erstmal mit meinen eigenen bewegungsmeldern auf kriegsfuss  ;)

edit:

Zitat
EDIT:

Wo holt sich der MSwitch eigentlich die Info FL_Taster2_Motion:trigger_cnt:243 im EVENT her? Das trigger_cnt staht ja auch im [EVTPART2] welches ich abfrage. Ich kann diese Zeile weder im FL_Taster2 noch im FL_Taster2_Motion finden. Ich wollte nämlich mal mit hilfe eines notify ausprobieren, ob es am MSwitch liegt, oder ob ich mit dem notify auch diesen Effekt habe. Aber das trigger_cnt finde ich in beiden devices nicht

das ist ein Event, welches von zugehörigem Modul erzeugt wird ( handelt sich ja um einen Homematicschalter mi BWM - glaube ich ) - insofern muss es auch im Eventmonitor auftauchen .

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Torsten_MG am 12 August 2018, 10:07:17
Wenn nach dem ersten Motion keine Bewegung kommt, geht der BWM nach 30ek. Auf nomotion. Ist aber permanent Bewegung vor dem BWM bleibt er bei motion. Aber erst 60sek  nach dem 1. schalten geht die Lampe wieder an.

Also: eine Bewegung, Lampe geht an. 30sek später geht auf nomotion und Lampe geht aus.

Dauerhafte Bewegung: motion on. Nach 30sek geht Lampe aus, aber weiterhin motion on. Nach weiteren 30sek. Lampe geht an und weiterhin motion on.

Gesendet von meinem SM-J730F mit Tapatalk

Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 12 August 2018, 11:03:34
Wenn nach dem ersten Motion keine Bewegung kommt, geht der BWM nach 30ek. Auf nomotion. Ist aber permanent Bewegung vor dem BWM bleibt er bei motion.

 genau das ist das problem , er bleibt bei motion , aber es wird kein neues event generiert , auf das reagiert werden kann .

da muss entweder im bewegungsmelder dafür gesorgt werden , dass ei neues event generiert wird ( per event on-...regel ) , weiss aber nicht ob des bei deinen Meldern geht, oder es muss im MSwitch eine entsprechende prüfung stattfinden.

reagiert werden kann nur auf ein erzeugtes event . wird keines generiert , sondern es nur nicht geändert , gibt es erstmal nichts , worauf reagiert werden kann.

ich schaue es mir nachher an.

gruss Byte09 
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 12 August 2018, 11:27:06
versuch bitte mal , ob du es lösen kannst , indem du bei deinem bewegungsmelder das attribut "attr <device> event-min-interval reading1:minInterval1" entsprechend setzt .

du musst halt dafür sorgen , dass das event erneut kommt, bevor die 30 sekunden abgelaufen sind.

nicht so schön ist dabei , dass natürlich eine entsprechende systemlast erzeugt wird.

alternativ müsstest du das MSwitch komplett umbauen , und zwar so , dass die lampen nicht schon von vornherein mit einem timer gesetzt werden , sondern diese "nur" angeschaltet werden. dann muss nach 30 sekunden geprüft werden, ob das reading noch auf motion steht , wenn nicht -> lampen aus , wenn ja -> erneute prüfung naxh 30 sekunden.
das geht auch alles in einem device, ist aber schon etwas komplizierter.

alternativ2 kannst du auch bei dem event motion nur "anschalten" , und wenn das event nomotion kommt "abschalten". dann bist du halt an die internen vorgaben des bewegungsmelders gebunden , wielange es dauert, bis das event "nomotion" kommt. ich glaube aber bei den homematic kannst du das über die register ändern (?).

gruss Byte09

edit: du triggerst auch nicht wirklich auf motion, obwohl dieses event ja kommen sollte , sondern irgendwie "hintenrum" (  bei den conditions ) . das sollte auch mal geändert werden , das das alles unnötig verkompliziert. Gerne kannst du mich dazu anrufen , das übersteigt hier den rahmen , bzw verkompliziert es nochmals
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 12 August 2018, 11:50:16
alternativ3: du gaukelst demMSwitch über set MSwitch fakeevent .... vor, das ein Event "motion" ankommt, wenn nach 29 sekunden der state des melders noch auf motion steht. Ist m.E die einfachste lösung in diesem Fall , sollten wir ggf. aber auch telefonieren.

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Torsten_MG am 12 August 2018, 11:55:59
Bin jetzt unterwegs.

Aber mir würde folgende Lösung am besten gefallen.

Bei motion bzw. Trigger_cnt geht die Lampe mit set pcs 50 an und bleibt an bis nomotion kommt.

Gesendet von meinem SM-J730F mit Tapatalk

Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 12 August 2018, 12:02:02
Bin jetzt unterwegs.

Aber mir würde folgende Lösung am besten gefallen.

Bei motion bzw. Trigger_cnt geht die Lampe mit set pcs 50 an und bleibt an bis nomotion kommt.

Gesendet von meinem SM-J730F mit Tapatalk

dann ändere alles was die lampe mit timer einschaltet auf pct 50 und lege den  cmd2 an, der ja jetzt komplett leer ist .

diesen löst du mit entsprechendem event "nomotion" bei "switch DEVICE off + execute 'cmd2'"aus und schaltest die lampe bei affected devicec im cmd2 aus.

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Torsten_MG am 12 August 2018, 18:32:29
Wenn ich versuche bei trigger details bei switch FL_Licht off + execute 'cmd2' etwas einzutragen, dann kommt die Meldung trigger for 'switch Test on + execute on commands' and 'switch Test off + execute off commands' must not both be '*'

Habe deswegen ein weiteres affects Device gemacht und den OFF Befehl dort eingetragen. Scheint so zu funktionieren.

Gesendet von meinem SM-J730F mit Tapatalk
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 12 August 2018, 18:36:42
Wenn ich versuche bei trigger details bei switch FL_Licht off + execute 'cmd2' etwas einzutragen, dann kommt die Meldung trigger for 'switch Test on + execute on commands' and 'switch Test off + execute off commands' must not both be '*'

Habe deswegen ein weiteres affects Device gemacht und den OFF Befehl dort eingetragen. Scheint so zu funktionieren.

Gesendet von meinem SM-J730F mit Tapatalk

ja, im notifymode geht das , das beide zweige denselben trigger nutzen , im fullmode nicht , das dort keinen sinn ergiebt , weil das MSwitch in diesem mode ja auch seinen status ändert. da musst du in den verschiedenen zweigen auf verschiedene events triggern

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 19 August 2018, 18:14:00
Ich werde die kommende Version des Moduls in den nächsten Tagen nun doch in das Fhem SVN einpflegen und eine aktualisierte Dokumentation im Wiki einstellen.

das heisst, das Updates demnächst über das Fhemupdate erfolgen und das bisherige Repository aus der Verwaltungsdatei entfernt werden sollte.

dieses Repository werde ich künftig nur nutzen , um Entwicklerversionen anzubieten.

gruss Byte09

Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 26 August 2018, 11:40:48
ich habe eben die Version V1.73 in das SVN eingechecked, somit ist ein update über git nicht mehr nötig.

die Version 1.73 hat ein geändertes Startverhalten. Ohne weitere Einstellungen reagieren MSwitch - devices nun innerhalb von 1 Minute nach Fhemstart nicht auf Events, somit fängt das Modul im Grunde erst 1 Minute verzögert an zu arbeiten. Dieses war aus verschiedenen Gründen notwendig.

Mit dem neuen Attribut "MSwitch_Startdelay" ist dieses Verhalten beinflussbar und kann auch auf sofortigen Start gesetzt werden (0 Sekunden verzögerung). Dierses sollte nur in Ausnahmefällen genutzt werden.
Für ein nicht gesetztes Attribut werden aut. 60 Sekunden angenommen.

Weiterhin wird bei dem ersten Systemstart nach einem Update die interne StrukturVersionsnummer auf V1.2 gesetzt, dazu werden alle MSwitchdevices aktualisiert.

Interne Hilfetexte wurden aktualisiert und die anordnung derHilfebuttons geändert.

diverse interne änderungen

Bechreibung im FhemWiki:
https://wiki.fhem.de/wiki/MSwitch (https://wiki.fhem.de/wiki/MSwitch)

Der Update-Verweis auf das GIT kann und sollte somit gelöscht werden , falls gesetzt :

update delete https://raw.githubusercontent.com/Byte009/FHEM-MSwitch/master/controls_mswitch.txt
gruss Byte09



Titel: Antw:98_MSwitch - Support
Beitrag von: andies am 26 August 2018, 13:13:55
Der Update-Verweis auf das GIT kann und sollte somit gelöscht werden , falls gesetzt :

update delete https://raw.githubusercontent.com/Byte009/FHEM-MSwitch/master/controls_mswitch.txt
Dann lösche ich das mal aus dem Wiki, oder?
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 26 August 2018, 13:44:13
Dann lösche ich das mal aus dem Wiki, oder?

ja, prima.

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Torsten_MG am 27 August 2018, 17:59:48
Aus irgendeinem Grund hats mir heute ein MSwitch zerschossen. Habe update all und shutdown restart gemacht und plötzlich war trigger details und device action leer.

Habe wieder alles gefüllt und läuft wieder.

Es ging um das MSwitch wo ich mit einem Homematic Taster eine Ikea Tradfri Lampe schalte. Desweiteren muß ich wieder FreeCMD nehmen, da wenn ich den Device der Lampe direkt wähle zur Auswahl nur no_action und remove stehen.

#V V1.73
#S .Device_Affected -> BD_Lampe-AbsCmd1,FreeCmd-AbsCmd1
#S .Device_Affected_Details -> FreeCmd-AbsCmd1,cmd,cmd,set~BD_Lampe~off,set~BD_Lampe~on,delay1,delay1,000000,000000,,,,,1
#S .Device_Events -> BD_Taster1_02 Short#[tr]no_trigger#[tr]BD_Taster1_01 Short
#S .First_init -> done
#S .Trigger_Whitelist -> undef
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> no_trigger
#S .Trigger_condition ->
#S .Trigger_off -> BD_Taster1_02 Short
#S .Trigger_on -> BD_Taster1_01 Short
#S .Trigger_time ->
#S .V_Check -> V 1.2
#S Trigger_device -> BD_Taster1
#S Trigger_log -> off
#S last_event -> BD_Taster1_01
#S state -> on
#A MSwitch_Lock_Quickedit -> 1
#A MSwitch_Expert -> 0
#A MSwitch_Delete_Delays -> 1
#A MSwitch_Activate_MSwitchcmds -> 1
#A MSwitch_Extensions -> 0
#A verbose -> 0
#A disable -> 0
#A MSwitch_Help -> 0
#A MSwitch_Include_Webcmds -> 0
#A MSwitch_Inforoom -> MSwitch
#A MSwitchcmd -> 1
#A MSwitch_Mode -> Full
#A room -> 01_Bad
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Include_MSwitchcmds -> 0
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A MSwitch_Debug -> 0
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 27 August 2018, 18:18:09
Aus irgendeinem Grund hats mir heute ein MSwitch zerschossen. Habe update all und shutdown restart gemacht und plötzlich war trigger details und device action leer.

Habe wieder alles gefüllt und läuft wieder.

Es ging um das MSwitch wo ich mit einem Homematic Taster eine Ikea Tradfri Lampe schalte. Desweiteren muß ich wieder FreeCMD nehmen, da wenn ich den Device der Lampe direkt wähle zur Auswahl nur no_action und remove stehen.

#V V1.73
#S .Device_Affected -> BD_Lampe-AbsCmd1,FreeCmd-AbsCmd1
#S .Device_Affected_Details -> FreeCmd-AbsCmd1,cmd,cmd,set~BD_Lampe~off,set~BD_Lampe~on,delay1,delay1,000000,000000,,,,,1
#S .Device_Events -> BD_Taster1_02 Short#[tr]no_trigger#[tr]BD_Taster1_01 Short
#S .First_init -> done
#S .Trigger_Whitelist -> undef
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> no_trigger
#S .Trigger_condition ->
#S .Trigger_off -> BD_Taster1_02 Short
#S .Trigger_on -> BD_Taster1_01 Short
#S .Trigger_time ->
#S .V_Check -> V 1.2
#S Trigger_device -> BD_Taster1
#S Trigger_log -> off
#S last_event -> BD_Taster1_01
#S state -> on
#A MSwitch_Lock_Quickedit -> 1
#A MSwitch_Expert -> 0
#A MSwitch_Delete_Delays -> 1
#A MSwitch_Activate_MSwitchcmds -> 1
#A MSwitch_Extensions -> 0
#A verbose -> 0
#A disable -> 0
#A MSwitch_Help -> 0
#A MSwitch_Include_Webcmds -> 0
#A MSwitch_Inforoom -> MSwitch
#A MSwitchcmd -> 1
#A MSwitch_Mode -> Full
#A room -> 01_Bad
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Include_MSwitchcmds -> 0
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A MSwitch_Debug -> 0


Habe eben das gleiche Phämonen gehabt und schaue gerade was da los ist .

BITTE UNBEDINGT MAL EIN BACKUP_MSWITCH ALL_DEVICES machen vor eine fhem restart.

ich stelle sobald wie möglich eine aktualisierte version ein , die wieder alle devices lädt.

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 27 August 2018, 18:54:37
WICHTIG !

Leider hat sich bei der Codebereinigung , vor dem einchecken in das svn ein blöder fehler eingeschlichen.

dieser sorgt dafür , dass nach einem Neustart von Fhem nur noch leere MSwitch-Devices existieren.

ich habe eine gefixde version in das GIT gestellt, bitte unbedingt so schnell wie möglich ein einmaliges update machen

update all https://raw.githubusercontent.com/Byte009/FHEM-MSwitch/master/controls_mswitch.txt
einen Fix stelle ich in der kommende Stunde in das SVN.

Sorry, das hätte nicht passieren dürfen , ist aber nicht mehr zu ändern

gruss Byte09

Titel: Antw:98_MSwitch - Support
Beitrag von: andies am 27 August 2018, 19:28:55
Shit happens  ;)
Titel: Antw:98_MSwitch - Support
Beitrag von: det. am 27 August 2018, 20:13:45
Und ich hatte gedacht, das muss so sein  :D :D  Hatte heute früh, als mein Sonos keinen Ton spielte nach dem PC Start einfach die Mswitch Einstellungen mit restore zurückgeholt. Gut wenn man sie gespeichert  hat…
Titel: Antw:98_MSwitch - Support
Beitrag von: Torsten_MG am 27 August 2018, 20:27:35
Muß ich das set <device> backup_mswitch all_devices in jedem MSwitch auslösen, oder nur in einem und damit wird von allen MSwitch ein Backup gemacht?

Gesendet von meinem SM-J730F mit Tapatalk

Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 27 August 2018, 20:36:34
Muß ich das set <device> backup_mswitch all_devices in jedem MSwitch auslösen, oder nur in einem und damit wird von allen MSwitch ein Backup gemacht?

Gesendet von meinem SM-J730F mit Tapatalk
Nur in einem ... da gibt es ja nur die Auswahl all-devices

Gruss Byte0o

Gesendet von meinem SM-G900F mit Tapatalk

Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 27 August 2018, 20:38:10
Und ich hatte gedacht, das muss so sein  :D :D  Hatte heute früh, als mein Sonos keinen Ton spielte nach dem PC Start einfach die Mswitch Einstellungen mit restore zurückgeholt. Gut wenn man sie gepieichert hat…
Definitiv ! Sonst geht es halt nur über die fhem.save ... aber kennen wir ja ;-)

Gruss Byte09

Gesendet von meinem SM-G900F mit Tapatalk

Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 30 August 2018, 17:15:20
ab morgigem fhemupdate werden in Freecmds Kommentarzeilen akzeptiert. Wie in Perl beginnen diese mit einer Raute und enden mit Zeilenumbruch.
Dieses ist sowoh im Perlmodus "{}" als auch im Fhemmodus möglich.
Entsprechende Zeilen werden vor intern Befehlsausführung komplett entfernt.

anzeige der aktuellen systemzeit im Fenster "show active timer".

gruss Byte09

Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 30 August 2018, 18:49:14
nur mal so ein codeschnipsel , ggf. such ja mal jemand so etwas.

da die dunklen monate wieder vor der tür stehe und ich es leid bin , nach hause zu kommen , wohnzimmer - volle beleuchtung, fernseher an  - aber leer. beide kinder in ihren zimmern , natürlich auch alles an  habe ich mal ein MSwitch gebastelt, was entsprechend alles Abschaltet ( bis auf eine Minimalbeleuchtung ) , wenn in einem gewissen zeitraum keine bewegung mehr festgestellt wird. wird nach der abschaltung wieder bewegung registriert, schaltet alles in den zustand , der bei abschaltung aktuell war ( nur für einen eingestellten zeitraum - hier 1800 sekunden -, danach schaltet es alles ab und reagiert auch nicht mehr auf bewegungen , bis manuell wieder etwas angeschaltet wurde ).

unterschieden wird hier noch nach 2 modi - ferneher an / fernseher nicht an - und die zeiten , in denen eine bewegung registriert werden muss, um nicht abzuschalten, werden unterschiedlich ( falls man beim fernsehen nicht zum zappeln neigt ) gesetzt.

ich setze das MSwitch seit einiger Zeit in drei Zimmern ( kinderzimmer / Wohnzimmer ) ein und es läuft ( nach anpassung der erkennungszeiten ) zuverlässig.

aufgrund der raumgrösse betreibe ich im wohnzimmer 3 bewegungsmelder ( zonen ) die zur einer struktur zusammengefasst sind. zur überprüfung , ob das MSwitch überhaupt aktiv werden muss sind ebenso alle geräte , die berücksichtigt werden sollen zur einer struktur zusammengefasst ( wenn sowieso alles aus ist , muss das Device ja nicht aktiv werden).

weiterhin gibt es einen dummy "energy_save" , mit dem ich das ganze aktivieren/deaktivieren kann.

da es doch recht komplex ist und natürlich diverse spezifische gerätenamen enthält , habe ich nur mal ein screenshot in den anhang gestellt. Falls jemand interesse hat , stelle ich gerne ein abgespecktes configfile zur verfügung , dass sich dann entsprechend erweitern , anpassen lässt.

gruss Byte09



.
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 31 August 2018, 18:24:22
kommendes update

mit dem nächsten Update ändere ich die EVENT-Readings , wenn das MSwitch über Zeitsteuerung 'ausgelöst' wird.

Bei 'Auslösung ' um z.b 17:59 werden die Readings wie folgt aussehen, wobei "timetest" in diesem Fall der Name des MSwitch-Devices ist:

EVENT timetest:execute_timer_P1:17:59
EVTFULL timetest:execute_timer_P1:17:59
EVTPART1 timetest
EVTPART2 execute_timer_P1
EVTPART3 17:59

"execute_timer_P1" bis "execute_timer_P4" ist der auslösende Zweig .

somit ist es möglich , in einem device welches zu mehreren Zeiten auslöst, verschiedene Aktionen auszuführe , indem in den Conditions auf die konkrete Zeit (EVTPART3) geprüft wird und jeder Zeit eine Aktion zugeordnet wird.

bisher lieferte eine zeitgesteuerte Auslüsung keine Zeit in den EVENTparts .

weiterhin stehen alle EVENTS ($EVENT, $EVTFULL, $EVTPART1, $EVTPART2, $EVTPART3) als vordefinierte Variablen in den Freecmds zur verfügung . Diese werden in Freecmd mit dem Inhalt der jeweiligen Readings ersetzt.

Gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 01 September 2018, 11:29:35
@ christian ,

da ist unerklärlicher weise beim einspielen was schief gegangen. kann ich noch nicht nachvollziehen.

geh mal in dem device bitte auf get_config

ersetze dort das angezeigte gegen
#V V1.74
#S .Device_Affected -> FreeCmd-AbsCmd1,FreeCmd-AbsCmd2,FreeCmd-AbsCmd3,FreeCmd-AbsCmd4,FreeCmd-AbsCmd5,Ikeadimmer1-AbsCmd1
#S .Device_Affected_Details -> FreeCmd-AbsCmd1,cmd,cmd,{[cnl]my~$ziel[se][cnl]my~$soll[se][cnl][cnl]$ziel~=~ReadingsVal("Ikeadimmer1"#[ko]"ziel"#[ko]0)[se]~#~bis~wohin~gedimmt~werden~soll[cnl]$soll~=~ReadingsVal("trafo_wohnzimmer"#[ko]"pct"#[ko]0)[se]~#~zustand~der~lampe[cnl][cnl]if~($soll~<=~$ziel~)~#~lösche~wiederholung~wenn~ziel~erreicht[cnl]~{[cnl]~fhem("set~Ikeadimmer1~del_delays")[se][cnl]~return[se][cnl]~}[cnl][cnl]if~($soll~>~5){$soll~=~$soll~-5}~else~{$soll=0}[se]~#~setze~zustand~der~lampe~-5[cnl]fhem("set~trafo_wohnzimmer~pct~$soll")[se][cnl]},,delay1,delay1,000000,000000,,,0,0,4|FreeCmd-AbsCmd2,cmd,cmd,setreading~Ikeadimmer1~ziel~90,,delay1,delay1,000000,000000,[$EVTPART3]#[sp]eq#[sp]"18#[dp]00",,,,1|FreeCmd-AbsCmd3,cmd,cmd,setreading~Ikeadimmer1~ziel~60,,delay1,delay1,000000,000000,[$EVTPART3]#[sp]eq#[sp]"18#[dp]25",,,,1|FreeCmd-AbsCmd4,cmd,cmd,setreading~Ikeadimmer1~ziel~40,,delay1,delay1,000000,000000,[$EVTPART3]#[sp]eq#[sp]"22#[dp]25",,,,1|FreeCmd-AbsCmd5,cmd,cmd,setreading~Ikeadimmer1~ziel~0,,delay1,delay1,000000,000000,[$EVTPART3]#[sp]eq#[sp]"23#[dp]55",,,,1|Ikeadimmer1-AbsCmd1,exec_cmd1,no_action,,,delay1,delay1,000000,000000,[trafo_wohnzimmer#[dp]pct]#[sp]>=#[sp]0,,,,2
#S .Device_Events -> no_trigger
#S .First_init -> done
#S .Trigger_Whitelist -> undef
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> no_trigger
#S .Trigger_condition -> undef
#S .Trigger_off -> no_trigger
#S .Trigger_on -> no_trigger
#S .Trigger_time -> on~off~ononly[09:15][18:00][18:25][22:25][23:55]~offonly
#S .V_Check -> V 1.2
#S Trigger_device -> no_trigger
#S Trigger_log -> off
#S last_event -> Ikeadimmer1-AbsCmd1_conditionon
#S state -> active
#A MSwitch_Safemode -> 0
#A MSwitch_Help -> 0
#A disable -> 0
#A MSwitch_Delete_Delays -> 0
#A MSwitch_Mode -> Notify
#A MSwitch_Lock_Quickedit -> 1
#A MSwitch_Extensions -> 0
#A MSwitch_Include_MSwitchcmds -> 0
#A MSwitch_Inforoom -> MSwitch
#A MSwitch_Debug -> 0
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Include_Webcmds -> 1
#A room -> 1_Test
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A MSwitch_Expert -> 1

und drücke auf save changes.

gib mir bitte dann bescheid, ob er das device nun korrekt hat.

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: ChristianH am 01 September 2018, 11:38:40
@Bytes01 - sieht im WebGui schon mal besser aus ... bin mir noch nicht ganz schlüssig, wie ich das testen kann.

Christian
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 01 September 2018, 11:43:03
ersetze di auslösezeiten
'[09:15][18:00][18:25][22:25][23:55]'

einfach gegen eine naheliegende zeit [11:50] und schalte die lampe auf 100 %.
'modify trigger device' drücken zum speichern.

wenn er dann auslöst und keine weitere zeitzuordnung in den freecmds findet sollte er die lampe bis auf 0 runterdimmen, bzw. bis auf den wert , der im reading 'ziel' steht ( falls bereits vorhanden)

die zeiten kannst du dann ja wieder ersetzen

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 01 September 2018, 11:52:42
PS: setze mal die attribute Mswitch_help und MSwitch_debug auf 1 , dann bekommst du entsprechende hilfetexte und prüfoptionen

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: ChristianH am 01 September 2018, 14:09:25
Habe die 18:00 Bedingung auf 14:05 gesetzt und "Check Condition" gemacht:

Zitat
eingehender String:
[$EVTPART3] eq "14:05"

If Anweisung Perl:
if (ReadingsVal('Ikeadimmer1', 'EVTPART3', 'undef') eq "14:05"){$answer = 'true';} else {$answer = 'false';}

Bedingung ist nicht Wahr und wird nicht ausgeführt

Trotz Debug keine Ausgabe in den Logs

Christian
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 01 September 2018, 14:13:51
Habe die 18:00 Bedingung auf 14:05 gesetzt und "Check Condition" gemacht:

Trotz Debug keine Ausgabe in den Logs

Christian

diese bedingung lässt sich mit check condition nicht prüfen. Debug 1 betrifft nicht das logverhalten , sondern nur das gui .

das eventpart3 wird nur dann gesetzt , wenn das MSwitch über den 'execute 'cmd1' at :'  auch um 14:05 ausgelöst hat. dann werden diereadings entsprechend aktualisiert , und nur dann trifft auch die bedingung zu .

in den reading siehst du dann aber , ab der befehl ausgeführt wurde 'Exec_cmd'.


gruss Byte09

ps_: wenn du möchtest können wir mal eine Teamviewer Sitzung machen , dann schaue ich es mir direkt an , muss aber erstmal schnell einkaufen.
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 01 September 2018, 16:16:27
Habe die 18:00 Bedingung auf 14:05 gesetzt und "Check Condition" gemacht:

Trotz Debug keine Ausgabe in den Logs

Christian

wenn du mal bei dir schaust ist da keine verzögerung eingetragen . siehe bild . trage da bitte 8 sekunden ein , dann sollte es passen.

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Torsten_MG am 02 September 2018, 10:27:19
Ich habe da noch ein Problem gefunden.

Habe es mehrfach getestet.

Immer wenn ich ein Shutdown restart auslöse, verliert folgendes MSwitch seine trigger details:

#V V1.73
#S .Device_Affected -> no_device
#S .Device_Affected_Details -> FreeCmd-AbsCmd1,cmd,cmd,set~BD_Lampe~off,set~BD_Lampe~on,delay1,delay1,000000,000000,,,,,1
#S .Device_Events -> no_trigger
#S .First_init -> done
#S .Trigger_Whitelist -> undef
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> no_trigger
#S .Trigger_condition ->
#S .Trigger_off -> no_trigger
#S .Trigger_on -> no_trigger
#S .Trigger_time ->
#S .V_Check -> V 1.2
#S Trigger_device -> BD_Taster1
#S Trigger_log -> off
#S last_event -> BD_Taster1_01
#S state -> off
#A MSwitch_Extensions -> 0
#A MSwitch_Activate_MSwitchcmds -> 1
#A room -> 01_Bad
#A MSwitch_Delete_Delays -> 1
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A MSwitch_Lock_Quickedit -> 1
#A MSwitch_Mode -> Full
#A MSwitch_Include_MSwitchcmds -> 0
#A verbose -> 0
#A disable -> 0
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Include_Webcmds -> 0
#A MSwitch_Debug -> 0
#A MSwitchcmd -> 1
#A MSwitch_Expert -> 0
#A MSwitch_Inforoom -> MSwitch
#A MSwitch_Help -> 0

nach restore ist aber alles wieder da!

#V V1.73
#S .Device_Affected -> BD_Lampe-AbsCmd1,FreeCmd-AbsCmd1
#S .Device_Affected_Details -> FreeCmd-AbsCmd1,cmd,cmd,set~BD_Lampe~off,set~BD_Lampe~on,delay1,delay1,000000,000000,,,,,1
#S .Device_Events -> BD_Taster1_02 Short#[tr]no_trigger#[tr]BD_Taster1_01 Short
#S .First_init -> done
#S .Trigger_Whitelist -> undef
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> no_trigger
#S .Trigger_condition ->
#S .Trigger_off -> BD_Taster1_02 Short
#S .Trigger_on -> BD_Taster1_01 Short
#S .Trigger_time ->
#S .V_Check -> V 1.2
#S Trigger_device -> BD_Taster1
#S Trigger_log -> off
#S last_event -> BD_Taster1_02
#S state -> off
#A MSwitch_Extensions -> 0
#A MSwitch_Activate_MSwitchcmds -> 1
#A room -> 01_Bad
#A MSwitch_Delete_Delays -> 1
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A MSwitch_Lock_Quickedit -> 1
#A MSwitch_Mode -> Full
#A MSwitch_Include_MSwitchcmds -> 0
#A verbose -> 0
#A disable -> 0
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Include_Webcmds -> 0
#A MSwitch_Debug -> 0
#A MSwitchcmd -> 1
#A MSwitch_Expert -> 0
#A MSwitch_Inforoom -> MSwitch
#A MSwitch_Help -> 0
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 02 September 2018, 10:30:49
Ich habe da noch ein Problem gefunden.

Habe es mehrfach getestet.

Immer wenn ich ein Shutdown restart auslöse, verliert folgendes MSwitch seine trigger details:

#V V1.73
#S .Device_Affected -> no_device
#S .Device_Affected_Details -> FreeCmd-AbsCmd1,cmd,cmd,set~BD_Lampe~off,set~BD_Lampe~on,delay1,delay1,000000,000000,,,,,1
#S .Device_Events -> no_trigger
#S .First_init -> done
#S .Trigger_Whitelist -> undef
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> no_trigger
#S .Trigger_condition ->
#S .Trigger_off -> no_trigger
#S .Trigger_on -> no_trigger
#S .Trigger_time ->
#S .V_Check -> V 1.2
#S Trigger_device -> BD_Taster1
#S Trigger_log -> off
#S last_event -> BD_Taster1_01
#S state -> off
#A MSwitch_Extensions -> 0
#A MSwitch_Activate_MSwitchcmds -> 1
#A room -> 01_Bad
#A MSwitch_Delete_Delays -> 1
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A MSwitch_Lock_Quickedit -> 1
#A MSwitch_Mode -> Full
#A MSwitch_Include_MSwitchcmds -> 0
#A verbose -> 0
#A disable -> 0
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Include_Webcmds -> 0
#A MSwitch_Debug -> 0
#A MSwitchcmd -> 1
#A MSwitch_Expert -> 0
#A MSwitch_Inforoom -> MSwitch
#A MSwitch_Help -> 0

nach restore ist aber alles wieder da!

#V V1.73
#S .Device_Affected -> BD_Lampe-AbsCmd1,FreeCmd-AbsCmd1
#S .Device_Affected_Details -> FreeCmd-AbsCmd1,cmd,cmd,set~BD_Lampe~off,set~BD_Lampe~on,delay1,delay1,000000,000000,,,,,1
#S .Device_Events -> BD_Taster1_02 Short#[tr]no_trigger#[tr]BD_Taster1_01 Short
#S .First_init -> done
#S .Trigger_Whitelist -> undef
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> no_trigger
#S .Trigger_condition ->
#S .Trigger_off -> BD_Taster1_02 Short
#S .Trigger_on -> BD_Taster1_01 Short
#S .Trigger_time ->
#S .V_Check -> V 1.2
#S Trigger_device -> BD_Taster1
#S Trigger_log -> off
#S last_event -> BD_Taster1_02
#S state -> off
#A MSwitch_Extensions -> 0
#A MSwitch_Activate_MSwitchcmds -> 1
#A room -> 01_Bad
#A MSwitch_Delete_Delays -> 1
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A MSwitch_Lock_Quickedit -> 1
#A MSwitch_Mode -> Full
#A MSwitch_Include_MSwitchcmds -> 0
#A verbose -> 0
#A disable -> 0
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Include_Webcmds -> 0
#A MSwitch_Debug -> 0
#A MSwitchcmd -> 1
#A MSwitch_Expert -> 0
#A MSwitch_Inforoom -> MSwitch
#A MSwitch_Help -> 0

schaue ich mir nach dem frühstück an

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 02 September 2018, 12:07:38
ich habe versucht da bei mir nachzubauen ( ua. mit dummys ) , kann das problem aber nicht nachstellen.

versuch bitte mal folgendes . lösche das ganze device. danach leg es neu an und spiele das vorhandene configfile ein. dann bitte ein update auf die aktuelle version 1.74 machen und das attribut MSwitch_startdelay auf 0 setzen .

schau ob es dann nach einem restart geht.

sollte es dann immer noch fehlerhaft sein , kann ich es nur prüfen , wenn du mir ein log verbose 5 des gesamten startvorganges schickst. da dieser vermutlich extrem gross ist müsstest du mir diesen bitte per mail schicken . Mailadresse:Byte009@web.de

danach bitte wieder deas loglevel runtersetzen .

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Torsten_MG am 02 September 2018, 13:19:35
Ok. Probiere ich später mal aus

Gesendet von meinem SM-J730F mit Tapatalk

Titel: Antw:98_MSwitch - Support
Beitrag von: Torsten_MG am 02 September 2018, 13:33:20
update all gemacht und shutdown restart.

Bleibt bei V1.73

Aber die Daten bleiben drin! Habe mehrere shutdown restart gemacht!
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 02 September 2018, 14:18:32
update all gemacht und shutdown restart.

Bleibt bei V1.73

Aber die Daten bleiben drin! Habe mehrere shutdown restart gemacht!

ok, die versionsnummer wird er beim nachsten update incl. strukturupdate automatisch fixen. das ist kein drama, hauptsache die daten bleiben jetzt erhalten .

ist mir aber fast unerklärlich  ---  aber egal ( nicht nachvollziehbar ), solange einzelfall.

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Torsten_MG am 02 September 2018, 14:45:10
ich habe da direkt noch etwas  ;D

da ich gerade ein bisschen mit mqtt rumspiele, habe ich das in meinem MSwitch für die Lampe im Flur mit eingebaut. Das was soll funktioniert auch, aber selsamerweise bekomme ich auch fehlerhafte Meldungen.

Und zwar, wenn jemand durch den Bewegungsmelder läuft, dann wird der Publish angestoßen, obwohl ich in cmd1 condition folgendes eingetragen habe:
[FL_Lampe:state] eq "on"

bzw.
[FL_Lampe:state] eq "off"
Der State der Lampe ändert sich aber nicht!

#V V1.73
#S .Device_Affected -> FL_Lampe-AbsCmd1,FL_Lampe-AbsCmd2,FL_Lampe-AbsCmd3,FL_Lampe_D-AbsCmd1,FL_Lampe_D-AbsCmd2,Mosquitto-AbsCmd1,Mosquitto-AbsCmd2
#S .Device_Affected_Details -> FL_Lampe-AbsCmd1,MSwitchtoggle,no_action,on/off,,delay1,delay1,000000,000000,[$EVTPART1]#[sp]eq#[sp]"FL_Taster1"#[sp]OR#[sp][$EVTPART1]#[sp]eq#[sp]"FL_Taster2_01"#[sp]OR#[sp][$EVTPART1]#[sp]eq#[sp]"FL_Taster2_02"#[sp]OR#[sp][$EVTFULL]#[sp]eq#[sp]"MQTT_dummy#[dp]FL_Lampe#[dp]on"#[sp]OR#[sp][$EVTFULL]#[sp]eq#[sp]"MQTT_dummy#[dp]FL_Lampe#[dp]off",,,,1|FL_Lampe-AbsCmd2,pct,no_action,50~3600~1,,delay1,delay1,000000,000000,[$EVTPART1]#[sp]eq#[sp]"FL_Taster2_Motion"#[sp]AND#[sp][$EVTPART2]#[sp]eq#[sp]"trigger_cnt"#[sp]AND#[sp][[FL_Lampe_D#[dp]Licht_an]-[FL_Lampe_D#[dp]Licht_aus]]#[sp]AND#[sp][FL_Lampe#[dp]state]#[sp]eq#[sp]"off",,0,0,1|FL_Lampe-AbsCmd3,off,no_action,,,delay1,delay1,000000,000000,[$EVTPART1]#[sp]eq#[sp]"FL_Taster2_Motion"#[sp]AND#[sp][$EVTPART3]#[sp]eq#[sp]"noMotion"#[sp]AND#[sp][[FL_Lampe_D#[dp]Licht_an]-[FL_Lampe_D#[dp]Licht_aus]]#[sp]#[sp]AND#[sp][FL_Lampe#[dp]state]#[sp]ne#[sp]"off"#[sp]AND#[sp][FL_Lampe#[dp]state]#[sp]ne#[sp]"on",,,,1|FL_Lampe_D-AbsCmd1,on,no_action,,,delay1,delay1,000000,000000,[FL_Lampe#[dp]state]#[sp]eq#[sp]"on",,0,0,1|FL_Lampe_D-AbsCmd2,off,no_action,,,delay1,delay1,000000,000000,[FL_Lampe#[dp]state]#[sp]eq#[sp]"off",,0,0,1|Mosquitto-AbsCmd1,publish,no_action,/Smarthome/FL_Lampe/State2~off,,delay1,delay1,000000,000000,[FL_Lampe#[dp]state]#[sp]eq#[sp]"on",,,,1|Mosquitto-AbsCmd2,publish,no_action,/Smarthome/FL_Lampe/State2~on,,delay1,delay1,000000,000000,[FL_Lampe#[dp]state]#[sp]eq#[sp]"off",,,,1
#S .Device_Events -> no_trigger
#S .First_init -> done
#S .Trigger_Whitelist -> FL_Taster1,FL_Taster2_01,FL_Taster2_02,FL_Taster2_Motion,MQTT_dummy
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> no_trigger
#S .Trigger_condition ->
#S .Trigger_off -> no_trigger
#S .Trigger_on -> *
#S .Trigger_time ->
#S .V_Check -> V 1.2
#S Trigger_device -> all_events
#S Trigger_log -> off
#S last_event -> FL_Taster2_Motion:state:noMotion
#S state -> on
#A MSwitch_Include_MSwitchcmds -> 1
#A MSwitch_Extensions -> 1
#A MSwitch_Debug -> 0
#A MSwitch_Include_Webcmds -> 1
#A MSwitch_Delete_Delays -> 1
#A MSwitch_Inforoom -> MSwitch
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Help -> 0
#A MSwitch_Lock_Quickedit -> 1
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A room -> 01_Flur->Licht,MSwitch
#A MSwitch_Activate_MSwitchcmds -> 1
#A MSwitch_Mode -> Full
#A MSwitch_Expert -> 1

Der Übersicht halber habe ich noch 2 Fotos den neuen Device action beigefügt
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 02 September 2018, 15:53:03
das ist für mich so schwer nachzuvollziehen , da ich alles per dummy anlegen müsste. Die Abfrage der Bedingungen habe ich eben in allen möglichen variationen geprüft, da gibt es keine fehler. d.H es hakt irgendwo in deinen einstellungen. d.h in dem moment , in dem er an die entsprechende prüfung kommt und den befehl ausführt muss das geprüfte device den verlangte status haben .

schaue mir das gerne an ,brauche dafür aber die rawdefinitionen aller beteiligten devices . Alternativ mal per teamviewer drübeschauen.

das problem ist , dass ich das MSwitch nicht anlegen kann, wenn nicht alle beteiligten devices vorhanden sind.

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 02 September 2018, 16:05:57
PS: du kannst mal angehängte version einspielen. stell das device auf verbose 3 . jede conditionprüfung wird dann im log protokoliert.

dann schau mal im log, wie denn der finalstring aussieht und ob das ergebniss zu entsprechender prüfung true oder false ist.

gruss Byte09

- DIESE VERSION BITTE ANSONSTEN NICHT EINSPIELEN -

edit : Anhang gelöscht !
Titel: Antw:98_MSwitch - Support
Beitrag von: Torsten_MG am 02 September 2018, 16:16:13
Das taucht nun im Event Monitor auf

2018-09-02 16:13:54 MSwitch FL_Licht EVENT: FL_Taster2_Motion:trigger_cnt:213
2018-09-02 16:13:54 MSwitch FL_Licht EVTFULL: FL_Taster2_Motion:trigger_cnt:213
2018-09-02 16:13:54 MSwitch FL_Licht EVTPART1: FL_Taster2_Motion
2018-09-02 16:13:54 MSwitch FL_Licht EVTPART2: trigger_cnt
2018-09-02 16:13:54 MSwitch FL_Licht EVTPART3: 213
2018-09-02 16:13:54 MSwitch FL_Licht last_event: FL_Taster2_Motion:trigger_cnt:213
2018-09-02 16:13:54 MSwitch FL_Licht on
2018-09-02 16:13:54 MSwitch FL_Licht Exec_cmd: set FL_Lampe_D off ,set Mosquitto publish /Smarthome/FL_Lampe/State2 on

Das Problem ist, warum kommt da auch set Mosquitto publish /Smarthome/FL_Lampe/State2 on


ich habe auch hier wieder das Problem, dass on und off vertauscht sind, siehe Fotos oben.


Da die Lampe nicht auf on gesetzt wird, scheint er alle Komandos für Lampe off zu senden, siehe set FL_Lampe_D off
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 02 September 2018, 16:27:49
wie gesagt , ich kann das device nicht anlegen . poste doch mal ein screen , dieser drei befehle ( anhang ) .

die vertauschung on und off  kommt daher , da du die zuordnung cmd1 und cmd2 vertauscht hast . ein on des MSwitch devices wird immer mit ausführung des cmd1 quittiert, ein off mit cmd2 . du musst die cmds nur tauschen.

gruss Byte09

PS:hast du einen reload des moduls gemacht nach einspielen ? es werden keine conditions protokoliert ?
Titel: Antw:98_MSwitch - Support
Beitrag von: Torsten_MG am 02 September 2018, 16:35:17
... poste doch mal ein screen , dieser drei befehle ( anhang ) .

..

Titel: Antw:98_MSwitch - Support
Beitrag von: Torsten_MG am 02 September 2018, 16:40:47
Hier noch der Log

2018.09.02 16:39:03 5: TSCUL_Read CUL1: /AF0011475B7E9000D98844157C3AE00000003DF6D5032

2018.09.02 16:39:03 4: TSCUL_Parse: CUL1  069109 A F001 14081956 00 0D 98 8441 57C3AE 000000 03DF6D50 -49dB -49
2018.09.02 16:39:03 5: CUL1: dispatch A0D98844157C3AE00000003DF6D50::-49:CUL1:
2018.09.02 16:39:03 3: FL_Licht MSwitch_Notif: Befehlsausfuehrung -> set FL_Licht on FL_Taster2_Motion:trigger_cnt:223 2159
2018.09.02 16:39:03 3: Aufruf Checkcondition - Parameter condition, name: [$EVTPART1] eq "FL_Taster2_Motion" AND [$EVTPART3] eq "noMotion" AND [[FL_Lampe_D:Licht_an]-[FL_Lampe_D:Licht_aus]]  AND [FL_Lampe:state] ne "off" AND [FL_Lampe:state] ne "on", FL_Licht
2018.09.02 16:39:03 3: Aufruf Checkcondition - Parameter event: FL_Taster2_Motion:trigger_cnt:223
2018.09.02 16:39:03 3: Aufruf Checkcondition - finalstring if (ReadingsVal('FL_Licht', 'EVTPART1', 'undef') eq "FL_Taster2_Motion" && ReadingsVal('FL_Licht', 'EVTPART3', 'undef') eq "noMotion" && (1514919600 < 1514907540 && 1514907540 < 1514959200)  && ReadingsVal('FL_Lampe', 'state', 'undef') ne "off" && ReadingsVal('FL_Lampe', 'state', 'undef') ne "on"){$answer = 'true';} else {$answer = 'false';} 
2018.09.02 16:39:03 3: Aufruf Checkcondition - return false
2018.09.02 16:39:03 3: Aufruf Checkcondition - Parameter condition, name: [FL_Lampe:state] eq "on", FL_Licht
2018.09.02 16:39:03 3: Aufruf Checkcondition - Parameter event: FL_Taster2_Motion:trigger_cnt:223
2018.09.02 16:39:03 3: Aufruf Checkcondition - finalstring if (ReadingsVal('FL_Lampe', 'state', 'undef') eq "on"){$answer = 'true';} else {$answer = 'false';} 
2018.09.02 16:39:03 3: Aufruf Checkcondition - return false
2018.09.02 16:39:03 3: Aufruf Checkcondition - Parameter condition, name: [$EVTPART1] eq "FL_Taster2_Motion" AND [$EVTPART2] eq "trigger_cnt" AND [[FL_Lampe_D:Licht_an]-[FL_Lampe_D:Licht_aus]] AND [FL_Lampe:state] eq "off", FL_Licht
2018.09.02 16:39:03 3: Aufruf Checkcondition - Parameter event: FL_Taster2_Motion:trigger_cnt:223
2018.09.02 16:39:03 3: Aufruf Checkcondition - finalstring if (ReadingsVal('FL_Licht', 'EVTPART1', 'undef') eq "FL_Taster2_Motion" && ReadingsVal('FL_Licht', 'EVTPART2', 'undef') eq "trigger_cnt" && (1514919600 < 1514907540 && 1514907540 < 1514959200) && ReadingsVal('FL_Lampe', 'state', 'undef') eq "off"){$answer = 'true';} else {$answer = 'false';} 
2018.09.02 16:39:03 3: Aufruf Checkcondition - return false
2018.09.02 16:39:03 3: Aufruf Checkcondition - Parameter condition, name: [$EVTPART1] eq "FL_Taster1" OR [$EVTPART1] eq "FL_Taster2_01" OR [$EVTPART1] eq "FL_Taster2_02" OR [$EVTFULL] eq "MQTT_dummy:FL_Lampe:on" OR [$EVTFULL] eq "MQTT_dummy:FL_Lampe:off", FL_Licht
2018.09.02 16:39:03 3: Aufruf Checkcondition - Parameter event: FL_Taster2_Motion:trigger_cnt:223
2018.09.02 16:39:03 3: Aufruf Checkcondition - finalstring if (ReadingsVal('FL_Licht', 'EVTPART1', 'undef') eq "FL_Taster1" || ReadingsVal('FL_Licht', 'EVTPART1', 'undef') eq "FL_Taster2_01" || ReadingsVal('FL_Licht', 'EVTPART1', 'undef') eq "FL_Taster2_02" || ReadingsVal('FL_Licht', 'EVTFULL', 'undef') eq "MQTT_dummy:FL_Lampe:on" || ReadingsVal('FL_Licht', 'EVTFULL', 'undef') eq "MQTT_dummy:FL_Lampe:off"){$answer = 'true';} else {$answer = 'false';} 
2018.09.02 16:39:03 3: Aufruf Checkcondition - return false
2018.09.02 16:39:03 3: Aufruf Checkcondition - Parameter condition, name: [FL_Lampe:state] eq "off", FL_Licht
2018.09.02 16:39:03 3: Aufruf Checkcondition - Parameter event: FL_Taster2_Motion:trigger_cnt:223
2018.09.02 16:39:03 3: Aufruf Checkcondition - finalstring if (ReadingsVal('FL_Lampe', 'state', 'undef') eq "off"){$answer = 'true';} else {$answer = 'false';} 
2018.09.02 16:39:03 3: Aufruf Checkcondition - return true
2018.09.02 16:39:03 3: FL_Licht MSwitch_Set: Befehlsausfuehrung -> set FL_Lampe_D off  L:1238
2018.09.02 16:39:03 3: Aufruf Checkcondition - Parameter condition, name: [FL_Lampe:state] eq "on", FL_Licht
2018.09.02 16:39:03 3: Aufruf Checkcondition - Parameter event: FL_Taster2_Motion:trigger_cnt:223
2018.09.02 16:39:03 3: Aufruf Checkcondition - finalstring if (ReadingsVal('FL_Lampe', 'state', 'undef') eq "on"){$answer = 'true';} else {$answer = 'false';} 
2018.09.02 16:39:03 3: Aufruf Checkcondition - return false
2018.09.02 16:39:03 3: Aufruf Checkcondition - Parameter condition, name: [FL_Lampe:state] eq "off", FL_Licht
2018.09.02 16:39:03 3: Aufruf Checkcondition - Parameter event: FL_Taster2_Motion:trigger_cnt:223
2018.09.02 16:39:03 3: Aufruf Checkcondition - finalstring if (ReadingsVal('FL_Lampe', 'state', 'undef') eq "off"){$answer = 'true';} else {$answer = 'false';} 
2018.09.02 16:39:03 3: Aufruf Checkcondition - return true
2018.09.02 16:39:03 3: FL_Licht MSwitch_Set: Befehlsausfuehrung -> set Mosquitto publish /Smarthome/FL_Lampe/State2 on L:1238
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 02 September 2018, 16:53:00
hier kannst du doch klar sehen ,woher der mosquito befehl kommt :

2018.09.02 16:39:03 3: Aufruf Checkcondition - Parameter condition, name: [FL_Lampe:state] eq "off", FL_Licht
2018.09.02 16:39:03 3: Aufruf Checkcondition - Parameter event: FL_Taster2_Motion:trigger_cnt:223
2018.09.02 16:39:03 3: Aufruf Checkcondition - finalstring if (ReadingsVal('FL_Lampe', 'state', 'undef') eq "off"){$answer = 'true';} else {$answer = 'false';}
2018.09.02 16:39:03 3: Aufruf Checkcondition - return true
2018.09.02 16:39:03 3: FL_Licht MSwitch_Set: Befehlsausfuehrung -> set Mosquitto publish /Smarthome/FL_Lampe/State2 on L:1238

es wird geprüft ob FL_Lampe aus ist . offensichtlich ist diese aus und der befehl set Mosquitto publish /Smarthome/FL_Lampe/State2 on wird ausgeführt .

ich steige irgendwie noch überhaupt nicht hinter die problematik.

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Torsten_MG am 02 September 2018, 16:57:39
Mein Problem ist, das der Aufruf/Befehl ausgeführt wird, wenn jemand tagsüber durch den BWM läuft. Der wird aber nur für abends/nachts gebraucht wo das Licht gedämmt automatisch eingeschaltet werden soll.

Gesendet von meinem SM-J730F mit Tapatalk

Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 02 September 2018, 17:06:19
Mein Problem ist, das der Aufruf/Befehl ausgeführt wird, wenn jemand tagsüber durch den BWM läuft. Der wird aber nur für abends/nachts gebraucht wo das Licht gedämmt automatisch eingeschaltet werden soll.

Gesendet von meinem SM-J730F mit Tapatalk

dann setze doch in den entsprechenden cmd noch eine bedingung , die ihn nur zu bestimmten zeiten ausführen lässt AND [20:00-23:00] oder per sunset AND [{ sunset() }-{ sunrise() }]

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Torsten_MG am 02 September 2018, 17:12:15
dann setze doch in den entsprechenden cmd noch eine bedingung , die ihn nur zu bestimmten zeiten ausführen lässt AND [20:00-23:00] oder per sunset AND [{ sunset() }-{ sunrise() }]

gruss Byte09
Die Idee hatte ich am Anfang auch, aber der Publish soll ja immer gesendet werden, wenn sich der state der Lampe ändert.

Dann muß ich mir was anderes einfallen lassen.

Gesendet von meinem SM-J730F mit Tapatalk

Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 02 September 2018, 17:14:44
Die Idee hatte ich am Anfang auch, aber der Publish soll ja immer gesendet werden, wenn sich der state der Lampe ändert.

Dann muß ich mir was anderes einfallen lassen.

Gesendet von meinem SM-J730F mit Tapatalk

offenbar möchtest du ja verschiedene aktionen ausführen , je nach nacht/tag bzw Lichtverhältnissen.  Wenn dem so ist , solltest du eine Aktion ggf. in ein komplett eigenständiges MSwitch auslagern ?!

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Torsten_MG am 02 September 2018, 17:31:19
Habe es jetzt ganz anders gelöst. Der Weg war viel einfacher.[emoji16]

Da ich ja MQTT_GENERIC_BRIDGE installiert habe, brauchte ich ja im Lampen Device nur mqttPublish zu aktivieren [emoji41]

Gesendet von meinem SM-J730F mit Tapatalk

Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 02 September 2018, 17:33:26
Habe es jetzt ganz anders gelöst. Der Weg war viel einfacher.[emoji16]

Da ich ja MQTT_GENERIC_BRIDGE installiert habe, brauchte ich ja im Lampen Device nur mqttPublish zu aktivieren [emoji41]

Gesendet von meinem SM-J730F mit Tapatalk

Zitat
Viele Wege führen nach Rom
   ;)
Titel: Dummy als Trigger - geht nicht recht
Beitrag von: Panik am 03 September 2018, 16:44:39
Hallo,

ich habe einen Dummy als Trigger und der ist "eins" als State
Prüfe ich die conditions erhalte ich merkwürdigerweise ein unwahre Ergebnis. :o
Was ist falsch?

eingehender String:
[anwesend:State] eq "eins"

If Anweisung Perl:
if ( ReadingsVal('anwesend', 'State', 'undef') eq "eins"){$answer = 'true';} else {$answer = 'false';}

Bedingung ist nicht Wahr und wird nicht ausgeführt
Titel: Antw:98_MSwitch - Support
Beitrag von: Panik am 03 September 2018, 16:52:15
Antwort an mich  ;)

nicht "State" sondern "state" ist zu schreiben
Vielleicht kann das ja noch großzügiger behandelt werden...

Aber das Modul ist Klasse.
Besonders die Hilfestellungen mit den Fragezeichen und weitere
Schmankerl mit den ganzen Einstellmöglichkeiten über das Webinterface.
So würde man es sich auch bei anderen Modulen wünschen ...
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 03 September 2018, 17:05:12
Antwort an mich  ;)

nicht "State" sondern "state" ist zu schreiben
Vielleicht kann das ja noch großzügiger behandelt werden...

Aber das Modul ist Klasse.
Besonders die Hilfestellungen mit den Fragezeichen und weitere
Schmankerl mit den ganzen Einstellmöglichkeiten über das Webinterface.
So würde man es sich auch bei anderen Modulen wünschen ...

problem selber gelöst  ;), thx für den rest

Zitat
Vielleicht kann das ja noch großzügiger behandelt werden...

möchte ich ungerne, da ja alle möglichen readings etc. geprüft werden können und es ggf. ja mal vorkommen kann, dass da Gross und Kleinschreibung den kleinen Unterschied machen , falls wirklich ( obwohl unwahrscheinlich ) mal beides in einem Device vorhanden sein sollte.

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 03 September 2018, 17:57:37
ich habe den letzten Beitrag zum Anlass genommen , die Ausgabe bei check conditions etwas zu erweitern. Ab der kommenden Version wird der Status aller geprüften Readings mit angezeigt.

eingehender String:
[HARMONY:activity] ne "PowerOff"

If Anweisung Perl:
if (ReadingsVal('HARMONY', 'activity', 'undef') ne "PowerOff"){$answer = 'true';} else {$answer = 'false';}

Bedingung ist nicht Wahr und wird nicht ausgeführt

States der geprüften Readings:
Reading: [HARMONY:activity] - Inhalt: PowerOff

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Esjay am 03 September 2018, 20:40:57
Nabend Byte,
Hast du zufällig etwas an dem Modul geändert zwecks der verwendung der Pipes?
#V V1.74
#S .Device_Affected -> Flur-AbsCmd1,ReceiverAxBox4K-AbsCmd1,TelegramBot-AbsCmd1
#S .Device_Affected_Details -> Flur-AbsCmd1,Speak,no_action,45~de~#[wa]Ton#[wa]~Am~[myAbfall.next_weekday]~wird~[ArtikelMuell.state]~[myAbfall.next_text]~abgeholt~heute~ist~[Wochentag.state],,delay1,delay1,000000,000000,[Haus#[dp]state]#[sp]eq#[sp]"home",000000,home~eq~"home",0,1|ReceiverAxBox4K-AbsCmd1,showText,no_action,Am~[myAbfall.next_weekday]~wird~[ArtikelMuell.state]~[myAbfall.next_text]~abgeholt~heute~ist~[Wochentag.state],,delay1,delay1,000000,000000,[Haus#[dp]state]#[sp]eq#[sp]"home",,,,1|TelegramBot-AbsCmd1,msg,no_action,@#Home~Am~[myAbfall.next_weekday]~wird~[ArtikelMuell.state]~[myAbfall.next_text]~abgeholt~heute~ist~[Wochentag.state],,delay1,delay1,000000,000000,[Haus#[dp]state]#[sp]ne#[sp]"home",,,,1
#S .Device_Events -> no_trigger
#S .First_init -> done
#S .Trigger_Whitelist -> undef
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> no_trigger
#S .Trigger_condition ->
#S .Trigger_off -> no_trigger
#S .Trigger_on -> no_trigger
#S .Trigger_time -> on[18:30][19:30][20:30]~off~ononly~offonly
#S .V_Check -> V 1.2
#S Trigger_device -> no_trigger
#S Trigger_log -> off
#S last_event -> undef
#S state -> on
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Help -> 1
#A MSwitch_Include_MSwitchcmds -> 0
#A MSwitch_Extensions -> 0
#A MSwitch_Expert -> 0
#A MSwitch_Include_Webcmds -> 0
#A MSwitch_Delete_Delays -> 1
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A MSwitch_Mode -> Full
#A room -> MSwitch
#A MSwitch_Lock_Quickedit -> 1

Wenn ich den Command über "set Muelinfo exec_cmd1" ausführe ist alles in Ordnung.

Führt das Modul ihn über den Timer aus, kommt das bei raus.

Siehe Exec_cmd

Internals:
   NAME       MuellInfo
   NOTIFYDEV  no_trigger
   NR         284
   NTFY_ORDER 45-MuellInfo
   STATE      on
   TYPE       MSwitch
   Version    V1.74
   READINGS:
     2018-09-03 20:30:00   EVENT           MuellInfo:execute_timer_P1:20:30
     2018-09-03 20:30:00   EVTFULL         MuellInfo:execute_timer_P1:20:30
     2018-09-03 20:30:00   EVTPART1        MuellInfo
     2018-09-03 20:30:00   EVTPART2        execute_timer_P1
     2018-09-03 20:30:00   EVTPART3        20:30
     2018-09-03 20:30:00   Exec_cmd        set Flur Speak 45 de #[wa]Ton#[wa] Am [myAbfall:next_weekday] wird [ArtikelMuell:state] [myAbfall:ne....
     2018-09-03 20:15:26   Trigger_device  no_trigger
     2018-07-26 20:12:23   Trigger_log     off
     2018-09-03 20:30:00   state           on
   helper:
     conditioncheck if (ReadingsVal('Haus', 'state', 'undef') ne "home"){$answer = 'true';} else {$answer = 'false';}
     savemodeblock:
     timer:
       1535999400-1 1535999400-1
       1536012010 1536012010-5
Attributes:
   MSwitch_Delete_Delays 1
   MSwitch_Expert 0
   MSwitch_Extensions 0
   MSwitch_Help 1
   MSwitch_Ignore_Types notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
   MSwitch_Include_Devicecmds 1
   MSwitch_Include_MSwitchcmds 0
   MSwitch_Include_Webcmds 0
   MSwitch_Lock_Quickedit 1
   MSwitch_Mode Full
   room       MSwitch




Grüße
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 03 September 2018, 21:22:05
Nabend Byte,
Hast du zufällig etwas an dem Modul geändert zwecks der verwendung der Pipes?
#V V1.74
#S .Device_Affected -> Flur-AbsCmd1,ReceiverAxBox4K-AbsCmd1,TelegramBot-AbsCmd1
#S .Device_Affected_Details -> Flur-AbsCmd1,Speak,no_action,45~de~#[wa]Ton#[wa]~Am~[myAbfall.next_weekday]~wird~[ArtikelMuell.state]~[myAbfall.next_text]~abgeholt~heute~ist~[Wochentag.state],,delay1,delay1,000000,000000,[Haus#[dp]state]#[sp]eq#[sp]"home",000000,home~eq~"home",0,1|ReceiverAxBox4K-AbsCmd1,showText,no_action,Am~[myAbfall.next_weekday]~wird~[ArtikelMuell.state]~[myAbfall.next_text]~abgeholt~heute~ist~[Wochentag.state],,delay1,delay1,000000,000000,[Haus#[dp]state]#[sp]eq#[sp]"home",,,,1|TelegramBot-AbsCmd1,msg,no_action,@#Home~Am~[myAbfall.next_weekday]~wird~[ArtikelMuell.state]~[myAbfall.next_text]~abgeholt~heute~ist~[Wochentag.state],,delay1,delay1,000000,000000,[Haus#[dp]state]#[sp]ne#[sp]"home",,,,1
#S .Device_Events -> no_trigger
#S .First_init -> done
#S .Trigger_Whitelist -> undef
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> no_trigger
#S .Trigger_condition ->
#S .Trigger_off -> no_trigger
#S .Trigger_on -> no_trigger
#S .Trigger_time -> on[18:30][19:30][20:30]~off~ononly~offonly
#S .V_Check -> V 1.2
#S Trigger_device -> no_trigger
#S Trigger_log -> off
#S last_event -> undef
#S state -> on
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Help -> 1
#A MSwitch_Include_MSwitchcmds -> 0
#A MSwitch_Extensions -> 0
#A MSwitch_Expert -> 0
#A MSwitch_Include_Webcmds -> 0
#A MSwitch_Delete_Delays -> 1
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A MSwitch_Mode -> Full
#A room -> MSwitch
#A MSwitch_Lock_Quickedit -> 1

Wenn ich den Command über "set Muelinfo exec_cmd1" ausführe ist alles in Ordnung.

Führt das Modul ihn über den Timer aus, kommt das bei raus.

Siehe Exec_cmd

Internals:
   NAME       MuellInfo
   NOTIFYDEV  no_trigger
   NR         284
   NTFY_ORDER 45-MuellInfo
   STATE      on
   TYPE       MSwitch
   Version    V1.74
   READINGS:
     2018-09-03 20:30:00   EVENT           MuellInfo:execute_timer_P1:20:30
     2018-09-03 20:30:00   EVTFULL         MuellInfo:execute_timer_P1:20:30
     2018-09-03 20:30:00   EVTPART1        MuellInfo
     2018-09-03 20:30:00   EVTPART2        execute_timer_P1
     2018-09-03 20:30:00   EVTPART3        20:30
     2018-09-03 20:30:00   Exec_cmd        set Flur Speak 45 de #[wa]Ton#[wa] Am [myAbfall:next_weekday] wird [ArtikelMuell:state] [myAbfall:ne....
     2018-09-03 20:15:26   Trigger_device  no_trigger
     2018-07-26 20:12:23   Trigger_log     off
     2018-09-03 20:30:00   state           on
   helper:
     conditioncheck if (ReadingsVal('Haus', 'state', 'undef') ne "home"){$answer = 'true';} else {$answer = 'false';}
     savemodeblock:
     timer:
       1535999400-1 1535999400-1
       1536012010 1536012010-5
Attributes:
   MSwitch_Delete_Delays 1
   MSwitch_Expert 0
   MSwitch_Extensions 0
   MSwitch_Help 1
   MSwitch_Ignore_Types notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
   MSwitch_Include_Devicecmds 1
   MSwitch_Include_MSwitchcmds 0
   MSwitch_Include_Webcmds 0
   MSwitch_Lock_Quickedit 1
   MSwitch_Mode Full
   room       MSwitch




Grüße

in der tat habe ich da etwas geändert und habe da etwas verbockt. versuche in 10 minuten einen fix hier einzustellen

gruss Byte09

Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 04 September 2018, 05:39:53
Ich habe eben einen FIX in das SVN geladen , der das Problem hoffentlich beseitigt.

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 05 September 2018, 18:40:35
V1.75 ab morgen im SVN

Webinterface geändert: Bei Datenänderung in einem Abschnitt wird das Speichern in allen anderen Abschnitten gesperrt, bis die Daten gespeichert wurden , oder wieder im Ursprungszustand sind.
( mal sehen , weiss noch nicht ob das der Weisheit letzter Schluss ist )

Mit dem Befehl on und off kann nun ein weiteres Argument übergeben werden set <device> on/off <parameter>. dieses wird als allererste Aktion im Reading 'Parameter' gespeichert und kann somit in jeder Aktion genutzt werden.

Behandlung von Readingaktivierten Sonderfällen/Modes.
 - Zuschalten von besonderen Modes, die aber so speziell sind, dass ich sie nicht über attribute schaltbar machen möchte. Im Grunde nur aus Eigenbedarf , mehr dazu falls mal irgendwo Bedarf besteht

FIX: setmagic / ersetzungen

gruss Byte09


Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 08 September 2018, 12:28:42
kommendes Update auf V1.76

- Logverhalten:
überarbeitet

- Bugfix:
im 'cmd2' wurde fälschlicher Weise versucht den Eintrag 'no_action' als Befehl  'no:action' an betreffendes Device abzusetzen. Das hat die Funtion erstmal nicht beeinträchtigt, sorgte aber unter umständen für 'unschöne' Fehlermeldungen im Log.
Dieses wurde behoben

- Funktionserweiterung Expertenmodus:
neben dem Auswahlfeld 'priority' steht nun ein weiteres Feld 'ID' zur Verfügung. Dieses steht standartmässig auf '-' kann aber auf eine ID gessetzt werden.
Die Auswahlmöglichkeiten der ID stehen in direktem Zusammenhang zur Anzahl der 'affected devices'.

Sobald der Wert von '-' auf eine ID gesetzt wird, wird dieses Device im normalen Programmablauf nicht mehr berücksichtigt ( es finden keine Schaltvorgänge statt ). Dier hier gesetze Befehl (oder Freecmd) kann aber separat aufgerufen werden set <DEVICE> <exec_cmd1>/<exec_cmd2> ID <NUMMER>Sollte das MSwitch Device selber in der Liste der 'affected devices' stehen , so werde diese Befehle direkt in entsprechenden Feldern angeboten.

Sollten mehrere 'affected Devices' die gleiche ID haben , werden mit entsprechendem Aufruf alle 'cmds' mit entsprechender ID ausgeführt.
Hintergund dieser Erweiterung ist der, das unter Umständen Befehle / Befehlsketten ausgeführt werden sollen , die völlig unabhängig von einem bestimmten 'Schalten' sind. Ich werde in den kommenden Tagen einige Beispieldevices in das Wiki stellen , die diese Funtion nutzen.
Im Normalmodus bleibt hier alles beim alten, ebenso im Expertenmode, wenn keine IDs zugewiesen werden.

- Funtionserweiterung durch Reading
Diese Option erwähne ich hier nur, damit bekannt ist das sie da ist, und niemand durch zufall darauf stösst und sich damit seine Fheminstallation 'verbiegt'. Ein Eintrag hier ist im Grunde ein direkter Eingriff in den Modulcode !
Durch setzten des Readings 'Sys_Extension' -> 'on' wird eine weiter Option in den Get Kommados aktiviert ( 'get_sysextension' ). Hier ist es Möglich , Perlcode einzutragen , der der nach bestimmten Kriterien an bestimmten Punkten des Codes ausgeführt wird.

Hintergund ist hier der, das ich so die Möglichkeit habe , gewisse 'Sonderanpassungen' zu machen , die ich aber nicht grundsätzlich im Modul habe möchte , da der  'allgemeine' Umfang einfach gesprengt werden würde. So kann ich Anpassungen nur für bestimmte Devices ermöglichen.

Als Beispiel habe ich jedem Dimmer ein MSwitch vorgeschaltet , um bestimmte Aktionen nach bestimmten Bedingungen zu ermöglichen , die das Dimmerdevice so nicht hergiebt. Gleichzeitig möchte ich dieses Device aber auch genau wie einen Dimmer Bedienen können. Dazu muss das Modul aber mit dem Befehl 'pct' umgehen können , da ansonsten u.A. gar keine Parameter zu 'on' oder 'off' zugelassen wären. Dazu habe ich an dieser Stelle z.b diesen code erweitert.
$special='pct:slider,0,1,100';
my $arg = $args[0];
if ($cmd eq "pct" && $arg eq '0')
{
$cmd ='off';
}
if ($cmd eq "pct" && $arg ne '0')
{
$cmd ='on';
}   
 if ( $cmd eq 'on' && $arg eq '')
{
$args[0] = ReadingsVal( $name, 'pct', 100);
}
if ( $cmd eq 'off' && $arg eq ''    )
{
$args[0] = 0;
}
readingsSingleUpdate( $hash, "pct", $args[0], 1 );

stark vereinfacht um um den Hintergrund dieser Möglichkeit zu erklären, diese hier könnte man in diesem Fall auch anders bezwecken.
Diese Möglichkeit sollte im Grunde nicht genutzt werden, sondern ich möchte hiermit auf Userwünsche und oder spezielle Anforderungen eingehen können.

gruss Byte09




Titel: Antw:98_MSwitch - Support
Beitrag von: Panik am 10 September 2018, 16:01:08
Hallo,

ich habe ein MSwitch, mit den Trigger-Einstellungen im Bild.
Werktags funktioniert es perfekt.
Heute hatte ich Urlaub. Da sollte es nicht auslösen. Hat es aber dennoch.
Die Trigger condition ist aber nachweisbar richtig und bringt heute auch "nicht wahr"

Muss ich das Trigger-Gebilde anders aufbauen?

Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 10 September 2018, 16:32:48
Hallo,

ich habe ein MSwitch, mit den Trigger-Einstellungen im Bild.
Werktags funktioniert es perfekt.
Heute hatte ich Urlaub. Da sollte es nicht auslösen. Hat es aber dennoch.
Die Trigger condition ist aber nachweisbar richtig und bringt heute auch "nicht wahr"

Muss ich das Trigger-Gebilde anders aufbauen?

Hi , hab es auf die schnelle bei mir mal gechecked, scheint aber auf den 1 blick alles OK. Mal ganz dumm gerfagt, '$we' weiss auch , dass du heute urlaub hast ? ist das in der holiday definiert ?

was liefert denn ein
{$we}in der kommandozeile ?  .... müsste dann ja heute bei dir eine 1 zurückgeben ?

gruss Byte09


Edit: die Triggerconditionen greifen nicht bei einer reinen Zeitsteuerung in der Grundeinstellung  . Das $we müsste hier auch ausreichend sein , wenn holiday definiert ist .

Deine einstellung ist auch im 'normalmode/grundeinstellung', das siehst du an : "Trigger condition (events only): ". soll die condition auch bei reiner zeitsteuerung greifen , musst du das attribut 'MSwitch_Condition_Time' auf 1 setzen , dann greift es auch für zeiten und es sollte dort stehen : "Trigger condition (time&events): "

Auszug Hilfetxt :
Zitat
Achtung: Conditions gelten nur für auslösende Trigger eines Devices und haben keinen Einfluss auf zeitgesteuerte Auslöser. Um Zeitgesteuerte Auslösr ebenfalls an Bedingungen zu Knüpfen muss dieses in den Attributen aktiviert werden.

PS: so wie du das MSwitch konfiguriert hast ( zumindest beim trigger ), ist es systemschonender , wenn du das MSwitch in den reinen Notifymode bringst . Attribut 'MSwitch_Mode' auf 'Notify' , ausser du schaltest es auch manuell
Titel: Antw:98_MSwitch - Support
Beitrag von: Esjay am 10 September 2018, 17:36:21
Nabend, kurze Frage.
Wie bekomme ich Repeat und Repeatdelay eingeblendet?
Geschweige denn, wo ist "without Conf-check" ?

Zitat
Die Auswahl "with Conf-check" oder "without Conf-check" legt fest, ob unmittelbar vor Befehlsausführung nochmals die Condition für den Befehl geprüft wird oder nicht.


Grüße
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 10 September 2018, 17:40:42
Nabend, kurze Frage.
Wie bekomme ich Repeat und Repeatdelay eingeblendet?
Geschweige denn, wo ist "without Conf-check" ?

Grüße
Kurz da Handy

Für repeats das Attribut mswitch_expert auf 1 setzen ... dann bekommst du u.a diese Optionen.   Die configoptionen befinden sich in den dropdownlisten bei den affected devices , vor den Eingabefeldern für verzögertes schalten.

Gruss byte09

Gesendet von meinem SM-G900F mit Tapatalk

Titel: Antw:98_MSwitch - Support
Beitrag von: Esjay am 10 September 2018, 17:44:59
Kurz da Handy

Für repeats das Attribut mswitch_expert auf 1 setzen ... dann bekommst du u.a diese Optionen.   Die configoptionen befinden sich in den dropdownlisten bei den affected devices , vor den Eingabefeldern für verzögertes schalten.

Gruss byte09

Gesendet von meinem SM-G900F mit Tapatalk

Man sollte die Texte auch zuende lesen. Sry.

Das habe ich gefunden, aber da steht ja überall nur "with cond check......."
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 10 September 2018, 18:01:06
Man sollte die Texte auch zuende lesen. Sry.

Das habe ich gefunden, aber da steht ja überall nur "with cond check......."

ja , mit diesen optionen kannst du doch alles abdecken

wenn du eine condition angiebst kannst du wählen:

- check nur sofort
- check nur verzögert
- check sofort und nochmal verzögert

wenn du keine condition eingiebst hast du : without check  ;)

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Esjay am 10 September 2018, 18:10:00
Ok, habe den zusammenhang nicht gecheckt.

Danke für die Gedult.

Gruß
Titel: Antw:98_MSwitch - Support
Beitrag von: Panik am 10 September 2018, 20:09:37
Hallo Byte09,

ich habe jetzt MSwitch_Condition_Time' auf 1 gesetzt, denn das ist was ich wollte. Danke!
Probieren werde ich es morgen.

PS: "urlaubsstatus" ziehe ich aus Google-Kalender und ist nicht in holiday sowie we hinterlegt.
Soll praktisch dynamisch-flexibel unkompliziert dazu kommen und so wirken als wäre es in der Holidaydatei  hinterlegt.

Panik
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 10 September 2018, 20:18:07
das angekündigte update auf V1.76 wir noch etwas auf sich warten lassen , da ich mich entschlossen habe daraus ein 'grosses' update zu machen. dazu wird u.a die form der gespeicherten daten komplett geändert . aufgrund vieler änderungen im laufe der zeit ist das intern derzeit nicht einheitlich . dieses führt zu extremen aufwand bei jeder änderung und ist somit fehleranfällig ( musste ich die tage erst feststelle mit einer fehlenden ersetzung ). Dieses werde ich nun ändern, auch mit dem Ziel backups, configfiles etc. wieder etwas leserlicher zu machen.

vorhanden daten bleiben dabei natürlich erhalten und werden dann automatisch angepasst , wie einige male schon  ;)

mit morgigem update im svn habe ich nur eine kleinigkeit gefixt.

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: arthur_dent_2015 am 13 September 2018, 18:26:49
Moin Byte09,
MSwitch schein DAS Modul zu sein mit dem ich meine, inzwischen etwas unübersichtliche, Fhem Installation wieder in den Griff bekommen könnte. Hab mich also durch das Wiki und den Foren Threat gelesen und mein erstes device angelegt und die bisherigen DOIF's und notifys deaktiviert. Hat soweit auch (fast) alles auf Anhieb funktioniert. Bis auf eine condition die falsch gesetzt war. Folge war, das Licht im Wohnzimmer brannte die ganze Nacht und ich habs erst heute morgen bemerkt :( Kurzer Blick ins Log und die Sache war klar. Kommt halt davon wenn man den Überblick verloren hat  ??? Ich fände es daher sehr hilfreich wenn es einen "testmode" gäbe mit dem man das device testen könnte, sprich die commands werden alle, wie definiert, abgearbeitet und das Ergebnis ins Log geschrieben, aber nicht wirklich abgesetzt. Die debug level geben das anscheinend nicht her, oder hab ich das nur falsch verstanden? Ich kann mir aber auch sehr gut vorstellen dass das ein ziemlicher Aufwand sein kann....  Naja, der nächste Winter kommt bestimmt ;)
Eine konkrete Frage hab ich dann auch noch. Ich habe einige devices im Harmony Hub definiert für die keine activities hinterlegt sind. Diese setze ich über set harmony_deviceid command. Wenn ich das Wiki richtig verstanden habe, müsste ich im jeweiligen device die commands als webcmd hinterlegen um sie im MSwitch nutzen zu können. Andernfalls geht nur freecmd?

Gruß & Danke für Deine Arbeit!
Arthur

Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 13 September 2018, 20:52:57
Moin Byte09,
MSwitch schein DAS Modul zu sein mit dem ich meine, inzwischen etwas unübersichtliche, Fhem Installation wieder in den Griff bekommen könnte. Hab mich also durch das Wiki und den Foren Threat gelesen und mein erstes device angelegt und die bisherigen DOIF's und notifys deaktiviert. Hat soweit auch (fast) alles auf Anhieb funktioniert. Bis auf eine condition die falsch gesetzt war. Folge war, das Licht im Wohnzimmer brannte die ganze Nacht und ich habs erst heute morgen bemerkt :( Kurzer Blick ins Log und die Sache war klar. Kommt halt davon wenn man den Überblick verloren hat  ??? Ich fände es daher sehr hilfreich wenn es einen "testmode" gäbe mit dem man das device testen könnte, sprich die commands werden alle, wie definiert, abgearbeitet und das Ergebnis ins Log geschrieben, aber nicht wirklich abgesetzt. Die debug level geben das anscheinend nicht her, oder hab ich das nur falsch verstanden? Ich kann mir aber auch sehr gut vorstellen dass das ein ziemlicher Aufwand sein kann....  Naja, der nächste Winter kommt bestimmt ;)
Eine konkrete Frage hab ich dann auch noch. Ich habe einige devices im Harmony Hub definiert für die keine activities hinterlegt sind. Diese setze ich über set harmony_deviceid command. Wenn ich das Wiki richtig verstanden habe, müsste ich im jeweiligen device die commands als webcmd hinterlegen um sie im MSwitch nutzen zu können. Andernfalls geht nur freecmd?

Gruß & Danke für Deine Arbeit!
Arthur

hi arthur

das mit dem testmode ist , denke ich , eine ganz gute sache. ich arbeite im moment eh an einem 'grossen' update und werde das in irgend einer form einbauen , wird zwar nicht bis in den winter dauern , aber sicher noch einige tage.

zu den commands:

version 1: Freecmd

version 2: webcmd des devices

version 3 : im mswitch das attribut 'MSwitch_Activate_MSwitchcmds' auf 1.

damit hast du in allen deinen geräten das attribut 'MSwitchcmds' zur verfügung . dort kannst du die befehle analog zu webcmd ( z.b on:off ) eintragen , ohne z.B einer änderung der ansicht der devices, wie es bei webcmd natürlich erfolgt.

wenn du dann noch im MSwitch das attribut 'MSwitch_Include_MSwitchcmds' auf 1 setzt , hast du die befehle ebenfalls in entsprechendem geraät ( affected_device ) zur verfügung ( jedenfalls sollte es so sein  ;) )

gruss Byte09

PS: sorry, für die späte antwort, habe mir heute aber mal einen pc-freien abend gegönnt ( fast ) ...... eigentlich musste ich was für das familiäre bonuskonto tun  ;D ;D ;D
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 13 September 2018, 21:07:17
Hallo Byte09,

ich habe jetzt MSwitch_Condition_Time' auf 1 gesetzt, denn das ist was ich wollte. Danke!
Probieren werde ich es morgen.

PS: "urlaubsstatus" ziehe ich aus Google-Kalender und ist nicht in holiday sowie we hinterlegt.
Soll praktisch dynamisch-flexibel unkompliziert dazu kommen und so wirken als wäre es in der Holidaydatei  hinterlegt.

Panik

hi panik ,

hat es denn funktioniert ?

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: arthur_dent_2015 am 14 September 2018, 14:22:31
Hi Byte,
der PC-freie Abend sei Dir gegönnt! Keiner erwartet von Dir dass Du innerhalb von n Minuten hier antwortest! Als user freut man sich ja mittlerweile schon wenn man überhaupt eine Antwort bekommt ;)

Das Problem mit den Harmony devices ist ja schon dass ich sie überhaupt nicht zur Auswahl angeboten bekomme :( Es handelt sich um die vom Hub per autocreate angelegten devices. Die devices haben nicht einmal readings, die commands bekommt man nur per get commands vom Hub. Ist wohl eher eine Frage die ich im Mutimedia Bereich stellen müsste, Freecmd funktioniert ja...
Ne andere Frage noch, kann es sein dass, wenn ich attr MSwitch_Condition_Time 1 gesetzt habe und keine Zeit definiert ist, das Modul nie auslösen wird?
und warum hat diese MSwitch heute morgen ausgelöst?
#V V1.75
#S .Device_Affected -> atimer1-AbsCmd1,atimer2-AbsCmd1,test-AbsCmd1
#S .Device_Affected_Details -> atimer1-AbsCmd1,on,off,,,delay1,delay1,000003,000003,,,,,1|atimer2-AbsCmd1,on,off,,,delay1,delay1,000006,000006,,,,,1|test-AbsCmd1,on,off,,,delay1,delay1,000010,000010,,,,,1
#S .Device_Events -> state:off#[tr]state:on#[tr]no_trigger
#S .First_init -> done
#S .Trigger_Whitelist -> undef
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> no_trigger
#S .Trigger_condition ->
#S .Trigger_off -> state:off
#S .Trigger_on -> state:on
#S .Trigger_time ->
#S .V_Check -> V 1.2
#S Trigger_device -> Test
#S Trigger_log -> off
#S last_event -> test-AbsCmd1_conditionoff
#S state -> off
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Help -> 1
#A MSwitch_Delete_Delays -> 1
#A MSwitch_Inforoom -> MSwitch
#A MSwitch_Expert -> 0
#A MSwitch_Lock_Quickedit -> 1
#A room -> Test
#A MSwitch_Extensions -> 0
#A MSwitch_Debug -> 0
#A MSwitch_Include_Webcmds -> 0
#A MSwitch_Include_MSwitchcmds -> 0
#A MSwitch_Mode -> Full

2018.09.14 09:49:43 3: Events from device BM_HM_Sz:motion
2018.09.14 09:49:44 3: Test_MSwitch MSwitch_Notif: Befehlsausfuehrung -> set Test_MSwitch on state:on 2170
2018.09.14 09:49:44 3: Test_MSwitch Checkcondition - Parameter condition: 
2018.09.14 09:49:44 3: Test_MSwitch Checkcondition - Parameter event: state:on
2018.09.14 09:49:44 3: Test_MSwitch MSwitch_Set: conidtion ok - Befehl mt at/delay wird ausgefuehrt -> set atimer1 on  L:1312
2018.09.14 09:49:44 3: Test_MSwitch MSwitch_Set: teststateorg -> 000003 L:1317
2018.09.14 09:49:44 3: Test_MSwitch Checkcondition - Parameter condition: 
2018.09.14 09:49:44 3: Test_MSwitch Checkcondition - Parameter event: state:on
2018.09.14 09:49:44 3: Test_MSwitch MSwitch_Set: conidtion ok - Befehl mt at/delay wird ausgefuehrt -> set atimer2 on  L:1312
2018.09.14 09:49:44 3: Test_MSwitch MSwitch_Set: teststateorg -> 000006 L:1317
2018.09.14 09:49:44 3: Test_MSwitch Checkcondition - Parameter condition: 
2018.09.14 09:49:44 3: Test_MSwitch Checkcondition - Parameter event: state:on
2018.09.14 09:49:44 3: Test_MSwitch MSwitch_Set: conidtion ok - Befehl mt at/delay wird ausgefuehrt -> set test on  L:1312
2018.09.14 09:49:44 3: Test_MSwitch MSwitch_Set: teststateorg -> 000010 L:1317

Gruß
Arthur
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 14 September 2018, 16:12:43
hi arthur,

ok , jetzt habe ich es verstanden mit den harmonydevices - da geht im moment nur der weg über freecmd . wenn entsprechende nachfrage ist , werde ich da ggf. mal irgendetwas machen.


Zitat
Ne andere Frage noch, kann es sein dass, wenn ich attr MSwitch_Condition_Time 1 gesetzt habe und keine Zeit definiert ist, das Modul nie auslösen wird?

hier kann ich nicht ganz nachvollziehen , was du meinst . wenn keine zeit definiert ist löst es ja so der so nicht aus.

wenn das attribut gesetzt ist prüft er bei auslösung durch event und durch zeit entsprechende condition ( die kann jawas auch immer sein ) . wenn dieses attribut nicht gesetzt ist , prüft er nur eingehende events auf diese bedingung , zeitauslöser werden nicht auf die bedingung geprüft.
manuelles schalten wird ebenso nicht geprüft.
das mswitch kann ja , je nach bedarf, alles kombinieren.

um dirgenau zu sagen , warum das modul ausgelöst hat , habe ixh so nicht geniug daten. fakt ist aber, das du des mswitch in einen zustand gebracht hast , den es nicht geben dürfte ( und ich kann diesen auch nicht herbeiführen )  und daraus der schaltvorgang resultierte.

du hast keinen trigger angegeben , sondern nur schaltzeiten . im nächtsen feld hast du aber events angegeben , auf die reagiert werden soll ( diese konstellation ist so nicht vorgesehen , da es ja auch keinen sinn macht ) und sollte eigentlich nicht möglich sein.

in der kommenden version werde ich das zusätzlich überprüfen .  der spuk sollte aber vorbei sein , wenn du einfach nochmal 'modify trigger device ' drückst.

gruss Byte09



Titel: Antw:98_MSwitch - Support
Beitrag von: arthur_dent_2015 am 14 September 2018, 17:04:16
Hi Byte,
ich versuche es mal konkreter zu formulieren. Bei meinem ersten Versuch habe ich unter switch MSwitch on + execute 'cmd1' at : [20:00-05:00] und unter switch MSwitch on + execute 'cmd2' at : [05:00-20:00] gesetzt ohne attr MSwitch_Condition_Time 1 gesetzt zu haben. Prompt saß ich um 20 Uhr im dunklen :( Also hab ich die Zeiten gelöscht und war der Meinung jetzt reagiert das Modul nur auf die trigger closed bzw opened. Das hat bei closed auch funktioniert, aber auf opened am nächsten Morgen erfolgte keine Reaktion. Ich musste im Modul off setzen damit die commands abgesetzt werden. Gestern noch mal im Wiki gelesen und über MSwitch_Condition_Time gestolpert und ausprobiert. Das Licht blieb um 20 Uhr an  8) Allerdings löste dann der Trigger auch nicht aus und ich musste wieder im Modul on setzen. Das könnte aber mein Fehler gewesen sein, Taster zu lange gedrückt oder so. Heute Abend neuer Versuch ;)

fakt ist aber, das du des mswitch in einen zustand gebracht hast , den es nicht geben dürfte ( und ich kann diesen auch nicht herbeiführen ) 
Der Dau hat mal wieder sein bestes gegeben  :-[ :o 8) Ich lösch das Ding, sollte eh nur dazu da sein das Modul zu verstehen.

Wenn Du eh gerade eine größere Änderung an dem Modul machst, könntest Du vielleicht auch noch attr auf die todo Liste setzen. Ich habe einige notifys mit denen ich Geräte über Nacht, sie nicht im Netz sind oder ich nicht Zuhause bin, auf inactive setze um freezes zu vermeiden.

Ach ja, bekommt MSwitch den INITIALIZED vom global device mit? Den SHUTDOWN wohl mit Sicherheit. Aber wie reagiert Fhem wenn beim shutdown noch delays im MSwitch anstehen? Verzögern die den shutdown oder fährt Fhem einfach runter?

Gruß
Arthur
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 14 September 2018, 19:31:34
hi,

Zitat
Ach ja, bekommt MSwitch den INITIALIZED vom global device mit? Den SHUTDOWN wohl mit Sicherheit. Aber wie reagiert Fhem wenn beim shutdown noch delays im MSwitch anstehen? Verzögern die den shutdown oder fährt Fhem einfach runter?

bei einem shutdown werden alle delays, timer etc gelöscht´. Nach neustart werden ganz oben gesetzte auslösezeiten neu gesetzt ( oder berechnet ) . delays sind in diesem moment 'verloren' ( derzeitiger stand ) .

zu 'attr'

das möchte ich im grunde nur ungerne, da fremdattribute - denke ich - nicht von einem Modul geändert werden sollten.
was mit freecmd angestellt wird .... naja, steht ja jedem frei  ;)

so, und hier:

Zitat
ich versuche es mal konkreter zu formulieren. Bei meinem ersten Versuch habe ich unter switch MSwitch on + execute 'cmd1' at : [20:00-05:00] und unter switch MSwitch on + execute 'cmd2' at : [05:00-20:00] gesetzt ohne attr MSwitch_Condition_Time 1 gesetzt zu haben. Prompt saß ich um 20 Uhr im dunklen :( Also hab ich die Zeiten gelöscht und war der Meinung jetzt reagiert das Modul nur auf die trigger closed bzw opened. Das hat bei closed auch funktioniert, aber auf opened am nächsten Morgen erfolgte keine Reaktion. Ich musste im Modul off setzen damit die commands abgesetzt werden. Gestern noch mal im Wiki gelesen und über MSwitch_Condition_Time gestolpert und ausprobiert. Das Licht blieb um 20 Uhr an  8) Allerdings löste dann der Trigger auch nicht aus und ich musste wieder im Modul on setzen. Das könnte aber mein Fehler gewesen sein, Taster zu lange gedrückt oder so. Heute Abend neuer Versuch

läuft glaube ich etwas grundlegend quer :
MSwitch on + execute 'cmd2' at : [05:00-20:00]
das ist keine formatierung , mit der das modul umgehen kann .
schaltzeiten müssen konkret benannt werden :

[21:00][22:00] schaltet um 21 uhr und um 22 uhr
ergänzend kann hier auch $we oder sunset genutzt werden und ein wochentag angegeben werden.
[21:00|1][22:00|2] schaltet um 21 montags uhr und um 22 uhr dienstags
[21:00|1][22:00|$we] schaltet um 21 uhr und um 22 uhr am wochenende

es gibt nur 2 ausnahme mit anderem format:

[?20:00-21:00|5] - Zufälliger Schaltvorgang zwischen 20 Uhr und 21 Uhr am Freitag
[00:02*04:10-06:30] - Schaltvorgang alle 2 Minuten zwischen 4.10 Uhr und 6.30 Uhr


bei der condition hingegn kann dieses angegeben werden:
[05:00-20:00]

bedeutet erstmal nur , das alle events von einem device ( fallls zusätzlich als trigger definiert ) nur zwischen 05 uhr und 20 uhr überhaupt berücksichtigt werden . Zeitschaltungen werden aber weiterhin ausgeführt , d.h hier wird nicht auf diese bedingung geprüft.

erst besagtes attribut sorgt dafür, das auch zeitschaltungen auf diese bedingung geprüft wird. dabei muss es sich ja nicht um einen zeitraum handeln , sondern um ein reading etc. pp. [device:reading] eq "on/grün .... ".

ggf. hat diese zeitangabe [05:00-20:00] zu dem merkwürdigen verhalten geführt, da überprüfe ich nicht auf syntaxfehler. muss ich prüfen.


sag mir doch bitte mal , was du genau wie bezwecken willst .

gruss Byte09


Titel: Antw:98_MSwitch - Support
Beitrag von: arthur_dent_2015 am 14 September 2018, 22:02:01
nachem ich heute um 20 Uhr wieder im dunkeln saß, habe ich das Modul erst mal deaktiviert und das alte DOIF wieder aktiviert. Deine Antwort habe ich erst später gelesen. Ich bin halt davon ausgegangen Syntax stark an DOIF angelehnt, wird schon gehen. Okay, habe gelernt das geht hier nicht so.
Was ich erreichen will, relativ einfach. Mit dem Schalter ET1 wird nachts die halbe Wohnung stromlos und das Licht im Schlafzimmer geschaltet und das eben nicht versehentlich z.B. durch die Putze, tagsüber passieren.
Also, wenn ich Dich richtig verstehe muss ich die Zeiten bei jedem device in den conditions setzen?
zu 'attr'

das möchte ich im grunde nur ungerne, da fremdattribute - denke ich - nicht von einem Modul geändert werden sollten.
was mit freecmd angestellt wird .... naja, steht ja jedem frei  ;)
okay, kann ich verstehen. Über freecmd muss ich mal nachdenken. Die ganzen notifys, da verliert man irgendwann den Überblick wann und wo ein device inactiv und wieder active gesetzt wird.


bei einem shutdown werden alle delays, timer etc gelöscht´. Nach neustart werden ganz oben gesetzte auslösezeiten neu gesetzt ( oder berechnet ) . delays sind in diesem moment 'verloren' ( derzeitiger stand ) .

Okay, auch verstanden, kann ich meine Idee vergessen und was ist mit INITIALIZED, bekommt MSwitch das schon mit?

Gruß
Arthur
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 15 September 2018, 07:08:20
nachem ich heute um 20 Uhr wieder im dunkeln saß, habe ich das Modul erst mal deaktiviert und das alte DOIF wieder aktiviert. Deine Antwort habe ich erst später gelesen. Ich bin halt davon ausgegangen Syntax stark an DOIF angelehnt, wird schon gehen. Okay, habe gelernt das geht hier nicht so.
Was ich erreichen will, relativ einfach. Mit dem Schalter ET1 wird nachts die halbe Wohnung stromlos und das Licht im Schlafzimmer geschaltet und das eben nicht versehentlich z.B. durch die Putze, tagsüber passieren.
Also, wenn ich Dich richtig verstehe muss ich die Zeiten bei jedem device in den conditions setzen? okay, kann ich verstehen. Über freecmd muss ich mal nachdenken. Die ganzen notifys, da verliert man irgendwann den Überblick wann und wo ein device inactiv und wieder active gesetzt wird.
Okay, auch verstanden, kann ich meine Idee vergessen und was ist mit INITIALIZED, bekommt MSwitch das schon mit?

Gruß
Arthur


hier ein configfile eines MSwitches , das auf INITIALIZED reagiert. In diesem Beispeil wird bei init nur ein logeintrag geschrieben .
( geh in einem neuen mswitch auf get_config , dort das file einsetzen und speichern drücken.

#V V1.75
#S .Device_Affected -> FreeCmd-AbsCmd1
#S .Device_Affected_Details -> FreeCmd-AbsCmd1,cmd,cmd,{[cnl]Log3(~"test"#[ko]~0#[ko]~"Fhem~wurde~initialisiert"~)[se][cnl]},,delay1,delay1,000000,000000,,,,,1
#S .Device_Events ->
#S .First_init -> done
#S .Trigger_Whitelist -> undef
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> INITIALIZED
#S .Trigger_condition -> [$EVENT]#[sp]=#[ti]#[sp]m/INITIALIZED(#[pt]*)/
#S .Trigger_off -> no_trigger
#S .Trigger_on -> no_trigger
#S .Trigger_time ->
#S .V_Check -> V 1.2
#S Trigger_device -> global
#S Trigger_log -> on
#S last_event -> INITIALIZED
#S state -> off
#A MSwitch_Extensions -> 0
#A MSwitch_Include_MSwitchcmds -> 0
#A MSwitch_Inforoom -> MSwitch
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A MSwitch_Delete_Delays -> 1
#A MSwitch_Expert -> 1
#A MSwitch_Mode -> Full
#A room -> 1_Test
#A MSwitch_Safemode -> 1
#A MSwitch_Include_Webcmds -> 0
#A MSwitch_Help -> 0
#A MSwitch_Debug -> 0
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Lock_Quickedit -> 1
#A MSwitch_Startdelay -> 0

2 besonderheiten: das mswich triggert hier auf den eintrag GLOBAL - konket auf INITILIZED. diesen eintrag in der Liste bekommst du nur dann , wenn das MSwitch im Expertenmodus ist ( attr MSwitch_Expert 1 ).
weiterhin reagiert das MSwitch hier schon auf alle während der startphase anfallende events. das tut es normalerweise nicht , sondern nimmt erst 1 minute nach fhemstart seine arbeit auf. um das zu erreichen , muss das attr 'MSwitch_Startdelay' auf 0 gesetzt werden.

zu deiner stromlosschaltung -  das ist glaube ich einfacher als du es gerade versuchst:
im anhang ein bild zur verdeutlichung. des gerät xioamibuttons entspricht deinem schalter ET1. wenn dieser og on geschaltet wird, wird der schaltzweig cmd1 ausgelöst ( event state:on) , enntsprechend für off des schalters. Auf den schalter wird aber nur zwischen 20 uhr und 8 uhr reagiert (Trigger condition (events only): ) .

zeitgesteuert wird der cmd1 um 8 uhr ausgelöst , der cmd2 um 20 uhr , diese schaltvorgänge werden immer ausgelöst , unabhängig von diesem Feld (Trigger condition (events only): )  .

wbei du die zeitgesteuerten schaltvorgönge in diesem fallja gar nicht brauchst, du willst ja über den schalter ab/anschalten. dann lass die 2 zeilen mit den zeiten einfach leer , aber den  (Trigger condition (events only): ) lass gesetzt , damit der schalter nur in den angegebenen zeiten reagiert.

was du dann in den affected devices für die schaltvorgänge für devices und aktionen einsetzt ist hier ja erstmal egal.

gruss Byte09

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Torsten_MG am 15 September 2018, 08:43:43
Gibt es eine möglichkeit den Log von einem speziellem MSwitch separat zu loggen? Mein Logfile ist ziemlich voll und meine Fam. sagt immer wieder das es probleme mit einer Schaltung gibt. Es würde eine Lampe immer wieder aus und angehen obwohl nur 1x eingeschaltet wurde. Würde gerne den MSwitch über mehrere std. isoliert loggen um zu sehen woran es liegen könnte. Ob es z.b. am MSwitch liegt oder an was anderem.

Im Log der Lampe wird nämlich angezeigt, das die Lampe immer wieder on/off gesetzt wird. Die Lampe ist eine Ikea Tradfri und wird über zigbee2mqtt angesteuert.

2018-09-15_07:59:02 BD_Lampe on
2018-09-15_07:59:04 BD_Lampe transmission-state: incoming publish received
2018-09-15_07:59:04 BD_Lampe on
2018-09-15_07:59:09 BD_Lampe transmission-state: incoming publish received
2018-09-15_07:59:09 BD_Lampe off
2018-09-15_07:59:15 BD_Lampe on
2018-09-15_07:59:15 BD_Lampe transmission-state: incoming publish received
2018-09-15_07:59:15 BD_Lampe on
2018-09-15_07:59:36 BD_Lampe off
2018-09-15_07:59:44 BD_Lampe transmission-state: incoming publish received
2018-09-15_07:59:44 BD_Lampe off
2018-09-15_08:01:57 BD_Lampe on
2018-09-15_08:02:41 BD_Lampe off
2018-09-15_08:02:43 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:02:43 BD_Lampe off
2018-09-15_08:02:58 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:02:58 BD_Lampe OFF
2018-09-15_08:03:19 BD_Lampe on
2018-09-15_08:03:34 BD_Lampe off
2018-09-15_08:03:35 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:03:35 BD_Lampe ON
2018-09-15_08:03:36 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:03:36 BD_Lampe off
2018-09-15_08:03:36 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:03:36 BD_Lampe OFF
2018-09-15_08:03:44 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:03:44 BD_Lampe OFF
2018-09-15_08:06:00 BD_Lampe on
2018-09-15_08:06:02 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:06:02 BD_Lampe ON
2018-09-15_08:06:02 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:06:02 BD_Lampe on
2018-09-15_08:06:08 BD_Lampe off
2018-09-15_08:06:08 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:06:08 BD_Lampe off
2018-09-15_08:06:10 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:06:10 BD_Lampe OFF
2018-09-15_08:06:21 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:06:21 BD_Lampe OFF
2018-09-15_08:09:41 BD_Lampe on
2018-09-15_08:09:41 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:09:41 BD_Lampe on
2018-09-15_08:09:42 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:09:42 BD_Lampe ON
2018-09-15_08:09:48 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:09:48 BD_Lampe ON
2018-09-15_08:20:13 BD_Lampe off
2018-09-15_08:20:27 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:20:27 BD_Lampe off
2018-09-15_08:24:38 BD_Lampe on
2018-09-15_08:24:39 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:24:39 BD_Lampe on
2018-09-15_08:27:11 BD_Lampe off
2018-09-15_08:27:11 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:27:11 BD_Lampe off
2018-09-15_08:27:31 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:27:31 BD_Lampe OFF
2018-09-15_08:27:51 BD_Lampe on
2018-09-15_08:27:51 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:27:51 BD_Lampe on
2018-09-15_08:28:04 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:28:04 BD_Lampe ON
2018-09-15_08:28:30 BD_Lampe off
2018-09-15_08:28:36 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:28:36 BD_Lampe off
2018-09-15_08:28:41 BD_Lampe on
2018-09-15_08:28:44 BD_Lampe off
2018-09-15_08:28:45 BD_Lampe on
2018-09-15_08:28:45 BD_Lampe off
2018-09-15_08:28:45 BD_Lampe on
2018-09-15_08:28:46 BD_Lampe on
2018-09-15_08:28:52 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:28:52 BD_Lampe OFF
2018-09-15_08:28:53 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:28:53 BD_Lampe ON
2018-09-15_08:30:37 BD_Lampe off
2018-09-15_08:30:37 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:30:37 BD_Lampe off
2018-09-15_08:30:45 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:30:45 BD_Lampe OFF
2018-09-15_08:33:55 BD_Lampe on
2018-09-15_08:33:56 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:33:56 BD_Lampe ON
2018-09-15_08:33:56 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:33:56 BD_Lampe on
2018-09-15_08:37:11 BD_Lampe off
2018-09-15_08:37:11 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:37:11 BD_Lampe off
2018-09-15_08:37:12 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:37:12 BD_Lampe OFF
2018-09-15_08:37:15 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:37:15 BD_Lampe OFF
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 15 September 2018, 09:17:21
Gibt es eine möglichkeit den Log von einem speziellem MSwitch separat zu loggen? Mein Logfile ist ziemlich voll und meine Fam. sagt immer wieder das es probleme mit einer Schaltung gibt. Es würde eine Lampe immer wieder aus und angehen obwohl nur 1x eingeschaltet wurde. Würde gerne den MSwitch über mehrere std. isoliert loggen um zu sehen woran es liegen könnte. Ob es z.b. am MSwitch liegt oder an was anderem.

Im Log der Lampe wird nämlich angezeigt, das die Lampe immer wieder on/off gesetzt wird. Die Lampe ist eine Ikea Tradfri und wird über zigbee2mqtt angesteuert.

2018-09-15_07:59:02 BD_Lampe on
2018-09-15_07:59:04 BD_Lampe transmission-state: incoming publish received
2018-09-15_07:59:04 BD_Lampe on
2018-09-15_07:59:09 BD_Lampe transmission-state: incoming publish received
2018-09-15_07:59:09 BD_Lampe off
2018-09-15_07:59:15 BD_Lampe on
2018-09-15_07:59:15 BD_Lampe transmission-state: incoming publish received
2018-09-15_07:59:15 BD_Lampe on
2018-09-15_07:59:36 BD_Lampe off
2018-09-15_07:59:44 BD_Lampe transmission-state: incoming publish received
2018-09-15_07:59:44 BD_Lampe off
2018-09-15_08:01:57 BD_Lampe on
2018-09-15_08:02:41 BD_Lampe off
2018-09-15_08:02:43 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:02:43 BD_Lampe off
2018-09-15_08:02:58 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:02:58 BD_Lampe OFF
2018-09-15_08:03:19 BD_Lampe on
2018-09-15_08:03:34 BD_Lampe off
2018-09-15_08:03:35 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:03:35 BD_Lampe ON
2018-09-15_08:03:36 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:03:36 BD_Lampe off
2018-09-15_08:03:36 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:03:36 BD_Lampe OFF
2018-09-15_08:03:44 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:03:44 BD_Lampe OFF
2018-09-15_08:06:00 BD_Lampe on
2018-09-15_08:06:02 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:06:02 BD_Lampe ON
2018-09-15_08:06:02 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:06:02 BD_Lampe on
2018-09-15_08:06:08 BD_Lampe off
2018-09-15_08:06:08 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:06:08 BD_Lampe off
2018-09-15_08:06:10 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:06:10 BD_Lampe OFF
2018-09-15_08:06:21 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:06:21 BD_Lampe OFF
2018-09-15_08:09:41 BD_Lampe on
2018-09-15_08:09:41 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:09:41 BD_Lampe on
2018-09-15_08:09:42 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:09:42 BD_Lampe ON
2018-09-15_08:09:48 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:09:48 BD_Lampe ON
2018-09-15_08:20:13 BD_Lampe off
2018-09-15_08:20:27 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:20:27 BD_Lampe off
2018-09-15_08:24:38 BD_Lampe on
2018-09-15_08:24:39 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:24:39 BD_Lampe on
2018-09-15_08:27:11 BD_Lampe off
2018-09-15_08:27:11 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:27:11 BD_Lampe off
2018-09-15_08:27:31 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:27:31 BD_Lampe OFF
2018-09-15_08:27:51 BD_Lampe on
2018-09-15_08:27:51 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:27:51 BD_Lampe on
2018-09-15_08:28:04 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:28:04 BD_Lampe ON
2018-09-15_08:28:30 BD_Lampe off
2018-09-15_08:28:36 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:28:36 BD_Lampe off
2018-09-15_08:28:41 BD_Lampe on
2018-09-15_08:28:44 BD_Lampe off
2018-09-15_08:28:45 BD_Lampe on
2018-09-15_08:28:45 BD_Lampe off
2018-09-15_08:28:45 BD_Lampe on
2018-09-15_08:28:46 BD_Lampe on
2018-09-15_08:28:52 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:28:52 BD_Lampe OFF
2018-09-15_08:28:53 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:28:53 BD_Lampe ON
2018-09-15_08:30:37 BD_Lampe off
2018-09-15_08:30:37 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:30:37 BD_Lampe off
2018-09-15_08:30:45 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:30:45 BD_Lampe OFF
2018-09-15_08:33:55 BD_Lampe on
2018-09-15_08:33:56 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:33:56 BD_Lampe ON
2018-09-15_08:33:56 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:33:56 BD_Lampe on
2018-09-15_08:37:11 BD_Lampe off
2018-09-15_08:37:11 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:37:11 BD_Lampe off
2018-09-15_08:37:12 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:37:12 BD_Lampe OFF
2018-09-15_08:37:15 BD_Lampe transmission-state: incoming publish received
2018-09-15_08:37:15 BD_Lampe OFF

in dier aktuellen Version leider nicht . In der kommenden Version wird es so etwas geben, ich arbeite gerade daran , wird aber wohl noch ein paar tage dauern.

gruss Byte09

Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 15 September 2018, 16:01:43
auf mehrfachen Wunsch wird die Debug Funktion in der kommenden Version geändert sein.

Debug 0
Keine gesonderte Funktion

Debug 1
zusätzliche Einblendung von Testbuttons für Conditions, etc.

Debug 2
Portokollierung aller Aktionen des Devices in gesonderter Logdatei - Aktionen werden nur simuliert und nicht ausgeführt

Debug 3
normaler Ablauf incl. ausführung aller Schaltvorgänge . Es werden alle Aktionen in gesonderter Datei protokolliert.

Sat Sep 15 15:49:35 2018 Starte Log
Sat Sep 15 15:49:38 2018: -> ----------------------------------------
Sat Sep 15 15:49:38 2018: -> t: aufruf on/off -> off
Sat Sep 15 15:49:38 2018: -> ----------------------------------------
Sat Sep 15 15:49:38 2018: -> t: angesprochener zweig cmd1 -> device -> -HM_1F675D-AbsCmd1-
Sat Sep 15 15:49:38 2018: -> t: teste auf timerstatus -> 0
Sat Sep 15 15:49:38 2018: -> t: timerstatus nach test -> 0
Sat Sep 15 15:49:38 2018: -> t: befehl gefunden -> set HM_1F675D off
Sat Sep 15 15:49:38 2018: -> t: teste auf delay -> 0
Sat Sep 15 15:49:38 2018: -> t: teste auf condition -> wird nicht getestet - kein eintrag
Sat Sep 15 15:49:38 2018: -> t: ergebniss condition -> ergebniss true
Sat Sep 15 15:49:38 2018: -> t: in exec-cmdpool geschrieben ->set HM_1F675D off
Sat Sep 15 15:49:38 2018: -> t: anzahl der auszufuehrenden befehle -> 1
Sat Sep 15 15:49:38 2018: -> t: uebergabe an sub execute
Sat Sep 15 15:49:38 2018: -> t:     execute -> set HM_1F675D off |HM_1F675D-AbsCmd1
Sat Sep 15 15:49:38 2018: -> t:     cmd nach decodierung -> set HM_1F675D off
Sat Sep 15 15:49:38 2018: -> t:     execute als fhemcode -> set HM_1F675D off

sieht im Device dann aus wi in angehangenem Screenshot.

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 16 September 2018, 12:35:20
Ich habe eine erste Version , der V2.0 soeben in das GIT gestellt. Wer möchte kann sie gerne testen. Feedback wäre hilfreich.

Vor dem Update auf diese Verion ist unbedingt ein Backup aller MSwitch-Devices zu machen , andernfalls gibt es kein zurück auf die atuelle Version im Falle eines Falles.

Nach dem Update ist zwingend ein Fhemneustart erforderlich .

In dieser Betaversion habe ich (aus sicherheitsgründen) das automatische anpassen der gespeicherten Daten deaktiviert, d.H es muss jedes Device manuell upgedatet werden. Ein entsprechender Button wird im Device angeboten. Solange ein Device nicht aktualisiert wurde ist es blockiert. ( siehe Bilder im Anhang )

Ein normales Fhemupdate überspielt diese Version wieder auf aktuelle version . Falls es Probleme mit dieser Version gibt kann insofern wieder auf die jetzt aktuelle Version umgestellt werden. Nach Rückspielung dieser Version muss ein Fhemneustart und danach ein 'Restore MSwitch_data all_devices' ausgeführt werden , damit sollte der aktuelle Stand wieder hergestellt sein.

Info: Der Debugmode 2 und 3 in der neuen verision ist Resourcenhungrig, d.H diese sollten wirklich nur eingesetzt werden , wenn es nötig ist . Der Debugmode 4 ist ein reiner Entwicklungsmode , auf den ich verschiedene Funktionen nach Bedarf lege. In der fertigen version wird dieser nicht mehr verfügbar sein.

einmaliges update über die Befehlszeile:
update all https://raw.githubusercontent.com/Byte009/FHEM-MSwitch/master/controls_mswitch.txt
Nochmal der Hinweis:
Es handelt sich um eine Testversion . Fehler (ggf. auch gravierende) sind nicht ausgeschlossen !

gruss Byte09

Edit:
Bekannte probleme:
Repeatfunktion fehlerhaft -> Fix V2.0 beta 1 - eingespielt 17.09.18 - 17:00
configfile fehlerhaft -> Fix V2.0 beta 2 - eingespielt 19.09.18 - 19:00
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 16 September 2018, 18:57:33
INFO:

bekanntes problem mit den modulen 21_OWSWITCH.pm und  21_OWLCD.pm.

diese werden von MSwitch nicht als schaltbare Devices erkannt . Das Problem ist nicht über das MSwitch-Modul lösbar. Falls jemand MSwitch in Verbindung mit diesen Modulen nutzen möchte -> bitte kurze nachfrage per PM

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Bäschdler am 20 September 2018, 14:21:25
Hallo,

jetzt habe ich endlich wieder Zeit gefunden mich um die (Um-)Programmierung auf dieses Modul zu kümmern. Ich habe vieles gefunden und es scheint wirklich DAS Modul für meine Anforderung zu sein. Danke an diese Stelle an Byte09.

Jetzt habe ich noch 2 Problemchen ungelöst:
Das MSwitch Device das ich angelegt habe (OG_WZ_ROLL_Balkon_Abschattung) lässt sich innerhalb des Moduls über entsprechende Parameter (in meinem Fall azimuth aus dem twilight Modul zwischen 100 und 230 bzw über 230) an- und wieder ausschalten. Wenn ich aber innerhalb des Moduls " [myLocation:azimuth]>100 AND [myLocation:azimuth]<230 AND [OG_WZROLL_Balkon_Abschattung:state] eq "off" " eintrage wird der Status nicht erkannt. Setze ich einen testdummy mit derselben Regel und trage " [myLocation:azimuth]>100 AND [myLocation:azimuth]<230 AND [testdummy:state] eq "off" " ein dann funktioniert es.
Was auch nicht funktioniert ist den pct-Wert des Rolladens auszuwerten. Dies habe ich mit " [myLocation:azimuth]>100 AND [myLocation:azimuth]<230 AND [OG_WZ_Roll_Balkon:pct]>5 " versucht aber diese Bedingung wird nie wahr.

Kann mir jemand sagen was ich anders machen muss, dass diese beiden Dinge funktionieren ?


Danke für eure Hilfe

Viele Grüsse
Bäschdler
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 20 September 2018, 16:05:31
Hallo,

jetzt habe ich endlich wieder Zeit gefunden mich um die (Um-)Programmierung auf dieses Modul zu kümmern. Ich habe vieles gefunden und es scheint wirklich DAS Modul für meine Anforderung zu sein. Danke an diese Stelle an Byte09.

Jetzt habe ich noch 2 Problemchen ungelöst:
Das MSwitch Device das ich angelegt habe (OG_WZ_ROLL_Balkon_Abschattung) lässt sich innerhalb des Moduls über entsprechende Parameter (in meinem Fall azimuth aus dem twilight Modul zwischen 100 und 230 bzw über 230) an- und wieder ausschalten. Wenn ich aber innerhalb des Moduls " [myLocation:azimuth]>100 AND [myLocation:azimuth]<230 AND [OG_WZROLL_Balkon_Abschattung:state] eq "off" " eintrage wird der Status nicht erkannt. Setze ich einen testdummy mit derselben Regel und trage " [myLocation:azimuth]>100 AND [myLocation:azimuth]<230 AND [testdummy:state] eq "off" " ein dann funktioniert es.
Was auch nicht funktioniert ist den pct-Wert des Rolladens auszuwerten. Dies habe ich mit " [myLocation:azimuth]>100 AND [myLocation:azimuth]<230 AND [OG_WZ_Roll_Balkon:pct]>5 " versucht aber diese Bedingung wird nie wahr.

Kann mir jemand sagen was ich anders machen muss, dass diese beiden Dinge funktionieren ?


Danke für eure Hilfe

Viele Grüsse
Bäschdler

Hi Bäschdler,

das sind leider zu wenig infos, um hier genau zu schauen was schief läuft. Schalte doch erstmal deas entsprechende MSwitch in den debugmodus ( attribut MSwitch_debug auf 1) . dann hast du entsprechende Felder, mit denen du die Conditions prüfen kannst , sieht dann so aus:

eingehender String:
[detdummy_1:pct] >7 AND [detdummy_1:state] eq "up"

If Anweisung Perl:
if (ReadingsVal('detdummy_1', 'pct', 'undef') >7 && ReadingsVal('detdummy_1', 'state', 'undef') eq "up"){$answer = 'true';} else {$answer = 'false';}

Bedingung ist Wahr und wird ausgeführt

States der geprüften Readings:
Reading: [detdummy_1:state] - Inhalt: up
Reading: [detdummy_1:pct] - Inhalt: 8

ggf. kannst du ja hier schon sehen , ob estwas nicht stimmt.

ansonsten gib mir bitte mal ein configfile des devices ( get DEVICE get_config) und ggf. ein list des devices, dessen zustand nicht erkannt wird.

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Bäschdler am 21 September 2018, 13:46:37
Hallo,

(gefühlt) habe ich seit ich das erste Mal den Debug-Mode eingeschaltet habe, dass mir das Logfile überläuft. Letzten Monat war es ein paar hundert kByte gross, diesen Monat hat es stolze 450 MByte.

Kann man da was einstellen, dass da nicht so viele Meldungen generiert werden?

Danke und Grüsse
Bäschdler
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 21 September 2018, 16:07:13
Hallo,

(gefühlt) habe ich seit ich das erste Mal den Debug-Mode eingeschaltet habe, dass mir das Logfile überläuft. Letzten Monat war es ein paar hundert kByte gross, diesen Monat hat es stolze 450 MByte.

Kann man da was einstellen, dass da nicht so viele Meldungen generiert werden?

Danke und Grüsse
Bäschdler

auf was hast du denn das verbose der devices stehen ? stell die mal auf 1, dann werden nur Fehler protokolliert. der Debugmode hat in der von dir genutzten Version nicht mit dem Logfile zu tun .

Letztendlich empfehle ich dir eh ein update auf die Version 2.0 ( ein paar posts drüber ) .

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 23 September 2018, 08:13:15
update auf v2.00.

ab sofort ist die version 2.00 über das svn verfügbar.
diese version beinhaltet gravierende änderungen in der datenstruktur, d.H ich empfehle vor dem update ein backup der MSwitches.

- Debugmodus 2 und 3 protokollieren alle aktionen in einer eigenen datei . debug 3 sendet dabei keine Befehle , sondern simuliert lediglich

- in der auswahlliste der betroffenen geräte ist jetzt immer das device 'MSwitch_Self' zur auswahl vorhanden. d.H wenn sich das MSwitch selber schalten soll , kann hier immer dieses device gewählt werden. vorteil : bei einspielung eines configfiles muss keine anpassung erfolgen , wenn sich der name des devices geändert hat.

-auswahlfelder ID : bei setzten einer ID wird dieser befehl im normale ablauf nicht mehr berücksichtigt . Mit einer ID besetzte Befehle können aber aus den cmd-zweigen abgerufen werden . vorteil: erheblich mehr schaltmöglichkeiten , nicht mehr in direkter abhängigkeit von den schaltzweigen.

- änderung disable : das device kann nun auch bearbeitet werden , wenn es disabled ist

- editorfenster für 'get sysextension' : nur für sonderfunktionen

- configfiles geändert: configfiles können nun so angelegt werden , dass nach dem einspielen bestimmte geräteersetzungen etc. abgefragt werden . dieses mache einen support erheblich einfacher.

Achtung , alte Backups und Configfiles sind in dieser Version nicht mehr verwendbar.

gruss Byte09


edit: Zeitfenster verpasst , erst ab morgem im update   :( .
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 23 September 2018, 16:59:52
die aktuelle Version ist jetzt auch im GIT verfügbar.

update all https://raw.githubusercontent.com/Byte009/FHEM-MSwitch/master/controls_mswitch.txt
nach update ist ein fhemneustart zwingend notwendig !

gruss Byte09

Titel: Antw:98_MSwitch - Support
Beitrag von: Bäschdler am 23 September 2018, 22:34:14
Hallo,

Zitat
auf was hast du denn das verbose der devices stehen ? stell die mal auf 1, dann werden nur Fehler protokolliert. der Debugmode hat in der von dir genutzten Version nicht mit dem Logfile zu tun .

Letztendlich empfehle ich dir eh ein update auf die Version 2.0 ( ein paar posts drüber ) .

Verbose war gar nicht als attribut gesetzt. Habe dann erst mal 1 eingestellt, da kam aber irgendwie auch mehr als nur Fehler und habe es jetzt mal auf 0 gesetzt. Jetzt kommt zwar gar nichts mehr im Logfile an, aber dafür wird's auch nicht dadurch unnötig gross ;-)

Jetzt funktioniert soweit alles so, wie ich es mir vorgestellt hatte :-)

Eine Frage hätte ich jetzt noch: In der Doku habe ich nichts über Ausdrücke in Klammer gelesen. Ich habe ein Konstrukt von "Bedingung1 AND Bedingung2 OR Bedingung1 AND Bedingung3" fände es aber viel hübscher wenn ich "Bedingung1 AND (Bedingung2 OR Bedingung3) schreiben könnte. Geht so was und wenn ja, wie muss ich das eintragen?


Habe eben ein Update auf die Version 2 gemacht, kann daher zu dieser Version noch nichts sagen.

Danke und Grüsse
Bäschdler
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 24 September 2018, 05:26:55
setze mal das attribut 'MSwitch_Help' auf 1, dann hast du vor jedem Feld ein Hilfebutton . dort ist entsprechende syntax beschrieben .

[19.10-23:00] AND ([Devicename:Reading] = 10 OR [Devicename:Reading] = 11)

... kannst du so schreiben.

letztendlich kannst du die klammern nach 'normalen' regeln setzen. mit den entsprechenden buttons 'check condition ' kannst du dir ansehen, was dabei herauskommt ( dafür attribut 'MSwitch_Debug' auf 1 setzen ) :

z.B.
[$EVENT] eq "IT_1527xac68c:state:on"  AND ([{ sunset("-5000") }-{ sunrise() }] OR [Motion_Control:Lux] < [Lux_Schwelle:state]) AND ([Kueche_Arbeitsplatte:state] eq "on" OR [Kueche_Dunsthaube:state] eq "on")
ansicht 'check condition':
eingehender String:
[$EVENT] eq "IT_1527xac68c:state:on" AND [Kueche_Arbeitsplatte:state] eq "off" AND [Kueche_Dunsthaube:state] eq "off" AND ([{ sunset("-5000") }-{ sunrise() }] OR [Motion_Control:Lux] < [Lux_Schwelle:state])

If Anweisung Perl:
if (ReadingsVal('Motion_Control', 'last_event', 'undef') eq "IT_1527xac68c:state:on" && ReadingsVal('Kueche_Arbeitsplatte', 'state', 'undef') eq "off" && ReadingsVal('Kueche_Dunsthaube', 'state', 'undef') eq "off" && ((1516728540 < 1516768740 && 1516768740 < 1516772400) || ReadingsVal('Motion_Control', 'Lux', 'undef') < ReadingsVal('Lux_Schwelle', 'state', 'undef'))){$answer = 'true';} else {$answer = 'false';}

If Anweisung Perl Klarzeiten:
if (ReadingsVal('Motion_Control', 'last_event', 'undef') eq "IT_1527xac68c:state:on" && ReadingsVal('Kueche_Arbeitsplatte', 'state', 'undef') eq "off" && ReadingsVal('Kueche_Dunsthaube', 'state', 'undef') eq "off" && ((18:29 < 05:39 && 05:39 < 06:40) || ReadingsVal('Motion_Control', 'Lux', 'undef') < ReadingsVal('Lux_Schwelle', 'state', 'undef'))){$answer = 'true';} else {$answer = 'false';}

Bedingung ist Wahr und wird ausgeführt

States der geprüften Readings:
Reading: [Lux_Schwelle:state] - Inhalt: 13
Reading: [Motion_Control:Lux] - Inhalt: 9
Reading: [Kueche_Dunsthaube:state] - Inhalt: off
Reading: [Kueche_Arbeitsplatte:state] - Inhalt: off
Reading: [Motion_Control:last_event] - Inhalt: IT_1527xac68c:state:on


gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 24 September 2018, 17:01:29
Codeschnipsel:

MSwitch-Configuration  um 'soft' zu dimmen.

Da ich doch einige Dimmer betreibe, die keine ramptime etc unterstützen , bzw nicht über register beinflussbar sind habe ich mal dieses MSwitch gebastelt, welches beliebige Dimmer soft dimmt. die Dimmgeschwindigkeit ist dabei über zwei dropdowns einstellbar ( siehe Bild ). Voraussetzung ist , das das Dimmdevice sowohl das reading ptc hat , als auch den Befehl set ptc ... versteht.

vorgehen : leeres MSwitch-Device erstellen , anhängenden Configfile einspielen - Frage nach zu dimmendem Device beantworten - fertig. Würde mich freuen , wenn es mal jemand testen würde. Umbau auf andere readings/sets ist möglich. Das Configfile benötigt mindestensdie Modulversion V2.0.


über die beiden dropdowns wird zum einen die Verzögerungszeit eingestellt , zum anderen die 'Dimmschritte' per durchlauf.

10 - 00:00:10 -alle 10 sekunden wird um 10% gedimmt

Bei entsprechender restlicher Systemkonfiguration ( genericDeviceType-light etc. ) ist dieses Device direkt über Alexa ansprechbar : Schalte Device XX%


PS:In einer Variante dieses Devices betreibe ich auch meine Tradfri etc. Lampen (MQTT) . Diese Version hat einen 'vogeschalteten' Linearschalter, da diese über MQTT einen Dimmbereich von 0 - 256 haben , Alexa z.B aber nur bis 100% versteht ( glaube ich ). Bei Interesse oder Bedarf -> kurze Anfrage hier.

#I Achtung, des zu steuernde Device muss das Reading ptc haben und über set DEVICE ptc WERT angesteuert werden können !
#Q HM_1F675D#bitte dieses Device gegen ein vorhandenes Dimmer-Device ersetzen :#device
#V V2.00
#VS V2.00
#S .Device_Affected -> FreeCmd-AbsCmd1,FreeCmd-AbsCmd2,HM_1F675D-AbsCmd1,MSwitch_Self-AbsCmd1
#S .Device_Affected_Details -> FreeCmd-AbsCmd1#[NF]cmd#[NF]cmd#[NF]{;;my $ziel = ReadingsVal("$SELF","ziel",0); # bis wohin gedimmt werden soll;;my $ist = ReadingsVal("HM_1F675D","pct",0); # zustand der lampe;;;my $steps = ReadingsVal("$SELF","steps",1); # dimmschritte pro durchgang;;Log3( "SELF", 5, "SELF: ziel ".$ziel );;;Log3( "SELF", 5, "SELF: ist ".$ist );;;if ($ist == $ziel ) # lösche wiederholung wenn ziel erreicht;; {;; fhem("set $SELF del_delays");;; return;;; };;if ($ziel > $ist );;{;;# setze zustand der lampe - steps;;$ist = $ist + $steps;;;$ist =int($ist);;;   if ($ziel < $ist );;   {;;   $ist = $ziel;;;   };;};;if ($ziel < $ist );;{;;# setze zustand der lampe - steps;;$ist = $ist - $steps; ;;$ist =int($ist);;;   if ($ziel > $ist );;   {;;   $ist = $ziel;;;   };;};;Log3( "SELF", 5, "SELF: SETTING ".$ist );;;fhem("set HM_1F675D pct $ist");;;}#[NF]#[NF]delay1#[NF]delay1#[NF]00:00:00#[NF]00:00:00#[NF]#[NF]#[NF]0#[NF]0#[NF]3#[NF]0#[ND]FreeCmd-AbsCmd2#[NF]cmd#[NF]cmd#[NF]setreading $SELF ziel [$SELF:Parameter]#[NF]set $SELF del_delays#[NF]delay1#[NF]delay1#[NF]00:00:00#[NF]00:00:00#[NF]#[NF]#[NF]#[NF]#[NF]1#[NF]0#[ND]HM_1F675D-AbsCmd1#[NF]no_action#[NF]off#[NF]#[NF]#[NF]delay1#[NF]delay1#[NF]00:00:00#[NF]00:00:00#[NF]#[NF]#[NF]#[NF]#[NF]4#[NF]0#[ND]MSwitch_Self-AbsCmd1#[NF]exec_cmd1#[NF]no_action#[NF]#[NF]#[NF]delay1#[NF]delay1#[NF][$SELF:seconds]#[NF]00:00:00#[NF]#[NF]#[NF]#[NF]#[NF]2#[NF]0
#S .Device_Events -> no_trigger
#S .First_init -> done
#S .Trigger_Whitelist -> undef
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> no_trigger
#S .Trigger_condition -> undef
#S .Trigger_off -> no_trigger
#S .Trigger_on -> no_trigger
#S .Trigger_time -> undef
#S .V_Check -> V2.00
#S Trigger_device -> no_trigger
#S Trigger_log -> off
#S last_event -> MSwitch_Self-AbsCmd1_conditionon
#S .sysconf -> #test#[se]#[nl]#[nl]$special="pct#[dp]slider#[ko]0#[ko]1#[ko]100#[sp]steps#[dp]1#[ko]2#[ko]3#[ko]4#[ko]5#[ko]6#[ko]7#[ko]8#[ko]9#[ko]10#[sp]seconds#[dp]00#[dp]00#[dp]01#[ko]00#[dp]00#[dp]02#[ko]00#[dp]00#[dp]03#[ko]00#[dp]00#[dp]04#[ko]00#[dp]00#[dp]05#[ko]00#[dp]00#[dp]06#[ko]00#[dp]00#[dp]07#[ko]00#[dp]00#[dp]08#[ko]00#[dp]00#[dp]09#[ko]00#[dp]00#[dp]10#[ko]00#[dp]00#[dp]30"#[sp]#[se]#[nl]#[nl]#[nl]#[nl]if#[sp]($cmd#[sp]eq#[sp]"steps")#[nl]{#[nl]MSwitch_LOG(#[sp]$name#[ko]#[sp]5#[ko]#[sp]"setting#[sp]STEPS#[sp]#[dp]#[sp]$cmd#[sp]$args[0]"#[sp])#[se]#[nl]readingsSingleUpdate(#[sp]$hash#[ko]#[sp]"steps"#[ko]#[sp]$args[0]#[ko]#[sp]1#[sp])#[se]#[nl]return#[sp]"exit"#[se]#[nl]}#[nl]#[nl]if#[sp]($cmd#[sp]eq#[sp]"seconds")#[nl]{#[nl]MSwitch_LOG(#[sp]$name#[ko]#[sp]5#[ko]#[sp]"setting#[sp]STEPS#[sp]#[dp]#[sp]$cmd#[sp]$args[0]"#[sp])#[se]#[nl]readingsSingleUpdate(#[sp]$hash#[ko]#[sp]"seconds"#[ko]#[sp]$args[0]#[ko]#[sp]1#[sp])#[se]#[nl]return#[sp]"exit"#[se]#[nl]}#[nl]#[nl]#[nl]#[nl]if#[sp]($cmd#[sp]eq#[sp]"on"#[sp]#[wa]#[wa]#[sp]$cmd#[sp]eq#[sp]"off"#[sp]#[wa]#[wa]#[sp]$cmd#[sp]eq#[sp]"pct")#[nl]{#[nl]$args[0]#[sp]=""#[sp]if#[sp]#[sp]!defined#[sp]$args[0]#[se]#[nl]my#[sp]$arg#[sp]=#[sp]$args[0]#[se]#[nl]#[sp]if#[sp]($cmd#[sp]eq#[sp]"on"#[sp]#[wa]#[wa]#[sp]$cmd#[sp]eq#[sp]"off"#[sp]#[sp]#[wa]#[wa]#[sp]$cmd#[sp]eq#[sp]"pct")#[nl]#[sp]{#[nl]#[sp]if#[sp]($cmd#[sp]eq#[sp]"pct"#[sp]&&#[sp]$arg#[sp]eq#[sp]#[st]0#[st])#[nl]#[sp]{#[nl]#[sp]$cmd#[sp]=#[st]off#[st]#[se]#[nl]#[sp]#[sp]}#[nl]if#[sp]($cmd#[sp]eq#[sp]"pct"#[sp]&&#[sp]$arg#[sp]ne#[sp]#[st]0#[st])#[nl]{#[nl]$cmd#[sp]=#[st]on#[st]#[se]#[nl]}#[sp]#[sp]#[sp]#[nl]#[sp]if#[sp](#[sp]$cmd#[sp]eq#[sp]#[st]on#[st]#[sp]&&#[sp]$arg#[sp]eq#[sp]#[st]#[st])#[nl]{#[nl]$args[0]#[sp]=#[sp]ReadingsVal(#[sp]$name#[ko]#[sp]#[st]pct#[st]#[ko]#[sp]100)#[se]#[nl]}#[nl]#[nl]if#[sp](#[sp]$cmd#[sp]eq#[sp]#[st]off#[st]#[sp]&&#[sp]$arg#[sp]eq#[sp]#[st]#[st]#[sp]#[sp]#[sp]#[sp])#[nl]{#[nl]$args[0]#[sp]=#[sp]0#[se]#[nl]}#[nl]readingsSingleUpdate(#[sp]$hash#[ko]#[sp]"pct"#[ko]#[sp]$args[0]#[ko]#[sp]1#[sp])#[se]#[nl]}#[nl]}#[nl]#[nl]#[nl]return#[sp]"end"#[se]#[nl]#[nl]
#S state -> on
#S Sys_Extension -> on
#A MSwitch_Expert -> 1
#A webCmd -> on:off:pct:steps:seconds
#A MSwitch_Debug -> 0
#A disable -> 0
#A MSwitch_Include_Webcmds -> 1
#A MSwitch_Delete_Delays -> 0
#A room -> 1_Test
#A MSwitch_Extensions -> 0
#A MSwitch_Lock_Quickedit -> 1
#A MSwitch_Mode -> Full
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A MSwitch_Help -> 0
#A MSwitch_Include_MSwitchcmds -> 0
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Safemode -> 0

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Esjay am 24 September 2018, 21:00:04
Nabend Byte,
Hast du zufällig etwas an dem Modul geändert zwecks der verwendung der Pipes?
#V V1.74
#S .Device_Affected -> Flur-AbsCmd1,ReceiverAxBox4K-AbsCmd1,TelegramBot-AbsCmd1
#S .Device_Affected_Details -> Flur-AbsCmd1,Speak,no_action,45~de~#[wa]Ton#[wa]~Am~[myAbfall.next_weekday]~wird~[ArtikelMuell.state]~[myAbfall.next_text]~abgeholt~heute~ist~[Wochentag.state],,delay1,delay1,000000,000000,[Haus#[dp]state]#[sp]eq#[sp]"home",000000,home~eq~"home",0,1|ReceiverAxBox4K-AbsCmd1,showText,no_action,Am~[myAbfall.next_weekday]~wird~[ArtikelMuell.state]~[myAbfall.next_text]~abgeholt~heute~ist~[Wochentag.state],,delay1,delay1,000000,000000,[Haus#[dp]state]#[sp]eq#[sp]"home",,,,1|TelegramBot-AbsCmd1,msg,no_action,@#Home~Am~[myAbfall.next_weekday]~wird~[ArtikelMuell.state]~[myAbfall.next_text]~abgeholt~heute~ist~[Wochentag.state],,delay1,delay1,000000,000000,[Haus#[dp]state]#[sp]ne#[sp]"home",,,,1
#S .Device_Events -> no_trigger
#S .First_init -> done
#S .Trigger_Whitelist -> undef
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> no_trigger
#S .Trigger_condition ->
#S .Trigger_off -> no_trigger
#S .Trigger_on -> no_trigger
#S .Trigger_time -> on[18:30][19:30][20:30]~off~ononly~offonly
#S .V_Check -> V 1.2
#S Trigger_device -> no_trigger
#S Trigger_log -> off
#S last_event -> undef
#S state -> on
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Help -> 1
#A MSwitch_Include_MSwitchcmds -> 0
#A MSwitch_Extensions -> 0
#A MSwitch_Expert -> 0
#A MSwitch_Include_Webcmds -> 0
#A MSwitch_Delete_Delays -> 1
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A MSwitch_Mode -> Full
#A room -> MSwitch
#A MSwitch_Lock_Quickedit -> 1

Wenn ich den Command über "set Muelinfo exec_cmd1" ausführe ist alles in Ordnung.

Führt das Modul ihn über den Timer aus, kommt das bei raus.

Siehe Exec_cmd

Internals:
   NAME       MuellInfo
   NOTIFYDEV  no_trigger
   NR         284
   NTFY_ORDER 45-MuellInfo
   STATE      on
   TYPE       MSwitch
   Version    V1.74
   READINGS:
     2018-09-03 20:30:00   EVENT           MuellInfo:execute_timer_P1:20:30
     2018-09-03 20:30:00   EVTFULL         MuellInfo:execute_timer_P1:20:30
     2018-09-03 20:30:00   EVTPART1        MuellInfo
     2018-09-03 20:30:00   EVTPART2        execute_timer_P1
     2018-09-03 20:30:00   EVTPART3        20:30
     2018-09-03 20:30:00   Exec_cmd        set Flur Speak 45 de #[wa]Ton#[wa] Am [myAbfall:next_weekday] wird [ArtikelMuell:state] [myAbfall:ne....
     2018-09-03 20:15:26   Trigger_device  no_trigger
     2018-07-26 20:12:23   Trigger_log     off
     2018-09-03 20:30:00   state           on
   helper:
     conditioncheck if (ReadingsVal('Haus', 'state', 'undef') ne "home"){$answer = 'true';} else {$answer = 'false';}
     savemodeblock:
     timer:
       1535999400-1 1535999400-1
       1536012010 1536012010-5
Attributes:
   MSwitch_Delete_Delays 1
   MSwitch_Expert 0
   MSwitch_Extensions 0
   MSwitch_Help 1
   MSwitch_Ignore_Types notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
   MSwitch_Include_Devicecmds 1
   MSwitch_Include_MSwitchcmds 0
   MSwitch_Include_Webcmds 0
   MSwitch_Lock_Quickedit 1
   MSwitch_Mode Full
   room       MSwitch




Grüße

Moin Byte09,
Das Problem tritt wieder auf  :)

Codeschnipsel:

MSwitch-Configuration  um 'soft' zu dimmen.

Da ich doch einige Dimmer betreibe, die keine ramptime etc unterstützen , bzw nicht über register beinflussbar sind habe ich mal dieses MSwitch gebastelt, welches beliebige Dimmer soft dimmt. die Dimmgeschwindigkeit ist dabei über zwei dropdowns einstellbar ( siehe Bild ). Voraussetzung ist , das das Dimmdevice sowohl das reading ptc hat , als auch den Befehl set ptc ... versteht.

vorgehen : leeres MSwitch-Device erstellen , anhängenden Configfile einspielen - Frage nach zu dimmendem Device beantworten - fertig. Würde mich freuen , wenn es mal jemand testen würde. Umbau auf andere readings/sets ist möglich. Das Configfile benötigt mindestensdie Modulversion V2.0.


über die beiden dropdowns wird zum einen die Verzögerungszeit eingestellt , zum anderen die 'Dimmschritte' per durchlauf.

10 - 00:00:10 -alle 10 sekunden wird um 10% gedimmt

Bei entsprechender restlicher Systemkonfiguration ( genericDeviceType-light etc. ) ist dieses Device direkt über Alexa ansprechbar : Schalte Device XX%


PS:In einer Variante dieses Devices betreibe ich auch meine Tradfri etc. Lampen (MQTT) . Diese Version hat einen 'vogeschalteten' Linearschalter, da diese über MQTT einen Dimmbereich von 0 - 256 haben , Alexa z.B aber nur bis 100% versteht ( glaube ich ). Bei Interesse oder Bedarf -> kurze Anfrage hier.
.......
.
.
..
.
.
.
gruss Byte09

Funktioniert sehr gut. Schöne Sache in Verbindung mit Twilight.

Grüße

Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 24 September 2018, 21:30:17
Shit , da habe ich nicht aufgepasst .  Ist morgen früh im update behoben.

vorab im anhang

Gruss Byte09

Gesendet von meinem SM-G900F mit Tapatalk

edit: ich habe da probleme und muss mir das heute abend nochmal genauer anschauen.
Titel: Antw:98_MSwitch - Support
Beitrag von: Bäschdler am 25 September 2018, 15:27:21
Hi,

eine Frage noch: ich habe bisher bei einigen Fahrbefehlen einen manuellen Logbucheintrag mittels

trigger man_log_OG_Buero_Roll_Garten log "Rolladen Abschattung auf Position 60 % fahren"

erzeugt. Kann ich das auch mittels MSwitch machen und wenn ja wie?

Danke und Grüsse
Bäschdler
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 25 September 2018, 17:11:23
Hi,

eine Frage noch: ich habe bisher bei einigen Fahrbefehlen einen manuellen Logbucheintrag mittels

trigger man_log_OG_Buero_Roll_Garten log "Rolladen Abschattung auf Position 60 % fahren"

erzeugt. Kann ich das auch mittels MSwitch machen und wenn ja wie?

Danke und Grüsse
Bäschdler

solle es in das ganz 'normale' logfile geschrieben werden ? siehe anhang:

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Esjay am 26 September 2018, 18:06:40
Moin Byte,
kann es sein dass dein Modul die Trigger time einmalig einließt, und diesen Wert dann dauerhaft speichert?
Wenn ich in "switch MSwitch on + execute 'cmd1' at :" [Twilight:ss_astro] eintrage, trägt das Modul die Zeit im Klarform ein, und behält diese auch über die nächste Akualisierung des Twilight Device bei.

Grüße
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 26 September 2018, 20:12:12
Moin Byte,
kann es sein dass dein Modul die Trigger time einmalig einließt, und diesen Wert dann dauerhaft speichert?
Wenn ich in "switch MSwitch on + execute 'cmd1' at :" [Twilight:ss_astro] eintrage, trägt das Modul die Zeit im Klarform ein, und behält diese auch über die nächste Akualisierung des Twilight Device bei.

Grüße

servus,

ja genau sp ist es . in dem moment, wenn du modify trigger device drückst , werden die schaltzeiten für den gesamten tag gesetzt und abgearbeitet -24.00 uhr. kurz nach 24.00 werden alle zeiten für den nächsten tag gesetzt.

so wie du es nun nutzt sehe ich natürlich das problem. ich habe mich mit dem twilightmodul allerdings noch nicht auseinandergesetzt. wieoft und wann aktualisiert dieses denn diese daten ?

ich sehe auch im augenblick keine direkt lösung dafür, da es ja nunmal zeitgesteuert ist / nicht eventgesteuert . Insofern kann das device ja gar nicht mitbekommen , wenn diese zeit sich ändert.  das wird bei einem at oder ähnlichem im grunde wohl nicht anders sein können ( vermute ich - ich arbeite nicht mit at ) und wohl mit setzen des at dann auch statisch ( ggf. mit zyklischen aktualisierungen ) sein.

die einzige lösung , die ich anbieten könnte , wäre das du im selben mswitch das twilight als trigger definierst und er bei änderung twilightreadings die zeiten neu berechnest ( über ein cmd ) . den befehl 'reload-timer' o.Ä müsste ich aber erst einbauen , wäre aber keine grosse sache. würde das helfen ?

gruss Byte09

PS: die gesetzten zeiten kannst du übrigens mit get active_timer show abrufen.

Beispiel:
Systemzeit: Wed Sep 26 20:34:59 2018
Schaltzeiten (at - kommandos).
2018-09-26 21:00:00 switch MSwitch on + execute 'on' cmds
2018-09-26 21:05:00 switch MSwitch off + execute 'off' cmds
2018-09-27 00:00:10 neuberechnung aller Schaltzeiten

 
aktive Delays:

Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 26 September 2018, 20:32:13
mit der angehängten version wäre es lösbar.
edit: habe es in das svn übernommen

dazu muss allerdings ( um es sinnvoll zu gestalten ) ein zweites mswitch angelegt werden . dieses muss auf das device twilight triggern ( entsprechendes event ) und in den affected devices das mswitch-device welches aktualisiert werden soll mit 'set device reload_timer' aktualisieren.

wenn es unverständlich ist schicke ich dir gerne eine entsprechende config ( brauche dann aber ein list deines twiligts ).

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Esjay am 27 September 2018, 14:03:09
servus,

ja genau sp ist es . in dem moment, wenn du modify trigger device drückst , werden die schaltzeiten für den gesamten tag gesetzt und abgearbeitet -24.00 uhr. kurz nach 24.00 werden alle zeiten für den nächsten tag gesetzt.

so wie du es nun nutzt sehe ich natürlich das problem. ich habe mich mit dem twilightmodul allerdings noch nicht auseinandergesetzt. wieoft und wann aktualisiert dieses denn diese daten ?

ich sehe auch im augenblick keine direkt lösung dafür, da es ja nunmal zeitgesteuert ist / nicht eventgesteuert . Insofern kann das device ja gar nicht mitbekommen , wenn diese zeit sich ändert.  das wird bei einem at oder ähnlichem im grunde wohl nicht anders sein können ( vermute ich - ich arbeite nicht mit at ) und wohl mit setzen des at dann auch statisch ( ggf. mit zyklischen aktualisierungen ) sein.

die einzige lösung , die ich anbieten könnte , wäre das du im selben mswitch das twilight als trigger definierst und er bei änderung twilightreadings die zeiten neu berechnest ( über ein cmd ) . den befehl 'reload-timer' o.Ä müsste ich aber erst einbauen , wäre aber keine grosse sache. würde das helfen ?

gruss Byte09

PS: die gesetzten zeiten kannst du übrigens mit get active_timer show abrufen.

Beispiel:
Systemzeit: Wed Sep 26 20:34:59 2018
Schaltzeiten (at - kommandos).
2018-09-26 21:00:00 switch MSwitch on + execute 'on' cmds
2018-09-26 21:05:00 switch MSwitch off + execute 'off' cmds
2018-09-27 00:00:10 neuberechnung aller Schaltzeiten

 
aktive Delays:

Das twilight Modul aktualisiert sich um 00:00:03.

mit der angehängten version wäre es lösbar.
edit: habe es in das svn übernommen

dazu muss allerdings ( um es sinnvoll zu gestalten ) ein zweites mswitch angelegt werden . dieses muss auf das device twilight triggern ( entsprechendes event ) und in den affected devices das mswitch-device welches aktualisiert werden soll mit 'set device reload_timer' aktualisieren.

wenn es unverständlich ist schicke ich dir gerne eine entsprechende config ( brauche dann aber ein list deines twiligts ).

gruss Byte09

Nee alles gut, sonst gewöhnt man sich daran, sein Problemlöseverhalten auf andere abzuwälzen  ;). Ich habe gerade sowieso in den Kopf bekommen, mir eigene Helligkeitssensoren über LaCrosse zu bauen, daher wäre das wahrscheinlich Perlen vor die Säue.

Grüße
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 27 September 2018, 15:47:32
Das twilight Modul aktualisiert sich um 00:00:03.

Nee alles gut, sonst gewöhnt man sich daran, sein Problemlöseverhalten auf andere abzuwälzen  ;). Ich habe gerade sowieso in den Kopf bekommen, mir eigene Helligkeitssensoren über LaCrosse zu bauen, daher wäre das wahrscheinlich Perlen vor die Säue.

Grüße

somit 7 sekunden vor dem MSwitch. d.H eigentlich müsste er das geänderte reading berücksichtigen . werde mir das heute nacht mal anschauen.

die Lösung von oben habe ich übrigens eingecheckt.

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Esjay am 27 September 2018, 17:53:01
somit 7 sekunden vor dem MSwitch. d.H eigentlich müsste er das geänderte reading berücksichtigen . werde mir das heute nacht mal anschauen.

die Lösung von oben habe ich übrigens eingecheckt.

gruss Byte09

Besten Dank!
Sag mal, wo kann ich die Steps bzw. die Sekunden in deinem Dimmerbeispiel anpassen? Momentan ist das Limit ja bei 5 Minuten. Würde das gerne noch ein wenig strecken!

Grüße
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 27 September 2018, 21:22:47
Besten Dank!
Sag mal, wo kann ich die Steps bzw. die Sekunden in deinem Dimmerbeispiel anpassen? Momentan ist das Limit ja bei 5 Minuten. Würde das gerne noch ein wenig strecken!

Grüße
Geh mal im Device auf get get_sysextensions , da wirst du es schnell sehen . Aber in der Datei ist Vorsicht angesagt [emoji6]

Gruss Byte09

Gesendet von meinem SM-G900F mit Tapatalk

Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 28 September 2018, 05:54:03
Moin Byte,
kann es sein dass dein Modul die Trigger time einmalig einließt, und diesen Wert dann dauerhaft speichert?
Wenn ich in "switch MSwitch on + execute 'cmd1' at :" [Twilight:ss_astro] eintrage, trägt das Modul die Zeit im Klarform ein, und behält diese auch über die nächste Akualisierung des Twilight Device bei.

Grüße

ich habe eben nochmal ein fix in das svn gestellt, damit dürfte das problem gelöst sein. in betreffendem Device musst du aber die schaltzeit neu ein eingeben '[Twilight:ss_astro]' und speichern.

eine aktualisierung erfolgt dann immer um 00:00:10 uhr oder mit 'set reload_timer'.

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Esjay am 28 September 2018, 12:10:48
ich habe eben nochmal ein fix in das svn gestellt, damit dürfte das problem gelöst sein. in betreffendem Device musst du aber die schaltzeit neu ein eingeben '[Twilight:ss_astro]' und speichern.

eine aktualisierung erfolgt dann immer um 00:00:10 uhr oder mit 'set reload_timer'.

gruss Byte09

Ich danke dir! Werde das die nächsten Tage beobachten. Wie sieht es eigentlich mit einer automatischen Konvertierung von doif`s,notify`s und at`s in ein MSwitch aus? ;D ;)

Grüße
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 28 September 2018, 12:49:25
Ich danke dir! Werde das die nächsten Tage beobachten. Wie sieht es eigentlich mit einer automatischen Konvertierung von doif`s,notify`s und at`s in ein MSwitch aus? ;D ;)

Grüße
Hi,
 Hatte ich mal angedacht , gab es auch mal im Ansatz , habe ich aber wieder rausgenommen ... sagen wir mal aus einer Vielzahl von Gründen . Wobei doif auch sehr komplex sein kann , für notifys kein Thema .

Gruss Byte09

Gesendet von meinem SM-G900F mit Tapatalk

Titel: Antw:98_MSwitch - Support
Beitrag von: Esjay am 28 September 2018, 19:21:07
Moin Byte, kann es sein, dass ein rename das MSwitch durcheinander bringt?

2018.09.28 18:15:30 1: Logfile gelöscht
2018.09.28 18:15:46 1: ERROR: empty name in readingsBeginUpdate
2018.09.28 18:15:46 1: stacktrace:
2018.09.28 18:15:46 1:     main::readingsBeginUpdate           called by ./FHEM/98_MSwitch.pm (7069)
2018.09.28 18:15:46 1:     main::MSwitch_EventBulk             called by ./FHEM/98_MSwitch.pm (5408)
2018.09.28 18:15:46 1:     main::MSwitch_checkcondition        called by ./FHEM/98_MSwitch.pm (5296)
2018.09.28 18:15:46 1:     main::MSwitch_Restartcmd            called by fhem.pl (3140)
2018.09.28 18:15:46 1:     main::HandleTimeout                 called by fhem.pl (649)
2018.09.28 18:15:46 1: readingsUpdate(,EVENT,MSwitch_Self-AbsCmd1_conditionon) missed to call readingsBeginUpdate first.
2018.09.28 18:15:46 1: stacktrace:
2018.09.28 18:15:46 1:     main::readingsBulkUpdate            called by ./FHEM/98_MSwitch.pm (7070)
2018.09.28 18:15:46 1:     main::MSwitch_EventBulk             called by ./FHEM/98_MSwitch.pm (5408)
2018.09.28 18:15:46 1:     main::MSwitch_checkcondition        called by ./FHEM/98_MSwitch.pm (5296)
2018.09.28 18:15:46 1:     main::MSwitch_Restartcmd            called by fhem.pl (3140)
2018.09.28 18:15:46 1:     main::HandleTimeout                 called by fhem.pl (649)
2018.09.28 18:15:46 1: readingsUpdate(,EVTFULL,:MSwitch_Self-AbsCmd1_conditionon) missed to call readingsBeginUpdate first.
2018.09.28 18:15:46 1: stacktrace:
2018.09.28 18:15:46 1:     main::readingsBulkUpdate            called by ./FHEM/98_MSwitch.pm (7071)
2018.09.28 18:15:46 1:     main::MSwitch_EventBulk             called by ./FHEM/98_MSwitch.pm (5408)
2018.09.28 18:15:46 1:     main::MSwitch_checkcondition        called by ./FHEM/98_MSwitch.pm (5296)
2018.09.28 18:15:46 1:     main::MSwitch_Restartcmd            called by fhem.pl (3140)
2018.09.28 18:15:46 1:     main::HandleTimeout                 called by fhem.pl (649)
2018.09.28 18:15:46 1: readingsUpdate(,EVTPART2,MSwitch_Self-AbsCmd1_conditionon) missed to call readingsBeginUpdate first.
2018.09.28 18:15:46 1: stacktrace:
2018.09.28 18:15:46 1:     main::readingsBulkUpdate            called by ./FHEM/98_MSwitch.pm (7073)
2018.09.28 18:15:46 1:     main::MSwitch_EventBulk             called by ./FHEM/98_MSwitch.pm (5408)
2018.09.28 18:15:46 1:     main::MSwitch_checkcondition        called by ./FHEM/98_MSwitch.pm (5296)
2018.09.28 18:15:46 1:     main::MSwitch_Restartcmd            called by fhem.pl (3140)
2018.09.28 18:15:46 1:     main::HandleTimeout                 called by fhem.pl (649)
2018.09.28 18:15:46 1: readingsUpdate(,last_event,MSwitch_Self-AbsCmd1_conditionon) missed to call readingsBeginUpdate first.
2018.09.28 18:15:46 1: stacktrace:
2018.09.28 18:15:46 1:     main::readingsBulkUpdate            called by ./FHEM/98_MSwitch.pm (7075)
2018.09.28 18:15:46 1:     main::MSwitch_EventBulk             called by ./FHEM/98_MSwitch.pm (5408)
2018.09.28 18:15:46 1:     main::MSwitch_checkcondition        called by ./FHEM/98_MSwitch.pm (5296)
2018.09.28 18:15:46 1:     main::MSwitch_Restartcmd            called by fhem.pl (3140)
2018.09.28 18:15:46 1:     main::HandleTimeout                 called by fhem.pl (649)
2018.09.28 18:15:46 1: MSWohnzimmerDim MSwitch_Restartcmd :Fehler bei Befehlsausfuehrung  ERROR Please define exec_cmd1 first 5384
2018.09.28 18:15:46 1: ERROR: empty name in readingsBeginUpdate
2018.09.28 18:15:46 1: stacktrace:
2018.09.28 18:15:46 1:     main::readingsBeginUpdate           called by fhem.pl (4748)
2018.09.28 18:15:46 1:     main::readingsSingleUpdate          called by ./FHEM/98_MSwitch.pm (5389)
2018.09.28 18:15:46 1:     main::MSwitch_Restartcmd            called by fhem.pl (3140)
2018.09.28 18:15:46 1:     main::HandleTimeout                 called by fhem.pl (649)
2018.09.28 18:15:46 1: readingsUpdate(,Exec_cmd,set  exec_cmd1 ) missed to call readingsBeginUpdate first.
2018.09.28 18:15:46 1: stacktrace:
2018.09.28 18:15:46 1:     main::readingsBulkUpdate            called by fhem.pl (4749)
2018.09.28 18:15:46 1:     main::readingsSingleUpdate          called by ./FHEM/98_MSwitch.pm (5389)
2018.09.28 18:15:46 1:     main::MSwitch_Restartcmd            called by fhem.pl (3140)
2018.09.28 18:15:46 1:     main::HandleTimeout                 called by fhem.pl (649)
2018.09.28 18:24:56 1: ERROR: empty name in readingsBeginUpdate
2018.09.28 18:24:56 1: stacktrace:
2018.09.28 18:24:56 1:     main::readingsBeginUpdate           called by ./FHEM/98_MSwitch.pm (7069)
2018.09.28 18:24:56 1:     main::MSwitch_EventBulk             called by ./FHEM/98_MSwitch.pm (5408)
2018.09.28 18:24:56 1:     main::MSwitch_checkcondition        called by ./FHEM/98_MSwitch.pm (1430)
2018.09.28 18:24:56 1:     main::MSwitch_Set                   called by fhem.pl (3592)
2018.09.28 18:24:56 1:     main::CallFn                        called by fhem.pl (1807)
2018.09.28 18:24:56 1:     main::DoSet                         called by fhem.pl (1840)
2018.09.28 18:24:56 1:     main::CommandSet                    called by ./FHEM/98_cmdalias.pm (99)
2018.09.28 18:24:56 1:     main::CommandCmdAlias               called by fhem.pl (1214)
2018.09.28 18:24:56 1:     main::AnalyzeCommand                called by ./FHEM/01_FHEMWEB.pm (2583)
2018.09.28 18:24:56 1:     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (861)
2018.09.28 18:24:56 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (533)
2018.09.28 18:24:56 1:     main::FW_Read                       called by fhem.pl (3597)
2018.09.28 18:24:56 1:     main::CallFn                        called by fhem.pl (726)
2018.09.28 18:24:56 1: readingsUpdate(,EVENT,MSWohnzimmerDim:on_with_Parameter:100) missed to call readingsBeginUpdate first.
2018.09.28 18:24:56 1: stacktrace:
2018.09.28 18:24:56 1:     main::readingsBulkUpdate            called by ./FHEM/98_MSwitch.pm (7070)
2018.09.28 18:24:56 1:     main::MSwitch_EventBulk             called by ./FHEM/98_MSwitch.pm (5408)
2018.09.28 18:24:56 1:     main::MSwitch_checkcondition        called by ./FHEM/98_MSwitch.pm (1430)
2018.09.28 18:24:56 1:     main::MSwitch_Set                   called by fhem.pl (3592)
2018.09.28 18:24:56 1:     main::CallFn                        called by fhem.pl (1807)
2018.09.28 18:24:56 1:     main::DoSet                         called by fhem.pl (1840)
2018.09.28 18:24:56 1:     main::CommandSet                    called by ./FHEM/98_cmdalias.pm (99)
2018.09.28 18:24:56 1:     main::CommandCmdAlias               called by fhem.pl (1214)
2018.09.28 18:24:56 1:     main::AnalyzeCommand                called by ./FHEM/01_FHEMWEB.pm (2583)
2018.09.28 18:24:56 1:     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (861)
2018.09.28 18:24:56 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (533)
2018.09.28 18:24:56 1:     main::FW_Read                       called by fhem.pl (3597)
2018.09.28 18:24:56 1:     main::CallFn                        called by fhem.pl (726)
2018.09.28 18:24:56 1: readingsUpdate(,EVTFULL,MSWohnzimmerDim:on_with_Parameter:100) missed to call readingsBeginUpdate first.
2018.09.28 18:24:56 1: stacktrace:
2018.09.28 18:24:56 1:     main::readingsBulkUpdate            called by ./FHEM/98_MSwitch.pm (7071)
2018.09.28 18:24:56 1:     main::MSwitch_EventBulk             called by ./FHEM/98_MSwitch.pm (5408)
2018.09.28 18:24:56 1:     main::MSwitch_checkcondition        called by ./FHEM/98_MSwitch.pm (1430)
2018.09.28 18:24:56 1:     main::MSwitch_Set                   called by fhem.pl (3592)
2018.09.28 18:24:56 1:     main::CallFn                        called by fhem.pl (1807)
2018.09.28 18:24:56 1:     main::DoSet                         called by fhem.pl (1840)
2018.09.28 18:24:56 1:     main::CommandSet                    called by ./FHEM/98_cmdalias.pm (99)
2018.09.28 18:24:56 1:     main::CommandCmdAlias               called by fhem.pl (1214)
2018.09.28 18:24:56 1:     main::AnalyzeCommand                called by ./FHEM/01_FHEMWEB.pm (2583)
2018.09.28 18:24:56 1:     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (861)
2018.09.28 18:24:56 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (533)
2018.09.28 18:24:56 1:     main::FW_Read                       called by fhem.pl (3597)
2018.09.28 18:24:56 1:     main::CallFn                        called by fhem.pl (726)
2018.09.28 18:24:56 1: readingsUpdate(,EVTPART1,MSWohnzimmerDim) missed to call readingsBeginUpdate first.
2018.09.28 18:24:56 1: stacktrace:
2018.09.28 18:24:56 1:     main::readingsBulkUpdate            called by ./FHEM/98_MSwitch.pm (7072)
2018.09.28 18:24:56 1:     main::MSwitch_EventBulk             called by ./FHEM/98_MSwitch.pm (5408)
2018.09.28 18:24:56 1:     main::MSwitch_checkcondition        called by ./FHEM/98_MSwitch.pm (1430)
2018.09.28 18:24:56 1:     main::MSwitch_Set                   called by fhem.pl (3592)
2018.09.28 18:24:56 1:     main::CallFn                        called by fhem.pl (1807)
2018.09.28 18:24:56 1:     main::DoSet                         called by fhem.pl (1840)
2018.09.28 18:24:56 1:     main::CommandSet                    called by ./FHEM/98_cmdalias.pm (99)
2018.09.28 18:24:56 1:     main::CommandCmdAlias               called by fhem.pl (1214)
2018.09.28 18:24:56 1:     main::AnalyzeCommand                called by ./FHEM/01_FHEMWEB.pm (2583)
2018.09.28 18:24:56 1:     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (861)
2018.09.28 18:24:56 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (533)
2018.09.28 18:24:56 1:     main::FW_Read                       called by fhem.pl (3597)
2018.09.28 18:24:56 1:     main::CallFn                        called by fhem.pl (726)
2018.09.28 18:24:56 1: readingsUpdate(,EVTPART2,on_with_Parameter) missed to call readingsBeginUpdate first.
2018.09.28 18:24:56 1: stacktrace:
2018.09.28 18:24:56 1:     main::readingsBulkUpdate            called by ./FHEM/98_MSwitch.pm (7073)
2018.09.28 18:24:56 1:     main::MSwitch_EventBulk             called by ./FHEM/98_MSwitch.pm (5408)
2018.09.28 18:24:56 1:     main::MSwitch_checkcondition        called by ./FHEM/98_MSwitch.pm (1430)
2018.09.28 18:24:56 1:     main::MSwitch_Set                   called by fhem.pl (3592)
2018.09.28 18:24:56 1:     main::CallFn                        called by fhem.pl (1807)
2018.09.28 18:24:56 1:     main::DoSet                         called by fhem.pl (1840)
2018.09.28 18:24:56 1:     main::CommandSet                    called by ./FHEM/98_cmdalias.pm (99)
2018.09.28 18:24:56 1:     main::CommandCmdAlias               called by fhem.pl (1214)
2018.09.28 18:24:56 1:     main::AnalyzeCommand                called by ./FHEM/01_FHEMWEB.pm (2583)
2018.09.28 18:24:56 1:     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (861)
2018.09.28 18:24:56 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (533)
2018.09.28 18:24:56 1:     main::FW_Read                       called by fhem.pl (3597)
2018.09.28 18:24:56 1:     main::CallFn                        called by fhem.pl (726)
2018.09.28 18:24:56 1: readingsUpdate(,EVTPART3,100) missed to call readingsBeginUpdate first.
2018.09.28 18:24:56 1: stacktrace:
2018.09.28 18:24:56 1:     main::readingsBulkUpdate            called by ./FHEM/98_MSwitch.pm (7074)
2018.09.28 18:24:56 1:     main::MSwitch_EventBulk             called by ./FHEM/98_MSwitch.pm (5408)
2018.09.28 18:24:56 1:     main::MSwitch_checkcondition        called by ./FHEM/98_MSwitch.pm (1430)
2018.09.28 18:24:56 1:     main::MSwitch_Set                   called by fhem.pl (3592)
2018.09.28 18:24:56 1:     main::CallFn                        called by fhem.pl (1807)
2018.09.28 18:24:56 1:     main::DoSet                         called by fhem.pl (1840)
2018.09.28 18:24:56 1:     main::CommandSet                    called by ./FHEM/98_cmdalias.pm (99)
2018.09.28 18:24:56 1:     main::CommandCmdAlias               called by fhem.pl (1214)
2018.09.28 18:24:56 1:     main::AnalyzeCommand                called by ./FHEM/01_FHEMWEB.pm (2583)
2018.09.28 18:24:56 1:     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (861)
2018.09.28 18:24:56 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (533)
2018.09.28 18:24:56 1:     main::FW_Read                       called by fhem.pl (3597)
2018.09.28 18:24:56 1:     main::CallFn                        called by fhem.pl (726)
2018.09.28 18:24:56 1: readingsUpdate(,last_event,MSWohnzimmerDim:on_with_Parameter:100) missed to call readingsBeginUpdate first.
2018.09.28 18:24:56 1: stacktrace:
2018.09.28 18:24:56 1:     main::readingsBulkUpdate            called by ./FHEM/98_MSwitch.pm (7075)
2018.09.28 18:24:56 1:     main::MSwitch_EventBulk             called by ./FHEM/98_MSwitch.pm (5408)
2018.09.28 18:24:56 1:     main::MSwitch_checkcondition        called by ./FHEM/98_MSwitch.pm (1430)
2018.09.28 18:24:56 1:     main::MSwitch_Set                   called by fhem.pl (3592)
2018.09.28 18:24:56 1:     main::CallFn                        called by fhem.pl (1807)
2018.09.28 18:24:56 1:     main::DoSet                         called by fhem.pl (1840)
2018.09.28 18:24:56 1:     main::CommandSet                    called by ./FHEM/98_cmdalias.pm (99)
2018.09.28 18:24:56 1:     main::CommandCmdAlias               called by fhem.pl (1214)
2018.09.28 18:24:56 1:     main::AnalyzeCommand                called by ./FHEM/01_FHEMWEB.pm (2583)
2018.09.28 18:24:56 1:     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (861)
2018.09.28 18:24:56 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (533)
2018.09.28 18:24:56 1:     main::FW_Read                       called by fhem.pl (3597)
2018.09.28 18:24:56 1:     main::CallFn                        called by fhem.pl (726)
2018.09.28 18:26:56 1: ERROR: empty name in readingsBeginUpdate
2018.09.28 18:26:56 1: stacktrace:
2018.09.28 18:26:56 1:     main::readingsBeginUpdate           called by ./FHEM/98_MSwitch.pm (7069)
2018.09.28 18:26:56 1:     main::MSwitch_EventBulk             called by ./FHEM/98_MSwitch.pm (5408)
2018.09.28 18:26:56 1:     main::MSwitch_checkcondition        called by ./FHEM/98_MSwitch.pm (5296)
2018.09.28 18:26:56 1:     main::MSwitch_Restartcmd            called by fhem.pl (3140)
2018.09.28 18:26:56 1:     main::HandleTimeout                 called by fhem.pl (649)
2018.09.28 18:26:56 1: readingsUpdate(,EVENT,MSwitch_Self-AbsCmd1_conditionon) missed to call readingsBeginUpdate first.
2018.09.28 18:26:56 1: stacktrace:
2018.09.28 18:26:56 1:     main::readingsBulkUpdate            called by ./FHEM/98_MSwitch.pm (7070)
2018.09.28 18:26:56 1:     main::MSwitch_EventBulk             called by ./FHEM/98_MSwitch.pm (5408)
2018.09.28 18:26:56 1:     main::MSwitch_checkcondition        called by ./FHEM/98_MSwitch.pm (5296)
2018.09.28 18:26:56 1:     main::MSwitch_Restartcmd            called by fhem.pl (3140)
2018.09.28 18:26:56 1:     main::HandleTimeout                 called by fhem.pl (649)
2018.09.28 18:26:56 1: readingsUpdate(,EVTFULL,:MSwitch_Self-AbsCmd1_conditionon) missed to call readingsBeginUpdate first.
2018.09.28 18:26:56 1: stacktrace:
2018.09.28 18:26:56 1:     main::readingsBulkUpdate            called by ./FHEM/98_MSwitch.pm (7071)
2018.09.28 18:26:56 1:     main::MSwitch_EventBulk             called by ./FHEM/98_MSwitch.pm (5408)
2018.09.28 18:26:56 1:     main::MSwitch_checkcondition        called by ./FHEM/98_MSwitch.pm (5296)
2018.09.28 18:26:56 1:     main::MSwitch_Restartcmd            called by fhem.pl (3140)
2018.09.28 18:26:56 1:     main::HandleTimeout                 called by fhem.pl (649)
2018.09.28 18:26:56 1: readingsUpdate(,EVTPART2,MSwitch_Self-AbsCmd1_conditionon) missed to call readingsBeginUpdate first.
2018.09.28 18:26:56 1: stacktrace:
2018.09.28 18:26:56 1:     main::readingsBulkUpdate            called by ./FHEM/98_MSwitch.pm (7073)
2018.09.28 18:26:56 1:     main::MSwitch_EventBulk             called by ./FHEM/98_MSwitch.pm (5408)
2018.09.28 18:26:56 1:     main::MSwitch_checkcondition        called by ./FHEM/98_MSwitch.pm (5296)
2018.09.28 18:26:56 1:     main::MSwitch_Restartcmd            called by fhem.pl (3140)
2018.09.28 18:26:56 1:     main::HandleTimeout                 called by fhem.pl (649)
2018.09.28 18:26:56 1: readingsUpdate(,last_event,MSwitch_Self-AbsCmd1_conditionon) missed to call readingsBeginUpdate first.
2018.09.28 18:26:56 1: stacktrace:
2018.09.28 18:26:56 1:     main::readingsBulkUpdate            called by ./FHEM/98_MSwitch.pm (7075)
2018.09.28 18:26:56 1:     main::MSwitch_EventBulk             called by ./FHEM/98_MSwitch.pm (5408)
2018.09.28 18:26:56 1:     main::MSwitch_checkcondition        called by ./FHEM/98_MSwitch.pm (5296)
2018.09.28 18:26:56 1:     main::MSwitch_Restartcmd            called by fhem.pl (3140)
2018.09.28 18:26:56 1:     main::HandleTimeout                 called by fhem.pl (649)
2018.09.28 18:26:56 1: MSWohnzimmerDim MSwitch_Restartcmd :Fehler bei Befehlsausfuehrung  ERROR Please define exec_cmd1 first 5384
2018.09.28 18:26:56 1: ERROR: empty name in readingsBeginUpdate
2018.09.28 18:26:56 1: stacktrace:
2018.09.28 18:26:56 1:     main::readingsBeginUpdate           called by fhem.pl (4748)
2018.09.28 18:26:56 1:     main::readingsSingleUpdate          called by ./FHEM/98_MSwitch.pm (5389)
2018.09.28 18:26:56 1:     main::MSwitch_Restartcmd            called by fhem.pl (3140)
2018.09.28 18:26:56 1:     main::HandleTimeout                 called by fhem.pl (649)
2018.09.28 18:26:56 1: readingsUpdate(,Exec_cmd,set  exec_cmd1 ) missed to call readingsBeginUpdate first.
2018.09.28 18:26:56 1: stacktrace:
2018.09.28 18:26:56 1:     main::readingsBulkUpdate            called by fhem.pl (4749)
2018.09.28 18:26:56 1:     main::readingsSingleUpdate          called by ./FHEM/98_MSwitch.pm (5389)
2018.09.28 18:26:56 1:     main::MSwitch_Restartcmd            called by fhem.pl (3140)
2018.09.28 18:26:56 1:     main::HandleTimeout                 called by fhem.pl (649)
2018.09.28 18:35:42 1: ERROR: empty name in readingsBeginUpdate
2018.09.28 18:35:42 1: stacktrace:
2018.09.28 18:35:42 1:     main::readingsBeginUpdate           called by ./FHEM/98_MSwitch.pm (7069)
2018.09.28 18:35:42 1:     main::MSwitch_EventBulk             called by ./FHEM/98_MSwitch.pm (5408)
2018.09.28 18:35:42 1:     main::MSwitch_checkcondition        called by ./FHEM/98_MSwitch.pm (1430)
2018.09.28 18:35:42 1:     main::MSwitch_Set                   called by fhem.pl (3592)
2018.09.28 18:35:42 1:     main::CallFn                        called by fhem.pl (1807)
2018.09.28 18:35:42 1:     main::DoSet                         called by fhem.pl (1840)
2018.09.28 18:35:42 1:     main::CommandSet                    called by ./FHEM/98_cmdalias.pm (99)
2018.09.28 18:35:42 1:     main::CommandCmdAlias               called by fhem.pl (1214)
2018.09.28 18:35:42 1:     main::AnalyzeCommand                called by ./FHEM/01_FHEMWEB.pm (2583)
2018.09.28 18:35:42 1:     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (861)
2018.09.28 18:35:42 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (533)
2018.09.28 18:35:42 1:     main::FW_Read                       called by fhem.pl (3597)
2018.09.28 18:35:42 1:     main::CallFn                        called by fhem.pl (726)
2018.09.28 18:35:42 1: readingsUpdate(,EVENT,MSWohnzimmerDim:on_with_Parameter:100) missed to call readingsBeginUpdate first.
2018.09.28 18:35:42 1: stacktrace:
2018.09.28 18:35:42 1:     main::readingsBulkUpdate            called by ./FHEM/98_MSwitch.pm (7070)
2018.09.28 18:35:42 1:     main::MSwitch_EventBulk             called by ./FHEM/98_MSwitch.pm (5408)
2018.09.28 18:35:42 1:     main::MSwitch_checkcondition        called by ./FHEM/98_MSwitch.pm (1430)
2018.09.28 18:35:42 1:     main::MSwitch_Set                   called by fhem.pl (3592)
2018.09.28 18:35:42 1:     main::CallFn                        called by fhem.pl (1807)
2018.09.28 18:35:42 1:     main::DoSet                         called by fhem.pl (1840)
2018.09.28 18:35:42 1:     main::CommandSet                    called by ./FHEM/98_cmdalias.pm (99)
2018.09.28 18:35:42 1:     main::CommandCmdAlias               called by fhem.pl (1214)
2018.09.28 18:35:42 1:     main::AnalyzeCommand                called by ./FHEM/01_FHEMWEB.pm (2583)
2018.09.28 18:35:42 1:     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (861)
2018.09.28 18:35:42 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (533)
2018.09.28 18:35:42 1:     main::FW_Read                       called by fhem.pl (3597)
2018.09.28 18:35:42 1:     main::CallFn                        called by fhem.pl (726)
2018.09.28 18:35:42 1: readingsUpdate(,EVTFULL,MSWohnzimmerDim:on_with_Parameter:100) missed to call readingsBeginUpdate first.
2018.09.28 18:35:42 1: stacktrace:
2018.09.28 18:35:42 1:     main::readingsBulkUpdate            called by ./FHEM/98_MSwitch.pm (7071)
2018.09.28 18:35:42 1:     main::MSwitch_EventBulk             called by ./FHEM/98_MSwitch.pm (5408)
2018.09.28 18:35:42 1:     main::MSwitch_checkcondition        called by ./FHEM/98_MSwitch.pm (1430)
2018.09.28 18:35:42 1:     main::MSwitch_Set                   called by fhem.pl (3592)
2018.09.28 18:35:42 1:     main::CallFn                        called by fhem.pl (1807)
2018.09.28 18:35:42 1:     main::DoSet                         called by fhem.pl (1840)
2018.09.28 18:35:42 1:     main::CommandSet                    called by ./FHEM/98_cmdalias.pm (99)
2018.09.28 18:35:42 1:     main::CommandCmdAlias               called by fhem.pl (1214)
2018.09.28 18:35:42 1:     main::AnalyzeCommand                called by ./FHEM/01_FHEMWEB.pm (2583)
2018.09.28 18:35:42 1:     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (861)
2018.09.28 18:35:42 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (533)
2018.09.28 18:35:42 1:     main::FW_Read                       called by fhem.pl (3597)
2018.09.28 18:35:42 1:     main::CallFn                        called by fhem.pl (726)
2018.09.28 18:35:42 1: readingsUpdate(,EVTPART1,MSWohnzimmerDim) missed to call readingsBeginUpdate first.
2018.09.28 18:35:42 1: stacktrace:
2018.09.28 18:35:42 1:     main::readingsBulkUpdate            called by ./FHEM/98_MSwitch.pm (7072)
2018.09.28 18:35:42 1:     main::MSwitch_EventBulk             called by ./FHEM/98_MSwitch.pm (5408)
2018.09.28 18:35:42 1:     main::MSwitch_checkcondition        called by ./FHEM/98_MSwitch.pm (1430)
2018.09.28 18:35:42 1:     main::MSwitch_Set                   called by fhem.pl (3592)
2018.09.28 18:35:42 1:     main::CallFn                        called by fhem.pl (1807)
2018.09.28 18:35:42 1:     main::DoSet                         called by fhem.pl (1840)
2018.09.28 18:35:42 1:     main::CommandSet                    called by ./FHEM/98_cmdalias.pm (99)
2018.09.28 18:35:42 1:     main::CommandCmdAlias               called by fhem.pl (1214)
2018.09.28 18:35:42 1:     main::AnalyzeCommand                called by ./FHEM/01_FHEMWEB.pm (2583)
2018.09.28 18:35:42 1:     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (861)
2018.09.28 18:35:42 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (533)
2018.09.28 18:35:42 1:     main::FW_Read                       called by fhem.pl (3597)
2018.09.28 18:35:42 1:     main::CallFn                        called by fhem.pl (726)
2018.09.28 18:35:42 1: readingsUpdate(,EVTPART2,on_with_Parameter) missed to call readingsBeginUpdate first.
2018.09.28 18:35:42 1: stacktrace:
2018.09.28 18:35:42 1:     main::readingsBulkUpdate            called by ./FHEM/98_MSwitch.pm (7073)
2018.09.28 18:35:42 1:     main::MSwitch_EventBulk             called by ./FHEM/98_MSwitch.pm (5408)
2018.09.28 18:35:42 1:     main::MSwitch_checkcondition        called by ./FHEM/98_MSwitch.pm (1430)
2018.09.28 18:35:42 1:     main::MSwitch_Set                   called by fhem.pl (3592)
2018.09.28 18:35:42 1:     main::CallFn                        called by fhem.pl (1807)
2018.09.28 18:35:42 1:     main::DoSet                         called by fhem.pl (1840)
2018.09.28 18:35:42 1:     main::CommandSet                    called by ./FHEM/98_cmdalias.pm (99)
2018.09.28 18:35:42 1:     main::CommandCmdAlias               called by fhem.pl (1214)
2018.09.28 18:35:42 1:     main::AnalyzeCommand                called by ./FHEM/01_FHEMWEB.pm (2583)
2018.09.28 18:35:42 1:     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (861)
2018.09.28 18:35:42 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (533)
2018.09.28 18:35:42 1:     main::FW_Read                       called by fhem.pl (3597)
2018.09.28 18:35:42 1:     main::CallFn                        called by fhem.pl (726)
2018.09.28 18:35:42 1: readingsUpdate(,EVTPART3,100) missed to call readingsBeginUpdate first.
2018.09.28 18:35:42 1: stacktrace:
2018.09.28 18:35:42 1:     main::readingsBulkUpdate            called by ./FHEM/98_MSwitch.pm (7074)
2018.09.28 18:35:42 1:     main::MSwitch_EventBulk             called by ./FHEM/98_MSwitch.pm (5408)
2018.09.28 18:35:42 1:     main::MSwitch_checkcondition        called by ./FHEM/98_MSwitch.pm (1430)
2018.09.28 18:35:42 1:     main::MSwitch_Set                   called by fhem.pl (3592)
2018.09.28 18:35:42 1:     main::CallFn                        called by fhem.pl (1807)
2018.09.28 18:35:42 1:     main::DoSet                         called by fhem.pl (1840)
2018.09.28 18:35:42 1:     main::CommandSet                    called by ./FHEM/98_cmdalias.pm (99)
2018.09.28 18:35:42 1:     main::CommandCmdAlias               called by fhem.pl (1214)
2018.09.28 18:35:42 1:     main::AnalyzeCommand                called by ./FHEM/01_FHEMWEB.pm (2583)
2018.09.28 18:35:42 1:     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (861)
2018.09.28 18:35:42 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (533)
2018.09.28 18:35:42 1:     main::FW_Read                       called by fhem.pl (3597)
2018.09.28 18:35:42 1:     main::CallFn                        called by fhem.pl (726)
2018.09.28 18:35:42 1: readingsUpdate(,last_event,MSWohnzimmerDim:on_with_Parameter:100) missed to call readingsBeginUpdate first.
2018.09.28 18:35:42 1: stacktrace:
2018.09.28 18:35:42 1:     main::readingsBulkUpdate            called by ./FHEM/98_MSwitch.pm (7075)
2018.09.28 18:35:42 1:     main::MSwitch_EventBulk             called by ./FHEM/98_MSwitch.pm (5408)
2018.09.28 18:35:42 1:     main::MSwitch_checkcondition        called by ./FHEM/98_MSwitch.pm (1430)
2018.09.28 18:35:42 1:     main::MSwitch_Set                   called by fhem.pl (3592)
2018.09.28 18:35:42 1:     main::CallFn                        called by fhem.pl (1807)
2018.09.28 18:35:42 1:     main::DoSet                         called by fhem.pl (1840)
2018.09.28 18:35:42 1:     main::CommandSet                    called by ./FHEM/98_cmdalias.pm (99)
2018.09.28 18:35:42 1:     main::CommandCmdAlias               called by fhem.pl (1214)
2018.09.28 18:35:42 1:     main::AnalyzeCommand                called by ./FHEM/01_FHEMWEB.pm (2583)
2018.09.28 18:35:42 1:     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (861)
2018.09.28 18:35:42 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (533)
2018.09.28 18:35:42 1:     main::FW_Read                       called by fhem.pl (3597)
2018.09.28 18:35:42 1:     main::CallFn                        called by fhem.pl (726)
2018.09.28 18:37:42 1: ERROR: empty name in readingsBeginUpdate
2018.09.28 18:37:42 1: stacktrace:
2018.09.28 18:37:42 1:     main::readingsBeginUpdate           called by ./FHEM/98_MSwitch.pm (7069)
2018.09.28 18:37:42 1:     main::MSwitch_EventBulk             called by ./FHEM/98_MSwitch.pm (5408)
2018.09.28 18:37:42 1:     main::MSwitch_checkcondition        called by ./FHEM/98_MSwitch.pm (5296)
2018.09.28 18:37:42 1:     main::MSwitch_Restartcmd            called by fhem.pl (3140)
2018.09.28 18:37:42 1:     main::HandleTimeout                 called by fhem.pl (649)
2018.09.28 18:37:42 1: readingsUpdate(,EVENT,MSwitch_Self-AbsCmd1_conditionon) missed to call readingsBeginUpdate first.
2018.09.28 18:37:42 1: stacktrace:
2018.09.28 18:37:42 1:     main::readingsBulkUpdate            called by ./FHEM/98_MSwitch.pm (7070)
2018.09.28 18:37:42 1:     main::MSwitch_EventBulk             called by ./FHEM/98_MSwitch.pm (5408)
2018.09.28 18:37:42 1:     main::MSwitch_checkcondition        called by ./FHEM/98_MSwitch.pm (5296)
2018.09.28 18:37:42 1:     main::MSwitch_Restartcmd            called by fhem.pl (3140)
2018.09.28 18:37:42 1:     main::HandleTimeout                 called by fhem.pl (649)
2018.09.28 18:37:42 1: readingsUpdate(,EVTFULL,:MSwitch_Self-AbsCmd1_conditionon) missed to call readingsBeginUpdate first.
2018.09.28 18:37:42 1: stacktrace:
2018.09.28 18:37:42 1:     main::readingsBulkUpdate            called by ./FHEM/98_MSwitch.pm (7071)
2018.09.28 18:37:42 1:     main::MSwitch_EventBulk             called by ./FHEM/98_MSwitch.pm (5408)
2018.09.28 18:37:42 1:     main::MSwitch_checkcondition        called by ./FHEM/98_MSwitch.pm (5296)
2018.09.28 18:37:42 1:     main::MSwitch_Restartcmd            called by fhem.pl (3140)
2018.09.28 18:37:42 1:     main::HandleTimeout                 called by fhem.pl (649)
2018.09.28 18:37:42 1: readingsUpdate(,EVTPART2,MSwitch_Self-AbsCmd1_conditionon) missed to call readingsBeginUpdate first.
2018.09.28 18:37:42 1: stacktrace:
2018.09.28 18:37:42 1:     main::readingsBulkUpdate            called by ./FHEM/98_MSwitch.pm (7073)
2018.09.28 18:37:42 1:     main::MSwitch_EventBulk             called by ./FHEM/98_MSwitch.pm (5408)
2018.09.28 18:37:42 1:     main::MSwitch_checkcondition        called by ./FHEM/98_MSwitch.pm (5296)
2018.09.28 18:37:42 1:     main::MSwitch_Restartcmd            called by fhem.pl (3140)
2018.09.28 18:37:42 1:     main::HandleTimeout                 called by fhem.pl (649)
2018.09.28 18:37:42 1: readingsUpdate(,last_event,MSwitch_Self-AbsCmd1_conditionon) missed to call readingsBeginUpdate first.
2018.09.28 18:37:42 1: stacktrace:
2018.09.28 18:37:42 1:     main::readingsBulkUpdate            called by ./FHEM/98_MSwitch.pm (7075)
2018.09.28 18:37:42 1:     main::MSwitch_EventBulk             called by ./FHEM/98_MSwitch.pm (5408)
2018.09.28 18:37:42 1:     main::MSwitch_checkcondition        called by ./FHEM/98_MSwitch.pm (5296)
2018.09.28 18:37:42 1:     main::MSwitch_Restartcmd            called by fhem.pl (3140)
2018.09.28 18:37:42 1:     main::HandleTimeout                 called by fhem.pl (649)
2018.09.28 18:37:42 1: MSWohnzimmerDim MSwitch_Restartcmd :Fehler bei Befehlsausfuehrung  ERROR Please define exec_cmd1 first 5384
2018.09.28 18:37:42 1: ERROR: empty name in readingsBeginUpdate
2018.09.28 18:37:42 1: stacktrace:
2018.09.28 18:37:42 1:     main::readingsBeginUpdate           called by fhem.pl (4748)
2018.09.28 18:37:42 1:     main::readingsSingleUpdate          called by ./FHEM/98_MSwitch.pm (5389)
2018.09.28 18:37:42 1:     main::MSwitch_Restartcmd            called by fhem.pl (3140)
2018.09.28 18:37:42 1:     main::HandleTimeout                 called by fhem.pl (649)
2018.09.28 18:37:42 1: readingsUpdate(,Exec_cmd,set  exec_cmd1 ) missed to call readingsBeginUpdate first.
2018.09.28 18:37:42 1: stacktrace:
2018.09.28 18:37:42 1:     main::readingsBulkUpdate            called by fhem.pl (4749)
2018.09.28 18:37:42 1:     main::readingsSingleUpdate          called by ./FHEM/98_MSwitch.pm (5389)
2018.09.28 18:37:42 1:     main::MSwitch_Restartcmd            called by fhem.pl (3140)
2018.09.28 18:37:42 1:     main::HandleTimeout                 called by fhem.pl (649)

Zusätzlich hat das Einfügen des Dimmercodes gerade meinen kompletten Raspi abgeschossen  ;D

2018.09.28 18:40:12 0: vor change: FreeCmd-AbsCmd1#[NF]cmd#[NF]cmd#[NF]{#[nl]my#[sp]$ziel#[sp]=#[sp]ReadingsVal("$SELF"#[ko]"ziel"#[ko]0)#[se]#[sp]##[sp]bis#[sp]wohin#[sp]gedimmt#[sp]werden#[sp]soll#[nl]my#[sp]$ist#[sp]=#[sp]ReadingsVal("HM_1F675D"#[ko]"pct"#[ko]0)#[se]#[sp]##[sp]zustand#[sp]der#[sp]lampe#[se]#[nl]my#[sp]$steps#[sp]=#[sp]ReadingsVal("$SELF"#[ko]"steps"#[ko]1)#[se]#[sp]##[sp]dimmschritte#[sp]pro#[sp]durchgang#[nl]Log3(#[sp]"SELF"#[ko]#[sp]5#[ko]#[sp]"SELF#[dp]#[sp]ziel#[sp]".$ziel#[sp])#[se]#[nl]Log3(#[sp]"SELF"#[ko]#[sp]5#[ko]#[sp]"SELF#[dp]#[sp]ist#[sp]".$ist#[sp])#[se]#[nl]if#[sp]($ist#[sp]==#[sp]$ziel#[sp])#[sp]##[sp]lösche#[sp]wiederholung#[sp]wenn#[sp]ziel#[sp]erreicht#[nl]#[sp]{#[nl]#[sp]fhem("set#[sp]$SELF#[sp]del_delays")#[se]#[nl]#[sp]return#[se]#[nl]#[sp]}#[nl]if#[sp]($ziel#[sp]>#[sp]$ist#[sp])#[nl]{#[nl]##[sp]setze#[sp]zustand#[sp]der#[sp]lampe#[sp]-#[sp]steps#[nl]$ist#[sp]=#[sp]$ist#[sp]+#[sp]$steps#[se]#[nl]$ist#[sp]=int($ist)#[se]#[nl]#[sp]#[sp]#[sp]if#[sp]($ziel#[sp]<#[sp]$ist#[sp])#[nl]#[sp]#[sp]#[sp]{#[nl]#[sp]#[sp]#[sp]$ist#[sp]=#[sp]$ziel#[se]#[nl]#[sp]#[sp]#[sp]}#[nl]}#[nl]if#[sp]($ziel#[sp]<#[sp]$ist#[sp])#[nl]{#[nl]##[sp]setze#[sp]zustand#[sp]der#[sp]lampe#[sp]-#[sp]steps#[nl]$ist#[sp]=#[sp]$ist#[sp]-#[sp]$steps#[se]#[sp]#[nl]$ist#[sp]=int($ist)#[se]#[nl]#[sp]#[sp]#[sp]if#[sp]($ziel#[sp]>#[sp]$ist#[sp])#[nl]#[sp]#[sp]#[sp]{#[nl]#[sp]#[sp]#[sp]$ist#[sp]=#[sp]$ziel#[se]#[nl]#[sp]#[sp]#[sp]}#[nl]}#[nl]Log3(#[sp]"SELF"#[ko]#[sp]5#[ko]#[sp]"SELF#[dp]#[sp]SETTING#[sp]".$ist#[sp])#[se]#[nl]fhem("set#[sp]HM_1F675D#[sp]pct#[sp]$ist")#[se]#[nl]}#[NF]#[NF]delay1#[NF]delay1#[NF]00#[dp]00#[dp]00#[NF]00#[dp]00#[dp]00#[NF]#[NF]#[NF]0#[NF]0#[NF]3#[NF]0#[ND]FreeCmd-AbsCmd2#[NF]cmd#[NF]cmd#[NF]setreading#[sp]$SELF#[sp]ziel#[sp][$SELF#[dp]Parameter]#[NF]set#[sp]$SELF#[sp]del_delays#[NF]delay1#[NF]delay1#[NF]00#[dp]00#[dp]00#[NF]00#[dp]00#[dp]00#[NF]#[NF]#[NF]#[NF]#[NF]1#[NF]0#[ND]HM_1F675D-AbsCmd1#[NF]no_action#[NF]off#[NF]#[NF]#[NF]delay1#[NF]delay1#[NF]00#[dp]00#[dp]00#[NF]00#[dp]00#[dp]00#[NF]#[NF]#[NF]#[NF]#[NF]4#[NF]0#[ND]MSwitch_Self-AbsCmd1#[NF]exec_cmd1#[NF]no_action#[NF]#[NF]#[NF]delay1#[NF]delay1#[NF][$SELF#[dp]seconds]#[NF]00#[dp]00#[dp]00#[NF]#[NF]#[NF]#[NF]#[NF]2#[NF]0
2018.09.28 18:40:21 1: PERL WARNING: Argument "un" isn't numeric in multiplication (*) at ./FHEM/98_MSwitch.pm line 1356.
2018.09.28 18:40:21 1: PERL WARNING: Argument "ef" isn't numeric in multiplication (*) at ./FHEM/98_MSwitch.pm line 1357.
2018.09.28 18:40:21 1: PERL WARNING: substr outside of string at ./FHEM/98_MSwitch.pm line 1358.
2018.09.28 18:40:21 1: PERL WARNING: Use of uninitialized value in multiplication (*) at ./FHEM/98_MSwitch.pm line 1358.
2018.09.28 18:40:22 1: PERL WARNING: Argument "un" isn't numeric in multiplication (*) at ./FHEM/98_MSwitch.pm line 4947.
2018.09.28 18:40:22 1: PERL WARNING: Argument "ef" isn't numeric in multiplication (*) at ./FHEM/98_MSwitch.pm line 4948.
2018.09.28 18:40:22 1: PERL WARNING: substr outside of string at ./FHEM/98_MSwitch.pm line 4949.
2018.09.28 18:40:22 1: PERL WARNING: Use of uninitialized value in multiplication (*) at ./FHEM/98_MSwitch.pm line 4949.
2018.09.28 18:40:27 1: PERL WARNING: Deep recursion on subroutine "main::CallFn" at fhem.pl line 3517.
2018.09.28 18:40:27 1: PERL WARNING: Deep recursion on subroutine "main::CallFn" at fhem.pl line 1807.
2018.09.28 18:40:27 1: PERL WARNING: Deep recursion on subroutine "main::AnalyzeCommandChain" at ./FHEM/98_MSwitch.pm line 5067.
2018.09.28 18:40:27 1: PERL WARNING: Deep recursion on subroutine "main::AnalyzeCommand" at fhem.pl line 1062.
2018.09.28 18:40:27 1: PERL WARNING: Deep recursion on subroutine "main::CommandCmdAlias" at fhem.pl line 1214.
2018.09.28 18:40:27 1: PERL WARNING: Deep recursion on subroutine "main::CommandSet" at ./FHEM/98_cmdalias.pm line 99.
2018.09.28 18:40:27 1: PERL WARNING: Deep recursion on subroutine "main::DoSet" at fhem.pl line 1840.
2018.09.28 18:40:27 1: PERL WARNING: Deep recursion on subroutine "main::MSwitch_Set" at fhem.pl line 3592.
2018.09.28 18:40:27 1: PERL WARNING: Deep recursion on subroutine "main::MSwitch_Exec_Notif" at ./FHEM/98_MSwitch.pm line 919.
2018.09.27 18:58:13 1: Including fhem.cfg

Ebenfalls habe ich beim Start von fhem folgende Warnungen.

2018.09.28 19:09:37 1: PERL WARNING: Useless use of concatenation (.) or string in void context at ./FHEM/98_MSwitch.pm line 3507, <$fh> line 2020.
2018.09.28 19:09:37 1: PERL WARNING: "my" variable $x masks earlier declaration in same scope at ./FHEM/98_MSwitch.pm line 7210, <$fh> line 2020.
2018.09.28 19:09:37 1: PERL WARNING: "my" variable $x masks earlier declaration in same scope at ./FHEM/98_MSwitch.pm line 7331, <$fh> line 2020.

Grüße
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 28 September 2018, 20:18:44
ja, mit dem rename gibt es probleme - ist mir aber selber erst seit gestern oder vorgestern bewusst - ich arbeite daran und hoffe das ich sonntag entsprechende zeit finde . da ist im moment  noch ein neustart fällig.
die warnungen habe ich heute bereits behoben , waren nur doppeldeclarierungen.

aber mit dem einfügen des codes weiss ich nicht was passiert ist . wie und wo hast du diesen eingefügt ? einfach in ein freecmd kopiert ?
... und gib mir bitte mal den code, den du eingefügt hast .  edit: wobei mir das aussiht als hattest du ein config eingespielt ?

gruss Byte09

Titel: Antw:98_MSwitch - Support
Beitrag von: Esjay am 28 September 2018, 20:31:32
Habe ein einfaches MSwitch angelegt. Anschließend ein "get xyz get_config" gemacht, anschließend folgendes eingefügt:

#I Achtung, des zu steuernde Device muss das Reading ptc haben und über set DEVICE ptc WERT angesteuert werden können !
#Q HM_1F675D#bitte dieses Device gegen ein vorhandenes Dimmer-Device ersetzen :#device
#V V2.00
#VS V2.00
#S .Device_Affected -> FreeCmd-AbsCmd1,FreeCmd-AbsCmd2,HM_1F675D-AbsCmd1,MSwitch_Self-AbsCmd1
#S .Device_Affected_Details -> FreeCmd-AbsCmd1#[NF]cmd#[NF]cmd#[NF]{;;my $ziel = ReadingsVal("$SELF","ziel",0); # bis wohin gedimmt werden soll;;my $ist = ReadingsVal("HM_1F675D","pct",0); # zustand der lampe;;;my $steps = ReadingsVal("$SELF","steps",1); # dimmschritte pro durchgang;;Log3( "SELF", 5, "SELF: ziel ".$ziel );;;Log3( "SELF", 5, "SELF: ist ".$ist );;;if ($ist == $ziel ) # lösche wiederholung wenn ziel erreicht;; {;; fhem("set $SELF del_delays");;; return;;; };;if ($ziel > $ist );;{;;# setze zustand der lampe - steps;;$ist = $ist + $steps;;;$ist =int($ist);;;   if ($ziel < $ist );;   {;;   $ist = $ziel;;;   };;};;if ($ziel < $ist );;{;;# setze zustand der lampe - steps;;$ist = $ist - $steps; ;;$ist =int($ist);;;   if ($ziel > $ist );;   {;;   $ist = $ziel;;;   };;};;Log3( "SELF", 5, "SELF: SETTING ".$ist );;;fhem("set HM_1F675D pct $ist");;;}#[NF]#[NF]delay1#[NF]delay1#[NF]00:00:00#[NF]00:00:00#[NF]#[NF]#[NF]0#[NF]0#[NF]3#[NF]0#[ND]FreeCmd-AbsCmd2#[NF]cmd#[NF]cmd#[NF]setreading $SELF ziel [$SELF:Parameter]#[NF]set $SELF del_delays#[NF]delay1#[NF]delay1#[NF]00:00:00#[NF]00:00:00#[NF]#[NF]#[NF]#[NF]#[NF]1#[NF]0#[ND]HM_1F675D-AbsCmd1#[NF]no_action#[NF]off#[NF]#[NF]#[NF]delay1#[NF]delay1#[NF]00:00:00#[NF]00:00:00#[NF]#[NF]#[NF]#[NF]#[NF]4#[NF]0#[ND]MSwitch_Self-AbsCmd1#[NF]exec_cmd1#[NF]no_action#[NF]#[NF]#[NF]delay1#[NF]delay1#[NF][$SELF:seconds]#[NF]00:00:00#[NF]#[NF]#[NF]#[NF]#[NF]2#[NF]0
#S .Device_Events -> no_trigger
#S .First_init -> done
#S .Trigger_Whitelist -> undef
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> no_trigger
#S .Trigger_condition -> undef
#S .Trigger_off -> no_trigger
#S .Trigger_on -> no_trigger
#S .Trigger_time -> undef
#S .V_Check -> V2.00
#S Trigger_device -> no_trigger
#S Trigger_log -> off
#S last_event -> MSwitch_Self-AbsCmd1_conditionon
#S .sysconf -> #test#[se]#[nl]#[nl]$special="pct#[dp]slider#[ko]0#[ko]1#[ko]100#[sp]steps#[dp]1#[ko]2#[ko]3#[ko]4#[ko]5#[ko]6#[ko]7#[ko]8#[ko]9#[ko]10#[sp]seconds#[dp]00#[dp]00#[dp]01#[ko]00#[dp]00#[dp]02#[ko]00#[dp]00#[dp]03#[ko]00#[dp]00#[dp]04#[ko]00#[dp]00#[dp]05#[ko]00#[dp]00#[dp]06#[ko]00#[dp]00#[dp]07#[ko]00#[dp]00#[dp]08#[ko]00#[dp]00#[dp]09#[ko]00#[dp]00#[dp]10#[ko]00#[dp]00#[dp]30"#[sp]#[se]#[nl]#[nl]#[nl]#[nl]if#[sp]($cmd#[sp]eq#[sp]"steps")#[nl]{#[nl]MSwitch_LOG(#[sp]$name#[ko]#[sp]5#[ko]#[sp]"setting#[sp]STEPS#[sp]#[dp]#[sp]$cmd#[sp]$args[0]"#[sp])#[se]#[nl]readingsSingleUpdate(#[sp]$hash#[ko]#[sp]"steps"#[ko]#[sp]$args[0]#[ko]#[sp]1#[sp])#[se]#[nl]return#[sp]"exit"#[se]#[nl]}#[nl]#[nl]if#[sp]($cmd#[sp]eq#[sp]"seconds")#[nl]{#[nl]MSwitch_LOG(#[sp]$name#[ko]#[sp]5#[ko]#[sp]"setting#[sp]STEPS#[sp]#[dp]#[sp]$cmd#[sp]$args[0]"#[sp])#[se]#[nl]readingsSingleUpdate(#[sp]$hash#[ko]#[sp]"seconds"#[ko]#[sp]$args[0]#[ko]#[sp]1#[sp])#[se]#[nl]return#[sp]"exit"#[se]#[nl]}#[nl]#[nl]#[nl]#[nl]if#[sp]($cmd#[sp]eq#[sp]"on"#[sp]#[wa]#[wa]#[sp]$cmd#[sp]eq#[sp]"off"#[sp]#[wa]#[wa]#[sp]$cmd#[sp]eq#[sp]"pct")#[nl]{#[nl]$args[0]#[sp]=""#[sp]if#[sp]#[sp]!defined#[sp]$args[0]#[se]#[nl]my#[sp]$arg#[sp]=#[sp]$args[0]#[se]#[nl]#[sp]if#[sp]($cmd#[sp]eq#[sp]"on"#[sp]#[wa]#[wa]#[sp]$cmd#[sp]eq#[sp]"off"#[sp]#[sp]#[wa]#[wa]#[sp]$cmd#[sp]eq#[sp]"pct")#[nl]#[sp]{#[nl]#[sp]if#[sp]($cmd#[sp]eq#[sp]"pct"#[sp]&&#[sp]$arg#[sp]eq#[sp]#[st]0#[st])#[nl]#[sp]{#[nl]#[sp]$cmd#[sp]=#[st]off#[st]#[se]#[nl]#[sp]#[sp]}#[nl]if#[sp]($cmd#[sp]eq#[sp]"pct"#[sp]&&#[sp]$arg#[sp]ne#[sp]#[st]0#[st])#[nl]{#[nl]$cmd#[sp]=#[st]on#[st]#[se]#[nl]}#[sp]#[sp]#[sp]#[nl]#[sp]if#[sp](#[sp]$cmd#[sp]eq#[sp]#[st]on#[st]#[sp]&&#[sp]$arg#[sp]eq#[sp]#[st]#[st])#[nl]{#[nl]$args[0]#[sp]=#[sp]ReadingsVal(#[sp]$name#[ko]#[sp]#[st]pct#[st]#[ko]#[sp]100)#[se]#[nl]}#[nl]#[nl]if#[sp](#[sp]$cmd#[sp]eq#[sp]#[st]off#[st]#[sp]&&#[sp]$arg#[sp]eq#[sp]#[st]#[st]#[sp]#[sp]#[sp]#[sp])#[nl]{#[nl]$args[0]#[sp]=#[sp]0#[se]#[nl]}#[nl]readingsSingleUpdate(#[sp]$hash#[ko]#[sp]"pct"#[ko]#[sp]$args[0]#[ko]#[sp]1#[sp])#[se]#[nl]}#[nl]}#[nl]#[nl]#[nl]return#[sp]"end"#[se]#[nl]#[nl]
#S state -> on
#S Sys_Extension -> on
#A MSwitch_Expert -> 1
#A webCmd -> on:off:pct:steps:seconds
#A MSwitch_Debug -> 0
#A disable -> 0
#A MSwitch_Include_Webcmds -> 1
#A MSwitch_Delete_Delays -> 0
#A room -> 1_Test
#A MSwitch_Extensions -> 0
#A MSwitch_Lock_Quickedit -> 1
#A MSwitch_Mode -> Full
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A MSwitch_Help -> 0
#A MSwitch_Include_MSwitchcmds -> 0
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Safemode -> 0

anschließend ein save change, dann kam die Frage nach dem Device welches gedimmt werden soll,daraufhin habe ich folgendes Device genommen:

Internals:
   DEF        group 1  IODev=Hue
   ID         G1
   INTERVAL   
   IODev      Hue
   NAME       HUEGroup1
   NR         43
   STATE      on
   TYPE       HUEDevice
   class      Living room
   lights     1,2,3,4
   name       Wz
   type       Room
   READINGS:
     2018-09-28 20:29:49   alert           nonuniform
     2018-09-28 20:29:04   all_on          true
     2018-09-28 20:29:04   any_on          true
     2018-09-28 20:29:49   bri             216
     2018-09-28 20:29:49   colormode       ct
     2018-09-28 20:29:49   ct              406
     2018-09-28 20:29:49   effect          none
     2018-09-28 20:29:49   onoff           1
     2018-09-28 20:29:49   pct             85
     2018-09-28 20:29:49   reachable       1
     2018-09-28 20:29:49   sat             170
     2018-09-28 20:29:49   state           on
   helper:
     alert      nonuniform
     bri        216
     colormode  ct
     ct         406
     devtype    G
     effect     none
     onoff      1
     pct        85
     reachable  1
     sat        170
     state      dim81%
     update_timeout 1
Attributes:
   IODev      Hue
   alias      Wohnzimmergruppe
   color-icons 2
   delayedUpdate 1
   devStateIcon {(HUEDevice_devStateIcon($name),"toggle")}
   group      HUEGroup
   icon       logic
   room       Wohnzimmer,hidden
   stateFormat {ReadingsVal("HUEGroup1","all_on","") eq "false"?"off":"on"}
   userReadings state {ReadingsVal("HUEGroup1","all_on","") eq "false"?"off":"on"}
   userattr   createActionReadings:1,0 createGroupReadings:1,0

Nach dem Bestätigen--> Feierabend!

Eben nach dem Update:

2018.09.28 20:28:40 1: PERL WARNING: Useless use of concatenation (.) or string in void context at ./FHEM/98_MSwitch.pm line 3532, <$fh> line 2020.
2018.09.28 20:28:41 1: PERL WARNING: "my" variable $x masks earlier declaration in same scope at ./FHEM/98_MSwitch.pm line 5894, <$fh> line 2020.
2018.09.28 20:30:00 1: PERL WARNING: Use of uninitialized value $evtparts[0] in join or string at ./FHEM/98_MSwitch.pm line 7138.
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 28 September 2018, 20:51:19
ich habe das jetzt glaube ich 10 mal probiert , in ähnlicher konstellation, ebenfalls mit dem device Huegroup1 ... ich kann es nicht nachvollziehen.

.. könntest du mir ggf. nochmal die RAW des devices geben (obwohl dort im grunde keine fehlerquelle sein kann , da hier nur eine ersetzung stattfindet ) ... aber sicher ist sicher

unabhängig davon wird das config nicht bei einer Huegroup funktionieren , da diese kein reading ptc besizt ( aber ein absturz dürfte es nicht produzieren )

 ... sehe gerade,das deine gruppe dieses reading besitzt , warum ? meine nicht?!  ... ggf. resultiert doch hieraus das problem ?!

gruss Byte
Titel: Antw:98_MSwitch - Support
Beitrag von: Esjay am 28 September 2018, 21:07:05
Setz mal folgendes:

attr <HueBridge> createGroupReadings 1

Damit werden die Gruppen zu "normalen" Devices gemacht.

Hier der Raw-Code

defmod HUEGroup1 HUEDevice group 1  IODev=Hue
attr HUEGroup1 userattr createActionReadings:1,0 createGroupReadings:1,0
attr HUEGroup1 IODev Hue
attr HUEGroup1 alias Wohnzimmergruppe
attr HUEGroup1 color-icons 2
attr HUEGroup1 delayedUpdate 1
attr HUEGroup1 devStateIcon {(HUEDevice_devStateIcon($name),"toggle")}
attr HUEGroup1 group HUEGroup
attr HUEGroup1 icon logic
attr HUEGroup1 room Wohnzimmer,hidden
attr HUEGroup1 stateFormat {ReadingsVal("HUEGroup1","all_on","") eq "false"?"off":"on"}
attr HUEGroup1 userReadings state {ReadingsVal("HUEGroup1","all_on","") eq "false"?"off":"on"}

setstate HUEGroup1 on
setstate HUEGroup1 2018-09-28 20:29:49 alert nonuniform
setstate HUEGroup1 2018-09-28 20:29:04 all_on true
setstate HUEGroup1 2018-09-28 20:29:04 any_on true
setstate HUEGroup1 2018-09-28 20:29:49 bri 216
setstate HUEGroup1 2018-09-28 20:29:49 colormode ct
setstate HUEGroup1 2018-09-28 20:29:49 ct 406
setstate HUEGroup1 2018-09-28 20:29:49 effect none
setstate HUEGroup1 2018-09-28 20:29:49 onoff 1
setstate HUEGroup1 2018-09-28 20:29:49 pct 85
setstate HUEGroup1 2018-09-28 20:29:49 reachable 1
setstate HUEGroup1 2018-09-28 20:29:49 sat 170
setstate HUEGroup1 2018-09-28 21:04:12 state on

Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 28 September 2018, 21:14:55
Setz mal folgendes:

attr <HueBridge> createGroupReadings 1

Damit werden die Gruppen zu "normalen" Devices gemacht.

Hier der Raw-Code

defmod HUEGroup1 HUEDevice group 1  IODev=Hue
attr HUEGroup1 userattr createActionReadings:1,0 createGroupReadings:1,0
attr HUEGroup1 IODev Hue
attr HUEGroup1 alias Wohnzimmergruppe
attr HUEGroup1 color-icons 2
attr HUEGroup1 delayedUpdate 1
attr HUEGroup1 devStateIcon {(HUEDevice_devStateIcon($name),"toggle")}
attr HUEGroup1 group HUEGroup
attr HUEGroup1 icon logic
attr HUEGroup1 room Wohnzimmer,hidden
attr HUEGroup1 stateFormat {ReadingsVal("HUEGroup1","all_on","") eq "false"?"off":"on"}
attr HUEGroup1 userReadings state {ReadingsVal("HUEGroup1","all_on","") eq "false"?"off":"on"}

setstate HUEGroup1 on
setstate HUEGroup1 2018-09-28 20:29:49 alert nonuniform
setstate HUEGroup1 2018-09-28 20:29:04 all_on true
setstate HUEGroup1 2018-09-28 20:29:04 any_on true
setstate HUEGroup1 2018-09-28 20:29:49 bri 216
setstate HUEGroup1 2018-09-28 20:29:49 colormode ct
setstate HUEGroup1 2018-09-28 20:29:49 ct 406
setstate HUEGroup1 2018-09-28 20:29:49 effect none
setstate HUEGroup1 2018-09-28 20:29:49 onoff 1
setstate HUEGroup1 2018-09-28 20:29:49 pct 85
setstate HUEGroup1 2018-09-28 20:29:49 reachable 1
setstate HUEGroup1 2018-09-28 20:29:49 sat 170
setstate HUEGroup1 2018-09-28 21:04:12 state on


ok, thx ... hab ich.

habe jetzt das config eingespielt, ohne fehler . gruppe lässt sich ansteuern über das mswitch. ich verstehe es gerade nicht.
frage mal ganz vorsichtig : kannst du es reproduzieren ?

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Esjay am 28 September 2018, 22:02:45
Gerade mal versucht zu reproduzieren. Klappt natürlich nicht  ;D

Kanns mir auch nicht erklären. Solange ich der einzige mit dem "Problem" bin, bzw. war, ist es wie es ist.

Zumindest haben deine Hue Gruppen jetzt das pct reading  ;D
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 28 September 2018, 22:10:37
Gerade mal versucht zu reproduzieren. Klappt natürlich nicht  ;D

Kanns mir auch nicht erklären. Solange ich der einzige mit dem "Problem" bin, bzw. war, ist es wie es ist.

Zumindest haben deine Hue Gruppen jetzt das pct reading  ;D
Das heisst jetzt ging es ?

Gruss Byte09

Gesendet von meinem SM-G900F mit Tapatalk

Titel: Antw:98_MSwitch - Support
Beitrag von: Esjay am 28 September 2018, 22:12:20
Jap ohne Probleme mehrmals hintereinander.

Grüße
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 30 September 2018, 09:55:15
kommendes Update auf V2.01

- Fix: Rename
Fehler bei der Renamefunktion ( rename MSwitchname Mswitchnewname ) behoben

- Fix/new : Copy
copy MSwitchdevice1 Mswitchdevice2 ist nun möglich . Bisher wurde hier nur die leere 'Hülle' kopiert , mit der kommenden Version werden alle daten übernommen. Aus Sicherheitsgründen wird ein kopiertes Device standartmässig immer auf 'disable' gesetzt

- Fix Delays
unter ganz bestimmten Voraussetzungen konnte es hier zu einem Fehlverhalten kommen , das Fhem zum Asturz brachte.
Bezug: https://forum.fhem.de/index.php/topic,86199.msg840535.html#msg840535 (https://forum.fhem.de/index.php/topic,86199.msg840535.html#msg840535)

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Bäschdler am 30 September 2018, 17:07:37
Hallo Byte,

ich möchte die Logbucheinträge im jeweiligen Logfile des Rolladen eintragen. Dafür habe ich jeweils weiteres Filelog definiert welches in das selbe File schribt wie das Rolladen-Modul dies tut.
Das würde ich auch gerne wieder so abbilden, denn dann steht bei dem Fahrbefehl eich ein Logbucheintrag weshalb der Rolladen da hin gefahren ist.

Dann hätte ich da noch § weitere Fragen:
- kann man innerhalb des MSwitch Moduls die (optische) Reihenfolge der Device Actions nachträglich noch ändern ?
- wäre es möglich eine "Überschrift" bzw. einen Kommentar bei dem jeweiligen Device Action-Block einzufügen (ich möchte mir da rein schreiben was die jeweilige Aktion macht)?
- kann man einen kompletten MSwitch irgendwie kopieren um quasi dieselbe Funktionalität unter einem anderen Namen und für ein anderes affected device zu bekommen?

Viele Grüsse
Bäschdler
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 30 September 2018, 19:05:07
Hallo Byte,

ich möchte die Logbucheinträge im jeweiligen Logfile des Rolladen eintragen. Dafür habe ich jeweils weiteres Filelog definiert welches in das selbe File schribt wie das Rolladen-Modul dies tut.
Das würde ich auch gerne wieder so abbilden, denn dann steht bei dem Fahrbefehl eich ein Logbucheintrag weshalb der Rolladen da hin gefahren ist.

Dann hätte ich da noch § weitere Fragen:
- kann man innerhalb des MSwitch Moduls die (optische) Reihenfolge der Device Actions nachträglich noch ändern ?
- wäre es möglich eine "Überschrift" bzw. einen Kommentar bei dem jeweiligen Device Action-Block einzufügen (ich möchte mir da rein schreiben was die jeweilige Aktion macht)?
- kann man einen kompletten MSwitch irgendwie kopieren um quasi dieselbe Funktionalität unter einem anderen Namen und für ein anderes affected device zu bekommen?

Viele Grüsse
Bäschdler

zu den logeinträgen . letztendlich sicher machbar, da müsstest du halt ein weiteres Freecmd definieren , welches den lofeintrag schreibt . formatierung muss ich mir nachher selber erstmal anschauen.

edit : schau mal hier -> https://forum.fhem.de/index.php/topic,69917.msg614675.html#msg614675 (https://forum.fhem.de/index.php/topic,69917.msg614675.html#msg614675) ... das als freecmd und es sollte gehen.

Zitat
- kann man innerhalb des MSwitch Moduls die (optische) Reihenfolge der Device Actions nachträglich noch ändern ?

derzeit nicht , ist auch nicht wirklich sinnvoll , da es ja 'allgemein' gehalten sein müsste. wonach willst du da sortieren? es alphabetisch ( auch umgekehrt ) zu sortieren wäre kein problem , aber wird in aller regel ja nicht das sein , was gewünscht ist . Die reihenfolge des 'abarbeitens' kannst du mit 'priority' im expertenmodus bearbeiten .

Zitat
- wäre es möglich eine "Überschrift" bzw. einen Kommentar bei dem jeweiligen Device Action-Block einzufügen (ich möchte mir da rein schreiben was die jeweilige Aktion macht)?

... mache ich mir mal einen kopf drüber , in aller regel ist aber jedes affected device ein einzeiler und somit recht durchschaubar .
bei gesetzten Freecmds ist es möglich kommentarzeilen einzusetzen ( # text ; ). ich bin mir nicht wirklich sicher, ob es sinnig ist  die resourcen hier weiter zu belasten ?! das du das attribut 'comment' nutzen kannst , in dieses auch als info angezeigt bekommmst , wenn du das attribut 'MSwitch-Inforoom' nutzt ist dir bewusst ?

edit:bin da gerade hin- und hergerissen , sollte das mehrheitlich für sinnvoll erachtet werden baue ich etwas ein.

Zitat
- kann man einen kompletten MSwitch irgendwie kopieren um quasi dieselbe Funktionalität unter einem anderen Namen und für ein anderes affected device zu bekommen?

ein komplettes 'copy' ist ab der kommenden Version möglich , siehe einen post über deinem (https://forum.fhem.de/index.php/topic,86199.msg840923.html#msg840923 (https://forum.fhem.de/index.php/topic,86199.msg840923.html#msg840923)). alternativ und im grunde nicht als 'öffentliche' Funktion vorgesehen:

wenn du in einem device auf getconfig gehst und in diesem configfile die folgende zeile einbaust

#Q <NAME_zu ersetzendes_device>#irgendein text zur beschreibung#device
wird beim einspielen des Files in ein anderes device eine Abfrage gestartet, gegen welches device das <NAME_zu ersetzendes_device> ersetzt werden soll . damit werden  auch alle abhängigkeiten (conditions die auf dieses gerät verweisten etc. pp.)  ersetzt . das funktionier aber nur für die affected devices, nicht für die triggernden. Geht aber auch für mehrere devices - eine Zeile pro device.

... aber wie gesagt , das ist eine Funktion , eigentlich für mich , um configfiles vernünftig weitergeben zu können .
nutze ich z.B hier:
https://forum.fhem.de/index.php/topic,86199.msg839234.html#msg839234 (https://forum.fhem.de/index.php/topic,86199.msg839234.html#msg839234)

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Bäschdler am 30 September 2018, 23:47:07
Hallo,

Zitat
Zitat

    - kann man innerhalb des MSwitch Moduls die (optische) Reihenfolge der Device Actions nachträglich noch ändern ?


derzeit nicht , ist auch nicht wirklich sinnvoll , da es ja 'allgemein' gehalten sein müsste. wonach willst du da sortieren? es alphabetisch ( auch umgekehrt ) zu sortieren wäre kein problem , aber wird in aller regel ja nicht das sein , was gewünscht ist . Die reihenfolge des 'abarbeitens' kannst du mit 'priority' im expertenmodus bearbeiten .

Ich dachte daran, dass man (optional) die Reihenfolge manuell festlegen kann.

Beispiel:
Ich erstelle für das affected device "Rolladen1" eine 1. action "morgens auf 0%" und "abends mit 5 Minuten Verzögerung auf 100% wenn er auf 10% steht", dann eine 2. action "abends auf 10%".
Der Sinn dahinter ist, dass der Rolladen erst ein Stück runter fährt (als Vorwarnung) und erst dann komplett sofern er nicht manuell hoch gefahren wird.
Sind also schon mal 2 Aktionen für dasselbe Device. Wenn ich jetzt noch nach Wochentagen / Wochenende unterscheiden möchte bin ich bei 4 Aktionen. Dann noch Abschattung, also nochmal 2 dazu.
Diese Aktionen stehen dann in der Reihenfolge untereinander wie ich sie programmiert habe.
Wenn ich jetzt das mit dem Logfile als FreeCMD eintrage (habe ich eben gemacht und bin gespannt ob es so tut wie ich mir das vorstelle) habe ich nochmal weitere 6 Aktionen, auch diese in der Reihenfolge wie programmiert. Jeweils als Block von Fahrbefehlen und Logeinträgen.
ich würde jetzt gerne erst die Action "morgens auf 0%", "abends auf 100%" und danach die Action FreeCMD "logbuch bin auf 0% gefahren", "bin auf 100% gefahren" sehen bevor ich dann die "auf 10% fahren" und "logbuch bin auf 10% gefahren" sehe.

Ich hoffe ich konnte das verständlich ausdrücken ?!?

Wobei mir da gerade auf fällt, dass es natürlich auch äusserst cool wäre, wenn man ein cmd1a, cmd1b, ... für dieselbe condition und dasselbe für 2 natürlich auch eintragen könnte, da bei mir 2 - 3 mal dasselbe unter condition steht und ja quasi durch das selbe triggernde Ereignis mehrere Dinge ausgelöst werden.

Viele Grüsse
Bäschdler
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 01 Oktober 2018, 09:38:00
Moin,

Ich werde mit der Sortierung was machen .. ähnlich wie Priorität und id ... ich habe auch mswitch devices mit teilweise 25+ affected devices .... macht schon Sinn und geht mit ein paar Zeilen code. 

cmd1a,b etc. Ist nicht machbar ... dafür ist die Struktur des Moduls einfach nicht gemacht ... da müsste ich von Grund auf umbauen.

Gruss Byte09



Gesendet von meinem SM-G900F mit Tapatalk

Titel: Antw:98_MSwitch - Support
Beitrag von: Bäschdler am 01 Oktober 2018, 17:18:30
Hi,

ich habe jetzt einfach alle 3 Kommandos unter FreeCMD nacheinander und mit Semikolon getrennt eingetragen und habe damit genau das was ich mit cmd1a, cmd1b,... gemeint habe. Und da ich für das schreiben in's Lofgfile ja sowieso das FreeCMD brauche ist das eine für mich super Lösung.

Damit relativiert sich auch das mit der Sortierung, da ich ja jetzt alle Kommandos "beieinander" habe.

Danke und viele Grüsse
Bäschdler
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 01 Oktober 2018, 17:44:49
Hi,

ich habe jetzt einfach alle 3 Kommandos unter FreeCMD nacheinander und mit Semikolon getrennt eingetragen und habe damit genau das was ich mit cmd1a, cmd1b,... gemeint habe. Und da ich für das schreiben in's Lofgfile ja sowieso das FreeCMD brauche ist das eine für mich super Lösung.

Damit relativiert sich auch das mit der Sortierung, da ich ja jetzt alle Kommandos "beieinander" habe.

Danke und viele Grüsse
Bäschdler

nun ist es mit dem nächsten update drinnen   ;)

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Bäschdler am 01 Oktober 2018, 20:04:57
Super

Vielen Dank.


Ich habe gerade ein "komisches" Verhalten, bin mir aber auch nicht sicher ob es schon mal tat da ich gerade noch am rumprobieren bin.

Folgende Fehlermeldung bekomme ich wenn ich auf "check condition" gehe:
Zitat
eingehender String:
*{twilight("myLocation","sr_weather","04:00","09:30")}

If Anweisung Perl:


Syntaxfehler:
Can't use string ("07:05:52") as a symbol ref while "strict refs" in use at (eval 9010) line 1.

Dann habe ich das selbe mal mit dem Sunset probiert.
Manchmal kommt folgendes (auch bei twilight):
Zitat
eingehender String:*{sunset(0,"15:00","22:00")}If Anweisung Perl:if (ReadingsVal('myLocation', 'azimuth', 'undef')>100 && ReadingsVal('myLocation', 'azimuth', 'undef')<230 && ReadingsVal('OG_WZ_Roll_Balkon_Fahrbefehle', 'state', 'undef') eq "off"){$answer = 'true';} else {$answer = 'false';}
Syntaxfehler:Can't use string ("43:32:43") as a symbol ref while "strict refs" in use at (eval 9077) line 1. States der geprüften Readings:Reading: [OG_WZ_Roll_Balkon_Fahrbefehle:state] - Inhalt: offReading: [myLocation:azimuth] - Inhalt: 276.2Reading: [myLocation:azimuth] - Inhalt: 276.2

meistens kommt das:
Zitat
eingehender String:
*{sunset(0,"15:00","22:00")}

If Anweisung Perl:


Syntaxfehler:
Can't use string ("43:32:43") as a symbol ref while "strict refs" in use at (eval 9079) line 1.

Ich bin aber irgendwie der Meinung das hätte so (egal ob sunset oder twilight) schon getan.
Habe ich da was falsch gemacht?
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 01 Oktober 2018, 20:14:39
ok , thx für die info.

schaue ich mir an , komme aber erst morgen abend dazu.

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 02 Oktober 2018, 05:39:49
Super

Vielen Dank.


Ich habe gerade ein "komisches" Verhalten, bin mir aber auch nicht sicher ob es schon mal tat da ich gerade noch am rumprobieren bin.

Folgende Fehlermeldung bekomme ich wenn ich auf "check condition" gehe:
Dann habe ich das selbe mal mit dem Sunset probiert.
Manchmal kommt folgendes (auch bei twilight):
meistens kommt das:
Ich bin aber irgendwie der Meinung das hätte so (egal ob sunset oder twilight) schon getan.
Habe ich da was falsch gemacht?

habe mir das gerade malangeschaut. die erkennung von sunset ist sehr kleinkariert in bezug auf die syntax ( incl. leerzeichen )  , das werde ich überarbeiten , aber es funktioniert.

in deinem obigen beispiel sieht es aber so aus, als hättest du nur einen zeitpunkt definiert ( oder da hat MSwitch etwas unterschlagen ), als condition wird aber immer ein zeitraum benötigt .

wenn ich z.B folgendes eingebe :
[{ sunset(0,"15:00","22:00") }-{ sunrise("+3600") }]

dann geht es  .

eingehender String:
[{ sunset(0,"15:00","22:00") }-{ sunrise("+3600") }]

If Anweisung Perl:
if ((1514831640 < 1514867940 && 1514867940 < 1514875920)){$answer = 'true';} else {$answer = 'false';}

If Anweisung Perl Klarzeiten:
if ((19:34 < 05:39 && 05:39 < 07:52)){$answer = 'true';} else {$answer = 'false';}

Bedingung ist Wahr und wird ausgeführt

.... oder reden wir jetzt aneinander vorbei ?

gruss BYte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Esjay am 02 Oktober 2018, 11:32:47
Moin Byte09, ich mal wieder.
folgende Version habe ich im Einsatz.

98_MSwitch.pm             17417 2018-09-28 03:52:31Z Byte09 Update zeigt mir keine neuere Version.

Wollte gerade meine beiden Mswitche (Die von dir zur Verfügung gestellten Dimmer) über die Slider in FHEMWEB einstellen, anschließend geht der fhem Prozess auf 100% (per top festgestellt) und nur ein reboot machte fhem wieder bedienbar!

2018.10.02 11:12:26 1: PERL WARNING: Argument "un" isn't numeric in multiplication (*) at ./FHEM/98_MSwitch.pm line 1367.
2018.10.02 11:12:26 1: PERL WARNING: Argument "ef" isn't numeric in multiplication (*) at ./FHEM/98_MSwitch.pm line 1368.
2018.10.02 11:12:26 1: PERL WARNING: substr outside of string at ./FHEM/98_MSwitch.pm line 1369.
2018.10.02 11:12:26 1: PERL WARNING: Use of uninitialized value in multiplication (*) at ./FHEM/98_MSwitch.pm line 1369.
2018.10.02 11:12:26 1: PERL WARNING: Argument "un" isn't numeric in multiplication (*) at ./FHEM/98_MSwitch.pm line 4999.
2018.10.02 11:12:26 1: PERL WARNING: Argument "ef" isn't numeric in multiplication (*) at ./FHEM/98_MSwitch.pm line 5000.
2018.10.02 11:12:26 1: PERL WARNING: substr outside of string at ./FHEM/98_MSwitch.pm line 5001.
2018.10.02 11:12:26 1: PERL WARNING: Use of uninitialized value in multiplication (*) at ./FHEM/98_MSwitch.pm line 5001.
2018.10.02 11:12:32 1: PERL WARNING: Deep recursion on subroutine "main::CallFn" at fhem.pl line 3517.
2018.10.02 11:12:32 1: PERL WARNING: Deep recursion on subroutine "main::CallFn" at fhem.pl line 1807.
2018.10.02 11:12:32 1: PERL WARNING: Deep recursion on subroutine "main::AnalyzeCommandChain" at ./FHEM/98_MSwitch.pm line 5119.
2018.10.02 11:12:32 1: PERL WARNING: Deep recursion on subroutine "main::AnalyzeCommand" at fhem.pl line 1062.
2018.10.02 11:12:32 1: PERL WARNING: Deep recursion on subroutine "main::CommandCmdAlias" at fhem.pl line 1214.
2018.10.02 11:12:32 1: PERL WARNING: Deep recursion on subroutine "main::CommandSet" at ./FHEM/98_cmdalias.pm line 99.
2018.10.02 11:12:32 1: PERL WARNING: Deep recursion on subroutine "main::DoSet" at fhem.pl line 1840.
2018.10.02 11:12:32 1: PERL WARNING: Deep recursion on subroutine "main::MSwitch_Set" at fhem.pl line 3592.

2018.10.02 11:25:10 1: PERL WARNING: Useless use of concatenation (.) or string in void context at ./FHEM/98_MSwitch.pm line 3532, <$fh> line 2020.
2018.10.02 11:25:10 1: PERL WARNING: "my" variable $x masks earlier declaration in same scope at ./FHEM/98_MSwitch.pm line 5894, <$fh> line 2020.
2018.10.02 11:25:12 1: Including ./log/fhem.save

Grüße
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 02 Oktober 2018, 11:38:50
Moin Byte09, ich mal wieder.
folgende Version habe ich im Einsatz.

98_MSwitch.pm             17417 2018-09-28 03:52:31Z Byte09 Update zeigt mir keine neuere Version.

Wollte gerade meine beiden Mswitche (Die von dir zur Verfügung gestellten Dimmer) über die Slider in FHEMWEB einstellen, anschließend geht der fhem Prozess auf 100% (per top festgestellt) und nur ein reboot machte fhem wieder bedienbar!

2018.10.02 11:12:26 1: PERL WARNING: Argument "un" isn't numeric in multiplication (*) at ./FHEM/98_MSwitch.pm line 1367.
2018.10.02 11:12:26 1: PERL WARNING: Argument "ef" isn't numeric in multiplication (*) at ./FHEM/98_MSwitch.pm line 1368.
2018.10.02 11:12:26 1: PERL WARNING: substr outside of string at ./FHEM/98_MSwitch.pm line 1369.
2018.10.02 11:12:26 1: PERL WARNING: Use of uninitialized value in multiplication (*) at ./FHEM/98_MSwitch.pm line 1369.
2018.10.02 11:12:26 1: PERL WARNING: Argument "un" isn't numeric in multiplication (*) at ./FHEM/98_MSwitch.pm line 4999.
2018.10.02 11:12:26 1: PERL WARNING: Argument "ef" isn't numeric in multiplication (*) at ./FHEM/98_MSwitch.pm line 5000.
2018.10.02 11:12:26 1: PERL WARNING: substr outside of string at ./FHEM/98_MSwitch.pm line 5001.
2018.10.02 11:12:26 1: PERL WARNING: Use of uninitialized value in multiplication (*) at ./FHEM/98_MSwitch.pm line 5001.
2018.10.02 11:12:32 1: PERL WARNING: Deep recursion on subroutine "main::CallFn" at fhem.pl line 3517.
2018.10.02 11:12:32 1: PERL WARNING: Deep recursion on subroutine "main::CallFn" at fhem.pl line 1807.
2018.10.02 11:12:32 1: PERL WARNING: Deep recursion on subroutine "main::AnalyzeCommandChain" at ./FHEM/98_MSwitch.pm line 5119.
2018.10.02 11:12:32 1: PERL WARNING: Deep recursion on subroutine "main::AnalyzeCommand" at fhem.pl line 1062.
2018.10.02 11:12:32 1: PERL WARNING: Deep recursion on subroutine "main::CommandCmdAlias" at fhem.pl line 1214.
2018.10.02 11:12:32 1: PERL WARNING: Deep recursion on subroutine "main::CommandSet" at ./FHEM/98_cmdalias.pm line 99.
2018.10.02 11:12:32 1: PERL WARNING: Deep recursion on subroutine "main::DoSet" at fhem.pl line 1840.
2018.10.02 11:12:32 1: PERL WARNING: Deep recursion on subroutine "main::MSwitch_Set" at fhem.pl line 3592.

2018.10.02 11:25:10 1: PERL WARNING: Useless use of concatenation (.) or string in void context at ./FHEM/98_MSwitch.pm line 3532, <$fh> line 2020.
2018.10.02 11:25:10 1: PERL WARNING: "my" variable $x masks earlier declaration in same scope at ./FHEM/98_MSwitch.pm line 5894, <$fh> line 2020.
2018.10.02 11:25:12 1: Including ./log/fhem.save

Grüße

Hi ,

Das ist das gleiche Problem ... zumindest die gleiche Ursache ..., was du die tage schon hattest . Die Ursache habe ich zwischenzeitlich behoben , das update aber noch nicht online gestellt.  Sobald ich heute nachmittag Zuhause bin lasse ich dir    die gefixte version zukommen. 

Gruss Byte09



Gesendet von meinem SM-G900F mit Tapatalk
Titel: Antw:98_MSwitch - Support
Beitrag von: Esjay am 02 Oktober 2018, 11:43:41
Tip Top !

Ich danke dir!

 8)

Grüße
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 02 Oktober 2018, 20:26:03
Tip Top !

Ich danke dir!

 8)

Grüße

hi ,

wollte nur schnell bescheid geben , dass ich es heute nicht mehr schaffe mit der gefixten version , brauche morgen noch 1-2 stunden . sorry.

gruss Byte09

PM konnte ich dir leider nicht schicken .
Titel: Antw:98_MSwitch - Support
Beitrag von: Maista am 03 Oktober 2018, 14:44:48
Moin Byte09

habe im Log folgende Meldung
Zitat
2018.10.02 22:20:04 1: PERL WARNING: Useless use of concatenation (.) or string in void context at ./FHEM/98_MSwitch.pm line 3532, <$fh> line 479.
2018.10.02 22:20:05 1: PERL WARNING: "my" variable $x masks earlier declaration in same scope at ./FHEM/98_MSwitch.pm line 5894, <$fh> line 479.

Gruss Gerd
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 03 Oktober 2018, 18:35:39
Moin Byte09

habe im Log folgende Meldung
Gruss Gerd

danke für den Hinweis, ist in der V2.01 weg. wollte ich eigentlich heute einspielen , leider habe ich mir heute morgen mein aktivsystem zerschosse ( vielmehr hat es sich irgendwie ohne mein zutun zerschossen ) und ich bekomme das problem nicht in den griff ( zigbee2mqtt
 ) . somit steht die Hälfte meiner Sensoren still ... super WAF.

Sobald ich das im Griff habe kümmere ich mich darum , das die Version online kommt .

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Bäschdler am 03 Oktober 2018, 20:00:57
Hi,

also beim sunset / sunrise weiss ich jetzt nicht geau, ich hatte den twilight genau so wie ich ihn jetzt im MSwitch drin habe in einem watchdog drin gehabt der mir den Rolladen gesteuert hat. Da hat's getan (aber ich brauchte halt 2 oder gar 3 watchdog's was ich jetzt durch einen MSwitch mit mehr Funktionalität ablösen will). Den sunset / sunrise aus meinem Beispiel hatte ich so aus der Doku von sunset / sunrise übernommen und testhalber in den MSwitch rein gemacht um zu sehen ob es da auch so ein ähnliches Verhalten gibt.

Was Du allerdings mit
[{ sunset(0,"15:00","22:00") }-{ sunrise("+3600") }]
machen willst verstehe ich jetzt nicht. Vom Sonnenuntergang zwischen 15 Uhr und 22 Uhr wird der Sonnenaufgang + 1 Stunde abgezogen?
Oder verstehe ich den Syntax nicht?

Gruss Bäschdler

Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 03 Oktober 2018, 20:28:32
Hi,

also beim sunset / sunrise weiss ich jetzt nicht geau, ich hatte den twilight genau so wie ich ihn jetzt im MSwitch drin habe in einem watchdog drin gehabt der mir den Rolladen gesteuert hat. Da hat's getan (aber ich brauchte halt 2 oder gar 3 watchdog's was ich jetzt durch einen MSwitch mit mehr Funktionalität ablösen will). Den sunset / sunrise aus meinem Beispiel hatte ich so aus der Doku von sunset / sunrise übernommen und testhalber in den MSwitch rein gemacht um zu sehen ob es da auch so ein ähnliches Verhalten gibt.

Was Du allerdings mit
[{ sunset(0,"15:00","22:00") }-{ sunrise("+3600") }]
machen willst verstehe ich jetzt nicht. Vom Sonnenuntergang zwischen 15 Uhr und 22 Uhr wird der Sonnenaufgang + 1 Stunde abgezogen?
Oder verstehe ich den Syntax nicht?

Gruss Bäschdler

wenn du es in zusammenhang mit conditions meinst ist es ein zeitraum : [zeit1-zeit2] ( zei1 bis zeit2 )

eingehender String:
[{ sunset(0,"15:00","22:00") }-{ sunrise("+3600") }]

If Anweisung Perl:
if ((1515004200 < 1515007740 && 1515007740 < 1515048900)){$answer = 'true';} else {$answer = 'false';}

If Anweisung Perl Klarzeiten:
if ((19:30 < 20:29 && 20:29 < 07:55)){$answer = 'true';} else {$answer = 'false';}

Bedingung ist Wahr und wird ausgeführt

oder redest du garnicht von conditions , sondern von einem zeitschaltpunt ?
Zitat
Folgende Fehlermeldung bekomme ich wenn ich auf "check condition" gehe:

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 04 Oktober 2018, 20:00:43
V2.01 ist ab morgen verfügbar.

- Rename eines MSwitch Devices - Fehler behoben
- Copy eines MSwitch Devices ist nun möglich - alle daten werden übernommen , nicht nur die 'Hülle'
- regex für die Conditions überarbeitet / Ensatz von z.B twilight etc. ist nun möglich
- Fehler inm Zusammenhang mit 'undef' in den delays behoben

Die angedachte Sortierreihenfolge in der Webansicht habe ich doch verworfen ( zumindest vorerst ) .

ACHTUNG: ich habe hier mal ein MSwitch eingestellt, welches auf das globale EVENT 'renamed' reagiert hat und von einem Rename betroffene devices innerhalb eines MSwitch-Devices angepassst hat . Dieses darf während eines Renames eines MSwitch-devices keinesfalls aktiv sein , das wird unweigerlich zum Totalverlust ALLER gespeicherten MSwitches führen.

Dieses bitte unbedingt löschen , ich werde hier in den kommenden Tagen ein überarbeitetes MSwitch mit dieser Funktion einstellen.

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 04 Oktober 2018, 20:16:12
@Esjay

der Fehler, der bei dir aufgetreten ist , ist ganz schwierig reproduzierbar . Die Änderungen die ich diesbezüglich gemacht habe basieren somit eher auf Vermutungen . Ich haffe, dass es behoben ist , würde im Augenblick aber nicht die Hand dafür insFeuer legen .

Info Allgemein: dieser Fehler betrifft nur ein ganz spezielles MSwitch , mit Sonderfunktionen !

Gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Esjay am 04 Oktober 2018, 20:32:59
@Esjay

der Fehler, der bei dir aufgetreten ist , ist ganz schwierig reproduzierbar . Die Änderungen die ich diesbezüglich gemacht habe basieren somit eher auf Vermutungen . Ich haffe, dass es behoben ist , würde im Augenblick aber nicht die Hand dafür insFeuer legen .

Info Allgemein: dieser Fehler betrifft nur ein ganz spezielles MSwitch , mit Sonderfunktionen !

Gruss Byte09

Kein Thema, ich werde weiter testen, und wenn es Probleme gibt sage ich bescheid!

Grüße
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 07 Oktober 2018, 10:28:49
kommende Version 2.02

in der kommenden Version gibt es einen neuen Befehl
set <DEVICE> change_renamed <NAMEOLD> <NAMENEW>
Hintergund:
bisher gab es ein MSwitchdevice, was automatisch auf Namensänderungen von Devices reagiert hat. Da diese Funktion sehr stark von der aktuellen 'Version_Datenstruktur' ahängig ist , ist dieses Device nicht mehr nutzbar.

um bei zukünftigen Änderungen darauf reagieren (und das anpassen)  zu können , habe ich eine Funktion , die sowieso schon vorhanden war, mit diesem Befehl zugänglich gemacht.

Dieser Befehl ändert alle im MSwitch vorkommenden Devices <NAME> in <NAME1>. Das betrifft die 'affected_devices' sowie alle vorkommenden Verweise in conditions etc. und das triggerde Device.

Da diese Funktion nicht automatisch ausgelöst werden kann /soll - jedes MSwitch-Device müsste permanent auf alle globalen Events 'lauschen' , muss dieses erstmal manuell ausgeführt werden .

Zusätzlich werde ich wieder ein MSwitch bereitstellen , was diese Überwachung übernimmt ( und bei Vorkommen ) entsprechend warnt und/oder diese Änderung automatisch veranlasst.

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Bäschdler am 08 Oktober 2018, 14:27:50
Zitat
oder redest du garnicht von conditions , sondern von einem zeitschaltpunt ?

Ich bin darüber gestolpert, dass sunrise und sunset in demselben statement verwendet waren. Aber ich habe es jetzt so wie ich es wollte  :) und kann die Zeitpunkte (-räume) von sunset / sunrise mit entsprechenden offsetwerten berechnen.

Jetzt habe ich mir ein MSwich Device gebaut das 11 Free command's hat in denen ich abhängig von Sonnenaufgang, Helligkeit und Azimuth einen Dummy mit entsprechendem (aufsteigendem) Wert befüllt. Leider kann ich jetzt keine 12. (und weitere) Action für FreeCMD mehr hinzufügen. Ist das "gewollt" oder ist da noch eine Begrenzung drin die aus einem "alten" Entwicklungsstand her kommt?

Viele Grüsse
Bäschdler
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 08 Oktober 2018, 14:34:16
Hi ,

Ganz ehrlich .... ich habe im Moment keine Ahnung warum er kein 12tes nimmt. Habe ich noch nicht gemacht , gebundene befehle habe ich weit über 20.

Ich schaue mir das an , wenn ich nach hause komme und gebe dir dann Bescheid , bzw fixe es falls nötig.

Poste mir doch bitte mal die raw definition des Devices bzw den config file.

Gruss Byte09

Gesendet von meinem SM-G900F mit Tapatalk
Titel: Antw:98_MSwitch - Support
Beitrag von: Bäschdler am 08 Oktober 2018, 14:43:58
Ich habe gerade entdeckt, dass die neuen actions doch angelegt wurden.

Bis action "11" war es so, dass die neue action immer am Ende angefügt wurde. Da habe ich jedes Mal auch hin gescrollt und daher nicht gesehen, dass die neue (leere) action an der zweiten Stelle eingefügt wurde. Da habe ich jetzt 4 leere action's, kann daher nicht sagen ob jetzt immer bei 2 eingefügt wurde (und dann die älteren wieder nach unten gerutscht sind) oder ob die nächste neue dann bei 3, 4, 5 eingefügt wurde. Aber jetzt kann ich weiter machen.

Gibt's jetzt schon die Möglichkeit die action's (manuell) zu sortieren? Wenn nicht ist nicht schlimm, wenn ja: wie kann man das machen?

Und dann noch die Frage: Wie kopiere ich einen MSwich? Habe ich da nicht alles gelesen oder bin ich einfach zu blind um die Funktion zu finden?


Danke und Grüsse
Bäschdler
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 08 Oktober 2018, 15:05:26
Sortieren geht noch nicht. Kopieren ganz normal über fhem

Copy mswitch mswitchcopy.

Die Kopie wird automatisch auf disable 1 gesetzt

Gruss Byte09

Gesendet von meinem SM-G900F mit Tapatalk

Titel: Antw:98_MSwitch - Support
Beitrag von: Bäschdler am 10 Oktober 2018, 20:13:38
Ich zweifle gerade entweder an meinen Programmierkünsten oder am MSwitch:

Folgendes habe ich als condition:
Zitat
eingehender String:
[{ sunset(0,"17:00","21:30") }-23:59] AND [Rolladen_Aktionen:state] < 570

If Anweisung Perl:
if ((1515608040 < 1515611160 && 1515611160 < 1515625140) && ReadingsVal('Rolladen_Aktionen', 'state', '00:00:00') < 570){$answer = 'true';} else {$answer = 'false';}

If Anweisung Perl Klarzeiten:
if ((19:14 < 20:06 && 20:06 < 23:59) && ReadingsVal('Rolladen_Aktionen', 'state', '00:00:00') < 570){$answer = 'true';} else {$answer = 'false';}

Bedingung ist Wahr und wird ausgeführt

States der geprüften Readings:
Reading: [Rolladen_Aktionen:state] - Inhalt: 102

Das cmd ist eigentlich ganz einfach:
set Rolladen_Aktionen 570

Rolladen_Aktionen ist ein Dummy

Trotzdem der MSwitch bei "check conditions" ausspuckt, dass die Bedingung wahr ist wird der Dummy leider nicht auf 570 gesetzt.

Hat mir jemand einen Tipp was das falsch läuft?
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 10 Oktober 2018, 22:41:44
Hi ,

Bin bis morgen abend unterwegs , kann es mir leider erst dann anschauen.

Scalte das Device doch mal auf debug 3 und stelle das interne log hier ein . Ggf. Kann ich auf dem Handy was erkennen.

Was löst denn das Device überhaupt aus ? Ein event oder zu einer bestimmten Zeit ?

Gruss Byte09

Gesendet von meinem SM-G900F mit Tapatalk
Titel: Antw:98_MSwitch - Support
Beitrag von: pflock_y am 11 Oktober 2018, 07:26:38
Guten Morgen zusammen,

ich versuch schon seit gestern mir einen MSwitch zu bauen, aber irgendwie steh ich auf dem Schlauch. Er macht nicht das was ich möchte. Ich vermute aber das der Fehler 40cm vor dem Bildschirm sitzt,  :-\

Also:
Ich hab im Keller einen Fensterkontakt (Homematic HmIP-SRH), einen Temperatur und Luftfeuchtesensor und einen Entfeuchter der über eine 433MHz Steckdose angeschlossen ist.
Der Entfeuchter soll an gehen sobald die Luftfeuchtigkeit über 69% steigt, aus gehen soll der Entfeuchter sobald 62% erreicht sind. Soweit geht es auch. Jetzt soll der Entfeuchter nicht angehen wenn das Fenster offen oder gekippt ist. Ist das Fenster geschlossen und die Feuchtigkeit bei 69% soll er angeschaltet werden.

Zur zeit hab ich es mit Dummys für Fenster und Entfeuchter versucht nachzustellen. Vom Büro aus öffnet sich das Fenster schlecht,  :)

config des MSwitch:

#V V2.01
#VS V2.00
#S .Device_Affected -> Entfeuchter-AbsCmd1,brennenstuhl_00110_1-AbsCmd1,test_Dummy-AbsCmd1
#S .Device_Affected_Details -> Entfeuchter-AbsCmd1#[NF]no_action#[NF]no_action#[NF]#[NF]#[NF]delay1#[NF]delay1#[NF]00:00:00#[NF]00:00:00#[NF]#[NF]#[NF]#[NF]#[NF]1#[NF]0#[ND]brennenstuhl_00110_1-AbsCmd1#[NF]no_action#[NF]no_action#[NF]#[NF]#[NF]delay1#[NF]delay1#[NF]00:00:00#[NF]00:00:00#[NF]#[NF]#[NF]#[NF]#[NF]1#[NF]0#[ND]test_Dummy-AbsCmd1#[NF]on#[NF]off#[NF]#[NF]#[NF]delay1#[NF]delay1#[NF]00:00:00#[NF]00:00:00#[NF][FensterTestDummy:state] eq "closed"#[NF][FensterTestDummy:state] eq "open"#[NF]#[NF]#[NF]1#[NF]0
#S .Device_Events -> state:T: 20.8 H: 60 dewpoint:12.6 D:12.4 D:12.6 dewpoint:12.8 humidity:59 temperature:20.8 temperature:20.7 temperature:20.9 state:T: 20.5 H: 61 D:12.2 dewpoint:12.2 state:T: 20.2 H: 61 temperature:20.3 dewpoint:12.7 state:T: 20.3 H: 61 temperature:20.6 state:closed state:T: 20.5 H: 59 state:T: 20.7 H: 60 humidity:61 state:T: 20.9 H: 60 D:12.7 D:12.8 humidity:60 humidity:58 battery:ok state:open dewpoint:12.5 state:T: 20.6 H: 60 humidity:69 no_trigger temperature:20.4 temperature:20.5 D:12.5
#S .First_init -> done
#S .Trigger_Whitelist -> undef
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> no_trigger
#S .Trigger_condition ->
#S .Trigger_off -> humidity:58
#S .Trigger_on -> humidity:60
#S .Trigger_time ->
#S .V_Check -> V2.00
#S Trigger_device -> TempundHumi_KG_rechts
#S Trigger_log -> on
#S last_event -> Entfeuchtet_MSwitch:on_with_Parameter:humidity:60
#S .sysconf -> undef
#S state -> on
#S Sys_Extension -> undef
#A MSwitch_Help -> 1
#A MSwitch_Expert -> 0
#A MSwitch_Lock_Quickedit -> 1
#A MSwitch_Activate_MSwitchcmds -> 1
#A MSwitch_Include_Webcmds -> 1
#A MSwitch_Mode -> Full
#A MSwitch_Include_MSwitchcmds -> 1
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A MSwitch_Extensions -> 0
#A MSwitch_Inforoom -> MSwitch
#A MSwitch_Delete_Delays -> 1
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Debug -> 0


Ich hoffe ihr könnt helfen!!!



Grüße
pflock_y
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 11 Oktober 2018, 09:10:56
Hi .

Ich schaue heute abend drüber , wenn ich wieder zu hause bin.



Soweit ich das jetzt am Handy sehen kann schaltest du bei humidity:62 an und bei humidity:58 aus. Damitschaltet er such nur dann , wenn genau diese Werte als event ankommen.   Du solltest auf generelle Änderungen des Readings reagieren ... humidity:.*  und eine abfrage ob größer oder kleiner bestimmter wert dann in den condition machen

Gruss Byte09

Gesendet von meinem SM-G900F mit Tapatalk
Titel: Antw:98_MSwitch - Support
Beitrag von: pflock_y am 11 Oktober 2018, 11:32:55
ja super, mach entspannt.

so hatte ich es schon probiert, bestimmt aber nicht richtig!!

danke und grüße
pflock_y
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 11 Oktober 2018, 19:00:46
Guten Morgen zusammen,

ich versuch schon seit gestern mir einen MSwitch zu bauen, aber irgendwie steh ich auf dem Schlauch. Er macht nicht das was ich möchte. Ich vermute aber das der Fehler 40cm vor dem Bildschirm sitzt,  :-\

Also:
Ich hab im Keller einen Fensterkontakt (Homematic HmIP-SRH), einen Temperatur und Luftfeuchtesensor und einen Entfeuchter der über eine 433MHz Steckdose angeschlossen ist.
Der Entfeuchter soll an gehen sobald die Luftfeuchtigkeit über 69% steigt, aus gehen soll der Entfeuchter sobald 62% erreicht sind. Soweit geht es auch. Jetzt soll der Entfeuchter nicht angehen wenn das Fenster offen oder gekippt ist. Ist das Fenster geschlossen und die Feuchtigkeit bei 69% soll er angeschaltet werden.

Zur zeit hab ich es mit Dummys für Fenster und Entfeuchter versucht nachzustellen. Vom Büro aus öffnet sich das Fenster schlecht,  :)

config des MSwitch:

#V V2.01
#VS V2.00
#S .Device_Affected -> Entfeuchter-AbsCmd1,brennenstuhl_00110_1-AbsCmd1,test_Dummy-AbsCmd1
#S .Device_Affected_Details -> Entfeuchter-AbsCmd1#[NF]no_action#[NF]no_action#[NF]#[NF]#[NF]delay1#[NF]delay1#[NF]00:00:00#[NF]00:00:00#[NF]#[NF]#[NF]#[NF]#[NF]1#[NF]0#[ND]brennenstuhl_00110_1-AbsCmd1#[NF]no_action#[NF]no_action#[NF]#[NF]#[NF]delay1#[NF]delay1#[NF]00:00:00#[NF]00:00:00#[NF]#[NF]#[NF]#[NF]#[NF]1#[NF]0#[ND]test_Dummy-AbsCmd1#[NF]on#[NF]off#[NF]#[NF]#[NF]delay1#[NF]delay1#[NF]00:00:00#[NF]00:00:00#[NF][FensterTestDummy:state] eq "closed"#[NF][FensterTestDummy:state] eq "open"#[NF]#[NF]#[NF]1#[NF]0
#S .Device_Events -> state:T: 20.8 H: 60 dewpoint:12.6 D:12.4 D:12.6 dewpoint:12.8 humidity:59 temperature:20.8 temperature:20.7 temperature:20.9 state:T: 20.5 H: 61 D:12.2 dewpoint:12.2 state:T: 20.2 H: 61 temperature:20.3 dewpoint:12.7 state:T: 20.3 H: 61 temperature:20.6 state:closed state:T: 20.5 H: 59 state:T: 20.7 H: 60 humidity:61 state:T: 20.9 H: 60 D:12.7 D:12.8 humidity:60 humidity:58 battery:ok state:open dewpoint:12.5 state:T: 20.6 H: 60 humidity:69 no_trigger temperature:20.4 temperature:20.5 D:12.5
#S .First_init -> done
#S .Trigger_Whitelist -> undef
#S .Trigger_cmd_off -> no_trigger
#S .Trigger_cmd_on -> no_trigger
#S .Trigger_condition ->
#S .Trigger_off -> humidity:58
#S .Trigger_on -> humidity:60
#S .Trigger_time ->
#S .V_Check -> V2.00
#S Trigger_device -> TempundHumi_KG_rechts
#S Trigger_log -> on
#S last_event -> Entfeuchtet_MSwitch:on_with_Parameter:humidity:60
#S .sysconf -> undef
#S state -> on
#S Sys_Extension -> undef
#A MSwitch_Help -> 1
#A MSwitch_Expert -> 0
#A MSwitch_Lock_Quickedit -> 1
#A MSwitch_Activate_MSwitchcmds -> 1
#A MSwitch_Include_Webcmds -> 1
#A MSwitch_Mode -> Full
#A MSwitch_Include_MSwitchcmds -> 1
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A MSwitch_Extensions -> 0
#A MSwitch_Inforoom -> MSwitch
#A MSwitch_Delete_Delays -> 1
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Debug -> 0


Ich hoffe ihr könnt helfen!!!



Grüße
pflock_y

hi ,

habe mir das gerade mal angeschaut.

hier mal eine funktionierende konfiguration, anhand derer du die funktionsweise nachvollziehen kannst. Die von dir vorgegebenen Dummys müssen vorhanden sein.

schau es dir einfach mal an , wenn dann fragen sind melde dich gerne.

Das Device habe ich in den Notifymode gesetzt , da es wesentlich einfacher zu konfigurieren ist . im Fullmode müsstest du bei den triggernden events schon mit regex arbeiten , da cmd1 und cmd2 nicht das gleiche event beinhalten darf, cmd3 und cmd4 schon. die genaue unterscheidung erfolgt dann in den conditions der ausgeführten zweige.

#V Arbeitsversion
#VS V2.00
#S .Device_Affected -> test_Dummy-AbsCmd1
#S .Device_Affected_Details -> test_Dummy-AbsCmd1#[NF]on#[NF]off#[NF]#[NF]#[NF]delay1#[NF]delay1#[NF]00:00:00#[NF]00:00:00#[NF][FensterTestDummy:state] eq "closed" AND [$EVTPART3] > 69#[NF][$EVTPART3] < 62#[NF]#[NF]#[NF]1#[NF]0
#S .Device_Events -> humidity:60 humidity:.* state:humidity 30 humidity:30 humidity:70
#S .First_init -> done
#S .Trigger_Whitelist -> undef
#S .Trigger_cmd_off -> humidity:.*
#S .Trigger_cmd_on -> humidity:.*
#S .Trigger_condition -> undef
#S .Trigger_off -> no_trigger
#S .Trigger_on -> no_trigger
#S .Trigger_time -> undef
#S .V_Check -> V2.00
#S Trigger_device -> TempundHumi_KG_rechts
#S Trigger_log -> on
#S last_event -> humidity:60
#S .sysconf -> undef
#S state -> active
#S Sys_Extension -> undef
#A MSwitch_Ignore_Types -> notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
#A MSwitch_Debug -> 0
#A room -> 1_test
#A MSwitch_Inforoom -> MSwitch
#A MSwitch_Include_Webcmds -> 1
#A MSwitch_Expert -> 0
#A MSwitch_Delete_Delays -> 1
#A MSwitch_Lock_Quickedit -> 1
#A MSwitch_Help -> 1
#A MSwitch_Include_Devicecmds -> 1
#A MSwitch_Mode -> Notify
#A MSwitch_Include_MSwitchcmds -> 1
#A MSwitch_Activate_MSwitchcmds -> 1
#A MSwitch_Extensions -> 0

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: pflock_y am 11 Oktober 2018, 19:43:18
nabend Byte09,

super vielen Dank für die Hilfe, soweit funktioniert der MSwitch.  ;D

Einzig der Status des FensterTestDummy "open" wurde nicht getriggert, ich hab es bei  'cmd2' condition: noch mit eingebaut und zum testen die Werte für humidity runter gesetzt.

Jetzt werd ich die Dummys gegen die "echten Geräte" ersetzen, bin gespannt und berichte

Dank und Gruß
pflock_y
Titel: Antw:98_MSwitch - Support
Beitrag von: pflock_y am 11 Oktober 2018, 20:08:04
nur der Vollständigkeit halber:

Ich hab noch den tilted Status des Fensters im 'cmd2' condition: eingefügt

[FK_Keller_rechts_F_links:state] eq "open" OR [FK_Keller_rechts_F_links:state] eq "tilted" OR [$EVTPART3] < 62
und auch die "echten" Werte für Luftfeuchtigkeit geändert. Beim nächsten Wäsche trocknen im Keller wird sich zeigen ob es auch unter realen Bedingungen funktioniert,  :)

Auf den MSwitch_Mode Notify wär ich allein nie gekommen!!!

Danke nochmals und Grüße
pflock_y
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 12 Oktober 2018, 10:08:50
V2.01a ab morgen im SVN

um Supportanfragen zu vereinfachen habe ich in dieser Zwischenversion das Kommando 'get <DEVICE> get_support_site' eingefügt.

Bei zukünftigen Supportanfragen wäre es Hilfreich , wenn dieses genuzt würde und entsprechende Daten mit der Anfrage eingestellt werden ( erspart auch das posten von screenshots und somit datenlast im Forum ) .

Die angeforderten Daten sehen dann wie folgt aus:
Modulversion: Arbeitsversion
Datenstruktur: V2.00

----- Devicename -----
usertest

----- Attribute -----
Attribut MSwitch_Mode: Notify
Attribut MSwitch_Delete_Delays: 1
Attribut MSwitch_Ignore_Types: notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
Attribut MSwitch_Expert: 0
Attribut MSwitch_Inforoom: MSwitch
Attribut MSwitch_Extensions: 0
Attribut MSwitch_Help: 1
Attribut MSwitch_Debug: 0
Attribut MSwitch_Lock_Quickedit: 1
Attribut MSwitch_Include_MSwitchcmds: 1
Attribut MSwitch_Include_Webcmds: 1
Attribut room: 1_test
Attribut MSwitch_Activate_MSwitchcmds: 1
Attribut MSwitch_Include_Devicecmds: 1

----- Trigger -----
Trigger device:  TempundHumi_KG_rechts
Trigger time: undef
Trigger condition: undef
Trigger Device Global Whitelist: undef

----- Trigger Details -----
Trigger cmd1: no_trigger
Trigger cmd2: no_trigger
Trigger cmd3: humidity:.*
Trigger cmd4: humidity:.*

----- Device Actions -----

Device: test_Dummy-AbsCmd1
cmd1: on
cmd2: off
cmd1 condition: [FensterTestDummy:state] eq "closed" AND [$EVTPART3] > 69
cmd2 condition: [$EVTPART3] < 62
cmd1 delay: 00:00:00
cmd2 delay: 00:00:00
repeats:
repeats delay:
priority: 1
id: 0

Gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 13 Oktober 2018, 09:47:06
ich habe für die nächste Version doch einen früheren Vorschlag/Bitte aufgegriffen und es wird eine Kommentarfunktion geben , die es erlaubt jedes 'affected device' mit einem kommentar zu versehen . Bei grossen Mswitches ist es doch Hilfreich , um die Übersicht zuu behalten.

Die Funktion muss in jedem Mswitch per attribut ( MSwitch_Comments = 1  ) aktiviert werden.

gruss Byte09

Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 14 Oktober 2018, 10:11:12
weitere neuerung in kommender v2.02

ab dieser version gibt es die möglichkeit einer abbruchoption in den 'affected devices' im expertenmode. das bedeutet , wenn entsprechender befehl ( in abhängigkeit der conditions ) ausgeführt wird , wird das programm danach abgebrochen und die folgenden befehle werden nicht mehr ausgeführt.

im zusammenhang mit der 'priorityfuktion' werden nachfolgende befehle nur dann abgearbeitet, wenn vorheriger befehl nicht ausgeführt wurde . Somit stellt dieses im grunde eine 'elsif' funktion dar.

gruss Byte09

Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 14 Oktober 2018, 13:12:01
die Versio 2.02 steht jetzt zum Update im GIT.

wer sie probieren möchte , kann sie mit folgendem Befehl einspielen:

update all https://raw.githubusercontent.com/Byte009/FHEM-MSwitch/master/controls_mswitch.txt
Falls es Probleme gibt , ist mit normalem Fhemupdate ein 'zurück' auf 2.01 möglich , da die Datenstruktur unverändert ist.

nach dem update muss zwingend ein Fhemneustart durchgeführt werden.

bei Problemen wäre eine kurze Info hilfreich .

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 15 Oktober 2018, 13:24:17
...

Gibt's jetzt schon die Möglichkeit die action's (manuell) zu sortieren? Wenn nicht ist nicht schlimm, wenn ja: wie kann man das machen?

...

Danke und Grüsse
Bäschdler

ich habe nochmals ein Update der Testversion im GIT gemacht. V 2.02a_Test.

in dieser Version lässt sich die Ansicht der 'affected_devicec' nun sortieren.
derzeit stehen folgende sortierungen zur verfügung:

none - ansicht entspricht der reihenfolge, in der die befehle abgearbeitet werden.

field show - ansicht wir anhand der einträge im Feld 'Show' sortiert . dieses Feld hat keinen einfluss auf die reihenfolge der abarbeitung und kann beliebig geändert werden.

field priority (nur im experten-mode verfügbar) - ansicht wir anhand der einträge im Feld 'Show' sortiert . dieses Feld beinflusst die reihenfolge der abarbeitung der Befehle ( nur in bestimmten fällen benötigt )

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Bäschdler am 15 Oktober 2018, 19:42:31
Hallo,

sorry ich hab' momentan noch viel anderes um die Ohren und komme daher immer nur "nebenher" zum ausprobieren und ändern :-(

Folgendes steht im Logfile (DebigMode 3):
Zitat
Mon Oct 15 19:25:55 2018 Starte Log
Mon Oct 15 19:25:55 2018: -> ----------------------------------------
Mon Oct 15 19:25:55 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> global
Mon Oct 15 19:25:55 2018: -> ----------------------------------------
Mon Oct 15 19:25:55 2018: -> ----------------------------------------
Mon Oct 15 19:25:55 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> global
Mon Oct 15 19:25:55 2018: -> ----------------------------------------
Mon Oct 15 19:25:55 2018: -> ----------------------------------------
Mon Oct 15 19:25:55 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> global
Mon Oct 15 19:25:55 2018: -> ----------------------------------------
Mon Oct 15 19:25:55 2018: -> ----------------------------------------
Mon Oct 15 19:25:55 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> global
Mon Oct 15 19:25:55 2018: -> ----------------------------------------
Mon Oct 15 19:25:55 2018: -> ----------------------------------------
Mon Oct 15 19:25:55 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> global
Mon Oct 15 19:25:55 2018: -> ----------------------------------------
Mon Oct 15 19:25:55 2018: -> ----------------------------------------
Mon Oct 15 19:25:55 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> global
Mon Oct 15 19:25:55 2018: -> ----------------------------------------
Mon Oct 15 19:25:55 2018: -> ----------------------------------------
Mon Oct 15 19:25:55 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> global
Mon Oct 15 19:25:55 2018: -> ----------------------------------------
Mon Oct 15 19:25:55 2018: -> ----------------------------------------
Mon Oct 15 19:25:55 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> global
Mon Oct 15 19:25:55 2018: -> ----------------------------------------
Mon Oct 15 19:25:55 2018: -> ----------------------------------------
Mon Oct 15 19:25:55 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> global
Mon Oct 15 19:25:55 2018: -> ----------------------------------------
Mon Oct 15 19:25:55 2018: -> ----------------------------------------
Mon Oct 15 19:25:55 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> global
Mon Oct 15 19:25:55 2018: -> ----------------------------------------
Mon Oct 15 19:25:55 2018: -> ----------------------------------------
Mon Oct 15 19:25:55 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> global
Mon Oct 15 19:25:55 2018: -> ----------------------------------------
Mon Oct 15 19:25:55 2018: -> ----------------------------------------
Mon Oct 15 19:25:55 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> global
Mon Oct 15 19:25:55 2018: -> ----------------------------------------
Mon Oct 15 19:25:55 2018: -> ----------------------------------------
Mon Oct 15 19:25:55 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> global
Mon Oct 15 19:25:55 2018: -> ----------------------------------------
Mon Oct 15 19:25:56 2018: -> ----------------------------------------
Mon Oct 15 19:25:56 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> global
Mon Oct 15 19:25:56 2018: -> ----------------------------------------
Mon Oct 15 19:25:56 2018: -> ----------------------------------------
Mon Oct 15 19:25:56 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> myHmUART
Mon Oct 15 19:25:56 2018: -> ----------------------------------------
Mon Oct 15 19:25:58 2018: -> ----------------------------------------
Mon Oct 15 19:25:58 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> myHmUART
Mon Oct 15 19:25:58 2018: -> ----------------------------------------
Mon Oct 15 19:25:58 2018: -> ----------------------------------------
Mon Oct 15 19:25:58 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> myHmUART
Mon Oct 15 19:25:58 2018: -> ----------------------------------------
Mon Oct 15 19:25:58 2018: -> ----------------------------------------
Mon Oct 15 19:25:58 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> myHmUART
Mon Oct 15 19:25:58 2018: -> ----------------------------------------
Mon Oct 15 19:25:58 2018: -> ----------------------------------------
Mon Oct 15 19:25:58 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> myHmUART
Mon Oct 15 19:25:58 2018: -> ----------------------------------------
Mon Oct 15 19:25:58 2018: -> ----------------------------------------
Mon Oct 15 19:25:58 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> myHmUART
Mon Oct 15 19:25:58 2018: -> ----------------------------------------
Mon Oct 15 19:26:00 2018: -> ----------------------------------------
Mon Oct 15 19:26:00 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> OG_Buero_Hzg
Mon Oct 15 19:26:00 2018: -> ----------------------------------------
Mon Oct 15 19:26:00 2018: -> ----------------------------------------
Mon Oct 15 19:26:00 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> OG_Buero_Hzg_Clima
Mon Oct 15 19:26:00 2018: -> ----------------------------------------
Mon Oct 15 19:26:00 2018: -> ----------------------------------------
Mon Oct 15 19:26:00 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> OG_Buero_Hzg_Weather
Mon Oct 15 19:26:00 2018: -> ----------------------------------------
Mon Oct 15 19:26:00 2018: -> ----------------------------------------
Mon Oct 15 19:26:00 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> OG_Buero_Hzg
Mon Oct 15 19:26:00 2018: -> ----------------------------------------
Mon Oct 15 19:26:00 2018: -> ----------------------------------------
Mon Oct 15 19:26:00 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> ActionDetector
Mon Oct 15 19:26:00 2018: -> ----------------------------------------
Mon Oct 15 19:26:01 2018: -> ----------------------------------------
Mon Oct 15 19:26:01 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> OG_WZ_Hzg_Hof
Mon Oct 15 19:26:01 2018: -> ----------------------------------------
Mon Oct 15 19:26:01 2018: -> ----------------------------------------
Mon Oct 15 19:26:01 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> ActionDetector
Mon Oct 15 19:26:01 2018: -> ----------------------------------------
Mon Oct 15 19:26:03 2018: -> ----------------------------------------
Mon Oct 15 19:26:03 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> EG_SZ_Roll_Strasse
Mon Oct 15 19:26:03 2018: -> ----------------------------------------
Mon Oct 15 19:26:03 2018: -> ----------------------------------------
Mon Oct 15 19:26:03 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> EG_SZ_Roll_Alle
Mon Oct 15 19:26:03 2018: -> ----------------------------------------
Mon Oct 15 19:26:05 2018: -> ----------------------------------------
Mon Oct 15 19:26:05 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> EG_WZ_Roll_Hof
Mon Oct 15 19:26:05 2018: -> ----------------------------------------
Mon Oct 15 19:26:05 2018: -> ----------------------------------------
Mon Oct 15 19:26:05 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> EG_WZ_Roll_Alle
Mon Oct 15 19:26:05 2018: -> ----------------------------------------
Mon Oct 15 19:26:06 2018: -> ----------------------------------------
Mon Oct 15 19:26:06 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> OG_Buero_Roll_Garten
Mon Oct 15 19:26:06 2018: -> ----------------------------------------
Mon Oct 15 19:26:06 2018: -> ----------------------------------------
Mon Oct 15 19:26:06 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> OG_Buero_Roll_Alle
Mon Oct 15 19:26:06 2018: -> ----------------------------------------
Mon Oct 15 19:26:07 2018: -> ----------------------------------------
Mon Oct 15 19:26:07 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> OG_KiZ_Roll
Mon Oct 15 19:26:07 2018: -> ----------------------------------------
Mon Oct 15 19:26:08 2018: -> ----------------------------------------
Mon Oct 15 19:26:08 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> OG_SZ_Roll_Hof
Mon Oct 15 19:26:08 2018: -> ----------------------------------------
Mon Oct 15 19:26:08 2018: -> ----------------------------------------
Mon Oct 15 19:26:08 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> OG_SZ_Roll_Alle
Mon Oct 15 19:26:08 2018: -> ----------------------------------------
Mon Oct 15 19:26:09 2018: -> ----------------------------------------
Mon Oct 15 19:26:09 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> meinWetter
Mon Oct 15 19:26:09 2018: -> ----------------------------------------
Mon Oct 15 19:26:09 2018: -> ----------------------------------------
Mon Oct 15 19:26:09 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> Wetterbedingungen_fuer_Abschattung
Mon Oct 15 19:26:09 2018: -> ----------------------------------------
Mon Oct 15 19:26:09 2018: -> ----------------------------------------
Mon Oct 15 19:26:09 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> man_log_FileLog_meinWetter
Mon Oct 15 19:26:09 2018: -> ----------------------------------------
Mon Oct 15 19:26:09 2018: -> ----------------------------------------
Mon Oct 15 19:26:09 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> Wetter_fuer_Abschattung
Mon Oct 15 19:26:09 2018: -> ----------------------------------------
Mon Oct 15 19:26:09 2018: -> ----------------------------------------
Mon Oct 15 19:26:09 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> OG_SZ_Roll_Strasse
Mon Oct 15 19:26:09 2018: -> ----------------------------------------
Mon Oct 15 19:26:09 2018: -> ----------------------------------------
Mon Oct 15 19:26:09 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> OG_SZ_Roll_Alle
Mon Oct 15 19:26:09 2018: -> ----------------------------------------
Mon Oct 15 19:26:10 2018: -> ----------------------------------------
Mon Oct 15 19:26:10 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> OG_WZ_Roll_Balkon
Mon Oct 15 19:26:10 2018: -> ----------------------------------------
Mon Oct 15 19:26:10 2018: -> ----------------------------------------
Mon Oct 15 19:26:10 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> OG_WZ_Roll_Alle
Mon Oct 15 19:26:10 2018: -> ----------------------------------------
Mon Oct 15 19:26:11 2018: -> ----------------------------------------
Mon Oct 15 19:26:11 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> OG_WZ_Roll_Garten
Mon Oct 15 19:26:11 2018: -> ----------------------------------------
Mon Oct 15 19:26:11 2018: -> ----------------------------------------
Mon Oct 15 19:26:11 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> OG_WZ_Roll_Alle
Mon Oct 15 19:26:11 2018: -> ----------------------------------------
Mon Oct 15 19:26:11 2018: -> ----------------------------------------
Mon Oct 15 19:26:11 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> OG_WZ_Roll_Alle_o_Balkon
Mon Oct 15 19:26:11 2018: -> ----------------------------------------
Mon Oct 15 19:26:12 2018: -> ----------------------------------------
Mon Oct 15 19:26:12 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> OG_WZ_Roll_Hof
Mon Oct 15 19:26:12 2018: -> ----------------------------------------
Mon Oct 15 19:26:12 2018: -> ----------------------------------------
Mon Oct 15 19:26:12 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> OG_WZ_Roll_Alle
Mon Oct 15 19:26:12 2018: -> ----------------------------------------
Mon Oct 15 19:26:12 2018: -> ----------------------------------------
Mon Oct 15 19:26:12 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> OG_WZ_Roll_Alle_o_Balkon
Mon Oct 15 19:26:12 2018: -> ----------------------------------------
Mon Oct 15 19:26:22 2018: -> ----------------------------------------
Mon Oct 15 19:26:22 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> EG_SZ_Roll_Hof
Mon Oct 15 19:26:22 2018: -> ----------------------------------------
Mon Oct 15 19:26:22 2018: -> ----------------------------------------
Mon Oct 15 19:26:22 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> EG_SZ_Roll_Alle
Mon Oct 15 19:26:22 2018: -> ----------------------------------------
Mon Oct 15 19:26:22 2018: -> ----------------------------------------
Mon Oct 15 19:26:22 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> EG_SZ_Roll_Hof
Mon Oct 15 19:26:22 2018: -> ----------------------------------------
Mon Oct 15 19:26:22 2018: -> ----------------------------------------
Mon Oct 15 19:26:22 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> EG_SZ_Roll_Alle
Mon Oct 15 19:26:22 2018: -> ----------------------------------------
Mon Oct 15 19:26:22 2018: -> ----------------------------------------
Mon Oct 15 19:26:22 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> EG_SZ_Roll_Hof
Mon Oct 15 19:26:22 2018: -> ----------------------------------------
Mon Oct 15 19:26:22 2018: -> ----------------------------------------
Mon Oct 15 19:26:22 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> EG_SZ_Roll_Alle
Mon Oct 15 19:26:22 2018: -> ----------------------------------------
Mon Oct 15 19:26:24 2018: -> ----------------------------------------
Mon Oct 15 19:26:24 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> EG_WZ_Roll_Garten
Mon Oct 15 19:26:24 2018: -> ----------------------------------------
Mon Oct 15 19:26:24 2018: -> ----------------------------------------
Mon Oct 15 19:26:24 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> EG_WZ_Roll_Alle
Mon Oct 15 19:26:24 2018: -> ----------------------------------------
Mon Oct 15 19:26:24 2018: -> ----------------------------------------
Mon Oct 15 19:26:24 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> EG_WZ_Roll_Garten
Mon Oct 15 19:26:24 2018: -> ----------------------------------------
Mon Oct 15 19:26:24 2018: -> ----------------------------------------
Mon Oct 15 19:26:24 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> EG_WZ_Roll_Alle
Mon Oct 15 19:26:24 2018: -> ----------------------------------------
Mon Oct 15 19:26:24 2018: -> ----------------------------------------
Mon Oct 15 19:26:24 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> EG_WZ_Roll_Garten
Mon Oct 15 19:26:24 2018: -> ----------------------------------------
Mon Oct 15 19:26:24 2018: -> ----------------------------------------
Mon Oct 15 19:26:24 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> EG_WZ_Roll_Alle
Mon Oct 15 19:26:24 2018: -> ----------------------------------------
Mon Oct 15 19:26:55 2018: -> ----------------------------------------
Mon Oct 15 19:26:55 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> 5_aktUhrzeit
Mon Oct 15 19:26:55 2018: -> ----------------------------------------
Mon Oct 15 19:26:55 2018: -> ----------------------------------------
Mon Oct 15 19:26:55 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> Time_Timer
Mon Oct 15 19:26:55 2018: -> ----------------------------------------
Mon Oct 15 19:26:58 2018: -> ----------------------------------------
Mon Oct 15 19:26:58 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> mailcheck
Mon Oct 15 19:26:58 2018: -> ----------------------------------------
Mon Oct 15 19:26:58 2018: -> ----------------------------------------
Mon Oct 15 19:26:58 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> dy_Wetterstation_Stefan_brightness
Mon Oct 15 19:26:58 2018: -> ----------------------------------------
Mon Oct 15 19:26:58 2018: -> ----------------------------------------
Mon Oct 15 19:26:58 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> dy_Wetterstation_Stefan_dew_point
Mon Oct 15 19:26:58 2018: -> ----------------------------------------
Mon Oct 15 19:26:58 2018: -> ----------------------------------------
Mon Oct 15 19:26:58 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> dy_Wetterstation_Stefan_humidness
Mon Oct 15 19:26:58 2018: -> ----------------------------------------
Mon Oct 15 19:26:58 2018: -> ----------------------------------------
Mon Oct 15 19:26:58 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> dy_Wetterstation_Stefan_israining
Mon Oct 15 19:26:58 2018: -> ----------------------------------------
Mon Oct 15 19:26:58 2018: -> ----------------------------------------
Mon Oct 15 19:26:58 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> dy_Wetterstation_Stefan_temperature
Mon Oct 15 19:26:58 2018: -> ----------------------------------------
Mon Oct 15 19:26:58 2018: -> ----------------------------------------
Mon Oct 15 19:26:58 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> dy_Wetterstation_Stefan_winddirection
Mon Oct 15 19:26:58 2018: -> ----------------------------------------
Mon Oct 15 19:26:58 2018: -> ----------------------------------------
Mon Oct 15 19:26:58 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> dy_Wetterstation_Stefan_winddirectionrange
Mon Oct 15 19:26:58 2018: -> ----------------------------------------
Mon Oct 15 19:26:58 2018: -> ----------------------------------------
Mon Oct 15 19:26:58 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> dy_Wetterstation_Stefan_windspeed
Mon Oct 15 19:26:58 2018: -> ----------------------------------------
Mon Oct 15 19:27:04 2018: -> ----------------------------------------
Mon Oct 15 19:27:04 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> OG_WZ_Hzg_Hof
Mon Oct 15 19:27:04 2018: -> ----------------------------------------
Mon Oct 15 19:27:04 2018: -> ----------------------------------------
Mon Oct 15 19:27:04 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> OG_WZ_Hzg_Hof_Clima
Mon Oct 15 19:27:04 2018: -> ----------------------------------------
Mon Oct 15 19:27:04 2018: -> ----------------------------------------
Mon Oct 15 19:27:04 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> OG_WZ_Hzg_Hof_Weather
Mon Oct 15 19:27:04 2018: -> ----------------------------------------
Mon Oct 15 19:27:21 2018: -> ----------------------------------------
Mon Oct 15 19:27:21 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> EG_WZ_Roll_Alle
Mon Oct 15 19:27:21 2018: -> ----------------------------------------
Mon Oct 15 19:27:21 2018: -> ----------------------------------------
Mon Oct 15 19:27:21 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> EG_WZ_Roll_Garten
Mon Oct 15 19:27:21 2018: -> ----------------------------------------
Mon Oct 15 19:27:21 2018: -> ----------------------------------------
Mon Oct 15 19:27:21 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> EG_WZ_Roll_Garten
Mon Oct 15 19:27:21 2018: -> ----------------------------------------
Mon Oct 15 19:27:21 2018: -> ----------------------------------------
Mon Oct 15 19:27:21 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> EG_WZ_Roll_Hof
Mon Oct 15 19:27:21 2018: -> ----------------------------------------
Mon Oct 15 19:27:21 2018: -> ----------------------------------------
Mon Oct 15 19:27:21 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> EG_WZ_Roll_Hof
Mon Oct 15 19:27:21 2018: -> ----------------------------------------
Mon Oct 15 19:27:22 2018: -> ----------------------------------------
Mon Oct 15 19:27:22 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> EG_WZ_Roll_Hof
Mon Oct 15 19:27:22 2018: -> ----------------------------------------
Mon Oct 15 19:27:22 2018: -> ----------------------------------------
Mon Oct 15 19:27:22 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> EG_WZ_Roll_Alle
Mon Oct 15 19:27:22 2018: -> ----------------------------------------
Mon Oct 15 19:27:35 2018: -> ----------------------------------------
Mon Oct 15 19:27:35 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> EG_WZ_Roll_Hof
Mon Oct 15 19:27:35 2018: -> ----------------------------------------
Mon Oct 15 19:27:35 2018: -> ----------------------------------------
Mon Oct 15 19:27:35 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> EG_WZ_Roll_Alle
Mon Oct 15 19:27:35 2018: -> ----------------------------------------
Mon Oct 15 19:27:38 2018: -> ----------------------------------------
Mon Oct 15 19:27:38 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> global
Mon Oct 15 19:27:38 2018: -> ----------------------------------------
Mon Oct 15 19:27:41 2018: -> ----------------------------------------
Mon Oct 15 19:27:41 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> EG_WZ_Roll_Garten
Mon Oct 15 19:27:41 2018: -> ----------------------------------------
Mon Oct 15 19:27:41 2018: -> ----------------------------------------
Mon Oct 15 19:27:41 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> EG_WZ_Roll_Alle
Mon Oct 15 19:27:41 2018: -> ----------------------------------------
Mon Oct 15 19:27:41 2018: -> ----------------------------------------
Mon Oct 15 19:27:41 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> EG_WZ_Roll_Garten
Mon Oct 15 19:27:41 2018: -> ----------------------------------------
Mon Oct 15 19:27:41 2018: -> ----------------------------------------
Mon Oct 15 19:27:41 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> EG_WZ_Roll_Alle
Mon Oct 15 19:27:41 2018: -> ----------------------------------------
Mon Oct 15 19:27:55 2018: -> ----------------------------------------
Mon Oct 15 19:27:55 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> 5_aktUhrzeit
Mon Oct 15 19:27:55 2018: -> ----------------------------------------
Mon Oct 15 19:27:55 2018: -> ----------------------------------------
Mon Oct 15 19:27:55 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> Time_Timer
Mon Oct 15 19:27:55 2018: -> ----------------------------------------
Mon Oct 15 19:28:15 2018: -> ----------------------------------------
Mon Oct 15 19:28:15 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> OG_Buero_Hzg
Mon Oct 15 19:28:15 2018: -> ----------------------------------------
Mon Oct 15 19:28:15 2018: -> ----------------------------------------
Mon Oct 15 19:28:15 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> OG_Buero_Hzg_Clima
Mon Oct 15 19:28:15 2018: -> ----------------------------------------
Mon Oct 15 19:28:15 2018: -> ----------------------------------------
Mon Oct 15 19:28:15 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> OG_Buero_Hzg_Weather
Mon Oct 15 19:28:15 2018: -> ----------------------------------------
Mon Oct 15 19:28:55 2018: -> ----------------------------------------
Mon Oct 15 19:28:55 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> 5_aktUhrzeit
Mon Oct 15 19:28:55 2018: -> ----------------------------------------
Mon Oct 15 19:28:55 2018: -> ----------------------------------------
Mon Oct 15 19:28:55 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> Time_Timer
Mon Oct 15 19:28:55 2018: -> ----------------------------------------
Mon Oct 15 19:29:02 2018: -> ----------------------------------------
Mon Oct 15 19:29:02 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> mailcheck
Mon Oct 15 19:29:02 2018: -> ----------------------------------------
Mon Oct 15 19:29:02 2018: -> ----------------------------------------
Mon Oct 15 19:29:02 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> dy_Wetterstation_Stefan_brightness
Mon Oct 15 19:29:02 2018: -> ----------------------------------------
Mon Oct 15 19:29:02 2018: -> ----------------------------------------
Mon Oct 15 19:29:02 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> dy_Wetterstation_Stefan_dew_point
Mon Oct 15 19:29:02 2018: -> ----------------------------------------
Mon Oct 15 19:29:02 2018: -> ----------------------------------------
Mon Oct 15 19:29:02 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> dy_Wetterstation_Stefan_humidness
Mon Oct 15 19:29:02 2018: -> ----------------------------------------
Mon Oct 15 19:29:02 2018: -> ----------------------------------------
Mon Oct 15 19:29:02 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> dy_Wetterstation_Stefan_israining
Mon Oct 15 19:29:02 2018: -> ----------------------------------------
Mon Oct 15 19:29:02 2018: -> ----------------------------------------
Mon Oct 15 19:29:02 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> dy_Wetterstation_Stefan_temperature
Mon Oct 15 19:29:02 2018: -> ----------------------------------------
Mon Oct 15 19:29:02 2018: -> ----------------------------------------
Mon Oct 15 19:29:02 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> dy_Wetterstation_Stefan_winddirection
Mon Oct 15 19:29:02 2018: -> ----------------------------------------
Mon Oct 15 19:29:02 2018: -> ----------------------------------------
Mon Oct 15 19:29:02 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> dy_Wetterstation_Stefan_winddirectionrange
Mon Oct 15 19:29:02 2018: -> ----------------------------------------
Mon Oct 15 19:29:02 2018: -> ----------------------------------------
Mon Oct 15 19:29:02 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> dy_Wetterstation_Stefan_windspeed
Mon Oct 15 19:29:02 2018: -> ----------------------------------------
Mon Oct 15 19:29:55 2018: -> ----------------------------------------
Mon Oct 15 19:29:55 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> 5_aktUhrzeit
Mon Oct 15 19:29:55 2018: -> ----------------------------------------
Mon Oct 15 19:29:55 2018: -> ----------------------------------------
Mon Oct 15 19:29:55 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> Time_Timer
Mon Oct 15 19:29:55 2018: -> ----------------------------------------
Mon Oct 15 19:30:02 2018: -> ----------------------------------------
Mon Oct 15 19:30:02 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> OG_WZ_Hzg_Hof
Mon Oct 15 19:30:02 2018: -> ----------------------------------------
Mon Oct 15 19:30:02 2018: -> ----------------------------------------
Mon Oct 15 19:30:02 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> OG_WZ_Hzg_Hof_Clima
Mon Oct 15 19:30:02 2018: -> ----------------------------------------
Mon Oct 15 19:30:02 2018: -> ----------------------------------------
Mon Oct 15 19:30:02 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> OG_WZ_Hzg_Hof_Weather
Mon Oct 15 19:30:02 2018: -> ----------------------------------------
Mon Oct 15 19:30:15 2018: -> ----------------------------------------
Mon Oct 15 19:30:15 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> OG_Buero_Hzg
Mon Oct 15 19:30:15 2018: -> ----------------------------------------
Mon Oct 15 19:30:15 2018: -> ----------------------------------------
Mon Oct 15 19:30:15 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> OG_Buero_Hzg_Clima
Mon Oct 15 19:30:15 2018: -> ----------------------------------------
Mon Oct 15 19:30:15 2018: -> ----------------------------------------
Mon Oct 15 19:30:15 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> OG_Buero_Hzg_Weather
Mon Oct 15 19:30:15 2018: -> ----------------------------------------
Mon Oct 15 19:30:54 2018: -> ----------------------------------------
Mon Oct 15 19:30:54 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> myLocation
Mon Oct 15 19:30:54 2018: -> ----------------------------------------

affected devices: FreeCmd

    
MSwitch 'cmd1': set Rolladen_Aktionen 10
MSwitch 'cmd2': set Rolladen_Aktionen 20

'cmd1' condition: [00:00-00:02]
'cmd2' condition: [00:02-{ sunrise("-1") }] AND [Rolladen_Aktionen:state] < 20

Rolladen_Aktionen ist ein Dummy


Leider steht der Wert des Dummy immer auf (von mir testhalber manuell gesetzten) 101


Ich hoffe Du kannst mir schreiben was ich da falsch gemacht habe.

Ich werde nachher versuchen auf die neue Version upzudaten, dann kann ich ja auch noch mehr Info's zur Verfügung stellen wenn Du die brauchst.

Danke und viele Grüsse
Bäschdler
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 15 Oktober 2018, 20:04:58
Hi Bäschdler,

in erster linie triggerst du 'global' , d.H jedes event löst hier das MSwitch device aus , scheinbar ohne jeden Filter.
inaller regel ist das nicht notwendig und ergiebt eine wirklich spürbare systemlast.

kannst du mir bitte nochmal sagen , was du überhaupt erreichen willst , was soll der auslöser sein , um das MSwitch auszulösen .

in jetziger konfiguration löstt ja keines der eingehenden Events wirklich den schaltvorgang aus.

un poste doch bitte die ausgabe von get DEVICE get_support_site mit, nur da kann ich wirklich sehen , was du eigentlich konfiguriert hat.

gruss Byte09

Titel: Antw:98_MSwitch - Support
Beitrag von: Bäschdler am 15 Oktober 2018, 20:22:42
Hallo Byte09,

ich möchte mit diesem MSwitch den Tag über bei Eintritt von bestimmten Bedingungen (vor Sonnenaufgang, x Minuten nach Sonnenaufgang, Helligkeit über y, Azimuth grösser Z1, Azimuth grösser Z2, x Minuten vor Sonnenuntergang, Helligkeit unter y, ...) einen Dummy "hochzählen" (und damit quasi eine Schrittkette aufbauen). In Abhängigkeit von diesem Dummywert soll dann mit je einem weiteren MSwitch je Rolladen dieser gesteuert werden. In diesem MSwitch wird dann (sinngemäß) drin stehen Rolladen_Ablaufsteuerung > 100 set Rolladen 0, Rolladen_Abaufsteuerung > 200 AND Raumtemperatur > 21 set Rolladen 60, ...

Ach ja, die whitelist hatte ich vergessen und habe sie jetzt eingetragen. Danke für den Hinweis

Welches Attribut muss ich denn setzen, dass die Sortierung dann auswählbar ist ?

hier die DAten von Support_Site:
Zitat
Modulversion: 2.02a_Test
Datenstruktur: V2.00

----- Devicename -----
Rolladen_Ablaufsteuerung

----- Attribute -----
Attribut MSwitch_Include_Webcmds: 0
Attribut MSwitch_Include_MSwitchcmds: 0
Attribut MSwitch_Mode: Full
Attribut MSwitch_Lock_Quickedit: 1
Attribut MSwitch_Help: 1
Attribut MSwitch_Debug: 3
Attribut MSwitch_Include_Devicecmds: 1
Attribut MSwitch_Comments: 1
Attribut MSwitch_Extensions: 0
Attribut MSwitch_Ignore_Types: notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
Attribut MSwitch_Delete_Delays: 1
Attribut MSwitch_Expert: 1

----- Trigger -----
Trigger device:  all_events
Trigger time:
Trigger condition:
Trigger Device Global Whitelist: Rolladen_Aktionen,

----- Trigger Details -----
Trigger cmd1: no_trigger
Trigger cmd2: no_trigger
Trigger cmd3: no_trigger
Trigger cmd4: no_trigger

----- Device Actions -----

Device: FreeCmd-AbsCmd1
cmd1: cmd set Rolladen_Aktionen 10
cmd2: cmd set Rolladen_Aktionen 20
cmd1 condition: [00:00-00:02]
cmd2 condition: [00:02-{ sunrise("-1") }] AND [Rolladen_Aktionen:state] < 20
cmd1 delay: 00:00:00
cmd2 delay: 00:00:00
repeats:
repeats delay:
priority: 1
Titel: Antw:98_MSwitch - Support
Beitrag von: Bäschdler am 15 Oktober 2018, 20:31:11
Mir ist eben aufgefallen, dass die whitelist die ich mit "Rolladen_Aktionen, sunrise, sunset, dy_Wetterstation_Stefan_brightness, myLocation" ausfülle irgendwie immer nur "Rolladen_Aktionen, " enthält.
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 16 Oktober 2018, 05:24:51
Hallo Byte09,

ich möchte mit diesem MSwitch den Tag über bei Eintritt von bestimmten Bedingungen (vor Sonnenaufgang, x Minuten nach Sonnenaufgang, Helligkeit über y, Azimuth grösser Z1, Azimuth grösser Z2, x Minuten vor Sonnenuntergang, Helligkeit unter y, ...) einen Dummy "hochzählen" (und damit quasi eine Schrittkette aufbauen). In Abhängigkeit von diesem Dummywert soll dann mit je einem weiteren MSwitch je Rolladen dieser gesteuert werden. In diesem MSwitch wird dann (sinngemäß) drin stehen Rolladen_Ablaufsteuerung > 100 set Rolladen 0, Rolladen_Abaufsteuerung > 200 AND Raumtemperatur > 21 set Rolladen 60, ...

Ach ja, die whitelist hatte ich vergessen und habe sie jetzt eingetragen. Danke für den Hinweis

Welches Attribut muss ich denn setzen, dass die Sortierung dann auswählbar ist ?

hier die DAten von Support_Site:

moin,

so wie du das mswitchkonfiguriert hast , kann es nicht funktionieren , unabhängig davon, was in den affected devices und den zugehörigen conditions steht. das mswitch lauscht zwar auf alle events 'global', aber es ist nichts konfiguriert, was einen zweig des mswitches dann wirklich auslösen soll :
----- Trigger -----
Trigger device:  all_events
Trigger time:
Trigger condition:
Trigger Device Global Whitelist: Rolladen_Aktionen,

----- Trigger Details -----
Trigger cmd1: no_trigger
Trigger cmd2: no_trigger
Trigger cmd3: no_trigger
Trigger cmd4: no_trigger

diese Teile cmd1: cmd set Rolladen_Aktionen 10
cmd2: cmd set Rolladen_Aktionen 20
cmd1 condition: [00:00-00:02]
cmd2 condition: [00:02-{ sunrise("-1") }] AND [Rolladen_Aktionen:state] < 20

besagen ledigleich , dass Rolladen_Aktionen auf 10 gesetzt wird, wenn cmd1 ausgelöst ist und es zwischen 00 Uhr und 00 Uhr 02 ist, bzw , dass Rolladen_Aktionen auf 20 gesetzt wird, wenn es cmd2 ausgelöst wird und es zwischen 00 uhr 02 und 7 uhr 14 ( zumindest heute ) ist und Rolladen_Aktionen kleiner als 20 ist . Aber eben die Auslöser für cmd1 und/oder cmd2 sind nicht konfiguriert :

Trigger cmd1: no_trigger
Trigger cmd2: no_trigger

auch das lauschen auf alle events macht nicht wirklich sinn , sondern hier solltest du wirklich nur auf das gerät 'hören', dessen ausgabe wirklich das auslösen des mswitches veranlassen soll.

das triggern auf alle events macht wirklich nur in ganz wenigen ausnahmefällen sinn und dann sollte es über die whitelist oder entsprechendes attribut (MSwitch_trigger_filter) weiter eingegrenzt werden , sonst belastet es das system wirklich völlig unnötig und spürbar. ( in deinem debugfile werden in 4 Minuten über 115 events in irgendeiner form vom modul ausgewertet )

alternativ dazu kannst du das mswitch zu bestimmten zeiten auslösen , um mit vorhandenen readings aus sunset, twilight etc. zu arbeiten , dann brauchst du aber gar kein gerät angeben , das als trigger dient.

es muss ein oder mehrere events eingestellt werden , die den entsprechenden zweig (cmd1-4) auslösen sollen, erst dann kannst du dich damit beschäftigen , was in den eigentlichen cmds dann passieren soll.

ps: in den Hilfefeldern ist doch zu jedem Eingabefeld erklärt, was dort hinein muss - und entsprechendes Format. Weiterhin wäre es ratsam , gerade wenn du global triggerst , das MSwitch in den Safemode zu schalten ( attr MSwitch_Safemode = 1 ) , hier besteht sonst immer die gefahr, das sich bei fehlerhafter konfiguration das MSwitch selber triggert und ruckzuck befindet es sich in einer endlosschleife = fhemabsturz = Fhemneustart erforderlich = doof . Im Safemode kann das nicht passieren , da hier nur eine gewisse anzahl anfragen in einem best. zeitraum zugelassen wird. wird diese überschritten schaltet sich das Mswitch auf disabled = 1 und eine vermutete endlosschleife wird unterbrochen.

Auch hast du das MSwitch in den Expertmodus geschaltet.Attribut MSwitch_Expert: 1 Wenn nicht zwingender Bedarf besteht solltest du das vermeiden. Zum einen sind im Normalmode schon ain grosser Teil an Fehlerquellen ausgeschlossen ( da nicht einstellbar ) und die internen Abläufe sind deutlich abgespeckt - d.H das device benötigt deutlich weniger verarbeitungszeit. Den Expertenmode brauchst du auch im Grunde nur in Ausnahmefällen. Selbst bei mir laufen von weit über 40 MSwitches nur eine Handvoll im Expertenmodus ( bei denen entsprechende Funktionen halt unverzichtbar sind ).

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 16 Oktober 2018, 17:21:43
Mir ist eben aufgefallen, dass die whitelist die ich mit "Rolladen_Aktionen, sunrise, sunset, dy_Wetterstation_Stefan_brightness, myLocation" ausfülle irgendwie immer nur "Rolladen_Aktionen, " enthält.

trennung der namen nur durch komma. Leerzeichen dürfen nicht enthalten sein !

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Bäschdler am 17 Oktober 2018, 22:22:07
Hi Byte09,

jetzt habe ich den MSwitch umgebaut. Ich habe jetzt nur noch Zeiten, die brightness und den Rolladen_Aktionen drin.

Im Device: FreeCmd-AbsCmd2 bekomme ich die Anzeige, dass die Bedingung wahr ist und ausgeführt wird, aber der set wird nicht ausgeführt.

Nochmals zur Verdeutlichung was ich haben möchte:
- bei Device: FreeCmd-AbsCmd1 soll der Dummy Rolladen_Aktionen nur abhängig von der Zeit (und bei cmd2 auch vom state des Dummy Rolladen_Aktionen) auf 10 bzw. 20 gesetzt werden.
- bei Device: FreeCmd-AbsCmd2 soll der Dummy Rolladen_Aktionen abhängig von brightness und state des Dummy Rolladen_Aktionen auf 520 bzw. 530 gesetzt werden.

Ich habe mit das so vorgestellt, dass ich je cmd1 / cmd2 Pfad in jedem Device FreeCmd im Prinzip einen vom anderen total unabhängigen Befehl eingeben kann. Das eine Mal nur abhängig von einer Zeit, das andere Mal nur abhängig von einem Reading (in diesem Fall brightness) und wieder ein anderes Mal abhängig von einer Kombination von 2 oder 3 Bedingungen.

Irgendwie stehe ich hier wohl auf dem Schlauch...

Viele Grüsse
Bäschdler



Hier der check condition von Device: FreeCmd-AbsCmd2:
Zitat
eingehender String:
[dy_Wetterstation_Stefan_brightness:state] < 60 AND [Rolladen_Aktionen:state] < 520

If Anweisung Perl:
if (ReadingsVal('dy_Wetterstation_Stefan_brightness', 'state', '00:00:00') < 60 && ReadingsVal('Rolladen_Aktionen', 'state', '00:00:00') < 520){$answer = 'true';} else {$answer = 'false';}

Bedingung ist Wahr und wird ausgeführt

States der geprüften Readings:
Reading: [Rolladen_Aktionen:state] - Inhalt: 102
Reading: [dy_Wetterstation_Stefan_brightness:state] - Inhalt: 0
Das zugehörige MSwich cmd1 ist "set Rolladen_Aktionen 520". Da würde ich jetzt erwarten, dass der Dummy auf 520 gesetzt wird. er bleibt aber dauerhaft auf (manuell von mir irgendwann mal gesetzten) 102.

Und hier der get_support_site
Zitat
Modulversion: 2.02a_Test
Datenstruktur: V2.00

----- Devicename -----
Rolladen_Ablaufsteuerung

----- Attribute -----
Attribut MSwitch_Include_Webcmds: 0
Attribut MSwitch_Include_MSwitchcmds: 0
Attribut MSwitch_Mode: Full
Attribut MSwitch_Lock_Quickedit: 1
Attribut MSwitch_Help: 1
Attribut MSwitch_Debug: 1
Attribut MSwitch_Include_Devicecmds: 1
Attribut MSwitch_Comments: 1
Attribut MSwitch_Extensions: 0
Attribut MSwitch_Ignore_Types: notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
Attribut MSwitch_Delete_Delays: 1
Attribut MSwitch_Expert: 0

----- Trigger -----
Trigger device:  dy_Wetterstation_Stefan_brightness
Trigger time:
Trigger condition:
Trigger Device Global Whitelist: undef

----- Trigger Details -----
Trigger cmd1: *:state: > 60
Trigger cmd2: *:state: < 60
Trigger cmd3: *:state:*
Trigger cmd4: *:state:*

----- Device Actions -----

Device: FreeCmd-AbsCmd1
cmd1: cmd set Rolladen_Aktionen 10
cmd2: cmd set Rolladen_Aktionen 20
cmd1 condition: [00:00-00:02]
cmd2 condition: [00:02-{ sunrise("-1") }] AND [Rolladen_Aktionen:state] < 20
cmd1 delay: 00:00:00
cmd2 delay: 00:00:00
repeats:
repeats delay:
priority: 1
id: 0
comment:
cmd1 exit: 0
cmd2 exit: 0

Device: FreeCmd-AbsCmd2
cmd1: cmd set Rolladen_Aktionen 520
cmd2: cmd set Rolladen_Aktionen 530
cmd1 condition: [dy_Wetterstation_Stefan_brightness:state] < 60 AND [Rolladen_Aktionen:state] < 520
cmd2 condition: [dy_Wetterstation_Stefan_brightness:state] < 60 AND [Rolladen_Aktionen:state] < 520
cmd1 delay: 00:00:00
cmd2 delay: 00:02:00
repeats:
repeats delay:
priority: 1
id: 0
comment:
cmd1 exit: 0
cmd2 exit: 0

Device: FreeCmd-AbsCmd3
cmd1: cmd set Rolladen_Aktionen 540
cmd2: cmd set Rolladen_Aktionen 550
cmd1 condition: [{ sunset(-900,"17:00","21:30") }-{ sunset("-780") }] AND [Rolladen_Aktionen:state] < 540
cmd2 condition: [{ sunset(-900,"17:00","21:30") }-{ sunset("-780") }] AND [Rolladen_Aktionen:state] < 550
cmd1 delay: 00:00:00
cmd2 delay: 00:00:00
repeats:
repeats delay:
priority: 1
id: 0
comment:
cmd1 exit: 0
cmd2 exit: 0

Device: FreeCmd-AbsCmd4
cmd1: cmd set Rolladen_Aktionen 560
cmd2: cmd set Rolladen_Aktionen 570
cmd1 condition: [{ sunset(0,"17:00","21:30") }-{ sunset("+60") }] AND [Rolladen_Aktionen:state] < 560
cmd2 condition: [{ sunset(0,"17:00","21:30") }-23:59] AND [Rolladen_Aktionen:state] < 570
cmd1 delay: 00:00:00
cmd2 delay: 00:00:00
repeats:
repeats delay:
priority: 1
id: 0
comment:
cmd1 exit: 0
cmd2 exit: 0

Device: FreeCmd-AbsCmd5
cmd1: cmd set Rolladen_Aktionen 30
cmd2: cmd set Rolladen_Aktionen 40
cmd1 condition: [{ sunrise(0,"05:00","08:30") }-{ sunrise("+60") }] AND [Rolladen_Aktionen:state] < 30
cmd2 condition: [{ sunrise(0,"05:00","08:30") }-{ sunrise("+60") }] AND [Rolladen_Aktionen:state] < 40
cmd1 delay: 00:00:00
cmd2 delay: 00:02:00
repeats:
repeats delay:
priority: 1
id: 0
comment:
cmd1 exit: 0
cmd2 exit: 0

Device: FreeCmd-AbsCmd6
cmd1: cmd set Rolladen_Aktionen 50
cmd2: cmd set Rolladen_Aktionen 60
cmd1 condition: [dy_Wetterstation_Stefan_brightness:state] > 60 AND [Rolladen_Aktionen:state] < 50
cmd2 condition: [dy_Wetterstation_Stefan_brightness:state] > 60 AND [Rolladen_Aktionen:state] < 50
cmd1 delay: 00:00:00
cmd2 delay: 00:02:00
repeats:
repeats delay:
priority: 1
id: 0
comment:
cmd1 exit: 0
cmd2 exit: 0

Device: FreeCmd-AbsCmd7
cmd1: cmd set Rolladen_Aktionen 70
cmd2: cmd set Rolladen_Aktionen 80
cmd1 condition: [{ sunrise(2700,"05:00","08:30") }-{ sunrise("+2820") }] AND [Rolladen_Aktionen:state] < 70
cmd2 condition: [{ sunrise(2700,"05:00","08:30") }-{ sunrise("+2820") }] AND [Rolladen_Aktionen:state] < 70
cmd1 delay: 00:00:00
cmd2 delay: 00:02:00
repeats:
repeats delay:
priority: 1
id: 0
comment:
cmd1 exit: 0
cmd2 exit: 0

Device: FreeCmd-AbsCmd8
cmd1: cmd set Rolladen_Aktionen 110
cmd2: cmd set Rolladen_Aktionen 100
cmd1 condition: [08:17-13:44] AND [Rolladen_Aktionen:state] < 110
cmd2 condition: [08:15-08:17] AND [Rolladen_Aktionen:state] < 100
cmd1 delay: 00:02:00
cmd2 delay: 00:00:00
repeats:
repeats delay:
priority: 1
id: 0
comment:
cmd1 exit: 0
cmd2 exit: 0

Device: FreeCmd-AbsCmd9
cmd1: cmd set Rolladen_Aktionen 210
cmd2: cmd set Rolladen_Aktionen 200
cmd1 condition: [13:47-13:59] AND  [Rolladen_Aktionen:state] < 210
cmd2 condition: [13:45-13:47] AND [Rolladen_Aktionen:state] < 200
cmd1 delay: 00:02:00
cmd2 delay: 00:00:00
repeats:
repeats delay:
priority: 1
id: 0
comment:
cmd1 exit: 0
cmd2 exit: 0

Device: FreeCmd-AbsCmd10
cmd1: cmd set Rolladen_Aktionen 250
cmd2: cmd set Rolladen_Aktionen 240
cmd1 condition: [14:02-17:29] AND [Rolladen_Aktionen:state] < 250
cmd2 condition: [14:00-14:02] AND [Rolladen_Aktionen:state] < 240
cmd1 delay: 00:02:00
cmd2 delay: 00:00:00
repeats:
repeats delay:
priority: 1
id: 0
comment:
cmd1 exit: 0
cmd2 exit: 0

Device: FreeCmd-AbsCmd11
cmd1: cmd set Rolladen_Aktionen 270
cmd2: cmd set Rolladen_Aktionen 260
cmd1 condition: [17:30-{ sunset("-1") }] AND [Rolladen_Aktionen:state] < 270
cmd2 condition: [17:30-17:32] AND [Rolladen_Aktionen:state] < 260
cmd1 delay: 00:02:00
cmd2 delay: 00:00:00
repeats:
repeats delay:
priority: 1
id: 0
comment:
cmd1 exit: 0
cmd2 exit: 0

Device: FreeCmd-AbsCmd12
cmd1: cmd set Rolladen_Aktionen 500
cmd2: cmd set Rolladen_Aktionen 510
cmd1 condition: [{ sunset(-2700,"17:00","21:30") }-{ sunset("-2580") }] AND [Rolladen_Aktionen:state] < 500
cmd2 condition: [{ sunset(-2700,"17:00","21:30") }-{ sunset("-2580") }] AND [Rolladen_Aktionen:state] < 510
cmd1 delay: 00:00:00
cmd2 delay: 00:02:00
repeats:
repeats delay:
priority: 1
id: 0
comment:
cmd1 exit: 0
cmd2 exit: 0
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 18 Oktober 2018, 05:51:46
ok, da liegt einiges im argen .

zum ersten die trigger :
Trigger cmd1: *:state: > 60
Trigger cmd2: *:state: < 60
Trigger cmd3: *:state:*
Trigger cmd4: *:state:*

cmd3 und cmd4 sind ok , d.h diese beiden zweige werden ausgeführt , sobald sich der state des devices ändert - egal welchen wert state annimmt.

cmd1 und cmd2 werde niemals auslösen ( müssen sie aber auch nicht  ) . in den zweigen 1 und 2 schaltet der state des mswitches zusätzlich auf on oder off, wird in deinem fall aber nicht benötigt . Daher dürfen 1 und 2 auch nicht mit dem gleichen string belegt sein , da hier eine klare abgrenzung zwischen on und off vorhanden sein muss.
Auslösen würde es nur dann ,wenn ein event eintrefffen würde, welches wirklich so aussieht "state: < 60" , ankommen wird aber "state:60(59,58,etc) " . Hier wird kein mathematischer "vergleich" durchgeführt, sondern ein reiner vergleich der strings . Lösbar wäre das nur über regex.

aber da du diese zweige eh nicht benötigst , setze 1 und 2 einfach auf 'no_trigger' ( du kanns das ganze mswitch auch in den Notify-Mode setzen - über attribut -, dann sind sie eh nicht mehr aufgeführt und können hier nicht mehr zur verwirrung beitragen).

zu den affected devices:

auch hier gibt es probleme mit einer eindeutigen definition:

angenommen das ankommende event ist 'state:59' , so werden beide zweige ausgefügrt, weil für beide zweige der auslöser 'state:*' ist.

bei dieser definition : (1)
Device: FreeCmd-AbsCmd2
cmd1: cmd set Rolladen_Aktionen 520
cmd2: cmd set Rolladen_Aktionen 530
cmd1 condition: [dy_Wetterstation_Stefan_brightness:state] < 60 AND [Rolladen_Aktionen:state] < 520
cmd2 condition: [dy_Wetterstation_Stefan_brightness:state] < 60 AND [Rolladen_Aktionen:state] < 520
cmd1 delay: 00:00:00
cmd2 delay: 00:02:00

werden beide befehle ausgeführt , weil die bedingungen BEIDE zutreffen ,d.h wenn Rolladen_Aktionen:state < 520 ist , wird das endergebniss in jedem fall nach 2 min 530 annehmen .... ( theroretisch, ... weill ja das zweite,dritte,...  affected device ggf. auch greift )

Device: FreeCmd-AbsCmd3
cmd1: cmd set Rolladen_Aktionen 540
cmd2: cmd set Rolladen_Aktionen 550
cmd1 condition: [{ sunset(-900,"17:00","21:30") }-{ sunset("-780") }] AND [Rolladen_Aktionen:state] < 540
cmd2 condition: [{ sunset(-900,"17:00","21:30") }-{ sunset("-780") }] AND [Rolladen_Aktionen:state] < 550


.... dieses erfüllt unter umständein die Bedingung nämlich auch und würde auf in jedem fall auf 550 schalten . 540 können hier nie erreicht werden , da die erste bedingung zutrifff und auf 540 geschaltet würde, aber die zweite trifft ebenso zu und es geht gleich weiter nach 550 .

...... und dann 2 min später schlägt das delay aus dem ersten 'affected zu ' und setzt wieder zurück nach 520 do diese bedingung :cmd2 condition: [dy_Wetterstation_Stefan_brightness:state] < 60 AND [Rolladen_Aktionen:state] < 520  vor 2 minuten nämlich zutraf !

ich kann die hier gar nicht wirklich helfen. du musst schritt für schrittt logisch durchgehen , was passiert , wenn welches event kommt ( ggf. sogar anhand eines diagrammes )  und dabei nicht vergessen: wenn eine bedingung erfüllt ist , bricht er nicht ab , d.h er testet auch alle anderen 'affected devices' noch und führt diese aus , wenn es passt , es sei denn du gibst explizit an , dass er nach einem befehl abbrechen soll ).

weiterhin wichtig: die befehle werden blockweise ausgeführt ! d.h es wird nicht 'affected_device1' geprüft und ausgeführt , und dann  affected_device 2 etc, sondern es werde erst alle affected devices geprüft und danach der oder die entsprechenden befehle abgesetzt . das ist nicht ganz unwesentlich , da sich eine bedingung somit während der prüfung nicht ändert, auch wenn diese zutrifft und er den befehl ausführen sollte und unter umständen damit die bedingung ändern würde - ich weise daher darauf hin , da sich bei dir ja eine bedingung nach prüfung des ersten devices ändern würde , und im zweiten device dann anders wäre. tut sie aber nicht - sie hat immer den wert, den sie hat , wenn das mswitch auslöst .
( einzige ausnahme ist hier zeitversetztes schalten ( delay ) da kannst du explizit angeben , ob er unmittelbar vor dem schalte nochmals prüfen soll )
gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Bäschdler am 18 Oktober 2018, 09:11:37
Guten Morgen,

danke für die ausführliche Antwort.
Anscheinend müsste ja jetzt das was ich programmiert habe eigentlich wenigstens ein bisschen funktionieren ;-)

Zitat
bei dieser definition : (1)
Code: [Auswählen]

Device: FreeCmd-AbsCmd2
cmd1: cmd set Rolladen_Aktionen 520
cmd2: cmd set Rolladen_Aktionen 530
cmd1 condition: [dy_Wetterstation_Stefan_brightness:state] < 60 AND [Rolladen_Aktionen:state] < 520
cmd2 condition: [dy_Wetterstation_Stefan_brightness:state] < 60 AND [Rolladen_Aktionen:state] < 520
cmd1 delay: 00:00:00
cmd2 delay: 00:02:00


werden beide befehle ausgeführt , weil die bedingungen BEIDE zutreffen ,d.h wenn Rolladen_Aktionen:state < 520 ist , wird das endergebniss in jedem fall nach 2 min 530 annehmen .... ( theroretisch, ... weill ja das zweite,dritte,...  affected device ggf. auch greift )

Genau das hatte ich so beabsichtigt, dass beide getriggert werden, das eine (520) für 2 Minuten bleibt und dann das nächste (530) geschaltet wird.

Zitat
Code: [Auswählen]

Device: FreeCmd-AbsCmd3
cmd1: cmd set Rolladen_Aktionen 540
cmd2: cmd set Rolladen_Aktionen 550
cmd1 condition: [{ sunset(-900,"17:00","21:30") }-{ sunset("-780") }] AND [Rolladen_Aktionen:state] < 540
cmd2 condition: [{ sunset(-900,"17:00","21:30") }-{ sunset("-780") }] AND [Rolladen_Aktionen:state] < 550



.... dieses erfüllt unter umständein die Bedingung nämlich auch und würde auf in jedem fall auf 550 schalten . 540 können hier nie erreicht werden , da die erste bedingung zutrifff und auf 540 geschaltet würde, aber die zweite trifft ebenso zu und es geht gleich weiter nach 550 .
Auch das hatte ich so beabsichtigt, denn wenn das nachfolgende "überholt" soll das "höhere" gesetzt werden.

Zitat
...... und dann 2 min später schlägt das delay aus dem ersten 'affected zu ' und setzt wieder zurück nach 520 do diese bedingung :
Code: [Auswählen]

cmd2 condition: [dy_Wetterstation_Stefan_brightness:state] < 60 AND [Rolladen_Aktionen:state] < 520

  vor 2 minuten nämlich zutraf !
Das sollte eigentlich nicht passieren, daher habe ich es (hoffentlich) so eingestellt, dass die condition erst nach 2 Minuten geprüft werden soll und dann verhindert ja der "AND [Rolladen_Aktionen:state] < 520" was wahr werden der Bedigung, da er höher als 520 ist.

Zitat
und dabei nicht vergessen: wenn eine bedingung erfüllt ist , bricht er nicht ab , d.h er testet auch alle anderen 'affected devices' noch und führt diese aus , wenn es passt
Genau so habe ich meine Logik aufgebaut und möchte ja bewusst, dass ein "höherer" Wert gesetzt wird wenn mehrere Dinge gleichzeitig zutreffen. Die weitere Logik die dann den Rolladen steuert hat dann als condition ein "[Rolladen_Aktionen:state] > x".

Zitat
weiterhin wichtig: die befehle werden blockweise ausgeführt ! d.h es wird nicht 'affected_device1' geprüft und ausgeführt , und dann  affected_device 2 etc,
Da ich im Augenblick nur ein affected device habe (den dummy "Rolladen_Aktionen") kann da auch nix passieren.


Jetzt bleibt für mich aber noch immer die Frage offen weshalb bei
Zitat
eingehender String:
[dy_Wetterstation_Stefan_brightness:state] < 60 AND [Rolladen_Aktionen:state] < 520

If Anweisung Perl:
if (ReadingsVal('dy_Wetterstation_Stefan_brightness', 'state', '00:00:00') < 60 && ReadingsVal('Rolladen_Aktionen', 'state', '00:00:00') < 520){$answer = 'true';} else {$answer = 'false';}

Bedingung ist Wahr und wird ausgeführt

States der geprüften Readings:
Reading: [Rolladen_Aktionen:state] - Inhalt: 102
Reading: [dy_Wetterstation_Stefan_brightness:state] - Inhalt: 0
und
Zitat
cmd1 ist "set Rolladen_Aktionen 520"
der Dummy nicht auf 520 gesetzt wird.

Wenn ich es mal schaffen würde, dass der MSwitch hier wenigstens mal überhaupt irgend einen Wert setzen würde dann wäre ich an dem Punkt an dem ich nachschauen könnte was ich falsch gemacht habe aber so tappe ich leider total im dunkeln und weiss nicht was ich ändern muss.


Danke und viele Grüsse
Bäschdler
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 18 Oktober 2018, 09:46:02
Bitte das Device nochmal auf debug 3 setzen , eine Auslösung veranlassen und den gesamten log hier einstellen . Gruss Byte09

Gesendet von meinem SM-G900F mit Tapatalk

Titel: Antw:98_MSwitch - Support
Beitrag von: Bäschdler am 18 Oktober 2018, 12:31:47
Hallo Byte09,

hier das Log
Zitat
Thu Oct 18 10:25:15 2018 Starte Log
Thu Oct 18 10:26:46 2018: -> ----------------------------------------
Thu Oct 18 10:26:46 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> dy_Wetterstation_Stefan_brightness
Thu Oct 18 10:26:46 2018: -> ----------------------------------------
Thu Oct 18 10:26:46 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event  -> dy_Wetterstation_Stefan_brightness state: 199
Thu Oct 18 10:26:46 2018: -> Rolladen_Ablaufsteuerung: checktrigger trigger cmd4 ->
Thu Oct 18 10:26:46 2018: -> Rolladen_Ablaufsteuerung: checktrigger ergebniss -> undef
Thu Oct 18 10:26:46 2018: -> Rolladen_Ablaufsteuerung: checktrigger trigger cmd4 ->
Thu Oct 18 10:26:46 2018: -> Rolladen_Ablaufsteuerung: checktrigger ergebniss -> undef
Thu Oct 18 10:26:46 2018: -> Rolladen_Ablaufsteuerung: anzahl gefundener Befehle -> 0
Thu Oct 18 10:26:46 2018: -> Rolladen_Ablaufsteuerung: inhalt gefundener Befehle ->
Thu Oct 18 10:29:34 2018: -> ----------------------------------------
Thu Oct 18 10:29:34 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> dy_Wetterstation_Stefan_brightness
Thu Oct 18 10:29:34 2018: -> ----------------------------------------
Thu Oct 18 10:29:34 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event  -> dy_Wetterstation_Stefan_brightness state: 199
Thu Oct 18 10:29:34 2018: -> Rolladen_Ablaufsteuerung: checktrigger trigger cmd4 ->
Thu Oct 18 10:29:34 2018: -> Rolladen_Ablaufsteuerung: checktrigger ergebniss -> undef
Thu Oct 18 10:29:34 2018: -> Rolladen_Ablaufsteuerung: checktrigger trigger cmd4 ->
Thu Oct 18 10:29:34 2018: -> Rolladen_Ablaufsteuerung: checktrigger ergebniss -> undef
Thu Oct 18 10:29:34 2018: -> Rolladen_Ablaufsteuerung: anzahl gefundener Befehle -> 0
Thu Oct 18 10:29:34 2018: -> Rolladen_Ablaufsteuerung: inhalt gefundener Befehle ->
Thu Oct 18 10:32:07 2018: -> ----------------------------------------
Thu Oct 18 10:32:07 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> dy_Wetterstation_Stefan_brightness
Thu Oct 18 10:32:07 2018: -> ----------------------------------------
Thu Oct 18 10:32:07 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event  -> dy_Wetterstation_Stefan_brightness state: 197
Thu Oct 18 10:32:07 2018: -> Rolladen_Ablaufsteuerung: checktrigger trigger cmd4 ->
Thu Oct 18 10:32:07 2018: -> Rolladen_Ablaufsteuerung: checktrigger ergebniss -> undef
Thu Oct 18 10:32:07 2018: -> Rolladen_Ablaufsteuerung: checktrigger trigger cmd4 ->
Thu Oct 18 10:32:07 2018: -> Rolladen_Ablaufsteuerung: checktrigger ergebniss -> undef
Thu Oct 18 10:32:07 2018: -> Rolladen_Ablaufsteuerung: anzahl gefundener Befehle -> 0
Thu Oct 18 10:32:07 2018: -> Rolladen_Ablaufsteuerung: inhalt gefundener Befehle ->
Thu Oct 18 10:34:26 2018: -> ----------------------------------------
Thu Oct 18 10:34:26 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event von -> dy_Wetterstation_Stefan_brightness
Thu Oct 18 10:34:26 2018: -> ----------------------------------------
Thu Oct 18 10:34:26 2018: -> Rolladen_Ablaufsteuerung: eingehendes Event  -> dy_Wetterstation_Stefan_brightness state: 196
Thu Oct 18 10:34:26 2018: -> Rolladen_Ablaufsteuerung: checktrigger trigger cmd4 ->
Thu Oct 18 10:34:26 2018: -> Rolladen_Ablaufsteuerung: checktrigger ergebniss -> undef
Thu Oct 18 10:34:26 2018: -> Rolladen_Ablaufsteuerung: checktrigger trigger cmd4 ->
Thu Oct 18 10:34:26 2018: -> Rolladen_Ablaufsteuerung: checktrigger ergebniss -> undef
Thu Oct 18 10:34:26 2018: -> Rolladen_Ablaufsteuerung: anzahl gefundener Befehle -> 0
Thu Oct 18 10:34:26 2018: -> Rolladen_Ablaufsteuerung: inhalt gefundener Befehle ->
so ging's bis 12:25 weiter - ich habe es uns erspart alles hier rein zu kopieren.

Aktuell müsste der Dummy auf 110 gesetzt werden. Check condition:
Zitat
eingehender String:
[08:17-13:44] AND [Rolladen_Aktionen:state] < 110

If Anweisung Perl:
if ((1516259820 < 1516274820 && 1516274820 < 1516279440) && ReadingsVal('Rolladen_Aktionen', 'state', '00:00:00') < 110){$answer = 'true';} else {$answer = 'false';}

If Anweisung Perl Klarzeiten:
if ((08:17 < 12:27 && 12:27 < 13:44) && ReadingsVal('Rolladen_Aktionen', 'state', '00:00:00') < 110){$answer = 'true';} else {$answer = 'false';}

Bedingung ist Wahr und wird ausgeführt

States der geprüften Readings:
Reading: [Rolladen_Aktionen:state] - Inhalt: 102

Der Teil des FreeCmd's:
Zitat
Device: FreeCmd-AbsCmd8
cmd1: cmd set Rolladen_Aktionen 110
cmd2: cmd set Rolladen_Aktionen 100
cmd1 condition: [08:17-13:44] AND [Rolladen_Aktionen:state] < 110
cmd2 condition: [08:15-08:17] AND [Rolladen_Aktionen:state] < 100
cmd1 delay: 00:02:00
cmd2 delay: 00:00:00
repeats:
repeats delay:
priority: 1
id: 0
comment:
cmd1 exit: 0
cmd2 exit: 0

Viele Grüsse
Bäschdler
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 18 Oktober 2018, 13:34:31
Ok thx. Ich werde da aber nicht richtig schlau draus ... am Handy schon gar nicht. Würdest du mir nochmal die raw definition oder den config file geben ?

Ich spiele es dann bei mir mal ein ... mit Dummys ... und schaue es mir genau sn heute abend.


Gruss Byte09

Gesendet von meinem SM-G900F mit Tapatalk

Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 18 Oktober 2018, 15:12:57
hi bäschdler ,

ich habe gerade am laptop erst gesehen , dass du den trigger von 'global' umgestellt hast auf ein einzeldevice .

in diesem Fall sehen die ankommenden Events anders aus und du musst das anpassen, da kein gerätename mitgeliefert wird.

Ändere mal die beiden trigger von
.*:state:.*nach
state:.*
das ist noch ein ( ätzendes ) überbleibsel aus einer ganz alten version des moduls ( damals noch 98_absent.pm ) und ich habe mich nie getraut das zu ändern, da das im grunde allle bestehenden konfugurationen betreffen würde .

auszug Helpbutton:
Zitat
Hier können manuell Events zugefügt werden , die in den Auswahllisten verfügbar sein sollen und auf die das Modul reagiert.
Grundsätzlich ist zu unterscheiden , ob das Device im Normal-, oder Globalmode betrieben wird
Im Normalmode bestehen die Events aus 2 Teilen , dem Reading und dem Wert "state:on"
Wenn sich das Device im GLOBAL Mode befindet müssen die Events aus 3 Teilen bestehen , dem Devicename, dem Reading und dem Wert "device:state:on".
Wird hier nur ein "*" angegeben , reagiert der entsprechende Zweig auf alle eingehenden Events.
Weitherhin sind folgende Syntaxmöglichkeiten vorgesehen :
device:state:*, device:*:*, *:state:* , etc.
Der Wert kann mehrere Auswahlmöglichkeiten haben , durch folgende Syntax: "device:state:(on/off)". In diesem Fal reagiert der Zweig sowohl auf den Wert on, als auch auf off.

auszug wiki:
Zitat
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.
Es können mehrere Events gleichzeitig eingegeben werden, eine Trennung erfolgt durch " , "
Hier ist zu unterscheiden, ob das gewählte triggernde Device ein einfaches Device ist oder ob der Trigger 'GLOBAL' ist.
Bei triggernden Devices können Events in folgendem Formaten zugefügt werden:

- * - Aktion erfolgt auf alle auftretende Events des entsprechenden Device
- reading:wert (z.b. state:on ) - Aktion erfolgt nur auf das Event "state:on"
- reading:* (z.b. state:* ) - Aktion erfolgt auf die Events "state:(on,off,etc.)
- reading:(wert1/wert2/wert3) (z.b. state:(left/right) - Aktion erfolgt nur auf Events "state:left" oder "state:right" etc.

Falls auf 'GLOBALE' Events getriggert wird, muss das auslösende Device vorangestellt werden:

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


zugegeben , das ist nicht wirklich schön - dieser unterschied . ggf. traue ich mich da irgendwann mal ran.

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Bäschdler am 18 Oktober 2018, 17:41:23
HEUREKA !!!

Ich habe wie du mir geschrieben hast den Trigger geändert und es hat funktioniert. :-)

Der Dummy steht auf 270.


Jetzt kann ich schauen ob der Ablauf wirklich so tut wie ich geplant hatte ;-)


DANKE für die Hilfe !!!!
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 18 Oktober 2018, 17:46:01
HEUREKA !!!

Ich habe wie du mir geschrieben hast den Trigger geändert und es hat funktioniert. :-)

Der Dummy steht auf 270.


Jetzt kann ich schauen ob der Ablauf wirklich so tut wie ich geplant hatte ;-)



DANKE für die Hilfe !!!!

ok ,wenn es nachwievor probleme gibt melde dich einfach.

ps: editiere doch bitte den vorherigen beitrag un nimm die raw raus , ich brauche sie dann nicht und sie ist eh irgendwie 'zerrissen'  ;)

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 21 Oktober 2018, 09:46:58
aktualisierte Testversion im GIT vorhanden.

wer mit der Testversion arbeitet sollte diese bitte entsprechend updaten ( siehe post 1 des threads )

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: Bäschdler am 21 Oktober 2018, 17:27:15
Hallo Byte09,

ich verstehe gerade nicht warum folgendes passiert:
Der MSwitch hat bei einem FreeCmd quasi dieselbe condition. Der Plan wäre, dass der Dummy auf 240 gesetzt wird und dann nach 2 Minuten auf 250 gesetzt wird. Die 250 erreicht er aber nie (auch bei den anderen FreeCmd's die so aufgebaut sind nicht), sondern immer dann erst den nächsten Wert des nächsten FreeCmd's. Wenn ich get active timer mache kommt
Zitat
aktive Delays:
2018-10-21 17:21:33   set Rolladen_Aktionen 250
Da steht aber jedesmal der Zeitpunkt in 2 Minuten drin. Der MSwitch startet also jedesmal (er wird jede Minute getriggert) den Timer neu. Bei der Einstellung "condition check immediately only" hätte ich gedacht wird der Timer einmal getriggert, läuft dann im Hintergrund und führt dann nach der eingestellten Zeit das command aus.
Denke ich da falsch?

Danke und Grüsse
Bäschdler


Hier ein Beispielhafter Auszug eines FreeCmd:
Zitat
Device: FreeCmd-AbsCmd10
cmd1: cmd set Rolladen_Aktionen 250
cmd2: cmd set Rolladen_Aktionen 240
cmd1 condition: [myLocation:azimuth] > 230 AND [myLocation:azimuth] < 245 AND  [Rolladen_Aktionen:state] < 250
cmd2 condition: [myLocation:azimuth] > 230 AND [myLocation:azimuth] < 245 AND [Rolladen_Aktionen:state] < 240
cmd1 delay: 00:02:00
cmd2 delay: 00:00:00
repeats:
repeats delay:
priority: 1
id: 0
comment:
cmd1 exit: 0
cmd2 exit: 0
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 21 Oktober 2018, 19:20:43
hi Bäschdler.

ich gehe mal davon aus, das es sich u das gleiche device vom letzten mal handelt ?

wenn dem so ist , werden alle delays glöscht, wenn ein neues (passendes) event 'hereinkommt':
Attribut MSwitch_Delete_Delays: 1
.... ändere das mal auf '0'.

Zitat
MSwitch_Delete_Delays (0:1)

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)


ausserdem musst du dir über die reihenfolge der abarbeitung bewusst sein , ich weiss aber nicht , ob das bei deinem device eine rolle spielt.

wenn ein und das selbe event cmd1 und cmd2 auslöst, ist die reihenfolge der abarbeitung der befehle nicht :

AD ( affected defice ) cmd1
AD cmd2
AD1 cmd1
AD1 cmd2
etc.

sondern:

AD cmd2
AD1 cmd2
AD2 cmd2
AD cmd1
AD1 cmd1
AD2 cmd1

dabei können natürlich gehörige unterschiede ( besonders in einem solchen Konstrukt ) im ergebniss entstehen.
Da du es im grunde zweckentfremdest , imdem du immer beide zweige auslöst , emfehle ich das entsprechend zu ändern , d.H nur einen zweig auslösen und alle Schaltvorgändge in diesen zweig in verschiedene ADs zu packen ,
bei dem was du erreichen willst wäre es ggf. sogar das beste , nur ein AD anzulegen , dieses im PERLmode auszuführen '{}' und die unterscheidung dort - in diesem einen affected device - zu machen und auch von dort aus den schaltbefehl abzusetzen . Das ist leztendlich viel schneller für das Modul abzuarbeiten , und  im Grunde viel einfacher in der Handhabung , da du nie die Kontrolle über die Reihenfolge verlierst.

und ich würde sogar behauüpten , das hier ( speziell für dein vorhaben ) ggf. ein Ausweichen auf die 99_utils der beste weg sein dürfte.

gruss Byte09
Titel: Antw:98_MSwitch - Support
Beitrag von: ChrisW am 07 November 2018, 15:14:18
Ich möchte gerne das "Kamin" um 23.59 auf off gesetzt wird falls er "on" ist ...
Wie bastel ich das am einfachsten ein ?
Internals:
   DEF        Kamin # heizung_wohnzimmersofa_Clima heizung_wohnzimmervitrine_Clima heizung_esszimmer_Clima
   NAME       Kamin
   NOTIFYDEV  Kamin
   NR         909
   NTFY_ORDER 45-Kamin
   STATE      off
   TYPE       MSwitch
   Version_Datenstruktur V2.00
   Version_Modul 2.02
   Version_autoupdate on
   eventsave  unsaved
   .attraggr:
   .attrminint:
   OLDREADINGS:
   READINGS:
     2018-11-06 16:51:06   .Device_Affected heizung_esszimmer_Clima-AbsCmd1,heizung_wohnzimmersofa_Clima-AbsCmd1,heizung_wohnzimmervitrine_Clima-AbsCmd1
     2018-11-06 16:52:47   .Device_Affected_Details heizung_esszimmer_Clima-AbsCmd1#[NF]controlManu#[NF]controlMode#[NF]16.0#[NF]auto#[NF]delay1#[NF]delay1#[NF]00#[dp]00#[dp]00#[NF]00#[dp]00#[dp]00#[NF]#[NF]#[NF]#[NF]#[NF]1#[NF]0#[NF]#[NF]0#[NF]0#[NF]1#[ND]heizung_wohnzimmersofa_Clima-AbsCmd1#[NF]controlManu#[NF]controlMode#[NF]16.0#[NF]auto#[NF]delay1#[NF]delay1#[NF]00#[dp]00#[dp]00#[NF]00#[dp]00#[dp]00#[NF]#[NF]#[NF]#[NF]#[NF]1#[NF]0#[NF]#[NF]0#[NF]0#[NF]1#[ND]heizung_wohnzimmervitrine_Clima-AbsCmd1#[NF]controlManu#[NF]controlMode#[NF]16.0#[NF]auto#[NF]delay1#[NF]delay1#[NF]00#[dp]00#[dp]00#[NF]00#[dp]00#[dp]00#[NF]#[NF]#[NF]#[NF]#[NF]1#[NF]0#[NF]#[NF]0#[NF]0#[NF]1
     2018-11-06 21:49:15   .Device_Events  no_trigger
     2018-11-06 16:13:46   .First_init     done
     2018-11-06 16:13:46   .Trigger_cmd_off no_trigger
     2018-11-06 16:13:46   .Trigger_cmd_on no_trigger
     2018-11-07 15:07:37   .Trigger_condition
     2018-11-06 16:13:46   .Trigger_off    no_trigger
     2018-11-06 16:13:46   .Trigger_on     no_trigger
     2018-11-07 15:07:37   .Trigger_time   
     2018-11-06 16:13:46   .V_Check        V2.00
     2018-11-07 15:07:36   EVENT           Trigger_device:Kamin
     2018-11-07 15:07:36   EVTFULL         Kamin:Trigger_device:Kamin
     2018-11-07 15:07:36   EVTPART1        Kamin
     2018-11-07 15:07:36   EVTPART2        Trigger_device
     2018-11-07 15:07:36   EVTPART3        Kamin
     2018-11-06 21:49:15   Exec_cmd        set heizung_esszimmer_Clima controlMode auto,set heizung_wohnzimmersofa_Clima controlMode auto,set h....
     2018-11-07 15:07:36   Trigger_device  Kamin
     2018-11-06 16:13:46   Trigger_log     off
     2018-11-07 15:07:36   incomming       Trigger_device:Kamin
     2018-11-07 15:07:36   last_event      Trigger_device:Kamin
     2018-11-06 21:49:15   state           off
   helper:
     eventfrom  Kamin
     events:
       Kamin:
         no_trigger on
     savemodeblock:
Attributes:
   MSwitch_Debug 0
   MSwitch_Delete_Delays 1
   MSwitch_Expert 0
   MSwitch_Extensions 0
   MSwitch_Help 1
   MSwitch_Ignore_Types notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
   MSwitch_Include_Devicecmds 1
   MSwitch_Include_MSwitchcmds 0
   MSwitch_Include_Webcmds 0
   MSwitch_Lock_Quickedit 1
   MSwitch_Mode Full
   room       timer
Titel: Antw:98_MSwitch - Support
Beitrag von: Byte09 am 07 November 2018, 17:22:18
Ich möchte gerne das "Kamin" um 23.59 auf off gesetzt wird falls er "on" ist ...
Wie bastel ich das am einfachsten ein ?
Internals:
   DEF        Kamin # heizung_wohnzimmersofa_Clima heizung_wohnzimmervitrine_Clima heizung_esszimmer_Clima
   NAME       Kamin
   NOTIFYDEV  Kamin
   NR         909
   NTFY_ORDER 45-Kamin
   STATE      off
   TYPE       MSwitch
   Version_Datenstruktur V2.00
   Version_Modul 2.02
   Version_autoupdate on
   eventsave  unsaved
   .attraggr:
   .attrminint:
   OLDREADINGS:
   READINGS:
     2018-11-06 16:51:06   .Device_Affected heizung_esszimmer_Clima-AbsCmd1,heizung_wohnzimmersofa_Clima-AbsCmd1,heizung_wohnzimmervitrine_Clima-AbsCmd1
     2018-11-06 16:52:47   .Device_Affected_Details heizung_esszimmer_Clima-AbsCmd1#[NF]controlManu#[NF]controlMode#[NF]16.0#[NF]auto#[NF]delay1#[NF]delay1#[NF]00#[dp]00#[dp]00#[NF]00#[dp]00#[dp]00#[NF]#[NF]#[NF]#[NF]#[NF]1#[NF]0#[NF]#[NF]0#[NF]0#[NF]1#[ND]heizung_wohnzimmersofa_Clima-AbsCmd1#[NF]controlManu#[NF]controlMode#[NF]16.0#[NF]auto#[NF]delay1#[NF]delay1#[NF]00#[dp]00#[dp]00#[NF]00#[dp]00#[dp]00#[NF]#[NF]#[NF]#[NF]#[NF]1#[NF]0#[NF]#[NF]0#[NF]0#[NF]1#[ND]heizung_wohnzimmervitrine_Clima-AbsCmd1#[NF]controlManu#[NF]controlMode#[NF]16.0#[NF]auto#[NF]delay1#[NF]delay1#[NF]00#[dp]00#[dp]00#[NF]00#[dp]00#[dp]00#[NF]#[NF]#[NF]#[NF]#[NF]1#[NF]0#[NF]#[NF]0#[NF]0#[NF]1
     2018-11-06 21:49:15   .Device_Events  no_trigger
     2018-11-06 16:13:46   .First_init     done
     2018-11-06 16:13:46   .Trigger_cmd_off no_trigger
     2018-11-06 16:13:46   .Trigger_cmd_on no_trigger
     2018-11-07 15:07:37   .Trigger_condition
     2018-11-06 16:13:46   .Trigger_off    no_trigger
     2018-11-06 16:13:46   .Trigger_on     no_trigger
     2018-11-07 15:07:37   .Trigger_time   
     2018-11-06 16:13:46   .V_Check        V2.00
     2018-11-07 15:07:36   EVENT           Trigger_device:Kamin
     2018-11-07 15:07:36   EVTFULL         Kamin:Trigger_device:Kamin
     2018-11-07 15:07:36   EVTPART1        Kamin
     2018-11-07 15:07:36   EVTPART2        Trigger_device
     2018-11-07 15:07:36   EVTPART3        Kamin
     2018-11-06 21:49:15   Exec_cmd        set heizung_esszimmer_Clima controlMode auto,set heizung_wohnzimmersofa_Clima controlMode auto,set h....
     2018-11-07 15:07:36   Trigger_device  Kamin
     2018-11-06 16:13:46   Trigger_log     off
     2018-11-07 15:07:36   incomming       Trigger_device:Kamin
     2018-11-07 15:07:36   last_event      Trigger_device:Kamin
     2018-11-06 21:49:15   state           off
   helper:
     eventfrom  Kamin
     events:
       Kamin:
         no_trigger on
     savemodeblock:
Attributes:
   MSwitch_Debug 0
   MSwitch_Delete_Delays 1
   MSwitch_Expert 0
   MSwitch_Extensions 0
   MSwitch_Help 1
   MSwitch_Ignore_Types notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
   MSwitch_Include_Devicecmds 1
   MSwitch_Include_MSwitchcmds 0
   MSwitch_Include_Webcmds 0
   MSwitch_Lock_Quickedit 1
   MSwitch_Mode Full
   room       timer

zwei kleineEigenheiten von MSwitch:
1. das überall geforderte List desDevices hier nicht wirklich geeignet ist um zu helfen .
2. du kannst leider kaum Hilfe erwarten, ausser von mir, da das Modul leider nur recht wenig genutzt wird und es insofern nur eine handoll User gibt, die sich damit auskennen - denke ich . Führt leider dazu , das es mal länger dauern kann , so wie jetzt  :-\

geh doch in betreffendem Device mal auf get get_config und poste mir diese. ich setze es dir dann ein und schicke sie dir zurück . ist der einfachste weg. dann siehst du wie es sein muss.

ansonsten bitte bei fragen immer auf
 get get_support_info und diesen file posten , das macht es einfacher für mich .

Dieses gilt aber nur für MSwitch - Devices.

gruss Byte09


edit : habe dir mal die rawdef eines MSwitch angehangen , das nur die gewünschte aktion ausführt ( nicht in kombination mit bestehendem device, dazu benötige ich oben angesprochene daten )
da ein manuelles schalten hier ja nicht erforderlich ist , habe ich das device in den notify-mode gesetzt ( attribut 'MSwitch_Mode' -> 'Notify' )
den im device eingefügten Kommentar kannst du durch löschen des Attributs 'MSwitch_Comments' bzw durch setzen auf '0' löschen.

defmod Kamin_off MSwitch
attr Kamin_off MSwitch_Comments 1
attr Kamin_off MSwitch_Debug 0
attr Kamin_off MSwitch_Delete_Delays 1
attr Kamin_off MSwitch_Expert 0
attr Kamin_off MSwitch_Extensions 0
attr Kamin_off MSwitch_Help 0
attr Kamin_off MSwitch_Ignore_Types notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
attr Kamin_off MSwitch_Include_Devicecmds 1
attr Kamin_off MSwitch_Include_MSwitchcmds 0
attr Kamin_off MSwitch_Include_Webcmds 1
attr Kamin_off MSwitch_Inforoom MSwitch
attr Kamin_off MSwitch_Lock_Quickedit 1
attr Kamin_off MSwitch_Mode Notify
attr Kamin_off room 1_Test

setstate Kamin_off active
setstate Kamin_off 2018-11-07 17:51:38 .Device_Affected Kamin-AbsCmd1
setstate Kamin_off 2018-11-07 17:58:28 .Device_Affected_Details Kamin-AbsCmd1#[NF]no_action#[NF]off#[NF]#[NF]#[NF]delay1#[NF]delay1#[NF]00#[dp]00#[dp]00#[NF]00#[dp]00#[dp]00#[NF]#[NF][Kamin#[dp]state]#[sp]eq#[sp]"on"#[sp]AND#[sp][$EVTPART3]#[sp]eq#[sp]"17#[dp]54"#[NF]#[NF]#[NF]1#[NF]0#[NF]die#[sp]hier#[sp]angegebene#[sp]condition#[sp]muss#[sp]in#[sp]diesem#[sp]Fall#[sp]nicht#[sp]vorhanden#[sp]sein#[sp]#[ko]#[sp]wird#[sp]nur#[sp]dann#[sp]benötigt#[sp]#[ko]#[sp]wenn#[sp]ein#[sp]mswitch#[sp]verschiedene#[sp]aktionen#[sp]zu#[sp]verschiedenen#[sp]zeiten#[sp]ausführen#[sp]soll.#[sp]könntest#[sp]du#[sp]im#[sp]grunde#[sp]löschen.#[sp]gruss#[sp]Byte09#[NF]0#[NF]0#[NF]1
setstate Kamin_off 2018-11-07 17:51:07 .Device_Events no_trigger
setstate Kamin_off 2018-11-07 17:49:48 .First_init done
setstate Kamin_off 2018-11-07 17:49:48 .Trigger_cmd_off no_trigger
setstate Kamin_off 2018-11-07 17:49:48 .Trigger_cmd_on no_trigger
setstate Kamin_off 2018-11-07 17:52:59 .Trigger_condition
setstate Kamin_off 2018-11-07 17:49:48 .Trigger_off no_trigger
setstate Kamin_off 2018-11-07 17:49:48 .Trigger_on no_trigger
setstate Kamin_off 2018-11-07 17:52:59 .Trigger_time on~off~ononly~offonly[17#[dp]54]
setstate Kamin_off 2018-11-07 17:49:48 .V_Check V2.00
setstate Kamin_off 2018-11-07 17:54:00 EVENT Kamin_off:execute_timer_P4:17:54
setstate Kamin_off 2018-11-07 17:54:00 EVTFULL Kamin_off:execute_timer_P4:17:54
setstate Kamin_off 2018-11-07 17:54:00 EVTPART1 Kamin_off
setstate Kamin_off 2018-11-07 17:54:00 EVTPART2 execute_timer_P4
setstate Kamin_off 2018-11-07 17:54:00 EVTPART3 17:54
setstate Kamin_off 2018-11-07 17:54:00 Exec_cmd set Kamin off
setstate Kamin_off 2018-11-07 17:52:59 Trigger_device no_trigger
setstate Kamin_off 2018-11-07 17:49:48 Trigger_log off
setstate Kamin_off 2018-11-07 17:58:28 state active



das hie wäre das entsprechende get_support_info file:

Modulversion: 2.02