[läuft soweit] - Rhasspy ohne Zusatzhardware

[Beta-User]

Hallo zusammen,

Rhasspy bietet vom Ansatz her eine Sprachsteuerung ohne Cloudanbindung - finde ich super.
Die Standard-Anleitung dazu beginnt aber mit: Man nehme einen Raspberry und ein Aufsatzmodul dazu oder schließe Mikro+Lautsprecher an - paßt nicht zu meinen Vorstellungen und Gegebenheiten, mal abgesehen davon, dass es zunächst ja mal ums Kennenlernen und Testen ging...

JensS hat dankenswerter Weise darauf hingewiesen, dass es auch eine App für Androiden gibt, die man als Interface einsetzen kann: https://github.com/razzo04/rhasspy-mobile-app.
Soweit so gut - das Problem ist dann "nur", dass man als noob in dem Thema dann erst mal praktisch keine Info hat, welche Einstellungen dann unter Rhasspy und der App vorzunehmen sind, damit das ganze funktioniert.

Habe daher etwas geraten und rumgespielt, und am Ende hat mir mein Handy dann die Zeit angesagt - "hello world" war geschafft...
Also falls jemand das  interessiert,  hier die Zusammenfassung:

Vorbereitung:
- Installation via deb-Paket auf einer sowieso laufenden x86_64-Ubuntu-Maschine. Ich war unsicher, ob das ganze Zugriff auf Soundhardware braucht und/oder große Systemlast erzeugt. Beides ist/scheint nicht der Fall zu sein. Vermutlich werde ich das ganze am Ende dann direkt auf den (x86_64)-FHEM-Server umziehen. (Für den Pi  gibt es auch ein docker-Image). Da die Audiodaten via MQTT ausgetauscht werden ( ), läuft jetzt noch ein mosquitto auf der Ubuntu-Maschine, vermutlich werde ich das dann bei einem Umzug auch so machen (aber auf einem anderen Port, damit es nicht mit dem für "normale Zwecke" reservierten MQTT2_SERVER kollidiert).
- Da rhasspy als normales deb-Paket installiert wurde, wird das Progrämmchen nicht automatisch gestartet, bis auf weiteres habe ich einfach in der user-Sphäre einen autostart angelegt: "rhasspy --profile de".
- In FHEM unsere aktuelle (0.4.4-) Version von hier, angebunden über einen MQTT2_CLIENT mit "subscriptions setByTheProgram". (siehe cref zu M2C)
- Auf dem Andorid-Handy die o.g. App.

Einstellungen:
- Rhasspy (zu erreichen über ein Web-Interface auf Port 12101 - hier das json aus dem backup):

Code Auswählen Erweitern

{
    "dialogue": {
        "satellite_site_ids": "mobile1",
        "system": "rhasspy"
    },
    "intent": {
        "satellite_site_ids": "mobile1",
        "system": "fsticuffs"
    },
    "microphone": {
        "system": "hermes"
    },
    "mqtt": {
        "enabled": "true",
        "site_id": "wohnzimmer"
    },
    "sounds": {
        "system": "hermes"
    },
    "speech_to_text": {
        "satellite_site_ids": "mobile1",
        "system": "kaldi"
    },
    "text_to_speech": {
        "satellite_site_ids": "mobile1",
        "system": "espeak"
    },
    "wake": {
        "system": "hermes"
    }
}

App:
- IP => die von der Ubuntu-Maschine
- kein SSL
- enable MQTT (an)
- host / port: IP von der Ubuntu-Maschine, Port vorerst auf 1883
- Username+Passwort (gesetzt, aber nicht in mosquitto)
- Siteid: "mobile1" (wie oben in den Rhasspy-Einstellungen!)
- Wake word (an)

Wie gesagt: Das reichte, um eine Antwort auf die Frage nach der Uhrzeit von FHEM zu erhalten, alles noch nicht schön und etwas verwirrend, aber ein Anfang.

Die weiteren Schritte werden jetzt sein, diverse Einstellungen in FHEM vorzunehmen und ggf. auch das eine oder andere auf der Rhasspy-Seite auszutesten, aber dazu ggf. ein andermal mehr.


Falls jemand Anregungen und Verbesserungsvorschläge hat: Her damit - die Stimme ist nämlich z.B. bei längeren Sätzchen schon überfordert...

Danke an JensS und drhirn für die Schubser in diese Richtung! 

[drhirn]

Auf der Base brauchst du keine Audio-Hardware. "Audio Recording", "Wake Word", "Audio Playing" und "Intent Handling" kannst du auf disabled setzen.

Im Screenshot sind die Einstellungen meiner Base und eines Satelliten.

[JensS]

Um richtig testen zu können, solltest Du auch die WakeWord-Engine nutzen.

[Beta-User]

Um richtig testen zu können, solltest Du auch die WakeWord-Engine nutzen.

Danke für den Tipp.
Rückfrage dazu: Bisher habe ich die App so genutzt, dass ich das Gerät in die Hand genommen habe, und dann eben auf den "shortcut" gedrückt habe, den das zur App gehörende widget bereitstellt. Das war erst mal ok.

Wenn jetzt ein Wakeword zum Einsatz kommt: Lauscht das Ding dann immer? Inwieweit geht das auf den Akku?
Ich werd's so oder so mal Testen, welche Engine ist dann die beste Wahl? Wie üblich, das, was mit recommended angemarkert ist, oder doch in der Konstellation was anderes?


