VoiceButton für Fhemweb

[Beta-User]

Die Doppelung der Texte lag vielleicht an stt.interimResults=true, das habe ich jetzt entfernt.

Zumindest unter fully funktioniert das damit erwartungsgemäß .

Das Firefox Problem habe ich jetzt in Prinzip (s.u.) gefixt.
Zum Aktivieren muss in about:config media.webspeech.recognition.enable auf true gesetzt werden.

Jetzt erscheint zumindest sowohl auf dem Androiden wie unter Linux das Dialogfeld. Das unter Android hinzubiegen war was größeres, auf about:config kommt man da nur über einen Umweg, ich hab's mit dem Weg aus https://discuss.techlore.tech/t/i-found-a-way-to-enable-about-config-on-regular-firefox-for-android/14584 gemacht, chrome://geckoview/content/config.xhtml aufgerufen und dort den entsprechenden Punkt direkt aktiviert.
Es wird allerdings trotzdem nichts aufgenommen, die Berechtigung zum Zugriff auf das Mikro wird auch nicht angefragt. Vielleicht fehlt noch was anderes, was in about:config aktiviert werden muss?

- eine eindeutige Zuordnung des Clients ist kein Problem, will aber (mit dem Rest auch) abwarten, welchen Weg wir gehen wollen

Danke, ich hatte mir schon gedacht, dass der Punkt mit dem Rückweg dann einer der Folgeschritte sein soll.

- Sprachausgabe ist laut Doku moeglich, habs aber nicht getestet

fully kann das, von daher _glaube_ ich, dass es von der technischen Seite her kein Hexenwerk sein wird, "irgendeinen" Browser dazu zu bewegen, entweder eine Audio-File abzuspielen oder das am Endgerät verfügbare TTS-System anzusteuern (allgemeine Berechtigung dazu vorausgesetzt). Die Frage wäre, wie man das aus FHEM heraus testen würde?

- Dialog veraltet: ich habe gerne ein Feedback, solange die Erkennung nicht perfekt ist. Was schwebt Dir vor?

Das kann ich grade nicht so recht einordnen:

"Bisher" (AMAD-Weg) war es so, dass nach einer gewissen silence-Phase der bis dahin erkannte Text an AMADCommBridge weitergegeben wurde und das Mikrofon dann zu war. Also - übertragen auf die jetzige Fassung - dem "Audio stopped" direkt ein automatisches "submit" folgen würde. 
Während des Sprechens zu sehen, was gerade "getippt wird", ist dabei allerdings in der Tat hilfreich, und das war zumindest in meiner Erinnerung auch so - manchmal mit "rückwirkender Änderung" bereits erkannter Worte - vermutlich wegen des besser erkannten Kontextes des einzelnen Bruchstücks.
Wäre klasse, wenn wir was in die Richtung hin bekämen, alternativ würde es m.E. auch eine kürzere Wartezeit auch tun, nach der ein (optionales?) "submit" erfolgt? Insbesondere, wenn man das Mikro auch auf andere Weise als den Button aktivieren kann (Reaktion auf einen Näherungssensor, z.B.), kann der User durchaus auch etwas entfernter sein, so dass er uU. gar nicht lesen kann, was erkannt wird.

RHASSPY hat dann diesen Inhalt an Rhasspy geschickt zur Intent-Erkennung. Da kam "irgendein" Ergebnis raus zwischen "nichts passendes gefunden" bis "Es wurde der Satz 'Mach lauter' mit 100% Wahrscheinlichkeit erkannt, die Bausteinchen sind ....". Je nach Treffgenauigkeit wird dann entweder die Aktion ausgelöst, eine Rückfrage gestellt ("soll wirklich das Licht im Wohnzimmer an geschaltet werden?") oder eben zurück gemeldet, dass nichts ermittelt werden konnte (optional: mit weiterer Eingabemöglichkeit = Mikro wieder offen).

Es ist daher in der Regel kein allzu großes Problem, wenn "Müll" erkannt wird, weil darauf keine Reaktion erfolgt ist - was im Übrigen deutlich angenehmer ist wie die Audio-Dekodierung mit den Rhasspy-defaults, die immer einen zwingenden match mit irgendeinem der hinterlegten Anweisungssätze ergeben hat, mit 100% Wahrscheinlichkeit ...

Was HTTP/HTTPS angeht: Das STT/TTS-Thema direkt mit Browser-Bordmitteln lösen zu können, ohne extra irgendeine spezielle App zu benötigen, ist imo ein Aspekt, der die f18.js-Variante deutlich attraktiv macht! Selbst wenn man dann erst mal diverse Berechtigungen für den FHEM-Server freischalten muss, wenn man nur HTTP verwenden will.

