Modulentwicklung für Rhasspy Sprachassistent

Beta-User · 23 Dezember 2021, 09:44:03

Zitat von: JensS am 23 Dezember 2021, 08:16:14
Du hast dafür bestimmt schon eine Lösung - war mal wieder zu faul, das Modul durchzustöbern...

Das ganze ist "einfacher" gestrickt, man braucht kein extra Attribut (für sowas ein Attribut zu "verschwenden" halte ich für überflüssig), und wie es funktioniert, hatte ich eigentlich ansatzweise schon erläutert - es gibt einen "globalen" Hauptschalter in der DEF, in den man auch gleich den konkreten timeout (in Sekunden) eintragen kann, den man haben will:

Code Auswählen

sessionTimeout=15
Der wirkt dann für alle Satelliten.

Über spezielle Readings kann man dieses allgemeine Verhalten überlagern, indem man pro Satelliten einen eigenen timeout setzt. Man kann diesen auch auf "0" setzen, dann wird für den betreffenden Satelliten das "mach gleich zu"-Verhalten erzwungen (z.B. "setreading <rhasspy> sessionTimeout_wohnzimmer 0"). Dazu steht was in der commandref.

So jedenfalls die Theorie

. Damit kann man z.B. auf ein bestimmtes wakeword reagieren und dann den timeout ein- oder ausschalten, so dass z.B. nur "Mann" testet...

Gisbert · 25 Dezember 2021, 19:17:33

Hallo Jörg,

heute habe ich erstmalig eine kleine unerwartete Reaktion gefunden. Änderungen am gesprochenen Text und der Installation habe ich in den letzten Tagen keine vorgenommen.

Der Befehl wird ausgeführt, aber als Antwort bekomme ich in etwa das folgende:

ZitatZu Diensten [editiert] senkrechter Strich Gerne [editiert] senkrechter Strich Ok usw.

Viele Grüße Gisbert

Edit: es wird senkrechter Strich und nicht nur Strich ausgegeben

Beta-User · 26 Dezember 2021, 09:54:34

Welche version war das?
Hast du ggf. auch den Intent, den du aufgerufen hattes?

@all: Habe noch ein paar Kleinigkeiten im svn aufgeräumt, u.a. gibt es im Fehlerfall bei SetOnOff jetzt (hoffentlich) qualifiziertere Rückmeldungen, an was es hapert.

Aktuelle version bekommt man am einfachsten per

Code Auswählen

{ Svn_GetFile('contrib/RHASSPY/10_RHASSPY.pm', 'FHEM/10_RHASSPY.pm') } (Dann Neustart oder reload)

Oder per wget (unter Linux):

Code Auswählen

"wget https://svn.fhem.de/trac/export/HEAD/trunk/fhem/contrib/RHASSPY/10_RHASSPY.pm -O ./FHEM/10_RHASSPY.pm"
Nix funktional revolutionäres, eher Code-Vereinfachungen...

Prof. Dr. Peter Henning · 26 Dezember 2021, 10:55:43

Ich habe immer noch ein Problem mit der TTS-Umelitung aus Rhasspy

Wenn ich in der Rhasspy-Oberfläche als Text-to-Speech (TTS) "Hermes MQTT" einstelle, und mit einem MQTT2_CLIENT+DEVICE auf hermes/tts/say lausche, kann ich problemlos die Sprachausgabe von Rhasspy auf mein System umleiten. Allerdings erwartet Rhasspy auch eine Bestätigung. Laut Beschreibung des Hermes-Protokolls muss diese die entsprechenden Parameter aus dem "say"-Aufruf enthalten. Mit dem Code

Code Auswählen

sub speakMQTT($$){
  my ($name,$evt) = @_;
  my $dec      = decode_json($evt);
  my $text     = $dec->{'text'};
  my $siteid   = $dec->{'siteId'};
  my $sessionid   = $dec->{'sessionId'};
  my $id       = $dec->{'id'};
  my %enc      = ( 'id' => $id, 'siteId' => $siteid, 'sessionId' => $sessionid);
  my $json = encode_json \%enc;

  speak($siteid,$text); # Das ist mein TTS-System
 
  fhem('set SpeakMQTT_Client publish hermes/tts/sayFinished '.$json);
 }

geht es aber nicht - Rhasspy wartet auf die Bestätigung und geht nach 30 Sekunden in ein Timeout. Hat jemand eine Idee, woran das liegen kann?

LG

pah

Gisbert · 26 Dezember 2021, 12:31:22

Hallo Jörg,

