Verschluckte Ansagen auf Alexa

[Superposchi]

Hallo, es kommt bei mir immer wieder mal vor, dass Ansagen einer Benachrichtigung vom entsprechenden Alexa-Lautsprecher "verschluckt" werden. der Dot bzw. Pop zeigt an, dass eine Ansage kommt, doch es kommt dann außer dem kurzen Ton doch nichts.
Manchmal wenn die Ansage auf mehr als einer Ausgabequelle erfolgen soll, kommt es sogar vor, dass es auf einem Lautsprecher funktioniert und auf dem anderen nicht. Leider gibt es keine Regel, so dass immer die gleichen Ansagen verschluckt werden oder zur gleichen Zeit oder so.

Gibt es eine Möglichkeit sicherzustellen, dass eine Ansage auch wirklich ausgegeben wird? Wahrscheinlich nicht.
Gibt es ein Reading, dass eine aktive Ansage signalisiert?

[passibe]

Das liegt mit sehr großer Wahrscheinlichkeit daran, dass Amazon die Requests abblockt, weil zu viele in zu kurzer Zeit kommen.
Vor allem, wenn du versuchst gleichzeitig mehrere Geräte anzusprechen.

Was hilft, ist eine Verzögerung einzubauen, d.h. jedes Kommando, das du an das echo-Modul schickst, z.B. mit sleep um 2-3 Sekunden zu verzögern (gilt nicht nur für "speak" sondern z.B. auch für Lautstärkeänderungen).

Wenn du mehrere Echos über eine structure ansprichst, könntest du statt sleep dafür auch das Attribut async_delay der structure nutzen.

Achtung natürlich, dass bei sleep nichts blockiert, d.h. es muss immer ein weiteres FHEM-Kommando folgen (dazu mal hier im Forum lesen, falls du nicht weißt, was gemeint ist).

[Superposchi]

Ich würde gerne feststellen ob eine Ausgabe erfolgt und wenn ja, dann in eine Verzögerungsschleife wechseln.
Gibt es kein Reading das anzeigt ob etwas wiedergegeben wird - ich sehe zumindest aktuell keins.

[passibe]

Ne, wüsste nicht, dass es sowas gibt.
Wäre auch gar nicht so einfach zu implementieren, denn vielfach wäre die Ausgabe schon vorbei, bis das Reading "umspringt" (bis der Echo das an Amazon meldet, dass er gerade was ausgibt, bis das Modul das dann von Amazon abruft ... ...).
Worüber man allenfalls nachdenken könnte ist, dass das Modul einen 429 (too many requests) erkennt und dann selbst eine Verzögerung einbaut. Das könntest du dem Modulentwickler im jeweiligen Thread mal vorschlagen.

Ansonsten aber einfach per default eine Verzögerung einbauen und gut ist. Sehe da wenig Nachteile.

[Superposchi]

Ok, danke für die Info.
Nur den letzten Satz verstehe ich nicht ganz.
Welchen default meinst du genau?
Im Alexa-Device

Ich gebe die Ansagen per myutils aus.
Wäre es da eine möglichkeit beim Aufruf des Codes selbst eine Variable zu setzen die die Ausgabe "anzeigt" und am Ende mit Verzögerung zurückgesetzt wird.

Da die Ansagen von diversesten Ereignissen ausgelöst werden könnte ich so auch Überschneidungen aus verschiedenen Auslösern abfangen, oder nicht?

[passibe]

Den default, den du selbst einprogrammierst. Einfach IMMER Ansagen bei mehreren Geräten verzögern.

Wie du das löst kommt halt drauf an, wie dein code aussieht.

Wenn du z.B.

Code Auswählen Erweitern

set echo1 speak "blabla"; set echo2 speak "blabla"nutzt, dann könntest du das zu

Code Auswählen Erweitern

set echo1 speak "blabla"; sleep 3; set echo2 speak "blabla"ändern.

Wenn du eine Variable machen willst, die Ansagen solange zurückstellt, bis die andere Ansage fertig ist, musst du natürlich ein bisschen kreativer werden. Hab jetzt spontan keine gute Idee, wie man das umsetzen könnte. Musst du nochmal nachdenken und für deinen eigenen Bedarf dann umsetzen. Kommt aber auch drauf an, wie viele Ansagen man hintereinander schickt, die nur ein Device betreffen (wo es ja normalerweise nicht zum "Verschlucken" kommen dürfte?). Normalerweise schickt man da ja nicht im Sekundentakt irgendwelche Ansagen.

