Modulentwicklung für Rhasspy Sprachassistent

[Prof. Dr. Peter Henning]

Also, erstmal mein Senf zum Thema "mehrere Sites" in einem Raum.

Ich habe stellenweise mehrere AMAD-Devices in einem Raum. Die haben bei mir Attribute z.B. babbleRoom=wohnzimmer:esstisch. Eines der Devices hat _keinen_ "Unterraum". Das wird für Ausgabe genommen, wenn ein solcher "Unterraum" nicht angegeben wird. Wenn die Ausgabe direkt auf eine Eingabe folgte, findet die Ausgabe generell dort statt, wo auch die Eingabe war.

Jetzt zum Thema AMAD und RHASSPY: Ich habe mir da wirklich einen Wolf gesucht und erwarte dafür die Gabe eines Glases Alkohol.

1. Das Modul RHASSPY startet die Spracheingabe auf einem AMAD-Device Tab2.EG. Das ist aber falsch, denn diesen Devicenamen kennt RHASSPY nur aus dem Attribut

Code Auswählen Erweitern

rhasspyTTS Tab2.EG=siteId=default ttsCommand={speak("$DEVICE","$message")}
Und sorry, aber die Spracheingabe hat mit TTS nichts zu tun.

2. Das Modul RHASSPY startet die Spracheingabe auf einem AMAD-Device leider _nicht_, wenn das "Hotword detected" wurde (wie es eigentlich sein sollte). Was läuft ab?
a. Nach der Hotword-Erkennung sendet Rhasspy eine Nachricht hermes/hotword/toggleOff, um die Hotword-Erkennung auszuschalten. Denn dann wird der Hotword-Erkennungston abgespielt.
b. Unmittelbar danach sendet Rhasspy eine Nachricht hermes/hotword/toggleOn, um die Hotword-Erkennung wieder einzuschalten ===> In diesem Moment startet RHASSPY die Spracherkennung - also eigentlich zu spät.
c. Dann wird eine Dialogsession gestartet, dafür wieder mit  hermes/hotword/toggleOff die Hotword-Erkennung ausgeschaltet.
d. Die Dialogsession wird natürlich im nachfolgenden Auszug nicht gefüllt. Also geht Rhasspy nach 30 Sekunden in einen Timeout, und schaltet die Howord-Erkennung mit einem hermes/hotword/toggleOn wieder ein. Macht Sinn, denn es soll ja jetzt erneut auf das Hotword gelauscht werden. ===> Durch den Fehler in RHASSPY startet die Spracherkennung aber bei diesem hermes/hotword/toggleOn erneut.

Die beiden Fehler müssten irgendwie behoben werden, damit das einsetzbar ist.

LG

pah

Code Auswählen Erweitern

2022.02.23 16:06:23 5: RHASSPY: [rhasspyDev] Parse (IO: rhasspyMQTT2): Msg: hermes/hotword/hallo-jeannie-3/detected => {"modelId": "hallo-jeannie-3.pb", "modelVersion": "", "modelType": "personal", "currentSensitivity": 0.5, "siteId": "default", "sessionId": null, "sendAudioCaptured": null, "lang": null, "customEntities": null}
2022.02.23 16:06:23 5: Parsed value: default for key: siteId
2022.02.23 16:06:23 1: [VoiceMQTT] Hotword hallo-jeannie detected =====> Das ist OK so !!!

2022.02.23 16:06:23 5: RHASSPY: [rhasspyDev] Parse (IO: rhasspyMQTT2): Msg: hermes/hotword/toggleOff => {"siteId": "default", "reason": "playAudio"}
2022.02.23 16:06:23 5: Parsed value: default for key: siteId
2022.02.23 16:06:23 5: RHASSPY: [rhasspyDev] Parse (IO: rhasspyMQTT2): Msg: hermes/hotword/toggleOn => {"siteId": "default", "reason": "playAudio"}
2022.02.23 16:06:23 5: Parsed value: default for key: siteId
2022.02.23 16:06:23 5: analyzeAndRunCmd called with command: set Tab2.EG activateVoiceInput
2022.02.23 16:06:23 5: set Tab2.EG activateVoiceInput is a FHEM command

