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

[schwatter]

Update im ersten Post voicecontrol_jarvis.js
- Antippen und dauerhaft zuhören klappt jetzt auch bei Mobile.
- Das Hotword ist James bzw james. Muss klein.

Wer selber mal auf Mobile remote debuggen will, bzw von Chrome Desktop auf AndroidMobileChrome.
1. Im Handy unter Entwicklertools USB-Debugging an.
2. Handy per Kabel Pc
3. adb devices
4. adb forward tcp:9222 localabstract:chrome_devtools_remote
5. Chrome Desktop öffnen
6. chrome://inspect/#devices in der Adresszeile eingeben.
7. Da taucht dann euer Chromedesktop sowie das Mobiledevice auf.
8. Den richtigen Tab mit inspect aufrufen. Und zack Remoteconsole.

Gruß schwatter

[schwatter]

Moin update - voicecontrol_james.js

- Hotword und Bezeichnung auf James umgestellt
- Sprachausgabe hinzugefügt (Minimal, siehe unten)
- Auf Desktop mit Windows11 wird erst nach VoiceStefan gesucht.

Audioaufzeichnung und Sprachausgabe im Einklang ist sehr diffizil...sonst antwortet James sich selbst.
Drücken und halten klappt super. Dauerhaft lauschen funktioniert jetzt auch ganz passabel. Gerade auf Mobile
mag Chrome es nicht so gerne, lange das Mikro offen zu lassen. Aktuell kann das JS es ganz gut abfangen.
Wenn James mal nicht antwortet, dann war wieder eine Unterbrechung. Zu sehen am kleinen grünen Punkt der
oben in der Statusleiste im Handy verschwindet.

Die Sprachausgabe hatte ich erst ausgeweitet. Aber das Timing ist schwierig. Wenn ich sage "James Esszimmer Licht an" und er dann antwortet "Befehl Esszimmer Licht an gesendet" kam es auch mal zu Rückkopplungen. Das hatte ich dann abgefangen, in dem
James sich nicht mehr zuhört, aber dann haut auch schon wieder das Timingproblem dazwischen, da Google gerne das Mikro aus
hat...deshalb antwortet er bei einem Befehl einfach mit ok aber den gesprochenen Befehl sieht man zum überprüfen in der Blase.

Wer z.B eine männliche Sprachausgabe haben möchte kann dies anpassen. Hier bei mir unter Lineageos 23.2:
Einstellungen --> Bedienungshilfen --> Sprachausgabe --> Rechts Zahnrad neben Bevorzugtes Modul --> Sprache installieren --> Deutsch klicken --> 4 Stimmen zur Auswahl. Ich habe Stimme III


Gruß schwatter

[schwatter]

Mh,

ich habe es gerade erst bemerkt. Das ständige restarten der Spracherkennung bei AlwaysOn löst einen Ton aus.
Es ist mir nicht aufgefallen, da Systemtöne auf minimal waren...Daher werde ich es wohl wieder entfernen müssen.

Gruß schwatter

[Beta-User]

Hammerhart!

Kurze Wasserstandsmeldung zu den jarvis/james-js: Sieht auch (optisch und funktional) cool aus, und der Ansatz, das per "solange man drückt, kann man sprechen", zu lösen, gefällt mir persönlich auch gut. Kann mir allerdings denken, dass andere das nicht so einfach zu bedienen finden. Mal sehen, ob jemand anderes sich dazu zu Wort meldet.

Hatte versucht, ob das overlay auch an fhemapp "weitervererbt" wird, aber jedenfalls ohne weiteres ist es mir nicht gelungen, das auch dort sichtbar zu machen. Jedenfalls kam es mir so vor, dass das separate js ein Ansatz sein könnte, diese Art Funktionalität auch dort unterzubringen.

Generell könnte ich mir vorstellen, zweigleisig zu fahren:
- die f18-Lösung als "Basisvariante für alle Browser", aber eben nur im "normalen FHEMWEB" (falls es nicht eine einfache Lösung gibt, den "Mikro-Button" in fhemAPP irgendwie auch sichtbar und funktional zu machen, und die
- VoiceButton-Lösung als "vollintegrierte FULLY/RHASSPY(2)"- Lösung auszubauen.
fully (PLUS-Version) hat eine (m.E. hinreichend) ausgefeilte API, mit der man v.a. auch die aufgezeigten Timing-Probleme beim Zusammenspiel zwischen Mikro und Lautsprecher in den Griff bekommen sollte (bei AMAD ist das vergleichbar gewesen, soweit ich das in Erinnerung habe und im Moment überblicken kann). Dazu könnte man z.B. per js checken, ob fully in der PLUS-Version läuft (String fully.getDeviceId() aus https://www.fully-kiosk.com/en/#rest, dort "JavaScript Interface ( PLUS )", "Get device info"), und dann statt an global das betreffende FULLY-Device mit der Info versorgen, was STT ermittelt hat.

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.

Kommt mir bekannt vor... Hatte vermutlich 1000 Zeilen Code in RHASSPY geändert, bevor ich den Dienst überhaupt selbst installiert habe .

Jedenfalls: Falls du Interesse hast, ist Rhasspy@docker in 0,nix am Laufen, und die Konfiguration in FHEM ist zwischenzeitlich auch easy... Letztlich "brauchen" wir für's Weiterentwickeln jedenfalls keine Hardware, egal, ob jetzt in der FULLY-Variante oder mit "global" und FHEM-TTS .
(Ich muss nur bei RHASSPY dann wieder ziemlich unter das Auto steigen, um das zu erweitern und noch einige Patches sauber einzuarbeiten, die aus einer Diskussion mit gregorv stammen, aber nicht ganz finalisiert sind)...