Mit der neuen Version ist es nun möglich Befehlszweige bzw. Zustände über einen set-Befehl bedingungslos auszulösen.
Die Syntax lautet:
set <DOIF_Modul> cmd_<NR>
Der Befehl hat folgende Eigenschaften:
1) es wird der Ausführungszweig mit der Nummer <NR> (cmd_1, cmd_2, cmd_3, usw. ) bedingungslos ausgeführt
2) der set-Befehl übersteuert alle Attribute wie z. B. wait, do, usw.
3) ein laufender Wait-Timer wird unterbrochen.
4) beim deaktivierten oder im Modus disable befindlichen Modul wird der set Befehl ignoriert.
Die Übersteuerung der Befehlsausführung lässt sich damit leicht über das Webinterface vornehmen.
Bsp.: Schaltbare Lampe über Fernbedienung und Webinterface
define di_lamp DOIF ([FB:"on"]) (set lamp on) DOELSEIF ([FB:"off"]) (set lamp off)
attr di_lamp cmdState on|off
attr di_lamp devStateIcon on:on:cmd_2 initialized|off:off:cmd_1
Das Anklicken des on/off-Lampen-Icons führt zum Schalten der Lampe.
Edit: Version wurde eingecheckt
Ich sehe, dass die Version sechs mal geladen wurde.
Wie sind die Erfahrungen? Gibt es noch Ideen zum neuen set cmd-Kommando?
Ansonsten werde ich die Version einchecken.
Ich habe es bisher nur an einer Stelle genutzt, finde es aber super.
Finde ich echt toll und funktoniert super an inzwischen vielen Stellen!!!
Bin begeistert. Vielen Dank.
Als ich diesen Post verfasste https://forum.fhem.de/index.php/topic,66090.msg573383.html#msg573383
empfand ich es als recht kompliziert diesen einfachen Fall (Lampe on/off über Webinterface zu schalten) mit DOIF abzubilden.
Ein paar Stunden später gab´s dann diese Version ;)
Ich habe vorher immer noch structures erstellt um alle betroffenen Geräte auf einmal schalten zu können, aber so ist es doch deutlich einfacher.
Mir gefällt, dass trotz der Aussage:
Zitat2) der set-Befehl übersteuert alle Attribute wie z. B. wait, do, usw.
in Befehlssequenzen die Wait-Timer wie gewohnt berücksichtigt werden.
Ist in dieser Version auch die Optimierung der indirekten Timer enthalten (checkReadingEvent für indirekte Timer intern als default)?
Zitat von: Ellert am 08 Februar 2017, 19:26:40
Mir gefällt, dass trotz der Aussage:in Befehlssequenzen die Wait-Timer wie gewohnt berücksichtigt werden.
Ist in dieser Version auch die Optimierung der indirekten Timer enthalten (checkReadingEvent für indirekte Timer intern als default)?
-neben dem neuen set cmd-Kommado, ist checkReadingEvent für indirekte Timer als default drin
-es werden Angaben in eckigen Klammern im Ausführungsteil nur ersetzt, wenn sie auch wirklich ersetzbar sind (also existierende Readings und Devices beinhalten), sonst bleibt der Ausdruck wie er ist, siehe https://forum.fhem.de/index.php/topic,65916.msg571719.html#msg571719
-es wird nur der laufende Timer unterbrochen bzw. der erste übersteuert, die Waittimer der Folgesequenzen werden wie gewohnt abgearbeitet.
-für die Nachvollziehbarkeit der Ausführung, steht im Reading cmd_event das set-Kommando drin, so lässt sich der manuelle Auslöser identifizieren.
- sinnvolle cmd-Befehle werden abhängig von der Definition automatisch erkannt und im set-dropdown Menü angezeigt.
- cmd-Angaben, die es laut Definition nicht gibt, werden bewusst nicht abgefangen, man kann damit einen neuen Zustand setzen, den es sonst nicht gibt z. B. set my_DOIF cmd_99 - wer weiß wofür es gut sein kann ;)
Der Wunsch nach set cmd wurde schon früher geäußert, den Nutzen habe ich damals nicht gesehen. In Verbindung mit dem Webinterface macht die Erweiterung allerdings durchaus Sinn.
Zum Glück war die Realisierung einfacher, als ich befürchtet hatte. :)
Es fehlt nur noch die Doku. Ich denke, das werde ich am Wochenende vervollständigen und dann die Version einchecken.
Diese Version ist super. Ich habe sie schon im Einsatz mit Alexa:
Internals:
DEF ([$SELF:mybutton] eq "start") ({system ("sudo /etc/init.d/alexa start > /dev/null 2>&1 &")})
DOELSEIF ([$SELF:mybutton] eq "stop") ({system ("sudo /etc/init.d/alexa stop > /dev/null 2>&1 &")})
DOELSEIF ([$SELF:mybutton] eq "restart") ({system ("sudo /etc/init.d/alexa restart > /dev/null 2>&1 &")})
DOELSEIF ([$SELF:mybutton] eq "status") ({system ("sudo /etc/init.d/alexa status > /dev/null 2>&1 &")})
NAME FHEM.Alexa.DOIF
NR 1553
NTFY_ORDER 50-FHEM.Alexa.DOIF
STATE Alexa running as PID 19053
TYPE DOIF
.userReadings:
Readings:
2017-02-09 10:19:32 Device FHEM.Alexa.DOIF
2017-02-09 10:19:31 INFO Alexa running as PID 19053
2017-02-09 10:19:32 STATUS on
2017-02-09 10:08:26 cmd 1
2017-02-09 10:08:26 cmd_event FHEM.Alexa.DOIF
2017-02-09 10:08:26 cmd_nr 1
2017-02-09 10:19:32 e_FHEM.Alexa.DOIF_mybutton start
2017-02-09 10:08:26 error {system ("sudo /etc/init.d/alexa start > /dev/null 2>&1 &")}: -1
2017-02-09 10:08:26 mybutton start
2017-02-09 10:08:26 state on
Condition:
0 ReadingValDoIf($hash,'FHEM.Alexa.DOIF','mybutton') eq "start"
1 ReadingValDoIf($hash,'FHEM.Alexa.DOIF','mybutton') eq "stop"
2 ReadingValDoIf($hash,'FHEM.Alexa.DOIF','mybutton') eq "restart"
3 ReadingValDoIf($hash,'FHEM.Alexa.DOIF','mybutton') eq "status"
Devices:
0 FHEM.Alexa.DOIF
1 FHEM.Alexa.DOIF
2 FHEM.Alexa.DOIF
3 FHEM.Alexa.DOIF
all FHEM.Alexa.DOIF
Do:
0:
0 {system ("sudo /etc/init.d/alexa start > /dev/null 2>&1 &")}
1:
0 {system ("sudo /etc/init.d/alexa stop > /dev/null 2>&1 &")}
2:
0 {system ("sudo /etc/init.d/alexa restart > /dev/null 2>&1 &")}
3:
0 {system ("sudo /etc/init.d/alexa status > /dev/null 2>&1 &")}
Helper:
event STATUS: on,Device: FHEM.Alexa.DOIF,e_FHEM.Alexa.DOIF_mybutton: start
globalinit 1
last_timer 0
sleeptimer -1
timerdev FHEM.Alexa.DOIF
timerevent STATUS: on,Device: FHEM.Alexa.DOIF,e_FHEM.Alexa.DOIF_mybutton: start
triggerDev FHEM.Alexa.DOIF
timerevents:
STATUS: on
Device: FHEM.Alexa.DOIF
e_FHEM.Alexa.DOIF_mybutton: start
timereventsState:
STATUS: on
Device: FHEM.Alexa.DOIF
e_FHEM.Alexa.DOIF_mybutton: start
triggerEvents:
STATUS: on
Device: FHEM.Alexa.DOIF
e_FHEM.Alexa.DOIF_mybutton: start
triggerEventsState:
STATUS: on
Device: FHEM.Alexa.DOIF
e_FHEM.Alexa.DOIF_mybutton: start
Internals:
Itimer:
Readings:
0 FHEM.Alexa.DOIF:mybutton
1 FHEM.Alexa.DOIF:mybutton
2 FHEM.Alexa.DOIF:mybutton
3 FHEM.Alexa.DOIF:mybutton
all FHEM.Alexa.DOIF:mybutton
Regexp:
0:
1:
2:
3:
All:
State:
Trigger:
Attributes:
cmdState on|off|restart|status
readingList mybutton
room Alexa
setList mybutton:start,stop,restart,status
stateFormat INFO
userReadings INFO STATUS
webCmd mybutton
Funktioniert prima.
Gruß
Carlos
Neue Version wurde eingecheckt. Sie ist morgen per Update verfügbar.
Ich habe mit dem Update ab und zu eine Perl-Warnung, konnte aber noch keine bestimmte Definition erkennen:
PERL WARNING: Use of uninitialized value $cmdList in concatenation (.) or string at ./FHEM/98_DOIF.pm line 2030, <GEN15> line 33.
Zitat von: Ellert am 12 Februar 2017, 19:46:47
Ich habe mit dem Update ab und zu eine Perl-Warnung, konnte aber noch keine bestimmte Definition erkennen:
PERL WARNING: Use of uninitialized value $cmdList in concatenation (.) or string at ./FHEM/98_DOIF.pm line 2030, <GEN15> line 33.
Das sind vermutlich die DOIF-Fälle ohne jegliche Bedingungen. Da fehlt die Initialisierung. Werde ich gleich korrigieren.
Zitat von: Damian am 12 Februar 2017, 20:12:26
Das sind vermutlich die DOIF-Fälle ohne jegliche Bedingungen. Da fehlt die Initialisierung. Werde ich gleich korrigieren.
Ich habe die korrigierte Version eingecheckt.
Kurze Rückinfo: hat alles funktioniert wie vorher (wusste nämlich nix von dem Termin :D), ein neues DOIF mit den neuen Features hat auch ausgezeichnet gearbeitet.
Ich habe neue Zeitvariablen $md im Format "MM-DD" und $ymd im Format "YYYY-MM-DD" eingebaut:
Damit lassen sich größere Zeitbereiche in der Bedingung eingrenzen:
vom 01.01 bis zum 26.02:
$md ge "01-01" and $md le "02-26"
oder
z. B. es Weihnachtet:
$ymd ge "2017-12-23" and $ymd le "2018-01-05"
Version ist bereits eingecheckt und ab morgen verfügbar.
Man kann so etwas natürlich über die holiday-Datei machen. Allerdings sind dort keine Jahresangaben vorgesehen.
Danke.
Aber verstehe ich was falsch?
"YYYY-MM-DD"
Wäre doch danbn nicht
2017-23-12
sondern nach meinem Verständnis
2017-12-23
Sorry, falls ich triefe. :-)
Zitat von: Invers am 14 Februar 2017, 23:07:58
Danke.
Aber verstehe ich was falsch?
"YYYY-MM-DD"
Wäre doch danbn nicht
2017-23-12
sondern nach meinem Verständnis
2017-12-23
Sorry, falls ich triefe. :-)
Gut aufgepasst, war mein Fehler ich korrigiere es im Post gleich.
Wäre es sinnvoll den direkten set-Befehl zu erweitern und cmdState mit einbeziehen.
So, dass cmd_<nr> ein gültiger Set-Parameter ist und wenn cmdState für den letzten Befehl eines Zweiges gesetzt ist, dieser Wert der gültige Parameter ist?
(Bedingung) () () ()
DOELSEIF (Bedingung) () () ()
cmdState ,,|,,on
In der cmdList würde dann "cmd_1 on" stehen und für DOIF_cmd müsste dann auf "cmd_2" zurück gemapped werden.
Zitat von: Ellert am 15 Februar 2017, 19:59:49
Wäre es sinnvoll den direkten set-Befehl zu erweitern und cmdState mit einbeziehen.
So, dass cmd_<nr> ein gültiger Set-Parameter ist und wenn cmdState für den letzten Befehl eines Zweiges gesetzt ist, dieser Wert der gültige Parameter ist?
(Bedingung) () () ()
DOELSEIF (Bedingung) () () ()
cmdState ,,|,,on
In der cmdList würde dann "cmd_1 on" stehen und für DOIF_cmd müsste dann auf "cmd_2" zurück gemapped werden.
Ich habe auch schon überlegt cmdStat für setlist auszuwerten
mit cmdStat on|off
würde in der Dropdown-Auswahl statt cmd_1 on und statt cmd_2 off stehen, on würde dann cmd_1 bedeuten und off cmd_2 ohne etwas zu umzubiegen.
Eine andere Version habe ich im aktuellen Thread zu dem Thema angehängt, dort wird zusätzlich jeder set Befehl akzeptiert, auf den man dann triggern kann, dass dürfte mit den anderen Features nicht kollidieren.
Wird schwer, wenn man
cmdState on|on|off
oder ähnliches hat.
Sieht auf den ersten Blick unnütz auch, aber i.V. mit wait oder repeatcmd durchaus brauchbar.
Zitat von: Per am 16 Februar 2017, 11:37:26
Wird schwer, wenn man
cmdState on|on|off
oder ähnliches hat.
Sieht auf den ersten Blick unnütz auch, aber i.V. mit wait oder repeatcmd durchaus brauchbar.
Zwei gleiche Zustände wären dann nicht sinnvoll nutzbar, weil dann keine eindeutige Zuordnung wäre
Muss man schauen, ob das alles Sinn macht. Es sind nur Ideen, die vielleicht eine Sackgasse darstellen.
Auch wenn das schon ne Weile alt ist, ist mir erst heute folgendes aufgefallen:
Set $SELF arbeitet nicht als "goto", sondern als "call".
Ist das so gewollt? Kann man das beeinflussen oder irgendwie was tun?
define DOIF.Tester DOIF (0) (set $SELF cmd_2) (set $SELF cmd_2) (set $SELF cmd_2)\
(0) (set dummy )
ergibt:
2017-04-17 09:39:30 DOIF DOIF.Tester cmd_nr: 2
2017-04-17 09:39:30 DOIF DOIF.Tester cmd: 2
2017-04-17 09:39:30 DOIF DOIF.Tester cmd_event: set_cmd_2
2017-04-17 09:39:30 DOIF DOIF.Tester cmd_2
2017-04-17 09:39:30 DOIF DOIF.Tester cmd_nr: 1
2017-04-17 09:39:30 DOIF DOIF.Tester cmd_seqnr: 1
2017-04-17 09:39:30 DOIF DOIF.Tester cmd: 1.1
2017-04-17 09:39:30 DOIF DOIF.Tester cmd_event: set_cmd_1
2017-04-17 09:39:30 DOIF DOIF.Tester cmd_1_1
2017-04-17 09:39:30 DOIF DOIF.Tester cmd_nr: 2
2017-04-17 09:39:30 DOIF DOIF.Tester cmd: 2
2017-04-17 09:39:30 DOIF DOIF.Tester cmd_event: set_cmd_2
2017-04-17 09:39:30 DOIF DOIF.Tester cmd_2
2017-04-17 09:39:30 DOIF DOIF.Tester cmd_nr: 1
2017-04-17 09:39:30 DOIF DOIF.Tester cmd_seqnr: 2
2017-04-17 09:39:30 DOIF DOIF.Tester cmd: 1.2
2017-04-17 09:39:30 DOIF DOIF.Tester cmd_event: set_cmd_1
2017-04-17 09:39:30 DOIF DOIF.Tester cmd_1_2
2017-04-17 09:39:30 DOIF DOIF.Tester cmd_nr: 2
2017-04-17 09:39:30 DOIF DOIF.Tester cmd: 2
2017-04-17 09:39:30 DOIF DOIF.Tester cmd_event: set_cmd_2
2017-04-17 09:39:30 DOIF DOIF.Tester cmd_2
2017-04-17 09:39:30 DOIF DOIF.Tester cmd_nr: 1
2017-04-17 09:39:30 DOIF DOIF.Tester cmd_seqnr: 3
2017-04-17 09:39:30 DOIF DOIF.Tester cmd: 1.3
2017-04-17 09:39:30 DOIF DOIF.Tester cmd_event: set_cmd_1
2017-04-17 09:39:30 DOIF DOIF.Tester cmd_1
Das kann man gut nutzen (wenn man weiss, dass es so ist), will man aber nicht immer.
define DOIF.Tester DOIF (0) (set $SELF cmd_2) (set $SELF cmd_2) (set $SELF cmd_2)\
(0) (set dummy )
Fehlt da nicht etwas? Wo ist denn cmd_2?
set $SELF cmd_2 ruft einfach den zweiten Zweig aus, es ist also als "Call" zu sehen und kein "GOTO"
Beispiel:
defmod di_bla DOIF (0) (set $SELF cmd_2) (set $SELF cmd_2) (set $SELF cmd_2) DOELSE (set bla on)
attr di_bla do always
set di_bla cmd_1
führt drei mal set bla on aus, etwas anderes habe ich auch nicht erwartet.
Zitat von: Damian am 17 April 2017, 11:23:21Fehlt da nicht etwas? Wo ist denn cmd_2?
Ist beim Kopieren verloren gegangen :(.
Zitat von: Damian am 17 April 2017, 11:23:21es ist also als "Call" zu sehen und kein "GOTO"
Also "by design".
Zitat von: Damian am 31 Januar 2017, 20:43:08
Mit der neuen Version ist es nun möglich Befehlszweige bzw. Zustände über einen set-Befehl bedingungslos auszulösen.
Übrigens auch hierfür danke. Auch das war ein Wunsch auf meiner Liste :) .
Muss das mal wieder aufheben.
Zitat von: Damian am 17 April 2017, 11:23:21führt drei mal set bla on aus, etwas anderes habe ich auch nicht erwartet.
Wie wird mit wait umgegangen?
[code](0) (set $SELF cmd_2)(set $SELF cmd_2)(set $SELF cmd_2)(set $SELF cmd_2)
DOELSEIF (0) () () ()wait 0:5,5,5[/code]
(Vereinfacht zum evtl. Nachstellen)
Ergibt irgendwie ein merkwürdiges Verhalten...
Zitat von: Per am 30 April 2017, 22:47:59
Muss das mal wieder aufheben.
Wie wird mit wait umgegangen?
[code](0) (set $SELF cmd_2)(set $SELF cmd_2)(set $SELF cmd_2)(set $SELF cmd_2)
DOELSEIF (0) () () ()
wait 0:5,5,5[/code]
(Vereinfacht zum evtl. Nachstellen)
Ergibt irgendwie ein merkwürdiges Verhalten...
Alles wie erwartet, die ersten drei set cmd2 führen den jeweils ersten Befehl ohne Zeitverzögerung aus (die verzögerten kommen nicht zum Zuge). Beim vierten werden auch die restlichen zwei Befehle zeitverzögert ausgeführt.
Zitat von: Damian am 14 Februar 2017, 22:08:13
Ich habe neue Zeitvariablen $md im Format "MM-DD" und $ymd im Format "YYYY-MM-DD" eingebaut:
Damit lassen sich größere Zeitbereiche in der Bedingung eingrenzen:
vom 01.01 bis zum 26.02:
$md ge "01-01" and $md le "02-26"
oder
z. B. es Weihnachtet:
$ymd ge "2017-12-23" and $ymd le "2018-01-05"
Version ist bereits eingecheckt und ab morgen verfügbar.
Man kann so etwas natürlich über die holiday-Datei machen. Allerdings sind dort keine Jahresangaben vorgesehen.
funktionieren die variablen auch im perl-modus ?
Zitat von: kumue am 29 November 2019, 04:38:39
funktionieren die variablen auch im perl-modus ?
ja
das freut mich, aber ich scheitere leider am ersten Versuch..
{if ([22:42] and ($md eq "11-29")); {fhem_set "dummy1 on"}}
FM:
condition c01: syntax error, line 1, at EOF
Damian, kannst Du bitte ein Beispiel aufzeigen. Danke!
Zitat von: kumue am 29 November 2019, 22:45:23
das freut mich, aber ich scheitere leider am ersten Versuch..
{if ([22:42] and ($md eq "11-29")); {fhem_set "dummy1 on"}}
FM:
condition c01: syntax error, line 1, at EOF
Damian, kannst Du bitte ein Beispiel aufzeigen. Danke!
eher:
{if ([22:42] and ($md eq "11-29")) {fhem_set "dummy1 on"}}Der if-Befehl ist ja nicht hinter der Bedingung zu ende, sondern erst hinter dem Ausführungsteil, daher kein Semikolon dazwischen.
perfekt, danke auch für die erklärung !
Hallo,
hab gerade gemerkt, dass man die $md-Variable im DOIF nicht über ein Jahresende einsetzen kann.
Das hier geht nicht: (($md ge "12-01" and $md le "01-15"))
Das hier funktioniert: (($md ge "12-01" and $md le "12-31") or ($md ge "01-01" and $md le "01-15"))
Vielleicht hilft diese Info nochmal jemandem.
Viele Grüße
Zitat von: Rudibarani am 09 Januar 2020, 21:26:31
Das hier geht nicht: (($md ge "12-01" and $md le "01-15"))
Aber das:
(($md ge "12-01" or $md le "01-15"))Und schon passt es ;)
Lieber Per,
vielen Dank - auch eine gute Lösung! Ich wollte vor allem dafür sensibilisieren, dass die Variable derzeit nicht über die Jahresgrenze hinweg in größer / kleiner-Beziehungen gesetzt werden kann.
Viele Grüße