Modulentwicklung für Rhasspy Sprachassistent

[Prof. Dr. Peter Henning]

Stellt sich die Frage, inwieweit eine Doppelung Sinn macht oder ob da nicht einfach ein notify angeflanscht werden kann/soll? (Meine Sorge: Mehr Optionen = mehr Verwirrung für die User, aber nicht wirklich mehr Funktionalität).

Na ja, was denn nun? Nach meiner Auffassung ist das jetzt ein entscheidender Punkt in der Entwicklung des RHASSPY-Moduls.

- Soll es als alleinige Schnittstelle für die Ankopplung von FHEM an Rhasspy dienen? Wenn JA, muss es schon die Funktionalitäten bieten, die eine Anbindung sowohl "nach oben" (also z.B. an Spracherkennungsdevices wie AMAD-Geräte) als auch "nach unten" (also z.B. an Babble) komfortabel möglich machen. Der Preis dafür ist hoch, nämlich wie Du zu Recht geschrieben hast, erfordert das viel mehr Optionen und erzeugt mehr Verwirrung.

- Oder soll es der einfache Weg zur Ankopplung von FHEM an RHASSPY sein? Wenn JA, sollte der ganze Kram mit AMAD und Babble aus dem Modul heraufallen. Das vermeidet auch unnötige gegenseitige Abhängigkeiten.

Tertium non datur, und ich plädiere für den zweiten Weg. So habe ich das ja auch beim Shelly-Modul gemacht, und das hat sich als sehr erfolgversprechend herausgestellt: Schnell und direkt verwendbar. Wer die Shelly-Devices detaillierter ausnutzen (oder steuern) will, sollte sie über MQTT anbinden.

LG

pah

[Beta-User]

So, nachdem ich AMAD jetzt doch noch ans laufen gebracht habe, gibt es im SVN jetzt eine Version, bei der die Datenübergabe auch soweit erkennbar sauber durchläuft .
Da war die "allowed" Prüfung "verbogen" gewesen, sorry...

Das wäre (aus meiner derzeitigen Sicht) eine Lösung, welche Hermes-Konform ist und keine Änderung oder Erweiterung des Protokolls bedarf.
Die Anfrage nach deaktivierten Intents kam bereits von anderen Usern aber noch keine Lösung dazu.

Es geht nicht (nur) darum, ob der Bedarf dafür besteht...

Ob es "hermes"-konform ist, ist dagegen m.E. nicht primär wichtig (wenn auch "wünschenswert", weil es dann wenigstens eine Doku dazu gibt).

Na ja, was denn nun?

...muss ich mal noch drüber nachdenken, jetzt ist erst mal der Schritt insoweit gemacht, dass sich über AMAD.*=> RHASSPY Lichter schalten lassen .

Jetzt bekomme ich halt über Telegram irgendwelchen  "Forwarded Message"s .

[drhirn]

- Oder soll es der einfache Weg zur Ankopplung von FHEM an RHASSPY sein? Wenn JA, sollte der ganze Kram mit AMAD und Babble aus dem Modul heraufallen. Das vermeidet auch unnötige gegenseitige Abhängigkeiten.

Also wenn man mich fragt, wär das mein Weg. Weil, wo fängt das an und wo hört das auf? Man könnte unter Umständen zusätzliche Readings einbauen, die dann von wo anders abgerufen werden können. Aber alles andere wird viel zu kompliziert.

[JensS]

Ob es "hermes"-konform ist, ist dagegen m.E. nicht primär wichtig (wenn auch "wünschenswert", weil es dann wenigstens eine Doku dazu gibt).

Da die verschiedenen Module für ASR, etc. beliebig gewechselt werden können, sehe ich eine Konformität auf Protokoll-Ebene als zwingend an. Vielleicht ist die Notwendig der Entwicklung der Dialogfähigkeit aktuell nach hinten gestellt. Dabei sucht @synesthesiam gerade genau jetzt nach einer Lösung zur gleichzeitigen Nutzung von der klassischen Steuerung und des offenen Modus...

