Modulentwicklung für Rhasspy Sprachassistent

[Beta-User]

Diverse Inkonsistenzen in der Schnellstart-Anleitung behoben.

Danke!

Die konsequente Kleinschreibung für die RHASSPY-Instanz ist eine gute Sache.

Klingt danach, als wäre die Einrichtung nach der Anleitung erst mal soweit nachvollziehbar  .

Als nächsten Schritt würde ich dann empfehlen, die relativ neuen "Schlüsselwörter" in rhasspyTweaks zu setzen (also ignoreKeywords und gdt2groups). Damit hat man dann z.B. gleich alle "blind"-Geräte in einer ansprechbaren Gruppe "Rollläden" oder alle "light" in "Lichter"...
Danach käme dann das "rhasspy-Attribut am Device geht genereller Einstellung/Erkennung vor"-Prinzip an die Reihe .

[drhirn]

Der MQTT von Rhasspy läuft per default auf Port 12183. Das hat schon gepasst.

Und mit deiner Einführung von "rhasspy" hast du eine dritte Schreibweise eingeführt. Passt zwar zum in den Screenshots definierten Device, weiß aber nicht, ob das dann nicht noch verwirrender wird. Ich hatte mit "RHASSPY" einfach das Modul im Kopf - unabhängig davon, wie's der User benennt. Im "Normalfall" hat man ja eh nur eine Definition des Moduls.

[Gisbert]

Hallo zusammen,

ich nutze die Android-App zur Spracheingabe. Bei Benutzung der App muss man diese öffnen und auf das Mikrofon tippen, bevor man den Sprachbefehl absetzen kann, immerhin sind 2 Klicks notwendig.

Gibt es die Möglichkeit wie bei Google Assistant ein Aufwachwort zu sprechen und dann den eigentlichen Sprachbefehl?

In meinem Fall benutzt Rhasspy den gleichen MQTT-Broker Mosquitto wie meine Fhem-Installation. Gibt es dabei etwas zu bedenken?

Viele​ Grüße​ Gisbert​

[drhirn]

In meinem Fall benutzt Rhasspy den gleichen MQTT-Broker Mosquitto wie meine Fhem-Installation. Gibt es dabei etwas zu bedenken?

Ja! Rhasspy schickt enorm viele Daten durch die Gegend. Sobald ein Hotword erkannt wurde z.B. alles, was das Mikrofon aufnimmt. Also wirklich Audio (WAV Chunks). Das willst du alles nicht wirklich auf einem MQTT-Broker haben, der auch andere Sachen machen soll. Deshalb lieber zwei getrennte Mosquittos. Einen für FHEM und den Rhasspy-eigenen für Rhasspy, den du dann mit MQTT2_CLIENT abfrägst.

Zur App kann ich nicht viel sagen. Hab aber im Hinterkopf, dass man schon irgendwie aktivieren konnte, dass die dauernd zuhört. Muss Beta-User etwas dazu sagen.

[Prof. Dr. Peter Henning]

@drhirn:

Und mit deiner Einführung von "rhasspy" hast du eine dritte Schreibweise eingeführt.

Nix da. Das war schon vorher im Wiki - aber eben nicht überall. Außerdem muss man sorgfältig zwischen dem Modul RHASSPY und der Instanz rhasspy unterscheiden.

Der MQTT von Rhasspy läuft per default auf Port 12183. Das hat schon gepasst.

Auch nicht zielführend - denn bei Verwendung der Installations- und Startanweisung für das Docker Image auf den offiziellen Rhasspy-Seiten ist der Port 12183 nicht exposed. Damit klappt die Verbindung zwischen FHEM und Rhasspy nur über einen (Rhasspy-externen) Mosquitto. Und der läuft auf 1883.

LG

pah

[Beta-User]

Bei Benutzung der App muss man diese öffnen und auf das Mikrofon tippen, bevor man den Sprachbefehl absetzen kann, immerhin sind 2 Klicks notwendig.

