Modulentwicklung für Rhasspy Sprachassistent

[JensS]

Code Auswählen Erweitern

mosquitto_sub -h 192.168.x.x -p 1883 -v -t hermes/dialogueManager/# -t hermes/hotword/# -t hermes/intent/#
hermes/hotword/alexa/detected {"modelId": "alexa", "modelVersion": "", "modelType": "personal", "currentSensitivity": 0.5, "siteId": "wohnzimmer", "sessionId": null, "sendAudioCaptured": null, "lang": null, "customEntities": null}
hermes/dialogueManager/sessionStarted {"sessionId": "wohnzimmer-alexa-3e2edb19-61c0-4f2a-a5b9-975745fb1db6", "siteId": "wohnzimmer", "customData": "alexa", "lang": null}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/intent/de.fhem:Shortcuts {"input": "Beleuchtung einschalten", "intent": {"intentName": "de.fhem:Shortcuts", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [], "sessionId": "wohnzimmer-alexa-3e2edb19-61c0-4f2a-a5b9-975745fb1db6", "customData": "alexa", "asrTokens": [[{"value": "Beleuchtung", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 11, "time": null}, {"value": "einschalten", "confidence": 1.0, "rangeStart": 12, "rangeEnd": 23, "time": null}]], "asrConfidence": 1.0, "rawInput": "beleuchtung einschalten", "wakewordId": "alexa", "lang": null}
hermes/dialogueManager/continueSession {"intentFilter":["de.fhem:ConfirmAction","de.fhem:CancelAction"],"sessionId":"wohnzimmer-alexa-3e2edb19-61c0-4f2a-a5b9-975745fb1db6","siteId":"wohnzimmer","text":"Soll ich die Stehlampe wirklich einschalten?"}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/dialogueManager/sessionEnded {"termination": {"reason": "intentNotRecognized"}, "sessionId": "wohnzimmer-alexa-3e2edb19-61c0-4f2a-a5b9-975745fb1db6", "siteId": "wohnzimmer", "customData": "alexa"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/dialogueManager/endSession {"sessionId":"wohnzimmer-alexa-3e2edb19-61c0-4f2a-a5b9-975745fb1db6","siteId":"wohnzimmer","text":"Tut mir leid, da hat etwas zu lange gedauert"}

Neustart - es wäre gut ohne configure auszukommen.

[Beta-User]

Hm, also:
"sessionEnded" wird sowieso abonniert, da habe ich jetzt das Löschen des Timers reingebastelt (#2140ff).
Damit sollte das "erledigt" sein (auch wenn es schöner wäre, "falsche intents" direkt auszuschalten, so dass da nichts dazwischenfunkt, aber selbst wenn das dann irgendwann klappen sollte, schadet es nicht, ggf. noch bestehende Timer abzuräumen und überflüssige Daten zu löschen).

Neustart - es wäre gut ohne configure auszukommen.

Wieso?

Zum Hintergrund der Frage:
Meine Überlegung beim Erstellen des dialogManager war, dass es sinnvoll wäre, nicht benötigte Intents ausschalten zu können. Dabei war mir die "Stille" (=> CancelAction in Folge des false positives auf "nein") besonders deutlich vor Augen, aber auch die Auswahlmöglichkeiten sind in der Erkennung kurze Sequenzen, und ich fürchte Nebenwirkungen, wenn man die betreffenden Intents _nicht_ deaktiviert.
Von daher wäre meine Überlegung eher, ggf. bestehende Probleme in diesem Zusammenhang in die Rhasspy-Community einzukippen bzw. mal nachzufragen, ob das so beabsichtigt ist (bzw. warum). Evtl. bekommt man "wenigstens" eine Neustart-Info via MQTT?
Aber evtl. übersehe ich ja mal wieder was wichtiges?

[JensS]

Prima - klappt alles.
Noch ein Vorschlag - bei intentNotRecognized "Habe abgebrochen" als Antwort. Dazu genügt ja ein speak.

configure - da kann ich deine berechtigten Bedenken nachvollziehen. Es wäre schön, wenn Rhasspy in hermes/dialogueManager/continueSession die Erweiterung "slot" aufnehmen würde. Das passiert ja vielleicht in Zukunft oder ist nur nicht dokumentiert.

CancelAction - da hatte ich den Sprung zur sub von ConfirmAction in 10_RHASSPY.pm gesehen. Letztlich ist alles, was nicht "OK" ist automatisch cancel. Ist CancelAction als separater Intent überhaupt noch notwendig?

[Beta-User]

p.p.s. [...]

Sorry, das hatte ich erst eben gesehen, hatte sich wohl überschnitten, scheint aber (weitesgehend) erledigt zu sein?

Noch ein Vorschlag - bei intentNotRecognized "Habe abgebrochen" als Antwort. Dazu genügt ja ein speak.

Hab's mal reingeknödelt.

Bin aber nach wie vor irgendwie "unruhig", was das ganze angeht. Eigentlich sollte sich irgendwie verhindern lassen, dass überhaupt der falsche Intent herangezogen wird. Habe jetzt eine Weile drauf rumgekaut und überlegt, ob man doch dialogManager irgendwie dazu nutzen sollte, nur noch bestimmte Intents aktiviert zu halten. Das dürfte aber andererseits auch nicht des Rätsels Lösung sein, denn - jedenfalls lt. Doku in https://rhasspy.readthedocs.io/en/latest/reference/#dialoguemanager_sessionqueued - theoretisch wäre es denkbar, dass mehrere Sessions von einer siteId her offen zu halten wären. Da würde dann das Deaktivieren zu echten Problemen führen, weil dann immer die letzte Anweisung durchschlagen würde.

Jetzt bin ich aber in der kurzen Doku noch über "sendIntentNotRecognized" gestolpert , und würde dazu noch zu einem kurzen Test bitten. Imo sollte das dazu führen, dass die Sitzung erst dann geschlossen wird, wenn entweder ein (zu intentFilter) "passender" Intent gewählt wird, oder der Timeout zuschlägt. Kann aber natürlich sein, dass uns das an anderer Stelle wieder einholt und man das ggf. ein- und ausschaltbar ausgestalten müßte...

configure - da kann ich deine berechtigten Bedenken nachvollziehen. Es wäre schön, wenn Rhasspy in hermes/dialogueManager/continueSession die Erweiterung "slot" aufnehmen würde. Das passiert ja vielleicht in Zukunft oder ist nur nicht dokumentiert.
[...]
CancelAction - da hatte ich den Sprung zur sub von ConfirmAction in 10_RHASSPY.pm gesehen. Letztlich ist alles, was nicht "OK" ist automatisch cancel. Ist CancelAction als separater Intent überhaupt noch notwendig?

Notwendig: nein. Vermutlich für die meisten User logischer?

Tatsächlich ist das in der jetzigen Form schlicht und ergreifend "halt so no worra", weil mir zu Beginn noch nicht so richtig klar war, ob man jetzt geschickter einen Intent mit mehreren Modi anlegen sollte und dann anhand der Payload den Rest ansteuert, oder ob man es besser getrennt hält. Das ganze schon vor dem gedanklichen Hintergrund, dass man z.B. Räume oder Devices wählen können sollte.
Für den Moment _glaube ich_, dass separate Intents die geschicktere Lösung sind. Das beruht aber vor allem auf dem Umstand, dass ich irgendwann über das "sister project" voice2json gestolpert bin, das als "Verbesserungen" v.a. das Ändern von slots@runtime mitbringen soll. Vermutlich fehlte dir diese letzte Info als Puzzlesteinchen, um zu verstehen, warum bestimmte Dinge jetzt eben erst mal so gelöst sind, wie sie gelöst sind...

[JensS]

Ok, bin gerade auf dem Sprung.
Stille und "wie spät ist es" führen zu "tut mir leid, da hat etwas zu lange gedauert"

Code Auswählen Erweitern

mosquitto_sub -h 192.168.100.1 -p 1883 -v -t hermes/dialogueManager/# -t hermes/hotword/# -t hermes/intent/#
hermes/hotword/alexa/detected {"modelId": "alexa", "modelVersion": "", "modelType": "personal", "currentSensitivity": 0.5, "siteId": "wohnzimmer", "sessionId": null, "sendAudioCaptured": null, "lang": null, "customEntities": null}
hermes/dialogueManager/sessionStarted {"sessionId": "wohnzimmer-alexa-a32c083b-4d02-4f6e-87f2-fb8d4d2dc652", "siteId": "wohnzimmer", "customData": "alexa", "lang": null}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/intent/de.fhem:Shortcuts {"input": "Beleuchtung einschalten", "intent": {"intentName": "de.fhem:Shortcuts", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [], "sessionId": "wohnzimmer-alexa-a32c083b-4d02-4f6e-87f2-fb8d4d2dc652", "customData": "alexa", "asrTokens": [[{"value": "Beleuchtung", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 11, "time": null}, {"value": "einschalten", "confidence": 1.0, "rangeStart": 12, "rangeEnd": 23, "time": null}]], "asrConfidence": 1.0, "rawInput": "beleuchtung einschalten", "wakewordId": "alexa", "lang": null}
hermes/dialogueManager/continueSession {"intentFilter":["de.fhem:ConfirmAction","de.fhem:CancelAction"],"sendIntentNotRecognized":"false","sessionId":"wohnzimmer-alexa-a32c083b-4d02-4f6e-87f2-fb8d4d2dc652","siteId":"wohnzimmer","text":"Soll ich die Stehlampe wirklich einschalten?"}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/dialogueManager/intentNotRecognized {"sessionId": "wohnzimmer-alexa-a32c083b-4d02-4f6e-87f2-fb8d4d2dc652", "siteId": "wohnzimmer", "input": "wie spät ist es", "customData": "alexa"}
hermes/dialogueManager/endSession {"sessionId":"wohnzimmer-alexa-a32c083b-4d02-4f6e-87f2-fb8d4d2dc652","siteId":"wohnzimmer","text":"Tut mir leid, da hat etwas zu lange gedauert"}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/dialogueManager/sessionEnded {"termination": {"reason": "nominal"}, "sessionId": "wohnzimmer-alexa-a32c083b-4d02-4f6e-87f2-fb8d4d2dc652", "siteId": "wohnzimmer", "customData": "alexa"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "dialogueSession"}

Es funktioniert soweit alles.

Dass der CancelAction-Intent noch drin ist, um irgendwelche Sonderfälle zu bedienen, habe ich mir schon gedacht.

Vielen Dank für die rasche Umsetzung!

Gruß Jens

[Beta-User]

Ok, bin gerade auf dem Sprung.
Stille und "wie spät ist es" führen zu "tut mir leid, da hat etwas zu lange gedauert"
[...]
Es funktioniert soweit alles.

OK, dann lassen wir das jetzt erst mal so, nochmal Danke auch für die Tests und die Inputs, auf das mit "intentNotRecognized" bei "continueSession" wäre ich wohl sonst nicht so schnell gestoßen.

Auswahl aus mehreren möglichen Geräten hattest du aber noch nicht getestet, wenn ich das richtig verstehe?
(Da muss ich bei mir mal ein paar priorities wieder löschen, um das zu testen , und kann vermutlich auch die sentences noch einkürzen)...

Dass der CancelAction-Intent noch drin ist, um irgendwelche Sonderfälle zu bedienen, habe ich mir schon gedacht.

Na ja, nach meiner Lesart ist es eher andersrum: Der indirekte Aufruf aus ConfirmAction ist noch drin, um einen Sonderfall abzudecken ...
Kommt aber wirklich nicht drauf an.

[Beta-User]

Zur Haltbarbeit von configure muss ich dich leider enttäuschen. Die ist abgelaufen, wenn die Basis neu gestartet wird.

Dazu ist mir noch was eingefallen: Es müßte ausreichen, wenn man das configure mit "retain"-flag versendet, also an den Topic einfach ein ":r" anhängt (#767)

Auswahl aus mehreren möglichen Geräten hattest du aber noch nicht getestet, wenn ich das richtig verstehe?
(Da muss ich bei mir mal ein paar priorities wieder löschen, um das zu testen , und kann vermutlich auch die sentences noch einkürzen)...

Getestet, und leider funktioniert der Teil jetzt grade nicht mehr, muss mal schauen, wie das im Lichte der neueren Erkenntnisse zu reparieren ist...

(v.a. @drhirn:) Generelle Anmerkung noch zum Thema Doku: Die ganzen Bestätigungs-Mechanismen sind sehr davon abhängig, dass man Rhasspy für das Dialog-Management verwendet (oder was, das 1:1 denselben "Dialekt" spricht). Kann sein, dass das mittelfristig Probleme schafft, falls jemand unbedingt was anderes einsetzen will.

p.s. Für einige SetOnOff-Devices würde ich gern die ConfirmAction nutzen. Rasensprenger, Teichbefüller, Weidezaungerät uem habe ich aus Sichereitsgründen noch nicht in Rhasspy intergriert. Für jedes Device zwei rhasspyShortcuts anzulegen, bläht die Config auf.

Der edit wäre mir mal wieder fast durch die Lappen gegangen...

Ich nehme es auf die Liste, aber ganz ohne zusätzliche Konfiguration wird es wohl nicht gehen.

[drhirn]

(v.a. @drhirn:) Generelle Anmerkung noch zum Thema Doku: Die ganzen Bestätigungs-Mechanismen sind sehr davon abhängig, dass man Rhasspy für das Dialog-Management verwendet (oder was, das 1:1 denselben "Dialekt" spricht). Kann sein, dass das mittelfristig Probleme schafft, falls jemand unbedingt was anderes einsetzen will.

Ok, nehme ich in die Doku auf

Danke für's Weiterwerken euch beiden!

[Beta-User]

Ok, nehme ich in die Doku auf

Bevor wir Doppelarbeit machen:
ist (neben anderem) in der cref der beiliegenden Version ergänzt.

Da ist weiter drin:
- "retain" für die dialogue-configuration
- die Antworttexte werden intern jetzt alle über getResponse() ermittelt, gibt einen weiteren Parameter, damit das auch für die Responses klappt, die eine Unterstruktur haben (ungetestet).

Getestet, und leider funktioniert der Teil jetzt grade nicht mehr, muss mal schauen, wie das im Lichte der neueren Erkenntnisse zu reparieren ist...

Das wird dauern, im Moment werde ich aus dem Code nicht schlau, wieso das nicht mehr klappt. "Eigentlich"... Vielleicht habe ich mal wieder für den Schnelltest die "besten" Testbedingungen getroffen .

[JensS]

Getestet, und leider funktioniert der Teil jetzt grade nicht mehr, muss mal schauen, wie das im Lichte der neueren Erkenntnisse zu reparieren ist...

Das wird dauern, im Moment werde ich aus dem Code nicht schlau, wieso das nicht mehr klappt. "Eigentlich"... Vielleicht habe ich mal wieder für den Schnelltest die "besten" Testbedingungen getroffen .

Hab ein zweites Device eingerichtet - hier läuft es. Bei intentNotRecognized kommt: "tut mir leid, da hat etwas zu lange gedauert" - aber das ist ok.

Gruß Jens

p.s.

Code Auswählen Erweitern

i="Beleuchtung einschalten" f="set Stehlampe on" n="Stehlampe" c="Soll ich die Stehlampe wirklich einschalten?" ct=10
i="Lampe einschalten" f="set Schreibtischlampe on" n="Schreibtischlampe" c="Soll ich die Schreibtischlampe wirklich einschalten?" ct=10

[JensS]

Evtl. bekommt man "wenigstens" eine Neustart-Info via MQTT?

Wenn man in der Rhasspy-Web-GUI auf "Restart" klickt, passiert rein gar nichts im MQTT. Die Zeit wäre auch zu kurz, um einen Notar für einen letzten Willen zu finden. Daher wird's wohl auch kein retain geben.

Gruß Jens

[Beta-User]

Hmm, bin grade ratlos:
Beim Testen war ich davon ausgegangen, dass ConfirmAction/CancelAction funktionieren und habe mir daher ChoiceDevice/CancelAction angesehen. Das hat "scheinbar" nicht funktioniert. Scheinbar, weil ich keine Sprachausgabe (mehr) hatte mit der Anfrage, welches Device ich denn gerne hätte.
Dann habe ich mir die MQTT-Seite dazu angesehen - die sah so aus, wie nach dem Code zu vermuten: Eigentlich passt alles!?!
Dann habe ich es mit ConfirmAction/CancelAction probiert, und siehe da, ich erhalte auch keine (gesprochende) Bestätigungsanfrage auf dem Handy-Satelliten?!? Das Problem ist also wohl nicht auf der Modulebene zu suchen, sondern wohl eher irgendwo anders. Normale Ausgaben ("gerne" etc.) werden aber gesprochen, das scheint auf continueSession beschränkt zu sein.
Meinen ESP-Satelliten habe ich grade nicht gefunden, und der Pi ist auch nicht getestet einsatzfähig...

@JensS (bzw. auch andere, die neben normalen Satelliten auch die Handy-App im Einsatz  haben): Könntet ihr bitte mal checken, ob das bei euch auch ein Problem ist bzw. ggf. mit welcher Art Satellit es auftritt? Dann könnte man das mal in Richtung der Rhasspy-Community adressieren...

Wenn man in der Rhasspy-Web-GUI auf "Restart" klickt, passiert rein gar nichts im MQTT. Die Zeit wäre auch zu kurz, um einen Notar für einen letzten Willen zu finden. Daher wird's wohl auch kein retain geben.

Imo gibt es da kein allgemein sichtbares "MQTT-Gelaber", sondern der Server haut die "retain"-Messages nur an die Clients raus, die sich neu verbinden. Soweit so klar. ABER: Einen ähnlichen Effekt kann man erzielen, wenn man sich mit mosquitto_sub neu subscribed. Aber da ist nichts...?!?
Also FHEM neu gestartet => immer noch nichts...? Scheinbar wir jetzt das configure_DialogManager gar nicht mehr aufgerufen und daher auch nichts gepublisht...? Und da die Messages per siteId versendet werden, wäre es sowieso immer nur die letzte, das bringt also auch nicht wirklich den gewünschten Effekt, selbst wenn es bis dahin funktionieren würde. Hmmm, muss wohl nochmal über dieser Sache brüten .

[Beta-User]

Das hat mir jetzt keine Ruhe gelassen...

Ursache dafür, dass da schlicht nichts kam war, dass die bei der Gesamtinitialisierung vor dem DialogManager-Aufruf stehende Erneuerung der Subscriptions erst mal den M2C disconnected hat, und der daher just zu dem Zeitpunkt einfach nicht bereit war, irgendwas zu verschicken!
Von daher: erst mal alles wieder jeweils 2 Schritte vor, zur Seite, zurück und zur anderen Seite...

Zwischenergebnis anbei (jetzt wieder ohne retain). Glaube zwar nicht, dass das meine App-Dialoge wieder zurückbringt, aber damit sollte sich zumindest checken lassen, ob
- die configure-Anweisungen nicht doch dauerhaft in Rhasspy registriert bleiben (Obacht: da das bisher @startup wirkungslos war, könnte das dazu führen, dass jetzt gar nichts mehr geht, falls ich beim Zusammenbasteln der payload was falsch gemacht haben sollte...!);
- es erforderlich/hilfreich ist, das jeweils innerhalb einer Session via configure zu ändern. Dazu gibt es jetzt in der DEF eine weitere Option "switchDM"; setzt man die auf 1 (oder einen anderen Wert, der als wahr interpretiert wird), sollten dann auch wieder die configure-Anweisungen rausgehen. Kann allerdings sein, dass man das ggf. vor der response machen muss.

Die Antworten auf

Könntet ihr bitte mal checken, ob das bei euch auch ein Problem ist bzw. ggf. mit welcher Art Satellit es auftritt?

würde mich aber weiter interessieren, und zwar optimalerweise sowohl mit der alten wie mit der angehängten Version.
Weiter wäre in dem Zusammenhang ggf. noch interessant, ob es auch bei echten Rhasspy's (Base+Satelliten) einen Unterschied macht, ob die Base sprechen soll oder ein Satellit.

[JensS]

@Beta-User
configure lässt dir wohl keine Ruhe. 
Hier mal wieder ein paar Gedanken/Ideen:
Der intentFilter gilt nur für die aktuelle Session und ist anschließend zwangsläufig nicht mehr aktiv. Das gilt auch bei einem Timeout.
Configure deaktiviert alle Intents für eine siteId und wenn eine Session nicht durchläuft, bleibt alles deaktiviert.
Da es aber den slot-Aufruf bei continueSession nicht gibt, bleibt wohl nur die zweite Variante.

Aus meiner Sicht sollte der Ablauf so aussehen:
Die Session wird von der Basis gestartet und der Intent wird von der Basis übergeben.
FHEM erkennt den Intent und setzt configure auf

Code Auswählen Erweitern

intents: [intentId: ConfirmAction, enable: true], siteId: wohnzimmerAlle Intents, außer ConfirmAction sind deaktiviert.

Nach der Antwort sollte 

Code Auswählen Erweitern

configure intents: [], siteId: wohnzimmerfolgen, um alle Intents zu aktivieren.
Abschließend dann

Code Auswählen Erweitern

intents: [intentId: ConfirmAction, enable: false], siteId: wohnzimmerum ConfirmAction zu deaktivieren.

Ist nur so eine Idee - ungestestet. Zum testen deiner 10_RHASSPY.pm komme ich frühestens heute Abend.

Gruß Jens

[Beta-User]

configure lässt dir wohl keine Ruhe.

Nein...

Hier mal wieder ein paar Gedanken/Ideen:
Der intentFilter gilt nur für die aktuelle Session und ist anschließend zwangsläufig nicht mehr aktiv. Das gilt auch bei einem Timeout.
Configure deaktiviert alle Intents für eine siteId und wenn eine Session nicht durchläuft, bleibt alles deaktiviert.
Da es aber den slot-Aufruf bei continueSession nicht gibt, bleibt wohl nur die zweite Variante.

Na ja, da die Sessions entweder durch RHASSPY (ok oder timeout) oder Rhasspy (no one managed bei meinem "ungesprächigen" App-Satelliten...) beendet werden, sollte dann "irgendwann" auch nach einem intentFilter wieder alles temporär deaktivierte wieder aktiv sein. (Nur) so macht das ganze für mich Sinn, aber evtl. übersehe ich auch was. (Ja, in Teilen: Wenn Rhasspy die Sitzung zumacht, müßte ggf. die DialogManager-config auch aufgerufen werden, wenn man die Intents zwischendurch via config umstellt; das deutet für mich darauf hin, dass es nicht so gedacht sein kann).

Grundsätzlich war ich auch davon ausgegangen, dass immer alles aktiv ist, es sei denn, man deaktiviert es (temporär via intentFilter oder dauerhaft via "configure"-Topic). Wieder anschalten sollte dann auch selektiv gehen, entweder über entsprechende intentFilter-Erneuerung oder via configure-true.
Es geht jetzt v.a. darum rauszufinden, ob diese Grundannahme korrekt ist.

Aus meiner Sicht sollte der Ablauf so aussehen:
Die Session wird von der Basis gestartet und der Intent wird von der Basis übergeben.
FHEM erkennt den Intent und setzt configure auf

Code Auswählen Erweitern

intents: [intentId: ConfirmAction, enable: true], siteId: wohnzimmerAlle Intents, außer ConfirmAction sind deaktiviert.

In diese Richtung ging mein ursprünglicher Ansatz, nur dass da eben neben ConfirmAction noch CancelAction und (alternativ statt ConfirmAction) einer der beiden Choice-Intents aktiviert wurde.
Fyi: Soweit hatte es auch schon mal bei mir funktioniert

Nach der Antwort sollte 

Code Auswählen Erweitern

configure intents: [], siteId: wohnzimmerfolgen, um alle Intents zu aktivieren.

Abschließend dann

Code Auswählen Erweitern

intents: [intentId: ConfirmAction, enable: false], siteId: wohnzimmerum alle Intents außer ConfirmAction zu aktivieren.

In diese Richtung ging auch der bisherige Code, nur eben mit mehr Intents und dem "direkten" Versuch, jeweils (nur) die betroffenen Intents wieder umzuschalten. Da "global" zu agieren, (also erst beim "Aufräumen" alles zu aktivieren, um dann selektiv wieder zu deaktivieren) finde ich schwierig, weil es theoretisch ja sein kann, dass grade irgendeine weitere Sitzung läuft (muss nicht mal FHEM sein), in der auch nur bestimmte Intents zulässig sind. Das käme mir sauberer vor: Immer der, der die Sitzungskontrolle übernimmt (continueSession), ist auch für das "Aufräumen" zuständig, muss aber nur wegräumen, was er selbst an Hinterlassenschaften zu verantworten hat.

Kannst ja heute abend dann beim Testen auch "mithören", was die neue Version mit und ohne den neuen Schalter jeweils über "configure" raushaut. Und falls du die Rhasspy-logs (oder wo auch immer man sehen kann, was grade auf der Rhasspy-Seite "Sache" ist, also welche Intents jeweils grade (de-) aktiviert sind) auswerten kannst, wäre das natürlich auch super!

Insgesamt _glaube ich_, dass die jetzige Version _ohne die Aktivierung in der DEF_ die korrekte Implementierung auf der FHEM-Seite darstellt und wir nur irgendein Problem auf der Rhasspy-Seite haben, wenn die App (oder bestimmte Satelliten-Typen?) im Einsatz ist.

Gegenüber der bei dir ja funktionierenden Variante bringt die neue ja eigentlich nur die (jetzt hoffentlich funktionsfähige) Erstinitialisierung der Intents mit, die Dialoge an sich hatten ja funktioniert (zumindest Confirm).