CustomIntent mit Dialog

[Beta-User]

Wenn ich das richtig verstehe, wäre das nicht ganz störungssicher, weil es sein könnte, dass jemand den Key gesetzt hat.

Dieser key ist ausdrücklich als "experimental" gekennzeichnet, also: Wer den gesetzt hat, weiß, auf was er sich eingelassen hat...
Im Ernst: Das ist niemand, und wenn, geht ja nicht gleich die Welt unter .

Du hattest ja vorgeschlagen mit sessionTimeout den Key retryIntent abzulösen - oder irre ich mich da?

Mein Vorschlag war eher so zu verstehen: Bitte lass uns nicht gleich in irgendwelche Details bei tweaks/specials gehen, sondern den dafür ursprünglich vorgesehenen experimentellen Weg der Aktivierung einer neuen Funktionalität via define gehen. Dieser "alte" Weg sah schon immer die Antwort aus "retryIntent" vor. Wir "lösen" also nichts "ab", sondern machen erst mal fertig, was schon vorgesehen war, und dann sehen wir weiter...

Klarer jetzt?

Zwei Dinge fallen auf:

Das muss ich mir bei Gelegenheit mal im MQTT-Verlauf ansehen; vielleicht kann ich morgen noch eine (kommentierte) Version liefern, aus der besser zu erkennen ist, was im Ergebnis bewirkt werden soll.

Es kann sein, dass die "alte" Logik auch deswegen nicht mehr (ohne weiteres) funktioniert, weil wir in respond() einige Änderungen vorgenommen haben. Das Ganze ist mir aber für heute abend zu komplex.

[Beta-User]

Willst Du reActivateVoiceInput auch da unterbringen ?

Dazu fehlte noch eine Antwort - Jein!
Also nochmal anders erklärt: Hinter "sessionTimeout" steckt "ursprünglich" der Gedanke, jede Sitzung schlicht immer weiterzuführen, bis der darin konfigurierte timeout (nach dem letzten Input) abgelaufen ist. Also immer dann, wenn entweder ein sinnvoller input kommt (also ein Intent erkannt) oder eben "irgendwas" gesagt wurde (not recognized). "Eigentlich" auch, wenn fälschlicherweise "silence" (vor Timerablauf) erkannt wurde (da aber - soweit ich mich entsinne) dann ohne Verlängerung/Erneuerung des timeouts.

Das ganze war/ist aber wackelig und unrund (deswegen gibt es m.E. niemanden, der den Key aktiv hat ), und zwischenzeitlich glaube ich auch, die Ursache gefunden zu haben, nämlich das mit dem zu häufigen "configure" für den DialogManager/intentFilter (siehe meine bisherigen Ausführen dazu, die jetzt vielleicht doch noch irgendwie verständlich werden).

Ergo geht es jetzt darum, diese "pauschale Option" zum Laufen zu bringen, bevor wir anfangen, für eine differenziertere Funktionalität mehr/andere Keys "zu verstreuen".

Und die "korrekte" Funktionalität von "handleIntentNotRecognized()" ist m.E. das verbleibende Bausteinchen, bis wir hinter das Thema einen Haken machen können. Jetzt schaue ich mal, ob ich das mit den Kommentaren im Code hinbekomme .

PS:
Um das nachzuvollziehen vielleicht den alten Code unter https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/10_RHASSPY.pm?rev=27324 - dort "sessionTimeout" bemühen. Da führt ein gesetzter Key immer zu $delay und damit zu einer "falschen" Erneuerung des intentFilter (mit enable/disable-Angaben).

[Beta-User]

Bei continous bleibt der intentFilter erhalten, wenn der key intentFilter in $reaction nicht mitgegeben wird.

Habe eben erst die Änderung dieses Teils (nach "stimmt gar nicht") gesehen...

Vermutlich ist das schon die Ursache, warum der Code nicht funktioniert hat (=> eventuell reicht es, einfach überall vor respond auch noch den intentFilter aus $data nach $sendData zu kopieren), aber wie dem auch sei, hier mal meine kommentierte Fassung (ohne Übertrag):

Code Auswählen Erweitern

