Modulentwicklung für Rhasspy Sprachassistent

[dkreutz]

Der "Chefentwickler" von Rhasspy (Michael Hansen) ist jetzt hauptberuflich bei Mycroft AI Inc. (der Firma hinter dem Mycroft Voice Assistant) angestellt: https://community.mycroft.ai/t/mycroft-dev-sync-2021-11-29/11562/13

[Beta-User]

Weitgehend ungetestetes update:
1. neuer Tweak "extrarooms", damit kein dummy benötigt wird, um "devicelose" Räume zu erzeugen (werden auch in mainrooms gelistet);
2. neuer Setter "activateVoiceInput". Was auf der MQTT-Seite rauskommt, sieht erst mal in etwa so aus wie das Beispiel von JensS, diverse Argumente können entweder benannt oder in der richtigen Reihenfolge übergeben werden, wenn nicht, schustert das Modul was zusammen;
3. noch mehr Room-slots für "treffgenauere" sentences;
4. es müßte neue Readings geben, wenn eine Info über die hermes/hotword/toggle.*-Topics reinkommt (entsprechende subscriptions vorausgesetzt, ungetestet).

Ad 2: Umgesetzt ist der bloße Request, einen passenden publish zu veranlassen; es erfolgt im Moment noch keine Sitzungsverwaltung oder Zwischenspeicherung irgendwelcher Daten, ich kann daher nicht sagen, wer so eine Sitzung ggf. wieder wann zu macht, und insbesondere noch nicht, ob Rhasspy das von sich aus tut.
Die rausgesendete Info landet dann auch wieder im "wakeword"-Event, RHASSPY vergißt also direkt wieder, was RHASSPY wußte. Weiß noch nicht, ob das ein Problem ist, es ist aber m.E. ein Verstoß gegen den Grundsatz, dass MQTT-Geräte nicht auf die von ihnen selbst gesendeten Infos irgendwie reagieren sollten (Schleifengefahr!), deswegen erwähne ich das hier.

[JensS]

2. Beobachtung:
- Derzeit habe ich es noch nicht geschafft, in Docker ein EXTERN trainiertes Modell für die Wakeup-Engine precise zum Laufen zu bekommen. Zwar kann man das Modell (in beiden Installationsversionen) in das richtige Verzeichnis schreiben, es wird dann in Rhasspy auch zur Auswahl angeboten - aber laufen tut es (noch) nicht.

Wird die Wakeword-Engine richtig aufgerufen?

Code Auswählen Erweitern

ps ax | grep wake
Gruß Jens

[Prof. Dr. Peter Henning]

Wird die Wakeword-Engine richtig aufgerufen?

Aber natürlich - genau wie mit anderen Modellen. Habe ich jetzt erstmal zurückgestellt.

Derzeit habe ich erst einmal die andere Richtung ausgebaut, nämlich meine TTS-Ausgaben an Rhasspy angepasst und damit die eher grenzwertigen mitgelieferten TTS-Systeme umgangen. Das geht ganz einfach durch einen externen MQTT2_CLIENT, der den Topic hermes/tts/say abonniert hat.

Die Rückgabe hängt noch, denn Rhasspy erwartet natürlich eine Bestätigung.

Nach der Seite hier: http://192.168.0.115:12101/docs/reference/#tts_sayfinished sollte das mit einem

Code Auswählen Erweitern

set SpeakMQTT_CLIENT publish hermes/tts/sayFinished {"id": "f1c1e037-55ee-4af6-bc1b-633c0ba03304", "siteId": "default"}
gehen (die id kommt natürlich aus der Nachricht an den den Client).

Leider akzeptiert Rhasspy das (noch) nicht und geht nach 30 Sekunden in einen Timeout.

LG

pah

[JensS]

Da fehlt noch die Session-ID. Scheint auch in der Referenz zu fehlen...
https://docs.snips.ai/reference/hermes#text-to-speech-tts

Gruß Jens

p.s. Ein Beispiel:

Code Auswählen Erweitern

