CustomIntent mit Dialog

[gregorv]

@Beta-User
Die neue Version ist prima, bis auf den Punkt cmdAny, wo Du ja noch überlegst, wie man das besser gestalten könnte - ist aber kein Problem.

Die letzten Änderungen:

Code Auswählen Erweitern

$allrooms !~ m{(?<!\p{L})$room(?:(?!\p{L})|\Z)}i und

Code Auswählen Erweitern

return [$hash->{NAME}]; habe ich noch eingebaut, letzteres allerdings, wie oben beschrieben in der respond(). Falls Du da Bedenken hast, kannst Du es ja noch in die handleIntentNotRecognized verschieben - es funktioniert ja an beiden Stellen, an letzterer halt nur für IntentNotRecognized.

Gelöscht habe ich noch den Kommentar: # Vorschlag GV: my $reaction... das war in der Tat ein Überbleibsel, weil ich erst das undef als 3. Argument bei Aufruf der respond()  vermeiden wollte. Später war mir das zu riskant, weil es ja sein könnte, dass jemand als response Argument ein hash übergeben könnte UND ein timeout Argument. Offenbar gibt es solche Fälle aber nicht, weil Du den Code so geändert, dass timeout und response definitv vom hash kommen, falls respone ein hash ist und diese Werte da geliefert werden.

Anmerkung:
ich hatte noch einen Schalter vorgesehen, mit dem man die WieBitte Funktion abschalten kann, sodass zwar der Dialog offen blebt aber die nächste Erkennung den Dialog beendet:

Code Auswählen Erweitern

