Modulentwicklung für Rhasspy Sprachassistent

[Beta-User]

Es dämmert mir aber, dass es vermutlich hilfreich wäre, die Liste der default zu deaktivierenden Intents ggf. auf einfache Weise ergänzbar zu machen... Kein Hexenwerk, aber ein kleinerer Umbau...

Anbei der (weitgehend ungetestete) Versuch, das einzubauen...

Es gibt dazu einen weiteren "Tweak" (intentFilter), mit dem man die Liste der "default" (de-) aktivierten Intents manipulieren können sollte; weiß noch nicht, wann ich dazu komme, das in Ruhe auch von der MQTT-Seite her zu begutachten. Bitte einfach etwas "spielen", das key/value-Ergebnis der Auswertung des Attributs ist im list unter "tweaks" zu finden, die intents müssen mit dem vollen Namen im key landen.

Na ja, dem könnte man mit einer Timer-Lösung begegnen, also das configure verzögert rauszuschicken.

Wie ich vorhin erst gesehen habe, klappt das grundsätzlich. Da es jetzt auch den "intent_filter" unter den "update"-settern gibt, sollte das auch als "einfaches FHEM-Kommando mit FHEM-sleep" umsetzbar sein, ohne dass der einzelne User besonders tief in's RHASSPY-coding einsteigen müßte.

Andere IO's finde ich eher schwierig, da (auch in der Gesamtkonfiguration incl. dem weiteren IO) unübersichtlich und ggf. bzgl. der Hintergründe unverstanden. MAn. sollte es reichen, wenn FHEM auf den "SilentCancelation"-Fall dadurch reagiert, dass der default-Filter wiederhergestellt wird und der User die Option hat, ggf. auf die dann auf Rhasspy-Seite eingebaute "bin wieder da"-Message angemessen (verzögert) zu reagieren (bzw. dann bauen wir das auch in RHASSPY direkt ein!).

Die Version anbei kann übrigens auch Messages auf intentNotRecognized "verarbeiten", wobei sich das im Moment mehr oder weniger darauf beschränkt, den zwischengespeicherten Kontent etwas anzureichern (so das überhaupt funktioniert); die Idee, wie es dann ggf. danach weitergehen soll fehlt mir im Moment noch...

Bitte mal schauen, ob ihr ggf. mit den cref-Hinweisen soweit erst mal hinkommt.

[JensS]

Sorry, ich suche gerade einen Wald - hast du mal ein Syntax-Beispiel bitte? 

p.s. Jetzt hab ich es gefunden:

Code Auswählen Erweitern

intentFilter= de.fhem:SetOnOff='false'

Danke @Beta-User - funktioniert zuverlässig!

Nun kann ich ja mal versuchen, ein (für Rhasspy) unbekanntes Wort zu buchstabieren [de.fhem:ABC] und in der Wikipedia zu suchen.
Das gestaltet sich noch schwierig, da z.B. b und w (für Rhasspy) ziemlich ähnlich klingen.

p.p.s. Hab mich dazu entschlossen, das Buchstabieren nach DIN 5009 umzusetzen - also Öko = Ökonom, Kaufmann, Otto.
Wie gut, dass in Deutschland alles geregelt ist. 

[Beta-User]

Ja, das Wegschalten von Intents klappt, aber leider nicht (bei allen) die Gegenrichtung...

Bin unschlüssig, was ich reparieren soll: Die cref oder den Code .

Lt. cref sollte auch sowas funktionieren:

Code Auswählen Erweitern

attr rhasspy rhasspyTweaks intentFilter=de.fhem:SetMute de.fhem:ConfirmAction=true
Und das klappt bzgl. ConfirmAction nicht. Hatte erst dazu tendiert, das im Code so anzupassen, dass auch das so geht wie in der cref beschrieben.
ABER: ist zwar nicht wirklich eine größere Aktion, aber zum einen ist unklar, ob sowas wirklich jemand braucht, und zum anderen (und das ist hier m.E. wichtiger): Das "leise" Wiederherstellen des vom Modul erwarteten Intent-Filter-Verhaltens setzt eben voraus, dass bestimmte Filter im normalen Betrieb wirklich gesetzt sind. Wenn jemand meint, die ausschalten zu müssen, wird der Filter nach jeder entsprechenden Aktion wieder aktiviert, ohne dass das positive Auswirkungen hätte - höchstens unbeabsichtigte Nebenwirkungen auf andere "Apps".
Es wird daher eine Klarstellung geben, dass das für "die 4" nicht geht...

[JensS]

Es wird daher eine Klarstellung geben, dass das für "die 4" nicht geht...

... sehe ich auch so. Die gehören ja auch zwingen zum Modul und sollten vom User im laufenden Betrieb nicht enabled werden.