2022.02.23 16:06:23 5: RHASSPY: [rhasspyDev] Parse (IO: rhasspyMQTT2): Msg: hermes/dialogueManager/sessionStarted => {"sessionId": "default-hallo-jeannie-3-c5604fc3-acb8-4fd9-8a24-0eaded724e92", "siteId": "default", "customData": "hallo-jeannie-3", "lang": null}
2022.02.23 16:06:23 5: Parsed value: hallo-jeannie-3 for key: customData
2022.02.23 16:06:23 5: Parsed value: default-hallo-jeannie-3-c5604fc3-acb8-4fd9-8a24-0eaded724e92 for key: sessionId
2022.02.23 16:06:23 5: Parsed value: default for key: siteId
2022.02.23 16:06:23 5: default room used
2022.02.23 16:06:23 5: RHASSPY: [rhasspyDev] Parse (IO: rhasspyMQTT2): Msg: hermes/hotword/toggleOff => {"siteId": "default", "reason": "dialogueSession"}
2022.02.23 16:06:23 5: Parsed value: default for key: siteId

2022.02.23 16:06:27 1: [Hear] from device Tab2.EG
2022.02.23 16:06:27 1: [speakTablet] name=Tab2.EG text=Das Haus ist Nicht Gesichert und im Modus Normal. Es ist Tageszeit, letzter Übergang war Nachmittag.

2022.02.23 16:06:27 5: [rhasspyDev] NotifyFn called with event in AMADBridge
2022.02.23 16:06:53 5: RHASSPY: [rhasspyDev] Parse (IO: rhasspyMQTT2): Msg: hermes/dialogueManager/sessionEnded => {"termination": {"reason": "timeout"}, "sessionId": "default-hallo-jeannie-3-c5604fc3-acb8-4fd9-8a24-0eaded724e92", "siteId": "default", "customData": "hallo-jeannie-3"}
2022.02.23 16:06:53 5: Parsed value: default for key: siteId
2022.02.23 16:06:53 5: Parsed value: hallo-jeannie-3 for key: customData
2022.02.23 16:06:53 5: Parsed value: default-hallo-jeannie-3-c5604fc3-acb8-4fd9-8a24-0eaded724e92 for key: sessionId
2022.02.23 16:06:53 5: default room used

2022.02.23 16:06:53 5: RHASSPY: [rhasspyDev] Parse (IO: rhasspyMQTT2): Msg: hermes/hotword/toggleOn => {"siteId": "default", "reason": "dialogueSession"}
2022.02.23 16:06:53 5: Parsed value: default for key: siteId
2022.02.23 16:06:53 5: analyzeAndRunCmd called with command: set Tab2.EG activateVoiceInput
2022.02.23 16:06:53 5: set Tab2.EG activateVoiceInput is a FHEM command

2022.02.23 16:06:58 1: [Hear] from device Tab2.EG
2022.02.23 16:06:58 1: [Babble_DoIt] Executing from hash: meister.sitzgruppe.spielen.none/ 
2022.02.23 16:06:58 1: [speakTablet] name=Tab2.EG text=:002:
2022.02.23 16:06:58 5: [rhasspyDev] NotifyFn called with event in AMADBridge

[drhirn]

Ich habe stellenweise mehrere AMAD-Devices in einem Raum. Die haben bei mir Attribute z.B. babbleRoom=wohnzimmer:esstisch. Eines der Devices hat _keinen_ "Unterraum". Das wird für Ausgabe genommen, wenn ein solcher "Unterraum" nicht angegeben wird. Wenn die Ausgabe direkt auf eine Eingabe folgte, findet die Ausgabe generell dort statt, wo auch die Eingabe war.

Guter Workaround! Bedingt halt ein zusätzliches Devices. In meinem Fall egal, Hardware hab ich genug herumliegen

[Beta-User]

Also, erstmal mein Senf zum Thema "mehrere Sites" in einem Raum.

