Modulentwicklung für Rhasspy Sprachassistent

[Prof. Dr. Peter Henning]

Nutze ich ja auch nicht, weil der MQTT-Server dafür in Rhasspy definiert ist.

Du hattest allerdings gesagt, Du wolltest RHASSPY zur alleinigen Schnittstelle zu Rhasspy machen - dann muss auch (wie aus der Rhasspy-App) die Möglichkeit bestehen, einen Text als Befehl an Rhasspy zu senden.

LG

pah

[Beta-User]

Imo ist diese App wie ein normaler Satellit zu behandeln und hat mit der Schnittstellendiskussion bezgl. FHEM nicht direkt was zu tun. Gehört für mich zur Rhasspy-Sphäre, RHASSPY kann nicht unterscheiden, welche Art Satellit das ist.
Für einen ESP-basierten Satelliten gilt btw. dasselbe.

[JensS]

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)

Habe ich hier einen Umbau beim textCommand von MQTT zu Websocket verpasst?
Wie bereits erwähnt, sollte man bei einer Übertragungsart (MQTT) bleiben und die Nutzung des Rhasspy-Webinterfaces (Websocket) tunlichst vermeiden.

Gruß Jens

[Beta-User]

Es gab keinen Umbau in Richtung websocket.
Im Code ist noch zu erkennen, dass ganz früher mal ein anderer Topic benutzt worden ist, um einen "fake command" abzusetzen.
Das ist aber "schon ewig", das das an nlu/query geht.

Gestern scheine ich vor lauter "App" und "andere App" etwas auf dem Schlauch gestanden zu haben:

dann muss auch (wie aus der Rhasspy-App) die Möglichkeit bestehen, einen Text als Befehl an Rhasspy zu senden.

Prinzipiell funktioniert das auch. Im Moment kann ich folgende Problemkreise erkennen:
- verwendet man den textCommand-Befehl an RHASSPY selbst, ist der "anonym", fhem/RHASSPY kann allenfalls anhand der sessionId erkennen, dass die Anfrage eine eigene ist. Die Zuordung einer Antwort zu irgendeiner Stelle in FHEM ist nicht vorgesehen und so auch nicht ohne weiteres möglich.
- Die "veranlassende Stelle" kann aber die "textResponse" abgreifen - vorausgesetzt, RHASSPY erzeugt ein Event an sich. Da war eine (vermutete) Lücke, die m.E. am effektivsten geschlossen wird, indem man ans Ende von sub response() das return auf return $hash->{NAME} aufbohrt. (Kommt bei nächster Gelegenheit). Hatte uU. Auswirkungen bei "devicelosen" Intents wie "GetTime".

- prinzipiell schwierig wird es, wenn eine Rückfrage zu beantworten wäre (Welches Device oder eine Bestätigung). Hab's nicht geprüft, aber Zweifel, ob das klappt bzw. überhaupt klappen kann.

- Besser wird die Situation mit den beiden jetzt etablierten Wegen, den Text-Input bei "Personen" (msgDialog/RESIDENTS/pushMsgReceived) bzw. "Hardware-Instanzen" (AMAD.*) abzugreifen. Da ist es "relativ einfach", den Rückweg zu ermitteln und auch temporär benötigte Daten vorzuhalten (weiß aber im Moment noch nicht, ob das überall wirklich klappt).

Prinzipiell müßte es auch möglich sein,
- z.B. den RESIDENTS-Ansatz auf andere (Text-) Input-Optionen aufzuweiten, falls dafür Bedarf bestehen sollte;
- bei textCommand (o.ä) eine "respond_command"-Info mitzugeben, allerdings wäre dann gleich die Anschlussfrage, wie das dann umzusetzen wäre; technisch würde man wohl das komplette (FHEM/Perl-) Kommando benötigen.

NACHTRAG noch:
Ein spezielles Thema sind "not recognized"-Rückmeldungen von Rhasspy. Im Moment werden die (in der Regel) einfach ignoriert. Hatte man eine Text-Message reingegeben, wäre vermutlich eine Rückmeldung hilfreich, dass eben die Message nicht verwertet werden konnte. Muss mal bei Gelegenheit schauen, ob/was man da was aus dem MQTT-Verkehr an Infos in RHASSPY darstellen kann/sollte.

[chicco]

Hallo zusammen,

bisher bin ich noch mit Snips unterwegs, wollte jetzt aber mal rhasspy probieren (weil ich bald umziehe und in der neuen Wohnung brauche in Satelliten, das wird schwierig mit Snips).
Bin laut der Schnellstart-Anleitung vorgegangen, aber ich scheiter am define des rhasspy-device.

Nach Eingabe von

Code Auswählen Erweitern

defmod rhasspy RHASSPY baseUrl=http://192.168.0.128:12101
bekomme ich die Antwort: Cannot load module RHASSPY

Im Log steht:

Code Auswählen Erweitern

