Hallo zusammen, viele Stunden nun versuche ich schon, einem vermeintlichen Fehler bei CMDAlias auf die Spur zu kommen.
Und zwar äußert es sich so, dass bei zwei direkt hintereinander ausgeführten - sicher auch etwas Zeit fressenden - CMD Alias Aufrufen der zweite nicht ausgeführt wird.
Für mich sieht es so aus, als wäre der erste CMD Alias noch nicht abgearbeitet und blockiert bzw. verwirft den zweiten CMD Alias Aufruf.
Meinen Code möchte ich zu Beginn nicht unbedingt gleich posten, da umfangreich und erklärungsbedürftig. Daher erstmal die grundsätzliche Frage:
Kann das oben beschriebene überhaupt möglich sein?
Gruß
Ronny
Zitatblockiert bzw. verwirft den zweiten CMD Alias Aufruf.
cmdalias ersetzt eine Zeichenkette durch eine Andere, und fuehrt die "Andere" dann aus. Die Ersetzung bleibt in einer Rekursion aus, d.h. man kann in der Ausfuehrung einer cmdalias nicht das gleiche cmdalias ausfuehren. Folgendes erzeugt also keine Endlosschleife:
Zitatdefine cmd1 cmdalias AS trigger dummy1
define ntfy1 notify dummy1 cmd1
cmd1
Möglicherweise habe ich den Threadtitel nicht sauber gewählt, jedenfalls rufe ich den CMDAlias nicht rekursiv auf.
Ich habe zwei Notifies, die nacheinander feuern und jeweils den gleichen CMDAlias mit anderen Parametern ($EVENT und $EVTPARTx werte ich dazu aus) aufrufen.
Dann sollte cmdalias nicht schuld sein.
Man kann es doch testen, indem man statt cmdalias das eigentliche Kommando hinschreibt.
Das eigentliche Kommando funktioniert, das hatte ich gleich getestet. Kannst Du anhand meines CMDAliases etwas erkennen (entstanden aus meinem Thread Sender/Absender in Notify (https://forum.fhem.de/index.php/topic,56104.msg491318.html#msg491318))
setex .* AS {
my @EVENTS = split(/\s+/, $EVENT, 3);
if (@EVENTS > 2) {
fhem("setreading $EVTPART0:FILTER=STATE!=$EVTPART1 trigger " . $EVENTS[2]);
}
fhem("set $EVTPART0:FILTER=STATE!=$EVTPART1 $EVTPART1");
}
Aufruf in Notifies außerhalb CMDAlias, wobei das 2. Notify vom 1. getriggert wird:
setex Alg.Trigger on Sensor01
setex Alg on Alg.Trigger
Könnte es sein, dass cmdalias "denkt", es wäre trotzdem rekursiv?
Mit "gleichen cmdalias" meinte ich nur die Definition, danach waeren deine beiden Befehle
Zitatsetex Alg.Trigger on Sensor01
setex Alg on Alg.Trigger
gleich. D.h. wenn der erste setex ein notify triggert, was wiederum den zweiten setex ausfuehrt, dann wird die Ausfuehrung der zweiten verhindert. Ich habe jetzt cmdalias.pm modifiziert, damit in diesem Fall eine Meldung ausgegeben wird.
Hallo Rudi,
deine Antwort hier hatte ich leider übersehen, aber anhand Deiner Änderung gleich im Log erkannt, dass etwas anders ist.
Vermutlich verstehe ich die Hintergründe nicht, denn ich frage mich immer noch, warum das cmdalias prüft, von wo es außerhalb aufgerufen wird. Ich würde ja verstehen, wenn ich innerhalb des cmdalias nicht das cmdalias aufrufen darf. Aber außerhalb müsste es doch mMn egal sein?
Stimmt. Du rufst es ja auch innerhalb auf, ueber trigger und notify.
Für meinen Anwendungsfall (der auch inzwischen ins Wiki gefunden hat), wäre es ein unerwünschtes Feature, wenn cmdalias sämtliche getriggerte Kaskaden von Notifies überwacht.
Wäre es möglich, dieses Feature mittels Attribut zu disablen? Möglicherweise auf einen Check innerhalb der Definition zu beschränken?
Sehr ungern, weil sowas leicht in einer Endlosschleife endet.
Ich empfehle zwei cmdalias Definitionen. Oder das Problem mit "normalen" Perl Funktionen loesen, da kann man Rekursion nach belieben verwenden.
Ich mache gar keine Rekursion. CMDAlias denkt das nur fälschlicherweise. Kannst Du Dir bitte einmal das Beispiel setex (http://www.fhemwiki.de/wiki/Cmdalias#setex) anschauen? Dann weißt Du, denke ich, was ich meine und warum ich es gerne so nutzen würde.
ZitatIch mache gar keine Rekursion.
Klar doch, hast selbst gesagt:
ZitatAufruf in Notifies außerhalb CMDAlias, wobei das 2. Notify vom 1. getriggert wird:
Rekursion ist, wenn eine Funktion sich selbst aufruft. Ist in deinem Fall zunaechst nicht endlos, es sei denn, irgendwer kommt auf die Idee, dein Code "anzupassen", weil er es nicht ganz verstanden hat. setex habe ich angeschaut, ist nett, wenn man sowas oefters braucht. Und state beim Geraet mitspielt. Hat mich aber nicht von meiner Meinung abgebracht.
Da muss man dann aber gut aufpassen, für was man cmdalias verwendet. (Bspw. ein Alias auf Shutdown+Restart funktioniert also nur, weil zufällig disposed wird?)
Ach schade, das hätte cmdalias vielseitiger werden lassen. Aber Du entscheidest. ;)
Gruß
Ronny
es könnte sein das sich das problem der fehlenden rekursion mit einem sleep 0.1 oder weniger umgehen lässt. d.h. vor den set aufruf ins gleiche fhem(...) noch ein sleep 0.1; mit einbauen.
@FHEMAN: Deine Frage mit dem Shutdown+Restart Alias verstehe ich nicht.
@justme1968: ja, ein sleep 0.1 wuerde die Rekursion unterbrechen. Damit kann man zwar immer noch Endlosschleifen bauen, aber FHEM bleibt bedienbar.
Irgendwie nicht gerade schön, diese Form des Ausbruchs aus dem Aliasgefängnis (ich versuche sleep sonst zu vermeiden). Aber wenn es die einzige Lösung darstellt, verwende ich es gerne. Danke für den Tip, justme1968!
Werde jetzt als erstes mal ne fiese Endlosschleife bauen gehen.. ;)
@rudolfkoenig: ich meinte damit, dass restlos alles im Kontext des Alias liefe und überwacht werden würde, wenn man einen Alias baut, der "ganz vorne" ansetzt.
sleep ist ganicht böse :). damit kann man tolle dinge machen...