Ich habe stellenweise mehrere AMAD-Devices in einem Raum. Die haben bei mir Attribute z.B. babbleRoom=wohnzimmer:esstisch. Eines der Devices hat _keinen_ "Unterraum". Das wird für Ausgabe genommen, wenn ein solcher "Unterraum" nicht angegeben wird. Wenn die Ausgabe direkt auf eine Eingabe folgte, findet die Ausgabe generell dort statt, wo auch die Eingabe war.

Dieses setup macht m.E. Sinn und sollte daher für die meisten Fälle passen bzw. sich auch so im Rhasspy-Kontext umsetzen lassen.

Damit auch 1:1 das Ausgangsdevice wieder angesprochen wird, ist anbei das mit siteId statt timerRoom umgesetzt.

Guter Workaround! Bedingt halt ein zusätzliches Devices. In meinem Fall egal, Hardware hab ich genug herumliegen

Wieso das? Es müßte doch reichen, eines der vorhandenen "doppelten" umzubenennen, oder?

@pah: Da war noch ein "Klopper" in notifySTT()...
Babble_DoIt() wurde aus dem falschen Kontext heraus aufgerufen, jetzt geht das über die Indirektion AnalyzePerlCommand() und sollte daher "save" sein. Wenn das Zugeschlagen hätte, müßte aber eigentlich FHEM komplett abgeschmiert sein.

Jetzt zum Thema AMAD und RHASSPY: Ich habe mir da wirklich einen Wolf gesucht und erwarte dafür die Gabe eines Glases Alkohol.

Ich trinke gerne zum Opfer ein Glas ordentlichen Rotweins auf dich ...
(Im Ernst: einen gemeinsamen Verzehr jeweils einer "Gabe" sollten wir ins Auge fassen.)

1. Das Modul RHASSPY startet die Spracheingabe auf einem AMAD-Device Tab2.EG. Das ist aber falsch, denn diesen Devicenamen kennt RHASSPY nur aus dem Attribut

Code Auswählen Erweitern

rhasspyTTS Tab2.EG=siteId=default ttsCommand={speak("$DEVICE","$message")}
Und sorry, aber die Spracheingabe hat mit TTS nichts zu tun.

Was die Namenswahl des Attributs angeht: An sich berechtigter Einwand, aber man kann das ja auch nur unidirektional nutzen, um reine Ausgaben zu machen. Und weil es einigermaßen naheliegend ist, dass Geräte, die für die Ausgabe verwendet werden, auch für die Eingabe tauglich sind, wird halt das herangezogen, was da ist. Sonst müßte man doppelt konfigurieren, was auch unschön wäre... (Doku ist eine weitere Frage, klar).

2. Das Modul RHASSPY startet die Spracheingabe auf einem AMAD-Device leider _nicht_, wenn das "Hotword detected" wurde (wie es eigentlich sein sollte).

Habe den Teil, der für "activateVoiceInput" verantwortlich ist verschoben von #3022ff nach #3042ff. Das sollte jetzt also auf "detected" reagieren und nicht mehr "doppelt" auf "toggleOn".

Kann aber noch nicht abschätzen, wie weit das trägt; da scheint auch noch manches andere mit aktiv zu sein, dessen Einfüsse auf das Gesamtgeschehen ich im Moment nicht so schnell überblicken kann.

[JensS]

... und erwarte dafür die Gabe eines Glases Alkohol.

Undank ist der Welten Lohn. 

[drhirn]

Damit auch 1:1 das Ausgangsdevice wieder angesprochen wird, ist anbei das mit siteId statt timerRoom umgesetzt.

Sicher, dass damit in der Küche der Satz "Timer im Wohnzimmer auf X" funktioniert? Der eine Kurztest von mir heute hat in meiner schnellschnell zusammengestückelten Testumgebung ergeben, dass dann die siteId der Küche genommen wird. Kann mich aber auch getäuscht haben.

Wieso das? Es müßte doch reichen, eines der vorhandenen "doppelten" umzubenennen, oder?