Es gibt auch ein (unschönes) "Widget", mit dem man mit einem Klick ein "offenes Mikro" bekommt.

Gibt es die Möglichkeit wie bei Google Assistant ein Aufwachwort zu sprechen und dann den eigentlichen Sprachbefehl?

Ja. Muss extra eingeschaltet werden (an der App), und die "Base" muss wissen, dass es für diesen Satelliten die wakeword-Funktion übernehmen soll. Sollte im "Läuft soweit"-Thread zu finden sein, wie die Ports zu konfigurieren sind. (Für wakeword wird per UDP der Ton übertragen => nicht sooo toll für die Akku-Laufzeit.... => ich nehme lieber den shortcut per widget.)

In meinem Fall benutzt Rhasspy den gleichen MQTT-Broker Mosquitto wie meine Fhem-Installation. Gibt es dabei etwas zu bedenken?

Ja. "not recommended", wie drhirn und meinereiner schon mehrfach geschrieben haben. Ich hatte erst einen extra externen Mosquitto dafür aufgesetzt, aber das macht keinen Sinn und der interne "frißt auch (fast) kein extra Brot"... (Man ist mit dem "internen" setup einfach "standardkonform").

[Gisbert]

Hallo Jörg,

danke für die Info. Das Widget für ein offenes Mikrofon finde ich ganz ok. Damit lasse ich es bewenden.

Viele​ Grüße​ Gisbert​

[Beta-User]

Hier findet ihr einen ersten Wurf für die "Einführung Teil 2": https://wiki.fhem.de/wiki/RHASSPY/Vertiefung

[Prof. Dr. Peter Henning]

1. Frage:
- Warum verhalten sich das Docker-Image und die per dpkg installierte Paketversion unterschiedlich in Bezug auf das Mikrofon?
  Bei Docker-Image wird zur Auswahl beim Audio Recording als Device angeboten "Hardware device with all software conversions (plughw:CARD=AK5370,DEV=0)", bei der Paketversion fehlt dies (obwohl natürlich das plughw-Plugin für Alsa installiert ist). Das wäre aber wichtig, um beliebige Mikros verwenden zu können.

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.

3. Feature Requests für das Modul:
- Es sollte möglich sein, zusätzliche Räume (als Werte für den Room-slot) in einem Attribut zu hinterlegen. Derzeit ist mein Weg, ein Dummy zu definieren, das einfach in diversen rhasspyRooms vertreten ist, und diesem den genericDeviceType switch zu geben.
- Es sollte ein "set ... activateVoiceInput" geben, mit dem Rhasspy aufgeweckt wird (also ohne Wakeword). Die Benennung "activateVoiceInput" orientiert sich dabei an dem, was man bei Android Tablets eingeben kann.

4. Rhasspy und Babble:
- Ich habe das jetzt genau evaluiert. Es ist problemlos möglich, im Attribut rhasspyIntents des rhasspy-Devices einen Intent-Handler anzulegen, der den gesamten input an Babble weiterleitet, indem die subroutine Babble_DoIt("<name>","<sentence>"[,<parm0>,<parm1>,...]) aufgerufen wird. Die Auswertung, sowie gegebenenfalls die Steuerung von FHEM-Devices, wird dann komfortabel über die Oberfläche von Babble konfiguriert. An Babble ist im Hintergrund noch der RiveScript-Chatbot angekoppelt, der einen echten Dialog mit dem Nutzer führen kann.

Beispiel (U=User, B=Babble, R=Rhasspy):