[Beta-User]

Na ja, was denn nun?

Nach etwas Nachdenken, ist die Welt m.E. nicht ganz so "entweder oder". Meine Sichtweise:

- RHASSPY sollte _eingangsseitig_ die alleinige Schnittstelle für die Ankopplung von FHEM an Rhasspy sein.
Den MQTT2_CLIENT zusätzlich "anzuzapfen", um dieselben Topics auszuwerten, die auch RHASSPY entweder "sowieso" oder optional abhört, macht die Gesamtkonstruktion sehr viel unübersichtlicher und bietet keinen wirklichen Vorteil.
Ergo "muss" RHASSPY die eingehenden Infos "ähnlich" wie MQTT2_DEVICE in FHEM weitergeben können, einschl. des direkten Aufrufs von Perl-Code.
Bzgl. der Hotword-Geschichte bin ich zwar immer noch skeptisch, ob es wirklich die Weitergabe von "$EVENT" braucht, aber darauf kommt es dann auch nicht mehr an .
Die in dieser Hinsicht noch verbleibende Flanke wäre "intentNotRecognized", aber das würde ich erst mal zurückstellen, da sind mir im Moment noch zu viele Variablen drumrum. Prinzipiell wäre es aber auch kein Ding, das z.B. in "Tweaks" mit zu erschlagen und dann halt "irgendein" Kommando mit den Daten zu füttern.

Also wenn man mich fragt, wär das mein Weg. Weil, wo fängt das an und wo hört das auf? Man könnte unter Umständen zusätzliche Readings einbauen, die dann von wo anders abgerufen werden können. Aber alles andere wird viel zu kompliziert.

Damit ist m.E. das "Pflichtprogramm" umrissen und es ist auch nicht allzu kompliziert im Modul zu verorten und auch nicht in der Erklärung für die User.

Entsprechender Code ist in der Vorbereitung, ich will aber zuerst selbst noch testen, wird etwas dauern.

Wenn JA, muss es schon die Funktionalitäten bieten, die eine Anbindung sowohl "nach oben" (also z.B. an Spracherkennungsdevices wie AMAD-Geräte)

Den Teil hoffe ich in dem Zuge auch vollends erledigen zu können. Prinzipiell bin ich mit den "textorientierten Eingabemethoden" im Zusammenwirken mit RHASSPY/Rhasspy zufrieden, das erweitert die Möglichkeiten doch sehr, und es gibt im Prinzip auch nur zwei Methoden, die (demnächst) beide implementiert sind, nämlich "one-shot"-Verfahren (so ist AMAD.* (mit und ohne Babble) grade konzipiert) und "Kennwort + (FHEM-interner) Dialog bleibt eine zeitlang offen" (ala msgDialog). Falls da also (neben der sowieso generischen (!) Schnittstelle msgConfig) noch was käme, sollte es nicht allzu schwierig sein, das noch zusätzlich einzubauen.

als auch "nach unten" (also z.B. an Babble)

Was die Ausgangsseite angeht: Eine "nahtlose" Integration ist zwar wünschenswert, allerdings stellt sich in der Tat die Frage, wie das ganze sinnvoll gegeneinander abzugrenzen sein soll, und wie der interne Datenfluss sein müßte.
Die Abgrenzung über "Sage mycroft" ist jedenfalls mal ein erster Ansatz, auch wenn das irgendwie noch nicht "schön" ist. Mittelfristig könnte man das z.B. erweitern oder ergänzen um ein Reading (rhasspy2babble_.*), anhand dem (zusätzlich? als override?) eingestellt werden kann, ob Rhasspy eventuellen Input bekommen soll oder (z.B.) Babble. Dann kann der User @runtime (z.B. anhand des wakewords?) entscheiden, wohin eine Info soll...