Der Vollständigkeit halber hier noch was aus dem anderen Thread, das eigentlich besser hierher gehört - damit es zusammen ist...

systemd-file (ungetestet):

Code Auswählen Erweitern

[Unit]
Description=Rhasspy Service
After=syslog.target network.target

[Service]
Type=simple
ExecStart=/bin/bash -o pipefail -c '{ /usr/bin/rhasspy -p de 2>&1 | cat >&2 3>&-; } 3>&1'
WorkingDirectory=/opt/rhasspy
User=rhasspy
Group=audio
RestartSec=1
Restart=on-failure
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=rhasspy

[Install]
WantedBy=multi-user.target

Und ein paar interessante Videos für eventuelle interessierte Mitleser, eine super Einführung zu Rhasspy an sich finde ich ist: https://www.youtube.com/watch?v=IsAlz76PXJQ
Zu den "sentences" das hier: https://www.youtube.com/watch?v=sWVl0ZoXZEo

Und dann gab es da noch was auf Französisch zu Satelliten:
https://www.youtube.com/watch?v=oTYpTYo2re8

[JensS]

Wenn jetzt ein Wakeword zum Einsatz kommt: Lauscht das Ding dann immer? Inwieweit geht das auf den Akku?

Und dann gab es da noch was auf Französisch zu Satelliten:
https://www.youtube.com/watch?v=oTYpTYo2re8

Das Wakeword kann man auch ausstellen. Wenn es an ist, läuft es natürlich immer - ähnlich wie "Hey Google", nur halt ohne Datenverarbeitung Dritter.
Nachteilig dabei ist, dass ein Datenstrom bei Audioerkennung zur WWE fließt, egal ob WW oder sonstige Geräusche. Die Datenrate ist nicht hoch und behindert im AC_Mode auch nicht das WLAN. Wenn WWE und Mikro auf einer Maschine sind, wird das Netzwerk geschont.

Gruß Jens

[drhirn]

Zumindest bis Android die App im Hintergrund killt, nehme ich an?

[Beta-User]

Auch hier mal noch ein aktualisierter Zwischenstand:

Auf der Base brauchst du keine Audio-Hardware. "Audio Recording", "Wake Word", "Audio Playing" und "Intent Handling" kannst du auf disabled setzen.

So habe ich das jetzt gemacht, und dann auch auf NanoTTS umgestellt. Das ist wirklich sehr viel verständlicher als das, was espeak so abgeliefert hatte!