Den Code schaue ich mir auch nochmal genau an aber vielleicht ist es #789, da configure_DialogManager bei "set Rhasspy update intent_filter" kein Shift bekommt.

[Beta-User]

... sehe ich auch so. Die gehören ja auch zwingen zum Modul und sollten vom User im laufenden Betrieb nicht enabled werden.

Thx für die Einschätzung. Zwischenzeitlich ist mir auch der Gedanke durch den Kopf gegangen, dass Experten, die es anders haben wollen, dann ja die Wahl haben, einen eigenen Intent dafür zu verwenden und dann eben das ganze Drumrum selbst zu organisieren.

Den Code schaue ich mir auch nochmal genau an aber vielleicht ist es #789, da configure_DialogManager bei "set Rhasspy update intent_filter" kein Shift bekommt.

"set Rhasspy update intent_filter" schubst eigentlich nur das Abholen der (vollständigen und aktuellen) Intents von Rhasspy an. Das eigentliche Filter-Setzen ist dann asynchron organisiert, nämlich aus der Verarbeitung der Antwort darauf heraus.

#789 bewirkt, dass die "default"-Routine mehr oder weniger übersprungen wird, wenn jemand configure_DialogManager() aufruft, um aktiv nur bestimmte Intents zu aktivieren. Diese Funktionalität ist mAn. eigentlich an sich überholt, kurzfristige Änderungen sollte man mit continueSession-intentFilter verwirklichen; sie schadet aber auch nicht....

Für das "Überspringen" der "4 speziellen" Intents ist die Folgezeile ("next if $_ =~ m{$matches}ms;") zuständig.

[JensS]

"next if $_ =~ m{$matches}ms;"

Ja klar - dann ist doch alles gut.

[Beta-User]

Da hast du ja ein ziemliches "Schmankerl" in einem sehr nachträglichen Edit versteckt :

p.p.s. Hab mich dazu entschlossen, das Buchstabieren nach DIN 5009 umzusetzen - also Öko = Ökonom, Kaufmann, Otto.

Klingt nach einem coolen Projekt, mit dem man die myUtils-Funktionalität iVm. "contunueSession" usw. ziemlich gut austesten können sollte .

Vielleicht in dem Zusammenhang noch ein Hinweis bzw. auch eine etwas abstrakte Überlegung: Vermutlich wird es aus "intentNotRecognized" heraus sinnvoll sein, "customData" mit einem "Merker" zu füllen, damit man z.B. relativ einfach (ohne erst den irgendwo zwischengespeicherten Intent zu suchen) in der Verarbeitung "normaler" Intents feststellen kann, _ob_ es eine "Vorgeschichte" gibt, die man sich ggf. näher ansehen muss.

Die angehängte Version unterscheidet sich in dem Punkt und einer weiteren Kleinigkeit von der Vorversion, sonst ist nur die cref angepaßt (und alles kaum getestet), aber evtl. hilft dir das schon etwas weiter....

[JensS]

  Ideen muss man haben - Hellwig.
customData dachte ich als Speicherort für die jeweilige Session zu nutzen, um den Einstiegsintent und die Dialog(zwischen)ergebnisse abzulegen.
Nun muss ich erst mal Urlaub machen. Ich schau zwischendurch mal rein, ob's was Neues gibt - auch im Rhasspy-Forum.

[Beta-User]

customData dachte ich als Speicherort für die jeweilige Session zu nutzen, um den Einstiegsintent und die Dialog(zwischen)ergebnisse abzulegen.
Nun muss ich erst mal Urlaub machen. Ich schau zwischendurch mak rein, ob's was Neues gibt - auch im Rhasspy-Forum.

Dann mal schönen Urlaub, erhol dich gut !

