*.Timer.triggered wird genau nach 1 Minute "false"

[padrino-x]

*.Timer.triggered wird eine Minute nachdem es auf "true" ging, auf "false" gesetzt und das ganz egal, ob oder wann ein timer gestoppt wurde. Also, selbst, wenn er noch klingelt, geht es nach 1min auf "false", ist er schon lange aus, bleibt er "true" und geht erst nach einer Minute auf "false"...

Bisher habe ich den DP genutzt und mich zu informieren, wenn ich mal einen klingelnden Timer überhöre/vergesse, weil ich grad nicht anwesend bin. 🙂

[Apollon77]

Hm ... Debug log please of such a case (with a bit before and a bit afterwards)

[padrino-x]

Hi, just sent you an email, subject "Debug für Timer Stopp", hope it helps. =)

[Apollon77]

Aaalso, der Grund ist an sich einfach. Alexa stoppt irgendwannn eine klingelnden Timer von alleine, daher prüftmder Adapter 60s nach dem Timer Trigger den Status indem es erneut alle Daten von Amazon abholt. In Deinem Fall ist der Timer dort als gestoppt verzeichnet (auch wenn er scheinbar noch klingelt). Daher wird der Trigger auf false gesetzt. Das ganze ist ein"Sicherheitmechanismus" damit genau der State nicht auf "true" hängenbleibt wenn keiner STopp sagt (zb weil niemand daheim ist und der Timer vergessen wurde)

Klar kann ich jetzt diesen Check nach weiter hinten schieben (müsste man mal stoppen wie lange Alexa nen Timer bzw nen Reminder aktiv ausgibt), aber auch dann würde er irgendwann sich zurücksetzen.

Diese Logik ist aber "schon immer" so ... Also ist am wahrscheinlichsten das Amazon hier etwas geändert hat und "abgelaufene aber noch alarmierende Timer" jetzt als "inaktiv" gemeldet werden. Die Daten beinhalten leider auch keine Information das der Timer noch nicht bestätigt wurde.

Also sorry aber ich weiss nicht was ich hier sinnvollerweise tun soll.

[padrino-x]

Hmm, also, wenn ich nicht irre, dann wird ein Timer eben nie gestoppt (oder zumindest war das mal so)...

Seltsam ist, wenn ich einen Timer schlummern lasse und dann stoppe (bevor er abgelaufen ist), dann passt alles.

Da läuft also was nicht wie geplant. Kann man da nicht irgendwie amazon mit Infos anschreiben? Wobei ich vermute, das wird schon am normalen "support" scheitern und wird nie zum "second level" eskaliert... :/

[Apollon77]

Naja ein Timer der schlummert wird nicht beendet sondern quasi aktualisiert und das bekommt der Adapter mit.

Am Ende kann ich sagen das alles läuft wie geplant und an sich immer so war.

Und nein bitte nicht Amazon anschreiben - bedenke das am Ende alles was wir tun inoffizieller kram ist!

[padrino-x]

Naja, es läuft ja eben nicht wie immer, denn früher klappte es ja. ;)

Übrigens, die App bekommt genau mit, wann ein timer gestoppt wird. Er bleibt so lange mit 00:00:00 in der Liste stehen (also auch über 1 Minute), bis man ihn (von wo auch immer) stoppt. Und es hieß doch mal, der Adapter macht/kann das, was die App macht/kann...

[Apollon77]

bleibts auch da stehen wenn du die seite in der app neu lädst während alarm noch an ist?

[padrino-x]

Also, neu laden kann meine Version der App nicht... 🤷🏻‍♂️ Aber ich kann die App schließen und nach über einer Minute neu öffnen, dann steht der klingende Timer mit 00:00:00 immer noch da. Kommt aufs gleiche raus, oder? 😊

[Apollon77]

Keine AHnung wann der die Daten neu lädt ... dein log ist an sich eindeutig ... muss ich ggf ganz tief reinschauen, aber die Zeit ist gerade mega knapp

[padrino-x]

Ok, jetzt wird es verrückt. 😭

Wenn der Timer klingelt, dann macht es einen Unterschied, ob ich nur "stop" oder "stop timer" bzw. "timer stop" sagen. Nur beim "einsamen" Stop taucht das Phänomen auf. 😕

Vermute mal, ein Log von beiden Situationen bringt da nix, oder? 🤔

[Apollon77]

