[Voicecontrol] Button für Fhemweb

Begonnen von schwatter, 14 März 2026, 17:25:25

Vorheriges Thema - Nächstes Thema

Beta-User

#30
Bzgl. firefox muss ich mich korrigieren: Sowohl unter Linux wie Android bekomme ich zumindest die Ansage, dass James (de-) aktiviert wurde.

Woran es noch fehlen könnte, wäre ggf. auch einfach erst mal die Anfrage, überhaupt das Mikrofon nutzen zu dürfen. Da bietet mir Firefox anscheinend keine Option an, den FHEM-Server proaktiv einzutragen?
Spätestens beim Klick auf eines der Mikrofone müßte das doch geschehen, oder?

Edit: Strg+i ist mein Freund, hilft aber nicht weiter, weil das Mikro dem Gefühl nach trotzdem nicht aktiviert wird, egal, welches der Web-Mikrofone (f18/voicecontrol) ich klicke...
Server: HP-elitedesk@Debian 13, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

schwatter

Super zumindest kommt dann die Sprachausgabe. Aber für SpeechToText fehlt wirklich das Backend. Such mal quer im Netz.
Was Firefox anbietet ist, du geht auf eine Googleseite und startest da z.B Spracheingabe. Das funktioniert, da da direkt
Google angezapft wird.

Im Moment habe ich für Firefox zum testen das alles gesetzt:
# Spracherkennung (Web Speech API) aktivieren
media.webspeech.recognition.enable          -> true
media.webspeech.recognition.force_enable    -> true

# Sicherheitskontext für deine FHEM-IP umgehen (WICHTIG!)
dom.securecontext.whitelist                 -> http://192.168.1.76:8084

# Mikrofon-Zugriff für unsichere Quellen (HTTP) erlauben
media.getusermedia.insecure.enabled         -> true
media.devices.enumerate.all.insecure        -> true
dom.serviceWorkers.testing.enabled          -> true

# Berechtigungs-Abfragen komplett deaktivieren (Vorsicht: Global)
media.navigator.permission.disabled         -> true
permissions.default.microphone              -> 1

Damit ist immerhin das Micro nicht mehr blockiert. Bzw ich werde auch nicht ständig gefragt.

Als Addon habe ich "Speech Recognition Polyfill" installiert. Bis jetzt konnte ich es noch nicht anzapfen.

Gruß schwatter

schwatter

Kleines Update im ersten Post - nur das notify angepasst.

Bei Spracheingabe "james kommandos" wird jetzt ein Popup mit der Befehlsübersicht eingeblendet.
Momentan aber auf allen offenen Screens. Da müsste ich noch eine eindeutige ID mitschicken, um
das zu differenzieren.

@Beta-User
Sie es mir nach, wenn ich noch nicht an Fully bastele. Im Moment ist die Motivation noch nicht da.
Fully mit Plus habe ich, aber die Einschränkungen bei mir mit FireOS nerven mich. Daher bastele ich
gerade lieber an dem was funktioniert.

Insgesamt wenn es vernünftig werden soll, müssen wir wohl einen anderen Weg gehen. Also anderes Backend
wie Rhasspy und Co.

Da das hier aber so einfach ist, lass ich noch nicht von ab.

Gruß schwatter

Beta-User

#33
Vermutlich ist Polyfill noch nicht richtig konfiguriert, aber immerhin bekomme ich nach dem f18-Mikro mit folgenden Einstellungen ein Dialogfeld, das auch Audio empfängt, am Ende dann aber meckert:
ZitatError connecting to the service.
Aus dem "Strauß" habe ich aktiviert:
Zitat von: schwatter am 17 März 2026, 19:21:43# Spracherkennung (Web Speech API) aktivieren
media.webspeech.recognition.enable          -> true
media.webspeech.recognition.force_enable    -> true (den key gab es nicht)

# Sicherheitskontext für deine FHEM-IP umgehen (WICHTIG!)
dom.securecontext.whitelist                -> http://192.168.1.76:8084 (dto, der Versuch, das per "+" hinzuzufügen, hat zwar geklappt, hatte aber keine Auswirkung. Der Weg über "Strg+i" dürfte dasselbe bewirkt haben)