Letztlich wird es auf dieser Seite der Strecke immer so sein, dass persönliche Vorlieben und ggf. historisch gewachsene Strukturen berücksichtigt werden müssen, und zumindest nach meinem jetzigen Kenntnisstand eben jede Lösung ihre Stärken hat.

Da der Weg m.E. nicht mehr allzuweit ist, um das zumindest für Babble auch noch hinzubekommen (und das auch nicht allzu spezifisch ist), würde ich gerne versuchen wollen, das vollends soweit zum Laufen zu bekommen, dass man sich Gedanken darüber machen kann, ob das "zu kompliziert" ist, oder ob sich das insgesamt gut integriert anfühlt (bzw. unter welchen weiteren Voraussetzungen und mit welchen weiteren Ergänzungen).

Da die verschiedenen Module für ASR, etc. beliebig gewechselt werden können, sehe ich eine Konformität auf Protokoll-Ebene als zwingend an.

Wir reden vermutlich aneinander vorbei: Rhasspy-intern ist es zwingend, dass die verschiedenen Module dasselbe Verständnis vom verwendeten Protokoll haben. Was aber nicht heißt, dass das "hermes-pur" oder "hermes-original" sein muss. Man kann das weiterentwickeln oder neue/andere Konventionen festlegen. Zu vermeiden ist aber Verwirrung, also alte Syntax, neue Bedeutung.

[Prof. Dr. Peter Henning]

In dieser Woche habe ich noch etwas Zeit zu Testen. Nächste Woche bin ich zum Golfen in Südfrankreich, falls die Welt bis dahin noch steht.

LG

pah

[Beta-User]

...na dann, bevor die Welt vollends untergeht: habe eben die nur ganz kurz angetestete Fassung ins svn geschubst, damit auch die Änderungen leichter auszumachen sind: https://svn.fhem.de/trac/changeset/25757/

Betr. "hotword" sollte die commandref ausreichend aufschlussreich sein, ansonsten hoffe ich mal dass man jetzt auch eine Antwort bekommt, wenn Aktionen per AMAD.* angeschubst wurden.

[Beta-User]

Hallo zusammen,

kurz die Fassung von gestern (im svn) angetestet und festgestellt, dass die Antwort immer noch an die falsche Adresse geht .

Jetzt habe ich mir diesen Teil des Pfades auch nochmal etwas intensiver (theoretisch) angesehen und glaube auch, noch einige Ungereimtheiten gefunden zu haben, die mit zu großen Parallelitäten zum msgDialog-Pfad zu tun hatten. Weiß noch nicht, ob das alles war, aber Schritt für Schritt sollten wir uns dem Ziel nähern...

Es gibt jetzt auch ein Reading "rhasspy_dialogue" am "Startdevice" für STT/TTS (typischweise: AMADDevice), anhand dem man erkennen kann, ob RHASSPY erwartet, dass die Sitzung fortgesetzt werden soll, z.B. weil es eine Rückfrage gab und nach der Sprachausgabe (deren Dauer RHASSPY nicht kennt) das Mikro wieder eingeschaltet werden sollte. Kann sein, dass es mittelfristig elegantere Lösungen gibt, aber auf die Schnelle ist mir erst mal nichts besseres eingefallen .

[Beta-User]

Weiß noch nicht, ob das alles war, aber Schritt für Schritt sollten wir uns dem Ziel nähern...

...es war noch nicht alles, mind. eine entscheidende Stelle hatte ich übersehen, bei der der Code in Richtung msg-System statt TTS "abgebogen" war...

Groß zum Testen komme ich aber derzeit nicht.

EDIT: aber wenigstens klein getestet: Jetzt gibt es eine Sprachausgabe - allerdings ist das ganze gefühlt bei der Ausgabe sehr viel langsamer als Rhasspy direkt.

[Beta-User]

Fyi: die aktuellste Fassung findet sich jetzt wieder im svn, relevant ist das erst mal v.a. für Mittester an dem "AMAD-feature", außerdem ist die Version ggf. für die interessant, die irgendwas spezielleres rund um "wakeword" realisieren wollen* (siehe commandref).

