CustomIntent mit Dialog

[gregorv]

rasppySpezials ein customData

Das würde mich auch interessieren - eventuell auch die anderen Optionen, die beim CustomIntent im return hash möglich sind?
@Jens

Sorry, wo genau?

Ist eben erst als Beta angehängt zum Testen.

[Beta-User]

@Beta-User
MEIN ENTWURF

Thx, hoffe, ich komme dazu, mir das zeitnah mal näher anzusehen. Falls du je ein unified diff zu meiner letzten Version von hier und zur "offiziellen" machen könntest, wäre das ggf. hilfreich, dann kann ich ggf. meine Kommentare in das diff reinfrickeln?
Ich habe den Verdacht, dass da ggf. auch was an den kleinen Änderungen verloren gegangen war, die in meiner letzten Version drinne waren*.

@Beta-User
Gibt's eine Möglichkeit in rasppySpezials ein customData mitzuschicken?

Ich habe vermutlich die Frage nicht verstanden...

Anmerkungen zu customData:
- lt. Definition ist es flacher Text, was anderes geht ja auch per MQTT nicht über den Äther...
- Man _könnte_ ggf. jede Art Daten da mitsenden, wenn man sie serialisiert (z.B. mit toJSON).
- Dunkle Erinnerung sagt mir: Ich habe mich damals dagegen entschieden, alles mögliche Ein- und wieder Auszupacken und das Ganze stattdessen so konzipiert, dass halt mit jedem Satelliten parallel immer nur ein Dialog laufen kann (?). Das hat den Vorteil, dass man intern (über ~ identifier und oldData) alles mögliche unkompliziert zwischenspeichern kann. Es ist nur nicht wirklich dokumentiert, was man damit in myUtils-Code anstellen könnte.
Aber an der Stelle könnte man z.B. auch die Info speichern, ob "wiebitte?" schon (x) mal durchlaufen war.

*Generell würde ich gerne ggf. eine "ungefährliche" Version als Zwischenversion (mit cfg und myUtils) einchecken, damit wir nicht zu viele Änderungen gleichzeitig nachziehen müssen, wenn wir jetzt weiter feilen.
PS: Es sollte alles unfallfrei durch perlcritic (onlne: http://perlcritic.com/) auf Stufe 3 laufen. Vermutlich muss dann "use constant" durch readonly ersetzt werden (wenn man die Werte überhaupt zentral braucht).

[Beta-User]

Hab mir nochmal session_timeout angeschaut und keine Möglichkeit zur Änderung während der Laufzeit gefunden.

Thx für die Analyse.

Prinzipiell gehe ich nicht davon aus, dass synesthesiam noch irgendwas an Rhasspy 2.x schrauben wird, und wir wenn, dann eher den update auf 3.x in FHEM nachziehen müssen (das wird dann aber vermutlich was größeres, da weg von MQTT).

Es bleibt daher erst mal bei dem, was gregorv angemerkt hatte: Man muss halt (wenn in Verwendung) in Kaldi den Wert dauerhauft anpassen, wenn man längere Werte haben will.

[Beta-User]

Test ABBRUCH!
In der Modulversion verschwinden offenbar session data - nach längerer Suchzeit habe ich aufgegeben.

Habe vermutlich noch nicht alles verstanden, was da passiert. Vermutlich ist da irgendeine Schleife drin und/oder der Rhasspy-timeout schlägt dann doch irgendwann zu?

Vielleicht noch was zu "IntentNotRecognized":

Allgemein wird das auch ausgegeben, wenn ein Intent an sich erkannt werden würde, aber dieser grade deaktiviert ist. Von daher müßte auch was im "input"-Feld zu finden sein, wenn es einer dieser "bekannten Sätze" war?

Vielleicht könnte man das auch nutzen, wenn eine Sitzung offen ist und "Schleifengefahr" zu bannen ist?

Und: Zu kurze Sätze sollte man m.E. vermeiden, weil sonst die große Gefahr besteht, dass Geräusche usw. als Eingabe missverstanden werden. Irgendwo müßte aus diesem Grund die Empfehlung zu finden sein, dass der kürzeste mögliche Satz "Nein" (oder so) sein sollte, damit im Zweifel "CancelAction" durchlaufen wird und alles resettet wird...

[gregorv]

@Beta-User,

die von mir gesandte Version basiert auf der Original-Version. Da habe ich meine Änderungen und anschließend Deine Änderungen nach und nach eingebaut und zwischendrin getestet. Die von Deinen Änderungen, die zu Fehlfunktionen (@@@@) geführt haben sind auskommentiert, aber alle drin. Ein anschließender compare zeigt nur noch die @@@@ Stellen und die Funktionserweiterungen, @@@ die in Deiner Version noch nicht drin waren.

Ich schick Dir aber noch ein unified diff.Sowas habe ich aber noch nie als Datei benötigt und bräuchte ich einen Tipp, womit man das macht. Google zeigt ja viele Möglichkeiten, aber Du möchtest ja sicher ein bestimmtes Datei-Format.

http://perlcritic.com

mault tatsächlich über die Verwendung von use constant und das wäre auch unabhängig davon, ob das global oder in einer sub plaziert wird. Grund: es funktioniert nicht, wenn es in Gänsefüßchen verwendet wird - in einem Log3 z.B. Eigentlich wollte ich aber explizit solche #defines haben, die nicht wie eine Variable aussehen und global sollten die auch sein.

Ansonsten gibt es nur zwei Stelllen, bei denen ich eine Variable mit my innerhalb einer condition definiere - das kommt sicher, weil ich viel mit Arduino und ESP mache, wo jedes Bit zählt), ach ja, und Tonnen von too complex Meldungen, die aber schon vorher da gewesen sein müssen.