[schwatter]

@rudolf

Besser, jetzt habe ich keine Doppelung mehr.

@Beta-User
Fully zickt bei mir noch. Egal ob mein JS oder von Rudolf, ich bekomme "SpeechRecognition Interface missing".
Ist ein FireHD10...mmhh. Habe in den Settings in Fully "Enable Microphone Access" an. Noch ein Tip von dir?

edit:
Mist, auf dem Handy mit Fully funktioniert es sofort

edit2:
Irgend eine Voicerecorder app funktioniert aucu aus dem Store....

edit3:
Das ist wohl ein FireOS Problem....egal

Gruß schwatter

[Beta-User]

Was schwebt Dir vor?

Vielleicht sollten wir auch bei Gelegenheit klären, wer "Dir" ist, bzw. wer welche Zielsetzung(en) hat.

Mir persönlich ging es als Minimalziel darum, einen Weg zu finden, wie man diverse Androiden möglichst einfach und möglichst ohne viele Abhängigkeiten von irgendwelchen großen Internetdienstleistern dazu nutzen kann, "typische Nutzerinteraktionen per Sprache" an und mit FHEM zu ermöglichen.

Das Gespann Rhasspy/RHASSPY war im Hinblick auf offline-Fähigkeit nahezu ideal, nur leider war (und ist) der STT-Teil im Hinblick auf Useability und effektive Ergebnisse eher bescheiden.
Der "alte" Workaround, für den STT-Teil eben doch die "normale online"-Fähikeit der Handys zu verwenden, war (mit ein paar Abstichen) ganz ok, benötigt(e) aber entweder die "Automagic"-App, die zwar noch erhältlich ist, aber nur in der vorletzten Version mit aktuellen Handys nutzbar ist, aber im mittelfristig "tot" ist, oder "Tasker", dessen Konfiguration (der aktuellen Version) (nicht nur) mich überfordert...

Wenn "wir" (also eher ihr...) den TTS/STT-Teil erfolgreich hier implementiert haben sollten, wäre mein persönliches Minimalziel eigentlich schon erreicht.
Vermutlich läßt sich das dann auch genauso mit Babble nutzen. Das war nie in meinem Fokus, mir lag die (bezogen auf den FHEM-Teil) weitgehend dezentrale Konfiguration von RHASSPY sehr viel näher.

Soweit, so gut.

Mittelfristig wird sich auch das Problem stellen, dass Rhasspy nicht mehr - jedenfalls nicht mehr in der jetzigen Systematik - weiterentwickelt werden wird. Nach meinem jetzigen Verständnis ist das "eigentlich" kein Beinbruch, denn der eigentliche Kern - die Intent-Erkennung - scheint sowieso (wie bei Babble auch) auf Rivescript zu basieren. Das "passend" zu konfigurieren (bzw. bei Änderungen der FHEM-Konfiguration auch zu aktualisieren), ist sicher etwas Aufwand, aber vermutlich (mit Unterstützung...) lösbar.

RHASSPY selbst ist gepackaged, so dass es praktisch kein Aufwand wäre, das zu klonen - und den Klon dann dieselben Attribute verwenden zu lassen, wie das bisherige Modul .

Von daher wäre die "mittelfristige Mission", RHASSPY2 (oder künftig vielleicht "RiveInterface") zu basteln, um damit eine (relativ) einfach zu konfigurierende Zwischenschicht pro FHEM-Installation (und Sprache) anbieten zu können, die - abgesehen von der STT-Seite - offline läuft.

[schwatter]

Ich persönlich, eigentlich hat mich Sprachsteuerung nie interessiert. Mein Heim ist beim Smarthome 100% Cloudfree.
Daher kam Alexa und Co nie in die engere Auswahl. Und alles andere ohne Cloud war mir zu mhhh, jedenfalls nicht
mein Ding. Aber ein bisschen mitreißen lasse ich mich hier jetzt schon.

Daher nochmal ein Update im ersten Post. Ein Mini-Jarvis. Bzw Hotworderkennung mit "Jarvis". Ohne die Wird der Text
nicht gesendet. Kurz tippen Jarvis an, kurz tippen Jarvis aus. Halten, dann Jarvis sagen + Kommando. Im Moment landet
das wie vorher gesagt auch in global als Reading STT.

Edit:
Jarvis auf dem Desktop klappt dauerhaft. Mobile noch nicht. Aber halten und sprechen auf Mobile ist ok.

Gruß schwatter