CustomIntent mit Dialog

[Beta-User]

Muss ich drüber nachdenken, im Moment hängt da für mich was schief und wir reden in Teilen aneinander vorbei.

[Beta-User]

das Bilden des/der Array-Strings könnte man auch in eine eigene (separate) Funktion auslagern (ist aber gefahrgeneigt).

Bin jetzt mal über den Code und die Doku bei Rhasspy. Dabei ist mir der Unterschied zwischen dem session-intentFilter (JSON-Array mit flachem Text) und dem globalen "configure" (JSON-Array mit Objekten, die an- oder ausgeschaltet sind) wieder deutlich geworden.

Für das globale "configure" gibt es Code, für die "einfache" Liste hier mal ein (ungetesteter) Vorschlag, der mit allem denkbaren input klarkommen sollte:

Code Auswählen Erweitern

sub _get_sessionIntentFilter {
    my $hash         = shift // return;
    my $intents        = shift;
    my $enableCancel = shift;
   
    my @allIntents = split m{,}xm, ReadingsVal( $hash->{NAME}, 'intents', '' );
    my @sessionIntents;
    for (@allIntents) {
        next if $_ =~ m{ConfirmAction|CancelAction|Choice|ChoiceRoom|ChoiceDevice};
        push @sessionIntents, $_ if
            !defined $hash->{helper}->{tweaks} ||
            !defined $hash->{helper}{tweaks}->{intentFilter} ||
            !defined $hash->{helper}{tweaks}->{intentFilter}->{$_} ||
            defined $hash->{helper}{tweaks}->{intentFilter}->{$_} && $hash->{helper}{tweaks}->{intentFilter}->{$_} eq 'true';
    }

    my $id = qq($hash->{LANGUAGE}.$hash->{fhemId}:);
    push @sessionIntents, "${id}CancelAction" if $enableCancel;
   
    my @addIntents;
    if ( ref $intents eq 'ARRAY' ) {
        @addIntents = @{$intents};
    } else {
        @addIntents = split m{,}xm, $intents;
    }
    for (@addIntents) {
        if ( $_ =~ m{\a${id}} ) {
            push @sessionIntents, $_;
        } else {
            push @sessionIntents, "${id}$_";
        }
    }
    return \@sessionIntents;
}Nachzusehen, ob er funktioniert und wo/wie er angesteuert werden sollte, reicht es heute nicht mehr. Eine Anmerkungen zum Verständnis des ganzen noch:

1.

Das ist sicher so gemacht, weil das de.fhem: ja bei jedem anders sein könnte.

Das kann sogar in einer Installation für mehrere Instanzen unterschiedlich sein, etwa wenn man einen deutschen und einen spanischen Rhasspy parallel betreibt. Da sollte eigentlich der myUtils-Code so auslegbar sein, dass der User, der es konfiguriert nicht groß drüber nachdenken muss, wie da die Details in seiner Installation eigentlich sind... Er gibt einfach die Intents ohne die Präfixe zurück und gut ist .

2. Bin mir nicht sicher, ob es clever ist, die defaults wiederherzustellen. Für die reopenVoiceInput-Option paßt es so, ansonsten könnte man noch eine Option vorsehen, eine Liste mit zu deaktivierenden (Standard-) Intents vorzugeben?

[gregorv]

das Bilden des/der Array-Strings könnte man auch in eine eigene (separate) Funktion auslagern

ich hatte schon versucht, das über einen Einzeiler mit regex zu machen - bisher aber nicht erfolgreich 

Bin mir nicht sicher, ob es clever ist, die defaults wiederherzustellen. Für die reopenVoiceInput-Option paßt es so..