Vielleicht noch was zu "IntentNotRecognized":

Das wäre interressant - wiebitte? muss ja nicht kommen, wenn es nur ein Geräusch war - das schau ich mir mal genauer an. Im input habe ich bisher nur sinnlose Worte gesehen.

Und: Zu kurze Sätze sollte man m.E. vermeiden ...

Ja, das ist korrekt. Ich habe viel mit den Kaldi settings 'Speech Before:', 'Minimum Duration:' ... herumgespielt bevor mein Feuerzeug nicht mehr als Eingabe erkannt wurde und ja, Nein . trotzdem funktioniert.

offen ist und "Schleifengefahr" zu bannen

In der (Test-)Praxis hat das bisher nicht gestört, kam da recht selten vor - zumindest wäre m.E ein Zähler nicht erforderlich, schon gar nicht, wenn man Geräusche noch ausfiltern könnte. Wenn ich es gezielt das wieBitte? so oft, wie möglich hören wollte, habe ich es innerhalb von 21 Sekunden nur 4-5 mal geschafft.

Frage:
Weißt Du, wie lang der Timeout (von fhem) sein kann ?

Gruß
Gregor

[gregorv]

Noch was vergessen:

der Rhasspy-timeout schlägt dann doch irgendwann zu?

Das wäre kein Problem - kommt ja IntentNotRecogized, was mit wieBitte? quittiert wird.

Und noch zur Frage von Jens (und mir) bzgl. der customData:
Bei CustomIntents kann man die ja im Code als return Wert anhängen - geht das eventuell auch bei anderen Intents z.B SetOnOff durch irgendwelch Kniffe (RhasspySpecials oder so)?

[Beta-User]

Ich schick Dir aber noch ein unified diff. Sowas habe ich aber noch nie als Datei benötigt und bräuchte ich einen Tipp, womit man das macht.

Kommt auf's Umfeld an, unter Linux einfach in eine Datei umleiten. notepad++ sollte auch diff ausgeben können, da habe ich das aber bisher nie gemacht. Das sind am Ende simple text-Files, kann man als txt kennzeichnen oder z.B. als .patch. Ist egal .

Eigentlich wollte ich aber explizit solche #defines haben, die nicht wie eine Variable aussehen und global sollten die auch sein.

Das ist C-Style und da auch völlig ok. Für Perl heißt das Stichwort "Readonly", was nichts anderes sind wie normale Variablen, nur halt nicht änderbar.

Ansonsten gibt es nur zwei Stelllen, bei denen ich eine Variable mit my innerhalb einer condition definiere - das kommt sicher, weil ich viel mit Arduino und ESP mache, wo jedes Bit zählt), ach ja, und Tonnen von too complex Meldungen, die aber schon vorher da gewesen sein müssen.

M.E. sind die Definitionen innerhalb einer Condition immer ein Fehler, den man halt in C/C++ nicht machen kann, weil die Deklaration einer Variablen (samt Type) zwingend vorab erfolgen muss...
"Too complex" läßt sich leider kaum verhindern, der Code ist schon einigermaßen refactored, das war früher noch viel übler ...

Im input habe ich bisher nur sinnlose Worte gesehen.

Habe den Teil bisher nicht angesehen, aber bei nochmaligem Nachdenken den Verdacht, dass es ggf. auch von der STT-Engine abhängt und es von daher ggf. gefährlich sein könnte, irgendwas von dieser Info abhängig zu machen.

Weißt Du, wie lang der Timeout (von fhem) sein kann ?

