Welche Alternative für Amazon Alexa für die Zukunft

[Jochen1977]

Hallo,

in meiner aktuellen FHEM Installation nutze ich die Alexa Integration für die Sprachsteuerung. Das läuft gut und auch mit der Cloudlösung über ein amerikanisches Unternehmen kann ich leben. Seit einigen Wochen spielt Amazon aber nun auf den Bildschirmgeräten Werbung mit ein. Das ich nicht schön aber wenigstens verdeckte die Werbung nicht die neuesten Rückmeldungen auf die gesprochenen Aktionen. Sprich die Schalter werden nach dem Umschalten auf dem Display angezeigt. Jetzt habe ich allerdings Nachrichten gelesen dass in den USA auf den nur Audio Geräten (Echo, Echo Dot, Echo Studio) nach Anfragen auch Audiowerbung abgespielt wird. Es ist also zu befürchten dass dies auch hierzulande kommen wird. Dadurch geht der WAF von 60% auf unter 10% und auch ich möchte das nicht.

Nun stellt sich also die Frage wie es weitergeht. Eine Sprachschnittstelle ist doch recht nützlich auch wenn das Handy immer in der Nähe ist. Nachdem was ich bisher gelesen habe ist Rhasspy wohl der aussichtsreiste Kandidat da ich nicht wieder Hardware von einem Hersteller kaufen möchte der dann nach einer gewissen Zeit ungefragt Werbeeinblendungen bringt.


Dass dies Aufwand in Form von Installation bringt und auch Geld für Geräte kostet ist mir klar. Was ich aber überhaupt nicht abschätzen kann wie die Erkennung von Sprachbefehlen über Rhasspy im Vergleich zu Amazon ist. Funktioniert das ähnlich gut oder deutlich schlechter? Es wäre prima wenn jemand mir hier eine Vergleichserfahrung hätte.

Danke und Gruß Jochen

[Beta-User]

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

[Jochen1977]

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

[Thyraz]

Bei uns ist der Umstieg von Alexa auf andere Geräte immer daran gescheitert, dass der Rest der Familie keine Sprach-Syntax zum bedienen erlernen wollte.
Mit der Einstiegshürde ging die Akzeptanz innerhalb von Minuten auf 0. 😉

Die zweite Hürde ist, dass bei den meisten Haushalten mit Alexa Musiksteuerung eine der Top-Einsatzwecke ist.

Insofern haben Alternativen (an denen ich zu Snips Zeiten auch mal selbst mitgebastelt habe) immer nur als Zweitlösung überlebt die nur durch mich genutzt wurden.

Du solltest dich also vor diesem "Abenteuer" fragen ob eine Lösung ohne LLM in deiner Familie eine Chance haben wird.
Bei mir war das nach mehreren fehlgeschlagener Versuche irgendwann definitiv mit nein zu beantworten.
Auch das hat Nachteile (du hast wieder einen der großen Player in der Pipeline, auch wenn es statt Amazon diesmal OpenAI o.Ä. sein mag).
Durch Nutzung der kostenpflichtigen APIs kann man immerhin umgehen direkt im Trainingsmaterial zu landen und für etwas Smart-Home sind die monatlichen Kosten sehr gering.
Alternativ kann man das Problem mit Geld bewerfen und sich für 3k€+ einen Server mit einer potenten GPU kaufen, welche auch etwas bessere Sprachmodelle lokal ausführen kann.

Auch ist die Latenz ein Problem solange STT, LLM und TTS in der Cloud rennen (und solange du lokal nichts gescheites schnell laufen lassen kannst, wirst du das wollen wenn du Dinge wie Musik auf Alexa-Niveau steuern willst.)
Wir reden hier von min. 6-7 Sekunden bis du eine Antwort bekommst. Und da sind wir schon bei aktuellem Stand der Technik mit LLM + TTS streaming sobald das LLM die ersten Zeichen ausspuckt anstatt zu warten bis die Antwort komplett generiert ist.
Auch hier hilft wieder die Geld-Lösung in Form eines leistungsfähigen lokalen Servers, was eine schnellere Reaktionszeit der gesamten Kette ermöglicht.