Nein. Dann funktioniert ja die "Gruppenfunktionalität" von Rhasspy nicht mehr und es reagieren wieder beide auf das Kommando nach dem Wakeword.

[Beta-User]

Sicher, dass damit in der Küche der Satz "Timer im Wohnzimmer auf X" funktioniert? Der eine Kurztest von mir heute hat in meiner schnellschnell zusammengestückelten Testumgebung ergeben, dass dann die siteId der Küche genommen wird. Kann mich aber auch getäuscht haben.

...vermutlich nicht, jedenfalls vorerst wieder zurückgedreht.

Nein. Dann funktioniert ja die "Gruppenfunktionalität" von Rhasspy nicht mehr und es reagieren wieder beide auf das Kommando nach dem Wakeword.

Blöd; da bin ich doch glatt froh, dass ich praktisch nur die Mobile-App nutze...

[drhirn]

Jetzt zum Thema AMAD und RHASSPY: Ich habe mir da wirklich einen Wolf gesucht und erwarte dafür die Gabe eines Glases Alkohol.

Undank ist der Welten Lohn. 

Ach du meine Güte, ich wollte darauf ja reagieren. Ist im beruflichen Trubel leider vergessen worden.
Angebot steht jederzeit. Allerdings in Wien

[Prof. Dr. Peter Henning]

Wenn das Zugeschlagen hätte, müßte aber eigentlich FHEM komplett abgeschmiert sein.

Nö, wie man an dem Log-Auszug sieht wurde da bisher analyzeAndRunCmd verwendet, das ist sicher gegen Abstürze.

Guter Workaround! Bedingt halt ein zusätzliches Devices.

Nö, kein Workaround, habe ich auch nicht. Der Trick ist, eine Liste für das Attribut zuzulassen. Das ist auch aus dem folgenden Grund sinnvoll.

Und weil es einigermaßen naheliegend ist, dass Geräte, die für die Ausgabe verwendet werden, auch für die Eingabe tauglich sind, wird halt das herangezogen, was da ist

Nein, entschiedener Widerspruch. Beispielsweise lasse ich bestimmte Sprachausgaben eben nicht auf den Tablets machen, sondern (auch aus Gründen der Audioleistung!) auf einem Gerät meiner BOSE Soundtouch-Systeme. Und wenn der housemode (im YAAHM-Device) auf "donotdisturb" gestellt ist, wird die Ausgabe nur auf einem Display angezeigt.

Angebot steht jederzeit. Allerdings in Wien

Kein Problem. Ich habe als einen meiner Nebenjobs einen Lehrauftrag am Institut für Bildungswissenschaft der Universität Wien, war zuletzt im Oktober da und mag die Stadt sehr gern. Auch wenn ich den Lehrauftrag wahrscheinlich auslaufen lassen werde: Schon alleine für den Besuch unserer Lieblingspizzeria fahre ich mit meiner Frau gerne mal wieder 2000 km.

LG

pah

[Beta-User]

Nö, wie man an dem Log-Auszug sieht wurde da bisher analyzeAndRunCmd verwendet, das ist sicher gegen Abstürze.

Ich dachte an eine andere Stelle...

Nein, entschiedener Widerspruch. Beispielsweise lasse ich bestimmte Sprachausgaben eben nicht auf den Tablets machen, sondern (auch aus Gründen der Audioleistung!) auf einem Gerät meiner BOSE Soundtouch-Systeme. Und wenn der housemode (im YAAHM-Device) auf "donotdisturb" gestellt ist, wird die Ausgabe nur auf einem Display angezeigt.

Vielleicht erst mal prinzipiell:
- Schritt 1 ist m.e. erst mal, einen "Pfad" durch das Dickicht zu bekommen. Den Code dann auszubauen, und z.B. zusätzliche Abfragen einzubauen ist dann ggf. nicht das große Problem.
- Der Rückgriff auf den Attributwert ist nach dem Code übrigens bereits jetzt der "Notnagel" . Die Info, wohin gesprochen werden soll, kann zur Laufzeit auch pro siteId über ein Reading beeinflusst werden, siehe Ende der commandref (da fehlt nur der "experimental"-Hinweis).
- Die Frage der Aktivierung des voiceInputs ist nochmal spezieller, weil das wirklich nur auf passenden (FHEM-) Geräten geht, und da ist uU. die Auswertung des Readings in der Tat nicht zielführend (oder zumindest verwirrend)...