hermes/hotword/alexa/detected {"modelId": "alexa", "modelVersion": "", "modelType": "personal", "currentSensitivity": 0.5, "siteId": "wohnzimmer", "sessionId": null, "sendAudioCaptured": null, "lang": null, "customEntities": null}
hermes/dialogueManager/sessionStarted {"sessionId": "wohnzimmer-alexa-dcce0c53-2b45-4240-ba93-3748d4e3920e", "siteId": "wohnzimmer", "customData": "alexa", "lang": null}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/nlu/query {"input": "wie spät ist es", "siteId": "wohnzimmer", "id": null, "intentFilter": [], "sessionId": "wohnzimmer-alexa-dcce0c53-2b45-4240-ba93-3748d4e3920e", "wakewordId": "alexa", "lang": null, "customData": "alexa", "asrConfidence": 0.99236121, "customEntities": null}
hermes/nlu/intentParsed {"input": "wie spät ist es", "intent": {"intentName": "de.fhem:GetTime", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "Value", "value": {"kind": "Unknown", "value": "spät"}, "slotName": "Value", "rawValue": "spät", "confidence": 1.0, "range": {"start": 4, "end": 8, "rawStart": 4, "rawEnd": 8}}], "sessionId": "wohnzimmer-alexa-dcce0c53-2b45-4240-ba93-3748d4e3920e"}
hermes/intent/de.fhem:GetTime {"input": "wie spät ist es", "intent": {"intentName": "de.fhem:GetTime", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "Value", "value": {"kind": "Unknown", "value": "spät"}, "slotName": "Value", "rawValue": "spät", "confidence": 1.0, "range": {"start": 4, "end": 8, "rawStart": 4, "rawEnd": 8}}], "sessionId": "wohnzimmer-alexa-dcce0c53-2b45-4240-ba93-3748d4e3920e", "customData": "alexa", "asrTokens": [[{"value": "wie", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 3, "time": null}, {"value": "spät", "confidence": 1.0, "rangeStart": 4, "rangeEnd": 8, "time": null}, {"value": "ist", "confidence": 1.0, "rangeStart": 9, "rangeEnd": 12, "time": null}, {"value": "es", "confidence": 1.0, "rangeStart": 13, "rangeEnd": 15, "time": null}]], "asrConfidence": 0.99236121, "rawInput": "wie spät ist es", "wakewordId": "alexa", "lang": null}
hermes/dialogueManager/endSession {"customData": "alexa","intentFilter": null,"sessionId": "wohnzimmer-alexa-dcce0c53-2b45-4240-ba93-3748d4e3920e","siteId": "wohnzimmer","text": "Es ist 19 Uhr 9"}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/tts/say {"text": "Es ist 19 Uhr 9", "siteId": "wohnzimmer", "lang": null, "id": "ebfdc14c-755e-4f5a-a343-e091eec81501", "sessionId": "wohnzimmer-alexa-dcce0c53-2b45-4240-ba93-3748d4e3920e", "volume": null}
hermes/tts/sayFinished {"siteId": "wohnzimmer", "id": "ebfdc14c-755e-4f5a-a343-e091eec81501", "sessionId": "wohnzimmer-alexa-dcce0c53-2b45-4240-ba93-3748d4e3920e"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/dialogueManager/sessionEnded {"termination": {"reason": "nominal"}, "sessionId": "wohnzimmer-alexa-dcce0c53-2b45-4240-ba93-3748d4e3920e", "siteId": "wohnzimmer", "customData": "alexa"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "dialogueSession"}

[Prof. Dr. Peter Henning]

Nö, kanns nicht sein. Weder bekomme ich bei hermes/tts/say eine sessionId, noch akzeptiert Rhasspy ein

Code Auswählen Erweitern

set ... publish hermes/tts/sayFinished {"id": "8b4937bc-1338-4e3c-b2da-cd977006af7a", "siteId": "default", "sessionId": null}

LG

pah

[Beta-User]

Wegen der generischen msgDialog-Schnittstelle habe ich auch etwas mit dem tts-Topic rumgespielt. Weitgehend ungetestetes Zwischenergebnis anbei, für Kommentare fehlt mir grade die Zeit.

RHASSPY braucht wohl eine siteId...

[Prof. Dr. Peter Henning]

Aber das ist doch drin, mit dem Wert "default"

LG

pah

[JensS]

@pah

Suchst du sowas? https://github.com/hcooper/snips-tts-polly/blob/master/snips-tts-polly.py

Vielleicht lässt sich im Kontext zu TTS  das Problem des lokalen Echos in hermes/dialogueManager/continueSession (erweiterter Dialog) behandeln. Ein Beispiel...

Ich: Rhasspy, buche ein Zugticket.
Rhasspy: Wohin? Berlin oder Düsseldorf?
Ich: Berlin.
Rhasspy: Wann möchtest du starten?
...

In der Zeit, wenn Rhasspy nachfragt, bleibt das Mikro offen. Sobald die Frage gestellt wurde, springt die SST wieder an. Die Sprachdaten werden vom TTS als RIFF an den Satelliten gesandt.
Dieser muss das dann erstmal verarbeiten und ausgeben, Dabei kommt es zwangsläufig zu Latenzen, welche die SST falsch als Eingabe versteht. Dadurch sind Dialoge extrem fehleranfällig.
Meine Notlösung war ein "Local Command" beim "Local Playing" des Satelliten.

Code Auswählen Erweitern

#!/bin/bash
amixer -q -c 'seeed2micvoicec' sset Capture 0
cat $1 > /tmp/handy.wav && aplay /tmp/handy.wav
amixer -q -c 'seeed2micvoicec' sset Capture 95



Gruß Jens

[Prof. Dr. Peter Henning]

Suchst du sowas? https://github.com/hcooper/snips-tts-polly/blob/master/snips-tts-polly.py

Nö, danke. Polly funktioniert bei mir seit Jahren auf allen Devices, die Anleitung dazu findet man auch in dem Buch "SmartHome mit FHEM". Ich habe sogar noch die alten Android-Apps mit der Stimme "Marlene", bevor der Hersteller von Amazon geschluckt wurde.

Meine Bose-SoundTouch-Devices oder sonstige Ausgabegeräte (auch Linux-Kisten) bekommen dann ein maßgefertigtes MP3 geliefert, gerne poste ich den Code hier noch einmal.

Vielleicht lässt sich im Kontext zu TTS  das Problem des lokalen Echos in sessionContinue (erweiterter Dialog) behandeln. Ein Beispiel...

Ich: Rhasspy, buche ein Zugticket.
Rhasspy: Wohin? Berlin oder Düsseldorf?
Ich: Berlin.
Rhasspy: Wann möchtest du starten?

Habe ich doch schon gelöst, mit dem ChatBot. Das läuft wirklich.

Das Problem ist, dass die Spracheingabe STT nicht verarbeitet wird, bevor sie abgeschlossen wurde. Also muss man nach der Antwort mit TTS die Spracherkennung neu starten, und aktives Dialogmanagement in FHEM betreiben.

LG

pah

[Beta-User]

Anbei ein update zu dem gestrigen Experiment und ein paar Anmerkungen und Vorschläge.

und aktives Dialogmanagement in FHEM betreiben.

Darauf zielte diese Bemerkung:

RHASSPY braucht wohl eine siteId...

Etwas Theorie:
Im Rhasspy-Ökosystem wird vorausgesetzt, dass jeder Teilnehmer (prinzipiell) bekannt ist und "seine" spezifische Rolle spielt. Bisher hatte RHASSPY (fast) keine aktive Rolle in diesem Ökosystem, sondern war nur "passive listener" mit gelegentlichen "Zwischenrufen" (nämlich dann, wenn eine Aktion erfolgreich ausgeführt worden ist oder "speak" bzw. "textCommand" als "one shot"-Aktionen ausgelöst wurden).
Will man Dialoge haben, muss man aktiv ins Geschehen eingreifen, was eben bedeutet, dass jede RHASSPY-Instanz auch eine "Kennung" innerhalb des Rhasspy-Ökosystems braucht, also eine siteId.
Wenn Babble diese Rolle (teilweise) auch spielen soll, gilt hier dasselbe, auch Babble (bzw. jede Instanz) braucht eine eigene siteId.

Deswegen hat RHASSPY ab sofort eine (optional konfigurierbare) siteId (default: "<language><fhemId>").

Für Babble, würde ich "<language><fhemId>.<Babble-Name>" vorschlagen (und hoffe, das wird später klarer, warum).

Bin mit dem Testen noch nicht an diese Stelle gekommen, gehe aber davon aus, dass man diese (und ggf. die von Babble) dann wie andere "normale Satelliten" auch jeweils für die Dienste in der Rhasspy-Weboberfläche registieren muss, die man nutzen will. Damit könnte man z.B. den "Babble-Satelliten" zum TTS-System für beliebige andere Satelliten machen.

Babble muss dazu nur in der Lage sein, das Dialogmanagement zu bedienen.
Meine aktuelle Idee zum Gesamtkonzept wäre nun, dass man
- RHASSPY optional in der DEF mitteilen kann, dass Babble integriert werden soll
- RHASSPY kann dann z.B. seine setter um Babble-spezifische Optionen ergänzen (vorausgesetzt, es gibt z.B. eine Babble-Definition). Das könnte z.B. genutzt werden, um RHASSPY die Anweisung zu geben, für einen bestimmten Satelliten die Info rauszuhauen, dass STT fertig ist.
- RHASSPY greift dann bestimmte (tbd) Messages ab und generiert entweder Events oder reicht das an eine oder mehrere noch zu spezifizierende(n) Schnittstelle(n) bei Babble weiter.
Damit würde quasi RHASSPY als "erweitertes" IO-Modul für Babble genutzt, daher auch der Vorschlag, durch die siteId kenntlich zu machen, dass  RHASSPY und Babble eine Art "Gruppe" sind.

Ein showcase für das dynamische Ergänzen des setters ist mal eingebaut.

Den Vorteil dieser Konstruktion gg. einer separaten MQTT-Anbindung sehe ich darin, dass RHASSPY sowieso in Teilen ein Sitzungsmanagement betreibt, den Traffic mitschneidet bzw. auch auswertet und die notwendigen internen Funktionen schon eingebaut hat, um die MQTT-Schnittstelle von Rhasspy zu beliefern.



Die allgemeine msgDialog-Schnittstelle "zuckt" auch schon, es hakt noch an der Weitergabe an die nlu-Query, aber immerhin kann man (in meinem Fall per Telegram) was an RHASSPY senden und erhält ein "blink" sowie eine "timeout"-Message.

Wer diesen Teil mittesten will, braucht:
- eine msgConfig-Instanz
- einen ROOMMATE oder GUEST, der für msgConfig eingerichtet ist (bei mir war vorher schon ein msgDialog eingerichtet gewesen, im Zweifel muss man erst mal dieser Anleitung bis dahin folgen, dann man darüber ein "hello world" bekommt)
- im RHASSPY-Device:

Code Auswählen Erweitern

attr rhasspy rhasspyMsgDialog allowed=<Name(n) der ROOMMATE-Instanz>
keepOpenDelay=90
Schickt man dann als zugelassener Teilnehmer ein "hi rhasspy" an FHEM, sollte eine Antwort kommen...

Wie gesagt: die weitere Verarbeitung von danach gesendeten Inhalten klappt noch nicht. Vermutlich ist es keine große Sache, das soweit zu fixen, dass man einfache Anweisungen raushauen kann. Man kann alle Parameter optional ändern, also z.B. das "hi rhasspy" durch "rapunzel lass dein haar herab" ersetzen.

Status: Dieser Teil scheint ungefährlich zu sein.



Prinzipiell stelle ich mir jetzt die Frage, warum es sein muss, dass RHASSPY die Sitzungen standardmäßig schließt, wenn was erkannt wurde. Daher gibt es jetzt den sehr experimentellen Schlüssel "keepOpenDelay" in der DEF. Wer das testen will sei gewarnt: im Code von gestern war eine loop versteckt, die hoffentlich jetzt ausgebaut ist, selbst Testen kann ich aber erst über das WE. (Symptom: rasanter Speicherverbrauch!).Status: Diesen Schlüssel zu aktivieren könnte gefährlich sein!

Bin mal auf eure Rückmeldungen gespannt!

[JensS]

Nö, danke. Polly funktioniert bei mir seit Jahren auf allen Devices,

Oha, seit Jahren mit Hermes-MQTT? Im Link sind einige Infos zur Reihenfolge der Topics für eine separate TTS versteckt...

Aus Interesse - kannst du bitte einen MQTT-Mitschnitt posten?

Gruß Jens

[Prof. Dr. Peter Henning]

Oha, seit Jahren mit Hermes-MQTT?

Nein, das habe ich nicht gesagt.

Sondern per direktem Aufruf und FHEM2FHEM-Kopplung.  Dafür mit anderen Features, z.B. kann ich die vordefinierte Nachricht Nr. 123 einfach in einen Text zum Sprechen einbinden per :123:, und das Caching funktioniert auch gut.

Die MQTT-Anbindung habe ich jetzt erst mit einem MQTT2_CLIENT, einem MQTT2_DEVICE und etwa 10 Zeilen Code realisiert.


LG

pah

[Beta-User]

Hallo zusammen,

die msgConfig-Schnittstelle scheint jetzt zumindest prinzipiell mal zu laufen, man kann also mit RHASSPY direkt chatten. Um dann z.B. zu wissen, dass jetzt z.B. "Babble_DoIt()" aufzurufen wäre, wäre es noch ein kleiner Schritt.

activateVoiceInput ist auch getestet und läuft.

Damit auch wieder mehr Leute Anlass haben mitzutesten, gibt es jetzt eine Möglichkeit, mehrere Antworten anzugeben. Das klappt erst mal nur bei den "flachen" Antworten, also da, wo es keine weitere Verzweigung mehr gibt. Alternativen werden mit pipe getrennt, es wird gewürfelt.
Beispiel:

Code Auswählen Erweitern

  "responses": {
    "DefaultConfirmation": "Gerne!|schon erledigt|ok|jawohl|stets zu diensten",
    "DefaultError": "Da paßt irgend was nicht|das klappt so nicht"

Im Zweig "inOperation" würde es z.B. (noch) nicht gehen.

Die MQTT-Anbindung habe ich jetzt erst mit einem MQTT2_CLIENT, einem MQTT2_DEVICE und etwa 10 Zeilen Code realisiert.

OK. Sag einfach Bescheid, wenn klarer ist, wie der nächste Schritt aussehen könnte/müßte.

[Beta-User]

  Scheinbar fehlt zu der msgConfig-Geschichte entweder Info oder ein "teaser", oder ist alles klar?

Anbei daher mal ein paar "real-life"-Beispiele als screenshots .

Grundsätzlicher Ablauf ist:
- Es wird eine Sitzung per "open"-Text geöffnet;
- dann kann man alles schreiben, was man auch sagen könnte;
- die (sonst gesprochene) Antwort kommt als Text an den Schreiber zurück;
- dann kann man weitere Anweisungen geben, ...
... bis entweder der timeout nach der letzten eingehenden Message abgelaufen ist, oder der "close"-Text gesendet wird.

Benötigt wird:
- ein msgConfig-Device. Das sorgt dafür, dass eingehende Textnachrichten (hier: von Telegram, das sollte aber mit jedem anderen einbindbaren Messenger-Dienst genauso funktionieren) einem ROOMMATE oder GUEST-Device zugeordnet wird und darüber dann auch wieder der Empfänger für die Antwort ermittelt werden kann;
- die siteId (möglichst: das, was im Internal "siteId" zu finden ist!) der RHASSPY-Instanz muss für die NLU-Funktion bei Rhasspy eingetragen sein;
- alle (zugelassenen) ROOMMATE bzw. GUEST-Devices müssen im "allowed"-key im Attribut "rhasspyMsgDialog" aufgeführt sein. Das ist der einzige zwingende Parameter;
- zu empfehlen ist auch, "keepOpenDelay" im Attribut "rhasspyMsgDialog" zu setzen, sonst schließt RHASSPY die Schnittstelle uU. schneller als man tippen kann...

Eigentlich also total easy (wenn man einen funktionierenden RHASSPY hat), und im Moment bin ich am überlegen, ob es nicht sinnvoll wäre, einen dDT "info" zu erfinden und den "GetState"-Intent etwas aufzubohren, damit man darüber vielleicht
- beliebige Readings abfragen und/oder auch
- update-Anfragen raushauen
kann.
Mein einziger msgDialog befasst(e) sich mit Spritpreisen, und die HTTPMOD-Devices dafür brauchen eigentlich immer erst eine "reread"-Anweisung, weil ich das ganze so selten nutze...

Da das ganze an sich stabil ist und m.E. auch eine sinnvolle Erweiterung darstellt, werde ich die commandref noch etwas überarbeiten und das ganze dann bei Gelegenheit ins svn einchecken...