ich hatte eigentlich die bis gestern aktuelle Version von RHASSPY im FHEM-Verzeichnis. Der Fehler kam bei mehreren Befehlen, es waren aber alle vom Typ setOn/setOff.

Ich hab die aktuelle Version runtergeladen, ein Upload durchgeführt und im RHASSPY-Modul ein update all durchgeführt - danach läuft jetzt alles fehlerfrei.

Vorher stand das im Reading state:

Code Auswählen

http://192.168.1.46:12101/api/intents: empty answer received

Viele Grüße Gisbert

Beta-User · 26 Dezember 2021, 13:30:42

Schön, dass es jetzt wieder funktioniert.

@pah: Kann es sein, dass der Audio-Server auf Daten wartet (playWav)?

JensS · 26 Dezember 2021, 14:01:35

@pah
... wie schon erwähnt, wäre ein MQTT-Mitschnitt interessant.
TTS ist ja nur ein Teil des Systems. Wurde der laufende Dialog vor TTS in continueSession versetzt oder mit endSession auf sessionEnded vorbereitet?

Gruß Jens

Prof. Dr. Peter Henning · 26 Dezember 2021, 15:06:30

@Beta-User:

ZitatKann es sein, dass der Audio-Server auf Daten wartet

Kein Audioserver. Schau mal auf <IP-Adresse Rhasspy>:12101/docs/text-to-speech/

So wie ich das verstehe, gibt es eine Message an hermes/tts/say, wenn diese beendet ist muss etwas an hermes/tts/sayFinished zurückkommen.

@JensS: Mag ja sein - aber wo steht das in der Dokumentation?

Der Ablauf ist seltsam, Das Rhasspy-Log sieht so aus