ichhatte gescheit - wir reagieren bei der history auswertung bisher nicht auf "timer spezifische aussagen" vs "nicht" ... ich hatte aber auch schon fälle wo Timer auf "stop" nicht reagiert haben generell .... aber fürchte log hilft da nicht wirklich

[padrino-x]

Sorry, verstehe den Text nicht so richtig... :/

[Apollon77]

Ok versuche anders zu erklären: Es gibt ein paar Stellen wo wir bei Sprachkommandos auf typen reagieren um Daten zu aktualisieren (vor allem playlist und so). Bei Timer war sowas bisher nie nötig, von daher verlassen wir uns da generell auf das was Amazon an Push Infos liefert.

Das andere war eigene Erfahrung das Timer manchmal auf ein normales" Stop" gar nicht reagieren bei mir und ein "Timer stop" nötig ist damit was ausgeht.

Von daher hilft ein Log eher wenig weil es ja scheinbar dann korrekt tut wenn Amazon die Push infos schickt zu änderungen. Der Sonderfall tritt ja auf wenn nichts gesendet wird und der Adapter nach 60s Daten neu holt die dann Datentechnisch (zumindestens für die aktuelle Logik) sagen das der timer beendet ist. Wenn es jetzt darum geht herauszufinden warum in einzelnen situationen der timer noch alarmiert und die app den auch so anzeigt aber wir denken er ist abgelaufen ... da muss ich mit zeit und muse sehtief rein schauen und dafür habe ich aktuell nicht die Zeit. Sorry. Aber auflassen zeit wird mal wieder kommen (ich weiss hilft dir aktuell nicht)

[Apollon77]

PS: Nein nicht genervt nur gerade kilometer tief in Matter vergraben

[padrino-x]

Ok, verstehe, danke für die Info. =)

Übrigens, ich spring hier zwar gerade mit dem Kopf gegen die Wand, aber ich kann dafür zumindest schonmal sagen, dass ein klingelnder Timer auch nach 17 Minuten nicht von Amazon terminiert wird. 8)

[padrino-x]

Lustiger "fun fact"... Zwar wird "triggered" immer noch nach einer Minute auf "false" gesetzt, also auch, wenn der Timer noch am Klingeln ist (also amazon gibt das falsch weiter), aber nach dem "Type1 Fix" für Alexa2 wird "triggered" nun wenigstens wieder sofort auf "false" gesetzt, auch wenn man nur "stop" und nicht "timer stop/stop timer" sagt. :D Von daher bin ich jetzt erstmal wieder happier. =)

[Apollon77]

Interesshalber ... wie isses mit der neuen Version jetzt nach dem Update?

[padrino-x]

Alles, wie gehabt. Also, "triggered" reagiert korrekt auf "stop" (auch ohne das Wort "timer"), aber lässt man den Timer einfach laufen, wird "triggered" nach 60 Sekunden auf "false" gesetzt. Also, alles in allem, verschmerzbar. ;) Ich frage mich nur gerade, ob man diesen Check nach einer Minute nicht besser weg lassen sollte, da das Ergebnis zu 50% falsch ist... Wäre es nicht besser, wenn triggered falsch auf "true" steht als falsch auf "false" (was es aber ja eigentlich nicht tut, da die push Info ja korrekt rein kommt)?

[Apollon77]

Schick mir gern nochmal ein debug log von so einem Fall. Dann schaue ich nochmal.

Formal ist aber alles korrekt ;-) "triggered" hat als einzige Bedeutung das die Zeit abgelaufen ist und der Timer getriggert wurde. Und ist ein "trigger auf Update" - das sich der auf false überhaupt zurücksetzt ist Nettigkeit von mir. Also das reset auf false war noch nie gemeint als "er alarmiert nicht mehr"! Falls das mal so getan hat war das eher Zufall ;-)

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within the next 7 days. Please check if the issue is still relevant in the most current version of the adapter and tell us. Also check that all relevant details, logs and reproduction steps are included and update them if needed. Thank you for your contributions. Dieses Problem wurde automatisch als veraltet markiert, da es in letzter Zeit keine Aktivitäten gab. Es wird geschlossen, wenn nicht innerhalb der nächsten 7 Tage weitere Aktivitäten stattfinden. Bitte überprüft, ob das Problem auch in der aktuellsten Version des Adapters noch relevant ist, und teilt uns dies mit. Überprüft auch, ob alle relevanten Details, Logs und Reproduktionsschritte enthalten sind bzw. aktualisiert diese. Vielen Dank für Eure Unterstützung.