Länger andauerndes notfiy Skript manuell beenden

Begonnen von helgekraak, 26 Dezember 2013, 15:42:28

Vorheriges Thema - Nächstes Thema

helgekraak

Hallo,

ich möchte eine per notify ausgelöste Befehlsfolge bei Bedarf abbrechen können, in dem beispielsweise ein weiteres notfiy-Skript einen entsprechenden Befehl an das bereits laufende notify-Skript sendet (falls so ein Befehl existiert). Das von mir konzipierte WakeUp Programm dauert insgesamt etwa zwei Stunden. Eine ausführliche Foren- und Dokumentationsrecherche hat mich nicht weitergebracht.

Als einziger Workaround innerhalb von FHEM ist mir bisher eingefallen, jeden einzelnen Befehl in meiner Befehlsabfolge in eine individuelle if-Bedingung zu packen, die jedes mal den on/off-Zustand eines separat eingerichteten dummy Schalters prüft. Das wäre aber keine schöne Lösung, zum einen aus Gründen der Skriptübersichtlichkeit und zum anderen, weil das Skript dann trotzdem bis zum Schluss weiterlaufen würde.

So etwas wie eine while Schleife scheint nicht zu existieren. Ein weiterer Workaround wäre, das Skript in ein Shell-Skript auszulagern. Hier könnte ich das Skript mit Unix-Befehlen beenden.

Am besten würde mir aber natürlich eine Lösung innerhalb von FHEM gefallen. Grundsätzliche Gründe, die dagegen sprechen könnten, ein Skript innerhalb von FHEM so lange dauern zu lassen (z.B. Performance-Aspekte), sehe ich nach meinem aktuellen Kenntnisstand nicht (lasse mich aber natürlich sehr gerne eines besseren belehren).

Daher meine Frage: Können aktive/aktuell ausgeführte Skripte in FHEM manuell beendet werden?

Besten Dank vorab!

Zrrronggg!

ZitatDaher meine Frage: Können aktive/aktuell ausgeführte Skripte in FHEM manuell beendet werden?

Nicht das ich wüsste. Man kann sie aber löschen. Alle zu dem Zeitpunkt noch nicht ausgeführten Befehle werden dann nicht mehr ausgeführt.

Ob das in deinem Fall hilft hängt davon ab, wie das Script im Einzelnen aussieht, also insbesondere, wie du die nötigen Verzögerungen gebaut hast.

Ich mache sowas oft so, dass ein Script selber andere Scripte definiert, die dann zu bestimmten späteren Uhrzeiten oder Verzögerungen aktiv werden. Und diese lasse ich dann löschen, wenn sie doch nicht in Aktion treten sollen.
FHEM auf Linkstation Mini, CUL 868 SlowRF, 2xCUL 868 RFR, CUL 433 für IT, 2xHMLAN-Configurator mit VCCU, ITV-100 Repeater, Sender und Aktoren von FHT, FS20, S300, HM, IT, RSL

helgekraak

Vielen Dank für Deine Idee! Ich habe sie nach meinem Verständnis Deiner Beschreibung wie folgt nachvollzogen:

1. Das notify Skript ausgelöst

2. Das notify Skript per delete Befehl gelöscht während es noch aktiv war

Ergebnis: Die Befehle wurden trotzdem bis zum Ende ausgeführt.

Die DEF-Sektion mit meinem Testskript und den darin verwendeten Zeitverzögerungsbefehlen (ich verwende sleep) sieht so aus :