Zitat[ERROR:2021-12-26 14:53:19,770] rhasspyserver_hermes:
Traceback (most recent call last):
File "/usr/lib/rhasspy/.venv/lib/python3.7/site-packages/quart/app.py", line 1821, in full_dispatch_request
result = await self.dispatch_request(request_context)
File "/usr/lib/rhasspy/.venv/lib/python3.7/site-packages/quart/app.py", line 1869, in dispatch_request
return await handler(**request_.view_args)
File "/usr/lib/rhasspy/rhasspy-server-hermes/rhasspyserver_hermes/__main__.py", line 1699, in api_text_to_speech
results = await asyncio.gather(*aws)
File "/usr/lib/rhasspy/rhasspy-server-hermes/rhasspyserver_hermes/__main__.py", line 1685, in speak
say_chars_per_second=say_chars_per_second,
File "/usr/lib/rhasspy/rhasspy-server-hermes/rhasspyserver_hermes/__init__.py", line 617, in speak_sentence
handle_finished(), messages, message_types, timeout_seconds=timeout_seconds
File "/usr/lib/rhasspy/rhasspy-server-hermes/rhasspyserver_hermes/__init__.py", line 995, in publish_wait
result_awaitable, timeout=timeout_seconds
File "/usr/lib/python3.7/asyncio/tasks.py", line 423, in wait_for
raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
[DEBUG:2021-12-26 14:52:49,763] rhasspyserver_hermes: Handling TtsSayFinished (topic=hermes/tts/sayFinished, id=39ebcd9f-2234-4dde-88d7-60bfa95ae20b)
[DEBUG:2021-12-26 14:52:49,763] rhasspyserver_hermes: Handling TtsSayFinished (topic=hermes/tts/sayFinished, id=fcf40d25-a095-4cf4-a774-b71db64888aa)
[DEBUG:2021-12-26 14:52:49,762] rhasspyserver_hermes: Handling TtsSayFinished (topic=hermes/tts/sayFinished, id=aa66560d-d6f9-4c64-89e8-a947d9439044)
[DEBUG:2021-12-26 14:52:49,762] rhasspyserver_hermes: Handling TtsSayFinished (topic=hermes/tts/sayFinished, id=acf9739e-23c9-4a99-b6ba-8114d0c9e500)
[DEBUG:2021-12-26 14:52:49,735] rhasspyserver_hermes: Publishing 141 bytes(s) to hermes/tts/say
[DEBUG:2021-12-26 14:52:49,735] rhasspyserver_hermes: -> TtsSay(text='Das ist ein Test', site_id='default', lang=None, id='06ea1d58-b7b8-494c-ac47-d099f9b201f2', session_id='', volume=1.0)
[DEBUG:2021-12-26 14:52:49,733] rhasspyserver_hermes: TTS timeout will be 30 second(s)
[ERROR:2021-12-26 14:51:28,242] rhasspyserver_hermes:
Traceback (most recent call last):
File "/usr/lib/rhasspy/.venv/lib/python3.7/site-packages/quart/app.py", line 1821, in full_dispatch_request
result = await self.dispatch_request(request_context)
File "/usr/lib/rhasspy/.venv/lib/python3.7/site-packages/quart/app.py", line 1869, in dispatch_request
return await handler(**request_.view_args)
File "/usr/lib/rhasspy/rhasspy-server-hermes/rhasspyserver_hermes/__main__.py", line 1699, in api_text_to_speech
results = await asyncio.gather(*aws)
File "/usr/lib/rhasspy/rhasspy-server-hermes/rhasspyserver_hermes/__main__.py", line 1685, in speak
say_chars_per_second=say_chars_per_second,
File "/usr/lib/rhasspy/rhasspy-server-hermes/rhasspyserver_hermes/__init__.py", line 617, in speak_sentence
handle_finished(), messages, message_types, timeout_seconds=timeout_seconds
File "/usr/lib/rhasspy/rhasspy-server-hermes/rhasspyserver_hermes/__init__.py", line 995, in publish_wait
result_awaitable, timeout=timeout_seconds
File "/usr/lib/python3.7/asyncio/tasks.py", line 423, in wait_for
raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
[DEBUG:2021-12-26 14:50:58,245] rhasspyserver_hermes: Handling TtsSayFinished (topic=hermes/tts/sayFinished, id=fcf40d25-a095-4cf4-a774-b71db64888aa)
[DEBUG:2021-12-26 14:50:58,244] rhasspyserver_hermes: Handling TtsSayFinished (topic=hermes/tts/sayFinished, id=aa66560d-d6f9-4c64-89e8-a947d9439044)
[DEBUG:2021-12-26 14:50:58,244] rhasspyserver_hermes: Handling TtsSayFinished (topic=hermes/tts/sayFinished, id=acf9739e-23c9-4a99-b6ba-8114d0c9e500)
[DEBUG:2021-12-26 14:50:58,218] rhasspyserver_hermes: Publishing 141 bytes(s) to hermes/tts/say
[DEBUG:2021-12-26 14:50:58,218] rhasspyserver_hermes: -> TtsSay(text='Das ist ein Test', site_id='default', lang=None, id='bf2a5edc-5bcf-45a8-a5ed-6d476e6cee01', session_id='', volume=1.0)
[DEBUG:2021-12-26 14:50:58,216] rhasspyserver_hermes: TTS timeout will be 30 second(s)
[ERROR:2021-12-26 14:50:24,531] rhasspyserver_hermes:
Traceback (most recent call last):
File "/usr/lib/rhasspy/.venv/lib/python3.7/site-packages/quart/app.py", line 1821, in full_dispatch_request
result = await self.dispatch_request(request_context)
File "/usr/lib/rhasspy/.venv/lib/python3.7/site-packages/quart/app.py", line 1869, in dispatch_request
return await handler(**request_.view_args)
File "/usr/lib/rhasspy/rhasspy-server-hermes/rhasspyserver_hermes/__main__.py", line 1699, in api_text_to_speech
results = await asyncio.gather(*aws)
File "/usr/lib/rhasspy/rhasspy-server-hermes/rhasspyserver_hermes/__main__.py", line 1685, in speak
say_chars_per_second=say_chars_per_second,
File "/usr/lib/rhasspy/rhasspy-server-hermes/rhasspyserver_hermes/__init__.py", line 617, in speak_sentence
handle_finished(), messages, message_types, timeout_seconds=timeout_seconds
File "/usr/lib/rhasspy/rhasspy-server-hermes/rhasspyserver_hermes/__init__.py", line 995, in publish_wait
result_awaitable, timeout=timeout_seconds
File "/usr/lib/python3.7/asyncio/tasks.py", line 423, in wait_for
raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
[DEBUG:2021-12-26 14:49:54,529] rhasspyserver_hermes: Handling TtsSayFinished (topic=hermes/tts/sayFinished, id=aa66560d-d6f9-4c64-89e8-a947d9439044)
[DEBUG:2021-12-26 14:49:54,528] rhasspyserver_hermes: Handling TtsSayFinished (topic=hermes/tts/sayFinished, id=acf9739e-23c9-4a99-b6ba-8114d0c9e500)
[DEBUG:2021-12-26 14:49:54,503] rhasspyserver_hermes: Publishing 141 bytes(s) to hermes/tts/say
[DEBUG:2021-12-26 14:49:54,503] rhasspyserver_hermes: -> TtsSay(text='Das ist ein Test', site_id='default', lang=None, id='8a32f023-b00c-421f-ab6d-80782311fe2a', session_id='', volume=1.0)
[DEBUG:2021-12-26 14:49:54,501] rhasspyserver_hermes: TTS timeout will be 30 second(s)