U: "Hey Mycroft"
R: Beep
U: "Spiele Musik"
(R: Erkennt dies als Dateneingabe in einem Intent "Musik". Leitet dies an B weiter. B intern: Nicht direkt erkannt, reiche weiter an RiveScript. Dort erkannt,  B wechselt in den Kontext "Musik". Antwortet mit Text, B reicht Text an R weiter oder lässt auf einem anderen Device sprechen)
R: "Das mache ich gerne, bitte sage mir wo Du gerade bist"
R mit Verzögerung: aktiviert Spracheingabe ohne Wakeword
U: "Im Schlafzimmer"
(R: Erkennt dies als Dateneingabe in einem Intent "GetRoom". Leitet dies an B weiter. B intern: Nicht direkt erkannt, reiche weiter an RiveScript. Dort erkannt, im Kontext "Musik" muss dies ein Raumname sein. Wenn nicht, Fehlermeldung zurück via B an R, dort ausgesprochen. Wenn ja, antworte mit Text. B reicht Text an R weiter oder lässt auf einem anderen Device sprechen)
R: "Von wem soll ich im Schlafzimmer Musik spielen?"
R mit Verzögerung: aktiviert Spracheingabe ohne Wakeword
U: "Von den Beatles"

===> Ab jetzt wird es visionär

