[Neues Modul] BOSE SoundTouch

[FlatTV]

Ist bei mir auch so, konnte das nicht weiter prüfen.

Code Auswählen Erweitern

2026.05.27 19:38:21 3: BOSEST: failed: 500 Internal Server Error

[fred_feuerstein]

Danke für den Check der Speak Funktion.

Dann liegt also kein lokales Problem bei mir vor.

Also liegt ein Problem bei der Google TTS Abfrage vor. Ich versuche mal herauszufinden wie das genau abgefragt wird im modulcode. Vielleicht kann man es extern prüfen und ggfs. mehr Infos herausbekommen.

Aber normalerweise sind die 500er Fehler ja Serverbasiert...

[fred_feuerstein]

wegen der nicht funktionierenden Speak-Funktion.

Denke hier im Modul erfolgt das mit der Sprachausgabe:

Code Auswählen Erweitern

sub BOSEST_speak($$$$$) {
    my ($hash, $text, $volume, $lang, $stopAfterSpeak) = @_;

    $lang = AttrVal($hash->{NAME}, "ttsLanguage", "en") if($lang eq "");
    $volume = AttrVal($hash->{NAME}, "ttsVolume", ReadingsVal($hash->{NAME}, "volume", 20)) if($volume eq "");

    if(length($text) < 100) {
       my $uri_text = uri_escape($text);
       my $translateUrl = "http://translate.google.com/translate_tts?ie=UTF-8&tl=$lang&client=tw-ob&q=$uri_text";
       $translateUrl =~ s/\&/\&amp\;/g;

       if(substr($volume, 0, 1) eq "+" or
          substr($volume, 0, 1) eq "-") {
           $volume = ReadingsVal($hash->{NAME}, "volume", 0) + $volume;
       }

       my $postXml = '<play_info><app_key>Ml7YGAI9JWjFhU7D348e86JPXtisddBa</app_key><url>'.$translateUrl.'</url><service>'.$text.'</service><volume>'.$volume.'</volume></play_info>';
       if(BOSEST_HTTPPOST($hash, '/speaker', $postXml)) {
       }

       if(defined($stopAfterSpeak) && $stopAfterSpeak eq "1") {
           $hash->{helper}{stateCheck}{enabled} = 1;
           #after play the speaker changes contentItemItemName
           $hash->{helper}{stateCheck}{actionContentItemItemName} = "";
           $hash->{helper}{stateCheck}{function} = \&BOSEST_off;
       }

       return undef;
    }
   
   
    my $ttsDir = AttrVal($hash->{NAME}, "ttsDirectory", "");
   
    my $sox = qx(which sox);
    chomp $sox;
    if(!-x $sox) {
        BOSEST_playGoogleTTS($hash, $ttsDir, $BOSEST_READ_CMDREF_TEXT, $volume, $BOSEST_READ_CMDREF_LANG, $stopAfterSpeak);
        return undef;
    }
   
    #download file and play
    BOSEST_playGoogleTTS($hash, $ttsDir, $text, $volume, $lang, $stopAfterSpeak);
   
    return undef;
}
Da ist ja auch ein app_key enthalten. Evtl. hat es damit was zu tun? Abgelaufen?

Hat da jemand mehr Ahnung von als ich?

Ich habe die im Code stehende Abfrage-Url von Google mal manuell getestet. Also der TTS von Google funktioniert.
es scheitert dann wohl beim abspielen der Rückmeldung mit diesem Play und AppKey.
Keine Ahnung wie das abgespielt wird oder was das für ein key ist. Somit kann ich auch nicht schauen ob der key evtl. nicht mehr gültig ist etc.

[fred_feuerstein]

Also ich habe (zusammen mit ChatGPT) an drei Stellen im 98_BOSEST.pm Modul (letzter Stand aus dem Git als Basis) Änderungen vorgenommen.

Damit läuft der Speak Befehl im Modul wieder.

Die Annahme, dass es nicht an Google lag, war wohl korrekt! Bei einem "set BOSEDEVICE speak ..." wurde das scheinbar über einen Bose-Dienst dann direkt auf dem Lautsprecher abgespielt, deshalb dieser appkey (etc.).

Voraussetzung ist nun ein aktiver und funktionsfähiger minidlna (bei mir auf dem gleichen Raspberry wie fhem).
Und der minidlna (bei mir als Name: fhem_tts) muss vom Lautsprecher aus als source erreichbar sein.

Wenn nun ein speak Befehl abgesetzt wird, dann erfolgt die Konvertierung über Google (wie bisher), die mp3 wird im tts Directory gespeichert, kurze Pause von 5 Sekunden um dem minidlna die Zeit zum indizieren zu geben, dann wird die mp3 auf dem Lautsprecher abgespielt. Nach Abspielen der tts mp3 wird wie bisher wieder zum vorigen Zustand gewechselt, also der bisherige Stream, oder falls ausgeschaltet war, wird die Box auch wieder ausgeschaltet.

Hier die drei Änderungen:

im "sub BOSEST_speak":
statt

Code Auswählen Erweitern

if(length($text) < 100) {nun

Code Auswählen Erweitern

if(0 && length($text) < 100) {durch diese Änderung wird u.a. die mp3 gespeichert

im "sub BOSEST_HTTPPOST":
statt

Code Auswählen Erweitern

my $ua = LWP::UserAgent->new();nun

Code Auswählen Erweitern

my $ua = LWP::UserAgent->new(timeout => 5);mit der kaputten speak Funktion hat sich fhem fast aufgehängt, nun timeout von 5 Sekunden aus Sicherheitsgründen.

im "sub BOSEST_playMessageStringArg":

komplett tauschen von bisher:

Code Auswählen Erweitern

sub BOSEST_playMessageStringArg {
    my ($name) = @_;
    my $hash = $main::defs{$name};
   
    BOSEST_playMessage($hash, "v1_".$hash->{helper}{tts}{fulltextmd5}, $hash->{helper}{tts}{volume}, $hash->{helper}{tts}{stopAfterSpeak});
   
    return undef;
}auf jetzt:

Code Auswählen Erweitern

sub BOSEST_playMessageStringArg {
    my ($name) = @_;

    InternalTimer(
        gettimeofday()+5,
        "BOSEST_playMessageStringArgDelayed",
        $name,
        0
    );

    return undef;
}

sub BOSEST_playMessageStringArgDelayed($) {
    my ($name) = @_;
    my $hash = $main::defs{$name};

    BOSEST_playMessage(
        $hash,
        "v1_".$hash->{helper}{tts}{fulltextmd5},
        $hash->{helper}{tts}{volume},
        $hash->{helper}{tts}{stopAfterSpeak}
    );

    return undef;
}
im ttsDirectory landen nun die ganzen mp3s, das kann u.U. recht viel werden, je nachdem, wie viele Speak Befehle man absetzt. (bei mir recht viele Meldungen tagsüber ). Deshalb lasse ich die beiden Varianten der mp3s per cron nachts löschen:

Code Auswählen Erweitern

15 3 * * * rm -f /opt/fhem/tts/[0-9a-f]*.mp3 && rm -f /opt/fhem/tts/v1_*.mp3
Ist alles so seit gestern wieder am Laufen.

Kenne mich mit Git usw. nicht so gut aus. Deswegen die Änderungen hier gemeldet.

Ich hänge immer noch damit hinterher, das neue Modul regulär einzuchecken. Bitte um Nachsicht, aber mein neues Buchmanuskript hat in 3 Wochen Abgabetermin, das geht derzeit vor.
LG
pah

Vielleicht kannst Du die Änderungen siehe oben berücksichtigen fürs offizielle Release.