Wie gestern abend bereits mitgeteilt, funktioniert jetzt auch die Sprachausgabe der $response via AMADDevice, was in etwa so viel bedeutet wie: Der "Pfad" ist bekannt, jetzt geht es um's "aufräumen" und ausbauen.

Noch ungetestet sind folgende Aspekte:
- (*) wakeword - spezielle Aktionen, Parameterübergabe usw.
- Verhalten bei Rückfragen/Bestätigungen (das betrifft im Übrigen auch den msgDialog-Teil). Mit etwas Glück funktioniert das, aber auch der Teil muss jeweils noch getestet werden, wobei bei der "voice"-Variante (AMAD) hinzukommt, dass man den voiceInput ja auch wieder aktivieren muss (im Moment muss man das per Eventhandler selber organisieren**)

Was das "aufräumen" angeht, ist im Moment noch das Attribut rhasspyTTS erforderlich, um den Rückweg zu organisieren, aber "eigentlich" müßte es möglich sein, (für eine "default-Verwendung") praktisch alles automatisch einzurichten, wenn der User eine schlicht und einfach angibt, welche AMADDevice-Instanz(en) als "Text-to-Rhasspy"-Input genutzt werden dürfen.

Abweichungen zum "default" könnte man dann (hoffentlich zwanglos) einfach in der "üblichen key=value-Schreibweise" in einer Zeile unterbringen, die mit dem Schlüssel des Namens der Gegenstelle beginnt...? Da könnte man auch eine wakeword=>Input-Device-Zuordnung machen?

Hmm, mal schauen...

[Beta-User]

Hallo zusammen,

habe eben im svn eine Fassung eingecheckt, die das hier umsetzt:

Code Auswählen Erweitern

Was das "aufräumen" angeht, ist im Moment noch das Attribut rhasspyTTS erforderlich, um den Rückweg zu organisieren, aber "eigentlich" müßte es möglich sein, (für eine "default-Verwendung") praktisch alles automatisch einzurichten, wenn der User eine schlicht und einfach angibt, welche AMADDevice-Instanz(en) als "Text-to-Rhasspy"-Input genutzt werden dürfen.

Man muss nur noch den "allowed"-Key in rhasspySTT (auf ein/mehrere vorhandene/s AMADDevice/s) setzen, dann weiß RHASSPY, dass auf Events in den zugehörigen AMADCommBridge zu hören ist. Damit ist es prinzipiell relativ einfach einzurichten, den voiceInput muss man halt noch "selbst"  aktivieren (kann sein, dass das auch recht einfach geht, wenn man das passende wakeword angibt, ist an der Stelle noch ungetestet).

Vermutlich bekommt das Attribut dann noch einen anderen Namen, da es funktional jetzt bidirektional ist.

[Prof. Dr. Peter Henning]

OK, Bericht zur aktuellen Version aus dem SVN.

Erste Angelegenheit:

1. Wenn ich aus FHEM ein textCommand absende, z.B. "schalte den nichtstoerenmodus an" => prima, wird in Rhasspy in den Intent übersetzt, zurück an RHASSPY gesendet und ausgeführt.
2. Wenn ich aus der App ein Kommando absende, z.B. "schalte den nichtstoerenmodus an" => prima, wird in Rhasspy in den Intent übersetzt, zurück an RHASSPY gesendet und ausgeführt.
3. Wenn ich aus der App das Kommando absetze "wie spaet ist es" (bewusst mit ae, so ist der Intent definiert), wird der Intent erkannt und - weil als TTS-Device in Rhasspy ein MQTT-Server eingetragen ist - die Sprachausgabe wieder in einer anderen Ecke von FHEM gemacht. => prima, passt auch
2. Wenn ich aber als textCommand in RHASSPY absetze "wie spaet ist es", kommt in RHASSPY