Was cutomData angeht, bin ich unschlüssig, wie man das sinnvoll verwenden kann. Das Problem ist halt, dass man da keine strukturierten Daten durchreichen kann (sonst zuerhaut's die Session), sondern nur "flachen Text". Daher neige ich eher dazu, alle Zwischeninfos im RHASSPY-Hash abzulegen und in customData nur irgendwelche (kurzen?) Statusinfos mitzugeben, damit man schnell(er) vorsortieren kann. Ist aber alles noch nicht komplett durchdacht, werd's vermutlich dann die Tage mal auch als Zwischenstand im Rhasspy-Forum posten und mir da nochmal Meinungen versuchen einzuholen...
Muß dazu aber auch nochmal (v.a.) den MQTT-Verkehr etwas "im laufenden Betrieb" beobachten, vielleicht kommt mir dann noch eine Eingebung?!?

[JensS]

Danke. 
Wegen des Formats würde ich mir erst mal keine Sorgen machen. Selbst JSON ist letztlich nur Text. Wichtig ist die richtige Codierung. Ich hatte mir mal mit der Sprachausgabe das ganze FHEM abgeschossen, bevor ich dann auf utf-8 umgestellt hatte. Lehrgeld eben... Man kann ja auch einen Konverter zum Maskieren drüber laufen lassen.

[Beta-User]

Selbst JSON ist letztlich nur Text.

Jo. Dachte ich auch mal...
Kann schon sein, dass da was ginge, wenn man das mit dem "Säubern" intensiver ansehen würde, aber die Reaktion von den Rhasspy-Leuten auf komplexeren Content an der Stelle war eher: "Watndat...?!?!?"
Von daher _glaube_ ich, dass es einfacher ist, das Feld nur für "Schalterwörter" zu nutzen und den eigentlichen Content dann einfach im "Dialoghash" zwischenzuspeichern. Den brauchen wir nach meinen bisherigen Erfahrungen sowieso und sind dann völlig flexibel...

[JensS]

Wenn die Grundlagen gelegt sind, gibt's der Wege viele. Klar, das alles in FHEM zwischenzuspeichern macht Sinn, wenn der Spieltrieb nicht wäre... 
Kann sein, dass ich den intentFilter-Thread im Rhasspy-Forum getötet habe. Mir ging es doch nur um default-disabled-Intent und slot in intentFilter...
Wäre schön, wenn es in die nächste Rhasspy-Version mit einfließen würde.
Konntest du dich inzwischen mit einer optionalen Rückfrage in SetOnOff anfreunden?

Insgesamt finde ich das Modul 10_RHASSPY.pm mittlerweile echt sehenswert, nachdem ich dem Umbau skeptisch entgegensah. Auch von den anderen Nutzern gibt es derzeit keine Fehleranzeigen. :Daumenhoch

[Beta-User]

Kann sein, dass ich den intentFilter-Thread im Rhasspy-Forum getötet habe. Mir ging es doch nur um default-disabled-Intent und slot in intentFilter...

Das glaube ich kaum, dass du den "abgeschossen" hast, die warten da eher auf (halbwegs) qualifizierten Input von meiner Seite .

Die zugrundeliegenden Probleme sind nach meiner Wahrnehmung auch in der einen oder anderen Form auch schon von anderen aufgegriffen worden, aber bis zum Ende durchgespielt (nicht nur mit der Demo-App) scheint das bisher keiner zu haben. Von daher bin ich optimistisch, dass es da in der einen oder anderen Form Bewegung geben wird.

Konntest du dich inzwischen mit einer optionalen Rückfrage in SetOnOff anfreunden?

Strukturell sollte das kein größerer Act sein, ich meine, da wären auch noch ein paar Fragen an die Nutzer offen, wie man es denn gerne hätte...?

Mein "Problem" ist derzeit eher, dass ich für den "Prototypen" (SetOnOffGroup) eigentlich lieber erst mal den Pfad durch den Gesamtcode gelegt haben wollte, bevor es weitergeht. Und das wird noch etwas dauern, ansonsten steht es auf dem Plan, klar...

Insgesamt finde ich das Modul 10_RHASSPY.pm mittlerweile echt sehenswert, nachdem ich dem Umbau skeptisch entgegensah. Auch von den anderen Nutzern gibt es derzeit keine Fehleranzeigen. :Daumenhoch

Danke!
Wenn ich nicht "gewisse Erfahrungen" aus dem MQTT_GENERIC_BRIDGE-Umbau heraus gehabt hätte, wäre ich auch skeptischer gewesen bzw. hätte mir den Umbau auch nicht zugetraut . So bin ich auch hocherfreut, dass keiner (berechtigten) Anlass hat, sich zu beklagen und das ganze doch sehr reibungslos zu laufen scheint... (?).

Aber bei so massiven Eingriffen darf man skeptisch sein! Und manches hat ja leider auch nicht auf Anhieb geklappt.
Jetzt finde ich das ganze - trotz der vielen Optionen auf vielen Ebenen - noch vergleichsweise easy in der Einrichtung (aus User-Sicht), das ist eigentlich das coolste daran ...

[JensS]

Hat schon jemand die Preview auf 2.5.11 (docker) am laufen? Ich nutze ausschließlich Debian-Pakete.
Mich interessiert, ob es was Neues im Dialogmodul gibt und z.B. eine Startmessage implementiert wurde.
Geschrieben wurde dazu leider nichts.

Gruß Jens

[JensS]

@Beta-User
Kannst du mir bitte auf die Sprünge helfen, wie ich die sessionId und die siteId von handleCustomIntent abgreifen kann?
Versuche mich gerade am Wikipedia-Dialog...

Gruß Jens