[Voicecontrol] Button für Fhemweb

[Beta-User]

Moin,

die Changes (https://svn.fhem.de/trac/changeset/31010/trunk/fhem/FHEM und https://svn.fhem.de/trac/changeset/31009/trunk/fhem/FHEM) sind doch eher sehr überschaubar , von daher ist "fleißig" relativ...
War schon vorher überzeugt, dass es ziemlich simpel sein sollte, FULLY als AMAD-Ersatz (sowohl für RHASSPY wie für Babble) zu verwenden, wenn man denn den STT-input "irgendwie" bekommt.

Die größere Aufgabe wird das Feintuning sein .
Ad Wakeword:
- Rhasspy kann auch diverse Varianten und empfielt Porcupine. Das lief nach meinen (wenigen) Erfahrungen auch auf einem Pi (3B+?) ohne nennenswerte Last.
- Der Gedanke, ständig Audio über das Netz zu schicken, hat mir persönlich noch nie richtig gefallen... Von daher hatte ich zwischenzeitlich auch mal mit Android-Apps rumexperimentiert. Müßte das aber suchen, und wie dann der Link zu FHEMWEB/FULLY wäre, müßte man sich auch ansehen.

Im Moment würde ich eventuell optional die Aktivierung via Näherungssensor@FULLY als sinnvolle Option für Wanddisplays ansehen.

Mein Plan für die nächsten Schritte wäre,
- das Mikro interaktiv wieder zu aktivieren (für Rückfragen bzw. weitere Anweisungen)
- die Audio-Ausgabe mit "Thorsten" zu machen. Ein ebenfalls sehr schmaler Webserver für "Piper" (OHF-Voice/piper1-gpl) läuft bereits, Anleitung wäre hier zu finden: https://github.com/OHF-Voice/piper1-gpl/blob/main/docs/API_HTTP.md
- das auf der RHASSPY-Seite noch so zu ergänzen, dass es auch mit Chrome funktioniert .

Ansonsten finde ich die 2-gleisigkeit zumindest für den Moment völlig ok. Falls es stört, bitte melden.

An die RHASSPY-User (und eventuelle Interessierte): Falls es spezifische Themen zur dortigen Konfiguration geben sollte - Bitte in einem der RHASSPY-Threads melden oder einfach einen neuen aufmachen.

[rudolfkoenig]

Ich habe FHEMWEB mit dem publicHostnames Atrtribut erweitert: wenn gesetzt, dann wird ein Zertifikat mit diesen Rechnername/IP-Adressen erstellt.
Weiterhin bekommt man in der Detailansicht von FHEMWEB unter dem Reading publicCertificate einen Link zum oeffentlichen Zertifikat.
Soweit ich sehe, akzetieren die meisten Browser keine IP-Adressen, d.h. um es sinnvoll zu verwenden, muss man FHEM mit dem Rechnernamen aufrufen.

Auf meiner TODO Liste ist noch die eindeutige Client-Kennung fuer die STT Nachrichten.
Da hier sehr viel geschrieben wurde, und ich nicht sicher bin, dass ich alles verstanden habe: kann mir noch jemand zusammenfassen, was in f18 noch eingebaut werden sollte?

[Beta-User]

Da hier sehr viel geschrieben wurde, und ich nicht sicher bin, dass ich alles verstanden habe: kann mir noch jemand zusammenfassen, was in f18 noch eingebaut werden sollte?

Hier mal der Versuch einer Zusammenfassung anhand des angehängten diff:

1.

Code Auswählen Erweitern

   f18_setWidePortrait();
+  if (typeof fully !== 'undefined')
+    FW_cmd(FW_root + "?cmd=set TYPE=FULLY:FILTER=deviceid=" + fully.getDeviceId() + " host " + fully.getHostname() + "&XHR=1");
 });
Das ist eine Hilfe für das FULLY-Modul. Das Modul war bisher mit fester IP oder festem hostname einzurichten, was dann nicht klappt, wenn das Android nicht speziell so konfiguriert wird, dass im jeweiligen WLAN immer dieselbe MAC-Adresse bekannt gegeben wird.
Aus meiner Sicht wäre das eine dringende Bitte, es sei denn, wir wollen alle fully-spezifischen Einstellungen in eine eigene .js auslagern. Dann käme das da rein.

2.

Code Auswählen Erweitern

-  if(!window.SpeechRecognition)
+  var Recognition = window.SpeechRecognition || window.webkitSpeechRecognition;
+  var isFully = (typeof fully !== 'undefined' && typeof fully.startSpeechRecognition === 'function');
+
+  if (!Recognition && !isFully)
     return FW_okDialog("SpeechRecognition Interface missing");