Das ist natürlich von unten nach oben zu lesen: Hier habe ich 3x nacheinander in der Rhasspy-Weboberfläche den Service "speak" aufgerufen, jeweils mit dem text "Das ist ein Test". Der wird auch wunderbar ausgegeben, und jedesmal liefere ich (mit der gleichen Id) ein SayFinished zurück. Das Log sagt auch, dass ein SayFinished gehandled wird - das hat aber eine andere Id, die ich auch nicht migeliefert habe. Sondern mein Logging auf der FHEM-Seite besagt

Zitat2021.12.26 14:48:27 1: set SpeakMQTT_Client publish hermes/tts/sayFinished {"siteId":"default","sessionId":"","id":"0dc56167-53b5-4173-a8a1-5aa8ffbdf638"}
2021.12.26 14:49:54 1: [speakTablet] name=Tab2.EG text=Das ist ein Test
2021.12.26 14:49:54 1: [speakMQTT] siteId=default text=Das ist ein Test
2021.12.26 14:49:54 1: set SpeakMQTT_Client publish hermes/tts/sayFinished {"id":"8a32f023-b00c-421f-ab6d-80782311fe2a","sessionId":"","siteId":"default"}
2021.12.26 14:50:58 1: [speakTablet] name=Tab2.EG text=Das ist ein Test
2021.12.26 14:50:58 1: [speakMQTT] siteId=default text=Das ist ein Test
2021.12.26 14:50:58 1: set SpeakMQTT_Client publish hermes/tts/sayFinished {"sessionId":"","id":"bf2a5edc-5bcf-45a8-a5ed-6d476e6cee01","siteId":"default"}
2021.12.26 14:52:49 1: [speakTablet] name=Tab2.EG text=Das ist ein Test
2021.12.26 14:52:49 1: [speakMQTT] siteId=default text=Das ist ein Test
2021.12.26 14:52:49 1: set SpeakMQTT_Client publish hermes/tts/sayFinished {"sessionId":"","id":"06ea1d58-b7b8-494c-ac47-d099f9b201f2","siteId":"default"}

Das ist hier von oben nach unten zu lesen, und wie man sieht, gebe ich dieselbe id zurück, die mit der say-Message empfangen wurde.

Was mich stutzig macht, ist dass die sayFinished-Messages offenbar von Rhasspy nicht abgerufen werden, sondern in der Queue verbleiben. Darum werden dann im letzten (oder beim Rhasspy-Log obersten Eintrag) mehrere solcher sayFinished-Messages abgearbeitet, von denen aber offenbar keine die richtige Id hat.

Also ist die Frage: Was sorgt in Rhasspy dafür, dass die von mir zurückgelieferte Id in eine andere verbogen wird?

LG

pah

Beta-User · 26 Dezember 2021, 15:10:04

SayFinished ist lt. meinem Verständnis der Doku die Info, dass die Konvertierung in Sound durch ist, nicht die Sound-Ausgabe...

Prof. Dr. Peter Henning · 26 Dezember 2021, 16:04:05

Ich habe jetzt die Bestätigungsnachricht sowohl an

hermes/audioServer/default/playFinished

als auch an

hermes/audioServer/default/playBytes/$id

($id ersetzt durch die Message-id) gesendet. Im Falle von playFinished tut sich gar nichts, im zweiten Fall gibt es vor dem Timeout auch noch einen Audioserver-Error.

Aus meiner Sicht ist das auch nicht sehr logisch: Rhasspy weiß nur, dass es ein "say" abgesetzt hat, es sollte also auf eine Rückmeldung von say warten.

Aber gut, auch das habe ich nioch ausprobiert: Zuerst den text nach say gepublished, prinma, wird ausgegeben. Dann von FHEM aus playBytes mit einer Länge von 0 aufgerufen, und dann eine Nachricht an playFinished abgesetzt

Zitat2021.12.26 15:58:35 1: set SpeakMQTT_Client publish hermes/audioServer/default/playBytes/muellIdFromFhem {"wav_bytes":0,"siteId":"default","requestId":"muellIdFromFhem"}
2021.12.26 15:58:35 1: set SpeakMQTT_Client publish hermes/audioServer/default/playFinished {"id":"muellIdFromFhem"}

(Das das mit dem beliebigen Id-String funktioniert, habe ich schon beim Abarbeiten eines Intents gecheckt, den ich von außen an Rhasspy sende)