2022.03.08 05:10:58 1: reload: Error:Modul 10_RHASSPY deactivated:
Can't locate FHEM/Core/Timer/Register.pm in @INC (you may need to install the FHEM::Core::Timer::Register module) (@INC contains: ./lib ./FHEM . /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.28.1 /usr/local/share/perl/5.28.1 /usr/lib/arm-linux-gnueabihf/perl5/5.28 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl/5.28 /usr/share/perl/5.28 /usr/local/lib/site_perl /usr/lib/arm-linux-gnueabihf/perl-base ./FHEM/lib) at ./FHEM/10_RHASSPY.pm line 46.
BEGIN failed--compilation aborted at ./FHEM/10_RHASSPY.pm line 46.

Hab den Fehler gegoogelt, aber nix brauchbares gefunden.
Was kann ich machen?

Gruß
chicco

[Beta-User]

Dann mal willkommen in der RHASSPY-Welt!

Dein FHEM ist "zu alt". RHASSPY setzt grundsätzlich ein ziemlich aktuelles FHEM voraus (aktuell: <ca. 3 Wochen), von daher kannst du froh sein, dass es so alt ist, dass diese lib (noch) nicht vorhanden ist, die wird seit längerem mit FHEM "geliefert".

Nach einem update sollte es klappen.

Nachtrag noch: Falls du als "prefix" "snips" wählst, könnte es sein, dass RHASSPY die betreffenden Attribute auch direkt mit auswertet. Wenn ich das aus den Augenwinkeln richtig erfasst habe, sollte die (Attribut-) Syntax häufig kompatibel sein von "snips" nach "RHASSPY@MQTT-classic" bis hin zu jetzt RHASSPY heute.

[chicco]

Danke für die schnelle Antwort.

Mein fhem war in der Tat schon länger nicht mehr geupdatet.
-> update gemacht, lief sauber durch
-> fhem neu gestartet

Wenn ich jetzt das rhasspy-device anlegen will, schmiert fhem ab, oben links kommt "connection lost, trying reconnect..."
Nach ca. 90 Sek. ist fhem wieder erreichbar.
Das rhasspy-device ist dann nicht vorhanden.

Im Log finde ich diesen Eintrag:
Can't use string ("en") as a HASH ref while "strict refs" in use at ./FHEM/10_RHASSPY.pm line 3462.
Statt "en" steht da manchmal auch "en_US"

Wenn ich die angegebene baseUrl im Browser aufrufe, sehe ich das rhasspy-web-interface.
Attribut language vom global-device steht auf "DE"
Den docker-container habe ich gestartet mit "profile en" (aus der Schnellstart-Anleitung abgeschrieben)

Netter Hinweis mit dem prefix, aber soweit bin noch nicht

[JensS]

Attribut language vom global-device steht auf "DE"
Den docker-container habe ich gestartet mit "profile en" (aus der Schnellstart-Anleitung abgeschrieben)

Code Auswählen Erweitern

rhasspy -p de

Gruß Jens

[chicco]

@Jens:
ich nehme an, du wolltest mir mit deinem Schnipsel sagen, dass ich den rhasspy-docker-container mit einem deutschen Profil starten soll.
Mich irritiert der Parameter -p, beim docker run Befehl werden damit doch die Ports angegeben.

Ich habe den rhasspy-docker-container jetzt mit "--profile de" gestartet. Wenn ich dann in fhem das rhasspy-device erstellen will, kommt der gleiche Fehler, nur mit "de" in der Fehlermeldung:

Code Auswählen Erweitern

Can't use string ("de") as a HASH ref while "strict refs" in use at ./FHEM/10_RHASSPY.pm line 3462.

Ich habe das hier gefunden:
https://forum.fhem.de/index.php?topic=97159.0
Die Fehlermeldung dort klingt ähnlich und es geht um MQTT2 (was ja bei rhasspy auch verwendet wird). Dort wird die Perl-Version diskutiert, ich habe hier v5.28.1

[Beta-User]

Hmmm, habe Schwierigkeiten, diese Fehlermeldung mit https://svn.fhem.de/trac/browser/trunk/fhem/contrib/RHASSPY/10_RHASSPY.pm#L3462 (rev. 25778) in Verbindung zu bringen.

Bitte die aktuellste Version verwenden (sollte so zu bekommen sein: { Svn_GetFile("contrib/RHASSPY/10_RHASSPY.pm", "FHEM/10_RHASSPY.pm") }), und bei solchen Dingen dann bitte auch angeben, mit welcher DEF du es versucht hattest. Bei mir läuft es jedenfalls seit langem ohne ausdrückliche Angabe einer  language in der DEF von RHASSPY.

Für das define des Moduls ist es auch erst mal unwichtig, ob überhaupt ein Rhasspy läuft und wie dessen Spracheinstellungen sind...

[chicco]

Hmmm, habe Schwierigkeiten, diese Fehlermeldung mit https://svn.fhem.de/trac/browser/trunk/fhem/contrib/RHASSPY/10_RHASSPY.pm#L3462 (rev. 25778) in Verbindung zu bringen.

Ich habe ebenfalls rev. 25778