(R: Erkennt dies als Dateneingabe in einem Intent "getSource", aber mit der Aussprache "Bietels". Leitet dies an B weiter. B intern: Nicht direkt erkannt, reiche weiter an RiveScript. Dort erkannt. Rivescript ruft B auf mit dem vollständigen Satz "Spiele Musik im Schlafzimmer von Quelle Bietels".

Hinweis: Bei mir läuft dann eine Suche in meiner Musikbibliothek nach Songs, bei dieser Suche kann z.B. "Bietels" auf "Beatles" gemappt werden.
Endergebnis: Es wird eine Playlist mit Beatles-Songs abgespielt.

Problematisch ist in diesem Beispiel, dass die STT-Engines von Rhasspy ohne Cloud-Zugriff keinen Text für untrainierte Sätze ausgeben können. In meinen Android-Devices kommt von Google tatsächlich auch in einer deutschen Satzkontruktion  "Beatles" zurück, weil die offenbar eine semantische Analyse durchführen und erkennen, dass die Band gemeint ist. Klappt auch bei anderen Bands, wie "Deep Purple" - scheitert dann aber an deutschen Künstlern, etwa wird statt "Degenhardt" nur "Degenhart" zurückgegeben. In meiner Suchroutine macht das nichts aus, weil ich zur Erkennung von Künstlern die Namen bis zu einem Levenshtein-Abstand von 3 auswerte.

Ob mit einer anderen STT-Engine (etwa Mozilla Deep Speech) auch die Rückgabe von Text für untrainierte Sätze möglich ist, muss ich mir noch ansehen.

Fazit: JA, Rhasspy (und auch das Modul) können prima mit Babble zusammenarbeiten. Das hat den Vorteil, dass die Intents komplett von den Devices getrennt werden können, und die auszuführenden Befehle zentral abgelegt werden können (eben in der Datenstruktur von Babble). Zusammen mit dem an Babble angehängten ChatBot ergeben sich tolle Möglichkeiten  - begrenzt nur durch die Tatsache, dass (bisher) untrainierte Sätze von Rhasspy nicht in Text umgewandelt werden können. In dem obigen Dialogbeispiel ist das bei den Räumen gut ausgeführt: Die relativ wenigen Räume meines Hauses kann ich Rhasspy antrainieren - aber nicht hundertundein Künstlernamen aus meiner Musikbibliothek.

Zur Verbessserung der Zusammenarbeit habe ich oben zwei Feature Requests für das Rhasspy-Modul gepostet. Auf der Seite von Babble wäre ein wichtige Verbesserung, es an MQTT anzubinden - es müsste sowohl textuelle Daten von dort bekommen, als auch textuelle Daten ODER Audiodaten zurückliefern. Ersteres geht ohne Cloud.

LG

pah

[Beta-User]

Erst mal zu dem hier:

3. Feature Requests für das Modul:
- Es sollte möglich sein, zusätzliche Räume (als Werte für den Room-slot) in einem Attribut zu hinterlegen. Derzeit ist mein Weg, ein Dummy zu definieren, das einfach in diversen rhasspyRooms vertreten ist, und diesem den genericDeviceType switch zu geben.
- Es sollte ein "set ... activateVoiceInput" geben, mit dem Rhasspy aufgeweckt wird (also ohne Wakeword). Die Benennung "activateVoiceInput" orientiert sich dabei an dem, was man bei Android Tablets eingeben kann.

Teil 1 mit den zusätzlichen Räumen verstehe ich noch nicht so ganz. Prinzipiell versucht RHASSPY halt, über die Räume rauszufinden, welches Device gemeint sein soll. Ein "device-loser Raum" macht für mich keinen großen Sinn (falls es so gemeint ist), und ein "normales Device" kann im Prinzip in beliebig vielen rhasspyRooms vertreten sein. Prinzipiell sehe ich aber kein Problem, einen Tweak zu basteln, der device-lose Räume ergänzt.
Vielleicht klärst du mich auf, was du damit erreichen willst .

"activateVoiceInput" dürfte auch kein allzugroßes Problem sein, allerdings wird in Rhasspy nach meinem Verständnis eine Sitzung immer einer "siteId" zugeordnet, die den Dialog vermutlich auch wieder schließen sollte.
Siehe https://rhasspy.readthedocs.io/en/latest/wake-word/#mqtthermes, und nach meinem Verständnis ergänzend: https://docs.snips.ai/reference/hermes#detecting-a-wake-word

Wenn es so gedacht ist, dass von FHEM aus ein beliebiger Satellit "geöffnet" werden soll, muss der als Argument übergeben werden (und bekannt sein).

Falls FHEM/RHASSPY die Sitzungsverwaltung machen soll: In etwa an dem Problem hänge ich grade bei der msgDialog-Geschichte fest. Da muss man m.E. streng genommen zwei Sitzungen verwalten, nämlich einmal in Richtung des Messengers (bzw.: Babble), und zum anderen (ggf. bedarfsorientiert auch mehrfach unterbrochen) in Richtung Rhasspy.

Bitte um Klärung, was du genau benötigst.

4. Rhasspy und Babble:
- Ich habe das jetzt genau evaluiert. Es ist problemlos möglich, im Attribut rhasspyIntents des rhasspy-Devices einen Intent-Handler anzulegen, der den gesamten input an Babble weiterleitet, indem die subroutine Babble_DoIt("<name>","<sentence>"[,<parm0>,<parm1>,...]) aufgerufen wird. Die Auswertung, sowie gegebenenfalls die Steuerung von FHEM-Devices, wird dann komfortabel über die Oberfläche von Babble konfiguriert. An Babble ist im Hintergrund noch der RiveScript-Chatbot angekoppelt, der einen echten Dialog mit dem Nutzer führen kann.

...das ist mir im Moment noch zu hoch, und prinzipiell stellt sich die Frage, über welchen Mechanismus eigentlich "komfortabel konfiguriert" am einfachsten zu bewerkstelligen ist, was die Steuerung von FHEM-Gerät angeht... (Vermutlich brauche ich einen Schnellkurs in Babble?).

Fazit: JA, Rhasspy (und auch das Modul) können prima mit Babble zusammenarbeiten. Das hat den Vorteil, dass die Intents komplett von den Devices getrennt werden können, und die auszuführenden Befehle zentral abgelegt werden können (eben in der Datenstruktur von Babble). Zusammen mit dem an Babble angehängten ChatBot ergeben sich tolle Möglichkeiten  - begrenzt nur durch die Tatsache, dass (bisher) untrainierte Sätze von Rhasspy nicht in Text umgewandelt werden können. In dem obigen Dialogbeispiel ist das bei den Räumen gut ausgeführt: Die relativ wenigen Räume meines Hauses kann ich Rhasspy antrainieren - aber nicht hundertundein Künstlernamen aus meiner Musikbibliothek.

Zur Verbessserung der Zusammenarbeit habe ich oben zwei Feature Requests für das Rhasspy-Modul gepostet. Auf der Seite von Babble wäre ein wichtige Verbesserung, es an MQTT anzubinden - es müsste sowohl textuelle Daten von dort bekommen, als auch textuelle Daten ODER Audiodaten zurückliefern. Ersteres geht ohne Cloud.

Ob Babble MQTT beherschen muss? Es wäre kein Hexenwerk, auf RHASSPY-Seite z.B. über ein rhasspy2Babble-Attribut einstellbar zu machen, dass Babble genutzt werden soll, um dann z.B. jeweils den Roh-Text weiterzugeben oder die Daten irgendwie anders vorverarbeitet/standardisiert zu liefern. Da könnte auch z.B. ein Schlüssel additionalBabbleRooms zu finden sein...

Audiodaten kann RHASSPY heute schon weitergeben, neu wäre nur, das (für ein anderes Modul) im Rahmen einer laufenden Sitzung zu machen, aber dem Bauchgefühl nach müßte das halbwegs stressfrei integrierbar sein.

Nicht erkannte Sentences sind übrigens ein Spezialthema, und sowas wie "GetRoom" gibt es schon als "ChoiceRoom"-Intent. Die Kunst wäre dann nur, für Babble (oder einen Messenger-Dienst) einen abweichenden Ablauf vorzuschalten, falls grade eine Sitzung läuft.

PS: https://wiki.fhem.de/wiki/RHASSPY/Vertiefung ist jetzt halbwegs "fertig", und es sind mir dabei auch noch ein paar Wackler in der commandref aufgefallen. Ich hoffe, irgendwann das mit dem Messenger-Dialog in den Griff zu bekommen, dann kommt wieder ein update.

[dkreutz]

Ob mit einer anderen STT-Engine (etwa Mozilla Deep Speech) auch die Rückgabe von Text für untrainierte Sätze möglich ist, muss ich mir noch ansehen.

Mozilla DeepSpeech wird nicht mehr weiter entwickelt. Ein großer Teil des Entwicklerteams hat coqui.ai gegründet und DeepSpeech als Coqui-STT "geforkt". Leider ist das deutschsprachige STT-Modell aber (immer noch) relativ "schlecht" (hohe WER).

Hier habe ich alle verfügbaren STT Modelle evaluiert: https://domcross.github.io/german-stt-evaluation/

[JensS]

zu 1. Frage:
   Seltsam, bei meinen Rhasspy-Installationen (Debian-Paket) wurde immer eine plughw erkannt. Vielleicht doch nur ein ALSA-Ploblem?
   
zu 2. Beobachtung:
   https://github.com/MycroftAI/mycroft-precise/wiki/Training-your-own-wake-word#demoing-the-model
   
zu 3. Feature Requests für das Modul:
   a) Man konnte schon immer einem Device mehrere Räume zuordnen.
   b) Die Erkennung des Hotwords kann auch vorgetäuscht werden. https://rhasspy.readthedocs.io/en/latest/reference/#hotword-detection

