Modulentwicklung für Rhasspy Sprachassistent

Begonnen von drhirn, 11 März 2021, 15:59:50

Vorheriges Thema - Nächstes Thema

Prof. Dr. Peter Henning

Hm. Snips habe ich schon vor langer Zeit verwendet - der Seminarvortrag dazu ist > 2 Jahre alt. Und schon da fand mein Team die Doku grenzwertig.

Betreffend die "Beendigung": Ich habe mehrfach (auch mit dem verwendeten) Code gezeigt, dass sayFinished mit korrekter id und siteId das Warten eben nicht beendet. Also woran liegt es?

LG

pah

Beta-User

Weiß nicht, ob es um's "Übernehmen" ging oder vielmehr ums "Nachbilden", aber klar ist, dass es Abweichungen gibt, und daher im Zweifel immer die aktuellste Doku bei Rhasspy maßgeblich ist, und nicht die Theorie/Darstellung aus der "Ursuppe".

Hier geht es nach meinem Verständnis aber erst mal darum, dass im Rahmen eines Dialogs (und zwar unabhängig davon, ob der anschließend zugemacht werden soll oder nicht) Rhasspy/das Sessionmanagement informiert wird, dass das Synthetisieren und Sprechen (im Rahmen eines ganz bestimmten Dialogs mit einer bestimmten Ausgabestelle) beendet wurde - und daher z.B. auch das Mikro wieder auf "hotword-detection" gestellt werden darf.

Zitat von: Prof. Dr. Peter Henning am 28 Dezember 2021, 09:32:18
Betreffend die "Beendigung": Ich habe mehrfach (auch mit dem verwendeten) Code gezeigt, dass sayFinished mit korrekter id und siteId das Warten eben nicht beendet. Also woran liegt es?
Hast du es auch mit dem eingeschränkten JSON versucht? Also nur genau diese zwei Elemente, nicht mehr.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Prof. Dr. Peter Henning

Aber ja. Hier nochmal im Detail, gerade eben durchgeführt.

Zuerst sende ich - aus der "Home"-Seite von Rhasspy:
Zitat[DEBUG:2021-12-28 09:39:22,800] rhasspyserver_hermes: -> TtsSay(text='Das ist noch ein fünfter Versuch', site_id='default', lang=None, id='3ae8e3ed-363b-42dd-866c-2b24dbb97727', session_id='', volume=1.0)

Das geht über den MQTT-Server als
Zitat[DEBUG:2021-12-28 09:39:22,800] rhasspyserver_hermes: Publishing 157 bytes(s) to hermes/tts/say

Wird bei mir wunderbar ausgeführt,
Zitat2021.12.28 09:39:22 1: [speakTablet] name=Tab2.EG text=Das ist noch ein fünfter Versuch

und umgehend beantwortet mit
Zitat2021.12.28 09:39:22 1: set SpeakMQTT_Client publish hermes/tts/sayFinished {"siteId":"default","id":"3ae8e3ed-363b-42dd-866c-2b24dbb97727"}

Das kommt auch - irgendwie - bei Rhasspy an, denn das Rhasspy-Log meldet
Zitat[DEBUG:2021-12-28 09:39:22,830] rhasspyserver_hermes: Handling TtsSayFinished (topic=hermes/tts/sayFinished, id=970ec854-df84-4261-9b2d-73990f8c9167)

Nur, und das ist die Kernfrage: Woher kommt die geänderte Id ????

Denn Rhasspy erkennt die Antwort nicht und geht nach 30 Sekunden in einen Timeout

Zitat[ERROR:2021-12-28 09:39:52,829] 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

LG

pah



Beta-User

Hmm, kann grade nicht testen, aber wenn ich meine Testmessages so ansehe, fällt mir auf, dass "id" da in der Regel mit "null" belegt ist bzw. in lastIntentPayload (das ist aber kein Roh-Wert, sondern toJSON von $data) findet sich dazu nichts...
Evtl. mal (echtes) "null" übergeben (also ohne Quotes)?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

JensS