Eine Sache, die mir grade noch einfällt:
Es kann auch sein, dass sich die Ansage mit dem generellen 5-minütigen Polling vom Modul überschneidet. Dann lohnt es sich, das Abfrageintervall jeweils zu erhöhen, also

Code Auswählen Erweitern

attr <device> interval <SEKUNDEN>Kann man z.B. auf 600 setzen, dann sind es 10 Minuten. Führt dann aber natürlich dazu, dass sich Readings etc. auch später aktualisieren. Musst du also wissen, wie die Abwägung hier ausfällt.

[Superposchi]

Der Code für die Ansagen sieht folgendermaßen aus:

Code Auswählen Erweitern

sub Ansage($$) {
    my ($Ansage, $Device)  = @_;
    my @Echolist  = ($Device); # Namen der Lautsprecher
    my $Echo  = "";

    foreach $Echo (@Echolist) {
        fhem("set $Echo speak \"$Ansage\"");
    }
}
und wird dann mit solchen Command in der Regel aus DOif's heraus ausgelöst:

Code Auswählen Erweitern

({Ansage("Das ist eine Testansage", "Echo_Wohnzimmer,Echo_Kueche")})Dein Beispiel von oben lässt sich also nicht so einfach umsetzen. Gibt es bei Alexa eigentlich kein Gruppengerät wie bei Google Cast-Geräten? Das müsste das Problem ja auch schon reduzieren, da - wenn ähnlich zu Google - das Gruppengerät als ein Lautsprecher behandelt wird. Kenne mich mit der Materie und den Unterschieden nicht gut genug aus.

Das andere Problem ist halt, dass ich verschiedene Sachen ansagen lassen wie zb das öffnen von Rolladen, das ändern der Heiztemperaturen aber auch Termine wie Blumen gießen, Geburtstagserinnerungen etc.. Damit diese nicht auch in der Nacht ausgegeben werde habe ich sie natürlich alle in einem Zeitfenster stehen (von 10-20 Uhr). Das führt aber natürlich dazu, dass wenn sich in dem Zeitraum dazwischen mehrere Ereignisse aktivieren, diese zusammen um 10 Uhr ausgegeben werden.
Meine Idee von gestern war jetzt, in dem oben geposteten Code als erstes eine Variable einzufügen die zu Beginn, also direkt nach dem Aufruf auf 1 gesetzt wird und erst ganz zum Schluss wenn die Durchsagen abgearbeitet wurden und eine kurze Pause von 2-3 Sekunden vergangen ist wieder auf Null zurückgesetzt wird.
Wenn dann zu Beginn des Codes eine Abfrage mit Schleife eingebaut würde die diese Variable abfragt und falls nicht 0 in die Schleife geht, sollte doch nach meinem Verständnis die zweite, dritte  Ansage etc. entsprechend durch die Schleife abgefangen und verzögert werden. Denn auch wenn Fhem sehr schnell ist, können die Befehle ja nicht exakt zeitgleich abgesetzt werden, sondern müssen im Microsekunden-Bereich nacheinander laufen.

Korrigiere mich bitte wenn ich damit falsch liegen.

[passibe]

nicht so einfach umsetzen

Doch, schon, du könntest z.B. abfragen, ob Echolist mehr als 1 Element (oder wie auch immer das bei Perl heißt) hat und dann die Verzögerung einbauen.

Das mit der Schleife könnte an sich schon funktionieren, aber dann müsstest du gut aufpassen, dass die Schleife dir nicht blockiert. Vielleicht lieber mit temporären at-Devices arbeiten (so wie der wakeuptimer von Residents) oder die Ansagen, die über Nacht anfallen, sammeln, damit sie auf einmal ausgegeben werden können und es dazu nicht n>1 Funktionsaufrufe braucht.

Das mit der Gruppe habe ich ja schon gesagt, du kannst das über eine structure steuern und dann dort die Verzögerung einbauen (siehe mein allererster Beitrag).

[MadMax-FHEM]

Gibt es bei Alexa eigentlich kein Gruppengerät wie bei Google Cast-Geräten? Das müsste das Problem ja auch schon reduzieren, da - wenn ähnlich zu Google - das Gruppengerät als ein Lautsprecher behandelt wird. Kenne mich mit der Materie und den Unterschieden nicht gut genug aus.