Code Auswählen Erweitern

mosquitto_pub -h 192.168.100.1 -p 1883 -t hermes/hotword/alexa/detected -m '{"modelId": "alexa", "modelVersion": "", "modelType": "personal", "currentSensitivity": 0.5, "siteId": "wohnzimmer", "sessionId": null, "sendAudioCaptured": null, "lang": null, "customEntities": null}'

zu 4. Rhasspy und Babble:
   Finde ich super. Hatte mal ein Beispiel zu Talk2Fhem gepostet https://forum.fhem.de/index.php/topic,113180.msg1124227.html#msg1124227 . Deep Speech hatte ich leider nicht recht zum laufen bekommen aber in Rhasspy gibt es den "Open transcription mode" zur freien Texterkennung und  das "Mixed Language Model" zur gewichteten freien Erkennung unter Beachtung der sentences.ini. Für einen echten Dialog ist die Quelle von Rhasspy aber noch nicht bereit. https://forum.fhem.de/index.php/topic,119447.msg1176363.html#msg1176363 , https://community.rhasspy.org/t/lost-in-dialogues-customdata-intentfilter-and-dialoguemanager-configure/2890/14?u=jens-schiffke
   
   Gruß Jens

[Beta-User]

Anbei erst mal eine ungetestete Version, mit der man als Tweak auch "extrarooms" zur Verfügung hat, damit pah erst mal weiterarbeiten kann. Mal sehen, wo das letztendlich hinwandert. Ergänzt werden dann (hoffentlich) sowohl rooms wie mainrooms.