Klar: Vermutlich müssen wir die Bausteinchen noch weiter verfeinern und ggf. diese impliziten Zuordnungen von TTS- und STT-Angaben irgendwie anders benennen, sortieren, verattributieren usw.. Aber dazu muss m.E. erst mal die "Karte gezeichnet" und ein erster Pfad da sein.

Vielleicht kann in diesem Kontext auch der befehl "msg" weiterhelfen, müßte man klären oder entscheiden. Wobei das dann eher eine "personenbezogene Denke" ist, die nicht so recht zu der bisherigen ortsabhängigen Logik zu passen scheint.

Grüße, Beta-User

[drhirn]

Kein Problem. Ich habe als einen meiner Nebenjobs einen Lehrauftrag am Institut für Bildungswissenschaft der Universität Wien, war zuletzt im Oktober da und mag die Stadt sehr gern. Auch wenn ich den Lehrauftrag wahrscheinlich auslaufen lassen werde: Schon alleine für den Besuch unserer Lieblingspizzeria fahre ich mit meiner Frau gerne mal wieder 2000 km.

Ja, das mit dem Lehrauftrag hab ich irgendwo mal gelesen. Wie gesagt, Angebot steht. Meld dich einfach, wenn du das nächste Mal da bist.
Welche Pizzeria ist denn das?

[Prof. Dr. Peter Henning]

Ich teste derzeit die jüngste RHASSPY-Version parallel zu meinen eigenen Routinen. Daraus ergeben sich schon ein paar klare Erkenntnisse.

1. Das Abfangen der Wakeword-Erkennung in RHASSPY ist nicht zielführend. Es sollte vielmehr die Option bestehen, Wakeword-Events mit komplett eigenen FHEM-Kommandos zu belegen. Also die Events "detected", "toggleOn" und "toggleOff", und diese FHEM-Kommandos (die natürlich auch Perl-Kommandos sein dürfen) können auch den gesamten JSON-Payload als Parameter mitbekommen. Damit kann der FHEM-Nutzer dann selber entscheiden, was danach passiert. Lösungsvorschlag: in RHASSPY Attribute für die entsprechenden FHEM-Kommandos einführen. Bei meinen eigenen Routinen wird das in einem MQTT2_DEVICE umgesetzt durch

Code Auswählen Erweitern

VoiceMQTT_Client:hermes/hotword/.*/detected:.* { rhasspyHotword($NAME,'hotword',$EVENT) }
VoiceMQTT_Client:hermes/hotword/toggleOn:.* { rhasspyHotword($NAME,'on',$EVENT) }
VoiceMQTT_Client:hermes/hotword/toggleOff:.* { rhasspyHotword($NAME,'off',$EVENT) }

2. Der direkte Aufruf von AMAD-Spracherkennung ist auch nicht zielführend. Schönes Anwendungsbeispiel: Wenn ich die AMAD-Spracherkennung auf meinen Devices im Wohnzimme starte, muss vorher die Audioanlage gemutet werden. Also sollte RHASSPY nicht selbst nach AMAD-Devices suchen, sondern einfach ein beliebiges (per Attribut konfigurierbares) FHEM-Kommando aufrufen. Das natürlich, wie oben, auch ein Perl-Kommando sein darf. Bei mir wird das unter anderem dafür genutzt, dasjenige Spracherkennungsdevice auszuwählen, das am nächsten an den Bewohnern dran ist. Auch hier könnte man den Payload aus Rhasspy weitergeben.

LG

pah

[Beta-User]

Hmm, irgendwie hatte ich bei den jüngsten Umbauten schon so ein Gefühl, dass das direkte Einschalten des voiceInput noch nicht der Weißheit letzter Schluss ist  ....