Ob so etwas in FHEM möglich ist, oder ob man das extern per LLM + Tools anflanschen müsste weiss ich nicht.

Nur mal so als Ausblick was aktuell möglich ist (mit entsprechenden Aufwänden).

Wir nutzen das mittlerweile erfolgreich statt Alexa.
Basierend auf OpenAI Chat-GPT 4.1 mini mit vielen Tool Calls für diverse Dinge:
- Struktur mit Tags über verfügbar Geräte bereitstellen
- Zugriff auf History der Geräte aus der DB über Zeitraum und gewünschter Aggregation
- Taschenrechner für das LLM, da es einfach nicht rechnen kann 😛
- Zugriff auf den Shared Kalender über Suchbegriffe oder Listing innerhalb Zeitraum
- Internet Suche
- Musiksuche und Musiksteuerung über Music Assistant (eine Open Source Lösung um diverse Music-Provider und Ausgabegeräte zu verknüpfen, welche aus dem Home Assistant Dunstkreis entstanden ist und über eine API gut steuerbar ist)
- Wetterbericht
- Diverse andere kleine Tools.

Gute Tools sind bei einem LLM genug um den Unterschied zu machen.
Die Verknüpfung bekommt das Modell dann selbst hin.

Zum Beispiel die Frage wann das letzte mal in Zimmer X gelüftet wurde (typisch deutsche Frage).
Dann sucht es eben aus den Geräten alle Fenster die für das Zimmer getagged sind und sucht über die jeweilige History wann die letzte Öffnungszeit war.

Oder bei Musiksuche: Frage nach den Top 10 meistverkauften Rock-Songs aus dem Jahr 1984 (und wenn es das nicht in den Trainingsdaten hat, nutzt es eben das Internet-Search-Tool) und sage es soll sie im Wohnzimmer abspielen, was dank der Suche + Kontrolle über Music Assistant möglich ist.
Aber das Kommando dauert bis zum Start der Wiedergabe durch die verketteten Tool-Calls dann halt auch eher 15 statt 6 Sekunden.

Das ist die erste Lösung, nach welcher meine Familie trotz kleiner Nachteile von Alexa abgeschworen hat.
Ich glaube der Knackpunkt war tatsächlich als die Musiksuche und -steuerung besser war als bei Alexa.
Einer Domäne bei der bisher einfach jede OpenSource Konkurrenz extrem schlecht aussah.

Dieser Post will dich also an sich vor einem warnen:
Wenn du das familientauglich angehen willst (Single-Nerds haben es da leichter 😉), dann solltest du mit entsprechend verfügbarer Freizeit rangehen. 😄

[Beta-User]

an denen ich zu Snips Zeiten auch mal selbst mitgebastelt habe

Vorab mal: Danke für die Vorarbeiten! Auch wenn das heutige RHASSPY-Modul deutlich umfangreicher ist als der darin weiter werkelnde SNIPS-Kern: Ohne diese weiter enthaltende solide Basis gäbe es das heute nicht in der Form!!!

Danke auch für den informativen Beitrag hier. Das Stichwort "Musiksteuerung" war auch für mich der letzte Schubs, einen deutlich potenteren Server einzusetzen als zuvor. Schon die Aufgabe, Rhasspy mit den (statistisch) wichtigsten Schlagworten aus dem lokalen MPD als Musikdatenbank zu trainieren, war für den vorherigen 2-Kern Thin Client eine größere Herausforderung...