Wenn eine neue session aufgemacht wird, werden derzeit (egal ob über reopenVoiceInput oder über resetInput alle Intents scharf gemacht, außer solchen, die eine eine offene session erwarten (Cancel,Choice...).

Bei resetInput sieht man das sogar explizit im Log, da werden alle de.fhem: Intents aufgelistet und mit enable=true oder false gekennzeichnet.

Code Auswählen Erweitern

... {"intentId": "de.fhem:CancelAction","enable": false} ..Warum das bei reopenVoiceInput nicht so im Log erscheint, habe ich nicht untersucht - das Verhalten bezüglich gültiger Intents ist jedenfall genau so.

Für reopenVoiceInput und resetInput wäre es aber praktisch, den Intent de.fhem:CancelAction auch aktiviert zu haben.
Szenario: Hotword -> Kommando 1 -> Kommando2 ... -> fertig ('oh nein' passt wenig). Aber die Worte 'sei still' oder 'fertig' ... kann man ja noch im Intent einfügen und die response 'habe abgebrochen' so formulieren, dass es auf beide Szenarien passt.

Nachtreg: hab die neue sub mal angeschaut da ist ja schon drin, dass man den CancelAction aktivieren kann.

Ich habe das derzeit über einen eigenen Intent CancelSession umgesetzt.

[gregorv]

hier mal ein (ungetesteter) Vorschlag

Habe ich mir mal genauer angesehen.
Die Möglichkeit, den Intent CancelAction zu aktivieren, wäre hier global einstellbar. Ggf. wäre es zu überlegen, ob man CancelAction nur in den Fällen aktiviert, in denen der key reopenVoiceInput oder resetInput gesetzt ist.

Ich habe in der Doku zu RhasspyTweaks unter intentFilter folgenden Hinweis gesehen:

Code Auswählen Erweitern

(Note: activating the 4 mentionned intents is not possible!). For details on how configure works see Rhasspy documentation.Das könnte darauf hindeuten, dass es ggf. mal Probleme mit CancelAction gab, wenn der Intent nach der Wake Word-Erkennung ausgeführt wurde.

Hinweis: die initialize_rhasspyTweaks müsste auch noch angepasst werden damit der neue key enableCancel nicht verschluckt wird.

[Beta-User]

Die Möglichkeit, den Intent CancelAction zu aktivieren, wäre hier global einstellbar. Ggf. wäre es zu überlegen, ob man CancelAction nur in den Fällen aktiviert, in denen der key reopenVoiceInput oder resetInput gesetzt ist.

"global" ist m.E. etwas zu weitgehend, man kann es eben (über diesen Code) aus jeder beliebigen Antwort heraus aktivieren (zumindest, wenn er funktioniert wie gedacht).

ggf. mal Probleme mit CancelAction gab, wenn der Intent nach der Wake Word-Erkennung ausgeführt wurde

Weiß auch nicht mehr genau, was die Ursache war, das in der Form so "hart" zu deaktivieren. Jedenfalls dann, wenn schon irgendeine Art von "Unterhaltung" stattgefunden hatte, ist es nicht mehr so schlimm, wenn der Dialog erkennbar geschlossen wird, und über einen weiteren "key" könnte man auch das Antwortverhalten in CancelAction ja nochmal anpassen (und z.B. silent schließen oder auf "halt die Klappe" mit "gerne" reagieren...). (Diese Art der Unterscheidung nach "Sub-Keys" ist im übrigen Code übrigens erst nach der grundlegenden "Bitte bestätigen"-Funktionalität dazu gekommen, für die man CancelAction braucht; über den Teil hat also imo noch keiner intensiver nachgedacht...).

Jedenfalls Danke, dass du mit mir erst mal gedanklich "von hinten nach vorne" gehst, ich komme leider grade (und vorassichtlich auch nicht vor Mitte nächster/Anfang übernächster Woche) dazu, das code-mäßig deutlich weiter zu treiben oder auszutesten. Also falls du konkrete Vorschläge hast, schaue ich mir das gerne an.

ob man CancelAction nur in den Fällen aktiviert, in denen der key reopenVoiceInput oder resetInput gesetzt ist.

Ich habe jedenfalls den Eindruck, dass wir gedanklich jetzt einigermaßen beieinander sind, wie das (funktional) im Großen und Ganzen aussehen sollte .

[gregorv]

@Beta-User

ich habe mir heute mal die handleSetNumeric() angeschaut.
Hintergrund: ich will mit meiner Blinds() ja nicht das Rad neu erfinden, sondern das nutzen, was da ist. Momentan schrumpft sie zu einem Mantel für den Aufruf bereits vorhandener Modul Funktionen und stellt nur zusätzliche Funktionalität und hoch flexible situationsangepasste responses zur verfügung

Frage:
Wenn ich die handleSetNumeric() nutze, kann die (für Rollläden)  ja Befehle wie Stop und anfahren bestimmter Positionen behandeln, was ich vermisse, ist, dass beim Anfahren von relativen Positionen 'höher und tiefer' geht, aber das i-Tüpfelchen wäre noch so ein Kommando wie setMore, womit man abhängig von der vorherigen Bewegungsrichtung ein Stück weiter fahren kann - z.B. mit Sprachkommando 'weiter'. In meiner Blinds() ist das drin und recht bequem. Für Lautstärke Einstellungen sicher auch nicht uninteressant.

Soll ich mal schauen, wie das in der handleSetNumeric() umgesetzt werden könnte.

Noch eine grundsätzliche Frage:
Da ich mit meiner Blinds() auch die Rollläden auf und zu machen kann, müsste ich - Stand jetzt, die handleSetOnOff() aufrufen, wobei ich vorher natürlich prüfen muss, ob das Kommando 'on/off' oder 'stop/pos x' ist.

Einfacher wäre es natürlich, wenn cmdOn und cmdOff von der handleSetNumeric() behandelt werden könnten. Über die rhasspyMappings bekommt man die schon jetzt in den SetNumeric Bereich im hash rein (devicemap->devices->device->Intents).
Wäre sicher kein besonders riskanter Eingriff - Das Problem sehe ich eher in dem Punkt, dass handleSetOnOff damit wohl überflüssig wird (aber natürlich bleiben kann). Als möglicher Change Wert wäre cmdOn und cmdOff denkbar

Was denkst Du ?

[Beta-User]

Schnellantwort:
ad "weiter" - setzt für Rollläden etc. halt voraus, dass man sich irgendwo die Richtung merkt. Wenn es dafür eine allgemein sinnvolle Lösung gibt: Warum nicht?

ad "cmdOn" in setNumeric:
Hatte ja schon geschrieben, dass ich zwischenzeitlich eher dazu tendiere, weniger Intents besser zu finden statt mehr... Von daher finde ich es zumindest auf den ersten Blick ok, aus "numeric" "ausbrechen" zu können bzw. das ggf. als "multi"-Kommand zu behandeln (je nachdem). Kannst ja mal schauen (auch im changelog), ob das nicht über die Multi-Geschichte ggf. sogar relativ einfach umzusetzen wäre.

Auch eine "Umleitung" nach (Gruppen-) onOff finde ich ok, wenn nur der eine Key drin ist. Man müßte halt ggf. $data "umverpacken"?

So viel (ohne Blick in den Code) auf die Schnelle dazu .

[gregorv]

Code Auswählen Erweitern

...dass man sich irgendwo die Richtung merkt...Bisher habe ich die alte Position (vor der Rolladenfahrt) in CustomData untergebracht. Beim nächsten Durchlauf vergleicht er die mit currentVal und weiß in welcher Richtung er unterwegs war. Das könnte über den bereits bekannten Key Value in $old_data gehen.

(Ich denke, Du weißt, was ich mit $old_data meine - schreibt sich schneller als hash->{helper}->{.delayed}->{$sessionId}

ob das nicht über die Multi-Geschichte ggf. sogar relativ einfach umzusetzen wäre

Schau ich mir auch mal an - gut, dass ich gerne lerne...

Man müßte halt ggf. $data "umverpacken"

Zumindest muss man sehen, dass nichts verloren geht, habe ich auch schon festgestellt. Da ein Kommando wie 'ein wenig runter' keine Device, Group und Room Keys mehr hat, muss man die aus $old_data wieder in $data kopieren. Klar könnte man die erneut sprechen, fände ich aber keine natürliche Kommunikation und hab die deshalb optional im sentence.

Gruß Gregor

[Beta-User]

Bisher habe ich die alte Position (vor der Rolladenfahrt) in CustomData untergebracht. Beim nächsten Durchlauf vergleicht er die mit currentVal und weiß in welcher Richtung er unterwegs war. Das könnte über den bereits bekannten Key Value in $old_data gehen.

Hmmm, prinzipiell gefällt mir der Gedanke gut, das via customData zu lösen.

Problem ist: Wenn man eigentlich fertig war und dann $old_data hat, könnte es weird werden, wenn die aktuelle Anweisung - die ja ganz anders sein kann - vorrangig (?) aus diesem Datensatz abgeleitet werden würde. Außerdem muss man das irgendwann löschen. Der Umweg über customData ist da m.E. eine gute Option. Da JSON-encoded alles rein, was zur letzten Sitzung gehört hatte und "gut ist", dann kann man es nutzen, wenn es paßt, und es ist weg, wenn man sonst klar kommt. (könnte nur ein (lösbares) Problem beim parsen der Message geben, weil zu weit ausgepackt wird (?)).

Mit "weiter" habe ich dann noch weitere "Hänger":
- es ist (gefühlt: zu?) kurz
- Das mit dem Positionsvergleich ist mehrfach gefahrgeneigt: Wo ist oben und unten? (ROLLO vs. CUL_HM-Style). Wann wird die Position wirklich aktualisiert? CUL_HM macht es fortlaufend, ZWave erst dann, wenn der Rollladen wieder steht, bei MQTT2_DEVICE ist es von der Konfiguration des Users und der konkreten Hardware abhängig...
Jedenfalls für das im Modul vercodete Verhalten würde ich dazu neigen, vom Sprechenden wenigstens zu verlangen, dass er eine Richtungsangabe macht ("weiter runter"); das ist dann (hoffentlich) auch "lang genug".

Puh, und dann fürchte ich, dass sich noch ein paar weitere Folgefragen stellen werden, aber m.E. müßten wir das erst mal so weit vercoden.

Würde allerdings dann gerne erst mal die bisher aufgerissenen Baustellen zu machen, bevor wir da mehr content in die Funktionalität rein bringen. Anders gesagt: Das "reopen" mit den "normalen" sentences muss erst mal reibungslos klappen, oder?

[gregorv]

es ist (gefühlt: zu?) kurz

Im Prinzip richtig, aber deshalb habe ich den IntentFilter gesetzt. In dem anschließend verlängerten Dialog kommen nur noch Kommandos vom CustomIntent und Cancel durch (und natürlich das resetInput - ist ja unabhängig von IntentFiltern) - das klärt auch den Punkt:

Problem ist: Wenn man eigentlich fertig war und dann $old_data...

Das erzwingt nämlich vor einem anderen Intent noch mal das Hotword - wodurch eine neue session gestartet wird, wo es noch kein $old_data gibt - abgesehen davon, dass in der alten session $old_data ohnehin gelöscht wird.

Wann wird die Position wirklich aktualisiert?

Für so was ist gut, dass Du darüberschaust. Bisher habe ich das so gebaut, dass mindestens drive-up-time-to-open gesetzt sein muss, damit man solche Kommandos starten kann. Wenn die drive-xxx Attribute passend gesetzt werden, macht FHEM (nach meinem Verständnis) das Update der Position (fast) live. Die Dooya liefern auch nur am Ende ein closed/opened. HM kommt aber ohne die drive-xxx Attribute aus, sollte aber trotzdem relative position Kommandos können. FS20 kann nicht mal Stop ... - es gibt auch Rollladensteuerungen, wo oben 100 ist und nicht 0 und möglicherweise kein inverse Attribut...
Immerhin ist es egal, wenn die aktuelle Position erst am Ende kommt, ein weiter wird man kaum veranlassen, wenn der Rollladen noch fährt - falls doch, wird es ignoriert.

Trotzdem zu viele ? für eine sichere Implementation. Da müssten wir noch weitere Infos bekommen - eine Zusammenstellung von Features aller FHEM Rollladensteuerungen gibt es wohl nicht. Gar nicht zu reden von Lautstärke-Einstellungen o.a.

[Beta-User]

es gibt auch Rollladensteuerungen,

Es gibt zu AutoShuttersControl einen Thread mit "spezieller Hardware", da kann man in etwa erkennen, wie bunt die Welt sein kann...

Ad "CancelActeion" und "Nicht-Aktivierbarkeit" ist mir noch eingefallen dass der wahre Grund für diese Besonderheit ein anderer ist: Daran erkennt RHASSPY, dass der (default) Intentfilter verloren gegangen ist und erneuert werden muss, z.B. nach einem restart von Rhasspy. Kann man vielleicht auch anders lösen, für den Moment werde ich mal bei Gelegenheit schauen, ob man das nicht macht, wenn spezielle Keys enthalten sind.

Ansonsten noch zu $old_data: Das ist sinnvoll, wenn man irgendeine Art von echter Interaktion hat, aber sobald man eigentlich "alles mögliche" sagen könnte, sind die Altdaten imo tendenziell eher verwirrend.

Das erzwingt nämlich vor einem anderen Intent noch mal das Hotword

Die Idee hinter einer "continous session" ist eben, nach einem Hotword dann noch eine ganze Zeit weitere Anweisungen absetzen zu können, und zwar eben im Prinzip "Intent-offen". Das erfordert aber eine etwas andere Struktur wie sie jetzt besteht.

Komme aber wie gesagt im Moment nicht dazu, da was weiter dran zu drehen...

[gregorv]

Die Idee hinter einer "continous session" ist eben ...

Das müssen wir prüfen. Aber ich habe mir noch nicht genau angeschaut, wie Du reopenVoiceInput realisiert hast. Derzeit ist es da jedenfalls so, dass nach jedem Kommando eine neue Session (mit anderer sessionId) aufgemacht wird. Damit gibt es da jedenfalls keinerlei Konfliktpotential mit old_data.
Aber was die sessionIds in diesem Szenario angeht bin ich im Log über unerwartete Events gestolpert, hatte nur noch nicht die Zeit, das zu analysieren. Da war im Log zu sehen, dass nach einem Kommando eine neue Session aufgemacht wird. Anschließend wurde laut Log die neue sessionId mit Msg: hermes/dialogueManager/sessionEnded beendet (erwartet hatte ich das für die alte).
In der Folge wurde aber mit der, laut Log beendeten. SessionId alles weitere gemacht und die alte sessionId taucht nicht mehr auf. Es scheint so, als wäre die richtige Session beendet und nur der zugehörige Logeintrag mit der falschen sessionId versehen. Beim Verhalten gab es auch bei bisherigen Tests nichts Auffälliges.

Da kommt mir aber gerade ein Gedanke.
Wenn man reopenVoiceInput mit continous session realisieren wollte, müsste man das so machen, wie für den CustomIntent - das ist es ja eine continous session, möglicherweise sogar der bessere Ansatz. Da müsste man natürlich auf die $old_data aufpassen, was aber relativ einfach gelöst werden kann. Ist das Kommando ein neuer Intent, ist $data->{Intent} != old_data->{Intent}, was man nutzen kann um $old_data komplett zu löschen. Das bedeutet allerdings, dass beim mehreren CustomIntents man auch nicht mehr auf die Daten eines anderen CustomIntent zugreifen kann (ist ohnehin konsistenter).

Dieser Ansatz bedeutet aber mehr Arbeit weil der meiste Code für eine continous session beim CustomIntent ja in handleSetDialogTimeout drin ist und dann doch besser in response() aufgehoben wäre. Da wird ja nur aufgrund der Tatsache, dass $reatction bzw. $response ein hash ist das topic continueSession gesetzt.


Ansonsten entdecke ich immer noch neues in der handleIntentSetNumeric() und man da kann auch viel lernen, wie rhasspyMapping funktioniert. Dazu kommt aber morgen mehr - gibt da ganz interessante Möglichkeiten.

[Beta-User]

Die Idee hinter einer "continous session" ist eben ...

wie Du reopenVoiceInput realisiert hast.

Na ja, das ist im Moment halt eine erste Version, ggf. müssen wir das anpassen - ich glaube aber nicht, dass das ein grundsätzlich falscher Ansatz ist, vielleicht abgesehen davon, dass eben keine (neue) sessionId vergeben wird, grade um Probleme mit $old_data zu vermeiden.

Da war im Log zu sehen, dass nach einem Kommando eine neue Session aufgemacht wird. Anschließend wurde laut Log die neue sessionId mit Msg: hermes/dialogueManager/sessionEnded beendet (erwartet hatte ich das für die alte).

Ich eigentlich auch. Wenn es ums FHEM-log geht: wenn man kein msec-Log macht, werden Events gepuffert und uU. "umgekehrt herum" weggeschrieben.

Ist das Kommando ein neuer Intent, ist $data->{Intent} != old_data->{Intent}, was man nutzen kann um $old_data komplett zu löschen. Das bedeutet allerdings, dass beim mehreren CustomIntents man auch nicht mehr auf die Daten eines anderen CustomIntent zugreifen kann (ist ohnehin konsistenter).

Ähm, im Moment ist grade der Ansatz, dass man in Dialogen (andere) Intents aktivieren kann und dann eben ggf. Inhalt ergänzen usw.. Genau dafür wird $old_data gespeichert. Für "irgendwas" braucht man (im Prinzip) eher nichts aus der vorherigen Anweisung. Und wenn, könnte man das via customData zur Verfügung stellen. Da wird Nacharbeit erforderlich sein.

in handleSetDialogTimeout drin ist und dann doch besser in response() aufgehoben wäre.

Weiß noch nicht genau, aber im Moment glaube ich nicht, dass da grundsätzlich was umzustellen ist. Das sind dann eher vorzuschaltende Funktionen.

Ansonsten entdecke ich immer noch neues in der handleIntentSetNumeric() und man da kann auch viel lernen, wie rhasspyMapping funktioniert. Dazu kommt aber morgen mehr - gibt da ganz interessante Möglichkeiten.

Freut mich, dass du da Freude dran hast .

[gregorv]

... dass eben keine (neue) sessionId vergeben wird ...

Bin etwas verunsichert - ist das Ziel, dass für reopenVoiceInput die sessionId behalten wird oder nicht ?
Derzeit ist das ja nicht der Fall - weiter unten sagst Du aber, dass man bei neuen Intents auch die Möglichkeit haben möchtest, dass man auf Daten eines (anderen) vorherigen zugreifen kann. Im Code wird activateVoiceInput() aufgerufen, was eine neue Session (mit anderer sessionId aufmacht - zumindest, soweit ich das bisher gesehen habe).
Wenn die sessionId bis zu timeout oder CancelAction beibehalten werden soll UND auf Daten des vorherigen Intent zugreifbar sein sollen, darf man die beim Start eines anderen Intent natürlich nicht löschen. Da würde tatsächlich die Frage entstehen, wie man sicherstellt, dass es keine ungewollten Störungen duch $old_data gibt.
Weißt Du welche Keys da stören könnten ?

Dazu eine Frage betreffend $old_data:
Bisher kopiere ich ja Keys, die im nächsten Intent benötigt werden in $data und damit erscheinen sie beim nächsten Intent in $old_data.
Was ich bisher nicht probiert habe, ist diese Daten einfach zum publish mit durchzureichen a) weil ich nicht weiß, was Rhasspy mit Daten macht, die nicht zum Topic passen und b) weil ich nicht weiß, ob die dann auch später in $old_data drin sind.
Wenn, wie Du sagst:

