[läuft soweit] - Rhasspy ohne Zusatzhardware

[Beta-User]

Danke euch beiden für das Angebot - einen Testwilligen habt ihr schon mal.

Dann mal willkommen .

Ein Beitrag für die Dokumentation wäre hiermit gegeben:
Unter Debian11 es muss libgfortran4 installiert werden, ansonsten verweigert rhasspy die Installation.
Ich hab es im gleichem Verzeichnis wie folgt installiert, welches ich vorher hier gefunden habe: https://packages.debian.org/buster/amd64/libgfortran4/download

Code Auswählen Erweitern

sudo apt install ./libgfortran4_7.4.0-6_amd64.deb

Und gleich noch eine Klarstellung: wir können zwar möglicherweise beim einen oder anderen Problem weiterhelfen, aber solche allgemeinen Hinweise sollten eigentlich in Richtung der Rhasspy-Community zurückgespiegelt werden, damit es ggf. gefixt werden kann. Das Thema scheint nämlich ein immer wiederkehrendes zu sein: https://community.rhasspy.org/search?q=libgfortran .

[Gisbert]

Hallo Jörg,

die Android-App funktioniert wohl (sag ich mal), da ich Nachrichten auf meinem Mosquitto-Broker empfange.
Den Text bekomme ich per hermes/nlu/query rein und gesprochenen Text über das Mikrofon mit hermes/audioServer/GooglePixel4a/audioFrame - davon aber echt viele bei nur wenigen Worten.
Getestet habe ich das mit Mosquitto und Port 1883; da ich - wie schon erwähnt - Mosquitto für MQTT_DEVICE benutze, sehe ich die Nachrichten, wenn ich sie per mqtt.fx subskribiere.

Wenn ich aber die Daten, wie in den beiden Screenshots benutze, sagt "Check connection" "failed to connect" - hier fehlt etwas auf der Fhem-Seite.

Viele Grüße Gisbert

[Beta-User]

Getestet habe ich das mit Mosquitto und Port 1883; da ich - wie schon erwähnt - Mosquitto für MQTT_DEVICE benutze, sehe ich die Nachrichten, wenn ich sie per mqtt.fx subskribiere.

Wenn ich aber die Daten, wie in den beiden Screenshots benutze, sagt "Check connection" "failed to connect" - hier fehlt etwas auf der Fhem-Seite.

Auch in der App müßtest du den Port (unterhalb enable MQTT) auf den Wert einstellen, der für MQTT tatsächlich genutzt wird, also 1883 (oder eben doch gleich die serviced-file auf internen MQTT-Server umstellen, dann paßt der in der App hinterlegte default).

[Gisbert]

Guten Morgen Jörg,

oder eben doch gleich die serviced-file auf internen MQTT-Server umstellen, dann paßt der in der App hinterlegte default

Ich hab einen Cliffhanger. rhasspy.service startet mit port 12183; das sieht gut aus. In Fhem und der Android-App bekomme ich disconnected oder failed bei port 12183.
Ich weiß nicht, wie ich den interenen MQTT-Broker aktivieren kann - und das, was ich bisher gegoogelt habe, verstehe ich nicht oder wende es falsch an.
Kannst du mir weiterhelfen?

Viele​ Grüße​ Gisbert​

[Beta-User]

Sorry, der cliffhanger war eher bei mir... (Und zur Klarstellung: es gibt ziemlich sicher viele andere Leute hier, die dir an dieser Stelle eigentlich besser helfen könnten...)

Die service-file enthält bei mir gar keine Angaben zum zu verwendenden MQTT-Server, das stellt man am Rhasspy-Web-Interface (Port 12101) ein (MQTT: Internal).

Habe das jetzt auch bei mir so aktiviert (sollte der default sein). Dann müßte das "wie spät ist es" aus der App auch im R-Web-Interface als erkannt erscheinen (unterstellt, der MQTT-Port steht dort wieder 12183).

Dann muss MQTT2_CLIENT entsprechend auch dahin umgebogen werden. Bei mir:

