Modulentwicklung für Rhasspy Sprachassistent

[Prof. Dr. Peter Henning]

Ich habe jetzt noch einmal alle Installationen erneuert. es bleibt leider beim Sachverhalt.

- Rhasspy im Docker Image, alle Funktionen in Ordnung.
- Angekoppelt ein externes MQTT2_CLIENT, das auf die Topics

hermes/tts/# rhasspy/tts/# hermes/hotword/#

susbcribed. Und bei hermes/tts/say eine Spaachausgabe macht sowie 2x JSON an den MQTT-Server zurücksendet.


Test 1: Im Rhasspy-Webinterface als TTS-Server nanoTTS ausgewählt. Subscription des eigenen MQTT-Client beibehalten. Eintippen eines Textes auf der Homepage des Webinterface
Ergebnis: 2x Sprachnachricht. Rhasspy ok. Mitschnitt des mosquitto_sub

hermes/tts/say {"text": "es ist 17 uhr 31", "siteId": "default", "lang": null, "id": "54b2cc5f-37e7-4512-b17e-a3de038924fe", "sessionId": "", "volume": 1.0}
hermes/tts/sayFinished {"siteId":"default","sessionId":"","id":"54b2cc5f-37e7-4512-b17e-a3de038924fe"}
hermes/audioServer/default/playFinished {"sessionId":"54b2cc5f-37e7-4512-b17e-a3de038924fe","id":"54b2cc5f-37e7-4512-b17e-a3de038924fe"}
hermes/tts/sayFinished {"siteId": "default", "id": "54b2cc5f-37e7-4512-b17e-a3de038924fe", "sessionId": ""}
hermes/audioServer/default/playFinished {"id": "54b2cc5f-37e7-4512-b17e-a3de038924fe", "sessionId": "54b2cc5f-37e7-4512-b17e-a3de038924fe"}

Wie man sieht, erhält Rhasspy identische Rückgaben von beiden TTS-Servern. Unterschiede nur in der Reihenfolge der Attribut-Wert-Paare und in ein paar Leerzeichen - die aber laut JSON-Spezifikation nichts ausmachen.

Test 2: Im Rhasspy-Webinterface als TTS-Server Hermes TTS ausgewählt. Subscription des eigenen MQTT-Client beibehalten. Eintippen eines Textes auf der Homepage des Webinterface
Ergebnis: 1x Sprachnachricht. Rhasspy akzeptiert die Rückgaben nicht und geht nach 30 Sekunden in einen Timeout. Mitschnitt des mosquitto_sub:

hermes/tts/say {"text": "es ist 17 uhr 32", "siteId": "default", "lang": null, "id": "1d84dddd-52a9-4d65-87c6-d69bd58b16fb", "sessionId": "", "volume": 1.0}
hermes/tts/sayFinished {"siteId":"default","id":"1d84dddd-52a9-4d65-87c6-d69bd58b16fb","sessionId":""}
hermes/audioServer/default/playFinished {"sessionId":"1d84dddd-52a9-4d65-87c6-d69bd58b16fb","id":"1d84dddd-52a9-4d65-87c6-d69bd58b16fb"}

Sag mir einer, was da los ist.

LG

pah

[JensS]

Wie sieht es bei Spracheingabe über einen Satelliten oder ein Handy aus?

[Prof. Dr. Peter Henning]

Kein Problem - die Eingabe eines Textes via Handy resultiert in entweder zwei Sprachausgaben (Fall 1) oder einer Sprachausgabe (Fall 2). Allerdings gibt es keinerlei Log-Eintrag, der auf ein Problem hinweist. Auch im Log der Rhasspy-App gibt es nichts. Das läuft also einfach durch.

LG

pah

[Beta-User]

Imo ist weiter die Erwartungshaltung zu hinterfragen, wieso Rhasspy _nicht_ in einen Timeout gehen sollte, wenn _per MQTT keine_ Audiodaten kommen... Die Zentrale ist eher schlicht nicht für TTS zuständig, wenn alles extern abläuft.
Ist beim Testszenarium mit der App das Handy als Satellit für TTS registriert oder nicht? (Soll: man. nicht registriert).

[JensS]