-  var stt = new SpeechRecognition();
+  if (isFully) {
+    fully.startSpeechRecognition("", false);
+    window.onSpeechRecognitionResult = function(result) {
+      if (result) {
+         FW_cmd(FW_root + "?cmd=set TYPE=FULLY:FILTER=deviceid=" + fully.getDeviceId() + " STTinput " + encodeURIComponent(txt) + " [" + $("body").attr("fw_id") + "]&XHR=1");
+      }
+    };
+    return;
+  }
+
+  var stt = new Recognition();Das ist der übernommene patch-Vorschlag von schwatter. Der Teil funktioniert bei mir nicht, das könnte eventuell für eine frühere fully-Version hilfreich sein.

Den Teil würde ich im Moment NICHT dringend ins svn übernehmen und erst mal warten, ob das mit (halbwegs) aktuellen Android-Modellen überhaupt auftritt (oder auch mit älteren der nachfolgende Teil ausreicht):

3.

Code Auswählen Erweitern

-      if(doSend && txt)
+      if(doSend && txt){
+        if (typeof fully !== 'undefined')
+          FW_cmd(FW_root + "?cmd=set TYPE=FULLY:FILTER=deviceid=" + fully.getDeviceId() + " STTinput " + encodeURIComponent(txt) + " [" + $("body").attr("fw_id") + "]&XHR=1");
         FW_cmd(FW_root+"?cmd=setreading "+$("body").attr("data-webName")+
                " STT "+encodeURIComponent(txt)+"&XHR=1");
+      }
+
Damit bekommt man die für die jetzige svn-Fassung von FULLY erforderlichen Infos im von schatter vorgeschlagenen Format (in eckigen Klammern angehängte FW_ID).

Anders formuliert:
Mit den patch-Teilen 1 und 3 könnte Gisbert nach einem update mit testen. Er würde nur (in FHEM) ein FULLY-Device benötigen und müßte dort im Attribut "STTprocessor" auf sein "zuständiges" RHASSPY-Device verweisen, und dazu noch die STT-Option in f18 aktivieren. Dann sollte es zumindest mit installiertem fully (mit PLUS-Lizenz) funktionieren, von dort aus Sprachbefehle via f18 einzusprechen und die passende Antwort zu erhalten.

Meine (komplettere) Wunschliste würde ich dann später mal posten, und vorher eventuell noch das eine oder andere Testen.

[Gisbert]

Anders formuliert:
Mit den patch-Teilen 1 und 3 könnte Gisbert nach einem update mit testen. Er würde nur (in FHEM) ein FULLY-Device benötigen und müßte dort im Attribut "STTprocessor" auf sein "zuständiges" RHASSPY-Device verweisen, und dazu noch die STT-Option in f18 aktivieren. Dann sollte es zumindest mit installiertem fully (mit PLUS-Lizenz) funktionieren, von dort aus Sprachbefehle via f18 einzusprechen und die passende Antwort zu erhalten.

Hallo Jörg,

ich bin gerne bereit zu testen, falls euch das in der Entwicklung weiterhilft. Dazu müsste ich aber genau wissen, was ich zu tun habe. Das Ziel kann ich wohl erkennen, aber die einzelnen Schritte dazu verstehe ich noch nicht.
Falls dein Ansinnen nur dazu da ist, mich mit meinem Sonderweg(? - RHASSPY, AMAD, Automagic, Google Speech Service) zu begleiten, dann ist das nicht nötig. Ich warte gerne, bis ein testreifer Zustand erreicht ist, und ich wie oben geschildert einsteigen kann.

Viele Grüße Gisbert

[schwatter]

@beta-user

zu 2.
Ich habe gerade nochmal Fully auf meinem LineageOS 23.2, sprich Android 16 installiert. Mit dem Patch aus #35
funktioniert das Mikro von Rudolf bei mir auch. Ich verstehe nicht, warum das bei dir nicht funktioniert.

@Rudolf
Danke für das einbauen um direkt Zertifikate zu generieren. Ich habe es gerade auf meinem Handy mit Chrome getestet.
Eine Verbindung mit http://hostname:8083/fhem konnte ich aufbauen. Leider kommt ständig
"Connection lost try reconnect evvery 5 sek." Ab und zu kann ich mich durch mein Fhem klicken. Woher können die
Abbrüche kommen? Longpoll habe ich auf websocket. Mit Verbose 5 sehe ich nichts. Ich muss mal ADB anschmeißen.

edit:
Hat sich erstmal erledigt. Ich habe nicht gesehen das ich auf http zugegriffen habe...Die doofe Adresszeile blendet das ja immer aus....
Ich denke jetzt ist es ok.