- manchmal die Fehlermeldung "read from http://192.168.0.115:12101 timed out" und gar nichts an bei RHASSPY
- manchmal geht es durch zu RHASSPY:

Code Auswählen Erweitern

[DEBUG:2022-03-05 19:39:36,769] rhasspyserver_hermes: Sent 362 char(s) to websocket
[DEBUG:2022-03-05 19:39:36,765] rhasspyserver_hermes: <- NluIntent(input='wie spaet ist es', intent=Intent(intent_name='de.fhem:GetTime', confidence_score=1.0), site_id='default', id=None, slots=[], session_id='fhem.textCommand', custom_data=None, asr_tokens=[[AsrToken(value='wie', confidence=1.0, range_start=0, range_end=3, time=None), AsrToken(value='spaet', confidence=1.0, range_start=4, range_end=9, time=None), AsrToken(value='ist', confidence=1.0, range_start=10, range_end=13, time=None), AsrToken(value='es', confidence=1.0, range_start=14, range_end=16, time=None)]], asr_confidence=None, raw_input='wie spaet ist es', wakeword_id=None, lang=None)

Aber ohne dass eine Ausgabe erfolgt. Das RHASSPY-Modul sollte aber - wie unter Punkt 3 - ein TTS-Kommando an Rhasspy senden, das dann auch ausgeführt wird. Macht es aber nicht, oder nicht korrekt. Wohlgemerkt, das "speak"-Kommandu in RHASSPY funktioniert korrekt.

Zweite Angelegenheit:
Das Handling von Umlauten ist kryptisch. Mein Android-Device mit der App sendet utf8 - "ä" wird als "ä" erkannt. FHEM sendet bei mir eine andere Codierung, das textCommand "wie spät ist es" wird also nicht korrekt erkannt. Das sollte irgendwo in der language-Datei abgefangen werden, eine Dokumentation dazu habe ich aber nicht gefunden.

LG

pah

[Beta-User]

Zum Verständnis: "App"=AutoMagic, nicht die Rhasspy-App?
In global ist das "encoding-Attribut" nicht gesetzt?

Mein AMAD-Androide beantwortet "wie spät ist es" ordnungsgemäß (aber spät).

Das encoding der languageFile legt der User fest, die wird nur eingelesen "as is" (so jedenfalls mein Verständnis dessen, was Rudi dazu in Development gesagt hat).

Soviel in der Kurzversion, den Rest muss ich mir in Ruhe anschauen.

Viel Spaß beim Golfen! (hoffe, das kann stattfinden!!!)

[Prof. Dr. Peter Henning]

Zum Verständnis: "App"=AutoMagic, nicht die Rhasspy-App?

Doch, Rhasspy-App ist gemeint.

In global ist das "encoding-Attribut" nicht gesetzt?

Das halte ich für irrelevant, weil entsprechende Befehle auch von anderen Systemen in meinem Haus kommen können. Müsste m.E. von RHASSPY abgefangen werden.

LG

pah

[Beta-User]

Das halte ich für irrelevant, weil entsprechende Befehle auch von anderen Systemen in meinem Haus kommen können. Müsste m.E. von RHASSPY abgefangen werden.

Im Prinzip schon klar, wobei es uU. eben auch ein Thema ist, dass diese "anderen Systeme" "ordentliche " Daten abliefern. Bei der Frage ging es erst mal darum, rauszufinden, ob es im "noch-default" Probleme gibt, oder das ganze schon verkompliziert ist...

"wie spät ist es" funktioniert bei mir auch mit der R-App.

textCommand ist eigentlich gar nicht für die Sprachausgabe gedacht, die Antwort kommt nicht-triggernd in textResponse. Dazu müßte man sich den flow nochmal ansehen, auch im Hinblick darauf, was man ggf. an Infos mitgeben muss, damit klar ist, wo dann eigentlich eine Reaktion erwartet wird.

Da du von TTS sprichst: in der aktuellsten Version gibt es dieses Attribut m.E. gar nicht mehr. (0.5.19)