# Mikrofon-Zugriff für unsichere Quellen (HTTP) erlauben
media.getusermedia.insecure.enabled        -> true (Das war die letzte Änderung, danach wurde nicht mehr ständig nach der Berechtigung gefragt)
media.devices.enumerate.all.insecure        -> true (hätte ergänzt werden müssen, fehlt im Moment)
dom.serviceWorkers.testing.enabled          -> true (gesetzt wie empfohlen)

# Berechtigungs-Abfragen komplett deaktivieren (Vorsicht: Global)
media.navigator.permission.disabled        -> true (gesetzt wie empfohlen)
permissions.default.microphone              -> 1 (hätte ergänzt werden müssen, fehlt im Moment)
Edith meint: das ist Firefox unter Linux. Am Handy war mir das heute morgen noch zu fummelig...
Server: HP-elitedesk@Debian 13, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Beta-User

Zwischenstand:

Mit einer zusätzlichen Zeile und einer kleinen Änderung wird das STT-Reading je nach Browser entweder nach global gesetzt, oder an die betreffende FULLY-Instanz (getestet unter fully und Chrome unter Android):

Vorne (Zeile 15) ergänzt:
        const notifydevice = ( typeof fully !== 'undefined' && typeof fully.getDeviceId() !== 'undefined' ) ? `TYPE=FULLY:FILTER=deviceid=${fully.getDeviceId()}` : "global";
und in        function sendAction(cmd) {
...
            const fhemCmd = `setreading ${notifydevice} STT ${cmd}`;        const notifydevice = ( typeof fully !== 'undefined' && typeof fully.getDeviceId() !== 'undefined' ) ? `TYPE=FULLY:FILTER=deviceid=${fully.getDeviceId()}` : "global";

...

Was aus meinem Wunschkonzert zur Funktionalität jetzt noch fehlen würde, wäre das Mikro wieder von FHEM aus aktivieren zu können für weitere STT-Aktionen. Nach meinem (immer noch rudimentärem) Verständnis müßte das über ein Reading an der FULLY-Instanz gehen können.

Tja , dann muss ich mich wohl mal bei Gelegenheit an die Renovierung von RHASSPY machen 8) .

Zitat von: schwatter am 17 März 2026, 21:25:04Insgesamt wenn es vernünftig werden soll, müssen wir wohl einen anderen Weg gehen. Also anderes Backend wie Rhasspy und Co.
Mein Vorschlag dazu wäre, das Schritt für Schritt anzugehen.

Wer heute erst mal testen will und eine "einfache" Lösung haben mag, kann ja sowas wie dein notify verwenden.

Wer heute Babble im Einsatz hat, wird das weiter verwenden wollen, und soweit ich das im Kopf habe, sollte es kein Problem sein, die Auswertungsroutinen dort aus einem sehr einfach gestrickten notify heraus anzusteuern. Ich würde wetten, dass sich pah demnächst dazu hier meldet ;D .

Was die anderen Backend-Fragen angeht:
- für Firefox ist mir noch "Speechfire" über den Weg gelaufen, https://github.com/Jejkobb/Speechfire. Das kann auch mit einem lokal installierten Server zusammenarbeiten, so dass wir - für daran interessierte User - wieder bei einer vollen offline-Funktionalität landen könnten :) .
- Im Gesamtkonstrukt, das mir im Moment als nächstem Schritt vorschwebt, spielt Rhasspy als Backend nur noch für die Intent-Erkennung (und die Identifikation der vom Sprecher gelieferten Bausteine) eine ("leider" ziemlich große) Rolle. Das zu ersetzen, aber lösbar sein. Ansonsten ist das in RHASSPY enthaltene "framework" m.E. eigentlich sehr ausgereift (und von einigen User längerfristig getestet). V.a. gibt es bereits jetzt eine Art "Sitzungsmanagement", mit dem man vermutlich zumindest die in FHEM beheimateten Timing-Probleme lösen können sollte.
Server: HP-elitedesk@Debian 13, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

schwatter

#35
Ok,

habe deinen Beitrag durchgelesen. Momentan hänge ich weiter am ausloten der Grenzen von meinem Setup. Desktop und Mobile
sind schwierig in Einklang zu bringen. Das macht einen fertig....
Immerhin habe ich jetzt Fully mit Sprachausgabe. Dazu musste ich die "Google App" installieren und auch die Google
"Speech Recognation & Synthesis" App + das JS anpassen auf fully.startSpeechRecognition .

