Ich wollte nur mal kurz vermelden: Bin eh noch da und lese brav mit. Kann nur nichts beitragen.
Aber habe gerade, wie immer knapp vor einem Urlaub, aus Langeweile wieder ein bisschen mit Rhasspy geredet. Und bin immer noch begeistert ob unser aller Arbeit 
Dann mal schönen Urlaub!
Im Anhang dann noch eine kleine Aktualisierung (s.u.), die aber weiter das "d=..." aus dem Shortcuts-Attribut (zur Doku passend) in "NAME" übernimmt. (Wir hatten irgendwann eine Diskussion darüber, ob das Kürzel "d" oder "n" sein sollte, weiß aber nicht mehr, wie wir das letztendlich entschieden hatten. Ich finde weiter n=>NAME verständlicher, aber da das auch in der Doku so stand, bleibt das erst mal so...).
Vielleicht schubst du das ins svn? MAn. ist v.a. das mit der verbesserten Doku "cool", ansonsten bin ich auch sehr froh, dass es im großen und ganzen keine größeren offenen Punkt gibt...
(OK, das mit dem komplexeren Dialog, aber da hat JensS jetzt ja auch mit dem myUtils-Buchstabieren ein sehr tolles Beispiel gebaut, mit dem man weiterarbeiten kann!)
Was das mit dem ausbleibenden DoTrigger-Anweisungen nach Dispatch angeht, habe ich mal noch eine Log-4-Meldung eingebaut, in der steht, welche Devices zurückgegeben werden.
...macht Sinn - funktioniert leider auch nicht.
Wird denn im RHASSPY-Hash zu dem Shortcut "NAME" gefüllt?
Habe den Code kurz überflogen, und mAn. müßte das eigentlich im Rückgabe-Array landen, was da steht, es sei denn
- (bisher) es wird Perl ausgeführt, und dieser Code gibt etwas zurück. Das stand etwas anders in der Doku, ich hoffe, den Code jetzt auch an der Stelle entsprechend angepasst zu haben;
- die Devices existieren nicht.
Kurze Zwischenfrage zu u.a. #2824 und #2834:
Wäre my $cmd = $shortcut->{perl} if exists $shortcut->{perl}; richtigerer? 
Doppelt nein:
- my $foo = "baa" if $baz; ist grundsätzlich eine "unzulässige" Anweisung. (Wenn, dann müßte man $foo vorher einführen);
- wenn der Hash nicht defined ist, bleibt $cmd undefined, und genau das wird später gecheckt.
Falls du strukturelle Zweifel hast (dahingehend, dass immer der erste (oder 2.) Zweig angefahren wird): Verbose 5 sollte Aufschluss geben
.
Da das Verhalten nur bei dummys auftritt und bei anderen Typen (z.B. FRM_out) nicht, könnte es auch eine Besonderheit im Eventhandling von 98_dummy.pm sein.
Vermute eher, dass FRM_out ein (eigentlich) 2. Event wirft, wenn der Befehl von der Hardware ausgeführt wurde. So sollte es für eigentlich alle bidirektionalen Systeme sein.
Wir sollten als erstes checken, was an fhem.pl-Dispatch() zurückgegeben wird, beginnend mit der sauberen Übernahme in den RHASSPY-Hash als "NAME". Dann sehen wir weiter.