Wakeword mit porcupine war leider ein Fehlschlag. Entweder ich bin nicht in der Lage, das passende dir zu finden, in das die Dateien reingehören, oder es ist bug bei x86-Systemen, der doch nicht durch den move nach 2.5.9 gelöst wurde (=> https://community.rhasspy.org/t/show-stopper-wakeword/2182/2).

Von daher habe ich mich auch noch nicht mit den Auswirkungen auf Batterie und Netzwerk befasst...

Wenn WWE und Mikro auf einer Maschine sind, wird das Netzwerk geschont.

An sich wäre es sowieso die bessere Lösung, das ganze lokal auf dem Handy zu lösen, aber dazu habe ich bislang nicht recherchiert. Falls also dazu jemand auch auf die Schnelle einen Vorschlag aus dem Hut zaubern kann, wäre das klasse!

Ansonsten wäre ich für zielführende Hinweise zu porcupine auch dankbar .


Dann war da noch der Versuch, Rhasspy auf dem FHEM-Server zu installieren...

Das klappte zwar, aber weder mit meiner supertollen serviced-file noch überhaupt mit dem "normalen" user auf der headless-Machine war rhasspy zum Starten zu überreden. Da scheinen irgendwelche Packages (Multimedia-Zeug?) zu fehlen, von denen ich annehme, dass die auf einer Desktop-Installation vorhanden wären.
Das ganze ist also vermutlich ein dickeres Brett und bekommt eine niedrige Prio, denn auf meinem anderen "Provisoriums-Server" läuft das ganze ja im Moment anstandslos...
Aber auch da gilt: Vielleicht hat ja jemand ein funktionierendes Kochrezept, das er hier posten oder verlinken will...?

[JensS]

Espeak klingt lustig...  NanoTTS ist natürlich eine Stufe besser.
Die Sache mit dem geschonten Netzwerk, bezog sich auf die Nutzung der Zero's o.ä.. Das alles auf einem Handy/Tablet zu portieren, wäre interessant wenn es als Steuerzentrale in den Räumen genutzt würde.
Porcupine soll ja besser sein als Snowboy. Mit den vorinstallierten Wakewords konnte ich allerdings keinen Vorsprung gegenüber Snowboy feststellen.

war rhasspy zum Starten zu überreden

Im Allgemeinen installiert Rhasspy alles, was es braucht. Welche Fehler werden ausgegeben?

Gruß Jens

[Beta-User]

Das alles auf einem Handy/Tablet zu portieren, wäre interessant wenn es als Steuerzentrale in den Räumen genutzt würde.

Na ja, ich habe gewisse Erfahrungen mit FHEM auf einer TV-Box (@armbian) und es gab auch schon Versuche von anderen, FHEM in einer Andoid-Umgebung laufen zu lassen. An sich bin ich da skeptisch, was Aufwand vs. Nutzen angeht.
Cool fände ich es allerdings, (nur) die WWE auf Android zu portieren, um dann nur bei Bedarf den Traffic über das Netz zu starten. Übersteigt aber meine Möglichkeiten...

Porcupine soll ja besser sein als Snowboy. Mit den vorinstallierten Wakewords konnte ich allerdings keinen Vorsprung gegenüber Snowboy feststellen.

OK, dann werde ich mich wohl mal Snowboy zu wenden (braucht eine Registrierung, von daher wäre Raven vermutlich meine nächste Anlaufstelle gewesen, aber dann beschäftige ich mich halt erst mal mit Snowboy => falls jemand Tricks hat, die nicht auf readthedocs direkt ins Auge springen...?.)

Im Allgemeinen installiert Rhasspy alles, was es braucht. Welche Fehler werden ausgegeben?

Startvorgangsversuch sieht so aus.

Code Auswählen Erweitern

rhasspy -profile de
Starting up...
DEBUG:rhasspysupervisor:Namespace(debug=True, docker_compose='', local_mqtt_port=12183, mosquitto_path='mosquitto', profile='rofile', supervisord_conf='supervisord.conf', system_profiles=None, user_profiles=PosixPath('/home/myUser/.config/rhasspy/profiles'))
DEBUG:rhasspysupervisor:Loading profile rofile (user=/home/myUser/.config/rhasspy/profiles, system=None)
Traceback (most recent call last):
  File "/usr/lib/rhasspy/usr/local/lib/python3.7/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/lib/rhasspy/usr/local/lib/python3.7/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/usr/lib/rhasspy/rhasspy-supervisor/rhasspysupervisor/__main__.py", line 109, in <module>
    main()
  File "/usr/lib/rhasspy/rhasspy-supervisor/rhasspysupervisor/__main__.py", line 74, in main
    profile = Profile(args.profile, args.system_profiles, args.user_profiles)
  File "/usr/lib/rhasspy/rhasspy-profile/rhasspyprofile/profile.py", line 55, in __init__
    self.load_profile()
  File "/usr/lib/rhasspy/rhasspy-profile/rhasspyprofile/profile.py", line 98, in load_profile
    with open(system_profile_path, "r") as system_profile_file:
FileNotFoundError: [Errno 2] No such file or directory: '/usr/lib/rhasspy/rhasspy-profile/rhasspyprofile/profiles/rofile/profile.json'
Habe es aber wirklich nur kurz versucht und bin keinem der Hinweise nachgegangen; anderes war dringlicher...
(Von daher bitte nicht verhauen, wenn die Lösung #1 bei der nächstgelegenen Suchmaschine wäre .)

[drhirn]

Sehr dubioses Log hast du da. Zum einen steht da:

Code Auswählen Erweitern

user_profiles=PosixPath('/home/myUser/.config/rhasspy/profiles')
Zum anderen aber

Code Auswählen Erweitern

No such file or directory: '/usr/lib/rhasspy/rhasspy-profile/rhasspyprofile/profiles/rofile/profile.json'
Mal abgesehen, dass der Pfad nicht richtig ist: rofile?
Kommt da auch vor:

Code Auswählen Erweitern

Loading profile rofile (user=/home/myUser/.config/rhasspy/profiles, system=None)

Auf welcher Hardware hast du jetzt Base und Satellite installiert? Und wie sieht das Start-Script aus?

Wakeword mit porcupine war leider ein Fehlschlag. Entweder ich bin nicht in der Lage, das passende dir zu finden, in das die Dateien reingehören, oder es ist bug bei x86-Systemen, der doch nicht durch den move nach 2.5.9 gelöst wurde (=> https://community.rhasspy.org/t/show-stopper-wakeword/2182/2).

Hihi, mein Thread

Ich kann dir wirklich Docker empfehlen für solche Tests. Ist ganz einfach installiert. Und du ersparst dir Probleme mit fehlenden Abhängigkeiten.

[Beta-User]

Also: Das war der Versuch auf meinem x86_64-Debian 10.irgendwas (aktuell)-System, auf dem FHEM läuft (headless). Für x86 gibt es leider keinen docker-Container, sonst hätte ich das damit versucht (schon alleine, um es ggf. wieder sauber deinstallieren zu können).

Wie gesagt: ich habe mich mit dem log "0" auseinandergesetzt, das war ein schneller Versuch - mit genau diesem Befehl war es kein Problem auf meinem anderen Server (fast identisches Umfeld/HW). Und das "rofile" kommt da wirklich, hab's eben nochmal getestet. Ergo scheint man ggf. die globalen und user-spezifischen Start-Parameter setzen zu müssen - in der hier bereits geposteten systemd-file (die hier nicht relevant war), ist das bisher auch nicht gesetzt, nur eine Art home-Pfad.


Ansonsten läuft die Base jetzt eben auf diesem anderen Server (da hat es problemlos mit genau diesem Startaufruf geklappt), als (einziger) Satellit ist ein lineage-Android (mit der App) im Einsatz.


Snowboy habe ich vorhin auch mal getestet, dafür gäbe es sogar eine lokal auf dem Androiden laufende Test-App: https://github.com/Kitt-AI/snowboy/raw/master/resources/alexa/SnowboyAlexaDemo.apk.
Die hat funktioniert, allerdings auch nicht so effektiv, wie ich mir das gewünscht hätte (man muss sehr laut sprechen).
Dazu kommt, dass  es auch ziemlich auf den Akku ging, als ich die andere mal längere Zeit auf "wakeword active" gesetzt hatte - und eine Verbindung zum Server wollte mir per UDP auch nicht gelingen => Versuch bzgl. WWE (vorerst) beendet!

Das mit dem Shortcut-Widget-feature der App ist für mich eine gelungene/ausreichende Lösung;
ideal wäre, wenn jemand in der Lage wäre, die Demo-App (Quellcode ist verfügbar) mit der "normalen" App "kreuzen" könnte und man das ganze dann lokal verwenden könnte. ("snowboy solo" wird auf einem Pi mit ca. 10% load angegeben, das sollte mit einem halbwegs modernen Handy Akku-mäßig "erträglich" sein, wenn man es einfach (widget?) ein- und ausschalten könnte...) Ist aber weit jenseits von dem, was ich mir grade zutrauen würde...

[drhirn]

Also: Das war der Versuch auf meinem x86_64-Debian 10.irgendwas (aktuell)-System, auf dem FHEM läuft (headless). Für x86 gibt es leider keinen docker-Container, sonst hätte ich das damit versucht (schon alleine, um es ggf. wieder sauber deinstallieren zu können).

?
Meine Base läuft auf einer Proxmox-VM mit Docker.
https://hub.docker.com/layers/rhasspy/rhasspy/2.5.9/images/sha256-e1cfc5306428cbf58faef24fcdefb14454ddc13d342b2db411f66b6f4344ccd2?context=explore

Code Auswählen Erweitern


Operating System: Debian GNU/Linux 10 (buster)
Kernel: Linux 4.19.0-14-amd64
Architecture: x86-64


[Beta-User]

?
Meine Base läuft auf einer Proxmox-VM mit Docker.
https://hub.docker.com/layers/rhasspy/rhasspy/2.5.9/images/sha256-e1cfc5306428cbf58faef24fcdefb14454ddc13d342b2db411f66b6f4344ccd2?context=explore

Na dann...

Bin mit docker ziemlicher noob. Mein bisher einziger vorangegangener Versuch damit war deconz, und der war relativ problemlos erfolgreich, aber auch aus der Not geboren, weil es "damals" noch kein debian-Paket gab - nachdem das verfügbar war und über den normalen apt-Weg mit updates versorgt wird, habe ich den docker-Container samt Basis direkt wieder runtergeworfen .
Hatte das dann mit rhasspy auf der anderen x86-Maschine (also der, auf dem FHEM nicht läuft) versucht, und zu meiner großen Überraschung festgestellt, dass da sogar docker installiert zu sein schien (kann mich nicht entsinnen, das da veranlasst zu haben). Aber da der Befehl (welcher konkret das auch immer gewesen sein mag, muss wohl der aus der rhasspy-doku gewesen sein (da war kein Bezug auf Pi-OS)) erst mal durchging und dann "nur" die Info kam, dass kein passendes Image für das OS verfügbar sei, hatte ich das eben zur Kenntnis genommen und dann mit der logalen Installation weitergemacht, die dann ja auch erfolgreich war.

Jetzt werde ich mich wohl doch wohl nochmal mit docker auf dem FHEM-Server auseinandersetzen (müssen...)! (Aber auch das eilt nicht).

Falls du also eine Kurzanleitung für DAU hast, mit der man das ganze auf der x86-(FHEM-) Maschine direkt incl. automatischem Start (muss man afaik bei docker gesondert (doppelt) aktivieren) ans Fliegen bekommt: Gerne!
Ansonsten werde ich mir das bei Gelegenheit mal in Ruhe ansehen...

[drhirn]

Ich würde mich da an die Docker-Doku halten: https://docs.docker.com/engine/install/debian/#install-using-the-repository

Docker startet dann auch automatisch.

Anschließend hier: https://docs.docker.com/engine/install/linux-postinstall/


Für docker-compose entweder apt install docker-compose oder - wenn's aktueller sein soll - hier: https://docs.docker.com/compose/install/

Damit die Container automatisch starten, gibt's Restart-Policies: https://docs.docker.com/config/containers/start-containers-automatically/

[JensS]

@Beta-User

Code Auswählen Erweitern

rhasspy --profile deoder

Code Auswählen Erweitern

rhasspy -p de
Nur ein Strich fehlt.

Gruß Jens

[Beta-User]

Danke für den Schubs!

In der systemd-file war die Kurzform, aber da brauchte es noch etwas mehr. So scheint es jetzt zu laufen:

Code Auswählen Erweitern

[Unit]
Description=Rhasspy Service
After=syslog.target network.target mosquitto.service

[Service]
Type=simple
#ExecStart=/bin/bash -o pipefail -c '{ /usr/bin/rhasspy --profile de --user-profiles /opt/rhasspy/profiles --local-mqtt-port 1884 2>&1
| cat >&2 3>&-; } 3>&1'
ExecStart=/usr/bin/rhasspy --profile de --user-profiles /opt/rhasspy/profiles --local-mqtt-port 1884
WorkingDirectory=/opt/rhasspy
User=rhasspy
Group=audio
RestartSec=1
Restart=on-failure
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=rhasspy

[Install]
WantedBy=multi-user.target

(user rhasspy muss angelegt sein, s.o.).

[JensS]

Gefällt mir - getrennt vom User.

/opt/rhasspy/profiles

müsste dann zuvor per Hand angelegt werden?

[Beta-User]

Hatte nur /opt/rhasspy angelegt - also eine Art "home" für rhasspy. Die Unterverzeichnisse werden dann - soweit ich das bisher beurteilen kann - automatisch angelegt.

[Beta-User]

...erst mal zu früh gefreut; die Zusatzdienste kommen nicht hoch:

Code Auswählen Erweitern

sudo systemctl status rhasspy
[sudo] Passwort für joerg: 
● rhasspy.service - Rhasspy Service
   Loaded: loaded (/etc/systemd/system/rhasspy.service; enabled; vendor preset: enabled)
   Active: active (running) since Sun 2021-03-28 13:21:50 CEST; 23s ago
Main PID: 1058 (rhasspy)
    Tasks: 5 (limit: 4011)
   Memory: 85.8M
   CGroup: /system.slice/rhasspy.service
           ├─1058 /bin/bash /usr/bin/rhasspy --profile de --user-profiles /opt/rhasspy/profiles --local-mqtt-port 1884
           ├─4893 python3 -m rhasspyserver_hermes --profile de --user-profiles /opt/rhasspy/profiles --web-dir /usr/lib/rhasspy/rhasspy-server-hermes/web --local-mqtt-port 1884
           └─4894 /usr/bin/python2 /usr/bin/supervisord --configuration /opt/rhasspy/profiles/de/supervisord.conf --logfile /opt/rhasspy/profiles/de/supervisord.log --pidfile /opt/rhasspy/pro

Mär 28 13:22:10 hpthin2 rhasspy[1058]: 2021-03-28 13:22:10,557 INFO spawnerr: unknown error making dispatchers for 'speech_to_text': ENXIO
Mär 28 13:22:10 hpthin2 rhasspy[1058]: 2021-03-28 13:22:10,560 INFO spawnerr: unknown error making dispatchers for 'text_to_speech': ENXIO
Mär 28 13:22:13 hpthin2 rhasspy[1058]: 2021-03-28 13:22:13,572 INFO spawnerr: unknown error making dispatchers for 'intent_recognition': ENXIO
Mär 28 13:22:13 hpthin2 rhasspy[1058]: 2021-03-28 13:22:13,574 INFO gave up: intent_recognition entered FATAL state, too many start retries too quickly
Mär 28 13:22:13 hpthin2 rhasspy[1058]: 2021-03-28 13:22:13,576 INFO spawnerr: unknown error making dispatchers for 'dialogue': ENXIO
Mär 28 13:22:13 hpthin2 rhasspy[1058]: 2021-03-28 13:22:13,576 INFO gave up: dialogue entered FATAL state, too many start retries too quickly
Mär 28 13:22:13 hpthin2 rhasspy[1058]: 2021-03-28 13:22:13,590 INFO spawnerr: unknown error making dispatchers for 'speech_to_text': ENXIO
Mär 28 13:22:13 hpthin2 rhasspy[1058]: 2021-03-28 13:22:13,591 INFO gave up: speech_to_text entered FATAL state, too many start retries too quickly
Mär 28 13:22:13 hpthin2 rhasspy[1058]: 2021-03-28 13:22:13,593 INFO spawnerr: unknown error making dispatchers for 'text_to_speech': ENXIO
Mär 28 13:22:13 hpthin2 rhasspy[1058]: 2021-03-28 13:22:13,594 INFO gave up: text_to_speech entered FATAL state, too many start retries too quickly


Werde das zu gegebener Zeit wieder aufgreifen...

[JensS]

--local-mqtt-port 1884 bezieht sich auf den "internen" MQTT von Rhasspy. Hast du bereits einen Mosquitto auf dem Port?
Wie sieht es als root aus, wenn man Rhasspy mit den Argumenten auf der Konsole startet?

p.s.
RestartSec=1 würde ich zu Sicherheit auf 30 stellen.
WorkingDirectory=/opt/rhasspy - wirklich? Kann das auf /usr/bin oder lieber ganz weg?

[Beta-User]

Hm, also jetzt scheint es zu laufen. Das Problem schien zu sein, dass Python/supervisord keine Berechtigung für bestimmte Verzeichnisse (für logausgaben etc) zu haben schien:

Code Auswählen Erweitern

[Unit]
Description=Rhasspy Service
After=syslog.target network.target mosquitto.service

[Service]
Type=simple
# for command, see https://github.com/rhasspy/rhasspy/issues/42#issuecomment-711472505
ExecStart=/bin/bash -c 'rhasspy -p de --user-profiles /opt/rhasspy/profiles 2>&1 | cat'
WorkingDirectory=/opt/rhasspy
User=rhasspy
Group=audio
RestartSec=10
Restart=on-failure
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=rhasspy

[Install]
WantedBy=multi-user.target

Kann nicht sagen, ob das jetzt schon optimal ist, aber es scheint erst mal zu funktionieren.

[Beta-User]

Mal ein update zum Thema:

Der service läuft, die Rechte auf /opt/rhasspy liegen auf rhasspy:rhasspy mit 744.

Habe jetzt mal hin und wieder mit top geschaut, was das so an load verursacht => meistens "nichts". Aber es gab auch Fälle, in denen es um die 100% load waren?!? Ursache war vermutlich eine falsche Einstellung an der Android-App (Silence Detection sollte m.E. aktiviert sein), aber sicher bin ich mir da nicht.

Ansonsten habe ich es nochmal versucht, die Hotword-Aktivierung mit snowboy zum Laufen zu bringen. Bis dato ohne Erfolg. Habe zwei Modelle (umdl) ins snowboy-dir gelegt, Rechte passen, nach dem "refresh" sehe ich beide dann sogar doppelt? Habe daher auch mal "subex" aktiviert, aber selbes Ergebnis: irgendwas passt nicht.

Wäre daher dankbar, wenn jemand zeigen könnte, welche Einstellungen an beiden Enden zum Erfolg führen. Das ist der aktuelle Stand der Dinge:
App: Wake word - Schieber ist aktiviert, Host steht auf dem FHEM-Server, Port 12199 (Zum Testen dann "Start wake word")
Das Handy lässt sich mit Namen (vom FHEM-Server aus) pingen, in Rhasspy ist dann unter UDP Audio (Input) angegeben: mobile1:12199:mobile1
Kann eigentlich nichts großes sein...

[laberlaib]

Ich häng mich hier mal mit rein.

Snowboy hatte ich genutzt um zwei Wakewords zu konfigurieren. Dazu muss (soll?) man auch die umdls in einen Unterordner des Profils kopieren und dann erscheinen die doppelt: Einmal im "generischen" Verzeichnis(usr/lib/rhasspy oder so) und eben einmal die aus dem Profilverzeichnis.
Beste Leistung erzielte ich mit "Alexa" was man aber wohl noch von deren Githubaccount runterladen muss. Also da wo es auch die PoC-App gibt.
https://github.com/Kitt-AI/snowboy#pretrained-universal-models
da stehen auch die Einstellungen.
Snowboy war mittel, Jarvis immer nur false-positive.

Porcupine war auch gut, wenn man mal raus hatte, wie man das aussprechen muss. Also eigentlich nix, wenn man noch andere mögliche Probleme hat.

Zum debuggen starte ich Rhasspy immer von Hand und nicht als Service/im Hintergrund. Dann sieht man eigentlich ganz gut, was passiert. dann sollte man eigentlich auch sehen, ob es einen UDP-Flow hin gibt (ich hab das noch nie genutzt und kanns auch gerade nicht weiter testen).

Last: Es gibt bei mir Fälle, wo Rhasspy hängen bleibt und 102% Systemlast der VM zieht. Dann fängt mein Server an zu brummen. Ich starte dann im Zweifel die VM neu, was natürlich doof ist, wenn das Ding parallel zu FHEM läuft.

[Beta-User]

Hmm, "alexa" habe ich jetzt auch mal runtergeladen und 0.6/true eingestellt, da tut sich nichts...
(Aussprache ist klar, das ist auch in die "Demo-App" einkompiliert). Aber immerhin scheinen meine sonstigen Angaben zu passen?

Den service als service neu zu starten, hat in den fragelichen Fällen ganz gut geklappt, die Frage wäre dann eher, wie man den Zustand erkennen und das automatisieren kann...

Was das mit dem debuggen angeht, will ich   den FHEM-Server eigentlich "sauberhalten"; dann muss ich mir dazu ggf. dann doch nochmal das Zweitsystem hernehmen (=> kommt wieder auf die low prio-Liste).

[JensS]

Ansonsten habe ich es nochmal versucht, die Hotword-Aktivierung mit snowboy zum Laufen zu bringen.

Bei mir funktioniert es. Wie sieht deine profile.json aus?

Gruß Jens

p.s. https://forum.fhem.de/index.php/topic,113180.msg1132773.html#msg1132773 ff.

[drhirn]

Kann mir jemand von euch die APK zur Verfügung stellen? Dann probiere ich das auch mal aus.

[Beta-User]

Gibt's hier: https://github.com/razzo04/rhasspy-mobile-app/releases

(Profil liefere ich bei Gelegenheit nach).

[drhirn]

Ups, das habe ich übersehen.

Danke!

[drhirn]

Gut, läuft. Wie das mit dem Wakeword aber gehen soll, ist mir nicht ganz klar.

Funktioniert auch (mit Porcupine).

Wie kann ich helfen?

[Beta-User]

Funktioniert auch (mit Porcupine).

Wie kann ich helfen?

Vielleicht für den Anfang mit dem betreffenden Auszug aus dem profile.json für den Porcupine-Teil und den "richtigen" Angaben zu UDP...?

Wäre daher dankbar, wenn jemand zeigen könnte, welche Einstellungen an beiden Enden zum Erfolg führen. Das ist der aktuelle Stand der Dinge:
App: Wake word - Schieber ist aktiviert, Host steht auf dem FHEM-Server, Port 12199 (Zum Testen dann "Start wake word")
Das Handy lässt sich mit Namen (vom FHEM-Server aus) pingen, in Rhasspy ist dann unter UDP Audio (Input) angegeben: mobile1:12199:mobile1
Kann eigentlich nichts großes sein...

Ansonsten freut es mich, dass das Problem eher hier vor dem Bildschirm sitzt denn ein generelles ist...

[drhirn]

Die Config meiner Docker-Base:

Code Auswählen Erweitern


{
    "dialogue": {
        "satellite_site_ids": "wohnzimmer,küche,bad,mobile-app5",
        "system": "rhasspy"
    },
    "intent": {
        "satellite_site_ids": "wohnzimmer,küche,bad,mobile-app5",
        "system": "fsticuffs"
    },
    "microphone": {
        "pyaudio": {
            "udp_audio_port": "12202"
        }
    },
    "mqtt": {
        "enabled": ""
    },
    "sounds": {
        "error": "${RHASSPY_PROFILE_DIR}/error.wav",
        "recorded": "${RHASSPY_PROFILE_DIR}/end_of_input.wav",
        "wake": "${RHASSPY_PROFILE_DIR}/start_of_input.wav"
    },
    "speech_to_text": {
        "satellite_site_ids": "wohnzimmer,küche,bad,mobile-app5",
        "system": "kaldi"
    },
    "text_to_speech": {
        "satellite_site_ids": "wohnzimmer,küche,bad,mobile-app5",
        "system": "nanotts"
    },
    "wake": {
        "porcupine": {
            "udp_audio": "172.19.0.3:12202:mobile-app5"
        },
        "raven": {
            "keywords": {
                "default": {
                    "enabled": true
                }
            },
            "udp_audio": "12202"
        },
        "satellite_site_ids": "wohnzimmer,küche,bad,mobile-app5",
        "system": "porcupine"
    }
}


172.19.0.3 ist die Docker-IP des Containers. Bei dir muss es halt die IP des Servers sein, auf dem Rhasspy läuft.

Und im Anhang zwei Screenshots von der Konfiguration der App. 10.168.1.1 ist die IP meines Docker-Hosts. Muss bei dir ebenfalls die IP des Servers sein.

[drhirn]

in Rhasspy ist dann unter UDP Audio (Input) angegeben: mobile1:12199:mobile1

Ah. Seh ich erst jetzt, weil ich erst jetzt weiß, wie's funktioniert. Das erste mobile1 in dem Fall durch die Server-IP ersetzen. Das sollte es gewesen sein.

[Beta-User]

...dann werde ich es also mal mit "localhost" versuchen und pyaudio aktivieren...
Rückmeldung folgt...

[drhirn]

Moment. Das hab ich übersehen. "microphone" dürfte ein Überbleibsel in der Config sein. Das habe ich nicht aktiviert. Genau wie auch "Raven". Das kannst ignorieren. Sorry.

[JensS]

0.0.0.0:12199:mobile1 und Satellite siteIds: mobile1 sollte gehen, wenn im Handy die Siteid mobile1 und Wake word auf UDP <RhasspyBasis>:12199 eingetragen ist.

[Beta-User]

OK, nun hatte ich auch erste "Treffer" mit porcupine (ohne Mikrophon-Aktivierung) und 0.0.0.0...

Was noch fehlt, ist eine haptische oder akkustische Rückmeldung, dass das hotword erkannt wurde, muss da mal noch in Ruhe testen, wann da überhaupt was geht. Das ganze fühlt sich irgendwie im Moment noch nicht "rund" an.

"localhost" wollte jedenfalls (bei einem kurzen Test) nicht, und im Moment ist mir noch unklar, wo der Vor- oder Nachteil von 0.0.0.0 zur echten IP liegt. Tendenziell wäre meine Grundhaltung "enger ist besser", aber bei UDP ist das (ganz allgemein) eh so eine Sache, wenn ich das soweit richtig verstanden habe.

Na ja, wie dem auch sei, der [WIP]-Status ist demnächst überholt  .
Herzliches Danke!

Abschließende Zusammenfassung folgt dann bei Gelegenheit.

[drhirn]

Bei mir bimmelt die App schon wenn das Hotword erkannt wurde. Und zwar mit den Sounds, die in Rhasspy eingestellt sind.

[JensS]

0.0.0.0 bedient alle Interfaces. Kann ja sein, dass dein Rhasspy mehrere Netzwerkinterfaces hat.
Dann passt die Namensauflösung eventuell nicht zwingend.
"nslookup <RhasspyName>" bzw. "nslookup <RhasspyName> 127.0.0.1" sollte Aufschluss geben.
"netstat -p | grep 12199"  ist auch ganz nützlich.

[Beta-User]

Bei mir bimmelt die App schon wenn das Hotword erkannt wurde. Und zwar mit den Sounds, die in Rhasspy eingestellt sind.

Hmm, also...
Das hier klappt nicht:

Code Auswählen Erweitern

set rhasspy play siteId="mobile1" path="/opt/rhasspy/profiles/de/sounds/start_of_input.wav"
Die File liegt da, Rechte sind rhasspy:rhasspy, Quelle ist https://github.com/Psychokiller1888/MyChef/tree/master/assistants/assistant_en/custom_dialogue/sound. Spielt man das von der Seite aus runtergeladen ab, plingt es auch.
Na ja, ein andermal...

[drhirn]

Auch das geht bei mir!?

[Gisbert]

Hallo Jörg,

ich versuche mich an RHASSPY (refers to this FHEM-module or the FHEM-device) und Rhasspy (refers to the Rhasspy Voice Assistant).
Kann ich hier Fragen stellen - oder ist es hier eher ungünstig?

Die Installation von rhasspy auf Debain 11 hab ich hinbekommen.
Wenn rhasspy läuft:

Code Auswählen Erweitern

PATH="$PATH:/usr/sbin" rhasspy --profile en
rhasspy --profile en
dann komme ich auf die Hompage - und hab gleich den Server runtergefahren, das ist also nicht der Schalter zum Verlassen der Seite.

Die Android-App habe ich runtergeladen und installiert; sie startet, mehr hab ich nicht versucht.

Einen Ordner /opt/rhasspy habe ich angelegt. Einen User rhasspy kann ich anlegen - wie ist es mit dem Passwort dieses Users?
Wie startest du dann rhasspy?

Dann noch eine Besonderheit bei mir: ich nutze (immer noch) MQTT_DEVICE, d.h. mosquitto in Fhem - ja ich weiß, Asche auf mein Haupt, und das Loch in dem ich versinke, ist schon ausgehoben, aber kann ich MQTT für Fhem (und für rhasspy) behalten, bis der Winter richtig da ist, und ich genug Zeit für den Umstieg auf MQTT2 hab?
Was muss ich hier beachten?

In Fhem habe ich die folgenden Devices angelegt:

Code Auswählen Erweitern

defmod rhasspyMQTT2 MQTT2_CLIENT rhasspy:12183
attr rhasspyMQTT2 clientOrder RHASSPY MQTT_GENERIC_BRIDGE MQTT2_DEVICE
attr rhasspyMQTT2 subscriptions hermes/intent/+ hermes/dialogueManager/sessionStarted hermes/dialogueManager/sessionEnded

defmod Rhasspy RHASSPY

Immerhin den Anfang hab ich geschafft, ermutigt durch deinen Vortrag und die Dokumentation bei Github.
Gibt es noch eine (versteckte) Anleitung, die ich noch nicht gefunden habe?

Viele Grüße Gisbert

[Beta-User]

Kann ich hier Fragen stellen - oder ist es hier eher ungünstig?

...teilweise...

Hierher gehören m.E. "eigentlich" nur die Fragen, die sich mit der "mobile app" beschäftigen.

In https://forum.fhem.de/index.php/topic,119679.msg1143870.html#msg1143870 ist dann noch meine Antwort auf diese Fragen zu finden:

Einen Ordner /opt/rhasspy habe ich angelegt. Einen User rhasspy kann ich anlegen - wie ist es mit dem Passwort dieses Users?
Wie startest du dann rhasspy?

Da Rhasspy dann als Dienst (wie fhem) läuft, braucht der User rhasspy kein Passwort (und es ist m.E. auch nicht zu empfehlen, eines zu setzen!).

Hoffe, es ist ok für dich, einfach für den Rest einen neuen Thread aufzumachen?
Du kannst gerne die hier nicht beantworteten restlichen Fragen einfach dann da reinkopieren und von hier aus dahin verlinken, und kannst für andere gerne dann auch meine/deine systemd-unit-file dort posten, wenn der autostart von rhasspy damit klappt .

Vielleicht etwas mehr zum Hintergrund:
Es sind grundsätzlich folgende Dinge, die man braucht und die zusammenspielen müssen:
a) einen laufenden rhasspy-Dienst (incl. autostart);
b) "irgendwas", um "Geräusch" auszutauschen (darum - bzw. die spezielle Lösung mit der App - geht es eigentlich in diesem Thread);
c) auf FHEM-Seite
-- zum einen (c1)) ein Interface (das geht nur noch (!) mit MQTT2_(CLIENT|SERVER) (SERVER: für diesen speziellen Anwendungsfall not recommended! Da Rhasspy sowieso einen eigenen Server mitbringt, ist die übrige MQTT-Welt an der Stelle völlig irrelevant.))
-- zum anderen (c2)) RHASSPY (und (je nachdem, was schon da ist) die weitere Konfiguration an den zu steuernden FHEM-Geräten (c3))).