Dadurch habe ich jetzt auch einen Patch für Rudolf um Fully mit f18 zu connecten:
function
f18_stt()
{
  var Recognition = window.SpeechRecognition || window.webkitSpeechRecognition;
  var isFully = (typeof fully !== 'undefined' && typeof fully.startSpeechRecognition === 'function');

  if (!Recognition && !isFully)
    return FW_okDialog("SpeechRecognition Interface missing");

  if (isFully) {
    fully.startSpeechRecognition("", false);
    window.onSpeechRecognitionResult = function(result) {
      if (result) {
        FW_cmd(FW_root + "?cmd=setreading " + $("body").attr("data-webName") +
               " STT " + encodeURIComponent(result) + "&XHR=1");
      }
    };
    return;
  }

  var stt = new Recognition();
  stt.continuous = true;
  stt.lang = $("body").attr("data-language") == "EN" ? "en-US":"de-DE";

  var doSend = false;
  var txt;

  stt.onresult = function(e){
    txt='';
    for(var i1=0; i1<event.results.length; i1++)
      txt += event.results[i1][0].transcript;
    $("#f18_stt").html(txt);
  };
  stt.onaudiostart = function(e){ $("#stt_state").html("Audio started") };
  stt.onaudioend   = function(e){ $("#stt_state").html("Audio stopped") };
  stt.onspeechstart= function(e){ $("#stt_state").html("Speech started") };
  stt.onspeechend  = function(e){ $("#stt_state").html("Speech stopped") };
  stt.onnomatch    = function(e){ $("#stt_state").html("No match") };
  stt.onerror      = function(e){ $("#stt_state").html(e.message) };
  stt.start();

  $("#FW_okDialog").remove();
  var div = $("<div id='FW_okDialog'>");
  $(div).html('<div id="stt_state"></div><div id="f18_stt" '+
              'style="min-height:200px;min-width:200px"></div>');
  $("body").append(div);
  var oldPos = $("body").scrollTop();
  $(div).dialog({
    dialogClass:"no-close", modal:true, width:"auto", closeOnEscape:true,
    maxWidth:$(window).width()*0.9, maxHeight:$(window).height()*0.9,
    buttons: [
      {text:"Send", click:function(){ doSend=true; $(this).dialog("close");}},
      {text:"Abort", click:function(){ $(this).dialog("close"); }}
    ],
    close:function(){
      if(doSend && txt)
        FW_cmd(FW_root+"?cmd=setreading "+$("body").attr("data-webName")+
               " STT "+encodeURIComponent(txt)+"&XHR=1");
      stt.stop();
      $(div).remove();
    }
  });

}

Außerdem sende ich jetzt noch die fw_id mit. Schaut dann im reading so aus:
setstate global 2026-03-19 19:41:04 STT kommandos [1773945420.58154]
Damit kann man genau 1 Popup auf genau dem einen Device erzeugen, welches gerade die Spracheingabe macht.
Aber ich habe Beitrag 1 noch nicht geupdatet.

Gruß schwatter

Beta-User

Wollte einfach mal fett DANKE sagen!

Hätte alleine wohl ewig, aber erfolglos an dem Thema rumgekaut!

RHASSPY (noch ohne FULLY) ist jedenfalls jetzt soweit getestet, dass ich wieder weiß, an was es zuletzt hing ::). Zumindest tritt der Effekt, der mich damals bewogen hatte, das noch nicht einzuchecken, nur auf, wenn man einen Test-Modus aktiviert, mal sehen, ob bzw. wann das ins SVN kommt.
Hängt auch davon ab, ob jemand aus Userkreis mit testen will...

Finde es jedenfalls cool, dass wir schon so weit gekommen sind!!!!!

DANKE!
Server: HP-elitedesk@Debian 13, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Beta-User

#37
Zitat von: schwatter am 19 März 2026, 20:23:06Außerdem sende ich jetzt noch die fw_id mit. Schaut dann im reading so aus:
setstate global 2026-03-19 19:41:04 STT kommandos [1773945420.58154]
Dieser Schnipsel wäre hilfreich:
Im Moment diskutiere ich mit mir als maintainer von FULLY, ob der nicht noch zwei set-Optionen verträgt.....