Code Auswählen Erweitern

defmod rhasspy2mqtt MQTT2_CLIENT localhost:12183
attr rhasspy2mqtt clientOrder RHASSPY
attr rhasspy2mqtt subscriptions hermes/intent/+ hermes/dialogueManager/sessionStarted hermes/dialogueManager/sessionEnded hermes/nlu/intentNotRecognized

Aus irgendeinem Grund musste ich dann FHEM neu starten, damit die Kommunikation zwischen dem Client und RHASSPY wieder geklappt hat.
Du kannst checken, ob die Kommunikation zwischen M2C und dem Server klappt, indem du rawEvents auf .* stellst und dann im Event-Monitor schaust, was über MQTT reinkommt (Filter setzen; das klappt auch ohne Neustart).

[Gisbert]

Hallo Jörg,

wenn ich im Rhasspy-Web-Interface (Port 12101) ein MQTT: Internal auswähle, dann speichere, dann wird rhasspy.service neu gestartet mit Port 12183.
Im Fhem-Device rhasspy2mqtt steht opened mit port 12183, aber die Android-App will fürs Verrecken keine Verbindung mit Port 12183 herstellen, wohl aber zu Port 1883 - und es ist egal, ob man im Rhasspy-Web-Interface den internen oder externen MQTT-Server gewählt hat.

Ich verstehe es nicht, und mach mal eine Frühstückspause.
Gisbert​

[Beta-User]

Hmm, also die App-Settings, die in dem screenshot aus https://forum.fhem.de/index.php/topic,119679.msg1188119.html#msg1188119 zu sehen sind, sehen für mich ok aus (unterstellt, die IP stimmt).
Das Handy muss dann eine Netzwerkverbindung zum R-Server haben (bei mir via WLAN), und die Aufnahmefunktion muss aktiviert sein, also entweder auf das Mikro drücken (entspricht dem shortcut-Widget "Start recording"), oder via Wakeword. Hast du die App nach dem Ändern der Einstellungen mal geschlossen und wieder geöffnet? Hilft manchmal...

EDIT: in der App gibt es auch unten im MQTT-Abschnitt einen Knopf "Check connection". Was kommt dann da?

[Gisbert]

Schließen und Öffnen hilft nicht. "Check connection", sowie Texteingabe als auch das Mikrofon werden mit einer Pop-up-Leiste mit rotem Dreieck und Ausrufezeichen sowie "failed to connect" quittiert.
Verbindung zum Fhem/rhasspy-Server ist vorhanden.
User/Passwort müssten richtig sein, denn a) verlangt die App das, b) es funktioniert mit Port 1883, c) wenn falsch eingegeben erscheint ein anderer Text (zumindest bei Port 1883).

Da gibt es noch Knöpfe für Zertifikate, ansonsten bin ich ratlos.

[Prof. Dr. Peter Henning]

Eine ziemlich gute Dokumentation über Rhasspy ist im ersten Post hier zu finden:

https://forum.fhem.de/index.php/topic,124233.0.html

LG

pah

[Gisbert]

Hallo zusammen,

leider habe ich die Literaturstelle verloren, es wurde schon im Forum vermutet, warum die Verbindung in der Android-App zum internen MQTT-Server mit Port 12183 nicht klappt.

Der Hauptgrund (vielleicht einziger?), liegt daran, dass beim internen MQTT-Server kein User und Password vorgesehen sind, die App, dass aber vorgibt.
Ohne im Detail zu verstehen, was im rhasspy-Code genau geschieht (alle Achtung für diejenigen, die es verstehen und programmiert haben), glaube ich zu verstehen, dass ein User und Passwort nicht vorgesehen sind:

/usr/lib/rhasspy/rhasspy-supervisor/rhasspysupervisor/__init__.py
/usr/lib/rhasspy/rhasspy-supervisor/rhasspysupervisor/__main__.py

