Modulentwicklung für Rhasspy Sprachassistent

Beta-User · 28 Juni 2021, 11:47:59

Zitat von: JensS am 28 Juni 2021, 10:33:34
Es geht ja nur um die Rückfrage-Dialoge.
Die normale sentences.ini und der bisherige Programmcode bliebe unangetastet und würde wie gewohnt abgearbeitet.

Das Problem ist aber, dass man dann eben aus der Rückfrage wieder in den "normalen" Modus wechselt (s.u.), aber - dem Gefühl nach - irgendwie festhalten muss, wo man herkommt...

Zitat
Wenn der intentFilter gesetzt ist und keine Antwort, wie "ja bitte" sondern "wie spät ist es" gegeben wurde, erhält man vor der intentNotRecognized-Nachricht eine NLU-Message (sofern aboniert).
Code Auswählen Erweitern
hermes/nlu/query {"input": "wie spät ist es"

Das "wie spät ist es" ist dann auch in der intentNotRegognized-Message drin. Es ist dort (wie auch bei "query") aber überhaupt nicht klar, "wo" das hingehört (also z.B. zu welchem (deaktivierten) Intent). Das bedeutet, man muss diesen Input wieder an Rhasspy zurückgeben (noch zu klären: wo und wie?), aber eben erst, nachdem man (welchen?) Filter wieder umgestellt hat, damit die Analyse auf den Intent (und ggf. enthaltene keywords) stattfindet. Vorab noch eine Rückfrage an den User, ob das Thema gewechselt werden soll...?
Da das dann aber innerhalb eines Dialoges stattfindet, stellt sich die Frage, welche "alten" Daten eigentlich gelöscht werden sollten, damit man nicht versehentlich in der falschen Schublade landet (z.B.: bleibt man im selben Raum wie dem, der ggf. bei der ersten Ansage genannt wurde oder nimmt man den aus der siteId abgeleiteten?!?).

Vielleicht denke ich grade auch zu sehr um's Eck, aber es kommt mir alles andere als trivial vor, von dem zentralen "intentNotRecognized" wieder zielführend wegzukommen...

JensS · 28 Juni 2021, 12:20:10

Zitat von: Beta-User am 28 Juni 2021, 11:47:59
Vielleicht denke ich grade auch zu sehr um's Eck, aber es kommt mir alles andere als trivial vor, von dem zentralen "intentNotRecognized" wieder zielführend wegzukommen...

Ich denke, dass das zentrale intentNotRecognized die Pflicht ist und die NLU als Kür vielleicht irgenwann mit reinkommen könnte. Vieles ist sowieso hypothetisch, solange wir keine Info/Erweiterung von Rhasspy haben.

JensS · 28 Juni 2021, 14:02:43

@drhirn
Da Rhasspy in einem recht gutem Zustand ist und prinzipiell die Anforderungen einer Sprachsteuerung erfüllt, wären die Voraussetzungen zu einem WIKI-Artikel in der Kategoie Sprachsteuerung gegeben.
Zumal das Modul bereits in contrib ist.
Man könnte ja https://github.com/fhem/fhem-rhasspy/blob/main/README.md dazu nehmen.

Gruß Jens

drhirn · 28 Juni 2021, 14:24:36

Ich habe meine Überlegungen dazu hier schon kund getan: https://forum.fhem.de/index.php/topic,119447.msg1157988.html#msg1157988

Kurz gesagt: Kann jeder jederzeit machen, ich unterstütze gerne. Kümmern möchte ich mich aber nicht darum.

JensS · 29 Juni 2021, 12:41:11

@Beta-User
Als Zwischenlösung habe ich meinen Beitrag https://forum.fhem.de/index.php/topic,119447.msg1163740.html#msg1163740 nochmals editiert.
Hast du ein Attribut, in dem ich meine per default zu deaktivierenden Intents reinpacken kann?

Gruß Jens

Edit: Funktioniert nicht, da Dialogue nach dem allg. Rhasspy-Server gestartet wird. Entweder setzt man ein qos, dass Dialogue die Nachricht erhält, wenn er sich beim MQTT anmeldet oder das notify bekommt ein at mit rein.

Beta-User · 29 Juni 2021, 13:02:25

Ein Attribut gibt es bisher nicht, muss mal überlegen, ob das Sinn macht (aber vermutlich erst, wenn wir mit dem ganzen gedanklich "fertig" sind). Dann wäre noch zu klären, wie das wirken soll und in welcher Form die Intents dann präsentiert werden müßten (Komma-separiert?)

An sich ist der Code aber generisch angelegt. Es sollte daher möglich sein, das über "normales Perl" im notify zu machen. Ausgangspunkt:

Code Auswählen

configure_DialogManager {
    my $hash      = shift // return;
    my $siteId    = shift // 'null'; #ReadingsVal( $hash->{NAME}, 'siteIds', 'default' ) // return;
    my $toDisable = shift // [qw(ConfirmAction CancelAction ChoiceRoom ChoiceDevice)];
    my $enable    = shift // q{false};

Das ergäbe dann ungefär sowas:

Code Auswählen

defmod updateIntentFilter notify MQTT2_rhasspyMQTT2 { my $toDisable = [qw(MeinIntent)];; RHASSPY::configure_DialogManager( $defs{Rhasspy}, undef, $toDisable ) }

Das ganze wird aber bei einer "SilentCancellation" derzeit wieder auf die defaults gesetzt!

JensS · 29 Juni 2021, 13:30:35

Danke, das übernehme gern. Gibt es eine Möglichkeit, nur diese Nachricht mit qos=1 o.ä. anzusetzen?

Zitat von: Beta-User am 29 Juni 2021, 13:02:25
Das ganze wird aber bei einer "SilentCancellation" derzeit wieder auf die defaults gesetzt!

Der "default intent filter" kann doch immer so bleiben.? Nach der Dialog-Session mit intentFilter gilt er doch sowieso wieder, egal ob ordentlich beendet wurde oder mit einem Timeout.

p.s. So geht's:

Code Auswählen

defmod updateIntentFilter notify MQTT2_rhasspyMQTT2 {fhem('define 5_s at +00:00:05 { my $toDisable = [qw(ConfirmAction)];;;; RHASSPY::configure_DialogManager( $defs{Rhasspy}, undef, $toDisable ) }')}

Beta-User · 29 Juni 2021, 13:40:53

Zitat von: JensS am 29 Juni 2021, 13:30:35
Danke, das übernehme gern. Gibt es eine Möglichkeit, nur diese Nachricht mit qos=1 o.ä. anzusetzen?

Mit QoS habe ich mich bisher nicht beschäftigt, und ich bin auch nicht sicher, ob das von MQTT2_CLIENT unterstützt wird bzw. dann auch wirklich die Auswirkung hätte, die du dir wünschen würde - das ganze setzt nämlich afaik voraus, dass das eigentliche Zielgerät sich ordentlich subscribed hatte, und das scheint beim Start ja grade nicht der Fall zu sein, wenn ich den Nachtrag von vorhin richtig interpretiere?

Zitat
Der "default intent filter" kann doch immer so bleiben.? Nach der Dialog-Session mit intentFilter gilt er doch sowieso wieder, egal ob ordentlich beendet wurde oder mit einem Timeout.

Na ja, wenn ein (bestimmter) "unzulässiger" Intent kommt, unterstelle RHASSPY derzeit, dass Rhasspy neu gestartet wurde und stellt dann die default-Filter wieder her. Wenn (künftig) per Attribut gelöst, würde man wohl die default-Liste entsprechend erweitern...

JensS · 29 Juni 2021, 13:50:20

Zitat von: Beta-User am 29 Juni 2021, 13:40:53
setzt nämlich afaik voraus, dass das eigentliche Zielgerät sich ordentlich subscribed hatte, und das scheint beim Start ja grade nicht der Fall zu sein

Rhasspy besteht, wie du weißt, aus veschiedenen Modulen. Das Hauptmodul (mit der Start-Message) subscribed kein configure. Das wird vom Dialog-Modul aboniert, welches später startet.
Beim Neustart ist die configure-Anweisung also längst durch, bevor das betreffende Modul gestartet wurde.

Beta-User · 29 Juni 2021, 14:01:21

Na ja, dem könnte man mit einer Timer-Lösung begegnen, also das configure verzögert rauszuschicken.
(Ich wollte nicht unterstellen, dass Rhasspy da was "falsch" macht, sondern nur klarstellen, dass es passieren kann, dass der MQTT-Server gar nicht weiß, dass "jemand" später einen bestimmten Topic subscriben will und daher ggf. das QoS ins Leere läuft.

Könnte man vielleicht mit einem retain-Flag lösen, aber da stellen sich dann wieder andere Probleme - kurz: Ich halte das mit dem "SilentCancellation"-reset für die noch am ehesten zielführende Lösung.

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...

JensS · 29 Juni 2021, 17:21:54

Wenn die Message mit QOS 1 gepublisht wurde, hält sie Mosquitto so lange vor, bis sie von einem Client subscribed/abgerufen wurde. Die Message ist so lange in der Mosquitto-Datenbank hinterlegt und überlebt sogar einen Mosquitto-Neustart.

Beta-User · 29 Juni 2021, 17:33:01

OK, dann habe ich das mit QoS jetzt auch verstanden... Nur: wie publisht man via M2C mit entsprechendem Flag? Doku ist an der Stelle etwas "dünn"...

JensS · 29 Juni 2021, 17:40:29

Ich hab's mal in MQTT angefragt. Rudi als Maintainer weiß das bestimmt.
Insgesamt wäre es sowieso besser, wenn das auf der Rhasspy-Seite gelöst werden würde. Eventuell mit einem flag in der Intentdefinition von sentences. Im Forum hatte ich ja gefragt, ob man die Intents per default (de)aktivieren kann. Das würde die ganze Nummer mit der Start-Message überflüssig machen. Irgendwie sind dort meine Vorschläge bislang auf kein großes Interesse gestoßen...

Beta-User · 29 Juni 2021, 17:46:56

Hab's dann auch gesehen...

Na ja, die Vorschläge laufen halt meinem Bauchgefühl nach auf ziemlich tiefe Eingriffe in die Gesamtfunktionalität ein und erfordern einiges an Coding. Da würde hier auch erst mal gefragt werden, wo denn die effektiven Restriktionen liegen, und ob man nicht erst mal versuchen kann, mit den vorhandenen Mitteln zurande zu kommen.
Genau an der Stelle sind jetzt mAn. erst mal wir in der Pflicht. Ich habe zwar das Gefühl, dass es noch andere "Apps" gibt, die an diesen Stellen straucheln, aber einen Bedarf zu erkennen heißt dann ja noch lange nicht, dass man eine gemeinsame Vision hat, wie sich die Probleme lösen lassen. Ergo: eines nach dem anderen...

JensS · 29 Juni 2021, 18:17:18

Ok, dann halte ich mal die Füße still.
Die Antwort von Rudi hast du bestimmt gelesen. Also könnte man von FHEM-Seite her (versuchen), ein extra MQTT2_CLIENT (zu) definieren, welcher die Start-Message abfängt und die Configure-Message mit QOS 1 absetzt. Ob's klappt, wird sich zeigen. Das hängt davon ab, ob das Dialogmodul nach dem subscribe einmal durchgelaufen und bereit für Messages ist.
Die Übertragung im Netzwerk dauert ja ein paar ms und das sollte eventuell als Verzögerung reichen.
Willst du dir das mal anschauen, ob man das in 10_RHASSPY reinnehmen könnte?

p.s. Andererseits ist es dem User nicht zuzumuten, den Rhasspy-Code zu editieren... $:-\$