Denke da an
- IP (die Verbindung geht nach wie vor immer mal wieder verloren)
- TTS. Die Idee wäre dabei, die aktuelle FW_ID (auch) in FULLY zu haben, und dann den Text auch direkt an RHASSPY bzw. Babble weiterzuleiten...

Edith meint: Danke für den Update! Hatte das Wiki zur FHEMWEB-Api und der FHEMWEB-Code durcheflözt, aber nichts passendes gefunden....
Server: HP-elitedesk@Debian 13, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

schwatter

#38
Hey,

ich habe im ersten Post das voicecontrol.js + notify angepasst. Da jetzt die fw_id mitgeschickt wird, müssen Beide aktualisiert
werden.

Hier der Codesnippet zu fw_id:
let clientId = $("body").attr("fw_id") || "no_fw_id";
const fhemCmd = `setreading global STT ${cmd} [${clientId}]`;
FW_cmd("/fhem?cmd=" + encodeURIComponent(fhemCmd) + "&XHR=1");

Auf meinem Handy und auch unter Fully im FireOS jetzt top. Auf meinem Desktop bin ich unschlüssig. Vielleicht
Probleme mit meinem Mikro? Mh...


Weil ich gestern so gefrustet war, hatte ich noch kurzerhand auf meinem Fhemserver Whisper aufgesetzt, das voicecontrol.js
angepasst und damit eine Wave an Whisper geschickt. Whisper läuft in Python

Voicecontrol nimmt Wave auf-->connected zu Whisper-->schickt Wave-->Whisper wertet Wave aus--> macht Buchstaben alle klein
--> Holt sich CSRFToken--> Patscht die fw_id mit dran --->schreibt das fertige Reading nach Fhem.

Funktioniert, aber mein kleiner Server macht bei top auch mal 200 bis 260% CPU Last....sehr unbefriedigend. Whisper hatte ich
auch getweaked mit tiny und verschiedenen Setups. Aber das ist nichts für mich glaube ich. Da schaue ich aber nochmal.

Gruß schwatter

schwatter

Moin,

ich habe den Eingangspost nochmal überarbeitet, da es eine Mischung aus voicebutton.js und voicecontrol.js war.
Ich habe jetzt alles auf Voicecontrol getrimmt, einschließlich der Überschrift.

Gruß schwatter

Beta-User

Habe zwischenzeitlich mal in den Code von FULLY geschaut und da ein paar Dinge umgebaut.

Jetzt gibt es jedenfalls bei FULLY zwei neue set-Optionen:
set <fully> host <IP-Adresse>
Das ist dazu gedacht, (aus FHEMWEB/js) heraus die IP-Adresse ggf. neu zu setzen. Damit könnte man das (ohne MQTT) lösen:
Zitat von: Beta-User am 26 November 2025, 21:31:14Meine Erfahrungen mit FULLY fingen jetzt jedenfalls erst mal damit an, dass die IP-Adresse meines Androiden unterschiedlich war, je nach genutzem AP und Frequenz :o . Also schon mal nix mit zuverlässigen reconnects.
Vielleicht hilft da die MQTT-Schnittstelle weiter, wir werden sehen.

set <fully> gotSTT [FW_ID] <text>Im Moment nimmt das (optional)
- die FW_ID (damit man weiß, wohin die Antwort gehen soll, falls das künfig nur via FHEMWEB gelöst werden könnte, wird als Internal verwaltet) und
- den Textinput entgegen, der dann erst mal schlicht als Readingaktualisierung ein Event auslöst.
Mittelfristig wäre die Idee, das direkt weiterzugeben, per Attribut konfigurierbar.

Mal sehen, ob ich nachher noch Lust habe, f18.js entsprechend anzupassen.

@Rudi: Ich unterstelle mal, dass es ok ist, in f18.js direkt einige Sonderbehandlungen für fully vorzusehen? Hilfreich wäre in jedem Fall eine Zeile, die jeweils die host-Angabe akutell hält (über ein devspec-mit-fully-Id-set).
Prinzipiell würde ich dazu tendieren, das meiste in der temporären FHEMWEB-Instanz zu verwalten, v.a. auch, weil man nicht gezwungen sein sollte, tatsächlich eine FULLY-Instanz anzulegen, nur weil man den zufällig für einen für diesen Zweck guten Browser hält...
Server: HP-elitedesk@Debian 13, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Beta-User