Mich würde halt interessieren, unter welchen Umständen eine Verbindung bei der Android-App und dem internen MQTT-Server eine Verbindung geklappt hat.

Viele Grüße Gisbert

[Beta-User]

Da gibt es noch Knöpfe für Zertifikate, ansonsten bin ich ratlos.

Zertifikate habe ich auch keine im Einsatz, und auch User/Passwort habe ich bei der Nutzung des internen Servers noch gesetzt. Daran sollte es also nicht liegen. Aber was ggf. noch wichtig wäre: die App hat/braucht eine "Kennung", die auf der App und in "Dialogue management => Satellite siteIds" (im Rhasspy-Web-Interface) übereinstimmen müssen.
Alles nach der Konfiguration für internen Server neu zu starten hast du vermutlich schon versucht?

Eine ziemlich gute Dokumentation über Rhasspy ist im ersten Post hier zu finden:

Dann mal willkommen im Rhasspy-Tester-Club .
Die Idee, nur das Wakeword (und/oder die Kombi WW und siteId) auszuwerten, hat auch was für sich. Vielleicht testest du mal, ob es nicht (erst mal) einfacher ist, die Infos über ein MQTT2_DEVICE abzufangen, beides wird innerhalb der Rhasspy-MQTT-Kommunikation verwendet, um z.B. den Dialogmanager zu aktivieren (was hier ggf. Gisberts Problem ist).

Ansonsten hatte ich die Darstellung zur Generierung eigener Wakewords zwar wirklich instruktiv gefunden, wäre aber von allein nicht auf die Idee gekommen, das als umfassende Einführung und den Rhasspy-Kosmos zu lesen .

[Beta-User]

@pah: In https://forum.fhem.de/index.php/topic,119447.msg1188779.html#msg1188779 findest du eine Modulfassung von RHASSPY, die u.a. auch direkt eine "hotword2action" und "hotword2event"-Funktionalität kann (bzw. können sollte). Falls du sowas zu Testzwecken benötigst und dich nicht mit dem etwas speziellen JSON-Format und MQTT2_DEVICE rumschlagen magst...


@Gisbert: Die Doku in der o.g. Modulfassung ist an der einen oder anderen Stelle mit ein paar kleinen Beispielen zu MQTT2_CLIENT und RHASSPY überarbeitet, v.a. was diese Einrichtungs-Themen angeht.

[Beta-User]

[OT]
@pah - da wir mit dem Wakeword-Thema eh' etwas OT waren: Siehst du eigentlich Möglichkeiten, Rhasspy und Babble irgendwie zusammenzubringen?
Ggf. könnte man dazu mal einen separaten Thread starten...

[Prof. Dr. Peter Henning]

Uff, habe meinen vorigen Post gelöscht - so etwas sollte man nicht nach 12 Stunden Arbeit schreiben...

Gemeint war: Klar, ich habe Babble ja schon zur Zusammenarbeit mit RiveScript und mit Rasa gebracht.

Babble könnte als ein Service zur Intent-Erkennung für Rhasspy werkeln.

LG

pah

[Beta-User]

Uff, habe meinen vorigen Post gelöscht - so etwas sollte man nicht nach 12 Stunden Arbeit schreiben...

Schade, irgendwie klang das nach interessant und lösbar, was mir von dem Post noch in Erinnerung geblieben war .

Gemeint war: Klar, ich habe Babble ja schon zur Zusammenarbeit mit RiveScript und mit Rasa gebracht.

Babble könnte als ein Service zur Intent-Erkennung für Rhasspy werkeln.

Darüber muss ich erst mal nachdenken, welche Vorteile das bringt. RHASSPY ohne Rhasspy? Oder ist mit "Rhasspy" hier tatsächlich der Service gemeint?

Na ja, erst mal hat mich das auf den Gedanken gebracht, RHASSPY vielleicht um eine Funktion für text2intent zu erweitern? Mal sehen...

Ansonsten: Wie würde man das grundsätzlich angehen mit Babble+Rhasspy/RHASSPY?