[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