Im Prinzip beliebig. Er wird aber afair jedesmal erneuert, wenn eine Antwort gesendet wird, von daher weiß ich nicht, ob das "innerhalb 21 Sekunden" die "korrekte Denke" zu dem Thema ist (muss ggf. selbst nochmal in den Code sehen).

Bei CustomIntents kann man die ja im Code als return Wert anhängen - geht das eventuell auch bei anderen Intents z.B SetOnOff durch irgendwelch Kniffe (RhasspySpecials oder so)?

Soweit ich mich entsinne, spielt sonst "customData" keine Rolle und mir wäre auch nicht klar, für was man das benötigen würde. Wie vorhin geschrieben: RHASSPY ist an der Stelle anders gestrickt, mutmaßlich hatte ich Schwierigkeiten mit (von Rhasspy geänderten?) customData, weiß es aber auch nicht mehr genau...

Wenn ihr eigenen Code schreibt, wäre es m.E. zielführender, die Identifizierungsmerkmale aus oldData zu holen, wie z.B. das in ConfirmAction vercodet ist.

[gregorv]

Angehängt die diffs:
10_RHASSPY.pm release-Beta-User.txt offizielles Release zu Deiner Version 11.10.2024
10_RHASSPY.pm Beta-User-Gregor.txt Deine Version 11.10.2024 zu meiner Version 13.10.2024
10_RHASSPY.pm release-Gregor.txt offizielles Release zu meiner Version 13.10.2024

[gregorv]

Soweit ich mich entsinne, spielt sonst "customData" keine Rolle

Noch nicht! - ich hatte zumindest daran gedacht mit vorhandenen fhem Bordmitteln beim Device sowas wie "what"=>"true" anzuhängen um damit ggf. die wieBitte? Funktion auch für 'nicht-CustomIntents' nutzen zu können.

[Beta-User]

10_RHASSPY.pm release-Beta-User.txt offizielles Release zu Deiner Version 11.10.2024

Thx, dachte mir schon, dass die Zwischenversion vom 12. untergegangen war. Bin jetzt aber zuhause und kann selbst diffs machen.

Frage zu den Keys im define: Welchen Sinn machen die? Wenn es nur darum geht, zusätzliche Infos an der RHASSPY-Instanz unterzubringen, würde ich das lieber über setreading oder userAttr lösen wollen.

Feedback zu den Commandref-Aktualisierungen und Anmerkungen in der myUtils wären auch willkommen, wobei ich mir mit dem customData-Ding schon wieder nicht sicher bin, ob das wirklich funktioniert und man nicht besser empfehlen sollte, die oldData-Referenz unterhalb $hash->{helper} zu verwenden...

Was neue Keys in der language-cfg angeht, wäre meine Bitte, sowas künftig gleich "ordentlich" mit zu pflegen, also ein etwas weniger lässiges "Wie Bitte?" bei den Sätzen oben (nicht "user") reinzumachen - jedenfalls dann, wenn es wie hier einigermaßen wahrscheinlich ist, dass der key auf die eine oder andere Weise kommt.
Mal sehen, ob ich es schaffe, einen Satz an eincheckbaren Dateien zeitnah hier einzustellen (zum Testen).

Noch nicht! - ich hatte zumindest daran gedacht mit vorhandenen fhem Bordmitteln beim Device sowas wie "what"=>"true" anzuhängen um damit ggf. die wieBitte? Funktion auch für 'nicht-CustomIntents' nutzen zu können.

Hmmm, bin mal gespannt, wie das aussehen soll. Die hartcodierten Intents fangen jedenfalls afair nichts mit den Infos aus customData an, und im Moment sehe ich auch nicht, dass es an sowas fehlt.

[JensS]

Prinzipiell gehe ich nicht davon aus, dass synesthesiam noch irgendwas an Rhasspy 2.x schrauben wird, und wir wenn, dann eher den update auf 3.x in FHEM nachziehen müssen (das wird dann aber vermutlich was größeres, da weg von MQTT).

Bin mir sicher, dass 3.x nicht der Renner ist .   
Meine Idee ist, für die 2.x ein paar modifizierte Dateien inkl. Installationsanleitung zur Verfügung zu stellen.
Deaktivierte Intents und Neustartinfo per MQTT könnten z.B. auch mit rein.

Gruß Jens

[gregorv]

Bin mir sicher, dass 3.x nicht der Renner ist .

das sehe ich genau so - ist seit langer Zeit nur eingeschränkt funktionsfähig   

[gregorv]

Thx, dachte mir schon, dass die Zwischenversion vom 12. untergegangen

Oh, sorry, das habe ich tatsächlich nicht gesehen.