if ( defined $data_old->{what} ) {...s.a. what - der muss nicht sein, aber Du hattest so etwas erwähnt, wenn ich richtig gelesen hatte.

Ich habe zwei Versionen angehängt, eine mit nur den drei Änderungen und eine, mit zusätzlichen Kommentaren, Links zu den entsprechenden Beiträgen in diesem Thread (alles mit @@@ markiert).

Ich finde, die Zusammenarbeit funktioniert hervorragend und macht Spass.
Mal sehen, was ich sonst noch so (er)finde.

Was hälst Du davon, wenn ich im ersten Post mal eine Zusammenstellung(Beschreibung der neuen Möglichkeiten einbaue - Mit Hinweisen auf die gefundenen Rhasspy Problemchen?
Gruß
Gregor

Danke, Gregor

[Beta-User]

Ich finde, die Zusammenarbeit funktioniert hervorragend und macht Spass.

Kann mich dem nur anschließen, Danke! Wobei du die Hauptarbeit machst ...

wo Du ja noch überlegst, wie man das besser gestalten könnte

Ich meine mich entsinnen zu können, dass ich um Tests gebeten habe, ob nicht ein rhasspyMapping dasselbe bewirken würde .

der muss nicht sein,

Beim drüber nachdenken bin ich dann auch irgendwann zu dem Schluss gekommen. Falls wir da doch einen "Hosenträger" brauchen, können wir ihn immer noch einbauen, wobei das ggf. auch der "experimental"-Schalter sein könnte - je nachdem, wie tatsächlich die Problemlage bei einer Mehrzahl von Usern ggf. ist => ich würde das erst mal ohne Sicherung einchecken, die Warnung ist ja raus .

Was hälst Du davon, wenn ich im ersten Post mal eine Zusammenstellung(Beschreibung der neuen Möglichkeiten einbaue - Mit Hinweisen auf die gefundenen Rhasspy Problemchen?

Doku ist prinzipiell immer eine gute Idee - ich habe daher (eigentlich schon immer) versucht, die commandref jeweils mit zu aktualisieren. Ggf. könnte man das auch direkt im Wiki irgendwie verwursteln? Darfst gerne einen Zugang beantragen und in "meinen" Artikeln ergänzen (oder korrigieren, wenn dir was auffällt).

Ansonsten wäre ggf. auch der "0.5"-Thread kein schlechter Ort für eine Zusammenfassung? As you like!

Code schaue ich mir frühestens morgen an, wollte v.a. nochmal auf den ausstehenden rhasspyMapping-Test hinweisen .

[gregorv]

auf den ausstehenden rhasspyMapping-Test hinweisen

Oh, hatte ich vergessen zu erwähnen. Der Wunsch war ja, dass im sentence solche Dinge, wie An,Aus,Auf,Zu in value schreiben wollte.
Das kommt ja in der handleIntentSetOnOffGroup() an. Im rhasspyMapping muss man das sozusagen noch mal bestätigen cmdOn=Zu und cmdOff=Auf, aber bei:

Code Auswählen Erweitern

$cmd = $value eq 'on' ? $cmdOn : $cmdOff gehts dann aber schief, da $value eben nicht on ist. Laut Doku kann man für SetOnOff auch nur on oder off verwenden und an der Stelle sieht man den Grund - das einzige was da durchkommt ist der Wert von cmdOff, das Auf.
Auf das cmdAny und die Zeile

Code Auswählen Erweitern

my $cmdAny = $mapping->{cmdAny} // $value;kann man natürlich verzichten - ein Mapping dafür wäre ohnehin recht sinnfrei.
Die Änderung jetzigen Codezeile oben (mit eq 'on')zu:

Code Auswählen Erweitern

        if ( $value eq 'on' ) { $cmd = $cmdOn;
        }elsif ( $value eq 'off' ) { $cmd = $cmdOff;
        }else { $cmd = $value; }
Also auf on oder off prüfen und sonst kein Mapping.
Da käme dann natürlich alles durch, also auch stop oder pos x, aber ich meine, das schadet ja nicht.

Ich hab zur Sicherheit noch mal in die getMapping() und in das hash geschaut und dabei erstaunt festgestellt, dass da die default Mappings so stehen, wie ich es mit meinem eventMap konfiguriert habe - ist ja wirklich intelligent. Ich hätte gewettet, dass da nur die Standard Befehle für ein Device drin stehen.

Falls Du es noch einbauen willst, bitte auch bei handleIntentSetOnOff(), sonst wäre es inkonsistent (nach meinem Bauchgefühl).

der "0.5"-Thread kein schlechter Ort

Das hört sich gut an, mach ich da mal zuerst.

Gruß
Gregor

[Beta-User]

Ich hab zur Sicherheit noch mal in die getMapping() und in das hash geschaut und dabei erstaunt festgestellt, dass da die default Mappings so stehen, wie ich es mit meinem eventMap konfiguriert habe - ist ja wirklich intelligent. Ich hätte gewettet, dass da nur die Standard Befehle für ein Device drin stehen.

Demnach müßte dein Rollladen ja komplett funktionieren (ganz ohne weitere Anpassung...), wenn du es machst wie in der Doku beschrieben  und eben "on" oder "off" in deinen sentences übergibst, oder?

Mein Punkt ist der:

Da käme dann natürlich alles durch, also auch stop oder pos x, aber ich meine, das schadet ja nicht.

Genau da bin ich - nach meinen bisherigen support-Erfahrungen - anderer Meinung. Es gibt nämlich auf der Strecke zwischen Rhasspy und FHEM-Devices so viele Stellen, wo man irgendwas anders machen könnte (und früher teils auch konnte!), und genau das machen dann die User: Sie konfigurieren "irgendwas", sagen es aber nicht explizit (meist, weil sie nicht wissen, dass das wichtig wäre), und man (=meinereiner) "sucht sich den Wolf" im Code. Also weiter: Wenn es so funktioniert wie in der Anleitung beschrieben, ändern wir nichts im Code und verstecken keine features, die "jemandem" irgendwann auf die Füße fallen können . Wer was (für einzelne Devices) "umbiegen" muss, soll das in rhasspyMapping machen. Da kann man alles mögliche verwursteln, wenn ich es richtig im Kopf habe .

Oh, hatte ich vergessen zu erwähnen. Der Wunsch war ja, dass im sentence solche Dinge, wie An,Aus,Auf,Zu in value schreiben wollte.

Das mit dem Wunsch hatte ich schon verstanden, den Code mit $mapping->{cmdAny} nicht. Meine "Vorgabe" damals (bei der Umsetzung der "Sprach-Agnostik") an alle User war: Stellt eure onOff-intents so um, dass genau nur on und off als Befehle kommen. Vorher war das (gefühlt) ein nicht handhabbarer Wildwuchs .

Das einzige Argument, das man ins Feld führen könnte, wären ggf. "sprachliche Ähnlichkeiten", wenn also Rhasspy nicht zuverlässig erkennen würde, was gewünscht ist, weil die Sätze zu ähnlich sind. Dann würde ich aber eher dazu tendieren, andere Keys zu verwenden, um einen absichtlichen Intent-Wechsel in RHASSPY vorzunehmen. Sowas kann man dann im log leichter nachvollziehen . Allerdings: Bisher hat kein User Bedarf in diese Richtung angemeldet .

PS: Hab's nicht nochmal im Code nachvollzogen, aber "eigentlich" sollte auch setNumeric einheitlich für FS20 und den Rest funktionieren, wenn klar ist, wo "oben" und "unten" ist. Da einfach auch die Ausgaben von getMapping vergleichen und ggf. anpassen.

[Beta-User]

Bin nochmal über den Code drüber und habe noch das eine oder andere gefunden, was mir "anders logischer" vorgekommen ist, v.a. was die return-Werte/Array-Geschichte angeht.

Bin geneigt, das einzuchecken, komme allerdings heute voraussichtlich nicht mehr zum Testen.

diff ist wieder beigefügt zwecks besserem Überblick über die Änderungen.

[gregorv]

@ Beta-User

Demnach müßte dein Rollladen ja komplett funktionieren (ganz ohne weitere Anpassung...), w

Das ist korrekt.

...Stellen, wo man irgendwas anders machen könnte (und früher teils auch konnte!),

Ha, jetzt hab ich Dich erwischt   Das Übergeben beliebiger Values funktioniert ja noch heute - eben nur bei cmdOff:

Code Auswählen Erweitern

$cmd = $value eq 'on' ? $cmdOn : $cmdOffAber im Ernst, ich sehe den Punkt. Ich hatte Überlegt ob beim Check auf on nicht eventuell auf ein Element in einer Liste prüft, die man aus dem language file unter z.B SetOnOff->ValidForOn {on|An|Zu,...} holen könnte...
Aber egal ich mach das Mapping von An zu on in meiner Blinds(), damit handleIntentSetOnOffGroup zufrieden ist (falls Du wg. meiner Anmerkung oben auch auf off-Prüfung umstellst, kann ich cmdOff im Custom Intent natürlich auch mappen).

Code Auswählen Erweitern

aber "eigentlich" sollte auch setNumericDa hatte ich auch schon dran gedacht, aber bin ich noch nicht ganz durchgestiegen - das Andere schien mir erst mal einfacher.

Die neue Version werde ich gleich mal testen, ich hatte bisher nur mal in die diff geschaut und sehe den key $data->{SilentClosure} aber auch noch $data->{noResponse}

[Beta-User]

Das Übergeben beliebiger Values funktioniert ja noch heute - eben nur bei cmdOff:

? Wenn es ein passendes (implizites oder explizites) rhasspyMapping gibt, funktionieren alle (im Prinzip denkbaren) Befehle, jeweils für cmdOn und cmdOff. Ohne eben nicht bzw. ohne gültigen "value" es ist eben dann immer das, was auf "off" gemappt ist.

Aber im Ernst, ich sehe den Punkt. Ich hatte Überlegt ob beim Check auf on nicht eventuell auf ein Element in einer Liste prüft, die man aus dem language file unter z.B SetOnOff->ValidForOn {on|An|Zu,...} holen könnte...

Im Ernst: Ich will wirklich bei dem simplen Prinzip bleiben, also: "Wer mappt, soll halt mappen, aber dann an beiden Enden." (also eventMap und rhasspyMapping). Der OnOff-Intent ist der "Einsteiger-Intent", und da ist es m.E. zwingend, dass man nicht zu viele Möglichkeiten schafft (die dann schiefgehen können), sondern den Pfad ganz geradlinig durchläuft. Ich kann jedenfalls keinen Mehrwert erkennen, wenn man dem User nicht klar macht, dass er eben "standardisierte" Werte (hier: on/off) zu übergeben hat. Ist ja bei "rot" und "grün" auch nicht anders: Da braucht es Farbkreiswerte (oder rgb). Ist immer dasselbe, also KISS.

Da hatte ich auch schon dran gedacht, aber bin ich noch nicht ganz durchgestiegen - das Andere schien mir erst mal einfacher.

Müßte auch suchen, wie das im Detail ist. Vermutlich steht dazu was im Wiki... Jedenfalls rechnet RHASSPY bei allen diesen Anweisungen (auch bei den HUE-Color-Dingen) immer ausgehend von dem, was das Device an Spanne kann und ermittelt daraus den Zielwert. Scheint zu funktionieren, jedenfalls wäre mir keine diesbezügliche Beschwerde bekannt (oder es haben alle 100%=offen-Type Rollläden?!?).

Die neue Version werde ich gleich mal testen, ich hatte bisher nur mal in die diff geschaut und sehe den key $data->{SilentClosure} aber auch noch $data->{noResponse}

Ich meine, diese Unterscheidung absichtlich gelassen zu haben; irgendwas war da auch in der Kommunikation zu Rhasspy unterschiedlich... (gelegentlich sollte man die Doku in der Demo anpassen, wenn beide Optionen so bleiben).
 

 

[gregorv]

? Wenn es ein passendes (implizites oder explizites) rhasspyMapping gibt, funktionieren

Das war nicht ganz, was ich meinte - es funktioniert mit der gegewärtigen Prüfung in der handleIntentSetOnOff()/Group() ein sentence wie dieser:

Code Auswählen Erweitern

\[bitte] [(mach|mache|schalte|schalt)] [<den>] $de.fhem.Device{Device} [<rooms>] ( (an|ein|einschalten){Value:on} | (aus|ausschalten){Value:AUS} )also AUS statt off - eben alles, was nicht on ist, ist gültig für off. In handleIntentSetOnOff...() wird es dann zu off, oder was anderem, wenn es ein Mapping gibt.

[Beta-User]

es funktioniert mit der gegewärtigen Prüfung in der handleIntentSetOnOff()/Group() ein sentence wie dieser:

Code Auswählen Erweitern

\[bitte] [(mach|mache|schalte|schalt)] [<den>] $de.fhem.Device{Device} [<rooms>] ( (an|ein|einschalten){Value:on} | (aus|ausschalten){Value:AUS} )

Na ja, das sieht mir schon fast wie ein "absichtlicher Fehler" aus ... Im Moment sehe ich keine Veranlassung, da auch noch eine explizite Gültigkeitsprüfung einzubauen (mit der Konseqenz,  den User auf den Fehler hinzuweisen ). Dein "AUS" wird im Moment halt einfach ausgefiltert bzw. ignoriert, gemacht wird halt "das Gegenteil von Einschalten". Kommt mir weiter logisch vor...

Ist ja bei "Bestätigen" auch so: alles, was nicht "OK" ist, bedeutet "abbrechen".

[gregorv]

Ich meine, diese Unterscheidung absichtlich gelassen zu haben

Ich habe mir das angesehen und festgestellt, dass es gestern schon drin war, aber mir nicht aufgefallen ist. Ist aber OK.

Dabei bin ich über das neue Codestück in der response gestolpert:

Code Auswählen Erweitern

    #new reopen or sessionTimeout variant: Close the old session and reopen a new one:
    if ( $topic ne 'continueSession' && $type eq 'voice' && ( defined $data->{reopenVoiceInput} || defined $hash->{sessionTimeout} ) ) {
        activateVoiceInput($hash,[$data->{siteId}]);
        $delay = ReadingsNum($name, "sessionTimeout_$data->{siteId}", $hash->{sessionTimeout} // _getDialogueTimeout($hash));
        $delay = $data->{SilentClosure};// if defined $data->{SilentClosure} &&     looks_like_number($data->{SilentClosure});
        resetRegIntTimer( 'testmode_end', time + $delay, \&RHASSPY_testmode_timeout, $hash ); #Beta-User: needs different timeout function
    }
Sieht mir ähnlich aus, wie mit dem resetInput, allerdings hier durch den response() Aufruf und dass da ein spezifischer sessionTimeout eingestellt werde kann.
Was für ein Anwendungsfall steckt hinter reopenVoiceInput?

Die ersten Tests sind alle erfolgreich. Geht aber noch weiter.

Ich denke mal bis 18:00 habe ich die Version soweit getestet, dass sie bereitgestellt werden kann.

[Beta-User]

Sieht mir ähnlich aus, wie mit dem resetInput, allerdings hier durch den response() Aufruf und dass da ein spezifischer sessionTimeout eingestellt werde kann.

resetInput wirkt global.

Bei meiner letzten Runde der Befassung mit RHASSPY war ich bei "kontinuierliche Eingabe-Optionen" stecken geblieben und habe das dann auch nicht weiter vertieft, u.a. auch, weil es niemanden sonst interessiert hatte. Jetzt bis du gekommen und hattest ein ähnliches Thema - nur halt beschränkt auf einen bestimmten Anwendungfall. Bei der Durchsicht des Codes ist mir dann aufgegangen, dass ich einen grundsätzlichen Denkfehler drin hatte: Wenn man einen echten Dialog hat, muss man sich Dinge merken. Nicht aber, wenn man einfach das Thema wechseln (können) will... Dann muss man einfach "alles auf Anfang" stellen und das Mikro wieder einschalten. Genau das soll (irgendwann mal) dann das Ergebnis dieser Codestelle hier sein. Daher der Pseudo-Aufruf von RHASSPY_testmode_timeout() am timer-Ende. Da muss was hin, das einfach unauffällig das Mikro wieder schließt, wenn man nichts gesagt hat.

Danke für's testen, bei mir im log waren noch ein paar "uninitialized"-Warnings für split (=> Vorbelegung mit "nichts"=q{}), dahingehend überarbeitete Fassung anbei.

[gregorv]

kontinuierliche Eingabe-Optionen...

Das hört sich gut an, da grübel ich auch noch. Eine Möglichkeit könnte sein dass man schon bei Start einen Dialog öffnet und das Wake Word über STT erkannt, nur noch alle Intents scharf schaltet - dann wird man das Porcupine o.äh. los. Passiert längere Zeit nichts, werden alle Intents gesperrt, außer dem Wake Word.
Den Dialog neu Starten nach Intent Bearbeitung ist schon mal gut. Man könnte einen Dialog auch neu Starten nach Ablauf des Timeout - und dann nur den Wake Word Intent aktivieren.
Ein Problem sehe ich allerdings einmal in Rhasspy und einmal bei Satteliten.
Bei Rhasspy kommt irgendwann der dort eingestellte Timeout (hab den Max.Wert immer noch nicht herausgefunden) dummerweise kommt der nicht als Timeout sondern als IntentNotRecognized. Soweit ich gesehen habe, kann man den nicht von den 'normalen' IntentNotRecognized unterscheiden.
Bei Satelliten müste Audio die ganze Zeit auf Sendung sein. Das kann man zwar steuern, aber macht bei vielen Satteliten das LAN/WiFi dicht. Deshalb will ich meinen Satelliten so umbauen, dass er bei Stille nichts sendet. Alle komerziellen tun das aber - zumindest soweit ich weiß, außer wenn die Wake Word Erkennung im Satelliten selbst ist.
Was man auch untersuchen müsste, wäre, wie das den Rhasspy Server belastet, wenn 4-10 Dialoge offen sind - falls der das überhaupt kann.
ist schon noch was zu forschen...

Die neue Version habe ich aktiviert und teste weiter.

Danke Gregor

[Beta-User]

Das war etwas anders gemeint:
Wakeword (oder "Knopf") => Rhasspy lauscht, was man haben möchte
Intent wird erkannt => FHEM führt das aus
NEU: Mikro wird ggf. wieder eingeschaltet (über den key im define oder über eine Einzelanweisung im CustomIntent; für letzteres ist der neue key gedacht!)
Dann überwacht FHEM einen timout und macht das Mikro wieder zu, wenn man Rhasspy nichts mehr zu sagen hat...

Dazwischen könnte man sowas machen wie die Ansage: "Sonst noch was?"

Es wird also nichts grundsätzliches am Ablauf verändert, außer, dass man eben hintereinander mehrere Einzelanweisungen absetzen kann, ohne Rhasspy jedes Mal explizit aufzurufen. That's all...

Ansonsten kann Rhasspy vermutlich viele Dialoge offen halten, das "Problem" dürfte eher sein, ggf. parallel viele Audiodaten auszuwerten mit dem STT-Modul. Text in Intent umzuwandeln dürfte dagegen kaum Rechenleistung erfordern und geht imo auch deutlich schneller wie man sprechen kann.

[gregorv]

NEU: Mikro wird ggf. wieder eingeschaltet

Das ist auch schon super.

Danke für die Info, Tests laufen gut.

Erweitere gerade meine Blinds() und da ich eher der Try& Error Typ bin fallen da noch irre viele Tests an.
Und die Erfahrungen wachsen auch, heute z.B. dass die erforderlichen 'muss' Wörter im sentence nicht zu knapp gehalten werden sollten. Eben habe ich mir ein regelrechtes Wortgefecht mit meiner Roberta geliefert, als ich knapp sage: Licht an und sie keck antwortet das Licht ist an - beim 3. Versuch musste ich dann doch etwas deutlicher werden: mach das Licht an!. Da hat sie dann mit einem gelangweilten OK nachgegeben.

Gruß
Gregor

[Beta-User]

Danke für die Info, Tests laufen gut.

Thx für die Rückmeldung, habe die Version zwischenzeitlich eingecheckt.

Erweitere gerade meine Blinds() und da ich eher der Try& Error Typ bin fallen da noch irre viele Tests an.

Apropos Tests: Testsuite für Sprachsteuerung und [RHASSPY] - Einstellungen optimieren mit Hilfe der Testsuite kennst du?

Und die Erfahrungen wachsen auch, heute z.B. dass die erforderlichen 'muss' Wörter im sentence nicht zu knapp gehalten werden sollten. Eben habe ich mir ein regelrechtes Wortgefecht mit meiner Roberta geliefert, als ich knapp sage: Licht an und sie keck antwortet das Licht ist an - beim 3. Versuch musste ich dann doch etwas deutlicher werden: mach das Licht an!. Da hat sie dann mit einem gelangweilten OK nachgegeben.

Hatte eigentlich gedacht, dass es einen thread gäbe mit "best practices" zu RHASSPY, in dem ein gewisser Erfahrungsaustausch zu solchen (allgemeinen) Themen gäbe, aber anscheinend habe ich den entweder nicht angefangen oder finde ihn nicht mehr...
Mal ein aktualisierter Zwischenstand:

Aber bevor wir darüber diskutieren, sollten wir m.E. mal definieren, wie wir vorgehen wollen. Mein Vorschlag:
- Das mit "resetInput" fertig machen und einchecken. Dazu müßte man m.E. die angehängten Dateien checken, ob das Zusammenspiel soweit paßt, dass bisherige User keine Probleme haben.
- Danach könnte man sich mit einem globalen (sentences-) Key für "führe den Dialog weiter" befassen. Ziel auch hier: Zwischenversion einchecken.
- Dann eventuell checken, ob man "specials" findet (Zwischenversion...)
- zuletzt wäre das mit myUtils dran.

Den globalen key zum zweiten Punkt gibt es jetzt, vermutlich macht RHASSPY auch das Mikro wieder auf. Was fehlt ist das "saubere Ende" nach timeout (und ggf. der Check, wie lange der timeout sein soll).

Für myUtils fehlt m.E. (fast nur?) noch etwas Doku zu den neuen bzw. geänderten keys in $response. Ansonsten fehlt in handleCustomIntent noch eine Verzweigung für den neuen "reopenVoiceInput"-Key. Da frage ich mich grade, ob man eine sessionId vergeben sollte, damit man ggf. auch den (session-) IntentFilter gleich setzen kann. Aber das ist im Moment noch "terra incognita", und für Tests fehlt mir die Zeit. (Hoffe, das überhaupt verständlich formuliert zu haben).