(WIP) FHEMWEB interaktiv (speziell mit RHASSPY)

Begonnen von Beta-User, 03 April 2026, 11:24:46

Vorheriges Thema - Nächstes Thema

Beta-User

 :o  - kaum macht man es richtig, funktioniert es auch ;D ...

DANKE! für den Schubs!

Mein aktueller Code:
defmod t2s Text2Speech none
attr t2s TTS_Ressource maryTTS
attr t2s TTS_User url='http://127.0.0.1:5000/' method=POST header='Content-Type: application/json' data={"text": "$text"}

Idee hinter dieser Konfig: Alle "eigenen Serverdienste" können über die "Großmutter" solcher Dienste, maryTTS angesteuert werden, man muss "nur" die korrekten Settings in TTS_User übergeben.
Kann sein, dass das noch nicht vollständig alle Optionen für fhem-httputils abdeckt, aber für den Moment würde ich das so lassen?
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,


ich bestätige, so läuft es auch bei mir unter marryTTS. Und ja, ich auch denke auch, lass es erstmal so. Wenn noch was ist,
meldet sich wer. Oder wir sind schneller.

Gruß schwatter

Beta-User

Dann mache ich mal einen Patch für @Tobias fertig :) .
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

Ja bitte, meine Liste von exclude_from_update wird immer größer  ;D

Gruß schwatter

Beta-User

Zitat von: schwatter am 28 April 2026, 21:19:42Ja bitte, meine Liste von exclude_from_update wird immer größer  ;D

Gruß schwatter
here you are: https://forum.fhem.de/index.php?topic=128346.0 (muss vermutlich Tobias auch direkt anpingen).

Btw: updates für t2s sind so selten, da lohnt es sich kaum, die "Hosenträger" anzuziehen...
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

Zitat von: Beta-User am 29 April 2026, 07:56:57muss vermutlich Tobias auch direkt anpingen
done. Dann warten wir mal ab, wann er Zeit findet, sich das anzusehen.

Nun ja, zumindest vorläufig können wir also diesen Exkurs zu Text2Speech für "erledigt" erklären, stellt sich die Frage, wie es sinnvoll weitergehen soll (wenn ich mal wieder Zeit finde, überhaupt weiterzubasteln - die nächsten Tage vermutlich nicht...).

Meine Idealvorstellung wäre weiter, piper per fetch() von js aus abzufragen und dann das js einfach wieder den "bin fertig"-Event absetzen zu lassen. Den ganzen Code dazu würde man auf der FHEM-Seite doch zusammenbasteln können, schwierig zu umschiffen kommt mir allerdings das CORS-Ding vor (Neuland, das alles)...

T2S-Events abzugreifen ginge (vielleicht) auch, aber das per js zu machen, kommt mir nach wie vor nicht wie eine "einfache" Lösung vor, und wechselseitige Event-Abhängigkeiten z.B. von RHASSPY und T2S zu basteln, gefällt mir letztlich genausowenig, wie z.B. die wav (direkt) aus RHASSPY heraus generieren zu lassen und dann zur Wiedergabe per js freizugeben....

Na ja, das darf jetzt jedenfalls erst mal vor sich hin gedacht werden ??? .
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

#51
Nabend,

den Event bekommen wir durch das attr additionalInform auf das TTS-Device gesetzt. Hier in f18 umgesetzt.

https://forum.fhem.de/index.php?msg=1362632

Damit wird auf jedem Device die letzte MP3 von TTS abgespielt. Daher werde ich Voicecontrol wohl auch umbauen,
damit ich Piper als Stimme habe. Die Sprachausgabe auf meinem FireHD ist roboterhaft schlecht.

Gruß schwatter

Beta-User

Zitat von: schwatter am 30 April 2026, 18:56:18den Event bekommen wir durch das attr additionalInform auf das TTS-Device gesetzt.
Vermutlich reden wir in Teilen aneinander vorbei, es geht um zwei Zeitpunkte:
1. Wann kann die Ausgabe starten, und
2. wann ist sie beendet?

Das mit additionalInform ist zunächst mal eine Option für den ersten Zeitpunkt. Ich werde mir das ansehen (Danke noch für das diff hier weiter oben), wie schon weiter oben mal angekündigt.

Für die "Interaktivität" im Sinne dieses Threads ist aber das 2., das "bin fertig"-Event genauso wichtig...
In diesem Code "verborgen" in dem "utterance.onend = ..."-Handler.
Zitat von: Beta-User am 21 April 2026, 07:23:50@Rudi - falls du hier mitliest: Scheinbar hatte ich bisher noch nicht meine modifizierte f18_speak() mit dem "bin fertig"-Event gezeigt.

Hier die Roh-Fassung:
Code Auswählen Erweitern
function
f18_speak(txt)
{
  let synth = window.speechSynthesis;
  if(!synth)
    return FW_okDialog("No speechSynthesis available");

  const utterance = new SpeechSynthesisUtterance(txt);
   
  // Good practice: Set listeners even if they're unreliable on all voices
  utterance.onend = () => {
        var fw_id = $("body").attr("fw_id");
        FW_cmd(`${FW_root}?cmd=setreading `+
               `TYPE=FHEMWEB:FILTER=FW_ID=${fw_id}:FILTER=inform=.%2B `+
               `TTS_state finished&XHR=1`);
  };

  synth.speak(utterance);
  //speechSynthesis.speak(new SpeechSynthesisUtterance(txt));
  //see https://iifx.dev/en/articles/457363230/chrome-tts-workarounds-solving-the-speechsynthesisutterance-event-and-initial-speak-failure for more info
}

Zitatdamit ich Piper als Stimme habe.
:) freut mich, dass dir diese Lösung (besser) gefällt. Ist auch kein Zufall, dass pah seine "Polly"-Apps als backup vermutlich im Jahr 2050 noch vorhalten wird ;D .


Was gefällt mir nun eigentlich an dem "additionalInform"-Weg im Moment nicht so recht?
- Man braucht überhaupt ein weiteres FHEM-Device. Wenn man das Abholen von piper per js erledigen könnte, braucht man den ganzen anderen Kram gar nicht :P . Leider funktionierte mein Testcode nicht.
- T2S fragt blockierend ab und wandelt nach mp3 um. Ist historisch bedingt halt so, aber beides mag ich nun mal einfach nicht, zumal
- mir das "Zwischenlagern" von files nicht gefällt, und
- mir noch nicht klar ist, ob T2S überhaupt einen Event generiert, wenn es diese Ausgabe schon als file gibt;
- Zu guter Letzt: Wenn es mehrere User gibt, braucht man auch mehrere Instanzen von T2S, oder? 

Insgesamt: Es ist frickelig, mir sind insgesamt bei dem T2S-Weg zu viele Stolpersteine verbaut, die mir im Moment unnötig vorkommen :P .

Wenn es nun keine Lösung für das direkte Abfragen bei piper aus js heraus gibt, werde ich daher für RHASSPY vermutlich dann separaten, non-blocking code basteln, der dann eine Datei pro offenem Dialog abholt und per "play"-Funktion aktiv an die betreffende Gegenstelle zum Abspielen anweist. Die js-Funktionalität fehlt in f18 noch, und wäre bitte ebenfalls mit "bin fertig-Event" am Ende zu versehen.

Hoffe, das ist jetzt etwas klarer?
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