#41
Zitat von: Beta-User am 22 März 2026, 11:36:36Mal sehen, ob ich nachher noch Lust habe, f18.js entsprechend anzupassen.
Hatte ich...

Anmerkungen:
"Vorne" in der "$(document).ready(function(){" ist die host-Aktualisierung drin:
  if (typeof fully !== 'undefined')
    FW_cmd(FW_root + "?cmd=set TYPE=FULLY:FILTER=deviceid=" + fully.getDeviceId() + " host " + fully.getHostname() + "&XHR=1");
In der f18_stt() ist auch der Code-Schnippsel aus
Zitat von: schwatter am 19 März 2026, 20:23:06function
f18_stt()
{
...}
etwas angepaßt drin. Bei mir ist das aber funktionslos, es kommt der "normale" Dialog wie unter Chrome auch. Daher ist dort (in der close:function) nochmal ein fully-spezifischer set-Befehl drin.
    close:function(){
      if(doSend && txt){
        if (typeof fully !== 'undefined')
          FW_cmd(FW_root + "?cmd=set TYPE=FULLY:FILTER=deviceid=" + fully.getDeviceId() + " gotSTT " + $("body").attr("fw_id") + " "  + encodeURIComponent(txt) + "&XHR=1");
        FW_cmd(FW_root+"?cmd=setreading "+$("body").attr("data-webName")+
               " STT "+encodeURIComponent(txt)+"&XHR=1");
      }
   
      stt.stop();
      $(div).remove();
    }

Damit ist der Weg nach FHEM rein zu FULLY erst mal funktional (aber noch nicht "schön"), um den Anschlusspfad, erst mal in Richtung RHASSPY geht es dann ein andermal.

Tendenziell würde ich dazu neigen, auch die FHEWEB-Events nur an der temporären Instanz dieser konkreten Verbindung zu generieren, oder alternativ die FW_ID-Info zusätzlich vorzuhalten. 
Server: HP-elitedesk@Debian 13, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Gisbert

Hallo Jörg,
hallo schwatter

ich lese hier auch interessiert mit und teste gerne eine weitere Spracheingabe. Da Automagic nur noch in der vorletzten Version auf neuen Android-Handys funktioniert - abgesehen vom Unsicherheitsgefühl einer alten, nicht mehr aktuellen Software - und irgendwann gar nicht mehr, ist meine Motivation zu testen entsprechend hoch.

Ich sehe aber den Wald vor lauter Bäumen nicht, warte deshalb gerne noch, bis ein Stand erreicht ist, der es interessierten Nutzern erlaubt, dieses Modul zu installieren.

Mir ist noch aufgefallen, dass die Rhasspy.pm sehr viele Änderungen erfahren hat. Muss ich als User davon etwas verstehen?

Viele Grüße Gisbert 
Proxmox | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | tuya local | Wlan-Kamera | SIGNALduino, Rauchmelder FA21/22RF | RHASSPY | DEYE | JK-BMS | ESPHome | Panasonic Heishamon

Beta-User

Hallo Gisbert,

willkommen in unserer netten Runde hier :) .

Da ich eben meine ersten Sprachanweisungen über den FULLY/FHEMWEB<=>RHASSPY-Weg (samt passender Rückantwort) abgesetzt habe 8)  8)  8) , hier das Kochrezept zum Nachmachen:

1. Morgen ein update machen, da gibt es nochmal neue Fassungen von RHASSPY und FULLY. Zu RHASSPY schreibe ich an anderer Stelle noch was, Fully hat
- zwei neue set-Optionen, "STTinput" (bisher übergangsweise "gotSTT") und "STTresponse", sowie
- ein neues Attribut "STTprocessor".