#1039
Es gibt auch noch ein schönes Bildchen, welches aber nur bedingt aussagekräftig ist.
https://snips.gitbook.io/tutorials/t/technical-guides/listening-to-intents-over-mqtt-using-python
Der Dialogmanager ordnet mit dem Text von endSession ein tts/say an. TTS übernimmt die id und verkündet dann die erfolgte Ausgabe.
Hier ein Mitschnitt einer Bestätigungsabfrage mit continueSession und Endsession. Auf die Topics mit Audioframes habe ich verzichtet.mosquitto_sub -v -t hermes/hotword/# -t hermes/dialogueManager/# -t hermes/asr/# -t hermes/audioServer/+/playFinished -t hermes/nlu/# -t hermes/error/# -t hermes/tts/# -t hermes/feedback/#
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-7e57b60f-47da-47f6-bd67-0a075f42d8c0", "siteId": "wohnzimmer", "customData": "alexa", "lang": null}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/asr/startListening {"siteId": "wohnzimmer", "sessionId": "wohnzimmer-alexa-7e57b60f-47da-47f6-bd67-0a075f42d8c0", "lang": null, "stopOnSilence": true, "sendAudioCaptured": true, "wakewordId": "alexa", "intentFilter": null}
hermes/asr/textCaptured {"text": "stehlampe an", "likelihood": 0.9419979, "seconds": 3.83437726192642, "siteId": "wohnzimmer", "sessionId": "wohnzimmer-alexa-7e57b60f-47da-47f6-bd67-0a075f42d8c0", "wakewordId": null, "asrTokens": [[{"value": "stehlampe", "confidence": 0.987926, "rangeStart": 0, "rangeEnd": 10, "time": {"start": 0.01116, "end": 1.54037}}, {"value": "an", "confidence": 1.0, "rangeStart": 10, "rangeEnd": 13, "time": {"start": 1.5453, "end": 4.14}}]], "lang": null}
hermes/asr/stopListening {"siteId": "wohnzimmer", "sessionId": "wohnzimmer-alexa-7e57b60f-47da-47f6-bd67-0a075f42d8c0"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/nlu/query {"input": "stehlampe an", "siteId": "wohnzimmer", "id": null, "intentFilter": ["de.fhem:SetAllOn", "de.fhem:ViomiRhasspy", "de.fhem:RhasspyGetTimer", "de.fhem:WIKI", "de.fhem:GetTime", "de.fhem:GetNumeric", "de.fhem:GetAllOff", "de.fhem:SetColor", "de.fhem:Wikipedia", "de.fhem:Fernsehprogramm", "de.fhem:Respeak", "de.fhem:SetNumeric", "de.fhem:RhasspySetTimer", "de.fhem:Status", "de.fhem:SetMute", "de.fhem:SetAllOff", "de.fhem:Witze", "de.fhem:SetOnOff", "de.fhem:Wetter", "de.fhem:MediaControls", "de.fhem:GetWeekday", "de.fhem:Shortcuts", "de.fhem:GetOnOff"], "sessionId": "wohnzimmer-alexa-7e57b60f-47da-47f6-bd67-0a075f42d8c0", "wakewordId": "alexa", "lang": null, "customData": "alexa", "asrConfidence": 0.9419979, "customEntities": null}
hermes/nlu/intentParsed {"input": "stehlampe on", "intent": {"intentName": "de.fhem:SetOnOff", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "de.fhem.Device", "value": {"kind": "Unknown", "value": "stehlampe"}, "slotName": "Device", "rawValue": "stehlampe", "confidence": 1.0, "range": {"start": 0, "end": 9, "rawStart": 0, "rawEnd": 9}}, {"entity": "Value", "value": {"kind": "Unknown", "value": "on"}, "slotName": "Value", "rawValue": "an", "confidence": 1.0, "range": {"start": 10, "end": 12, "rawStart": 10, "rawEnd": 12}}], "sessionId": "wohnzimmer-alexa-7e57b60f-47da-47f6-bd67-0a075f42d8c0"}
hermes/dialogueManager/continueSession {"customData": "alexa","intentFilter":["de.fhem:ConfirmAction","de.fhem:CancelAction"],"sendIntentNotRecognized": true,"sessionId": "wohnzimmer-alexa-7e57b60f-47da-47f6-bd67-0a075f42d8c0","siteId": "wohnzimmer","text": "bestätige stehlampe an"}
hermes/asr/stopListening {"siteId": "wohnzimmer", "sessionId": "wohnzimmer-alexa-7e57b60f-47da-47f6-bd67-0a075f42d8c0"}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/asr/toggleOff {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/tts/say {"text": "bestätige stehlampe an", "siteId": "wohnzimmer", "lang": null, "id": "d52aadcd-1447-4753-9234-d4862a872b58", "sessionId": "wohnzimmer-alexa-7e57b60f-47da-47f6-bd67-0a075f42d8c0", "volume": null}
hermes/tts/sayFinished {"siteId": "wohnzimmer", "id": "d52aadcd-1447-4753-9234-d4862a872b58", "sessionId": "wohnzimmer-alexa-7e57b60f-47da-47f6-bd67-0a075f42d8c0"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/asr/toggleOn {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/asr/startListening {"siteId": "wohnzimmer", "sessionId": "wohnzimmer-alexa-7e57b60f-47da-47f6-bd67-0a075f42d8c0", "lang": null, "stopOnSilence": true, "sendAudioCaptured": true, "wakewordId": null, "intentFilter": null}
hermes/audioServer/wohnzimmer/playFinished {"id": "d52aadcd-1447-4753-9234-d4862a872b58", "sessionId": "d52aadcd-1447-4753-9234-d4862a872b58"}
hermes/asr/textCaptured {"text": "ja bitte", "likelihood": 1.0, "seconds": 5.306720254011452, "siteId": "wohnzimmer", "sessionId": "wohnzimmer-alexa-7e57b60f-47da-47f6-bd67-0a075f42d8c0", "wakewordId": null, "asrTokens": [[{"value": "ja", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 3, "time": {"start": 0.0, "end": 0.93}}, {"value": "bitte", "confidence": 1.0, "rangeStart": 3, "rangeEnd": 9, "time": {"start": 0.93, "end": 5.42}}]], "lang": null}
hermes/asr/stopListening {"siteId": "wohnzimmer", "sessionId": "wohnzimmer-alexa-7e57b60f-47da-47f6-bd67-0a075f42d8c0"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/nlu/query {"input": "ja bitte", "siteId": "wohnzimmer", "id": null, "intentFilter": ["de.fhem:ConfirmAction", "de.fhem:CancelAction"], "sessionId": "wohnzimmer-alexa-7e57b60f-47da-47f6-bd67-0a075f42d8c0", "wakewordId": "alexa", "lang": null, "customData": "alexa", "asrConfidence": 1.0, "customEntities": null}
hermes/nlu/intentParsed {"input": "OK", "intent": {"intentName": "de.fhem:ConfirmAction", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "Mode", "value": {"kind": "Unknown", "value": "OK"}, "slotName": "Mode", "rawValue": "ja bitte", "confidence": 1.0, "range": {"start": 0, "end": 2, "rawStart": 0, "rawEnd": 8}}], "sessionId": "wohnzimmer-alexa-7e57b60f-47da-47f6-bd67-0a075f42d8c0"}
hermes/dialogueManager/endSession {"customData": "alexa","intentFilter": null,"sessionId": "wohnzimmer-alexa-7e57b60f-47da-47f6-bd67-0a075f42d8c0","siteId": "wohnzimmer","text": "Ok - Stehlampe im wohnzimmer ist eingeschaltet"}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/asr/toggleOff {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/tts/say {"text": "Ok - Stehlampe im wohnzimmer ist eingeschaltet", "siteId": "wohnzimmer", "lang": null, "id": "18e18822-5851-464d-b6f4-dbc7622ce03b", "sessionId": "wohnzimmer-alexa-7e57b60f-47da-47f6-bd67-0a075f42d8c0", "volume": null}
hermes/tts/sayFinished {"siteId": "wohnzimmer", "id": "18e18822-5851-464d-b6f4-dbc7622ce03b", "sessionId": "wohnzimmer-alexa-7e57b60f-47da-47f6-bd67-0a075f42d8c0"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/asr/toggleOn {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/asr/stopListening {"siteId": "wohnzimmer", "sessionId": "wohnzimmer-alexa-7e57b60f-47da-47f6-bd67-0a075f42d8c0"}
hermes/dialogueManager/sessionEnded {"termination": {"reason": "nominal"}, "sessionId": "wohnzimmer-alexa-7e57b60f-47da-47f6-bd67-0a075f42d8c0", "siteId": "wohnzimmer", "customData": "alexa"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/audioServer/wohnzimmer/playFinished {"id": "18e18822-5851-464d-b6f4-dbc7622ce03b", "sessionId": "18e18822-5851-464d-b6f4-dbc7622ce03b"}

Gruß Jens

@Beta-User
Bei genauerer Betrachtung denke ich den Grund für die Stotterei gefunden zu haben. ASR und Hotword werden gestartet, obwohl es noch keine Bestätigung von playFinished gibt.hermes/dialogueManager/continueSession {"customData": "alexa","intentFilter":["de.fhem:ConfirmAction","de.fhem:CancelAction"],"sendIntentNotRecognized": true,"sessionId": "wohnzimmer-alexa-7e57b60f-47da-47f6-bd67-0a075f42d8c0","siteId": "wohnzimmer","text": "bestätige stehlampe an"}
hermes/asr/stopListening {"siteId": "wohnzimmer", "sessionId": "wohnzimmer-alexa-7e57b60f-47da-47f6-bd67-0a075f42d8c0"}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/asr/toggleOff {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/tts/say {"text": "bestätige stehlampe an", "siteId": "wohnzimmer", "lang": null, "id": "d52aadcd-1447-4753-9234-d4862a872b58", "sessionId": "wohnzimmer-alexa-7e57b60f-47da-47f6-bd67-0a075f42d8c0", "volume": null}
hermes/tts/sayFinished {"siteId": "wohnzimmer", "id": "d52aadcd-1447-4753-9234-d4862a872b58", "sessionId": "wohnzimmer-alexa-7e57b60f-47da-47f6-bd67-0a075f42d8c0"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/asr/toggleOn {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/asr/startListening {"siteId": "wohnzimmer", "sessionId": "wohnzimmer-alexa-7e57b60f-47da-47f6-bd67-0a075f42d8c0", "lang": null, "stopOnSilence": true, "sendAudioCaptured": true, "wakewordId": null, "intentFilter": null}
hermes/audioServer/wohnzimmer/playFinished {"id": "d52aadcd-1447-4753-9234-d4862a872b58", "sessionId": "d52aadcd-1447-4753-9234-d4862a872b58"}

Das ist aus meiner Sicht ein Fehler in der Reihenfolge. Siehst du das auch so?
Meine Lösung, das Mikro des Satelliten beim Abspielen des Antworttextes zu muten, macht hierbei Sinn. Besser wäre natürlich, die Reihenfolge zu korrigieren.
Da es bei Rhasspy im Moment einige Umbrüche gibt, sehe ich nicht, wer das dort machen würde.

Gruß Jens

p.s. @Beta-User
Das Mikro wird vielleicht für das Stoppen der Sprachausgabe geöffnet. Dann muss ein lokales Echo-Canceling her...
Debian auf APU2C4, HM-CFG-USB2, SIGNALduino, HM-ES-PMSw1-Pl, TFA 30.3121, TFA 30.3125, ITS-150, PIR-5000, configurable Firmata USB & LAN, 1-wire: DS-18B20, DS-18S20, DS-2408, DS-2413, diverse I2C-Komponenten, zigbee2mqtt, ESPEasy etc.

Beta-User

Hmm, also wird die id doch durchgeschleust...

Das "Problem" mit diesem Muster-Dialog ist allerdings, dass vermutlich als TTS-Komponente grade nicht Hermes-MQTT eingestellt ist (bei meinen Messenger-Dialogen aber sehr wohl, nur dass dort die "FHEM-Site" nicht als für die Komponente relevante SiteId eingetragen ist).

@pah: evtl. wäre es eine Idee, das mal auf dem Default zu lassen und dann die betreffenden SiteId's für diesen Dienst bei Rhasspy zu löschen?
Ist nur ein Experiment, und an sich sieht mir das nach einer kaputten (im Sinne von nicht der Spec entsprechenden) Implementierung auf Rhasspy-Seite aus, die man im dortigen Forum hinterfragen sollte.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Prof. Dr. Peter Henning

Klar, wenn ich einen der internen TTS-Services nutze, ist ja alles OK - das ist aber nicht das Problem.

@JensS: Es wäre interessant, zu diesem Mitschnitt noch das Rhasspy-Log zu sehen. Nämlich, ob das Handling des sayFinished auch die id verändert, oder dieselbe id beibehält.

Ich vermute, dass an dieser Stelle der Fehler in Rhasspy ist.

LG

pah

Beta-User

#1042
Zitat von: Prof. Dr. Peter Henning am 28 Dezember 2021, 13:00:26
Klar, wenn ich einen der internen TTS-Services nutze, ist ja alles OK - das ist aber nicht das Problem.
Mein Vorschlag war, Rhasspy "auszutricksen":
- Soweit ich das in Erinnerung habe, kommt die Meldung auf dem "say-Topic" immer, egal, welchen TTS-Handler man eingestellt hat (=> immer abgreifbar! Das ist im Beispiel von JensS so, paßte aber auch bei meinem Messenger-SiteId-Versuchen)
- der "picoTTS-default" (?) ist aber nur aktiv, wenn eine "ihm gehörende" SiteId genannt wird.
Will man den also "eigentlich" gar nicht nutzen, muss man ihm "nur" alle SiteId's entziehen und braucht ihn nicht explizit durch was anderes ersetzen.

Klar ist das eine Fehlfunktion, wenn es so klappt, aber immerhin eine Option.

Schreibe das nur für den Fall, dass das vorher missverstanden worden sein sollte.

EDIT: Wegen des Posts bei Rhasspy: Du solltest vielleicht noch erwähnen, dass Hermes-MQTT als TTS-Dienst ausgewählt ist, und der auch für den Satelliten "default" zuständig ist.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files


Beta-User

Ups, das wäre mir beinahe durch...:
Zitat von: JensS am 28 Dezember 2021, 10:58:16
Das ist aus meiner Sicht ein Fehler in der Reihenfolge. Siehst du das auch so?
Es klingt plausibel. In diese Richtung hatte ich auch schon überlegt, allerdings ist es schade, dass man die zeitlichen Zusammenhänge nicht deutlich erkennen kann, und irritierend ist auch, dass es sehr wechselhaft ist, ob man weiterreden kann oder nicht.

Zitat
Meine Lösung, das Mikro des Satelliten beim Abspielen des Antworttextes zu muten, macht hierbei Sinn. Besser wäre natürlich, die Reihenfolge zu korrigieren.
Da es bei Rhasspy im Moment einige Umbrüche gibt, sehe ich nicht, wer das dort machen würde.
Na ja, es ist ja nicht so, dass der Hauptentwickler nicht mehr da wäre, es geht halt uU. etwas langsamer wie früher.

Bei den Dialog-Themen hier würde ich auch tippen, dass das bisher einfach nicht so sehr im Fokus war, weil es eher darum ging, nach einem wakeword einen Befehl abzusetzen und gut ist, und es nicht besonders schwer ist, das zu fixen...

Zitat
p.s. @Beta-User
Das Mikro wird vielleicht für das Stoppen der Sprachausgabe geöffnet. Dann muss ein lokales Echo-Canceling her...
Den Absatz verstehe ich im Moment nicht.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Prof. Dr. Peter Henning

#1045
Anbei mal mein Schema für die Anbindung von Babble an Rhasspy. An einem Wiki-Artikel, der die Vor- und Nachteile der jeweiligen Alternativen auflistet, arbeite ich auch schon. Ich habe das jetzt so gelöst, dass ich mit dem Wakeword "Hallo Jeannie" (Precise, selbst trainiert, via Rhasspy und MQTT) meine Spracherkennung starte (auf Tablets, also via Google. Ist einfach um Klassen besser als die vorhandenen Open Source Lösungen).

Der fertige Befehlssatz wird an Babble zur Auswertung (also Intent-Erkennung und Handling) weitergeleitet, es sei denn, ich sage
"Hallo Jeannie. Sage Mycroft: <Hier der Text>". In diesem Falle wird der nachfolgende Text an hermes/nlu/query weitergeleitet.

LG

pah

Edit: Sehe gerade, dass der eine blaue Pfeil noch falsch ist - der muss auch über RHASSPY laufen.

Beta-User

Auf die Schnelle ein erster Eindruck: Es könnte m.E. einiges entfallen, wenn man wollte...

- Das notify (+Perl-Code für "Hey Jeannie"): die Funktionalität ähnelt dem, was bei "normalen" RESIDENTS-Message-Events (in RHASSY) "veranstaltet" wird
- MQTT2_DEVICE: Das hat ja nur eine Art "Relay-Stations-Funktionalität". Sollte sich einfach in RHASSPY integrieren lassen (Damit entfällt auch Konfigurationsaufwand am MQTT2_CLIENT)
- Perl-Code zum Start der Spracherkennung: Müßte auch recht einfach zu integrieren sein. RHASSPY müßte "nur" wissen, welches AMADDevice anzusprechen ist. (Rhasspy-) wakeword-abhängig?

In welchen Fällen ist denn Rhasspy noch für STT verantwortlich? Wenn ich das richtig deute, eigentlich nie. Oder nur bei "anderen" Wakewords?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

JensS

#1047
Zitat von: JensS am 28 Dezember 2021, 10:58:16
p.s. @Beta-User
Das Mikro wird vielleicht für das Stoppen der Sprachausgabe geöffnet. Dann muss ein lokales Echo-Canceling her...
Die Reihenfolge von WakeWord, ASR und playFinished kann gewollt sein, um das Mikro beim Abspielen einer Antwort offen zu haben. Dann könnte man Rhasspy "das Maul stopfen".
Manche WIKI-Antwort oder Programmvorschau dauert und dauert...
Wakeword und ASR müssten in dem Fall, den momentan gesprochenen Audiostream aus der momentanen Aufnahme des Mikros ausfiltern/abziehen, um der ASR eine brauchbare AUfnahme zu übermitten. Ein solches Echo-Canceling könnte über Pulse oder auf Hardwareebene realisiert werden. Das ist natürlich keinem Nutzer zuzumuten. Ein fertiges Image für eine festgelegte Hardware wäre die Lösung, welche wiederum andere Hardware aussen vor lässt.

s. Folgender Test:
Nach dem Fernsehprogramm gefragt. Ton-Ausgabe kommt.
Dann beim Satelliten den Ton auf 0 gestellt, so dass kein augegebener Ton aufgenommen werden kann.
In der laufenden Ausgabe Wakeword gesprochen und in der WIKI nachschlagen lassen.
Ergebnis:
Rhasspy arbeitet die zweite Aufforderung sauber ab, kapert beim Antworten den Tonausgang und würgt das Fernsehprogramm ab. Mit einem guten Echo-Canceling durchaus brauchbar.

Trotzdem überlege ich im Moment, mein LED-Script für RPi0W umzuschreiben. Es gibt für den Respeaker2MicHat keine mute/unmute-Funktion. So muss die Mikrolautstärke definiert werden.
Der Ablauf würde dann so aussehen: Bei tts/say würde der Ton auf 0 und nach playFinished auf 90 gestellt werden. Im Mute-Modus würden die LEDs leicht blau leuchten. Falls playFinished ausbleibt, könnte man mit einem kurzen Tastendruck das Mikro wieder auf 90 stellen. Das generelle Deaktivieren des Mikros nach 3 Sekunden Tastendruck würde ebenso drin bleiben, wie das Herrunterfahren des Satelliten nach 10 Sekunden drücken.

@pah
Hübsch bunt.  :)
Läuft es jetzt? Ich denke, dass jemand in die Session quatscht, der eigentlich den Mund halten sollte. Ein zweiter Teilnehmer mit der SiteId "default" z.B..

p.s. sh. s.
Debian auf APU2C4, HM-CFG-USB2, SIGNALduino, HM-ES-PMSw1-Pl, TFA 30.3121, TFA 30.3125, ITS-150, PIR-5000, configurable Firmata USB & LAN, 1-wire: DS-18B20, DS-18S20, DS-2408, DS-2413, diverse I2C-Komponenten, zigbee2mqtt, ESPEasy etc.

Prof. Dr. Peter Henning

Zitat- Das notify (+Perl-Code für "Hey Jeannie"): die Funktionalität ähnelt dem, was bei "normalen" RESIDENTS-Message-Events (in RHASSY) "veranstaltet" wird
Kein Widerspruch.

Zitat
- MQTT2_DEVICE: Das hat ja nur eine Art "Relay-Stations-Funktionalität". Sollte sich einfach in RHASSPY integrieren lassen (Damit entfällt auch Konfigurationsaufwand am MQTT2_CLIENT)
Auch richtig. Allerdings ist die Doku von 10_RHASSPY.pm derzeit noch so unübersichtlich, dass man das sehr gut beschreiben müsste.
Zitat
- Perl-Code zum Start der Spracherkennung: Müßte auch recht einfach zu integrieren sein. RHASSPY müßte "nur" wissen, welches AMADDevice anzusprechen ist. (Rhasspy-) wakeword-abhängig?
Das wechselt - müsste als Parameter à la siteid übergeben werden.

ZitatIn welchen Fällen ist denn Rhasspy noch für STT verantwortlich? Wenn ich das richtig deute, eigentlich nie. Oder nur bei "anderen" Wakewords?
Richtig gedeutet. Die STT Transformation auf Basis von Phonemen und lokal hinterlegten Dictionaries ist der Erkennung von Google um Lichtjahre hinterher. Dabei müsste man nicht über ein Android-Gerät gehen. Ich habe schon länger vor, das direkt in FHEM zu integrieren (per Zugriff auf Google Cloud Dienste).

Das mache ich ja auch mit der TTS-Transformation - wobei ich hierzu Amazon Polly bevorzuge, wegen der hohen Sprachqualität (Amazon hat hier die beste Firma aufgekauft). Bei mir daheim erfolgt die Sprachausgabe auf allen Geräten mit derselben Stimme (Marlene). Auf Android-Geräten erfordert das nur die Installation der Sprachdateien und einen Aufruf von AMAD. Auf allen anderen Geräten werden die Textdaten an AWS geschickt und ein MP3 zurückgeliefert.

LG

pah

Prof. Dr. Peter Henning

ZitatLäuft es jetzt? Ich denke, dass jemand in die Session quatscht, der eigentlich den Mund halten sollte. Ein zweiter Teilnehmer mit der SiteId "default" z.B..
Nö, nach wie vor dasselbe. Ich habe jetzt in meine Antworten genau die Parameter eingebaut, die auch nanoTTS zurückliefert - keine Chance, immer noch timeout.

Ich habe auch eine Subscription für hermes/# laufen lassen - da kommt nichts dazwischen.

Sobald ich die Ausgabe über nanoTTS laufen lasse, aber trotzdem die Subscription für /hermes/tts/say aufrecht erhalte, gibt es die doppelte Sprachausgabe - und wunderbarerweise keinen Timeout. Ich bin inzwischen ziemlich überzeugt davon, dass hier Rhasspy einen Fehler hat, wenn "nur" MQTT als TTS eingestellt wird.

LG

pah