Ergebnis dasselbe: Audioserver Fehler, und dann wieder der Timeout. Die Frage, worauf Rhasspy eigentlich wartet, ist damit immer noch ungeklärt.

LG

pah

JensS · 26 Dezember 2021, 21:33:41

@pah
Dein TTS gibt den Text von hermes/dialogueManager/continueSession oder von hermes/dialogueManager/endSession wieder.
Dabei wird vom Dialog-Manager im Schritt vorher bestimmt, ob die Session anschließend offen bleibt oder geschlossen wird.
https://docs.snips.ai/reference/dialogue#end-session
https://rhasspy.readthedocs.io/en/latest/reference/#dialogue-manager
Aus deinen Log-Auszügen kann ich diese Info nicht entnehmen. Ein Mitschnitt über mosquitto_sub bringt bestimmt schneller Licht ins Dunkel.

Gruß Jens

Beta-User · 27 Dezember 2021, 06:31:59

@pah: Wenn RHASSPY diese Rolle beim Messenger-Dialog übernimmt, sind da nur zwei Datenpunkte im JSON:

Code Auswählen

my $sendData =  { 
        id           => $data->{id},
        siteId       => $hash->{siteId}
    };
    my $json = _toCleanJSON($sendData);
    IOWrite($hash, 'publish', qq{hermes/tts/sayFinished $json});

Als spec-Notiz habe ich mir diesen Link notiert: https://rhasspy.readthedocs.io/en/latest/reference/#tts_say

Da in diesem Fall FHEM selbst der Dialogpartner ist, paßt auch die siteId, du müßtest die mAn. anders setzen.

Da du die Befehle "drumrum" scheinbar fertig hast nochmal das Angebot, RHASSPY für diesen Teil direkt als IO-Modul zu erweitern, tts/say wird "eh" schon abonniert...

Prof. Dr. Peter Henning · 28 Dezember 2021, 07:18:47

Ich werde es heute nochmal probieren (Golf fällt vermutlich ins Wasser..).

Ich denke nicht, dass das eine Frage des "Dialogmanagements" ist - wir wissen einfach noch nicht, auf welche Message Rhasspy dann wartet (sayFinished offenbar nicht, und ein PlayBytes mit Null Bytes löst einen Fehler aus).

Zitat
SayFinished ist lt. meinem Verständnis der Doku die Info, dass die Konvertierung in Sound durch ist, nicht die Sound-Ausgabe...

So steht es auf der einen Seite (Link in der Rhasspy-Oberfläche). Aber hier https://rhasspy.readthedocs.io/en/latest/reference/#tts_say steht das Gegenteil:

Zitathermes/tts/sayFinished (JSON)

Indicates that the text to speech system has finished speaking

Möglichweise werde ich wirklich mal MQTT bei einem internen TTS-Service mitschneiden müssen. Obwohl mich so etwas ärgert, denn ein Protokoll wie Hermes sollte sauber dokumnetiert sein, ohne dass man erst ein solches Reverse Engineering betreiben muss.

LG

pah

Beta-User · 28 Dezember 2021, 07:29:41

Na ja, "eigentlich" ist die Doku von Rhasspy eher als sehr gut zu bezeichnen, und vermutlich ist mein erster Link veraltet, und "sayFinished" ist wirklich die Info, dass das Sprechen fertig ist. Jedenfalls habe ich bei eher oberflächlicher Suche keine Probleme wahrgenommen mit der dargestellten Messenger-Variante (hatte vorher mit einigen anderen Elementen im JSON gespielt, und da hat das nicht so gut funktioniert).

"hermes" war halt nach meinem Verständnis die Entwicklung von Snips, die ja nicht mehr exisitieren, und am ehesten von Rhasspy-Seite weiterentwickelt wird, von daher ist der Wunsch nach "noch besserer" Doku zwar nachvollziehbar, ich sehe aber nicht, wer den einlösen sollte...

JensS · 28 Dezember 2021, 09:24:35

Also ich finde die Doku von Snips gut. Leider hat Rhasspy nicht alle Funktionalitäten übernommen.
Die Beendigung der Session ist aus meiner Sicht eindeutig:
continueSession: Die Session wird nach der TTS mit den Optionen aus der continueSession-Anweisung wieder aufgenommen.
endSession: Wartet auf sayFinished und schließt dann die Session mit SessionEnd.
kein Text in continueSession bzw. endSession: DIe Session wird sofort geschlossen.
Dazu gibt ja einen Sitzungsleiter (Dialog-Manager).

Gruß Jens