Allerdings gibt es keinerlei Log-Eintrag, der auf ein Problem hinweist. Auch im Log der Rhasspy-App gibt es nichts. Das läuft also einfach durch.

... bedeutet, dass es zu keinem Timeout kommt - also wie gewünscht?

[JensS]

Im Rhasspy-Forum ist mir der kleine Unterschied "" beim MQTT-Log aufgefallen.

Code Auswählen Erweitern

"sessionId": ""vs.

Code Auswählen Erweitern

"sessionId":""
Das deutet auf https://github.com/rhasspy/rhasspy-dialogue-hermes/blob/0d697cb1631880688fd484177f1cdf50351f4a3e/rhasspydialogue_hermes/__init__.py#L900 und https://github.com/rhasspy/rhasspy-server-hermes/blob/ba9ce182dc2d7387f73dc3920cc2ebe88f0b6218/rhasspyserver_hermes/__init__.py#L544 hin, welches besser

Code Auswählen Erweitern

session_id = str,oder

Code Auswählen Erweitern

session_id = None,sein sollte; besser noch, im Folgenden die tatsächliche sessionId beinhalten sollte.
Der Fehler tritt bei mir nicht auf, da immer eine sessionId vergeben wurde. Umgehen kann das Problem eventuell, wenn man die Länge von sessionId prüft und bei 0

Code Auswählen Erweitern

"sessionId": nulloder

Code Auswählen Erweitern

"sessionId": ""in tts/sayFinished an Rhasspy übergibt. https://rhasspy.readthedocs.io/en/latest/reference/#text-to-speech
tts/playFinished ist dabei nur die Kür, da die Schließung der Session bereits mit tts/sayFinished veranlasst wird.

Gruß Jens

p.s. Es bleibt zu klären, weshalb die sessionId in tts/say nicht vergeben wird. Im Rhasspy-Code scheint die siteId "default" generell einen VIP-Status zu haben und andere Wege zu nehmen, als die anderen stiteIds.
Vermutlich könnte es helfen, bei keiner Instanz (Basis und Satelliten) "default" als siteId zu nutzen. Das keine Infos zu Konfigurationen, bzw ausführliche MQTT-Mitschnitte vorliegen - mal wieder geraten.

p.p.s. Vielleicht würde ein simples

Code Auswählen Erweitern

my $tts_json = JSON->new->allow_nonref->utf8->decode( $message );genügen.

[Beta-User]

Vermutlich könnte es helfen, bei keiner Instanz (Basis und Satelliten) "default" als siteId zu nutzen.

Ob es bei keiner Instanz sein muss, wäre die Frage. Meine nennt sich "base", was aber vermutlich nichts zur Sache tut. Die Zentrale scheint mir jedenfalls auch privilegiert zu sein, und wir wollen ja gerade keine Audio-Ausgabe über Rhasspy-interne Mechanismen. Von daher meine ich weiter, dass alles über andere Satelliten-Id's laufen sollte.

Hier jedenfalls mal auszugsweise meine config:

Code Auswählen Erweitern

{
    "dialogue": {
        "satellite_site_ids": "motox,buero,büro,Küche",
        "system": "rhasspy",
        "volume": "1"
    },
    "intent": {
        "lang": "de",
        "satellite_site_ids": "motox,buero,büro,Küche,defhem",
        "system": "fsticuffs"
    },
    "mqtt": {
        "enabled": ""
    },
    "sounds": {
        "error": "${RHASSPY_PROFILE_DIR}/sounds/error.wav",
        "recorded": "${RHASSPY_PROFILE_DIR}/sounds/end_of_input.wav",
        "wake": "${RHASSPY_PROFILE_DIR}/sounds/start_of_input.wav"
    },
    "speech_to_text": {
        "satellite_site_ids": "motox,buero,büro,Küche",
        "system": "kaldi"
    },
    "text_to_speech": {
        "larynx": {
            "vocoder": "vctk_small"
        },
        "nanotts": {
            "volume": "2"
        },
        "satellite_site_ids": "motox,buero,büro,Küche",
        "system": "nanotts"
    },
    "wake": {
        "porcupine": {
            "keyword_path": "bumblebee_linux.ppn",
            "udp_audio": "0.0.0.0:12199:motox"
        },
        "satellite_site_ids": "motox,buero,büro,Küche",
        "snowboy": {
            "apply_frontend": true,
            "model": "alexa.umdl",
            "sensitivity": "0.6",
            "udp_audio": "0.0.0.0:12199:motox"
        },
        "system": "porcupine"
    }
}