AUFWACHENTERTAINMENT {

if ("%EVENT" eq "on") {

fhem("set Weisse_LED_Bett on;

sleep 10;

set Musik_Bett on;

sleep 10;

set Weisse_LED_Bett off;

sleep 5;

set Musik_Bett off;

")}
   
}

fiedel

Das meint er anders: Du definierst als Ausgabe aus dem ersten Notify heraus ein oder mehrere "at", welche z.B. eine relative Zeit enthalten (schalte von jetzt an in 10 min). Zusätzlich läuft ein zweites Notify, welches überwacht, ob die Aktion die das "at" ausführen soll, schon anderweitig getriggert wurde. Ist das der Fall, löscht das zweite Notify das "at" vor Ablauf der 10 min und damit vor dessen aktiv werden.
FeatureLevel: 6.1 auf Wyse N03D ; Deb. 11 ; Perl: v5.14.2 ; IO: HM-MOD-RPI-PCB + VCCU|CUL 868 V 1.66|LinkUSBi |TEK603
HM: SEC-SCO|SCI-3-FM|LC-SW4-PCB|ES-PMSW1-PL|RC-4-2|SEN-MDIR-O|SEC-WDS-2
CUL: HMS100TF|FS20 S4A-2 ; OWDevice: DS18S20|DS2401|DS2406|DS2423

Zrrronggg!

Ja, wenn das Notify eingelesen wurde wird es ausgeführt. Da habe ich mich ungenau ausgedrückt, stimmt.

Ich meinte es so wie fiedel es beschrieb.

FHEM auf Linkstation Mini, CUL 868 SlowRF, 2xCUL 868 RFR, CUL 433 für IT, 2xHMLAN-Configurator mit VCCU, ITV-100 Repeater, Sender und Aktoren von FHT, FS20, S300, HM, IT, RSL

helgekraak

#5
Abermals vielen Dank für die Rückmeldungen. Nachdem ich nun gegen alle Wände gerannt bin, bin ich nun auch zu der Erkenntnis gekommen, dass der Weg über temporäre Notify-Skripte der einzig sinnvolle und gangbare ist, ohne FHEM für längere Zeit zu blockieren. Wohl gibt es auch noch eine potenzielle Möglichkeit mit dem Modul http://www.fhemwiki.de/wiki/Blocking_Call , das ist aber viel zu kompliziert und die Variante mit den temporären Notify-Skripten ist auch gar nicht so schlimm und unübersichtlich wie ich zunächst dachte. Hier die Rahmenstruktur, die ich für mein Programm jetzt verwenden werde:

define AUFWACHENTERTAINMENT dummy
attr AUFWACHENTERTAINMENT group Schaltungen
attr AUFWACHENTERTAINMENT room AUFWACHEN
attr AUFWACHENTERTAINMENT setList on off

define AUFWACHENTERTAINMENT_STARTEN notify AUFWACHENTERTAINMENT:on {\
fhem "define MAKRO_TEMP_1 at +00:00:30 set Lichtleiste_Weiss_Bett on" if (Value("AUFWACHENTERTAINMENT") eq "on");;\
fhem "define MAKRO_TEMP_2 at +00:00:40 set Lichtleiste_Weiss_Bett off" if (Value("AUFWACHENTERTAINMENT") eq "on");;\
fhem "define MAKRO_TEMP_4 at +00:01:00 set AUFWACHENENTERTAINMENT off" if (Value("AUFWACHENTERTAINMENT") eq "on");;\
usw.....
}
attr AUFWACHENTERTAINMENT_STARTEN group Schaltungen
attr AUFWACHENTERTAINMENT_STARTEN room MAKROS

define AUFWACHENTERTAINMENT_STOPPEN notify AUFWACHENTERTAINMENT:off {\
fhem "delete MAKRO_TEMP_.*";;\
}
attr AUFWACHENTERTAINMENT_STOPPEN group Schaltungen
attr AUFWACHENTERTAINMENT_STOPPEN room MAKROS

fiedel

#6
Perfekt! ;D

Edit: Kleiner Tipp noch dazu:

Wenn die Makros gerade laufen, stehen sie "mit einem Bein" in der CFG. Wenn man zu dieser Zeit ein "save" durchführt, werden sie fest gespeichert und bei jedem Neustart oder rereadcfg ausgeführt. Das muss man einfach wissen, sonst erschreckt man sich.  ;D

Gruß

Frank
FeatureLevel: 6.1 auf Wyse N03D ; Deb. 11 ; Perl: v5.14.2 ; IO: HM-MOD-RPI-PCB + VCCU|CUL 868 V 1.66|LinkUSBi |TEK603
HM: SEC-SCO|SCI-3-FM|LC-SW4-PCB|ES-PMSW1-PL|RC-4-2|SEN-MDIR-O|SEC-WDS-2
CUL: HMS100TF|FS20 S4A-2 ; OWDevice: DS18S20|DS2401|DS2406|DS2423

helgekraak

Dieser Falle war ich mir zum Glück bewusst, Frank. :-) Aber manch anderer könnte vielleicht darüber stolpern. Daher auf jeden Fall Danke für diese Ergänzung.

Gruß
Helge