edit2:
Fully benötigt in den Einstellungen die Option ,,Ignore SSL Errors", damit HTTPS funktioniert.
Auf meinem Firmenhandy trat das Problem ebenfalls auf, bis mir aufgefallen ist, dass ich ja Private DNS (dns.adguard.com) konfiguriert hatte. Nach dem Deaktivieren des privaten DNS funktionierte die Verbindung problemlos.

edit3:
Außerdem kann ich bestätigen, das das Mikro von Rudolf in f18 und Semi-HTTPS funktioniert. Super.

Gruß schwatter

[rudolfkoenig]

Mit den patch-Teilen 1 und 3 könnte Gisbert nach einem update mit testen.

Ich habe das auch so eingecheckt.

Weiterhin habe ich das Generieren des Zertifikats umgebaut.
Da aktuelle Browser keine selbstsignierten Zertifikate akzeptieren, wird erst ein CA Zertifikat erzeugt, und damit das FHEMWEB Zertifikat signiert.
Zum Download wird jetzt das CA Zertifikat angeboten, das muss man installieren.
Hat den weiteren Vorteil, dass beim Anpassen des FHEMWEB Zertifikates nichts mehr installiert werden muss, da (wenn einmal vorhanden) das CA Zertifikat nicht mehr geaendert wird.

[schwatter]

Ich habe noch 2 Anmerkungen

1. Wenn puplicHostnames gesetzt und dann HTTPS auf 1 blockiert mein Browser. Ein Neustart cancelt dann den Save?

2. puplicHostnames ohne Domain sind schlecht, da in Chrome z.B. keine Logindaten gespeichert werden können. Mh, wird .local verschluckt?

Grußs schwatter

[Beta-User]

Ich habe das auch so eingecheckt.

Danke!

@beta-user

zu 2.
Ich habe gerade nochmal Fully auf meinem LineageOS 23.2, sprich Android 16 installiert. Mit dem Patch aus #35 funktioniert das Mikro von Rudolf bei mir auch. Ich verstehe nicht, warum das bei dir nicht funktioniert.

Kann durchaus sein, dass ich beim Testen was falsch gemacht habe, werd's bei Gelegenheit nochmal durchspielen. fully ist/war zumindest bei den ersten Tests ziemlich zickig, was die Akzeptanz des geänderten js anging, und mit der Sprache selbst fremdle ich auch noch ziemlich, und war vor allem froh, als es dann "irgendwie" und irgendwann überhaupt funktioniert hat .

ich bin gerne bereit zu testen, falls euch das in der Entwicklung weiterhilft. Dazu müsste ich aber genau wissen, was ich zu tun habe. Das Ziel kann ich wohl erkennen, aber die einzelnen Schritte dazu verstehe ich noch nicht.

Falls (!) ich das richtig zusammengepuzzelt habe, wäre Schritt 1, das neue "publicHostnames"-Attribut an dem FHEMWEB-Device zu setzen, über das du in fully (sofern vorhanden) oder Chrome auf FHEM zugreifst, und im Browser nicht die IP-Adresse einzugeben, sondern den hostname.

2. Im Moment müßte f18 als Style gewählt sein und in den f18-Style-Einstellungen dann die Option STT aktiviert werden.

Dann solltest du nach dem Neuladen der FHEMWEB-Seite (eventuell nach Bestätigung des Zugriffs auf das Mikro) mit einem Klick auf das neu hinzugekommene Mikrofon-Symbol das Dialogfeld erhalten und was einsprechen können, das dann nach Klick auf "OK" an der FULLY-Instanz (falls angelegt) und zusätzlich am FHEMWEB-Device als Reading landet (auch hier ggf. die Seite neu laden, damit das neu angelegte Reading sichtbar wird).

3. Um das mit RHASSPY zu koppeln, wäre dann am FULLY-Device einfach der Name des RHASSPY-Devices einzutragen (Attribut: STTprocessor).   

4. Frage nach der Uhrzeit, schalte das Licht ein, usw.. Im Moment braucht man dazu eine PLUS-Lizenz, weil (intern) der reguläre "speak"-Befehl genutzt wird. Ansonsten ist am FULLY-Device zu sehen, was geantwortet worden wäre.

5. Weitere Tests: Mal sehen...
So oder so: vermutlich ist der Hauptteil erst mal jeweils die js zu tauschen (und den Browser zu überreden, die auch zu laden). Da steckt jeweils erst mal die meiste Funktionalität drin, den FULLY/RHASSPY-Teil würde ich dann via svn bereitstellen, vermutlich schlicht im regulären update.
Mein nächstes Zwischenziel wäre in Richtung Bedienbarkeit v.a. die Möglichkeit, von FHEM aus das Mikro wieder aufzumachen. Sollte eigentlich auf Basis von dem "welche Optionen gibt es"-Schnippsel von schwatter zu machen sein...