sub handleIntentNotRecognized {
    my $hash = shift // return;
    my $data = shift // return;

    Log3( $hash, 5, "[$hash->{NAME}] handleIntentNotRecognized called, input is $data->{input}" );

    my $response;
   
    # Teil 1: Umgang mit "silence", also gar kein {input}
    # Klären:
    # a) (https://forum.fhem.de/index.php?msg=1326892): müssen wir zwingend immer den intentFilter mit angeben?
    #b) brauchen wir eine Unterscheidungen nach "unmittelbar" nach (nur) dem Wakeword (b1), einer "echten Sitzung" (Info oder Bestätigung nachgefordert, b2), oder einfach einer "weiterlaufenden" Sitzung (b3, nach (z.B.) reActivateVoiceInput)
       
    if ( !$data->{input} ) { # just listened to "noise" or silence
        $data->{requestType} //= 'voice'; # we need "voice" to make sure we reopen the microphone if session is voice type
        $response = {
            text => 'SilentClosure',
            sendIntentNotRecognized => 'true',
            customData => $data->{customData}
        };
        return respond( $hash, $data, $response);  # continue session silently
    } # Ende Teil 1
   
#text-basierte Dialoge, nicht unser aktuelles Thema
    my $identity = qq($data->{sessionId});
    my $siteId = $hash->{siteId};
    my $msgdev = (split m{_${siteId}_}x, $identity,3)[0];

    if ($msgdev && $msgdev ne $identity) {
        $data->{text} = getResponse( $hash, 'NoIntentRecognized' );
        return handleTtsMsgDialog($hash,$data);
    }
# Ende text-basierte Dialoge

    #return $hash->{NAME} if !$hash->{experimental};


    my $data_old = $hash->{helper}{'.delayed'}->{$identity};

    # Teil 2: {input} ist da, es wurde also (vermutlich) was gesagt, aber der input wurde nicht als Intent erkannt (z.B. falscher Filter?)


    # Teil 2a - wir sind in einer neuen (2a1) oder "weiterlaufenden", aber "sauberen" Sitzung (z.B. nach reActivateVoiceInput, 2a2)
    if ( !defined $data_old ) {
       
        # user-definierte Sonderbehandlung hat Vorrang und ist abschließend!
        return handleCustomIntent($hash, 'intentNotRecognized', $data) if defined $hash->{helper}{custom} && defined $hash->{helper}{custom}{intentNotRecognized};
       
       
        my $entry = qq([$data->{siteId}] $data->{input});
        readingsSingleUpdate($hash, 'intentNotRecognized', $entry, 1);
        if ( defined $hash->{sessionTimeout} ) { #this might be the place to extend for "getOption" keys
            $data->{requestType} //= 'voice'; # we need "voice" to make sure we reopen the microphone if session is voice type
            $response = {
                text => getResponse( $hash, 'RetryIntent'),
                sendIntentNotRecognized => 'true',
                customData => $data->{customData}
            };
            return respond( $hash, $data, $response);  # continue listening, as $response is HASH type
           
        }
       
        $data->{requestType} //= 'text';
        return respond( $hash, $data, getResponse( $hash, 'NoIntentRecognized' ));
    }
   
    # Teil 2b - irgendwas hat mit der weiteren Eingabe nicht geklappt (könnte v.a. auch ein ganz anderer Satz gewesen sein - es ist häufig (choice!) nur ein sehr eingeschränkter intentFilter aktiv!)
    #$data_old is given, continue dialogue
    $data->{requestType} //= $data_old->{requestType} // 'voice'; # required, otherwise session open but no voice input possible
    $response = {
        text => getResponse( $hash, 'RetryIntent'),
        sendIntentNotRecognized => 'true',
        customData => $data->{customData}
    };
    respond( $hash, $data, $response); # keep session open and continue listening
    return $hash->{NAME};
}

[gregorv]

neue handleIntentNotRecognized() getestet
wieder reActivateVoiceInput und retryIntent gesetzt
kein input
  normaler Intent:

•     Wake-Word -> Geräusch -> silent continue -> Kommando -> Bestätigung -> sonst noch was? -> fertig -> OK -> Session closed                <---- OK
•     Wake-Word -> Kommando -> Bestätigung -> sonst noch was? -> Geräusch -> silent continue -> fertig -> nicht verstanden -> Session closed  <---- falsche Ansage (vmtl. intentFilter weg)

  customIntent

•     Wake-Word -> Geräusch -> silent continue -> Kommando -> Bestätigung -> fertig -> OK                        <---- OK
•     Wake-Word -> Kommando -> Bestätigung -> Geräusch -> silent continue -> fertig -> wie bitte?                <---- intentFilter weg

->> wenn Nach einem erfolgreichen Kommando der Fall kein Input auftritt, ist CancelAction nicht mehr möglich.

input != ''
  normaler Intent:

