FHEM Forum
FHEM => Automatisierung => Thema gestartet 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
-
@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
-
:) ist bedeutend besser geworden, seit dem letzten update !!!
-
Die Modulbeschreibung ist ab sofort hier zu finden:
https://wiki.fhem.de/wiki/MSwitch.pm (https://wiki.fhem.de/wiki/MSwitch.pm)
gruss Byte09
-
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
-
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
-
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
-
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!
-
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.
-
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...
-
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
-
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
-
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
-
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
-
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 :
-
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
-
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.
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
-
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
-
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 !
-
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
-
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.
-
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
-
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
-
...
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
-
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
-
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
-
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
-
@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
-
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
-
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
-
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
-
@Maista @Andies
danke für die Wiki Korrekturen
gruss Byte09
-
Moin Byte09
Gerne :) Opera hilft ;D
Schönen Sonntag
Gerd
-
Danke für das Modul!
Gesendet von iPhone mit Tapatalk Pro
-
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
-
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 : abortingbei
update all https://raw.githubusercontent.com/Byte009/FHEM-MSwitch/master/controls_mswitch.txt
-
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 : abortingbei
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
-
Looft.
-
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
-
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
-
update verfügbar: kleinere designänderungen
gruss Byte09
-
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
-
das lange wochenende steht ja vor der tür, da werde ich die Beispiele entsprechend ergänzen .
gruss Byte09
-
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
-
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
-
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
-
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
-
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
-
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
-
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 .
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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 ;)
-
@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
-
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
-
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
-
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
-
update auf V1.42 verfügbar.
gruss Byte09
-
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
-
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?
-
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
-
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! :)
-
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.
-
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
-
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
-
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
-
Man kommt ja mit dem Wikischreiben gar nicht hinterher :D
-
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
-
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?
-
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
-
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
-
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?
-
...
Jetzt klarer?
Leider nein
-
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
-
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!
-
Leider nein
Kannst du wenigstens sagen, wieso? Sonst hole ich mir auch ein Bier ;-)
-
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.
-
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
-
Auf den Punkt gebracht ;-)
Gruss Thomas
Gesendet von meinem SM-G900F mit Tapatalk
-
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 <name> MSwitch</code>
<br><br>
<code><name></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 <name> 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 <name> 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 <name> 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 <name> 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 <name> 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 <name> 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 <name> 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 <name> 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 <name> 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
-
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!
-
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
-
...
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
-
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
-
Das event ist im normalmode nur zweistellig , also state.* ... nicht *.state.*
Einfacher ist es wenn du die event speichern lässt.
Gruss Byte09Da fangen meine Probleme schon an, siehe Fotos. Anscheinend habe ich was falsch eingetragen
Gesendet von meinem SM-G900F mit Tapatalk
-
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
-
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
-
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
-
Verschieben wir das auf morgen, möchte dich nicht von deinem Bier abhalten ;)
-
Top , so machen wirres ;-)
Gruss Thomas
Gesendet von meinem SM-G900F mit Tapatalk
-
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.
-
Habe es jetzt mal versucht, siehe Screenshots. Aber wenn ich den Taster betätige passiert nichts
-
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
-
ich spiele in der nächsten Stunde ein Zwischenupdate ein , das diesen Fehler behebt.
gruss Byte09
-
Ich habe state nur mit (to broadcast)
und auf trigger:Short reagiert es nicht
-
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
-
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?
-
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
-
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 <name> MSwitch</code>
<br><br>
<code><name></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 <name> 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 <name> 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 <name> 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 <name> 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 <name> 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 <name> 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 <name> 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 <name> 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 <name> 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
-
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
-
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 !
-
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
-
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.
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
-
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
-
... 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
-
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
-
ok, bin jetzt noch auf das update gespannt, wegen dem Blinken, was du gestern in meinem anderen Thema angekündigt hast.
-
wird noch 1 , 2 Stunden dauern ;) ..... läuft bei mir zur Probe
-
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?
-
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..
-
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
-
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
-
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
-
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
-
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
-
wer lesen kann ist klar im vorteil ::)
-
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
-
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
-
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
-
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
-
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
-
Update auf V1.44
Fehler in der Webansicht behoben ( Auswahl der Eventfelder in den 'trigger details :' war Fehlerhaft )
Gruss Byte09
-
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
-
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
-
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
-
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
-
hi mark
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 : ...
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
-
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
-
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.
-
Ho Torsten,
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.
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
-
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
-
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
-
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
-
...
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
-
Funktioniert leide nicht
ich stelle das gerade mal mit einem dummy nach , melde mich dann.
gruss Byte09
-
ich stelle das gerade mal mit einem dummy nach , melde mich dann.
gruss Byte09
Siehe Edit ein Post drüber
-
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
-
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.
-
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
-
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
-
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
-
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
-
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
-
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
-
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)
-
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
-
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
-
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:
...configfile MSwitch ( die dummys müssen erst angelegt werden )...
Habe ich gedacht, ich brauche die!
Aber es läuft jetzt perfekt!
-
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 ...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
-
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
-
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
-
...
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
-
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
-
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.
-
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
-
...
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?
-
gib mir 10 minuten , poste dan die beispielkonfig.
gruss Thomas
-
gib mir 10 minuten , poste dan die beispielkonfig.
gruss Thomas
kein Sress!
-
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
-
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
-
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?
-
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.
-
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.
-
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?
-
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
-
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
-
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
-
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
-
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.
-
Da ich diese Woche Spätschicht habe, kann ich das dann erst Dienstag Vormittag testen
-
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
-
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
-
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
-
#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
-
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
-
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
-
...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
-
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
-
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
-
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
-
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.
-
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.
-
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
-
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.
-
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
-
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
-
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
-
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
-
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
-
Bin in 2 Std wieder zuhause ... schaue es mir dann an .
Gruss Byte09
Gesendet von meinem SM-G900F mit Tapatalk
-
Ok, bin in 30min zur Arbeit. Bin also erst ab morgen wieder erreichbar
-
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
-
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
-
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
-
Alle Events kommen so wie eingetragen, mache später mal Screenshots bin gerade unterwegs
-
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
-
... 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 ...
-
Hier mal die Screenshots von meinen Events
-
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
-
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:
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:
Unknown command Fhemsave, try help.
-
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
-
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
-
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
-
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
-
ich habe gerade ein update in das git gestellt, damit geht es.
gruss thomas
-
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
-
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
-
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
-
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
-
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
-
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.
-
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
-
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
-
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
-
Ich habe den Fehler gefunden, bei KU_MSwitch_Dummy fehlt das "state". ::)
Also so: KU_MSwitch_Dummy:state
-
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
-
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
-
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
-
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.
-
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 ;)
-
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 !
-
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?
-
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
-
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
-
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
-
Ich meine, ich hatte es damals genau so wie im oberen Post gemacht
-
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
-
@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
-
@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!
-
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
-
@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.
-
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
-
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
-
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
-
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.
-
@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:
- 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?
-
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
-
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
2Ist das normal?
-
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
2Ist 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
-
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>Ü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ü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 <name> 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
-
@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?
-
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
-
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
-
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
-
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 ;)
-
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
-
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.
-
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
-
@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
#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
-
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
-
Da ist aber ein Fehler drin, siehe Foto. Da ist ein " zu viel
-
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 [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 :([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 {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
-
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
-
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
-
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.
-
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
-
immer, also auch bei zeitauslösung, oder wenn du ihn 'abrufst' ?
gruss Byte09
Nur bei manuellem abruf
-
Nur bei manuellem abruf
ja, habe es gerade probiert, liegt am MSwitch ... schaue mir das gerade an
-
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
-
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
-
Bin gerade unterwegs und gleich zur Arbeit. Werde heute nicht mehr testen können
Gesendet von meinem SM-J730F mit Tapatalk
-
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.
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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ß
-
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
-
das problem mit dem DarkStyle sollte behoben sein.
gruss Byte09
-
das problem mit dem DarkStyle sollte behoben sein.
gruss Byte09
Funktioniert!
Super!
-
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")}
}
-
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
-
...
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!
-
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
-
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.
-
ok, vielen Dank. Werde ich gleich einpflegen und beim nächsten Fall merken ob´s dann klappt
-
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
-
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
-
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
-
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
-
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"
-
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
-
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
-
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
-
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!!
-
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
-
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
-
Ich bin heute den ganzen tag unterwegs , schaue mir das dann heute abend an .
Gruss byte09
Gesendet von meinem SM-G900F mit Tapatalk
-
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:
[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.
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
-
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
-
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.
-
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
-
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
-
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
-
Ups.... kümmere mich morgen um die Warnungen . Aber es geht hoffe ich ?
Gruss Byte09
Gesendet von meinem SM-G900F mit Tapatalk
-
Ja die Funktion ist soweit gegeben 👍
-
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
-
... ( 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
-
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
-
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.
-
Ok , dann schaue ich es mir auch in Ruhe heute abend an.
Gruss Byte09
Gesendet von meinem SM-G900F mit Tapatalk
-
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
-
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
-
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 )
-
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
-
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
-
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
-
Im Grunde sollte es mit v1.69 auch gehen wenn du beides auf 1 setzt ?!
Gruss Byte09ON und OFF funktionieren jetzt bei mir mit den Einstellungen
MSwitch_Include_Devicecmds 0
MSwitch_Include_Webcmds 1
Gesendet von meinem SM-G900F mit Tapatalk
-
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
-
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
-
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.
-
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
-
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.
-
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
-
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
-
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?
-
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
-
Danke, probiere ich morgen Nachmittag aus, bin jetzt auf der Arbeit (Nachtschicht)
Gesendet von meinem SM-J730F mit Tapatalk
-
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.
-
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
-
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
-
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
-
habe dir mal eine PM geschrieben , wenn du willst kannst du mich gerne mal anrufen.
gruss Byte09
-
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>")
}
-
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
-
Zusätzlich muß ja dieser Code um 5sek verzögert abgesetzt werden.
-
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
-
Mit dem Code funktioniert es noch nicht.
Aber mit dem 2. freecmd und den 5sek und den Aufruf {Fahrplan()} funktionierts
-
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
-
Kein Streß, es funktioniert ja erstmal!!
-
Kein Streß, es funktioniert ja erstmal!!
noch eine kleinigkeit umgebaut, geht jetzt bei mir mit V1.71b.
danke für deine Geduld.
gruss Byte09
-
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
-
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
-
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:
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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?
-
Dann lösche ich das mal aus dem Wiki, oder?
ja, prima.
gruss Byte09
-
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
-
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
-
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
-
Shit happens ;)
-
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…
-
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
-
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
-
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
-
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
-
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
.
-
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
-
@ 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
-
@Bytes01 - sieht im WebGui schon mal besser aus ... bin mir noch nicht ganz schlüssig, wie ich das testen kann.
Christian
-
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
-
PS: setze mal die attribute Mswitch_help und MSwitch_debug auf 1 , dann bekommst du entsprechende hilfetexte und prüfoptionen
gruss Byte09
-
Habe die 18:00 Bedingung auf 14:05 gesetzt und "Check Condition" gemacht:
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
-
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.
-
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
-
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
-
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
-
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
-
Ok. Probiere ich später mal aus
Gesendet von meinem SM-J730F mit Tapatalk
-
update all gemacht und shutdown restart.
Bleibt bei V1.73
Aber die Daten bleiben drin! Habe mehrere shutdown restart gemacht!
-
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
-
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
-
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
-
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 !
-
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
-
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 ?
-
... poste doch mal ein screen , dieser drei befehle ( anhang ) .
..
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
Viele Wege führen nach Rom
;)
-
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
-
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 ...
-
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
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
-
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
-
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
-
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
-
Ich habe eben einen FIX in das SVN geladen , der das Problem hoffentlich beseitigt.
gruss Byte09
-
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
-
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
-
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?
-
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 :
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
-
Nabend, kurze Frage.
Wie bekomme ich Repeat und Repeatdelay eingeblendet?
Geschweige denn, wo ist "without Conf-check" ?
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
-
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
-
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......."
-
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
-
Ok, habe den zusammenhang nicht gecheckt.
Danke für die Gedult.
Gruß
-
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
-
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
-
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
-
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
-
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
-
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
-
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.
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
-
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
-
hi,
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:
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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 :( .
-
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
-
Hallo,
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
-
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
-
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
-
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
-
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.
-
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
-
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
-
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
-
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:
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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.
-
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
-
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
-
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
-
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
-
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
-
Jap ohne Probleme mehrmals hintereinander.
Grüße
-
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
-
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
-
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.
- 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 .
- 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.
- 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
-
Hallo,
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
-
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
-
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
-
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
-
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:
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):
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:
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?
-
ok , thx für die info.
schaue ich mir an , komme aber erst morgen abend dazu.
gruss Byte09
-
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
-
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
-
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
-
Tip Top !
Ich danke dir!
8)
Grüße
-
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 .
-
Moin Byte09
habe im Log folgende Meldung
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
-
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
-
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
-
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 ?
Folgende Fehlermeldung bekomme ich wenn ich auf "check condition" gehe:
gruss Byte09
-
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
-
@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
-
@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
-
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
-
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
-
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
-
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
-
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
-
Ich zweifle gerade entweder an meinen Programmierkünsten oder am MSwitch:
Folgendes habe ich als condition:
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?
-
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
-
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 .
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
-
ja super, mach entspannt.
so hatte ich es schon probiert, bestimmt aber nicht richtig!!
danke und grüße
pflock_y
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
...
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
-
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):
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
-
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
-
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:
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
-
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.
-
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
-
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
-
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:
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
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
-
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
-
Guten Morgen,
danke für die ausführliche Antwort.
Anscheinend müsste ja jetzt das was ich programmiert habe eigentlich wenigstens ein bisschen funktionieren ;-)
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.
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.
...... 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.
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".
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
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
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
-
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
-
Hallo Byte09,
hier das Log
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:
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:
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
-
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
-
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:
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:
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
-
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 !!!!
-
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
-
aktualisierte Testversion im GIT vorhanden.
wer mit der Testversion arbeitet sollte diese bitte entsprechend updaten ( siehe post 1 des threads )
gruss Byte09
-
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
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:
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
-
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'.
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
-
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
-
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