Die messenger-Schnittstelle sollte man vorsichtshalber nicht nutzen, aber der Rest dürfte ok sein, und v.a. ist jetzt auch wieder die commandref aktuell...

Was die STT-Engine angeht, bin ich zwar relativ blind, aber im Prinzip ist auch innerhalb des Rhasspy-frameworks ja nicht nur der default drin, sondern man könnte verschiedene nutzen. Stellt sich die Frage, ob das auch "on the fly" ginge.
Weiter ist "voice2json" als Schwesterprojekt ja auf Geschwindigkeit getrimmt, v.a., was das Training im laufenden Betrieb angeht. Evtl. wäre es eine Idee, sich (parallel zu allem anderen) auch mal anzusehen, ob bzw. was damit machbar ist? (Sehe ich aber eher als mittel- bis langfristiges Thema an).

Was das Wakeword-Thema angeht: Prinzipiell stellt sich die Frage, ob man RHASSPY nicht eine siteId zuweisen sollte? In der messenger-Geschichte ist es so vorgesehen, wobei im Moment mein Favorit "<language><fhemId>" ist, die dann aber auf der "Gegenseite" (also in der Regel der Base) freigeschaltet werden muss.

(Generell: alles reichlich kompliziert, auch in der Einrichtung).

[Prof. Dr. Peter Henning]

Vielleicht klärst du mich auf, was du damit erreichen willst

Ich will, dass Raumnamen (auch) abstrahiert von Devices angegeben werden können. Mit einem Dummy, der diverse Raumnamen enthält, ist das ja schon getan.

Wenn es so gedacht ist, dass von FHEM aus ein beliebiger Satellit "geöffnet" werden soll, muss der als Argument übergeben werden (und bekannt sein).

Kein Problem, das geht

Mozilla DeepSpeech wird nicht mehr weiter entwickelt. 

Bäh.

Hier habe ich alle verfügbaren STT Modelle evaluiert: https://domcross.github.io/german-stt-evaluation/

Sehr gut.

zu 1. Frage:
   Seltsam, bei meinen Rhasspy-Installationen (Debian-Paket) wurde immer eine plughw erkannt. Vielleicht doch nur ein ALSA-Ploblem?

Identische Maschine, rhasspy einmal als Docker und einmal als Debian. Ohne Wechsel von SD-Karte oder Audio-Hardware.

zu 2. Beobachtung:
   https://github.com/MycroftAI/mycroft-precise/wiki/Training-your-own-wake-word#demoing-the-model

Längst geschehen, als standalone mit precise-listen läuft das sehr gut.
   

zu 3. Feature Requests für das Modul:
   a) Man konnte schon immer einem Device mehrere Räume zuordnen.

Das war aber nicht gemeint. Sondern eine abstrakte Liste von Räumen

   b) Die Erkennung des Hotwords kann auch vorgetäuscht werden

Prima, eines der Probleme gelöst. Muss nur noch herausfinden, ob es eine MQTT-Nachricht gibt, die das Ende von "speak" verkündet. Wenn ich meine Sprachausgabe mit Amazon Polly mache, kann ich immer die Laufzeit der erzeugten MP3-Dateien benutzen.

LG

pah

[JensS]

Muss nur noch herausfinden, ob es eine MQTT-Nachricht gibt, die das Ende von "speak" verkündet.

Code Auswählen Erweitern

hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "ttsSay"}

Gruß Jens