Autor Thema: 98_MSwitch - Support  (Gelesen 19050 mal)

Online Byte09

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 873
Antw:98_MSwitch - Support
« Antwort #420 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
Fhem 5.7, 3*RPi2, Harmony, Hyperion, HM-CFG-LAN, Signalduino, SignalESP, NanoCul
MAINTAINER: 98_Siro, 98_MSwitch

Offline Esjay

  • Sr. Member
  • ****
  • Beiträge: 809
Antw:98_MSwitch - Support
« Antwort #421 am: 10 September 2018, 18:10:00 »
Ok, habe den zusammenhang nicht gecheckt.

Danke für die Gedult.

Gruß

Offline Panik

  • Jr. Member
  • **
  • Beiträge: 86
Antw:98_MSwitch - Support
« Antwort #422 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
Cubietruck (mit FHEM),  FHEM 5.5 von fhem.de (root), Perl v5.12.2 , CUL USB V3 mit V 1.57 CUL868, TRXRFX433, FB7490

Online Byte09

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 873
Antw:98_MSwitch - Support
« Antwort #423 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
Fhem 5.7, 3*RPi2, Harmony, Hyperion, HM-CFG-LAN, Signalduino, SignalESP, NanoCul
MAINTAINER: 98_Siro, 98_MSwitch
Gefällt mir Gefällt mir x 2 Liste anzeigen

Online arthur_dent_2015

  • Full Member
  • ***
  • Beiträge: 156
Antw:98_MSwitch - Support
« Antwort #424 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


Online Byte09

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 873
Antw:98_MSwitch - Support
« Antwort #425 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
« Letzte Änderung: 13 September 2018, 21:06:08 von Byte09 »
Fhem 5.7, 3*RPi2, Harmony, Hyperion, HM-CFG-LAN, Signalduino, SignalESP, NanoCul
MAINTAINER: 98_Siro, 98_MSwitch

Online Byte09

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 873
Antw:98_MSwitch - Support
« Antwort #426 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
Fhem 5.7, 3*RPi2, Harmony, Hyperion, HM-CFG-LAN, Signalduino, SignalESP, NanoCul
MAINTAINER: 98_Siro, 98_MSwitch

Online arthur_dent_2015

  • Full Member
  • ***
  • Beiträge: 156
Antw:98_MSwitch - Support
« Antwort #427 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

Online Byte09

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 873
Antw:98_MSwitch - Support
« Antwort #428 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



Fhem 5.7, 3*RPi2, Harmony, Hyperion, HM-CFG-LAN, Signalduino, SignalESP, NanoCul
MAINTAINER: 98_Siro, 98_MSwitch

Online arthur_dent_2015

  • Full Member
  • ***
  • Beiträge: 156
Antw:98_MSwitch - Support
« Antwort #429 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

Online Byte09

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 873
Antw:98_MSwitch - Support
« Antwort #430 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


Fhem 5.7, 3*RPi2, Harmony, Hyperion, HM-CFG-LAN, Signalduino, SignalESP, NanoCul
MAINTAINER: 98_Siro, 98_MSwitch

Online arthur_dent_2015

  • Full Member
  • ***
  • Beiträge: 156
Antw:98_MSwitch - Support
« Antwort #431 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

Online Byte09

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 873
Antw:98_MSwitch - Support
« Antwort #432 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
« Letzte Änderung: 15 September 2018, 07:14:36 von Byte09 »
Fhem 5.7, 3*RPi2, Harmony, Hyperion, HM-CFG-LAN, Signalduino, SignalESP, NanoCul
MAINTAINER: 98_Siro, 98_MSwitch

Offline Torsten_MG

  • Full Member
  • ***
  • Beiträge: 364
Antw:98_MSwitch - Support
« Antwort #433 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
« Letzte Änderung: 15 September 2018, 08:47:03 von Torsten_MG »

Online Byte09

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 873
Antw:98_MSwitch - Support
« Antwort #434 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

« Letzte Änderung: 15 September 2018, 15:57:56 von Byte09 »
Fhem 5.7, 3*RPi2, Harmony, Hyperion, HM-CFG-LAN, Signalduino, SignalESP, NanoCul
MAINTAINER: 98_Siro, 98_MSwitch

 

decade-submarginal