CustomIntent mit Dialog

[gregorv]

Ich experimentiere seit einiger Zeit mit Rhasspy und fhem. Da ich ohnehin viele Funktionalität in 99_myUtils.pm ausgelagert habe, bin ich dazu übergegangen CustomIntents zu erstellen. Falls da jemand einen Link zu umfangreicherer Dokumentation hat, bitte sagen, wo das zu finden ist.
Derzeit habe ich meine gesamten RollladenIntens in zwei CustomIntents gepackt mit Funktionen wie Auf, Zu, halb oder beliebige pos. Wenn der Intent zum fahren der Rollladen gestartet wird, lasse ich den Dialog offen und der Benutzer kann in dieser Zeit 'Stop' (oder ähnliches sagen, damit der Rollladen anhält.
Das funktioniert prima, aber nicht ganz so, wie ich mir das vorstelle.
Info:In der BlindStop sub wird nur ein String "Rollladen angehalten" zurückgeliefert.
Hier der return Wert, der in der sub "Blinds" zum Starten der Rolladen benutzt wird:

Code Auswählen Erweitern

  return {
    text => "gestarted",
    intent => {
      name => "Blinds",
      confidence => $data->{confidence}
    },
    sendIntentNotRecognized => 0,
    sessionTimeout => 30,
    customData => {
        action => "blindMoving",
        device => $name
    }
  };
Folgende Probleme konnte ich noch nicht lösen:
1. "sendIntentNotRecognized => 0": Wenn ich nach dem Start kein Stopp Kommando spreche, wird nach ca. 15 Sek. Intent not recognized gemeldet und die zugehörige Ansage wird gespielt. Wie kann ich erreichen, dass der Dialog sauber geschlossen wird ? (Falls das nicht geht, die Fehleransage nicht kommt)
2. "sessionTimeout => 30": Der Parameter wird ignoriert, Intent not Recognized kommt immer nach ca. 15 Sek. Wie kann ich den Zeitraum, in dem auf ein eventuelles Stop gewartet wird, verändern idealerweise auf den Wert, der für "drive-up-time-to-open" beim entsprechenden Rolladen eingestellt ist ?
3. Wenn wärend dieser Wartezeit ein Geräusch aufgenommen wird (z.B. vorbeifahrendes Auto), kommt 'Intent not recognized' und kein Stop ist mehr möglich. Gut wäre, wenn alles was nicht Stop (oder den im Intent angegebenen Alternativen - nein, halt...) ist, ignoriert wird und den Dialog nicht beendet.

Wäre super, wenn mir da jemand Hinweise geben könnte.
Allgemeine Fragen zum Rückgabewert:
Das Hash Format ist ja "key" => "wert" -> müssen numerische Werte auch in " eingeschlossen sein? Habe ich getestet, kein Unterschied (aber gerade die Werte werden ja auch ignoriert).
Sollte der Rückgabewert in VAR1 => {...} eingeschlossen sein ? (Habe ich noch nicht getestet)
Ist mein Syntax im Code Block überhabt richtig? (das meiste funktioniert ja)
Bei einem Array als Rückgabewert können nur alternative responses angegeben werden, von denen eine zufällig ausgewähl wird - oder hat man da auch Möglichkeiten der Steuerung?
Danke, Gregor

[Beta-User]

Hallo, willkommen bei den RHASSPY-Usern!

Ist leider schon sehr lange her, seit ich mich das letzte Mal mit diesen Sachen beschäftigt habe, von daher tappe ich auch ziemlich im Dunkeln rum. Weiter hatte ich bei der Entwicklung eher im Auge, die Dinge, die ich als "Basisfunktionalität" ansehe, eher direkt in den Code zu integrieren, CustomIntent war nicht mein Fokus, daher bitte die folgenden Anmerkungen mit einer gewissen Vorsicht genießen:

- Wenn ich das Beispiel in https://svn.fhem.de/trac/browser/trunk/fhem/contrib/RHASSPY/99_RHASSPY_Utils_Demo.pm (DialogueTest) richtig verstanden habe, wird der default timeout nur geändert, wenn ein ARRAY type per return zurückgegeben wird.
- ggf. kann man das ändern, indem man (ungetestet!) im RHASSPY-Code eine Zeile 4226 neu einfügt:

Code Auswählen Erweitern

        $timeout = $error->{sessionTimeout} if defined $error->{sessionTimeout} && looks_like_number( $error->{sessionTimeout} );
.

Das "Grundproblem" dürfte aber weiter bleiben, dass nach dem Abwarten des timeouts eine Info "angesagt" wird, dass der timeout um ist, weil eigentlich halt auf eine weitere Ansage gewartet wird. Möglicherweise (!) gibt es irgendwo noch ein Beispiel mit einer "silent" Rückgabe? Mir dämmert dunkel, damit auch rumexperimentiert zu haben, wenn dazu was zu finden ist, dann ggf. in dem sehr langen Entwicklungstread zu RHASSPY (ziemlich hinten).

Zu dem konkreten Problem mit dem Anhalten der Rollläden würde ich allerdings sowieso eher zu einer generischen Lösung tendieren, die auch dann funktioniert, wenn der Fahrbefehl von "irgendwoher" kam, also z.E. auch von einem Taster, einer Automatik, whatever.

Hier ein Auszug aus meiner sentences/SetNumeric, bei der auch solche "Spezialfälle" wie "Halb" oder eben das Anhalten mit abgedeckt sind, erläuterungen müßten in einem Thread mit "best practices", Lösungsansätze oder so zu finden sein:

Code Auswählen Erweitern

( stoppe | stop ){Change:cmdStop} [<den>] $de.fhem.Device-blind{Device} [<rooms>]
( halte | halt ){Change:cmdStop} [<den>] $de.fhem.Device-blind{Device} [<rooms>] an
( <cmddrive> | <cmdmulti> ) [<den>] $de.fhem.Device-blind{Device} [<de.fhem:SetOnOff.rooms>] (halb (auf|zu)){Value:49.5}
( <cmddrive> | <cmdmulti> ) [<den>] $de.fhem.Device-blind{Device} [<de.fhem:SetOnOff.rooms>] (<etwas> | ein [(kleines{Factor:0.75} | großes{Factor:2} ) ] Stück{Value:15})  [weiter] (auf{Change:setUp} | zu{Change:setDown} )
(öffne{Change:setUp} | schließe{Change:setDown} ) [<den>] $de.fhem.Device-blind{Device} [<de.fhem:SetOnOff.rooms>] (<etwas> | ein [(kleines{Factor:0.75} | großes{Factor:2} ) ] Stück{Value:15})
  

[Beta-User]

Bei einem Array als Rückgabewert können nur alternative responses angegeben werden, von denen eine zufällig ausgewähl wird - oder hat man da auch Möglichkeiten der Steuerung?

Sorry, hatte ich irgendwie überlesen:

Soweit mir das in Erinnerung ist, wird bei jeder "response" geschaut, ob da was "pipe-separiertes" kam, und wenn ja, wird daraus zufällig einer dieser Blöcke ausgegeben. Diesen Teil kann man (unterstellt, das stimmt so) also nur dahingehend steuern dass man RHASSPY eine passende Auswahl vor die Füße wirft.

Dementsprechend kann man das schon "steuern", indem man eben im myUtils-Code selbst die Vorauswahl trifft oder eben nur die einen passende Antwort zuläßt.

Trifft das die Frage?

[gregorv]

Hallo Beta-User,
vielen Dank für die ausführliche Antwort. Damit habe ich erstmal neues 'Futter' für weitere Recherchen und Tests. Ich schau mir die 10_RHASSPY.pm mal genauer an.
Bei Deinem sentence für die Rollladensteuerung (nehme ich an) wird der Dialog nicht offengehalten? Falls doch, wäre toll, wenn Du mir die zugehörige 'rhasspyMappings' und ggf. 'rhasspySpecials'. Noch zeigen könnntest. Ich hatte zuerst die generische Variante implementiert, konnte aber Stop nur realisieren, wenn das KeyWort erneut gesprochen wird, was einerseits lästig ist und außerdem ist die Rollladenfahrt ggf. schon beendet bevor man das geschafft hat. Deshalb hatte ich schon die ausführlichere response zu "gestartet" geschrumpft. "sag stop, um den Rolladen anzuhalten" geht gar nicht ohne 'sleep' im fhem Kommando sonst bleibt keine Zeit zum Stop

Weißt Du, ob man Rhasspy so einstellen kann, dass er keine Nachricht an FHEM schickt, wenn er zwar was erkennt, aber keinen intent findet ?

Bezüglich der Frage zum Array als return Wert ging es eher darum, ob man damit auch z.B. den Dialog offen halten kann (ich mag keine hashes).

Danke Gregor

[Beta-User]

Bei Deinem sentence für die Rollladensteuerung (nehme ich an) wird der Dialog nicht offengehalten?

Nein.
Und meine Devices (CUL_HM und ZWave) verstehen nativ ein "stop"-Kommando, "problematisch" ist da nur das Einstellen der Lamellendrehung, dafür sind dann rhasspySpecials definiert.

Wenn das Problem aber das Schließen des Dialogs nach "getaner Arbeit" ist, könntest du mal den sessionTimeout-Parameter im define testen bzw. mal schauen, ob es dazu irgendwelches feedback im "Mega-Thread" gibt.

Weißt Du, ob man Rhasspy so einstellen kann, dass er keine Nachricht an FHEM schickt, wenn er zwar was erkennt, aber keinen intent findet ?

Dazu ist mir nichts in Erinnerung, bei mir ist Rhasspy so konfiguriert, dass er immer irgendeinen Intent findet. Ich benutze aber praktisch nur die App und dort den "Knopf", kein Hotword.

Ggf. könntest du dich im "Mega-Thread" mal einklinken, da lesen dann eher die anderen mit, die sonst noch mit Rhasspy arbeiten. Eventuell liest auch der eine oder andere eher mit, wenn du den Threadtitel im ersten Beitrag so änderst, dass klarer wird, dass es hier um RHASSPY geht.

Bezüglich der Frage zum Array als return Wert ging es eher darum, ob man damit auch z.B. den Dialog offen halten kann (ich mag keine hashes).

Das geht, aber egal bei welcher Variante muss man strukturiert aufbereitete returns liefern, damit die Datenstrukturen im Großen und Ganzen schon zu dem passen, was hinterher als JSON vercodet werden muss. Hatte mich damals an dem orientiert, was lt. Doku bei Rhasspy möglich war, weniger an "user-friendlyness" im Vercoden innerhalb der myUtils. (PS: da war mir vieles von dem zu "frickelig", das damals vorzufinden war, als wir damit angefangen haben. Am Ende sind weniger "echte" Intents übrig geblieben bei größerer Funktionalität, weil eben viel mehr im Hauptcode gelandet ist...)

[gregorv]

Danke, den Mega-Thread kenne ich und habe auch schon viele Anregungen daraus bezogen. Wenn man gerade auf der Suche nach etwas bestimmten ist, überliest man natürlich was gerade nicht aktuell ist; mit der Folge, dass ich schon mehrfach von Seite 1 angefangen habe - halt bis dahin, wo ich fündig wurde. Ist halt recht zeitaufwändig, aber macht Spass.
An dem Timeout Parameter bin ich gerade dran - wenn ich schaffe, die sub 'setSpeechDialogTimeout' mit der erwarteten Parametern zu füllen oder wenn ich zur richtigen Zeit $hash->{helper}->{SpeechDialog}->{config}->{$device}->{sessionTimeout} überschreiben kann (nämlich bevor die sub 'SpeechDialog_open' aufgrufen wird), könnte es klappen.
Alternativ hattest Du ja erwähnt, dass es mit einem Array als return geht. Werde ich auch testen.
Ich hatte mir heute mal OpenVoiceOS angeschaut aber mein erster Eindruck war, dass das noch viel komplexer wird. Meinst Du, das wäre echt eine Alternative zu Rhasspy ? Ich müsste dann auch meinen ESP-C3 Rhasspy Satelliten umschreiben. Solange keiner sagt, dass wäre DIE "Goldrand"- Lösung bleibe ich wohl erst mal bei Rhasspy.

[JensS]

Ist zwar schon eine Weile her aber ich denke, dass alle Anforderungen aus dem ersten Post bereits im Modul intergriert sind.
Ich versuche abends ein Beispiel zu frickeln.

Gruß Jens

[gregorv]

ich arbeite gerade die 10_RHASSPY.pm durch und versuche zu verstehen, wie was funktioniert. Wäre super, wenn Du mir ein Beispiel senden könntest.
Wo wird eigentlich der SpeechDialog timer gesetzt ? Default ist wohl 20 Sekunden, ich sehe bei mir (nach der Ansage immer etwa 15 Sekunden. Die Änderung, die Beta-User vorgeschlagen hat fürht zwar zum Aufruf der entsprechenden sub und der Wert wird auch richtig übergeben, ergibt aber keine Änderung - hier mein Print dazu:

Code Auswählen Erweitern

"starting: setDialogTimeout, timeout: 30".
Danke, Gregor

[Beta-User]

Ich hatte mir heute mal OpenVoiceOS angeschaut aber mein erster Eindruck war, dass das noch viel komplexer wird. Meinst Du, das wäre echt eine Alternative zu Rhasspy ? Ich müsste dann auch meinen ESP-C3 Rhasspy Satelliten umschreiben. Solange keiner sagt, dass wäre DIE "Goldrand"- Lösung bleibe ich wohl erst mal bei Rhasspy.

Vielleicht schaue ich mir das über den Winter mal an, bisher kenne ich das nicht.

Prinzipiell ist mir etwas zu wenig Bewegung auf der Rhasspy-Seite, und wenn, scheint es eher HomeAssistant-support zu betreffen. Ich würde mir wünschen, dass wenigstens die bekannten (kleinen!) Mängel in der Installation der letzten Version beseitigt werden. Aber es funktioniert ja, wenn man die Kniffe kennt...

Falls OpenVoiceOS die grundlegenden Dinge nicht substantiell anders macht (also im Kern Konfigurationen anzunehmen, und key-value-Infos auszutauschen), sollte es auch nicht allzuviel Aufwand sein, das Modul zu portieren.

An dem Timeout Parameter bin ich gerade dran - wenn ich schaffe, die sub 'setSpeechDialogTimeout' mit der erwarteten Parametern zu füllen oder wenn ich zur richtigen Zeit $hash->{helper}->{SpeechDialog}->{config}->{$device}->{sessionTimeout} überschreiben kann (nämlich bevor die sub 'SpeechDialog_open' aufgrufen wird), könnte es klappen.

Das ist nur bedingt richtig: Diese sub ist nur dafür da, wenn NICHT Rhasspy für die Ein- und Ausgabe genutzt wird, sondern ein Messenger oder AMAD oä.. Die "Musik" in der Kommunikation mit Rhasspy ist nämlich das hier in der "sub respond":

Code Auswählen Erweitern

    IOWrite($hash, 'publish', qq{hermes/dialogueManager/$topic $json});

Wo wird eigentlich der SpeechDialog timer gesetzt ? Default ist wohl 20 Sekunden, ich sehe bei mir (nach der Ansage immer etwa 15 Sekunden. Die Änderung, die Beta-User vorgeschlagen hat fürht zwar zum Aufruf der entsprechenden sub und der Wert wird auch richtig übergeben, ergibt aber keine Änderung - hier mein Print dazu:

Der steckt (für den Rhasspy-dialogmanager) in "$json". Kann durchaus sein, dass da was in der Kommunikation zu Rhasspy verbesserungsfähig ist, ich habe das damals mit den "kontinuierlichen Eingabemöglichkeiten" auch eher schnell dann wieder gelassen, weil irgendwas nicht funktioniert hat und mir dann das mit der Musikauswahl per Sprache wichtiger war. Ggf. müßte man das mal im Rhasspy-Code (oder Forum) verifizieren, wie das zu sein hat und ob es überhaupt jemals auf der Rhasspy-Seite funktioniert hatte, aber s.o..
Jedenfalls hatte "damals" kaum jemand bei Rhasspy viel mit Dialogen gemacht (oder ich habe es nicht gefunden), die FHEM-Lösung ist afaik sowas wie der "Gold-Standard", was solche Dinge angeht .

[Beta-User]

Die Änderung, die Beta-User vorgeschlagen hat

Danke für die Rückmeldung, dann checke ich das bei Gelegenheit mal ein (es fehlt vielleicht noch etwas Doku dazu).

[gregorv]

Hallo Beta-User,
etwas weiter, aber noch nicht fertig.

Code Auswählen Erweitern

  return setDialogTimeout($hash, $data, $timeout, $error);hat deshalb nicht funktioniert, weil $error ein hash ist und setDialogTimeout einen Sting erwartet (hat allerdings keinen fehler ausgegeben)

Code Auswählen Erweitern

  $timeout = $error->{sessionTimeout} if defined $error->{sessionTimeout} && looks_like_number( $error->{sessionTimeout} );
  return setDialogTimeout($hash, $data, $timeout, $error->{'text'});setzt den DialogTimeout nun aud den Wert von Timeout.
Allerdings gibt es nur einen halben Erfolg:
1.Wenn ich das 'Stop' Kommando spreche, wird der Intent 'BlindStop' nicht mehr erkannt. Das hängt aber mit meinem Intent-Filter zusammen - lasse ich den weg, geht es wieder (aber alle anderen Intents natürlich auch). Ändere ich

Code Auswählen Erweitern

  return setDialogTimeout($hash, $data, $timeout, $error->{'text'});
zu
  return setDialogTimeout($hash, $data, $timeout, $error->{'text'}, '[\"CancelAction\"]');
klappt es mit dem Timer UND ohne Fehleransage! - allerdings wird der Intent Filter ignoriert 


Auch noch nicht gut:
Wenn ich die Rolladenfahrt starte und nichts sage (oder der Intent nicht erkannt wird) kommt nach dem Timeout eine Fehleransage.
Da werde ich mir mal die handleIntentNotRecognized anschauen und das timeout handling.
Weiterhin ist zwar gut, dass ich nun den DialogTimeout einstellen kann, aber es kommt (vermutlich) vom Rhasspy Server immer noch ein IntentNotRecognized Event nach ca. 15 Sekunden.


Falls einer dazu eine Idee hat ?

[gregorv]

Wieder ein Stück weiter:

Weiterhin ist zwar gut, dass ich nun den DialogTimeout einstellen kann, aber es kommt (vermutlich) vom Rhasspy Server immer noch ein IntentNotRecognized Event nach ca. 15 Sekunden.

Das kommt, wenn die Dauer von Stille den Wert überschreibt, der bei STT Kaldi unter "Maximum Duration:" eingestellt ist (default ist 30 Sekunden). Da stand bei mir 20 Sekunden. In Rhasspy gibt es an dieser Stelle offenbar einen Fehler. Im Log war zu sehen, das nach exakt 10 Sekunden (also nicht 20!!)

Code Auswählen Erweitern

rhasspyasr_kaldi_hermes: -> AsrRecordingFinished(site_id=...kommt. Bei Erhöhung des Wertes auf 30 waren es exakt 15 Sekunden und bei 60 dann 30 Sekunden. Der effektive Wert ist also immer die Hälfte von dem, was eingestellt wird.

Gut: Wenn in FHEM mit setDialogTimeout ein Wert < dem (echten) Timeout durch "Maximum Duration:", hat FHEM die Kontrolle über den DialogTimeout.

[gregorv]

Und noch ein Stück:

- allerdings wird der Intent Filter ignoriert

Ich hatte in 'handleCustomIntent'

Code Auswählen Erweitern

  setDialogTimeout($hash, $data, $timeout, $error->{'text'}, '[\"CancelAction\"]');Das CancelAction setzt den IntentFilter auf de.fhem:CancelAction (im hash unter .ENABLED)
Damit muss noch etwas geändert werden, um einen bestimmten Intent zu aktivieren:

Code Auswählen Erweitern

  my $intentFilter = $error->{intentFilter} if defined $error->{intentFilter} && ref $error->{intentFilter} eq 'ARRAY';
  $timeout = $error->{sessionTimeout} if defined $error->{sessionTimeout} && looks_like_number( $error->{sessionTimeout} );
  return setDialogTimeout($hash, $data, $timeout, $error->{'text'}, $intentFilter);
@Beta-User Damit sind die ersten beiden Zeilen komplett zusätzlich erforderlich und in der dritten Zeile statt $error); nun $error->{'text'}, $intentFilter);
Interresant ist auch, dass der intentFilter im return hash des CustomIntent "intentFilter"->["BlindStop"] sein muss und nicht "intentFilter"->["de.fhem:BlindStop"], was aber dann funktioniert, wenn die sub setDialogTimeout mit einem ungültigen (3. oder 4.) Parameter aufgerufen wird.

[Beta-User]

Habe zugegebenermaßen gewisse Schwierigkeiten, mich in das Thema wieder einzudenken. Ist wirklich schon lange her, seit ich damit rumexperimentiert hatte. Lese aber einstweilen interessiert mit!
Das finding, dass der timeout über Kaldi definiert wird, ist z.B. ein nettes Detail, klingt danach, als wäre das gar nicht über MQTT abweichend parametrierbar?

Wenn du patches einreichen willst, übernehme ich das gerne, bitte aber darum, dass sich der Code-Style möglichst am RHASSPY-Code zu orienteren. Falls dazu Fragen sind, bitte melden.

[gregorv]

timeout über Kaldi definiert wird

Die Einstellung des timeout über setDialogTimeout hat zumindest keinerlei Effekt auf den Zeitpunkt an dem Rhasspy den Dialog mitIntentNotRecognized beendet.
Sehe ich aber kein Problem, weil man den ja so groß einstellen kann, dass er nie vor dem SessionTimeout von FHEM zuschlägt - im Gegenteil, letzterer ermöglicht auch eine Unterscheidung zwischen timeout und IntentNotRecognized - der Kaldi timeout liefert ja immer (zumindest bei mir) IntentNotRecognized.

Das mit den Patches könnte für andere interessant sein. Aber da müsste erst noch jemand drüberschauen - ich hab in den 10_RHASSPY.pm code vor ein paar Tagen erstmalig gesehen. Wann welches Stück durchlaufen wird, weiß ich noch lange nicht.

Gerade hänge ich an dem nächsten Punkt: Wenn der Dialog auf das Stop wartet, soll ein IntentNotRecognized den Dialog nicht schließen sondern nur 'wie bitte?' sagen.