Zitat von: Jochen1977 am 03 Dezember 2025, 16:04:14Dass dies Aufwand in Form von Installation bringt und auch Geld für Geräte kostet ist mir klar.
Die Einrichtung ist Aufwand ja, aber man kann (!) prinzipiell auch Rhasspy einfach nur per Handy nutzen, im Prinzip "kostet" Rhasspy/RHASSPY im Moment also vor allem den Einarbeitungsaufwand.
Das ist die gute Nachricht daran.
Die schlechte: RHASSPY setzt auf Rhasspy in der Version 2.5 auf, und das wird in dieser Form nicht mehr weiterentwickelt.
Wie nun also weiter?
1. In FHEM gibt es noch "Babble" (und TEERKO). Ich habe mich damit bisher nicht intensiver auseinandergesetzt, aber die Babble-Konfiguration der im Hintergrund erforderlichen Rivescript-Dateien wirkt aufwändig, zumindest, wenn man es mit Rhasspy-sentences.ini vergleicht (bei Rhasspy läuft im Hintergrund afaik diesselbe Perl-lib, wird aber anders konfiguriert). Auch diese Module brauchen aber - soweit ich das verstanden habe - Text als Input; dazu unten mehr.
2. Zu Rhasspy und RHASSPY
a) es gibt für Rhasspy einen docker-Container, und der dürfte für sich genommen durchaus noch einige Jahre auch auf kommenden Linuxen etc. lauffähig sein. Wenn man docker kennt, ist die Installation schnell gemacht, und man kann intern auch diverse Komponenten dann einfach nachinstallieren. Easy, wenn man docker kennt und/oder schon im Einsatz hat (z.B. wegen zigbee2mqtt).
b) Das RHASSPY-Modul ist sehr modular aufgebaut; man könnte sich durchaus vorstellen, dass es möglich sein könnte, das mit überschaubarem Aufwand auf Rhasspy V3 (und das dort genutzte Wyoming-Protokoll) umzubauen. Allerdings war in Rhasspy V3 auch seit längerem recht wenig Bewegung zu erkennen...
Aber selbst wenn es ein komplett neues "ecosystem" gäbe, dürfte die Anpassung des RHASSPY-Moduls (oder einer Kopie) vergleichsweise einfach sein.
Letztlich liegt die "Stärke" des Moduls darin, der NLU-Komponente strukturierte Datensätze mit "Variablen" zur Verfügung zu stellen, und dann aus der Rückgabe (eine JSON-Struktur) wieder FHEM-Aktionen zu machen (die auch einfach nur die Generierung einer aus FHEM heraus ermittelten Antwort sein kann), und die passende Antwort dann wieder an "irgendein" Ausgabegerät zu senden - entweder als Anweisung, selbst die TTS-Komponente anzuwerfen (z.B. des Handy-OS), oder eben als play-Anweisung der von Rhasspy generierten Audio-Daten.
3. Anders betrachtet:
a) Es funktioniert derzeit der "Rhasspy-only"-way: Man nehme eine der beiden Andorid-Apps und einen Rhasspy-docker-container und konfiguriere nach Wiki.
Man erhält ein funktionales System mit mäßigen Audio-Files, zu bedienen über eine eher unschöne App mit - je nach Flexibilität der eingegebenen sentences.ini - meist halbwegs akzeptablen Erkennungsraten. Problem dabei ist eine Art "es muss irgendwas von dem sein, das ich kenne"-Logik in Rhasspy.
b) "Früher" konnte man alternativ den Rhasspy+AMAD-way beschreiten:
Da wird die STT-Komponente des Handys genutzt, was meistens gut brauchbare Texte ergibt, die dann auch von Rhasspy einer Übereinstimmungsbewertung unterzogen werden, was ggf. deutlich mehr Rückfragen und gefühlt bessere Ergebnisse und "normale" Rückmeldungen an die Nutzer erzeugt. Die Audioausgabe erfolgt dann afair als TTS-Anweisung, denkbar wäre auch eine play-Implementierung.
Problem dabei ist, dass man an offiziellen Apps dann "Tasker" benötigt. Derzeit habe ich allerdings keinen Plan, wie das funktional einzurichten sein soll, aber derzeit wäre das "eigentlich" der Weg, den ich zum Testen vorschlagen würde... (Falls du die nicht mehr offiziell zu bekommende Automagic-App installieren magst, geht es etwas einfacher).
c) "Ganz früher" gab es mal eine App namens WebViewControl, die mit etwas javascript in der Lage war, den STT-Teil zu erledigen und den erkannten Text an FHEM zu übermitteln.
FULLY/fully kann das derzeit (noch?) nicht, würde aber jedenfalls den Rückweg für TTS (und play-Anweisungen) beherrschen. Die Aufgabe wäre hier, den Teil zu ergänzen und ggf. den FULLY- und RHASSPY-Code aufzubohren. Da mir das als der aussichtsreichste Weg für die Zukunft erscheint, habe ich jüngst das FULLY-Modul als Maintainer übernommen.
Dann hätte man eventuell einen "hübschen" fullscreen-Browser (zur Anzeige z.B. von FHEMapp) und direkter "Mikro-Klick"-Funktionalität und geringem Konfigurationsaufwand als "Handy-Interface" mit vergleichbaren Ergebnissen wie dem AMAD-Weg.
Da afaik auch Babble (erst) auf dem erkannten Text aufsetzt, hoffe ich darauf, dass jemand bezüglich des javascript-Teils mit einsteigt...
Hoffe, das ist einigermaßen verständlich?
Vielen Dank für Deine ausführliche Antwort. Das meiste ist mir zumindest in den Grundzügen klar. Da ich leider nicht programmieren kann sondern nur etwas "scripten" muss die Lösung quasi ready to use sein.
Der Vorteil der Audiolösung ist die Bequemlichkeit. Immer zuerst das Handy hervorholen und entsperren möchte ich eigentlich nicht. Somit sind Hardwaremicrofone eigentlich obligatorisch. Zur Zeit habe ich 9 Amazon Geräte im Haus und der Garage verteilt. Ob es jetzt wirklich notwendig ist mein Echo dannach zu fragen wie viel Strom meine PV Anlage gerade macht oder ob ich das auch in der App nachschauen kann liegt im Auge des Betrachters. Eine andere Sache ist z.B. das Licht am Waschbecken. Wenn ich gerade Salat wasche und mehr Licht möchte wäre es ungeschickt zuerst das Handy herholen zu müssen.
Docker ist hier kein Hindernis da sowieso ein Homeserver mit div. VMs 24/7 läuft. Text als Input über div. ini Dateien wäre für mich auch ok dann habe ich selbst die Hand drauf was wann ausgeführt wird. STT vom Handy zu nutzen wäre für mich nur der halbe Weg (s.o.)
Deinem Beitrag entnehme ich dass die Erkennung von Sprache nur "halbwegs akzeptable Erkennungsraten" bringt. Hier liegt für mich die Frage. Was ist halbwegs akzeptabel? Meine Frustrationsschwelle liegt hier deutlich höher als die meiner Frau.
Gruß Jochen