Erste Anmerkungen:
- Das Verhalten kann man jetzt schon ausschalten, wenn man das siteId2ttsDevice_<siteId>-Reading für jedes bekannte AMAD-Device auf "0" setzt. Für Testzwecke würde ich das mal empfehlen, ansonsten wäre es auch nicht das große Problem, die Abfrage in #3045 erst mal tot zu stellen, bis wir wissen, ob das jemand braucht (ggf. einschaltbar über einen key in DEF?).

Es sollte vielmehr die Option bestehen, Wakeword-Events mit komplett eigenen FHEM-Kommandos zu belegen. Also die Events "detected", "toggleOn" und "toggleOff", und diese FHEM-Kommandos (die natürlich auch Perl-Kommandos sein dürfen) können auch den gesamten JSON-Payload als Parameter mitbekommen.

Auch das geht mit gewissen Einschränkungen heute schon:
- Es gibt siteId-spezifische hotword-Reading-Events für on/off. Soweit mir in Erinnerung, gibt es da kaum mehr an Info wie "welches hotword" und welche siteId. Stellt sich die Frage, inwieweit eine Doppelung Sinn macht oder ob da nicht einfach ein notify angeflanscht werden kann/soll? (Meine Sorge: Mehr Optionen = mehr Verwirrung für die User, aber nicht wirklich mehr Funktionalität).
- für "detected" gibt es ebenfalls bereits Funktionalität, allerdings "pro hotword". Die siteId findet sich bei einem Perl- oder FHEM-Kommando-Aufruf wie üblich in $ROOM, $VALUE müßte für das hotword stehen. Würde das schon reichen, oder braucht es wirklich mehr? Wenn ja: Ideen für die Erweiterung des "handleHotword"-Attributs?
(Den kompletten JSON weiterzugeben, ist zumindest vom ersten Bauchgefühl her unnötig kompliziert).

[JensS]

Im Rhasspy-Forum habe ich nochmals den Feature Request zur Erweiterung des Dialogmanagements nach oben geholt. Ich fürchte, dass die Bitten zur Umsetzung der deaktivierten Intents sowie des zusätzlichen Slot-Aufrufs in continueSession nicht in die Version 2.6 einfließen werden und so das Dialogmanagement weiterhin in einer rudimentären Fassung bleibt. 
Habt Ihr eine Idee, wie man das den Rhasspy-Leuten schmackhaft machen könnte?

Gruß Jens

[Beta-User]

Hallo zusammen,

habe eben eine aktualisierte dev-Fassung ins svn geschubst (@drhirn: wg. github). Doku ist noch geringfügig ergänzt, und ein Fehler beim Zusammenbau des NOITIFYDEV (hoffentlich) ausgemerzt (der sich aber nicht auf das list von pah neulich ausgewirkt hatte, von daher habe ich weiter keine Idee, warum das nicht "funktioniert" hatte).

Jetzt wollte ich selbst mal AMAD.* in Betrieb nehmen, aber die Ersteinrichtungsroutine auf automagic läuft nicht sauber durch (die Doku ist auch verbesserungsfähig...). Mal sehen, ob ich noch auf den Trichter komme, woran es hängt.

Habt Ihr eine Idee, wie man das den Rhasspy-Leuten schmackhaft machen könnte?

Ich gehe davon aus, dass das bei den devs da so oder so auch auf der Liste steht; allerdings glaube ich nicht, dass die vorgeschlagene Lösung derjenigen entspricht, die am Ende Eingang in den Code findet. Das über den Namen zu machen würde jedenfalls mit gewaltig widerstreben, das fühlt sich  einfach wie ein workaround an...

[JensS]

Das über den Namen zu machen würde jedenfalls mit gewaltig widerstreben, das fühlt sich  einfach wie ein workaround an...

Das wäre (aus meiner derzeitigen Sicht) eine Lösung, welche Hermes-Konform ist und keine Änderung oder Erweiterung des Protokolls bedarf.
Die Anfrage nach deaktivierten Intents kam bereits von anderen Usern aber noch keine Lösung dazu.