[Aufruf] Alexa2 2.6.0 Testen
-
@apollon77 funktioniert hier einwandfrei, geile Sache! Dankeschön!
-
@apollon77
bei mir funktioniert das Lautstärke setzen über speak-volume in Verbindung mit ssml nicht. Die Ansagelautstärke bleibt gleich.
Ich bin eben mal zurück auf 2.51, da funktioniert es. -
@dslraser
Kann ich bestätigen.
Speak und Announcement dagegen gehen noch.
Lustig, bei SSML wird am Anfang zwar nicht geändert, aber am Ende wieder "zurückgesetzt" (dann kommt der "bupp"-Ton).
-
@apollon77 sagte in [Aufruf] Alexa2 2.6.0 Testen:
Hey All,
ich habe mal wieder etwas Zeit genutzt und noch weitere offene Dinge abgearbeitet und so ist auf GitHub gerade die v2.6.0 verfügbar und ich bitte um Tests
Changelog:
- Announcement und SSML werden jetzt mit einem Kommando gesendet, was synchroner bei Gruppen sein sollte. Speak bleibt wie bisher weil geht nicht anders
Bei mir sind 3 einzelne Announcements/SSML/Speak an alle 3 Echo Dots bei 10 Tests immer synchroner in der Ausgabe als beim Setzen des jeweiligen Datenpunktes meiner Gruppe aller Echo Dots.
Der Versatz beträgt gern mal 0,5 Sekunden oder mehr. Im 2.4x Thread war doch eine Methode für die synchrone Gruppenansteuerung erwähnt. Ist das das was du nun umgesetzt hast? -
@Diginix genau. Zuerst wir für jedes device einzeln die Lautstärke gesetzt, dann in einem einzelnen Kommando die Sprachausgabe mit der Liste der Geräte und Amazon regelt die synchronität. Danach wieder Lautstärke einzeln zurück setzen.
-
@dslraser ok checke ich nachher.
-
@apollon77 sagte in [Aufruf] Alexa2 2.6.0 Testen:
@Diginix genau. Zuerst wir für jedes device einzeln die Lautstärke gesetzt, dann in einem einzelnen Kommando die Sprachausgabe mit der Liste der Geräte und Amazon regelt die synchronität. Danach wieder Lautstärke einzeln zurück setzen.
Komisch dass es dann so derart asynchron ist. Und dazu auch noch besser wenn ich die Geräte einzeln zur gleichen Zeit ansteuere. Und was auch schon immer ein Problem bei mir ist. von 5 Ausgaben auf meinen 3 Dots werden gern mal 1-2 auf einem der 3 nicht ausgegeben.
Aber alles jammern auf hohem Niveau. Die Welt dreht sich weiter. -
Auf GitHub gibt es die 2.6.1 mit:
- volume set bei ssml gefixt
- ein neues Deivce (Kommandos deaktiviert für Stereo/Subwoofer Pairs)
- Reminder für >1 tag in Zukunft sollten jetzt gehen
-
@apollon77 sagte in [Aufruf] Alexa2 2.6.0 Testen:
Auf GitHub gibt es die 2.6.1 mit:
- volume set bei ssml gefixt
Scheint zu klappen.
Reminder für >1 tag in Zukunft sollten jetzt gehen
Cool, tut.
Vielen Dank!Kannst Du sagen, wieso der Timestamp, wenn man eine neue Erinnerung anlegt, nicht in "... .Reminder.New" mit auftaucht (also "timestamp,uhrzeit")?
Sondern nur die Uhrzeit?
Lässt sich da evtl. etwas machen?
-
@apollon77 sagte in [Aufruf] Alexa2 2.6.0 Testen:
volume set bei ssml gefixt
Funktioniert wieder, Danke
-
@padrino Hast nen Screenshot? Ich denke ist verbunden mit der Ursache der anderen Änderung. Früher gingen Reminder maximal einen tag in die Zukunft ... das hab ich jetzt geändert. kann sein das da noch eine Anzeigethematik ist ...
-
@padrino Vergiss es ... brauchst mir nichts schicken ... ich weiss es wieder. Da ist etwas wofür ich noch keine Lösung habe. Die interne Struktur der Daten ist seeeehr gewöhnungsbedürftig bei den Remindern. Vor allem bei sich wiederholenden Timern bleibt das Datumsfeld "originalDate" (Ja heisst so) üblicherweise gleich, hat also ggf einen Wert in der Vergangenheit auch wenn der nächste Lauf in der Zukunft ist (weil zB "täglich" oder so eingestellt ist).
Die Herausforderung ist also zu erkennen wann der Reminder "Zeitbasiert" ist und wann er "Datumsbasiert" ist.Einzige Idee die ich bisher habe ist zu schauen ob das Datum in der Zukunft oder Vergangenheit ist und dann ggf den Wert anders anzuzeigen ... Also wenn in Zukunft dann ist die Annahme das es eine Bedeutung hat, sonst nicht ... Alles irgendwie unschön und keine Ahnung ob diese Annahmen wirklich passen. Um alle möglichen Fälle aktuell auszutesten fehlt mir im Moment die Zeit und Ruhe. Kannst das gern versuchen, hast ja schon grob gesehen wie Du das Log lesen musst
Sonst gern ein GitHub Issue auf machen mit Deinen Erkenntnissen.Das oben beschriebene "Wenn Datum in Zukunft dann anzeigen sonst weiterhin nur die Zeit" kann ich so gern einbauen wenn es sinn macht auch für Dich.
-
@apollon77
Sicher, dass wir vom selben reden?
Ich meine nicht den Eintrag der permanent die gesetzte Uhrzeit gespeichert hat, sondern "timer.new", was nur kurz beim Anlegen eines Timers gesetzt wird. Dort erscheint (auch) keinerlei datum/timestamp. Man kann ihn dort ja nun manuell eintragen , aber er erscheint nicht, wenn ein Timer per Sprache gesetzt wird. Was toll wäre. -
@padrino Ok, dann reden wir von verschiedenen Dingen.
Du hättest gern das neue Timer/Reminder die ausserhalb von ioBroker gesetzt werden in "Timer/Reminder.new" auftauchen? Bisher ist ".new" ein nur "schreibender" State für ioBroker Nutzung -
@apollon77
Fast.;)
Sie tauchen auch jetzt schon dort auf, was ich mit dem Skript "globale Erinnerung" bereits triggere
Allerdings steht dort dann nur 12:12:00 drin und nicht 0123456789,12:12:00 -
@padrino Sorry, ich kapiere nur Bahnhof
-
@apollon77
Sorry, bin nicht am Rechner...
Aber ".new" ist nicht nur ein schreibender state, es ist jetzt schon auch anzeigend ( wenn der timer außerhalb von ioB gesetzt wird. Aber es steht nur die Uhrzeit im "menschenlesbaren" Format drin hh:mm:ss -
Hm ... ich finde keinerlei Code der das tun sollte ...
-
@apollon77
Dann habe ich vermutlich meinen Code falsch im Kopf.
Muss ich heute Abend schauen.
Vermutlich trigger ich dann doch auf ".time". -
@apollon77
Vorne schreibst Du "wenn Datum in der Zukunft".
Wäre es denn ein Problem, wenn Du das Datum immer mit rein packst? Es wäre dann ja nicht falsch.
Und vielleicht kann man ja irgendwann einen weiteren Datenpunkt haben, der das Wiederholungsinter enthält.