•     Wake-Word -> falsches Kommando -> nicht verstanden -> Session closed                <---- OK
•     Wake-Word -> Kommando -> Bestätigung -> sonst noch was? -> falsches Kommando -> nicht verstanden -> Session closed  <---- wenn retryIntent aktiv ist, sollte hier wenn wie bitte? kommen und die Session fortgeführt werden - künftig erst??) AUSSERDEM kommt nach sessionEnded später noch (18 sec im Log) endSession ersteres bei IntentNotRecognized, letzteres wenn der sessionTimeout abgelaufen ist - siehe IntentNotRecognized sessionTimeout.txt. Falls in der Zwischenzeit (zwischen sessionEnded und endSession) nach erneutem Wake-Word andere Kommandos gesprochen werden, ist das Ergebnis nicht nicht vorhersehbar z.B. nach einem deutlich gesprochenen Kommando wird der Choice-Intent gestartet - zumindest nach der Ansage zu urteilen - reagiert aber auf nein mit wie bitte? oder nach nicht verstanden kommt noch mal sonst noch was?

  customIntent

•     Wake-Word -> falsches Kommando -> nicht verstanden -> Session closed                <---- OK
•     Wake-Word -> Kommando -> Bestätigung -> falsches Kommando -> wie bitte? -> fertig -> wie bitte?                <---- intentFilter weg

->> wenn Nach einem erfolgreichen Kommando der Fall input != '' auftritt, ist CancelAction nicht mehr möglich.

[Beta-User]

wieder reActivateVoiceInput und retryIntent gesetzt

Das sind nach wie vor nicht die erwarteten Keys. Erwartet wird sessionTimeout im define, sonst wird die Sitzung halt einfach nach "not recognized" geschlossen.

Ansonsten ist der Code nur kommentiert, nicht irgendwie gegenüber gestern geändert. Hatte kurz angefangen mit Testen, bin aber nicht besonders weit gekommen (außer, dass die erwartete "normale" Funktionalität (=> immer neue Sitzung aufmachen) scheinbar funktioniert).

Eventuell morgen mehr, jetzt ist mein Zeitbudget dafür aus...

[gregorv]

@Beta-User
nach längeren Tests mit der letzten Version, insbesondere auch nur mit global sessionTimeout habe ich es nicht geschafft, die Dialoge so zu bekommen, wie ich es eingentlich haben will. Nach einer Session, die nur verlängert wurde z.B. um einen Rolladen anhalten, etwas höher/tiefer zu fahren sollte nicht automatisch eine neue Session starten. Auch der noch laufende Timer nach IntentNotRecognized stört und führt zu unvorhersehbaren Resultaten, wenn vor dem Ablauf eine neue Session gestartet wird. Nach vielen Versuchen das doch zum Laufen zu bringen, habe ich mich heute entschlossen, wieder auf meiner Version vom 30.11. aufzusetzen. Da funktioniert nun alles so, wie ich es  mir vorgestellt hatte - zumindest solange man nicht den globalen sessionTimeout aktiviert.
die Dokumentation habe ich auf den neuesten Stand gebracht Doku.

[Beta-User]

Hmmm, Danke erst mal für die Rückmeldung zu deinen Tests.

Ich bin die Tage leider selbst nicht wirklich zum Testen gekommen, hatte wenn, dann aber auch wieder einige seltsame Effekte.
Nach wie vor glaube ich aber, dass es möglich sein sollte, das erst mal global zufriedenstellend zum Laufen zu bekommen (vermutlich nicht so granular, wie du das im Moment hast), denn ich gehe nach wie vor davon aus, dass die Probleme eigentlich von einem grundlegenden Verständnisproblem (meinerseits) in der Interaktion zwischen Rhasspy und RHASSPY herkommen. Das muss erst sauber sein, bevor man wieder komplizierter werden darf.

Ich hoffe, am WE irgendwann sowas wie einen Vergleich unserer Versionen hinzubekommen und/oder vielleicht sogar die Probleme doch testweise besser nachvollziehen zu können, aber versprechen kann ich nichts, habe zu viel andere dringendere Baustellen...

Trotzdem eine Frage:

Nach einer Session, die nur verlängert wurde z.B. um einen Rolladen anhalten, etwas höher/tiefer zu fahren sollte nicht automatisch eine neue Session starten.

Warum nicht?
Meine Denke dazu: Der ursprüngliche Befehl ist abgearbeitet. Was danach kommt, könnte alles sein. Die Schwierigkeit liegt ggf. "nur" darin, festzustellen, was der "Bezugspunkt" des Sprechenden ist. Das ist ggf. in der Tat eine größere (programmiertechnische (und konfigurationsmäßige?)) Herausforderung.
Klar könnte man das anders wollen und dann übergangsweise nur bestimmte Intents zulassen, aber dann ist man wirklich bei CustomIntent. Oder übersehe ich was?

Inwieweit der laufende Timer in Konflikt kommt mit einer neuen session ist mir auch noch nicht klar, aber das werde ich vermutlich selbst sehen, wenn ich (endlich) mal in Ruhe zum Testen komme.

(Vielleicht kannst du noch schreiben, in welche Richtung du was modifiziert hattest, wir brauchen ja nicht doppelt dieselben Fehler machen...)