Frage zu den Keys im define: Welchen Sinn machen die?

Damit soll man die Audio Ausgabe allgemein für ein oder mehrere Resultat(e) einstellen können und es ergibt selbstsprechenden Code z.B. '

Code Auswählen Erweitern

if defined silent && silent & CancelSilent ...Im return hash beim CustomIntent übergibt man z.B.

Code Auswählen Erweitern

'... , "silent" => '.CancelSilent + TimeoutSilent.', ... '. Das 'use constant' Problem bei Perl ist bei #define in C übrigens auch da, nur kenne ich keinen, der das als Problem sieht.

Bitte, sowas künftig gleich "ordentlich" mit zu pflegen

ist oben schon ganz gesittet drin  und JA, kannst Du beliebig umformulieren, sollte nur kurz sein (also nicht wie oben - sonst ist der Rolladen schon unten bevor man Stop sagen kann

setreading oder userAttr lösen wollen

gute Idee! daran hatte ich noch gar nicht gedacht (obwohl ich selbst schon $timeout = AttrNum($name,'drive-up-time-to-open', 30); im CustomIntent verwende

unterhalb $hash->{helper}

kann man da durch irgendwelche settings am fhem device Infos reinschreiben?

[gregorv]

Noch zu setDialogTimeout:
wenn der timeout gesetzt ist, bleibt er erhalten, egal wie viele Antworten kommen.
Nur ein neues setDialogTimeout startet den timeout neu oder eine neue session wird gestartet.
Beispiel: Rhaspy wartet auf Stop und man sagt das hotword. Dann startet der Timer mit default Timeout (30 Sekunden)

[Beta-User]

kann man da durch irgendwelche settings am fhem device Infos reinschreiben?

Na ja, direktes "Rumgepfusche" im Device-Hash ist immer schwierig, weil man das Risiko hat, dass man beim Löschen was übersieht und damit ein Speicherloch aufreißt. Würde tendenziell immer zu den "offiziellen" Methoden (attr und Reading) raten. Die Ausnahme wäre ggf., wenn man im laufenden Dialog irgendwas an den "Altdaten" ergänzen muss/will, die dann durch das Schließen auch wieder sauber entsorgt werden. Da war "nur" das Problem, dass man nicht mit Kopien arbeiten darf, sondern besser mit der Referenz auf's Original (so jedenfalls meine Erinnerung).

. Das 'use constant' Problem bei Perl ist bei #define in C übrigens auch da, nur kenne ich keinen, der das als Problem sieht.

"constant" ist in Perl Scheiße, wenn du dir manche komischen Klimmzüge in MYSENSORS.* ansiehst ("+CONSTANTNAME"), verstehst du vielleicht, warum ich diese critic voll teile. Andere Programmiersprachen haben das Problem ggf. nicht bzw. anders gelöst. In "meinen" Code kommt sowas jedanfalls nicht neu rein , und schon gleich nicht, wenn man eine "Vorratsvariable" an genau einer Stelle "braucht" (Bitgeschubse war bisher nicht meins, von daher finde ich persönlich den Code eher "unleserlich").
Würde sagen, wer den Key in seinem return-Hash setzt, weiß was er tut und dabei kann man es auch bewenden lassen bzw. ggf. den nächsten timeout damit setzen, falls es "nicht 0" ist. Das ist imo KISS - oder übersehe ich was wichtiges?

Ansonsten bin ich immer noch der Ansicht, dass jeder optionale Key im define auch in der commandref beschrieben sein sollte und tendenziell für eine Mehrzahl von Usern interessant, also in diesem Sinne "wichtig". Wer myUtils-code (und CustomIntent) verwendet, kann RHASSPY auch gleich passend beliefern, das ist also eher "exotisch"

Noch zu setDialogTimeout:

Thx für den Hinweis, war mir nicht mehr bewußt, dass es "vor" "respond" noch eine Abzweigung gab, die man explizit wählen muss. Bin halt immer noch nicht wieder komplett im Code drin.

Review dauert noch etwas, allerdings finde ich den Teil "# just copied from setDialogTimeout" an dieser Stelle (unabhängig vom berechtigten percritic-Punkt) nicht in sich logisch. An der Originalstelle kann es sein, dass die Funktion entweder mit einer kommaseparierten Liste oder einem Array aufgerufen wird, hier verwenden wir entweder das, was schon gesetzt war (~oldata - warum eigentlich? Rhasspy wird ja in den seltensten Fällen neu gestartet...), oder wir MÜSSEN die Variable sinnvoll füllen, wenn da nichts steht (oder den Teil überspringen, wenn das nicht geht?).