2. Die angehängte f18.js ist eine modifizierte Fassung der von Rudi bereitgestellten und kommt nach www/pgm2. Gegenüber der Ausgangsfassung von gestern ist da nur die Syntax der Übergabe der FW_ID wie von schwatter vorgeschlagen geändert (an 2 Stellen zu finden):
FW_cmd(FW_root + "?cmd=set TYPE=FULLY:FILTER=deviceid=" + fully.getDeviceId() + " STTinput " + encodeURIComponent(txt) + " [" + $("body").attr("fw_id") + "]&XHR=1");
3. Man braucht (eventuell nur im Moment) noch eine PLUS-Lizenz von fully, damit die Sprachausgabe klappt, und eine dazu passende FULLY-Instanz. An der stellt man das Attribut STTprocessor auf den Namen der zuständigen RHASSPY-Instanz, alternativ sollte auch Babble bereits in diese Richtung funktionieren (da wäre dann aber die Sprachrückmeldung manuell zu konfigurieren, war nicht mein Thema; Details siehe unten).

4. Dann muss in den f18-Einstellungen (select style im Menü ziemlich unten zu finden) bei den room-specific-Einstellungen (?!? Warum denn da?) "STT" aktiviert werden.

5. Die "normale FHEMWEB"-Seite per fully auf dem Handy öffnen, . Dann sollte links neben dem "grünen Plus" ein Mikrofon-Symbol erscheinen. Damit die Spracheingabe aktivieren, z.B. nach der Uhrzeit fragen, "Send" klicken und es könnte schon eine Antwort kommen 8) . Ansonsten die Seite mal neu laden (das nach-unten-ziehen zum refresh zu aktivieren schadet nicht...)


Anmerkungen:
- Man kann unabhängig von RHASSPY/Babble selbstredend jeden Event-Handler auf das STT-Event lauschen und die Antworten dann einfach per "set <FULLY> STTresponse <Antwort-Text>" sprechen lassen.
Der Plan dazu wäre, hierfür noch ein Attribut für eine lokale Sprachsynthetisierung vorzusehen, damit "Jeanie" immer gleich klingt ;) .
- Für Dialoge muss man vermutlich dann auch wieder aktiv das Mikro drücken, es sollte aber klappen, dass z.B. Rückfragen nach dem Raum seitens RHASSPY korrekt zugeordnet werden (ungetestet).
- Das ganze ist noch nicht hübsch, und viele der von schwatter dankenswerterweise in seinem voicecontrol.js enthaltenen Ansätze sind (noch) nicht berücksichtigt, von daher wird es vermutlich v.a. am Coding noch einige Verbesserungsmöglichkeiten geben, Tests und Rückmeldungen sind selbstredend willkommen.

Soviel an dieser Stelle dazu, ich hoffe, es ist halbwegs nachvollziehbar :)
Server: HP-elitedesk@Debian 13, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

schwatter

Nabend,

@Beta-User
Ich sehe du warst schon fleißig  :) und kommst voran. 

Um alle noch etwas mehr zu verwirren :) Im Moment fahren wir hier 2 Gleisig. Beta-User mit RHASSPY, FULLY und f18 mit
Spracheingabebutton und ich versuche immer noch Google SpeechToText weiter auszureizen.

Da meine Frau sagt, "Ist ja ganz nett die Spielerei, aber wenn ich einen Knopf drücken muss ist es solala", habe ich mich
weiter umgeschaut wie ich das aufbohren kann. Dabei geht es um das Eingangspost was ich von Zeit zu Zeit anpasse.

Als erstes bin ich bei faster-whisper gelandet. Das hat meine CPU aber zu stark belastet (230%). Dann kam mir Sonntag die Idee, ich nutze eine reine WakewordAPI. Zack https://picovoice.ai/platform/porcupine/ angemeldet....nah toll, wird hier und da als gut gelistet, die wollen aber keine Privaten. Ich warte immer noch auf Freischaltung und mit meinem Firmenaccount da reggen bringt auch nix, es soll ja für alle sein.

Dann bin ich über Openwakeword gestoplert. Das funktioniert top. Das läuft mit python venv. Ist schnell installiert und für einen Server braucht man wenig Code. Das JS verbindet sich dann per Websocket mit dem Server und schaltet bei Wakeword auf Google SpeechToText um. So konnte ich die CPU-Last von Whisper mit gut 230% auf dauerhaft 33% mit Openwakeword drücken.
Und die reine Wakeworderkennung ist wirkich top. Mitm PC und Mikro klappt das schon ganz gut. Nachteil, erstmal feste
Wakewords. James wird mit Alexa angesprochen. Aber bevor es nicht solide ist, fange ich kein Training an.

Gruß schwatter