Ja gibt es, sofern du eines über die App anlegst...
...allerdings kann das mWn keine Ansage machen (und wenn, gibt es damit auch Probleme, zumindest ist diese Problematik [also "abgehackte Ansagen etc.] auch ab und an Thema im echodevice-Thread)...

Dein Beispiel von oben lässt sich also nicht so einfach umsetzen.

Warum?
Einfach prüfen, ob noch ein Durchlauf folgt: max. Anzahl Echos in der Liste und einen Schleifenzähler...
Dann statt direkt in der Schleife aufrufen dort "nur" den Aufruf "zusammenbauen": $cmd .= "set $Echo speak \"$Ansage\"" . ";" . "sleep 123" . ";";
Wenn nicht, dann ein sleep ans Ende, ansonsten nicht (mehr)...
Und nach der Schleife dann den Befehl (inkl. sleeps) aufrufen: fhem("$cmd");

Gruß, Joachim

[Superposchi]

@MadMax-FHEM
OK, so fit bin ich in Perl nicht das ich daran gedacht hätte. Wüsste auch jetzt nicht auf Anhieb wie ich eine Prüfung durchführen könnte ob mehr als ein Device angesprochen wird. Reicht da ein "if $Device > 1 then ..."?

Bei all der Hilfe müsst ihr bedenken, dass hier inzwischen zwei Dinge ineinander greifen.
1. Das Problem verschluckter Ansagen wenn mehrere Echo's angesprochen werden
2. Das gleichzeitige Auslösen diverser Ansagen durch verschiedene Ereignisse.

Mein Kommentar mit der Schleife zielte auf Nr. 2 ab, ist aber wie zu sehen auch für 1. einzusetzen.

@passibe
Das mit dem structure für Echo-Devices habe ich mitbekommen aber bisher praktisch noch nicht ausprobiert, da ich noch schauen wie ich am besten vorgehe. Das mit dem sammeln klingt aber auch interessant und das würde nicht nur da greifen sondern zu jedem Zeitpunkt. Das mit dem Zeitfenster waren ja nur Beispiele, wenns ganz dumm läuft kommt um 11.37 Uhr eine Ansage das der Wächetrockner im Keller fertig ist und gleichzeitig wird das Rolle als Sonnenschutzt teilweise geschlosssen -> Ansage Rollo.
Wie gesagt ist aktuell nicht immer vorhersehbar wann welche Ereignisse eine Ansage auslösen. Sowas wie komme nach Hause und Heizung wird hochgedreht kann man manuell zeitlich trennen, aber wenn die Ansagen automatisch ausgelöst werden wird das natürlich schwerer. Daher wäre ein gruppieren wahrscheinlich der richtige Weg. Allerdings hab ich Null plan wie das funktionieren könnte.

[passibe]

Vielleicht lohnt es sich auch, zu überlegen, welche Ansagen du wirklich brauchst. Dass ein Rollo geschlossen wird, merkt man in der Regel ja – entweder akustisch oder weil man es direkt sieht (oder halt spätestens wenn man in den jeweiligen Raum geht).
Auch das mit der Heizung: Ich vertraue z.B. einfach darauf, dass FHEM schon seinen Job macht und die Heizung hochdreht, dazu brauche ich keine Ansage. Sollte es nicht funktionieren, merke ich es spätestens, wenn mir kalt wird und kann mich dann auf die Fehlersuche begeben.

Manche Benachrichtigungen sind evtl. auch besser als Push-Benachrichtigung ausgeführt, als dass Alexa ständig dazwischenblökt.

Ist aber natürlich alles Geschmackssache und kommt auf die konkreten Use-Cases an, aber vielleicht ist Verschlankung hier eine (jedenfalls teilweise) Lösungsmöglichkeit.

[Superposchi]

Ja da hast du sicherlich recht. Viele der Ansagen dienen auch nur der Kontrolle, darum kann ich eigentlich jedes Ansage-Ereignis per ftui ein-/ausschalten.

Was die Pushnachrichten angeht habe ich damit angefangen und stelle vieles auf Ansagen um oder lasse es parallel ausführen, da ich gemerkt habe, dass bei reinen Push-Nachrichten zu oft der innere Schweinehud gewonnen hat, grins.

Aber ich muss mal prüfen was ich weglassen könnte.