Mein persönlicher Anspruch ist "eigentlich", alles möglichst lokal zu halten und auf die Preisgabe meiner Daten(strukturen) möglichst zu verzichten. Von daher sind die lokale Sprachsteuerung aller Dinge rund ums Haus und der Rest der Welt sowieso getrennt, und es macht mir nichts aus, für dieses Ziel auch Komforteinbußen in Kauf zu nehmen, hier eben in der Form, das Handy aus der Tasche holen zu müssen oder vielleicht künftig einen "lokalen Androiden" (zu denen vielleicht auch die neuen Sonoff-Displays gehören) dezidiert anzusprechen.
Generell sollten sowieso die meisten Automatisierungsaufgaben rund um's Haus so ablaufen, dass der Nutzer gar nicht erst den Bedarf hat einzugreifen, von daher sind schon die Anwendungsfälle eher seltener, so dass ich auch kein große Neigung habe, dafür Geld auszugeben...
Aber schon bei der Etappe STT ist leider festzustellen, dass das letztlich nur praktikabel ist, wenn man externe Kapazitäten in Anspruch nimmt .

Und Wakeword ist nochmal ein Punkt, der zwar lokal durchaus gut klappt, wenn man denn "gute" Hardware bereithält. War mir auch irgendwann für meine eher seltenen sprachlichen Eingriffe einfach zu aufwendig...
(OT: Neulich habe ich einen "Kellerkisten" PI3A+ mit ReSpeaker2-Board mal wieder in Betrieb genommen auf aktueller Trixie-Basis. War "nur" eine "overlay"-Anweisung, und schon lief der Audio-Teil, cool!)

Und Wakeword-Erkennung auf dem Handy? Da gibt es Apps, aber ich habe vor längerem das Experimentieren damit beendet, das saugte einfach zu sehr am Akku...
 

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.

Zurück dazu:

In deiner Situation würde ich jedenfalls erst mal nicht Geld in die Hand nehmen, um (z.B.) Rhasspy (2.5) auszuprobieren. Falls du experimentierfreudig bist und etwas Zeit übrig hast, kann Rhasspy vielleicht eine Option sein, um eigene Erfahrungen mit dem Thema lokale Sprachsteuerung zu machen, zumal dein Server potent genug ist, das zumindest für Basisanwendungen nebenher zu machen. 
Der modulare Aufbau des "Rhasspyversums" läßt es zu, dass man praktisch bei jeder Etappe (die auf den Projektseiten nach wie vor sehr gut dokumentiert sind!) andere/eigene Lösungen einsetzt. So kann z.B. für den TTS-Teil auch ein lokaler MaryTTS-kompatibler Serverdienst benutzt werden.

Da experimentiere ich grade (eher nebenher, zugegebenermaßen) mit "piper", mit dem zumindest nach dem ersten Eindruck "Thorsten" nochmal deutlich besser klingt als mit "mimic3". Allerding hat die aktuelle Version 1.3 zwar einen (http-) Serverdienst, der die Audio-Ausgabe sehr schnell liefert (RTF auf meinem G3-elitedesk-i7 gefühlt 0.1), der ist aber wieder nicht mit MaryTTS kompatibel, so dass ich mir dazu einen Würgaround überlegen muss oder evtl. auf eine Vorversion gehen, was auch doof ist bei der an dieser Stelle aktiven Weiterentwicklung des ursprünglichen Rhasspy-Masterminds...

[Beta-User]

Nachtrag noch zum Thema Ausprobieren:

RHASSPY kennt einen Test-Modus, Anleitung siehe hier: https://forum.fhem.de/index.php?msg=1215415

Damit kann man ganz ohne effektiv zu schalten mal austesten, was Rhasspy/RHASSPY in der eigenen FHEM-Umgebung so "kann" - und das, ohne extra Hardware zu beschaffen, Apps zu installieren oä.. Die Installation von Rhasspy mit docker ist easy, und die Aktivierung von RHASSPY auf der FHEM-Seite sollte jedenfalls in den Fällen auch schnell gemacht sein, in denen man per devspec (ungetestet z.B. mit "room=alexa" oder "genericDeviceType=.+" oä.) Devices abgrenzen kann und für seine Devices schon "sprechende Namen" (und den gDT) vergeben hatte.

Details erkläre ich bei Bedarf gerne, allerdings wäre das m.E. sinnvoller in einem eigenen Thread unterzubringen; hier darf es gerne weiter auch um andere Alternativen gehen .