Die genannten Satelliten "motox,buero,büro,Küche" sind entweder die mobile app, ein ESP32 (https://github.com/Romkabouter/ESP32-Rhasspy-Satellite/blob/master/m5atomecho.md), oder es steckt ein weiterer Rhasspy dahinter. "base" (oder "default") taucht da gar nicht auf.

Für den Abschnitt "intent" ist das dann ergänzt um "defhem", was es erlaubt, über FHEM (via msgConfig zu ROOMMATE/GUEST, vermutlich mit 0.5.11 auch via AMADComBridge) eingehende Text-Messages zur Analyse an Rhasspy weiterzusenden und die Antwort aus RHASSPY an den Messenger (und vermutlich auch an ein allgemeines TTS-System) weiterzuleiten.
Für diesen speziellen "Satelliten" ist also TTS-mäßig meine "base" (bzw. "default") nicht zuständig!

[JensS]

"base" (oder "default") taucht da gar nicht auf.

Daher wird es wahrscheinlich "Satellite siteIds:" heißen.

ESP32 (https://github.com/Romkabouter/ESP32-Rhasspy-Satellite/blob/master/m5atomecho.md)

Läuft das gut? Welches Mikro und welche Soundausgabe nutzt du dazu?
Bei mir sind es bisher rpi0w, die ihren Dienst gut tun aber natürlich empfindlich bei Stromtrennung und SD-Card-Fehlern sind.

Gruß Jens

[Beta-User]

Daher wird es wahrscheinlich "Satellite siteIds:" heißen.

...vermutlich... Wie dem auch sei, dass "default" vermutlich eine unglückliche Wahl ist und man für "externes Zeug" eine eigene Satellite/siteId vergeben sollte ist das, was mir testweise in der ganzen MQTT-Traffic-Analyse bisher gefehlt hatte.
Daher auch dieser "Zwischenruf":

Imo ist weiter die Erwartungshaltung zu hinterfragen, wieso Rhasspy _nicht_ in einen Timeout gehen sollte, wenn _per MQTT keine_ Audiodaten kommen... Die Zentrale ist eher schlicht nicht für TTS zuständig, wenn alles extern abläuft.
Ist beim Testszenarium mit der App das Handy als Satellit für TTS registriert oder nicht? (Soll: man. nicht registriert).

Läuft das gut? Welches Mikro und welche Soundausgabe nutzt du dazu?

Na ja, es ist "Micky-Maus"-like und eher eine Spielerei (ich habe aber die neuesten firmwares nicht getestet, da hat sich wohl zumindest bei den "Verschluckern" was getan). Effektiv nutze ich - wie bereits mehrfach erwähnt - mehr oder weniger ausschließlich den Shortcut-Button am Handy...
Was mir an der ESP32-Lösung (der Atom M5 ist "fertige Hardware", wenn, dann genutzt "as is" - liegt wie der Pi (ich hasse die Dinger...) grade im Eck) nicht gefällt: die Wakeword-Erkennung läuft auch auf der "base", es werden die ganze Zeit Audio-Daten gestreamt. Der Atom M5 taugt(e) allerdings zum Testen, (daher auch die "umlauts") und hat mir v.a. geholfen zu verstehen wie das mit den Satelliten - und der Zuordnung von "Verantwortlichkeiten" - eigentlich gedacht ist.
Wenn man "zu wenige Beteiligte" hat, ist das Zusammenspiel mAn. nicht besonders gut zu erkennen, weil alles scheinbar "in one" ist.

Muss das Würfelchen (M5) mal wieder rauskramen wegen der neueren Spielereien...

[JensS]

... nicht gefällt: die Wakeword-Erkennung läuft auch auf der "base", es werden die ganze Zeit Audio-Daten gestreamt.

Das ist ja genau wie bei der Handy-App. Die streamt auch die ganze Zeit. Mal sehen, ob's in demnächst was Besseres gibt - vielleicht von Mycroft.

Gruß Jens

[Beta-User]

Das ist ja genau wie bei der Handy-App. Die streamt auch die ganze Zeit. Mal sehen, ob's in demnächst was Besseres gibt - vielleicht von Mycroft.

...nur, wenn man es an der Handy-App einschaltet. Bei mir ist es meistens aus, ich nehme den "shortcut".

Zur Klarstellung: Der ESP32 streamt via MQTT, wenn ich das richtig im Kopf habe, nicht per UDP (mir letztlich egal, ich finde es in beiden Varianten nicht prickelnd).

Es gibt aber anscheinend "Bewegung" in Richtung der Miniaturisierung der Wakeword-Geschichte - mal sehen, ob bzw. wann da was vernünftiges rauskommt .


@drhirn:

so, neue Erkenntnis. Nach einem heutigen Fhem-Update trat der Fehler wieder auf. Ich hab das Modul jetzt vom update ausgeschlossen; ich hoffe, dass dies die richtige Maßnahme ist.

Das scheint daher zu kommen, dass 0.5.10 noch nicht auf github ist. Darauf bezog sich das:

Oder per wget (unter Linux):

Code Auswählen Erweitern

"wget https://svn.fhem.de/trac/export/HEAD/trunk/fhem/contrib/RHASSPY/10_RHASSPY.pm -O ./FHEM/10_RHASSPY.pm"

(Damit ich nicht immer die aktuelle version aus dem svn hier zusätzlich anhängen muss...)

[drhirn]

@drhirn:Das scheint daher zu kommen, dass 0.5.10 noch nicht auf github ist.

Im dev-Zweig sogar 0.5.11.
Gisbert verwendet doch eh SVN!?

[Prof. Dr. Peter Henning]

Auch romkabouter aus dem Rhasspy-Forum teilt meine Einschätzung, dass es sich hier um einen Fehler handelt. Ich habe ein "Issue" bei Github aufgemacht, warten wir es ab.

LG

pah

[Beta-User]

Auch romkabouter aus dem Rhasspy-Forum teilt meine Einschätzung, dass es sich hier um einen Fehler handelt. Ich habe ein "Issue" bei Github aufgemacht, warten wir es ab.

Das wollte/kann ich auch nicht ausschließen. Das Verhalten ist jedenfalls gefühlt in der Tat "komisch".

Bei mir ist nur in dem Zusammenhang weiter die Frage offen, was bei "Hermes-TTS" eigentlich die seitens der zentralen Diensteverwaltung in Rhasspy (die vermutlich für den timeout verantwortlich ist) erwartete Rückmeldung sein soll. Ist das "nur" die Info, dass die Ausgabe fertig ist, oder sind es Audiodaten via MQTT?

Unabhängig davon stellt sich die Frage, wie man externe "Dienstleister" eigentlich bei Rhasspy registrieren sollte. Und da stehe ich im Moment auf dem Standpunkt, dass jedes "autonome" Audio-Gerät (bzw. die Kombi aus Mikro und Lautsprecher) eine Art eigene siteId haben sollte (wenn FHEM/RHASSPY die Verwaltung macht, wer was bekommt, kann das auch eine "Sammel-siteId sein").

[JensS]

Bei mir ist nur in dem Zusammenhang weiter die Frage offen, was bei "Hermes-TTS" eigentlich die seitens der zentralen Diensteverwaltung in Rhasspy (die vermutlich für den timeout verantwortlich ist) erwartete Rückmeldung sein soll. Ist das "nur" die Info, dass die Ausgabe fertig ist, oder sind es Audiodaten via MQTT?

Der Dialogmanager von Rhasspy sendet den zu sprechenden Text mit tts/say und wartet auf die Bestätigung des (externen) TTS durch tts/sayFinished. Danach wird die Session vom Dialogmanager geschlossen oder an die ASR übergeben - wenn continueSession im Spiel ist.
Bleibt tts/sayFinished aus oder passt die Antwort nicht zu tts/say, kommt es zu einem Timeout.

Gruß Jens