Bitte die aktuellste Version verwenden (sollte so zu bekommen sein: { Svn_GetFile("contrib/RHASSPY/10_RHASSPY.pm", "FHEM/10_RHASSPY.pm") })

Der gleiche Befehl steht so auch im Wiki, den habe ich vorgestern so ausgeführt und gestern nach dem fhem-Update dann nochmal.

und bei solchen Dingen dann bitte auch angeben, mit welcher DEF du es versucht hattest. Bei mir läuft es jedenfalls seit langem ohne ausdrückliche Angabe einer  language in der DEF von RHASSPY.

Jetzt wollte ich eben die DEF für dich raussuchen und habe es nochmal probiert und es hat geklappt 
Unterschied zu vorher: jetzt grade läuft der raspi mit dem Docker-Container nicht!

Nochmal von vorne:
Ich habe einen pi4, darauf läuft fhem.
Ich habe einen pi3, mit Mikro und Lautsprecher, darauf läuft snips.

Um jetzt rhasspy zu testen habe ich eine andere SD-Karte genommen, darauf ist ein frisches bullseye gebrannt. Damit dann den pi3 gebootet, docker installiert, und per "docker run..." das rhasspy image gezogen und gestartet.

Mit dieser DEF habe ich es versucht:

Code Auswählen Erweitern

defmod rhasspy RHASSPY baseUrl=http://192.168.0.128:12101
192.168.0.128 ist der pi3

Wenn der pi3 mit der rhasspy-sd-Karte läuft, bekomme ich den Fehler.
Wenn der pi3 mit der snips-sd-Karte läuft oder ausgeschaltet ist, bekomme ich keinen Fehler und das rhasspy-device wird erstellt.

Wenn das device erstellt wird, kommt natürlich ein Fehler im STATE:
192.168.0.128: Keine Route zum Zielrechner (113) -> wenn der pi3 ausgeschaltet ist
192.168.0.128: Verbindungsaufbau abgelehnt (111) -> wenn der pi3 mit der snips-sd-Karte läuft
Die STATE-Fehler können wir hier natürlich ignorieren, denn wenn der pi3 nicht läuft bzw. wenn snips darauf läuft, kann da natürlich kein rhasspy antworten.

Ich denke ich mache jetzt so weiter:
pi3 ausschalten, device erstellen, pi3 booten und dann weiter nach Anleitung...
Müsste funktionieren, oder?

Vielleicht hilft euch meine Fehlerbeschreibung bei der Fehlersuche, hier ist es auf jeden Fall reproduzierbar.

[JensS]

Ich tippe mal darauf, dass keine Satelliten definiert sind.
Bei der Suche nach satellite_site_ids wird das ganze JSON durchsucht und bei language: "de" streikt Perl, weil es sich um einen String handelt.
In meinem Vorschlag zu fetchSiteIds hatte ich bewusst

Code Auswählen Erweitern

$ref->{'dialogue'}{'satellite_site_ids'});geschrieben, da die SiteIds des Dialogmanagers verwendet werden sollten und nicht die SiteIds anderer Module (wakeword, etc.).

Gruß Jens

[Beta-User]

Ich tippe mal darauf, dass keine Satelliten definiert sind.
Bei der Suche nach satellite_site_ids wird das ganze JSON durchsucht und bei language: "de" streikt Perl, weil es sich um einen String handelt.
In meinem Vorschlag zu fetchSiteIds hatte ich bewusst

Code Auswählen Erweitern

$ref->{'dialogue'}{'satellite_site_ids'});geschrieben, da die SiteIds des Dialogmanagers verwendet werden sollten und nicht die SiteIds anderer Module (wakeword, etc.).

Das sieht mir eher so aus, als hätte sich irgendwas an der Antwort an sich geändert, und @chicco ist einfach der erste, der einen aktualisierten container getestet hat. Jedenfalls würde  diese Beschränkung den Absturz m.E. auch nicht verhindern.
Die Hereinnahme weiterer möglicher siteId's mag man kritisch sehen, hat aber eigentlich kaum eine praktische Relevanz.

Bitte das aktuelle update aus dem svn holen, das sollte das beheben (und @pah: auch immer triggern, wenn es eine "devicelose" Anwort gibt).

[JensS]

Nun will ich nicht die Laune verderben aber es handelt sich um eine Frage des Datentyps. 

Code Auswählen Erweitern

!defined $ref->{$_}{satellite_site_ids};fragt nach einen Subkey {'satellite_site_ids'}.
Wenn der Hauptkey {'language'} an der Reihe ist, crasht die Abfrage, da es dort keine Subkeys gibt und der String-Value "de" die Frage nach einem Key nicht versteht.

Die Abfrage auf den Key {'dialogue'} zu beschränken, macht insofern Sinn, da im Dialog von Rhasspy nur die Satelliten verarbeitet werden, welche dort aufgeführt sind.

Gruß Jens

[Beta-User]

Wie dem auch sei, mit der aktuellen svn-Version sollte es dieses Problem nicht mehr geben...