Eigentlich wäre es sinnvoll, für jeden der 3-5 Teilbereiche je einen eigenen Thread zu haben (bzw. ggf. für weitere "Geräusch"-Bereiche ggf. was gesondertes, wobei das und a) eigentlich keine FHEM-Themen sind)...

Ich unterstelle mal, dass noch mehr Leute Interesse an dem "wie fange ich an" haben, ohne sich durch "gefühlt 1000 Seiten Entwicklungs-Thread" wühlen zu wollen, möchte ich die Gelegenheit gerne nutzen, die (nach meinem Eindruck) zwischenzeitlich sehr wenigen Schritte mal wieder auf dem aktuellen Stand mit einem "Testwilligen" durchzuspielen .

[drhirn]

Ich unterstelle mal, dass noch mehr Leute Interesse an dem "wie fange ich an" haben, ohne sich durch "gefühlt 1000 Seiten Entwicklungs-Thread" wühlen zu wollen, möchte ich die Gelegenheit gerne nutzen, die (nach meinem Eindruck) zwischenzeitlich sehr wenigen Schritte mal wieder auf dem aktuellen Stand mit einem "Testwilligen" durchzuspielen .

Da kann ich gerne mitmachen. In Ö ist ab Montag wieder Lockdown. Ich hab Zeit

[Gisbert]

Ich unterstelle mal, dass noch mehr Leute Interesse an dem "wie fange ich an" haben, ohne sich durch "gefühlt 1000 Seiten Entwicklungs-Thread" wühlen zu wollen, möchte ich die Gelegenheit gerne nutzen, die (nach meinem Eindruck) zwischenzeitlich sehr wenigen Schritte mal wieder auf dem aktuellen Stand mit einem "Testwilligen" durchzuspielen .

Da kann ich gerne mitmachen. In Ö ist ab Montag wieder Lockdown. Ich hab Zeit

Danke euch beiden für das Angebot - einen Testwilligen habt ihr schon mal. Eine rasche Antwort kann ich jeweils von Samstag bis einschließlich Montag geben, unter der Woche (Di - Fr) meist nur abends.
Ich versuche derweil mit den Informationen, die ich finde bzw. ihr mir gebt, schon mal weiterzumachen.

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

Viele Grüße Gisbert

[drhirn]

Das ist ein Thema für Rhasspy. Wir haben uns entschieden, dessen Installation nicht zu dokumentieren. Weil das eh hier passiert. Sonst laufen die zwei Dokus nur auseinander.

[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?