...dass man in Dialogen (andere) Intents aktivieren kann und dann eben ggf. Inhalt ergänzen...

UND das eine Möglichkeit ist, die Rhasspy bereitstellt, müsste es ja in Rhasspy einen 'offiziellen' Weg geben, solche Daten zu Rhasspy selbst zu transportieren.
An einfachsten eben dadurch dass man die einfach mit einem publich mitsendet.
Jetzt endlich die Frage: ist das möglich, eventuell sogar der 'offizielle' Weg ?

[Beta-User]

Bin etwas verunsichert - ist das Ziel, dass für reopenVoiceInput die sessionId behalten wird oder nicht ?

Ziel ist erst mal, nach Abschluss einer Aktion direkt eine neue "ansagen" zu können (eventuell mit einem konfigurierbaren intentFilter oä.).
Allerdings ist mir zwischenzeitlich aufgegangen, dass man das nur dann "geordnet" wieder abgeräumt bekommt (mit dem intern definierten timeout, falls der kürzer ist als der in Rhasspy), wenn man aktiv eine neue SessionId vergibt. Das fehlt im Moment (für reopen).

Jetzt endlich die Frage: ist das möglich, eventuell sogar der 'offizielle' Weg ?

Der "offizielle" Weg, innerhalb einer Sitzung Daten in Rhasspy durchzuschleusen ist "customData". Da mir das aber zu kompliziert erschienen ist, alles mitzuschicken und wieder auszupacken, habe ich damals das mit $old_data reingeknödelt. Da erfolgt das "Verknüpfen" der neuen mit den alten Daten über die sessionId.

Ergo würde ich weiter zwei getrennte Wege vorsehen:
- Fortsetzungsdialoge unter der alten sessionId mit $old_data
- "reopen" mit neuer (aktiv festzulegender) sessionId, Weitergabe des "Datenmülls" per customData (?), falls (!) man die braucht, FHEM-interner Timer-Verwaltung zum Schließen und der Option, direkt einen anderen als den üblichen IntentFilter zu setzen (insbes. CancelAction für "sei still").

Hoffe, das Bild ist jetzt etwas klarer?